Verifying Your Configurations
It's important to verify your configurations once you've completed them, or at least once you think you've completed them. The following list includes the commands you can use to verify the routed and routing protocols configured on your Cisco routers:
- show ip route
- show ip protocols
- debug ip rip
The first command was covered in the previous section—I'll go over the others in the sections that follow.
The show ip protocols Command
The show ip protocols command shows you the routing protocols that are configured on your router. Looking at the following output, you can see that RIP is running on the router and the timers that RIP uses:
Corp#sh ip protocols Routing Protocol is “rip” Sending updates every 30 seconds, next due in 23 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 1, receive any version Interface Send Recv Triggered RIP Key-chain Vlan1 1 2 1 FastEthernet0/0 1 2 1 Serial0/0/0 1 2 1 Serial0/0/1 1 2 1 Serial0/1/0 1 2 1 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 10.0.0.0 Passive Interface(s): Routing Information Sources: Gateway Distance Last Update 10.1.5.2 120 00:00:28 10.1.2.2 120 00:00:21 10.1.3.2 120 00:00:21 10.1.4.2 120 00:00:12 Distance: (default is 120)
Notice in this output that RIP is sending updates every 30 seconds, which is the default. The other timers used in distance vector are also shown.
Notice further down that RIP is routing for the directly connected interfaces f0/0, S0/0/0, s0/0/1, and s0/1/0. The send and receive versions are listed to the right of the interfaces—RIPv1 and v2. This is an important troubleshooting section. If the interface you need is not listed in this section, you did not type in the correct network statements, and this information can be found under the heading Routing for Networks.
Under the Gateway heading, the neighbors it found and the last entry is the default AD for RIP (120).
Troubleshooting with the show ip protocols Command
Let's use a sample router and use the show ip protocols command to see what you can determine about routing by looking at this output from a router on another network:
Router#sh ip protocols Routing Protocol is “rip” Sending updates every 30 seconds, next due in 6 seconds Invalid after 180 seconds, hold down 180, flushed afteR340 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Key-chain Serial0/0 1 1 2 Serial0/1 1 1 2 Routing for Networks: 10.0.0.0 Routing Information Sources: Gateway Distance Last Update 10.168.11.14 120 00:00:21 Distance: (default is 120)
Let's also look at the show ip interface brief command from the same router and see what you find out.
Router#sh ip interface brief
Interface IP-Address OK? Method Status
FastEthernet0/0 192.168.18.1 YES manual up
Serial0/0 10.168.11.17 YES manual up
FastEthernet0/1 unassigned YES NRAM Administratively down
Serial0/1 192.168.11.21 YES manual up
Under the show ip protocols output, you can see that I'm using RIP routing for network 10.0.0.0, which means the configuration would look like this:
Router(config)#router rip Router(config-router)#network 10.0.0.0
Also, only serial 0/0 and serial 0/1 are participating in the RIP network. And last, the neighbor router is 10.168.11.14.
From the output of the show ip interface brief command, you can see that only serial 0/0 is in the 10.0.0.0 network. This means that the router will send and receive routing updates only with the 10.0.0.0 network and not advertise the 192.168.0.0 networks out any interface. To fix this, you would need to add the 192.168.11.0 and 192.168.18.0 networks under the router rip global command.
The debug ip rip Command
The debug ip rip command directs routing updates as they are sent and received on the router to the console session. If you are telnetted into the router, you'll need to use the terminal monitor command to be able to receive the output from the debug commands.
You can see in this output that RIP is both sending and receiving (the metric is the hop count):
R3#debug ip rip RIP protocol debugging is on RIP: received v1 update from 10.1.5.1 on FastEthernet0/0 10.1.1.0 in 1 hops 10.1.2.0 in 1 hops 10.1.3.0 in 1 hops 10.1.4.0 in 1 hops 192.168.10.0 in 2 hops 192.168.20.0 in 2 hops 192.168.30.0 in 2 hops 192.168.40.0 in 2 hops RIP: sending v1 update to 255.255.255.255 via Dot11Radio0/0/0(172.16.10.1) RIP: build update entries network 10.0.0.0 metric 1 network 192.168.10.0 metric 3 network 192.168.20.0 metric 3 network 192.168.30.0 metric 3 network 192.168.40.0 metric 3 RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (10.1.5.2) RIP: build update entries network 172.16.0.0 metric 1)
Let's talk about the output for a minute. First, R3 received all the routes that the Corp router has, and RIP is sending v1 packets to 255.255.255.255—an “all-hands” broadcast—out interface Dot11Radio0/0/0/0 via 172.16.10.1. This is where RIPv2 will come in handy. Why? Because RIPv2 doesn't send broadcasts; it used the multicast 224.0.0.9. So, even though the RIP packets could be transmitted onto a network with no routers, all hosts would just ignore them, making RIPv2 a bit of an improvement over RIPv1.
Okay—now check out the fact that RIP is sending advertisements for all networks out Dot11Radio0/0/0/0, yet the last advertisement out FastEthernet 0/0 on R3 is only advertising 172.16.0.0. Why? If you answered the split horizon rule, you nailed it! The R3 router in this example will not advertise all those networks received from a neighbor router back to the same router.
If the metric of a route shows 16, this is a route poison, and the network being advertised is unreachable.
Troubleshooting with the debug ip rip Command
Now let's use the debug ip rip command to both discover a problem and figure out how RIP was configured on a router from a different sample network.
07:12:58: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (172.16.1.1) 07:12:58: network 10.0.0.0, metric 1 07:12:58: network 192.168.1.0, metric 2 07:12:58: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (10.0.8.1) 07:12:58: network 172.16.0.0, metric 1 07:12:58: RIP: Received v1 update from 10.0.15.2 n Serial0/0 07:12:58: 192.168.1.0 in one hop 07:12:58: 192.168.168.0 in 16 hops (inaccessible)
You can see from the updates that I'm sending out information about networks 10.0.0.0, 192.168.1.0, and 172.16.0.0. But both the 10.0.0.0 network and the 172.16.0.0 network are being advertised with a hop count (metric) of 1, meaning that these networks are directly connected. The 192.168.1.0 is being advertised as a metric of 2, which means that it is not directly connected.
For this to be happening, the configuration would have to look like this:
Router(config)#router rip Router(config-router)#network 10.0.0.0 Router(config-router)#network 172.16.0.0
And there's something else you can find out by looking at this: there are at least two routers participating in the RIP network because I'm sending out two interfaces and receiving RIP updates on one interface (if I'm receiving updates, there must be another router on that interface). Also, notice that the network 192.168.168.0 is being advertised as 16 hops away. RIP has a maximum hop count of 15, so 16 is considered unreachable, making this network inaccessible. So, what will happen if you try to ping to a host on network 192.168.168.0? You just will not be successful, that's what! But if you try any pings to network 10.0.0.0, you should be successful.
I have one more output I want to show you—see whether you can find the problem. Both a debug ip rip and a show ip route output are shown from the sample router.
07:12:56: RIP: received v1 update from 172.16.100.2 on Serial0/0
07:12:56: 172.16.10.0 in 1 hops
07:12:56: 172.16.20.0 in 1 hops
07:12:56: 172.16.30.0 in 1 hops
Router#sh ip route
[output cut]
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 8 subnets
C 172.16.150.0 is directly connected, FastEthernet0/0
C 172.16.220.0 is directly connected, Loopback2
R 172.16.210.0 is directly connected, Loopback1
R 172.16.200.0 is directly connected, Loopback0
R 172.16.30.0 [120/2] via 172.16.100.2, 00:00:04, Serial0/0
S 172.16.20.0 [120/2] via 172.16.150.15
R 172.16.10.0 [120/2] via 172.16.100.2, 00:00:04, Serial0/0
R 172.16.100.0 [120/2] is directly connected, Serial0/0
Looking at the two outputs, can you tell why users can't access 172.16.20.0?
The debug output shows that network 172.16.20.0 is one hop away and being received on serial0/0 from 172.16.100.2. By viewing the show ip route output, you can see that packets with a destination of 172.16.20.0 are being sent to 172.16.150.15 because of a static route entry. The output also shows that 172.16.150.0 is directly connected to FastEthernet 0/0 and network 172.16.20.0 is really out serial 0/0, so packets with a destination of 172.16.20.0 are being sent out the wrong interface because of a misconfigured static route.
Enabling RIPv2 on the Internetwork
Before moving on to Chapter 7 and discussing Layer 2 switching, I want to enable RIPv2 on the routers. It'll take only a second. Here are my configurations:
Corp#config t Corp(config)#router rip Corp(config-router)#version 2 Corp(config-router)#^Z R1#config t R1(config)#router rip R1(config-router)#version 2 R1(config-router)#^Z R2#config t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router rip R2(config-router)#version 2 R2(config-router)#^Z R3#config t R3#(config)#router rip R3#(config-router)#version 2 R3#(config-router)#^Z
This was probably the easiest configuration in the book so far. Let's see whether you can find a difference in the routing tables. Here's the Corp router's routing table now:
10.0.0.0/24 is subnetted, 5 subnets C 10.1.1.0 is directly connected, Vlan1 C 10.1.2.0 is directly connected, Serial0/0/0 C 10.1.3.0 is directly connected, Serial0/0/1 C 10.1.4.0 is directly connected, Serial0/1/0 C 10.1.5.0 is directly connected, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.16.0.0/16 [120/1] via 10.1.5.2, 00:00:18, FastEthernet0/0 S 172.16.10.0/24 [150/0] via 10.1.5.2 R 192.168.10.0/24 [120/1] via 10.1.2.2, 00:00:04, Serial0/0/0 [120/1] via 10.1.3.2, 00:00:04, Serial0/0/1 R 192.168.20.0/24 [120/1] via 10.1.2.2, 00:00:04, Serial0/0/0 [120/1] via 10.1.3.2, 00:00:04, Serial0/0/1 R 192.168.30.0/24 [120/1] via 10.1.4.2, 00:00:06, Serial0/1/0 R 192.168.40.0/24 [120/1] via 10.1.4.2, 00:00:06, Serial0/1/0 Corp#
Well—looks the same to me, and it still didn't fix my double entry for the 172.16.0.0 network. I'm going to turn on debugging and see whether that shows anything new.
Corp#debug ip rip RIP protocol debugging is on Corp#RIP: sending v2 update to 224.0.0.9 via Vlan1 (10.1.1.1) RIP: build update entries 10.1.2.0/24 via 0.0.0.0, metric 1, tag 0 10.1.3.0/24 via 0.0.0.0, metric 1, tag 0 10.1.4.0/24 via 0.0.0.0, metric 1, tag 0 10.1.5.0/24 via 0.0.0.0, metric 1, tag 0 172.16.0.0/16 via 0.0.0.0, metric 2, tag 0 192.168.10.0/24 via 0.0.0.0, metric 2, tag 0 192.168.20.0/24 via 0.0.0.0, metric 2, tag 0 192.168.30.0/24 via 0.0.0.0, metric 2, tag 0 192.168.40.0/24 via 0.0.0.0, metric 2, tag 0 RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.1.5.1) [output cut]
Bingo! Look at that! The networks are still being advertised every 30 seconds, but they're now sending the advertisements as v2 and as a multicast address of 224.0.0.9. Let's take a look at the show ip protocols output.
Corp#sh ip protocols Routing Protocol is “rip” Sending updates every 30 seconds, next due in 20 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 2 Interface Send Recv Triggered RIP Key-chain Vlan1 2 2 FastEthernet0/0 2 2 Serial0/0/0 2 2 Serial0/0/1 2 2 Serial0/1/0 2 2 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 10.0.0.0 Passive Interface(s): Routing Information Sources: Gateway Distance Last Update 10.1.5.2 120 00:00:09 10.1.2.2 120 00:00:20 10.1.3.2 120 00:00:20 10.1.4.2 120 00:00:23 Distance: (default is 120)
I am now sending and receiving RIPv2. Nice when things work out well, huh? However, I never did fix that double entry for the 172.16.0.0 network in the Corp and R2 routing tables, even though I could have done so using RIPv2. I want to save that solution for EIGRP. But the answer for the problem was previously shown in Table 6.3, and the solution was discussed following Figure 6.13 if you just can't wait!
Advertising a Default Route Using RIP
I want to show you how to advertise a way out of your autonomous system. Imagine that you were to look at the network diagram and that instead of having the wireless network connected to R3, you could use a serial interface and configure the little internetwork to the Internet from R3.
If you do add an Internet connection to R3, all routers in the AS need to know where to send packets that are destined for networks on the Internet, or they'll just drop the packets if they get a packet with a remote request. One solution would be to put a default route on every router and funnel the information to R3, which in turn would have a default route to the ISP. Most people do this type of configuration in small to medium-sized networks.
However, since I am running RIPv2 on all routers including R3, I'll just add a default route on R3 to the ISP, as I would normally, but then add another command to advertise my network to the other routers in the AS as the default route.
Here is an example of my new R3 configuration:
R3(config)#interface s0/0 R3(config-if)#ip address 172.16.10.5 255.255.255.252 R3(config-if)#exit R3(config)#ip route 0.0.0.0 0.0.0.0 s0/0 R3(config)#ip default-network 172.16.0.0
Now, let's see what the Corp and R2 routers' routing tables see.
Corp#
10.0.0.0/24 is subnetted, 5 subnets
C 10.1.1.0 is directly connected, Vlan1
C 10.1.2.0 is directly connected, Serial0/0/0
C 10.1.3.0 is directly connected, Serial0/0/1
C 10.1.4.0 is directly connected, Serial0/1/0
C 10.1.5.0 is directly connected, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
R 172.16.0.0/16 [120/1] via 10.1.5.2, 00:00:16, FastEthernet0/0
S 172.16.10.0/24 [150/0] via 10.1.5.2
R 192.168.10.0/24 [120/1] via 10.1.2.2, 00:00:16, Serial0/0/0
[120/1] via 10.1.3.2, 00:00:16, Serial0/0/1
R 192.168.20.0/24 [120/1] via 10.1.2.2, 00:00:16, Serial0/0/0
[120/1] via 10.1.3.2, 00:00:16, Serial0/0/1
R 192.168.30.0/24 [120/1] via 10.1.4.2, 00:00:02, Serial0/1/0
R 192.168.40.0/24 [120/1] via 10.1.4.2, 00:00:02, Serial0/1/0
R* 0.0.0.0/0 [120/1] via 10.1.5.2, 00:00:16, FastEthernet0/0
Corp#
Nice—look at the last entry: R3 is advertising to the Corp router that “Hey, I am the way to the Internet!” or “I am the way out of the AS!” Let's see whether R2 can see this same entry.
R2# 10.0.0.0/24 is subnetted, 5 subnets R 10.1.1.0 [120/1] via 10.1.4.1, 00:00:29, Serial0/0/0 R 10.1.2.0 [120/1] via 10.1.4.1, 00:00:29, Serial0/0/0 R 10.1.3.0 [120/1] via 10.1.4.1, 00:00:29, Serial0/0/0 C 10.1.4.0 is directly connected, Serial0/0/0 R 10.1.5.0 [120/1] via 10.1.4.1, 00:00:29, Serial0/0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.16.0.0/16 [120/2] via 10.1.4.1, 00:00:29, Serial0/0/0 S 172.16.10.0/24 [150/0] via 10.1.4.1 R 192.168.10.0/24 [120/2] via 10.1.4.1, 00:00:29, Serial0/0/0 R 192.168.20.0/24 [120/2] via 10.1.4.1, 00:00:29, Serial0/0/0 C 192.168.30.0/24 is directly connected, FastEthernet0/0 C 192.168.40.0/24 is directly connected, FastEthernet0/1 R* 0.0.0.0/0 [120/2] via 10.1.4.1, 00:00:29, Serial0/0/0 R2#
R2 is seeing it as well, so the ip default-network command is working and advertising with RIP, and in addition, I verified that R1 is receiving the default route as well. This command would work with either RIP or RIPv2.
You're ready now to move on to the next chapter!