R2#debug ip rip
RIP protocol debugging is on
*Mar 1 00:03:21.227: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (172.16.0.2)
*Mar 1 00:03:21.231: RIP: build update entries - suppressing null update
R1#show ip route
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, FastEthernet0/0
Nothing...R2 has the connected routes but is not even advertising it over to R1. This is because RIPv1 is classfull, and even if R1 got the route, it would put a /24 mask to it even though it is a /30, because rip interprets any update without a mask like it has the same mask as one of its connected interfaces within that major network number. As soon as I put "version 2" under the RIP process I got some joy:
R1(config-router)#do show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.16.1.4/30 [120/1] via 172.16.0.2, 00:00:11, FastEthernet0/0
C 172.16.0.0/24 is directly connected, FastEthernet0/0
R 172.16.1.0/30 [120/1] via 172.16.0.2, 00:00:11, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R 10.10.10.0/24 [120/2] via 172.16.0.2, 00:01:06, FastEthernet0/0
R 10.0.0.0/8 [120/1] via 172.16.0.2, 00:00:11, FastEthernet0/0
I also want you to note that 10.10.10.0/24 network. Originally when I enabled Version 2, I also put on the no auto-summary command. R3 has a loopback of 10.10.10.1/24 and is advertising it into RIP. To show what auto-summary does, I went ahead and disabled it right before I ran the preceding show ip route. Notice the timer on the /24...its getting awfully close to that 180 invalid timer. I went ahead and ran a clear ip route * again, and look at the output now...
R1(config-router)#do show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.16.1.4/30 [120/1] via 172.16.0.2, 00:00:02, FastEthernet0/0
C 172.16.0.0/24 is directly connected, FastEthernet0/0
R 172.16.1.0/30 [120/1] via 172.16.0.2, 00:00:02, FastEthernet0/0
R 10.0.0.0/8 [120/1] via 172.16.0.2, 00:00:02, FastEthernet0/0
Now because R2 is the one with auto-summary on it is summarizing that major network...10.0.0.0/8 and sending it down the pipe to R1. Heres the debug output:
*Mar 1 00:14:25.451: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (172.16.0.2)
*Mar 1 00:14:25.455: RIP: build update entries
*Mar 1 00:14:25.455: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:14:25.459: 172.16.1.0/30 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:14:25.459: 172.16.1.4/30 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:14:35.003: RIP: received v2 update from 172.16.1.2 on FastEthernet1/0
*Mar 1 00:14:35.007: 10.10.10.0/24 via 0.0.0.0 in 1 hops
Now the highlighted portions are important b/c R2 is receiving an update of the /24 version of that network, but is sending just the /8 (the actual class A boundary) to R1. This is the default behavior or RIP:v2, and is reflected in the routing table of R1.
Now you might be wondering...well Jason, why then is the 172.16.1.x/30 routes still showing up in there if auto-summary is enabled...and to be honest I was wondering the same thing. Here's direct quote from the Cisco god himself, Scott Morris:
"Auto-summarization only works when routes are from a differerent classful network than the interface it's received on. So if everything in your network is 10.0.0.0/8 addresses, you won't see much difference (exception = redistribution). But when you see a route come in that's 172.16.1.0, even though you have a /24 mask on the interface, auto-summarization will change that to a /16 in your routing table."
Thanks Scott, that clears it up!
References:
https://learningnetwork.cisco.com/thread/6541
