Configuring RIP with SDM

RIP configuration using SDM are relatively similar and just as easy as configuring default and static routes. Select configuration, routing. Focus on the bottom of the screen for our dynamic routing protocols. When you click the edit button you can specify your routing protocol parameters. You can enable RIP by checking the checkbox and specifying which version you want to run.

Below that, you add the networks you want to advertise. Be sure that you specify each network that is directly attached to the router. This ensures that they are included in the routing updates and that the updates are sent and received on the interfaces associated with those networks. Finally, in the bottom of the window, you can check the checkboxes for the interfaces that you want to make into passive interfaces to save bandwidth or control which routers will have updates sent to them.

RIP verification

To verify RIP, you can use an assortment of show commands, each equally contributing to a wealth of information about the RIP routing protocol you configured. For instance, show running-config is an easy pick to show your configuration for RIP and the networks that you have configured. It is also a useful starting point if you are troubleshooting an existing implementation of RIP and you suspect missing or misconfigured network statements.

To ensure that RIP updates are being received from neighbors, show ip route proves the next work configuration is functioning because you will see RIP entries appear in the routing table:

Router A#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, *-candidate default, U-per-user static route, o-ODR, P-periodic downloaded static route, T-traffic engineered route

Gateway of last resort is not set

R             172.17.0.0/16 [120/2] via 192.168.1.6, serial0/0/0
C             172.16.0.0/16 is directly connected, FastEthernet0/0
R             172.18.0.0/16 [120/2] via 192.168.1.6, serial0/0/0
              192.168.1.0/30 is sub netted, 3 subnets
R             192.168.1.8 [120/1] via 192.168.1.6, serial0/0/0
R             192.168.1.12 [120/1] via 192.168.1.6, serial0/0/0
C             192.168.1.4 is directly connected, FastEthernet0/0         

The RIP entries are identified in the routing table with the letter R followed by the administrative distance and hop count in brackets. The IP 192.168.1.6 is the next-hop address to reach those networks out of Serial 0/0/0.

Finally, to see detailed information about all the IP routing protocols configured on a routing device, use show ip protocols to see a plethora of information.

RouterA#show ip protocols
Routing protocol is ‘rip’
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 2, receive version 2
Interface             send      recv       triggered RIP     key-chain
FastEthernet0/0          2         2
Serial0/0/0              2         2                        luckyrabbitsfoot
Automatic network summarization is in effect
Maximum path: 4
Routing for networks:
172.16.0.0
192.168.1.0
Routing information sources:
Gateway         distance                 last update
192.168.1.6          120                   00:00:11
Distance: (default is 120)

In this output, you can see the timers involved with the routing protocol, including the update interval of 30 seconds and the invalid and hold-down timers. The show ip protocols output also lists the interfaces participating in RIP and the version that they are configured to send and receive (in this case, version 2). On our serial 0/0/0 interface, you can also see that we have configured RIP authentication and that the key chain lucky rabbits foot is assigned to this interface. In addition, you can see which networks you are routing using RIP. This is useful for administrators who do not have access to privileged EXEC mode (and who therefore cannot use the show running-config command) to verify which networks are being advertised.

Troubleshooting RIP

Troubleshooting routing protocols always begins with verification of the routing configuration and status by using the show commands discussed in our RIPv1 and RIPv2 article.

You can also test whether you have IP connectivity by pinging or you can test the route packets will take by using the traceroute command. However, if you need to get into the trenches, so to speak, and verify the updates as they are being sent and received, you need to use real-time troubleshooting tools entailing the debug command.

To actively see real-time updates as they are being sent and received for RIP, use the privileged EXEC command debug ip rip, as demonstrated here:

RouterA#debug ip rip
RIP protocol debugging is on
RouterA#
*Oct 9 22:33:21.002: RIP: received packet with MD5 authentication
*Oct 9 22:33:21.002: RIP: received v2 update from 192.168.1.6 on Serial0/0/0
*Oct 9 22:33:21.002:        172.17.0.0/16 via 0.0.0.0 in 2 hops
*Oct 9 22:33:21.002:        172.18.0.0/16 via 0.0.0.0 in 2 hops
*Oct 9 22:33:21.006:        192.168.1.8/30 via 0.0.0.0 in 1 hop
*Oct 9 22:33:21.006:        192.168.1.12/30 via 0.0.0.0 in 1 hop

In this section of the debug output, the router receives an update from a neighbor with the IP address 192.168.1.6. this update is a version 2 update and has been authenticated using MD5. If any new subnets are learned from this update, they ultimately are placed in the routing table, using 192.168.1.6 as the next-hop address and serial0/0/0 as the existing interface, because that is where this information was learned. Notice in this section that subnet masks are received in the update, solidifying the fact that you are running a classless routing protocol, RIPv2.

The next bit of output that follows is the local router sending its v2 multicast (224.0.0.9) update out its Fast Ethernet 0/0 interface. Most important, notice how the router increments the hop count by 1 before sending it to any neighbors on its LAN.

*Oct 9 22:33:21.598: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (172.16.0.1)
*Oct 9 22:33:21.598: RIP: build update entries
*Oct 9 22:33:21.598:        172.17.0.0/16 via 0.0.0.0, metric 3, tag 0
*Oct 9 22:33:21.598:        172.17.0.0/16 via 0.0.0.0, metric 3, tag 0
*Oct 9 22:33:21.598:        192.168.1.8/30 via 0.0.0.0, metric 1, tag 0
*Oct 9 22:33:21.598: RIP: ignored v2 packet from 172.16.0.1 (sourced from one of our addresses)

Also, take note of the 192.168.1.0 entry that is being advertised out this Fast Ethernet 0/0 interface. Because the interface has an IP address of 172.16.0.1, which is not in the same major network, this router automatically summarized its subnetted entries to 192.168.1.0. therefore, we can surmise by this debug output we have not configured any auto-summary on Router A. if this were the case, the entry would remain classless and look more like this:

Oct 9 22:33:21.598:          192.168.1.8/30 via 0.0.0.0, metric 1, tag 0

The final output that follows is proof that the split horizon is enabled and working on this router. This is evident because the router does not send any entries that it received on serial 0/0/0 from the first output explanation. Recall that split horizon keeps a router from advertising networks back out the interface from which it received that information. Because the 192.168.1.8, 192.168.1.12, 172.17.0.0 and 172.18.0.0 networks were received in the router’s serial0/0/0 interface, they cannot be sent back out that interface.

*Oct 9 22:33:23:822: RIP: sending v2 update to 224.0.09 via Serial0/0/0 (192.168.1.5)
*Oct 9 22:33:23:822: RIP: build update entries
*Oct 9 22:33:23:822:        172.16.0.0/16 via 0.0.0.0, metric 1, tag 0