Cisconinja’s Blog

VLSM Usage and Mismatched Subnet Masks in RIPv1

Posted by Andy on April 12, 2009

In this post we will look at what happens when a router using VLSM attempts to advertise the variably subnetted address space with RIPv1.  We will also look at what happens when opposite ends of a link are configured with different subnet masks in RIPv1.  The topology and configurations are shown below:

ripv1-vlsm

R1:
interface Loopback1
 ip address 10.1.1.1 255.255.255.0
!
interface Loopback2
 ip address 10.1.2.1 255.255.255.0
!
interface Loopback3
 ip address 10.1.3.1 255.255.255.0
!
interface Loopback4
 ip address 10.1.4.1 255.255.255.0
!
interface Loopback5
 ip address 10.1.5.1 255.255.255.192
!
interface Loopback6
 ip address 10.1.6.65 255.255.255.192
!
interface Loopback7
 ip address 10.1.7.129 255.255.255.192
!
interface Loopback8
 ip address 10.1.8.193 255.255.255.192
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0

R2:
interface Loopback1
 ip address 10.2.1.2 255.255.255.0
!
interface Loopback2
 ip address 10.2.2.2 255.255.255.0
!
interface Loopback3
 ip address 10.2.3.2 255.255.255.0
!
interface Loopback4
 ip address 10.2.4.2 255.255.255.0
!
interface Loopback5
 ip address 10.2.5.2 255.255.255.192
!
interface Loopback6
 ip address 10.2.6.65 255.255.255.192
!
interface Loopback7
 ip address 10.2.7.129 255.255.255.192
!
interface Loopback8
 ip address 10.2.8.193 255.255.255.192
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0

We will enable RIPv1 for the 10.0.0.0 network on each router.  We will also configure all loopback interfaces as passive interfaces so that there isn’t so much debug output:

R1:
router rip
 passive-interface default
 no passive-interface Serial0/0
 network 10.0.0.0

R2:
router rip
 passive-interface default
 no passive-interface Serial0/0
 network 10.0.0.0

R1 and R2 send only routes that have the same mask as the outgoing interface.  All /24 networks are sent and added to each other’s routing tables, and neither has knowledge of the other /26 networks:

R1#debug ip rip
*Mar 1 00:26:03.619: RIP: sending v1 update to 10.0.12.2 via Serial0/0 (10.0.12.1)
*Mar 1 00:26:03.623: RIP: build update entries
*Mar 1 00:26:03.623: subnet 10.1.1.0 metric 1
*Mar 1 00:26:03.623: subnet 10.1.2.0 metric 1
*Mar 1 00:26:03.623: subnet 10.1.3.0 metric 1
*Mar 1 00:26:03.627: subnet 10.1.4.0 metric 1
*Mar 1 00:26:05.643: RIP: received v1 update from 10.0.12.2 on Serial0/0
*Mar 1 00:26:05.643: 10.2.1.0 in 1 hops
*Mar 1 00:26:05.647: 10.2.2.0 in 1 hops
*Mar 1 00:26:05.651: 10.2.3.0 in 1 hops
*Mar 1 00:26:05.651: 10.2.4.0 in 1 hops

1-r1-route-table

1-r2-route-table

 

Next, we will change R2 to use a /26 mask on S0/0:

R2:
interface Serial0/0
 ip address 10.0.12.2 255.255.255.192

R2 stops sending the /24 routes in updates and begins sending the /26 routes:

R2#debug ip rip
*Mar 1 00:36:36.751: RIP: received v1 update from 10.0.12.1 on Serial0/0
*Mar 1 00:36:36.751: 10.1.1.0 in 1 hops
*Mar 1 00:36:36.751: 10.1.2.0 in 1 hops
*Mar 1 00:36:36.751: 10.1.3.0 in 1 hops
*Mar 1 00:36:36.751: 10.1.4.0 in 1 hops
*Mar 1 00:36:58.327: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (10.0.12.2)
*Mar 1 00:36:58.327: RIP: build update entries
*Mar 1 00:36:58.331: subnet 10.2.5.0 metric 1
*Mar 1 00:36:58.331: subnet 10.2.6.64 metric 1
*Mar 1 00:36:58.331: subnet 10.2.7.128 metric 1
*Mar 1 00:36:58.331: subnet 10.2.8.192 metric 1

Because mask information is not carried in routing updates in RIPv1, the mask of the receiving interface is also used for determining the mask of received routes.  R2 interprets R1’s routes as all having /26 masks.  As a result, only the first 1/4 of the address space of each route is reachable from R2.  Once the flush timer expires for the old routes after changing the mask, R2’s route table now looks like this:

2-r2-route-table

R1 interprets all the routes received from R2 as having /24 masks.  Of the 4 routes received from R2, only 10.2.5.0 is a valid subnet address using a /24 mask.  Since the other 3 are invalid /24 subnets, they are instead interpreted as host routes and added with a /32 mask:

2-r1-route-table

The result is that R1 will attempt to route traffic in the range 10.2.5.64 – 10.2.5.255 to R2 when it should not, and will not route any traffic to the other 3 /26 networks when it should.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: