Using /31’s on point to point links and their affect on routing protocols

The use of 31bit subnet masks on point to point links is documented in RFC 3021: http://www.ietf.org/rfc/rfc3021.txt

If you know subnetting, you should know that networks always need a subnet address (all zeroes) and a ‘broadcast’ address. This is why when you generally use a /30 for point-to-point links. 2 addresses used for the routers on each end, then 1 subnet address and 1 broadcast address.

Essentially using a /31 gives you no option to use directed broadcasts. How does this affect routing protocols though? These days most use multicast, but some of the older ones use broadcasts. Let’s run a lab to find out!

I’ve got a simple topology going here. 2 routers connected to each other, each with a loopback subnet advertised in the protocol.

Let’s see what happens!

The first thing I do is to give /31 addresses to both interfaces. Immediately I got the following warning:

R2(config-ip)ip address 10.1.1.4 255.255.255.254
% Warning: use /31 mask on point-to-point interface cautiously

RIPv1:

R1(config)#router rip
R1(config-router)#network 10.0.0.0
R1(config-router)#network 192.168.1.0

R1#sh ip route 172.16.1.1
Routing entry for 172.16.0.0/16
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 10.1.1.4 on FastEthernet0, 00:00:13 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

So it works fine!

RIPv2:

R1(config)#router rip
R1(config-router)#version 2

R1#sh ip route 172.16.1.1
Routing entry for 172.16.0.0/16
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 10.1.1.4 on FastEthernet0, 00:00:08 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

Once again, no problem!

EIGRP

R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 10.1.1.5
R1(config-router)#network 192.168.1.1

R1#sh ip route 172.16.1.1
Routing entry for 172.16.0.0/16
 Known via "eigrp 1", distance 90, metric 156160, type internal
 Redistributing via eigrp 1
 Last update from 10.1.1.4 on FastEthernet0, 00:01:45 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

So EIGRP has no problems either!

OSPF:

R1(config)#router ospf 1
R1(config-router)#network 10.1.1.5 0.0.0.0 area 0
R1(config-router)#network 192.168.1.1 0.0.0.255 area 0

R1#sh ip route 172.16.1.1
Routing entry for 172.16.1.1/32
 Known via "ospf 1", distance 110, metric 2, type intra area
 Last update from 10.1.1.4 on FastEthernet0, 00:00:45 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

OSPF is just fine. I guess we can see a pattern emerging here…

BGP

R1(config)#router bgp 100
R1(config-router)#neighbor 10.1.1.4 remote-as 200
R1(config-router)#network 192.168.1.0 mask 255.255.255.0

R1#sh ip route 172.16.1.1
Routing entry for 172.16.1.0/24
 Known via "bgp 100", distance 20, metric 0
 Tag 200, type external
 Last update from 10.1.1.4 00:00:08 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

Out trusted BGP works just fine

To be honest everything seems to work just fine. I suppose I could test IS-IS and IGRP as well, but who really uses IGRP anymore? (I suppose the same could be said about RIPv1)

IS-IS I suppose would work just fine, but I forgot to test it. I’ll update this post when I do though :)

I’m going to make all my future topologies using /31 on point-to-point links. Not only will it be good practice, but if I ever run into something that ‘doesn’t work’ in the lab, its a better place to not work than in the real world!

If you have any bad experiences with /31’s please let me know in the comments.

Note: I’ve done a new post with some other network OS’s. Check it out here http://mellowd.co.uk/ccie/?p=937

© 2009-2018 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright