Does RIPv2 Support CIDR/SUPERNET Networks?...Continued

Ok Friends...it's time to continue the mysterious RIPv2's CIDR/Supernet support issue. It took me a while to solve this issue but more time I spent was to understand the logic behind it.

In the first look most of the people I know thought that RIPv2 will work fine in this scenario. They said: just configure RIPv2 than disable classful summarization behavior using "no auto-summary" key-word and that is pretty much enough to make this scenario work.

But I had already tried those things and I knew it's not gonna work in that way. So I though lets go through rfc for RIP and also I went through Routing TCP/IP Vol 1 by Jeff Doyle. But more I read more I got confused. RFC clearly says that RIP flavors do not support supernet ip addressing at all, on the other hand Jeff Doyle was mentioning that Classless and CIDR support is there in RIPv2.

Hmmmm.....pretty confusing :-( isn't it......

Anyways...I spoke one of my very close friend who is also preparing for CCIE Lab exam Mr. Mrityunjay Rai....he was also not sure why RIPv2 was not working but anyhow we discussed the issue and then decided to run PPP as encapsulation on WAN interfaces of both R1 and R2. As soon as we did that the RIP started working :-)

Wow..........We made it work :-)

But the next question in my mind was how RIP started working by just configuring PPP as encapsulation on WAN interfaces of both routers...I mean come on we all know that PPP is just a Layer 2 encapsulation and how come it can change the behavior of Layer 3 routing protocol's behavior.

So one journey ended and another begin...

So again I started working on the new issue about how PPP made RIPv2 work in this scenario.

I check the routing table prior and after setting encapsulation as ppp and finally I found the clue with help of my CCIE Security friend Mr. Deptanshu Singh CCIE#20679. Again the clue was our very old friend PPP peer neighbor route feature. Here is the routing table of R1 before and after changing encapsulation to PPP:

Before:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0


After:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.2 is directly connected, Serial0/0
C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0
R 192.168.2.0/23 [120/1] via 192.168.4.2, 00:00:09, Serial0/0


So if you look closely at the routing tables you will see that before setting encapsulation as ppp the WAN subnet 192.168.4.0 was appearing in routing table with /23 prefix as 192.168.4.0/23; but as soon as we changed the encapsulation to ppp, the ppp peer neighbor route feature installed a /32 prefix for the same WAN subnet and now it appears in routing table as 192.168.4.0/32. So with /32 prefix it is not a supernet network anymore and became subnetted network and we all know that RIPv2 does support subnetting and vlsm.

So finally we found the reason why ppp made this scenario working. But......still But? :-(

Still I wanted to figure out the difference between the statement of RIP rfc and statement of respected Mr. Jeff Doyle about CIDR/Classless support.

After working on while on this new mystery I conclude that rfc and Jeff's statements are right I mean both of them are right......Huhh.....don't worry.....You need not to panic :-)

The final conclusion is RIP routers won't exchange routes on WAN links which contain supernet ip addresses by default or in other words no supernet support. On the other hand if we are receiving a supernet route on a RIP router through some other routing protocol or may be even through static routing, in that case after redistributing that supernet route learned through other routing protocol into RIP routing process, RIP will forward this supernet route information to other routers running RIP in the same domain.

To test this thing I added one more router in our existing topology and run EIGRP on R3 and R1's S0/1 interface. After that I assigned a supernet ip address 172.16.100.1 on R3's F0/0. Later I saw that router R1 was able to see this supernet network. See below the routing table of R1 :

R1(config)#do sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial0/1
192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.2 is directly connected, Serial0/0
D 172.0.0.0/10 [90/2195456] via 1.1.1.1, 00:00:41, Serial0/1
C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0
R 192.168.2.0/23 [120/1] via 192.168.4.2, 00:00:03, Serial0/0

And after redistributing EIGRP 100 process into RIP Process; R2 was also able to see the 172.0.0.0/10 supernet route :-)

R1(config)#do sh run | be router rip
router rip
version 2
redistribute eigrp 100 metric 1
network 192.168.0.0
network 192.168.4.0
no auto-summary

R2(config)#do sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.1 is directly connected, Serial0/0
R 172.0.0.0/10 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
C 192.168.4.0/23 is directly connected, Serial0/0
R 192.168.0.0/23 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
C 192.168.2.0/23 is directly connected, FastEthernet0/0

I hope you enjoyed this topic... If you have any opinions or suggestions on this please feel free to drop an email to me @ deepakarora.1984@gmail.com

Best Regards,
Deepak Arora
CCIE#2XXXX...Oops that number is still missing