Fun With Distance-Vector Routing & Frame-Relay

Introduction

 

It is important to understand how our different IGP’s work when running over frame-relay. In particular, it is important to understand how things work when dealing with frame-relay hub-and-spoke topologies.  OSPF (link-state protocol) over frame-relay is another whole series of articles in and of itself, but understanding the different defaults and options with respect to our distance-vector IGPs (RIP and EIGRP) are important as well.  In this article we will primarily be taking a look at how RIP operates in a frame-relay hub-and-spoke environment.  We will look at how RIP functions on all three types of frame-relay interfaces – physical, multipoint sub-interfaces and point-to-point sub-interfaces

 

Frame-Relay Physical Interfaces

 

Here is our basic setup for today’s tests.  In our first example, R2, R4 and R5 all run frame-relay and are all running physical frame-relay interfaces on the same IP subnet.  R2 is the frame-relay hub, while R4 and R5 are spokes. Note that R4 and R5 MUST traverse the hub to reach each other and have no direct PVC between themselves.

 

 

Let’s check out our initial configurations here on all devices:

R4

interface Serial0/0
 ip address 100.100.100.4 255.255.255.248
 encapsulation frame-relay
 frame-relay map ip 100.100.100.2 402 broadcast
 frame-relay map ip 100.100.100.5 402
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
!
router rip
 version 2
 passive-interface default
 no passive-interface Serial0/0
 network 4.0.0.0
 network 100.0.0.0
 no auto-summary

R2

interface Serial0/1/0
 ip address 100.100.100.2 255.255.255.248
 encapsulation frame-relay
 frame-relay map ip 100.100.100.5 205 broadcast
 frame-relay map ip 100.100.100.4 204 broadcast
 no frame-relay inverse-arp
!
router rip
 version 2
 passive-interface default
 no passive-interface Serial0/1/0
 network 2.0.0.0
 network 100.0.0.0
 no auto-summary

R5

interface Serial2/0
 ip address 100.100.100.5 255.255.255.248
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 100.100.100.2 502 broadcast
 frame-relay map ip 100.100.100.4 502
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
!
router rip
 version 2
 network 5.0.0.0
 network 100.0.0.0
 no auto-summary

OK, that was fun…now how are we doing with reachability? Let’s check the routing table on R4.

R4#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/1] via 100.100.100.2, 00:00:13, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
R       5.5.5.5 [120/2] via 100.100.100.5, 00:00:13, Serial0/0

R4#ping 5.5.5.5 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/116 ms

We can ping R5 sourced from R4’s loopback, so obviously R5 also has a route for R4’s loopback for the return traffic. We have reachability! That’s good, right?!!! Well…wait a minute. What about that little rule called split-horizon? We all learned it when we first started out with CCNA, and it goes something like this — A router will never send a route out the same interface it received it on. We just saw that happen though…R2 received the 4.4.4.4 route on S0/1/0 and then sent it right back out s0/1/0 to R5. The same thing happened when it received 5.5.5.5 on s0/1/0 and sent it right back out to R4. Why?
Let’s take a look at a show command on our hub router R2 to find out.

R2#sh ip interface s0/1/0
Serial0/1/0 is up, line protocol is up
  Internet address is 100.100.100.2/29
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.9
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is disabled
  ICMP redirects are always sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  IP fast switching is enabled
  IP fast switching on the same interface is enabled
  IP Flow switching is disabled
  IP CEF switching is enabled
  IP CEF switching turbo vector
  IP multicast fast switching is enabled
  IP multicast distributed fast switching is disabled
  IP route-cache flags are Fast, CEF
  Router Discovery is disabled
  IP output packet accounting is disabled
  IP access violation accounting is disabled
  TCP/IP header compression is disabled
  RTP/IP header compression is disabled
  Policy routing is disabled
  Network address translation is disabled
  BGP Policy Mapping is disabled
  Input features: MCI Check
  WCCP Redirect outbound is disabled
  WCCP Redirect inbound is disabled
  WCCP Redirect exclude is disabled

Well, isn’t that interesting! We see that split-horizon is actually disabled here. Why? By default, a Cisco router will actually disable split-horizon on a physical frame-relay interface. In other words, if you have a physical serial interface (as opposed to sub-interface) and you type “encapsulation frame-relay”, boom split-horizon is disabled. Why would Cisco decide to do this you ask? Well, what is the purpose of split-horizon in the first place? To prevent routing loops and the count to infinity problem inherent in distance-vector routing right? Well, the split-horizon rule sort of assumes that we have a broadcast based media. If we were on a broadcast type media, any multicast RIP updates R4 sent out on to the frame would be received by R2 AND R5 at the same time. Additionally, if we didn’t have split-horizon R2 could reflect the same route it received right back to R4 and potentially cause problems…..frame-relay is a NBMA technology, and it doesn’t have a concept of broadcasting. If R4 sends a multicast RIP update, R5 won’t receive it unless it comes through R2.

The important point to understand is that split-horizon is actually disabled by default on frame-relay physical interfaces.

 

Frame-Relay Multipoint Sub-interfaces

 

Now we will switch things up by making R2’s frame-relay link a multipoint sub-interface instead.  Let’s do that…

R2(config)#default interface s0/1/0
Building configuration...


Interface Serial0/1/0 set to default configuration

R2(config)#int s0/1/0
R2(config-if)#shut
R2(config-if)#encapsulation frame-relay
R2(config-if)#no frame-relay inverse-arp
R2(config-if)#no ip address
R2(config-if)#no shutdown
!
R2(config-if)#interface s0/1/0.245 multipoint
R2(config-subif)#ip address 100.100.100.2 255.255.255.248
R2(config-subif)#frame-relay map ip 100.100.100.4 204 broad
R2(config-subif)#frame-relay map ip 100.100.100.5 205 broad
!
R2(config)#router rip
R2(config-router)#no passive-interface s0/1/0.245

Now let’s see if anything has changed on R4

R4#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2/32 is possibly down,
          routing via 100.100.100.2, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
R 5.5.5.5/32 is possibly down,
          routing via 100.100.100.5, Serial0/0

Uh-Oh, we broke it! Oh well, that is a good thing that’s how we learn : ) What happened? Now 5.5.5.5 is reporting as “possibly down” which is RIP speak for a bad day at work. It means we have not heard an update for 5.5.5.5 in a while and the invalid timer expired. The router just has to wait until the flush timer expires now and 5.5.5.5 will be totally gone. In other words, we lost the route for our other spoke. After another 60 seconds you will see 5.5.5.5 be flushed

R4#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/1] via 100.100.100.2, 00:00:12, Serial0/0

What changed? Split-horizon of course!!! Take a look on R2

R2#sh ip int s0/1/0.245
Serial0/1/0.245 is up, line protocol is up
  Internet address is 100.100.100.2/29
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.9
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled
  ICMP redirects are always sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  IP fast switching is enabled
  IP fast switching on the same interface is enabled
  IP Flow switching is disabled
  IP CEF switching is enabled
  IP CEF switching turbo vector
  IP multicast fast switching is enabled
  IP multicast distributed fast switching is disabled
  IP route-cache flags are Fast, CEF
  Router Discovery is disabled
  IP output packet accounting is disabled
  IP access violation accounting is disabled
  TCP/IP header compression is disabled
  RTP/IP header compression is disabled
  Policy routing is disabled
  Network address translation is disabled
  BGP Policy Mapping is disabled
  Input features: MCI Check
  WCCP Redirect outbound is disabled
  WCCP Redirect inbound is disabled
  WCCP Redirect exclude is disabled

So, by default split-horizon is enabled on frame-relay multipoint sub-interfaces, the exact opposite of what we saw on physical interfaces. To fix our routing problem we will need to manually disabled it on the interface of R2.

R2(config)#int s0/1/0.245
R2(config-subif)#no ip split-horizon
R2(config-subif)#do sh ip int s0/1/0.245 | i Split
  Split horizon is disabled

After that change, we are back in business!

R4#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/1] via 100.100.100.2, 00:00:09, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
R       5.5.5.5 [120/2] via 100.100.100.5, 00:00:09, Serial0/0
R4#ping 5.5.5.5 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/113/116 ms

 

Frame-Relay point-to-point sub-interfaces

 

Split-Horizon is indeed enabled on frame-relay point-to-point sub-interfaces.  It’s pretty easy to remember because it makes sense.  In our example, we could have a point-to-point sub-interface to R4 and another to R5.  The router sees them as two completely different interfaces, where split-horizon is enabled on both.  We don’t have a problem with spoke-to-spoke routing by default because the routes will come in one sub-interface and exit another. Even though the packets are leaving out the same physical hardware, to the router they are different logical interfaces so we are OK.

 

EIGRP Behavior

We have primarily focused on RIP here, but let’s have some love for EIGRP too.  EIGRP is really simple when it comes to this — Split-Horizon is enabled by default no matter what kind of frame-relay interface you are dealing with.  That means that by default if we are running EIGRP in our scenario what we have is a broken network.  Can’t we simply do no ip split-horizon on the hub s0/1/0 interface to fix it?  Nope.  We need a special command that is specific to EIGRP.  That would be the no ip split-horizon eigrp command.  You then give it the EIGRP AS number as a parameter of the command and you are all set.

 

Summary

 

Split-Horizon works a little bit differently when dealing with frame-relay and our distance-vector protocols, depending on what exactly the environment looks like.  When working with RIP, remember split-horizon is disabled by default for physical frame-relay interfaces, but enabled by default for multipoint and point-to-point sub-interfaces.  If you are running a hub and spoke network and running RIP on frame-relay multipoint sub-interfaces you may need to disable split-horizon with the  no ip split-horizon command at the interface-level.  When dealing with EIGRP, split-horizon is always enabled by default.  If you need to disable it use the no ip split-horizon eigrp command at the interface level.  Thanks for reading!

 

8 Comments

  • alef says:

    Hi Joe,
    Nice article. I was wondering how a FR hub is actually defined.

    In my labs i sometimes connect through a HUB as we do here, but sometimes i also get DLCI’s that map straight to the other router (i.e. instead of doing frame map ip x.x.x.2 502, x.x.x.3 502, x.x.x.4 502 i would get 502, 503, 504 etc) and a FR switch would still be there (they would not be direct links with just no keepalives on).

    Do we only use a HUB when the HUB is the DR (ip ospf priority 255) and the other links are NON-DR ?

    • Joe Astorino says:

      A frame-relay hub just means a router running frame-relay encapsulation that has PVCs to 2 or more routers. The 2 or more other routers ONLY have a PVC to the hub router and not directly between each other. It is more of a design term than a technical term. This is different than the concept of a frame-relay switch, which is more behind the scenes. In this example. every router is physically wired to a frame-relay switch, but we don’t see that, and we don’t care. We care about the virtual-circuits, or PVCs between the routers. The fact that I have a PVC from R2 –> R4 and a PVC from R2 –> R5 and the fact that R4 and R5 do not have a direct PVC connection makes the topology “hub and spoke”

  • Pranit Rathod says:

    Hi Joe,
    i am little bit confuse in “frame-relay map”command. how to use map cmd in p2p and multipoint.

  • Joe Astorino says:

    @Pranit You generally use the “frame-relay map” command for layer 3 to layer 2 address resolution on a physical or multipoint subinterface. On a point-to-point subinterface you will generally be looking at the “frame-relay interface-dlci” command for the same purpose

  • aulia sabri says:

    Nice article Joe,
    i will spare my time to try it on GNS3 later. This means that using point-to-point (spoke-spoke) network overcomes split horizon issue on distance routing protocol, doesn’t it?

  • Sinade says:

    Nice article.

    Does frame-relay map statement disable frame-relay inverse-arp or we MUST enter it? And if it is not configured, what is the outcome?

Leave a Reply