EIGRP over Frame-Relay

EIGRP is normally pretty straight-forward to configure. You type in the correct network commands, routers become neighbors and start exchanging routing information.

Frame-relay is an exception though…it’s no problem to run EIGRP on a frame-relay network but there are some small issues we might have to deal with. We can configure our frame-relay network as multipoint or point-to-point, the multipoint setup will introduce issues when you use a hub and spoke topology.

Let’s take a look at both scenarios. You will learn about the issues and how to deal with them. Here’s the topology I will use:

Above we have three routers, R1 is our hub and R2/R3 are spoke routers. You can see the DLCI numbers in the picture above or you can find them on your routers:

R1#show frame-relay pvc | include DLCI
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

R2#show frame-relay pvc | include DLCI
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

R3#show frame-relay pvc | include DLCI
DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

The show frame-relay pvc command is useful to check the DLCI numbers but also to see if a PVC is active or not. Our layer 2 topology is looking fine so let’s see if we can run EIGRP on this network. We’ll start with the multipoint setup.

EIGRP on Multipoint Frame-Relay

Using multipoint frame-relay means that we will use a single subnet for all PVCs. I will use 192.168.123.0 /24 for our routers, you can see it in the diagram below:

Physical interfaces that use frame-relay encapsulation are multipoint by default. Inverse ARP is also enabled by default so once you configure IP addresses on your interfaces then you should see some frame-relay maps:

R1#show frame-relay map 
Serial0/0 (up): ip 192.168.123.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 192.168.123.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active

R2#show frame-relay map 
Serial0/0 (up): ip 192.168.123.1 dlci 201(0xC9,0x3090), dynamic,
              broadcast,, status defined, active

R3#show frame-relay map 
Serial0/0 (up): ip 192.168.123.1 dlci 301(0x12D,0x48D0), dynamic,
              broadcast,, status defined, active

Take a close look at the output above. You can see that R1 knows how to reach R2 and R3 and these two routers also know how to reach R1. The dynamic parameter tells us that these entries were created by inverse ARP. The broadcast parameter tells us that we can send broadcast and multicast traffic.

Everything looks ok so let’s configure EIGRP:

R1, R2 & R3#
(config)#router eigrp 123
(config-router)#no auto-summary 
(config-router)#network 192.168.123.0

I’ll use the same network command on all routers, after a few seconds they will be neighbors:

R1#show ip eigrp neighbors 
IP-EIGRP neighbors for process 123
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.123.3           Se0/0            170 00:10:35   44   264  0  3
0   192.168.123.2           Se0/0            146 00:10:43 1253  5000  0  3

So far so good, R1 sees two neighbors but we are not done yet. Let’s try to advertise something in EIGRP. I’ll create a new loopback interface on R2 and will advertise it in EIGRP:

R2(config)#interface loopback 0
R2(config-if)#ip address 2.2.2.2 255.255.255.0

R2(config)#router eigrp 123
R2(config-router)#network 2.2.2.0 0.0.0.255

Now let’s see if R1 and R3 learn this network:

R1#show ip route eigrp 
     2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/2297856] via 192.168.123.2, 00:01:06, Serial0/0

R1 knows about it, no issues there. What about R3?

R3#show ip route eigrp 

R3 doesn’t have anything in its routing table. Why not? This is because split horizon is enabled by default. Anything that R1 learns on its serial 0/0 interface will not be advertised out of the same interface. Let’s disable it:

R1(config)#interface serial 0/0
R1(config-if)#no ip split-horizon eigrp 123

Let’s see if this makes any difference:

R3#show ip route eigrp 
     2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/2809856] via 192.168.123.1, 00:00:22, Serial0/0

There we go, R3 has it in its routing table. Are we done now? There’s still one issue we have to deal with…take a look at this ping:

R3#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R3 is unable to ping 2.2.2.2 even though it has an entry in the routing table. Let’s find out what is going on here. First we’ll check R3:

R3#show ip route 2.2.2.2
Routing entry for 2.2.2.0/24
  Known via "eigrp 123", distance 90, metric 2809856, type internal
  Redistributing via eigrp 123
  Last update from 192.168.123.1 on Serial0/0, 00:02:59 ago
  Routing Descriptor Blocks:
  * 192.168.123.1, from 192.168.123.1, 00:02:59 ago, via Serial0/0
      Route metric is 2809856, traffic share count is 1
      Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

R3 is not the issue. It knows that it can reach 2.2.2.2 by sending packets to 192.168.123.1. R3 has a frame-relay map to reach this IP address:

R3#show frame-relay map
Serial0/0 (up): ip 192.168.123.1 dlci 301(0x12D,0x48D0), dynamic,
              broadcast,, status defined, active

Let’s check R1, it won’t hurt to try a ping:

R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/56 ms

Now we know that R3 knows how to reach 2.2.2.2 and R1 is able to ping it. Our ping from R3 is able to make it to R2 so it’s probably the return traffic that is failing. Let’s take a look at R2: