Looking closely at Figure 2-2, we see that there is no field for subnet masks in RIP. Let’s say that router SantaFe received an update with the following routes in the IP address field:
192.100.1.48 192.100.1.64 192.100.2.0 10.0.0.0
And let’s say that SantaFe has the following configuration:
hostname SantaFe ! interface Ethernet 0 ip address 192.100.1.17 255.255.255.240 ! interface Ethernet 1 ip address 192.100.1.33 255.255.255.240 ! router rip network 192.100.1.0 network 192.100.2.0
How would the router associate subnet masks with these routes?
If the router has an interface on a network number received in an update, it would associate the same mask with the update as it does with its own interface. Consequently, RIP does not permit Variable Length Subnet Masks (VLSM).
If the router does not have an interface on the network number received in an update, it would assume a natural mask for the network number.
SantaFe’s routing table would look like this:
SantaFe>sh ip route
...
Gateway of last resort is not set
R 10.0.0.0 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
R 192.100.2.0 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
192.100.1.0/16 is subnetted, 4 subnets
C 192.100.1.16 is directly connected, Ethernet0
C 192.100.1.32 is directly connected, Ethernet1
R 192.100.1.48 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
R 192.100.1.64 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
SantaFe represents
192.100.1.48 and 192.100.1.64
with a 28-bit mask even though the subnet mask was not conveyed in
the RIP update. SantaFe was able to deduce the
28-bit mask because it has direct interfaces on
192.100.1.0 networks. This assumption is key to
why RIP does not support VLSM.
SantaFe represents
192.100.2.0 and 10.0.0.0 with
their natural 24-bit and 8-bit masks, respectively, because it has no
interfaces on those networks. Chapter 5 covers
RIP-2, an extension of RIP that supports VLSM.