As I march onwards to the CCIE written the need is apparent that you must understand every trick and caveat of a routing protocol. I have been reading up and working on RIP this weekend and amongst the funny situations that have cropped up initially this one had me stumped.
The little topology focuses on R1 and R2. I have applied the following configurations.
R1 interface Loopback0 ip address 10.0.0.1 255.255.255.0 ! interface Loopback2 ip address 10.0.1.1 255.255.255.0 ! interface FastEthernet0/0 ip address 184.108.40.206 255.255.255.0 duplex auto speed auto router rip version 2 network 10.0.0.0 network 220.127.116.11 R2 interface FastEthernet0/0 ip address 18.104.22.168 255.255.255.0 duplex auto speed auto router rip version 2 network 22.214.171.124
Your output from R2’s routing table should look like this.
R2#sh ip route rip R 10.0.0.0/8 [120/1] via 126.96.36.199, 00:00:15, FastEthernet0/0
Due to the nature of auto-summary and it being on by default, as R1 advertising a RIP update to R2 it performs summarisation to the class-full boundary. This means our networks we configured, 10.0.0.0 and 10.0.1.0, albeit they have a /24 mask, they are being represented by the 10.0.0/8 route. To confim we shall check the debugs.
R1(config-router)# *Mar 1 00:55:54.007: RIP: sending v2 update to 188.8.131.52 via FastEthernet0/0 (184.108.40.206) *Mar 1 00:55:54.007: RIP: build update entries *Mar 1 00:55:54.007: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0 *Mar 1 00:55:58.707: RIP: sending v2 update to 220.127.116.11 via Loopback2 (10.0.1.1) *Mar 1 00:55:58.707: RIP: build update entries *Mar 1 00:55:58.707: 18.104.22.168/8 via 0.0.0.0, metric 1, tag 0
Note here the update entries sending 22.214.171.124/8 and 10.0.0.0/8. We can deduce that auto-summary is occurring. Checking R2’s debug we can see that 10.0.0.0/8 is being received as advertised.
R2(config-router)# *Mar 1 00:56:51.627: RIP: received v2 update from 126.96.36.199 on FastEthernet0/0 *Mar 1 00:56:51.631: 10.0.0.0/8 via 0.0.0.0 in 1 hops
We can also confirm what exactly is being seen with show ip rip database command.
R1#sh ip rip data 10.0.0.0/8 auto-summary 10.0.0.0/24 directly connected, Loopback0 10.0.1.0/24 directly connected, Loopback2 188.8.131.52/8 auto-summary 184.108.40.206/24 directly connected, FastEthernet0/0 R2#sh ip rip data 10.0.0.0/8 auto-summary 10.0.0.0/8  via 220.127.116.11, 00:00:18, FastEthernet0/0 18.104.22.168/8 auto-summary 22.214.171.124/24 directly connected, FastEthernet0/0
Note we see auto-summary entries next to 10.0.0.0/8 and 126.96.36.199/8 even though we did initially specify them with the individual network commands. There are /24’s in this table but remember this is due to being directly connected. They do not appear on their peer of R2.
What is a major network? A major network heralds back to the days of classes. The original use of RIPv1 was that it was designed to summarize at the enterprise edge to represent an entire business or network. A major network follows the original Class A, B, C network structure. Looking at the 4 most significant bits of the network portion you can see this in better detail.
Class A = 0000 Default mask = 255.0.0.0 Class B = 1000 Default mask = 255.255.0.0 Class C = 1100 Default mask = 255.255.255.0
What does that mean to you? Well a Class A range is 0.0.0.0 to 188.8.131.52. Combined with a default class-full mask of 255.0.0.0 this means that if there is a change in the first octet, you are crossing a major boundary. If anything is changed in the second, third, or fourth octet, you are residing in the major network of the first octet. This is still represented by a /8.
This scales the same way for Class B and Class C. A class B address residing between 184.108.40.206 and 220.127.116.11 with a subnet mask of 255.255.255.0 would change in the first two octets would indicate a major network crossing. A Class C address, residing between 192.0.0.0 to 18.104.22.168 would make any change to the the first three octets a change to the major network boundary.
If a different major network is running between the two devices then it is advertised back to the class full boundary. In the example of demonstrated above you can see that 22.214.171.124 connects between the two devices. The major networks are 10 and 50. When R1 sends the advertisements out they are summarized to the class full boundary.
How does one keep auto-summary one whilst advertising routes per our network statements? If the interconnect between R1 and R2 was in the same major network then it is treated differently. Lets apply 10.0.2.0 to the interconnect, replacing 126.96.36.199. Advertise them with RIP too.
R1 interface FastEthernet0/0 ip address 10.0.2.1 255.255.255.0 duplex auto speed auto router rip version 2 network 10.0.0.0 network 10.0.1.0 network 10.0.2.0 R2 interface FastEthernet0/0 ip address 10.0.2.2 255.255.255.0 duplex auto speed auto router rip version 2 network 10.0.2.0
Now check the ip routing table. Look at the different from before. Where we had the entire 10.0.0.0 network summarised by a /8.
R2#sh ip route | beg Gateway Gateway of last resort is not set 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/0 R 10.0.0.0 [120/1] via 10.0.2.1, 00:00:14, FastEthernet0/0 R 10.0.1.0 [120/1] via 10.0.2.1, 00:00:14, FastEthernet0/0
Here you can see that now we have changed the major network on the interconnect to reside in the overall class-full network range we have a much different result. Our RIP routes on R2 show two networks, 10.0.0.0 and 10.0.1.0. Lets see how the updates are different this time.
R1# *Mar 1 00:52:50.619: RIP: sending v2 update to 188.8.131.52 via FastEthernet0/0 (10.0.2.1) *Mar 1 00:52:50.619: RIP: build update entries *Mar 1 00:52:50.623: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0 *Mar 1 00:52:50.623: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0 R2# *Mar 1 00:53:58.383: RIP: received v2 update from 10.0.2.1 on FastEthernet0/0 *Mar 1 00:53:58.387: 10.0.0.0/24 via 0.0.0.0 in 1 hops *Mar 1 00:53:58.387: 10.0.1.0/24 via 0.0.0.0 in 1 hops
Look at that, we can see two new networks in the updates being sent and received based upon these outputs.
So now we can see that if an interconnect between peers does not reside on the same major boundary then summarisation to the class-full edge will occur. What happens where we turn auto summary off and repeat what we did before? First with the 184.108.40.206 network then the 10.0.2.0 network.
With the 220.127.116.11 network as the interconnect I disabled auto-summary on both devices.
R1(config)#router rip R1(config-router)#no auto R2(config)#router rip R2(config-router)#no auto
Time to check our outputs and debugs. First the output of the routing table
R2#sh ip route rip 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks R 10.0.0.0/24 [120/1] via 18.104.22.168, 00:00:20, FastEthernet0/0 R 10.0.0.0/8 [120/1] via 22.214.171.124, 00:01:16, FastEthernet0/0 R 10.0.1.0/24 [120/1] via 126.96.36.199, 00:00:20, FastEthernet0/0
Ah yes. With auto-summary off note that the correct networks are advertised including their subnet mask. No automatic summary replaces all the networks so we will get the 10.0.0.0/8 (due to crossing the major network boundary) plus the two more specific entries denoted by the /24 networks.
R2#show ip rip data 10.0.0.0/8 auto-summary 10.0.0.0/8  via 188.8.131.52, 00:01:36, FastEthernet0/0 10.0.0.0/24  via 184.108.40.206, 00:00:10, FastEthernet0/0 10.0.1.0/24  via 220.127.116.11, 00:00:10, FastEthernet0/0 18.104.22.168/8 auto-summary 22.214.171.124/24 directly connected, FastEthernet0/0
Showing our RIP data we get the expected output. Now lets change back our interconnect to 10.0.2.0 network and see the difference now that we have auto-summary disabled.
R2#sh ip rip data 10.0.0.0/8 auto-summary 10.0.0.0/24  via 10.0.2.1, 00:00:03, FastEthernet0/0 10.0.1.0/24  via 10.0.2.1, 00:00:03, FastEthernet0/0 10.0.2.0/24 directly connected, FastEthernet0/0
Good. Look at that. We can see the two /24’s being advertised from 10.0.2.1 (R1’s interconnect) which R2 reaches via FastEthernet0/0.
R2# *Mar 1 04:35:24.162: RIP: received v2 update from 10.0.2.1 on FastEthernet0/0 *Mar 1 04:35:24.162: 10.0.0.0/24 via 0.0.0.0 in 1 hops *Mar 1 04:35:24.162: 10.0.1.0/24 via 0.0.0.0 in 1 hops
The inbound update packet lists our two networks including their mask! Huzzah! This means we have the correct updates from R1 and they are there specific networks. No entire /8 being thrown into our routing table. Time to issue a show route.
R2#sh ip route | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/0 R 10.0.0.0 [120/1] via 10.0.2.1, 00:00:12, FastEthernet0/0 R 10.0.1.0 [120/1] via 10.0.2.1, 00:00:12, FastEthernet0/0
There we go. Nice and neat. A clean and expected routing table.
So there we go. It goes to show that even RIP, the routing protocol that stands in the shade of its bigger brothers has some curve balls up its sleeves. There are plenty more blogs like this to come. I hope you have enjoyed this and continue with me as I did deeper into the CCIE RS.