- Configure, verify, and troubleshoot RIPv2
The configuration for RIPv2 is practically identical to RIPv1. In other words, you still must enter the RIP routing process with the router rip command and still must advertise the directly connected classful networks. To enable RIPv2, you have to enter the command version 2 in the routing process:
RouterA(config)#router rip RouterA(config-router)#version 2 RouterA(config-router)#network 172.16.0.0 RouterA(config-router)#network 192.168.1.0
By default, RIPv2 is classful. To configure this enhanced routing protocol to support classless routing updates, the only entry you need to configure is the no auto-summary command in the routing process:
RouterA(config)#router rip RouterA(config-router)#no auto-summary
After you configure this command, the RIP version 2 updates being multicast to 220.127.116.11 are no longer be considered classful, because the subnet mask is advertised in the updates along with the network.
By default, RIP is configured to send version 1 and accept version 1 and 2 received updates. This means that routers that have not been changed to version 2 will still accept version 2 updates but will process them as version 1 (ignoring any subnet mask or authentication). Be sure to keep this in mind if you decide to revert your RIP configuration to version 1 by using the version 1 command. This command instructs the router to receive only version 1 updates, which causes version 2 updates to be treated as an illegal version and be ignored. To revert to the default RIP configuration, a better command to use is default version in the RIP routing process.
If a router is explicitly configured to run as version 1, RIP version 2 updates are considered an illegal version and are ignored.
RIPv2 Update Authentication
As previously mentioned, RIPv2 provides update authentication to help protect from rogue devices or attackers injecting false routing information into your routing table by authenticating the routing updates. This authentication is achieved by defining a key and attaching a key string (password) to it. This key string must match on both routers, or the updates will be rejected. To define the authentication key, use the key chain command followed by a name for the key chain in global configuration mode. After you enter that command, you are put into configkeychain subconfiguration mode:
RouterA(config)#key chain luckyrabbitsfoot RouterA(config-keychain)#
Here you can configure several keys if you want, with different key string passwords. To create a key, use the key keyword and a number identifier for that key. You are put into another subconfiguration mode for that specific key, as shown by the config-keychain-key prompt:
RouterA(config-keychain)#key 1 RouterA(config-keychain-key)#
Now we finally get to define our password, using the key-string command followed by the password that will match on each side:
With our key chain defined, we have to apply it to interfaces that connect to neighboring RIPv2 routers with matching authentication configurations. The command to assign the key chain to the interface is ip rip authentication key-chain followed by the key chain you defined a moment ago:
RouterA(config-keychain-key)#exit RouterA(config-keychain)#exit RouterA(config)#interface serial 0/0/0 RouterA(config-if)#ip rip authentication key-chain luckyrabbitsfoot
This key chain is sent over the link in clear text by default. This defeats the point of securing links, because the key chain can be seen if the link is being eavesdropped. To secure the key using an MD5 hash of the password, use the following command:
RouterA(config-if)#ip rip authentication mode md5
Configuring RIP with SDM
RIP configurations 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 see the pop-up window shown in
Figure 11.11, in which 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 check boxes for the interfaces that you want to make into passive interfaces to save bandwidth or control which routers will have updates sent to them.
- Verify router hardware and software operation using SHOW & DEBUG commands
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 network configuration is functioning, because you will see RIP entries appear in the routing table:
RouterA#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 subnetted, 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, Serial0/0/0
The RIP entries are identified in the routing table with the letter R followed by the administrative distance and the 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 luckyrabbitsfoot 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.
- Troubleshoot routing issues
Troubleshooting routing protocols always begins with verification of the routing configuration and status by using the show commands discussed in the last section. 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.
If you forget which debug processes you have running, you can issue the show debug command to list all the processes you are currently debugging. 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# *Aug 6 22:33:21.002: RIP: received packet with MD5 authentication *Aug 6 22:33:21.002: RIP: received v2 update from 192.168.1.6 on Serial0/0/0 *Aug 6 22:33:21.002: 172.17.0.0/16 via 0.0.0.0 in 2 hops *Aug 6 22:33:21.002: 172.18.0.0/16 via 0.0.0.0 in 2 hops *Aug 6 22:33:21.006: 192.168.1.8/30 via 0.0.0.0 in 1 hops *Aug 6 22:33:21.006: 192.168.1.12/30 via 0.0.0.0 in 1 hops
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 Serial 0/0/0 as the exiting 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 (18.104.22.168) 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:
*Aug 6 22:33:23.598: RIP: sending v2 update to 22.214.171.124 via FastEthernet0/0 (172.16.0.1) *Aug 6 22:33:23.598: RIP: build update entries *Aug 6 22:33:23.598: 172.17.0.0/16 via 0.0.0.0, metric 3, tag 0 *Aug 6 22:33:23.598: 172.18.0.0/16 via 0.0.0.0, metric 3, tag 0 *Aug 6 22:33:23.598: 192.168.1.0/24 via 0.0.0.0, metric 1, tag 0 *Aug 6 22:33:23.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 that we have not configured the no auto-summary on
Router A. If this were the case, the entry would remain classless and look more like this:
*Aug 6 22:33:23.598: 192.168.1.4/30 via 0.0.0.0, metric 1, tag 0
The final output that follows is proof that 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 Serial 0/0/0 interface, they cannot be sent back out that interface.
*Aug 6 22:33:23.822: RIP: sending v2 update to 126.96.36.199 via Serial0/0/0 (192.168.1.5) *Aug 6 22:33:23.822: RIP: build update entries *Aug 6 22:33:23.822: 172.16.0.0/16 via 0.0.0.0, metric 1, tag 0
Be sure you can decipher the output of a debug ip rip command.
Given the following design in Figure 11.12, configure RIP on Router A to be able to communicate with the remainder of the preconfigured network.
- Remember to remove any existing static routes. Why?
- Enter the configuration process for RIP.
- dvertise Router A’s networks.
What will Router B do with the update from Router A?
What will the networks look like when Router B sends them on to Router C?
- Configure Router A to run RIP version 2.
- Configure Router A to be classless.
What will the update from Router A look like now?
- Configure RIP authentication using an MD5 hash of the password on Routers A and B.
You must first remove any static routes because they have a lower administrative distance than RIP. The configuration in steps 2 and 3 would look like the following:
RouterA(config)#router rip RouterA(config-router)#network 172.16.0.0 RouterA(config-router)#network 10.0.0.0
Despite having subnetted the major networks in our topology, you must advertise the directly connected classful networks. When Router B receives that update, it adds the 172.16.0.0 entry into its routing table (because 10.1.1.60 is already directly connected) with a metric of 1 and uses Router A’s serial interface as the next hop. The entry is not 172.16.100.0 because Router A auto-summarizes that network when exiting its WAN interface because that is on a different major network. When Router B sends that entry to Router C, it is sent as 172.16.0.0 with a metric (hop count of 2). To configure Router A for RIPv2 and make it classless, you must add the following configurations:
RouterA(config)#router rip RouterA(config-router)#version 2 RouterA(config-router)#no auto-summary
With this configuration, Router A does not automatically summarize the 172.16.100.0 network and it sends the subnet mask along to Router B. If B is running RIPv2 also, it keeps the network in its subnetted form of 172.16.100.0/24. To assign RIP update authentication, we have to create matching keys on each router and apply them to the serial interfaces of each router:
RouterA(config)#key chain RtrAKey RouterA(config-keychain)#key 1 RouterA(config-keychain-key)#key-string perfectmatch RouterA(config-keychain-key)#exit RouterA(config-keychain)#exit RouterA(config)#interface serial 0/0/0 RouterA(config-if)#ip rip authentication key-chain RtrAKey RouterA(config-if)#ip rip authentication mode md5 RouterB(config)#key chain RtrBKey RouterB(config-keychain)#key 1 RouterB(config-keychain-key)#key-string perfectmatch RouterB(config-keychain-key)#exit RouterB(config-keychain)#exit RouterB(config)#interface serial 0/0/0 RouterB(config-if)#ip rip authentication key-chain RtrBKey RouterB(config-if)#ip rip authentication mode md5
Notice that the names of the key chains do not have to match, but the actual key strings inside the key chains do.