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:

EIGRP Frame Relay Hub Two Spokes

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:

R1 R2 R3 EIGRP Frame-relay multipoint

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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 654 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

540 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Rene,

    I noticed in the frame-relay “eigrp on Multipoint Frame-Relay” you did not do the ping back to R3.
    So, when I tried it failed of course. I created in GNS3 a loopback 3.3.3.3 on R3 and advertised it on
    EIGRP and it would not ping from router 2(R2). You then have to correct the problem by mapping the DLCI on
    router 3, as well. If you do not add the static DLCI mapping to the interface s0/0 on R3 the entire router
    is not able to be pinged from R2 to R3. Checking the Routing table shows an EIGRP route (R2) through R1 but
    R3 will not respond to the echo reque

    ... Continue reading in our forum

  2. @Forrest That’s right, in that example I only solved the problem for the ping from R3 to R2 by adding a frame-relay map on R2. For the other way around, you should add a map on R3 as well.

    The underlying problem here is that EIGRP expects the network to be multi-access, this means that all devices should be able to reach each other directly. In reality, only the hub can reach the spokes directly. You won’t be able to estalish an EIGRP adjacency between R2/R3 directly with only PVCs to the hub.

    It’s better to use frame-relay point-to-point everywhere instead. Yo

    ... Continue reading in our forum

  3. Hi,

    My question is if we have to configure also the spoke routers with the same type of logical sub-interface that we use in the hub? In other examples, and I used it as well on GNS3, I configured my hub router with logical sub-interfaces (point-to-point)/(multi-point) but for the spoke routers I always used the physical interface regardless the setup on the hub router. Is this approach correct ? Thus my configuration on the spokes was always done with the "frame-relay map ip ", which I take into account both for the hub router and rest of spokes. Thus I use

    ... Continue reading in our forum

  4. Hello Konstantinos!

    The spoke routers can be configured to function using a subinterface or using the physical interface for both point to point configurations (each link between routers has its own subnet) or point to multipoint configurations (all routers are in the same subnet). It is a good idea however to use subinterfaces because the numbers used for the subinterface can correspond to the DLCIs of the PVC. It is also a more symmetric configuration having both ends configured in the same way. The functionality will be the same however.

    I hope this has been helpful!

    Laz

  5. Hello Oliver

    When configuring subinterfaces to function with Frame Relay, it is necessary to first configure the main physical interface with frame relay encapsulation. There is no need to configure an IP address as each subinterface will have its own IP address.

    I hope this has been helpful!

    Laz

15 more replies! Ask a question or join the discussion by visiting our Community Forum