Frame Relay and RIP problem configuration and observation (CNA-04-002)

CCNA Exploration 4.0, Semester 4, "Frame Relay and RIP problem configuration and observation" Packet Tracer 5.0 practice file (CNA-04-002).

• CNA-04-002.pkt, (Backup Link)
• CNA-04-002-wrong-sol.pkt, (Backup Link)
• CNA-04-002-final-sol.pkt, (Backup Link)

Of course, I do not recommend you to use RIP anymore during my lecture. Since this is a typical RIP over Frame Relay problem in all versions of ICND materials, you might be interested to configure and observe it!

In this example, we have only two Virtual Circuit available. One is between Router 1 and Router 2, and the other is between Router 2 and Router 3. This is quite a typical deployment in "hub and spoke" scenario to minimize virtual circuit cost!

The access to Frame Relay configuration is not difficult at all for you. All you have to do is to change serial encapsulation to "frame-relay". Here is the sample configuration for Router 1:

interface Serial0/0/0
 ip address 10.1.1.1 255.255.255.0
 encapsulation frame-relay

After you configure all three interfaces on three routers, please wait a moment! Cisco IOS's Inverse ARP feature would automatically setup the correct IP addresses mapping to DLCIs. We can examine this on Router 2:

R2#show frame-relay map
Serial0/0/0 (up): ip 10.1.1.1 dlci 201, dynamic, broadcast, CISCO, status defined, active
Serial0/0/0 (up): ip 10.1.1.3 dlci 203, dynamic, broadcast, CISCO, status defined, active
R2#ping 10.1.1.1

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

R2#ping 10.1.1.3

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

R2#

The frame relay access portion is actually done! Now we look closer at the RIP problem.

After we start RIP on all routers with default setting, we will immediately see a serious problem: Router 1 does not receive Router 3's RIP routes, and vice versa.

R1>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
R    192.168.2.0/24 [120/1] via 10.1.1.2, 00:00:23, Serial0/0/0
R1>

The cause for this on Router 2. We have only two virtual circuits available in this case. Therefore, only Router 2 will receive Router 3's RIP updates. Router 1 will never receive them unless Router 2 re-send those RIP updates for Router 1.

Recall the default behavior of "split horizon": both Router 1 and Router 3 are addressed in the same subnet, so any RIP updates received in Router 2's Serial0/0/0 interface connecting to this subnet will not be re-sent out through the same interface Serial0/0/0 by Router 2!

That is why Router 1 will not receive Router 3's updates, because Router 2 won't re-send them!

To eliminate this problem, we have to disable the "split horizon" function on Router 2's Serial0/0/0, like this:

interface Serial0/0/0
 ip address 10.1.1.2 255.255.255.0
 no ip split-horizon
 encapsulation frame-relay

Then RIP goes well with such Frame Relay deployment and addressing!

I want to repeat this over and over to you: this is only a sample problem of RIP on Frame Relay. I strongly suggest you to use better protocols such as EIGRP or OSPF instead. Both of them does not have such odd "split horizon" problem. You should refer to this only if you cannot remove RIP in your network!