Using /31 network masks in cOS Core (RFC-3021)

Last modified on 1 Jun, 2022. Revision 6
This short guide goes through the scenario when we want to use a /31 network mask in cOS Core. Limitations and workaround.
Up to date for
cOS Core 14.00.04
Supported since
cOS Core 9.30.xx
Not valid for
cOS Core 8.xx
Status OK
Author
Peter Nilsson


Problem

Is it possible to configure cOS Core with a /31 network mask? We get an error when we try to add 192.168.1.175/31 to the address book, saying it’s invalid.

Description

It is possible but the correct (base) network address needs to be specified. If we look at the above IP example it looks like this if we use an IPv4 calculator on it:

Network:   192.168.1.174/31
Broadcast: 192.168.1.175
HostMin:   192.168.1.174
HostMax:   192.168.1.175

Just to clarify, 192.168.1.175/31 is by definition of RFC-1878/RFC-950 invalid. The reason for this is because the first address in a e.g. a /31 should be the starting number of the subnet. This varies of course depending on the size of the network, a /24 subnet mask for example the last number must be set to zero (may also vary between vendors/systems).

Note: On /31 network masks, no broadcast address is used. Both IP addresses will be treated as host addresses. The above calculator output does not reflect this.

Some systems accept e.g. 192.168.1.175/31 as valid because it automatically converts it to the correct network. When using e.g. an online IPv4 calculator it may also automatically convert 192.168.175/31 to the correct 192.168.1.174/31. Since cOS Core does not automatically convert it, it will instead report it as an error. This has both a advantage and a disadvantage, the advantage is that the administrator quickly will get feedback on an invalid network and the drawback is that the system could have handled this automatically.

But one question would be, how far should we go in modifying what a user types in? There may not be a correct answer to this question.

Limitation

There is a known limitation when using /31 networks and that appears when we are attempting to connect to the Firewall for remote management. It will not work and there will not be any log generated about it (Engineering report ID COP-21060)

Workaround

  1. Disable automatic route creation on the interface.
  2. Assign the IP you want to the interface but use a dummy network, e.g. 127.0.25.0/32
    1. Important: You can NOT set the /31 network on the interface as network as that could cause some traffic towards the assigned IP to not function as it should (incoming packets could vanish without any logs being generated). So very important to set a dummy network here.
  3. Create a manual route with the /31 network.

Question - What about the DHCP client in the Firewall?

What if an ISP hands out a /31 with e.g. 192.168.1.175/31?

Answer

At this time it is unconfirmed on how it would behave, there is a fairly good chance that the DHCP lease offer would be unable to update the cOS Core address book and it could generate a failure/error.



Related articles

Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
The meaning of the "Default_Access_Rule" log entry
25 Jan, 2021 brokenlink core arp log routing
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink