Major network RIP

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.rip-gns3

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 50.0.0.1 255.255.255.0
 duplex auto
 speed auto
router rip
 version 2
 network 10.0.0.0
 network 50.0.0.0
R2
interface FastEthernet0/0
 ip address 50.0.0.2 255.255.255.0
 duplex auto
 speed auto
router rip
 version 2
 network 50.0.0.0

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 50.0.0.1, 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 224.0.0.9 via FastEthernet0/0 (50.0.0.1)
*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 224.0.0.9 via Loopback2 (10.0.1.1)
*Mar 1 00:55:58.707: RIP: build update entries
*Mar 1 00:55:58.707: 50.0.0.0/8 via 0.0.0.0, metric 1, tag 0

Note here the update entries sending 50.0.0.0/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 50.0.0.1 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
50.0.0.0/8    auto-summary
50.0.0.0/24    directly connected, FastEthernet0/0

R2#sh ip rip data
10.0.0.0/8    auto-summary
10.0.0.0/8
    [1] via 50.0.0.1, 00:00:18, FastEthernet0/0
50.0.0.0/8    auto-summary
50.0.0.0/24    directly connected, FastEthernet0/0

Note we see auto-summary entries next to 10.0.0.0/8 and 50.0.0.0/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 126.255.255.255. 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 128.0.0.0 and 191.255.255.255 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 223.255.255.255 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 50.0.0.0 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 50.0.0.0. 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 224.0.0.9 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 50.0.0.0 network then the 10.0.2.0 network.

With the 50.0.0.0 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 50.0.0.1, 00:00:20, FastEthernet0/0
R 10.0.0.0/8 [120/1] via 50.0.0.1, 00:01:16, FastEthernet0/0
R 10.0.1.0/24 [120/1] via 50.0.0.1, 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
 [1] via 50.0.0.1, 00:01:36, FastEthernet0/0
10.0.0.0/24
 [1] via 50.0.0.1, 00:00:10, FastEthernet0/0
10.0.1.0/24
 [1] via 50.0.0.1, 00:00:10, FastEthernet0/0
50.0.0.0/8 auto-summary
50.0.0.0/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
 [1] via 10.0.2.1, 00:00:03, FastEthernet0/0
10.0.1.0/24
 [1] 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.

3 thoughts on “Major network RIP

  1. stretch says:

    Next on the History Channel: When Nazi Sharks Attack!

    Seriously though, how frustrating and depressing is it that in this era of virtualization and SDN, CCIE candidates are forced to dig into protocols and methodologies which have been obsolete for decades? Cisco, it’s past time for some thorough pruning of the CCIE R&S topic roster.

    • pandom says:

      Yeah, it is a bit odd. I do hope v5 trims up a few older technologies. Although I see RIP staying, Frame Relay and some others should disappear.

  2. Tomislav says:

    RIP has been thrown out from the new curriculum altogether, despite being the only protocol in use on many SOHO and ISP equipment.

Leave a Reply

Your email address will not be published. Required fields are marked *


*