CCNA6-11

Verifying Your Configurations 397
Let’s talk about the parts I highlighted. First, RIP is sending v1 packet to 255.255.255.255—
an “all-hands” broadcast—out interface serial0/0/1 via 10.1.5.2. 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. On our R3, we are using the
passive-interface so we are not sending broadcasts out to a LAN with no routers connected.
Okay—now check out the fact that it’s sending advertisements for all networks except
10.1.11.0 and 10.1.12.0 out FastEthernet0/1, yet the last advertisement out serial0/0/1 is only
advertising networks 10.1.10.0, 10.1.11.0, and 10.1.12.0. Why? If you answered split horizon
rules, you nailed it! Our R3 router will not advertise all those networks received from the Corp
router back to the Corp router.
If the metric of a route shows 16, this is a route poison, and the route 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 we’re 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, our 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
398 Chapter 6  IP Routing
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 we’re sending out two interfaces but only receiving RIP
updates on one 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 if you can find the problem. Both a debug
ip rip and a show ip route output are shown from our 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 checking out 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. The output also shows that 172.16.150.0 is directly connected to FastEthernet 0/0 and
network 172.16.20.0 is out serial 0/0.
Enabling RIPv2 on Our Internetwork
Before we move on to Chapter 7 and configure EIGRP and OSPF, I want to enable RIPv2 on
our routers. It’ll only take a second. Here are my configurations:
Corp#config t
Corp(config)#router rip
Verifying Your Configurations 399
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
For the R3 router, I just clicked the Version2 button and clicked OK. Done.
871W#config t
871W#(config)#router rip
871W#(config-router)#version 2
871W#(config-router)#^Z
400 Chapter 6  IP Routing
This was probably the easiest configuration we have done in the book so far. Let’s see if we
can find a difference in our routing tables. Here’s the R3 router’s routing table now:
10.0.0.0/24 is subnetted, 12 subnets
C 10.1.11.0 is directly connected, FastEthernet0/1
C 10.1.10.0 is directly connected, FastEthernet0/0
R 10.1.9.0 [120/2] via 10.1.5.1, 00:00:23, Serial0/0/1
R 10.1.8.0 [120/2] via 10.1.5.1, 00:00:23, Serial0/0/1
R 10.1.12.0 [120/1] via 10.1.11.2, 00:00:18, FastEthernet0/1
R 10.1.3.0 [120/1] via 10.1.5.1, 00:00:23, Serial0/0/1
R 10.1.2.0 [120/1] via 10.1.5.1, 00:00:23, Serial0/0/1
R 10.1.1.0 [120/1] via 10.1.5.1, 00:00:23, Serial0/0/1
R 10.1.7.0 [120/2] via 10.1.5.1, 00:00:23, Serial0/0/1
R 10.1.6.0 [120/2] via 10.1.5.1, 00:00:23, Serial0/0/1
C 10.1.5.0 is directly connected, Serial0/0/1
R 10.1.4.0 [120/1] via 10.1.5.1, 00:00:23, Serial0/0/1
R3#
Well—looks the same to me. I’m going to turn on debugging and see if that shows us anything
new:
*Mar 17 19:34:00.123: RIP: sending v2 update to 224.0.0.9 via
Serial0/0/1 (10.1.5.2)
*Mar 17 19:34:00.123: RIP: build update entries
*Mar 17 19:34:00.123: 10.1.10.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 17 19:34:00.123: 10.1.11.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 17 19:34:00.123: 10.1.12.0/24 via 0.0.0.0, metric 2, tag 0col
*Mar 17 19:34:03.795: RIP: received v2 update from 10.1.5.1 on
Serial0/0/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:
R3#sh 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 27 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2