CCNA Routing Labs

Three Router RIP Lab

The purpose of this lab is to explore the functionality of the RIP routing protocol. The main goal is to allow PC1 to reach PC2 and vice versa. Hardware Required for Lab

A Cisco router with two Fa0/0 interfaces and one serial port. A Cisco router with two Fa0/0 interfaces and one serial port. A Cisco router with two Fa0/0 interfaces. Two straight through Cat 5 cable Two crossover Cat 5 cables One smart serial cable or two DCE/DTE serial cables depending on router. One Console Cable Two PCs to connect to the routers Commands Used in Lab enable - Used to move from unprivileged mode to privileged mode. show ip interface brief - Displays a brief summary of the interfaces on the router, what IPs they have configured, and their status. Initial Configs R1
host R1 line con 0 logging synch exit int fa0/0 ip add 192.168.12.1 255.255.255.0 no shut int fa2/0 ip add 192.168.11.1 255.255.255.0 no shut

int s1/0 ip add 192.168.131.1 255.255.255.0 clock rate 64000 no shut exit int loopback 1 ip add 1.1.1.1 255.255.255.255 R2 host R2 line con 0 logging synch exit int fa0/0 ip add 192.168.12.2 255.255.255.0 no shut int fa1/0 ip add 192.168.23.2 255.255.255.0 no shut exit int loopback 1 ip add 2.2.2.2 255.255.255.255

R3
host R3 line con 0 logging synch exit int fa0/0 ip add 192.168.23.3 255.255.255.0 no shut int fa2/0 ip add 192.168.33.1 255.255.255.0 no shut int s1/0 ip add 192.168.131.3 255.255.255.0 clock rate 64000 no shut exit int loopback 1 ip add 3.3.3.3 255.255.255.255

PC1

PC2

Note: Even though the nature of serial links require a clock rate to be set on the DCE, you can safely add the clock rate to each side of the link. The router with the DTE end of the link will simply ignore the command.

RIP is one of the oldest and simplest routing protocols that is still in use and will be around for some time to come. Enabling RIP on the router is done with the router rip command Once RIP is enabled it is necessary to use network statements to tell the router which interfaces are going to send and receive RIP updates. The network statement uses the following syntax: network <classful network> Most people have trouble understanding the purpose of the network statements when they are first learning routing protocols because they commonly assume that the command is used to advertise networks into RIP. This is not correct, when you enter the network command under RIP the router will check what interfaces match the classful network and adds the interface to the routing process. As a refresher the classful networks are:

CIDR suffix 0 0.0.0.0 127.255.255.255 /8 Class A 10 128.0.0.0 191.255.255.255 /16 Class B 110 192.0.0.0 223.255.255.255 /24 Class C Class D (multicast) 1110 224.0.0.0 239.255.255.255 /4 Class E (reserved) 1111 240.0.0.0 255.255.255.255 /4 Lets configure RIP between R1 and R2 for all networks Class Leading bits Start End
R1(config)#router rip R1(config-router)#network R1(config-router)#network R1(config-router)#network R2(config)#router rip R2(config-router)#network R2(config-router)#network R2(config-router)#network 192.168.11.0 192.168.12.0 1.1.1.1 192.168.12.0 192.168.23.0 2.2.2.2

Default subnet mask 255.0.0.0 255.255.0.0 255.255.255.0 not defined not defined

Lets explore the RIP configure on R1 a bit more in depth, checking the show run config we can see that even though we entered the loopback network as 1.1.1.1 the router scaled it back to its classful boundary.
R1#show run | sec router router rip network 1.0.0.0 network 192.168.11.0 network 192.168.12.0

A quick way to check various information about RIP including what interfaces RIP is running on is: show ip protocols
R1#show ip protocols Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 26 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain FastEthernet0/0 1 1 2 FastEthernet2/0 1 1 2 Loopback1 1 1 2 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 1.0.0.0 192.168.11.0 192.168.12.0 Routing Information Sources: Gateway Distance Last Update 192.168.12.2 120 00:00:00 Distance: (default is 120)

Lets take a moment to go over some of the output shown from show ip protocols

Sending updates every 30 seconds, next due in 26 seconds Invalid after 180 seconds, hold down 180, flushed after These are the current timers that RIP is us 240 Interface Send Recv Triggered RIP Keychain This shows what interfaces RIP is running FastEthernet0/0 1 1 2 RIPv2 for all other labs. FastEthernet2/0 1 1 2 Loopback1 1 1 2 Automatic network summarization is in effect This shows that RIP is summarizing all ro Routing for Networks: 1.0.0.0 This is a quick summary of what network 192.168.11.0 192.168.12.0 Routing Information Sources: Gateway Distance Last Update This section is used to quickly see what ne 192.168.12.2 120 00:00:00 Distance: (default is 120) This shows the administrative distance, we

Now that we have an idea about how RIP is configured, lets check the routing table to see whats there.
R1#show ip route Codes: C - connected, S - static, 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 i - IS-IS, su - IS-IS summary, 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 C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback1 C 192.168.131.0/24 is directly connected, Serial1/0 R 2.0.0.0/8 [120/1] via 192.168.12.2, 00:00:04, FastEthernet0/0 C 192.168.11.0/24 is directly connected, FastEthernet2/0 R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:04, FastEthernet0/0

You should already be somewhat familar with the basics of the routing table from earlier labs, whats new is now we are now seeing seeing RIP routes which are denoted with an "R" Notice that the 192.168.12.0/24 network is not seen as a RIP route because its directly connected and the router will always believe its directly connected routes over anything. You can also filter the routing table by protocol to help you focus on exactly what your interested in
R1# show ip route ? Hostname or A.B.C.D bgp connected dhcp eigrp isis list mobile Network to display information about or hostname Border Gateway Protocol (BGP) Connected Show routes added by DHCP Server or Relay Enhanced Interior Gateway Routing Protocol (EIGRP) ISO IS-IS IP Access list Mobile routes

odr ospf profile rip static summary supernets-only track-table update-queue vrf | <cr> R1# R R

On Demand stub Routes Open Shortest Path First (OSPF) IP routing table profile Routing Information Protocol (RIP) Static routes Summary of all routes Show supernet entries only Tracked static table Queue of RIB updates Display routes from a VPN Routing/Forwarding instance Output modifiers

show ip route rip 2.0.0.0/8 [120/1] via 192.168.12.2, 00:00:10, FastEthernet0/0 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:10, FastEthernet0/0

Lets take a minute to show explain the output of the routing table
R 2.0.0.0/8 120 1 via 192.168.12.2 00:00:10 FastEthernet0/0

Denotes a RIP route This is the learned route and subnet mask This is the administrative distance for RIP, by default it is 120 This is how many hops away the route is, in RIP a hop is each router it passes throug This is the next hop neighbor that the route was learned from This is the age of the route since the last update, when everything is normal RIP sho Lastly this is the interface the route was learned on. Notice that even though R2's loopback is 2.2.2.2/32 RIP has striped the network back to its classful boundary 2.0.0.0/8 This is because RIPv1 doesn't send any subnet mask information with its routing updates so the receiving router has no choice but to assume a classful boundary. This behavior can been seen in the following debug.

R1#debug ip rip RIP protocol debugging is on R1# *Mar 1 00:43:32.991: RIP: received v1 update from 192.168.12.2 on FastEthernet0/0 *Mar 1 00:43:32.995: 2.0.0.0 in 1 hops *Mar 1 00:43:32.999: 192.168.23.0 in 1 hops R1# *Mar 1 00:43:35.915: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (19 *Mar 1 00:43:35.919: RIP: build update entries *Mar 1 00:43:35.919: network 1.0.0.0 metric 1 *Mar 1 00:43:35.923: network 192.168.131.0 metric 1 R1#un all All possible debugging has been turned off

One of the many pitfalls of RIPv1 is that it simply broadcasts its update to everyone (the 255.255.255.255 address) This means that every host on the network will receive the RIP updates whether they want them or not!!! Below is a packet capture of traffic going to PC1, even though the PC isn't runnng RIP it is still receiving all the RIP packets which can be both a waste of bandwidth and a security concern.

Note: You can ping multicast or broadcast addresses from a router to quickly see what hosts will receive certain kinds of packets R1# ping 255.255.255.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds: Reply to request 0 from 192.168.131.3, 20 ms Reply to request 0 from 192.168.12.2, 36 ms

Since RIPv1 isn't on the CCNA (or any Cisco exam) anymore we won't spend anymore time on it. Before we switch to RIPv2 we'll first add the remaining interfaces into RIP
R3(config)#router rip R3(config-router)#network R3(config-router)#network R3(config-router)#network R3(config-router)#network 192.168.33.0 192.168.23.0 192.168.131.0 3.3.3.3

To use RIPv2 you simply need to type: version 2 under the RIP configuration.
R1(config)#router rip R1(config-router)#version 2 R2(config)#router rip

R2(config-router)#ver 2 R3(config)#router rip R3(config-router)#ver 2

We can confirm RIPv2 is running in a couple ways, lets start by looking at the show ip protocols output. Notice that the Send/Receive verison is now just 2
R1# show ip protocols Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 22 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain FastEthernet0/0 2 2 Serial1/0 2 2 FastEthernet2/0 2 2 Loopback1 2 2 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 1.0.0.0 192.168.11.0 192.168.12.0 192.168.131.0 Routing Information Sources: Gateway Distance Last Update 192.168.131.3 120 00:00:14 192.168.12.2 120 00:00:20 Distance: (default is 120)

Another way is check the debug output with: debug ip rip which is RIPs only really useful debug option.

R1#debug ip rip RIP protocol debugging is on R1# *Mar 1 01:24:13.519: RIP: received v2 update from 192.168.131.3 on Serial1/0 *Mar 1 01:24:13.523: 3.0.0.0/8 via 0.0.0.0 in 1 hops *Mar 1 01:24:13.527: 192.168.23.0/24 via 0.0.0.0 in 1 hops *Mar 1 01:24:13.531: 192.168.33.0/24 via 0.0.0.0 in 1 hops R1# *Mar 1 01:24:16.311: RIP: received v2 update from 192.168.12.2 on FastEthernet0/0 *Mar 1 01:24:16.315: 2.0.0.0/8 via 0.0.0.0 in 1 hops *Mar 1 01:24:16.319: 3.0.0.0/8 via 0.0.0.0 in 1 hops *Mar 1 01:24:16.323: 192.168.23.0/24 via 0.0.0.0 in 1 hops R1# *Mar 1 01:24:21.167: RIP: sending v2 update to 224.0.0.9 via FastEthernet2/0 (192.168. *Mar 1 01:24:21.171: RIP: build update entries *Mar 1 01:24:21.171: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:24:21.175: 2.0.0.0/8 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:24:21.179: 3.0.0.0/8 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:24:21.179: 192.168.12.0/24 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:24:21.183: 192.168.131.0/24 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:24:21.183: 192.168.23.0/24 via 0.0.0.0, metric 1, tag 0

*Mar

1 01:24:21.183:

192.168.33.0/24 via 0.0.0.0, metric 1, tag 0

Theres a few things to notice about the debug output, for one it clearly says its sending v2 updates but now it is sending them to the RIP multicast address: 224.0.0.9 instead of broadcasting to everyone. Also notice that subnet masks being sent with the updates now, though you may find it odd that the loopbacks are still being advertised by their classful boundary. This is because RIPv2 will by default continue to automatically summarize routes - This behavior can be turned off with: no autosummary this command will need to be entered on all routers participanting in RIP.
R1(config)#router rip R1(config-router)#no auto-summary R2(config)#router rip R2(config-router)#no auto-summary R3(config)#router rip R3(config-router)#no auto-summary

Checking the debug again we can see that the proper routes are being advertised.

R2#debug ip rip RIP protocol debugging is on R2# *Mar 1 01:35:53.871: RIP: sending v2 update to 224.0.0.9 via FastEthernet1/0 (192.168. *Mar 1 01:35:53.875: RIP: build update entries *Mar 1 01:35:53.875: 1.0.0.0/8 via 0.0.0.0, metric 2, tag 0 *Mar 1 01:35:53.879: 1.1.1.1/32 via 0.0.0.0, metric 2, tag 0 *Mar 1 01:35:53.879: 2.2.2.2/32 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:35:53.879: 192.168.11.0/24 via 0.0.0.0, metric 2, tag 0 *Mar 1 01:35:53.879: 192.168.12.0/24 via 0.0.0.0, metric 1, tag 0 R2# *Mar 1 01:35:57.855: RIP: received v2 update from 192.168.12.1 on FastEthernet0/0 *Mar 1 01:35:57.859: 1.1.1.1/32 via 0.0.0.0 in 1 hops *Mar 1 01:35:57.863: 3.0.0.0/8 via 0.0.0.0 in 2 hops *Mar 1 01:35:57.863: 3.3.3.3/32 via 0.0.0.0 in 2 hops *Mar 1 01:35:57.867: 192.168.11.0/24 via 0.0.0.0 in 1 hops *Mar 1 01:35:57.871: 192.168.131.0/24 via 0.0.0.0 in 1 hops *Mar 1 01:35:57.875: 192.168.33.0/24 via 0.0.0.0 in 2 hops

If we try to ping from PC1 to PC2 we can see it is successful because R1 knows about the 192.168.33.0/24 network .

Lets see how this looks in the routing table, we can see that RIP is choosing to use the serial link to get to the 192.168.33.0/24 network even though has the choice between two routers with 100mbs connections or one with two 64kbs links which clearly isn't the quickest route.

R1#sh ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 192.168.12.2, 00:00:03, FastEthernet0/0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/1] via 192.168.131.3, 00:00:11, Serial1/0 R 192.168.23.0/24 [120/1] via 192.168.131.3, 00:00:11, Serial1/0 [120/1] via 192.168.12.2, 00:00:03, FastEthernet0 R 192.168.33.0/24 [120/1] via 192.168.131.3, 00:00:11, Serial1/0

This is because RIP only takes hop count into consideration, R1 - R3's link is one hop which beats R1 -> R2 -> R3 this can be seen in the following debug
*Mar *Mar *Mar *Mar *Mar 1 1 1 1 1 02:00:07.971: RIP: received v2 update from 192.168.12.2 on FastEthernet0/0 02:00:07.975: 2.2.2.2/32 via 0.0.0.0 in 1 hops 02:00:07.979: 3.3.3.3/32 via 0.0.0.0 in 2 hops 02:00:07.979: 192.168.23.0/24 via 0.0.0.0 in 1 hops 02:00:07.983: 192.168.33.0/24 via 0.0.0.0 in 2 hop 1 1 1 1 1 02:00:03.043: RIP: received v2 update from 192.168.131.3 on Serial1/0 02:00:03.047: 2.2.2.2/32 via 0.0.0.0 in 2 hops 02:00:03.051: 3.3.3.3/32 via 0.0.0.0 in 1 hops 02:00:03.055: 192.168.23.0/24 via 0.0.0.0 in 1 hops 02:00:03.055: 192.168.33.0/24 via 0.0.0.0 in 1 hops

*Mar *Mar *Mar *Mar *Mar

We can test this out with the ping and traceroute commands
R1(config-if)#do ping 192.168.33.1 Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.33.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/25/60 ms R1#traceroute 192.168.33.1 Type escape sequence to abort. Tracing the route to 192.168.33.1 1 192.168.131.3 44 msec 36 msec *

When using the serial link pings take 60 ms to get across the link. Now lets disable the serial link on R1 and try this again.

R1(config)#int s1/0 R1(config-if)#shut R1(config-if)#exit R1(config)# *Mar 1 02:13:58.235: %LINK-5-CHANGED: Interface Serial1/0, changed state to administrativ *Mar 1 02:13:59.235: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed s

Pinging again from R1 we can see that it is using the ethernet links this time and and the pings only take 24ms
R1#ping 192.168.33.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.33.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/24 ms R1#traceroute 192.168.33.1 Type escape sequence to abort. Tracing the route to 192.168.33.1 1 192.168.12.2 40 msec 48 msec 24 msec 2 192.168.23.3 4 msec 40 msec *

RIP does provide a feature that can modify a routes metric called an Offset-List Offset-lists can be used to increase the hop count of a route but can't be used to decrease the hop count. Its importent to keep track of how many hops a route will have when changing the hop metric because RIP only allows any given route to have 15 hops this is help guard against loops and in reality if your network has more then 15 hops you probably won't want to use RIP anyway. The syntax for offset-lists are: offset-list <access-list> <in/out> <offset><interface>
R1(config-router)#offset-list ? <0-99> Access list of networks to apply offset (0 selects all networks) <1300-1999> Access list of networks to apply offset (expanded range) WORD Access-list name R1(config-router)#offset-list 0 ? in Perform offset on incoming updates out Perform offset on outgoing updates R1(config-router)#offset-list 0 in ? <0-16> Offset R1(config-router)#offset-list 0 in 5 ? Async Async interface BVI Bridge-Group Virtual Interface CDMA-Ix CDMA Ix interface

CTunnel Dialer FastEthernet Lex Loopback MFR Multilink Null Port-channel Serial Tunnel Vif Virtual-PPP Virtual-Template Virtual-TokenRing

CTunnel interface Dialer interface FastEthernet IEEE 802.3 Lex interface Loopback interface Multilink Frame Relay bundle interface Multilink-group interface Null interface Ethernet Channel of interfaces Serial Tunnel interface PGM Multicast Host interface Virtual PPP interface Virtual Template interface Virtual TokenRing

<cr> R1(config-router)#offset-list 0 in 5 fa1/0 ? <cr>

Note: Anytime you see <cr> in the ? output this means you can press enter, any other options past that point are optional Here's a break down of the various command options.
access-list access-list 0 in

Access-list that defines what routes will be affected by the offset-list, can be standard Special meaning access-list that means all routes will be affected by offset. This means the offset will be applied to matching inbound RIP routes. out This means the offset will be applied to matching outbound RIP routes (Routes the ro offset # This is how many hops to ADD to the route's hop count. If a route has a hop count of (Optional) Further filter what routes are matched by what interface will send/receive t interface be offset After you go through the Access-list labs you'll understand the various list options but for now we'll stick with access-list 0 for our examples. At the moment we have R1 using the serial link to get to the 192.168.33.0 network because it is only one hop and is 2 hops when using the ethernet links.
R1(config)#do show ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:25, FastEthernet1/0 R 192.168.33.0/24 [120/1] via 192.168.131.3, 00:00:22, Serial0/0 R1(config)# *Mar 1 04:40:16.686: RIP: received v2 update from 192.168.131.3 on Serial0/0 *Mar 1 04:40:16.686: 192.168.23.0/24 via 0.0.0.0 in 1 hops *Mar 1 04:40:16.686: 192.168.33.0/24 via 0.0.0.0 in 1 hops *Mar 1 04:40:30.974: RIP: received v2 update from 192.168.12.2 on FastEthernet1/0 *Mar 1 04:40:30.978: 192.168.23.0/24 via 0.0.0.0 in 1 hops *Mar 1 04:40:30.982: 192.168.33.0/24 via 0.0.0.0 in 2 hops

Lets add a couple hops to all routes coming in from R1's S0/0 interface
R1(config)#router rip R1(config-router)#offset-list 0 in 2 s0/0

After R1 receives the next update (every 30 seconds for RIP) it will change the serial route's metric to 3 and the Fa1/0 route will be prefered.

R1(config)#do sh ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:17, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.12.2, 00:00:17, FastEthernet1/0

Checking on a debug we can see that both R3 routes over the serial link are now shown as 3 hops.
R1# *Mar *Mar *Mar 1 04:47:40.014: RIP: received v2 update from 192.168.131.3 on Serial0/0 1 04:47:40.018: 192.168.23.0/24 via 0.0.0.0 in 3 hops 1 04:47:40.022: 192.168.33.0/24 via 0.0.0.0 in 3 hops

Lets adjust the offset-list to make the metric the same for the serial and the Fa1/0 links, since the serial link is 1 hop and the Ethernet link is 2, we'll just add 1 to the serial link.
R1(config)#router rip R1(config-router)# offset-list 0 in 1 s0/0

Now when we check the routing table we can see that we now have two paths to get to the 192.168.33.0 network, RIP by default will load share between 6 equal cost paths. This provides redundence so if one of the paths have an issue, RIP will eventually detect the issue and remove the path from the routing table.
R1#sh ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:00, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:15, Serial0/0 [120/2] via 192.168.12.2, 00:00:00, FastEthernet1/0

I say eventually detect the issue because RIP is a very slow moving, lazy protocol. It updates every 30 seconds
R1#sh ip route Codes: C - connected, S - static, 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 i - IS-IS, su - IS-IS summary, 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 C 192.168.12.0/24 is directly connected, FastEthernet1/0 C 192.168.11.0/24 is directly connected, FastEthernet2/0 C 192.168.131.0/24 is directly connected, Serial0/0 R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:07, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:07, Serial0/0 [120/2] via 192.168.12.2, 00:00:07, FastEthernet1/0

To test this I'm going to "accidentally" apply an access-list that blocks all traffic onto R1's Fa1/0 interface.
R1(config)#access-list 5 deny any R1(config)#int fa1/0 R1(config-if)#ip access-group 5 in

We can tel something is wrong because the 2 routes haven't seen an update in over a minute when its supposed to update every 30 seconds.

R1#show ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:01:13, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:15, Serial0/0 [120/2] via 192.168.12.2, 00:01:13, FastEthernet1/0

Routes are still present in the table at the 2 minute mark...

R1#show ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:02:01, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:09, Serial0/0 [120/2] via 192.168.12.2, 00:02:01, FastEthernet1/0 R1#show ip route rip

Almost 3 minutes....
R1#show ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:02:50, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:03, Serial0/0 [120/2] via 192.168.12.2, 00:02:50, FastEthernet1/0

Once the routes hit the 3 minute mark they go into the hold down timer and are listed as possibly down.
R1#show ip route rip R 192.168.23.0/24 is possibly down, routing via 192.168.12.2, FastEthernet1/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:06, Serial0/0

After 240 seconds the routes are fully flushed from the routing table.
R1#show ip route rip R 192.168.23.0/24 [120/2] via 192.168.131.3, 00:00:05, Serial0/0 R 192.168.33.0/24 [120/2] via 192.168.131.3, 00:00:05, Serial0/0

As you can see it takes a few minutes for RIP to correct a problem and possible another couple minutes for all the routers to agree there is an issue and remove the route if you have a larger RIP domain. Compared with Static routes where it will never detect the problem this is an improvement, however compared to other protocols that can detect changes in a matter of seconds it clearly can't compete. Below is a Pros & Cons summary of RIP. Pros Simplest Routing Protocol Most devices support RIP. Supports VLSM in Version 2. ...keep reading Three Router EIGRP Lab

Cons Slow problem detection 15 hop maximum and slow detection ensure it can deployments.

The purpose of this lab is to explore the functionality of the EIGRP routing protocol. ...keep reading Three Router OSPF Lab

The purpose of this lab is to explore the functionality of OSPF using a single area. This lab focuses many on the basics and concepts of OSPF to get you used to it. ...keep reading Default Routing Lab

The purpose of this lab is to explore a common default routing scenario ...keep reading Four Router Split Horizon RIP Lab

The purpose of this lab is to explore the Split-horizon rule for RIP. ...keep reading Four Router Split Horizon EIGRP Lab

The purpose of this lab explores the Split-horizon rule for EIGRP. Hardware Required for Lab

3 Cisco routers with serial ports. 1 Cisco router with at least 3 serial ports. 3 smart serial cables, or 6 DCE/DTE cables.

One Console Cable Commands Used in Lab no ip split-horizon eigrp <AS> - Disables Split-horizon on an interface.. Inital Configs
FRAME host FRAME frame-relay switching interface Serial0/1 encapsulation frame-relay clock rate 64000 frame-relay intf-type dce frame-relay route 102 interface Serial0/2 201 frame-relay route 103 interface Serial0/3 301 interface Serial0/2 encapsulation frame-relay clock rate 64000 frame-relay intf-type dce frame-relay route 201 interface Serial0/1 102 interface Serial0/3 encapsulation frame-relay clock rate 64000 frame-relay intf-type dce frame-relay route 301 interface Serial0/1 103 R1 line console 0 logging synch int s0/0 encapsulation frame-relay no frame inverse no shut int s0/0.123 multi ip add 123.123.123.1 255.255.255.0 frame map ip 123.123.123.2 102 broadcast frame map ip 123.123.123.3 103 broadcast host R1 R2 line console 0 logging synch int s0/0 encapsulation frame-relay no frame inverse no shut int s0/0.123 multi ip add 123.123.123.2 255.255.255.0 frame map ip 123.123.123.1 201 broadcast host R2 R3 line console 0

logging synch int s0/0 encapsulation frame-relay no frame inverse no shut int s0/0.123 multi ip add 123.123.123.3 255.255.255.0 frame map ip 123.123.123.1 301 broadcast no shut host R3

Distance routing protocols have a simple loop prevention rule called Split-horizon. The splithorizon rule says that a routing protocol will not send out an update on the same interface it received an update on. This is a particular problem on Frame-relay Hub and Spoke networks because the hub will receive an update from one spoke but due to split-horizon will not forward the update to the other spokes since its the same interface. First lets add a loopback interface on each router, we will use the 150.101.123.x/32 scheme where X is the router number.
R1(config)#int lo0 R1(config-if)#ip add 150.101.123.1 255.255.255.255 R2(config)#int lo0 R2(config-if)#ip add 150.101.123.2 255.255.255.255 R3(config)#int lo0 R3(config-if)#ip add 150.101.123.3 255.255.255.255

Next lets enable EIGRP AS 123 on the frame network and add the loopbacks.
R1(config)#router eigrp 123 R1(config-router)#no auto R1(config-router)#network 123.123.123.0 255.255.255.0 R1(config-router)# *Mar 1 00:46:48.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: adjacency *Mar 1 00:46:48.735: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: adjacency R1(config-router)#network 150.101.123.0 255.255.255.0 R2(config)#router eigrp 123 R2(config-router)#no auto R2(config-router)#network 123.123.123.0 255.255.255.0 R2(config-router)# *Mar 1 00:46:48.335: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: adjacency R2(config-router)#network 150.101.123.0 255.255.255.0 R3(config)#router eigrp 123 R3(config-router)#no auto R3(config-router)#network 123.123.123.0 255.255.255.0 R3(config-router)# *Mar 1 00:46:47.743: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: adjacency R3(config-router)#network 150.101.123.0 255.255.255.0

Neighbor 123.123.123.2 (Serial0/

Neighbor 123.123.123.3 (Serial0/

Neighbor 123.123.123.1 (Serial0/

Neighbor 123.123.123.1 (Serial0/

We can see that R1 has learned both R2 & R3 as expected.

R1(config)#do show ip route eigrp 150.101.0.0/32 is subnetted, 3 subnets D 150.101.123.2 [90/2297856] via 123.123.123.2, 00:01:28, Serial0/0.123 D 150.101.123.3 [90/2297856] via 123.123.123.3, 00:01:28, Serial0/0.123

R2 & R3 however only learned the R1 route due to the split-horizon rule
R2(config)#do show ip route eigrp 150.101.0.0/32 is subnetted, 2 subnets D 150.101.123.1 [90/2297856] via 123.123.123.1, 00:01:28, Serial0/0.123 R3(config)#do show ip route eigrp 150.101.0.0/32 is subnetted, 2 subnets D 150.101.123.1 [90/2297856] via 123.123.123.1, 00:01:28, Serial0/0.123

We can disable split-horizon by using the no ip split-horizon eigrp <AS> command under the interface.

R1(config)#int s0/0.123 R1(config-subif)#no ip split-horizon eigrp 123 R1(config-subif)# *Mar 1 00:50:57.875: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: Neighbor 123.123.123.3 (Serial0/ split horizon changed *Mar 1 00:50:57.875: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: Neighbor 123.123.123.2 (Serial0/ split horizon changed

Now if we check the routing table on R2 & R3 we can see we are learning all routes.
R2(config)#do show ip route eigrp 150.101.0.0/32 is subnetted, 3 subnets D 150.101.123.1 [90/2297856] via 123.123.123.1, D 150.101.123.3 [90/2809856] via 123.123.123.1, R3(config)#do show ip route eigrp 150.101.0.0/32 is subnetted, 3 subnets D 150.101.123.1 [90/2297856] via 123.123.123.1, D 150.101.123.2 [90/2809856] via 123.123.123.1, 00:04:29, Serial0/0.123 00:00:35, Serial0/0.123

00:04:38, Serial0/0.123 00:00:43, Serial0/0.123