The Subnet Mask

Time: 30 min

Needs: two OL9 Router, four OL9 PCs, one Ethernet switch

GNS3 project: w05-a1-subnet-mask

Build it

Start with two OL9 PC nodes H1 and H2 cabled to a switch.

Log on to H1 as root, then:

nmcli con add type ethernet ifname eth0 con-name eth0
nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.100/25
nmcli con up eth0

Log on to H2 as root, then:

nmcli con add type ethernet ifname eth0 con-name eth0
nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.200/24
nmcli con up eth0

Try to ping H2 from H1 and vice versa. The pings fail. Let's find out why:

On H1:

ip route get 192.168.10.200

On H2:

ip route get 192.168.10.100

What just happened

• We intentionally configured H1 with the wrong subnet mask /25
• The mask determines which addresses H1 considers local which is why it sees 192.168.10.200 as unreachable as show by ip route get
• The subnet mask is a claim about which addresses the host can reach.
  • It matters only to the host, i.e., it is not enforced by the network
  • it is not advertised. No one else, other than the host itself, needs to know
• H2 does see H1 as reachable and the ping is duly delivered to H1, but H1 is unable to answer
  • Note that H1's "wrong" mask does not influence H2 view of the network. H2 consults only its own mask

Do this - fix it

On H1:

ip route add 192.168.10.200 dev eth0

ip route get 192.168.10.200

ping -c1 192.168.10.200

What just happened

• This time the pings work.
• ip route add without a gateway is an assertion that 192.168.10.200 is reachable locally. Note that this is only stated but not verified. If the host is somewhere else, attempting to connect to it will still fail.

On H1:

ip route del 192.168.10.200

ip route get 192.168.10.200

ping -c1 192.168.10.200

The pings are back to failing as expected

Do this - Use a gateway

Add an OL9 Router node R1 and cable it to the switch. Then:

# on R1
nmcli con add type ethernet ifname eth0 con-name eth0
nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.1/24
nmcli con up eth0

sysctl -w net.ipv4.ip_forward=1

On H1:

ip route add default via 192.168.10.1

ip route

ip route get 192.168.10.200

Start a capture on R1 link.

On H1:

ping -c1 192.168.10.200

ip route get 192.168.10.200

What just happened

• R1 is configured with the "correct" mask, so it can reach both H1 and H2
• Setting a default gateway on H1 allows it to attempt any destination, not just what it can reach locally. As a result, the pings succeed.
• In R1 capture, select the Redirect ICMP packet and expand its contents:
  • Find the line that reads Gateway Address: 192.168.10.200. R1 is telling H1 that it can reach H2 directly and does not need to use a gateway.
  • Runing ip route get 192.168.10.200 on H1 after the ping reveals that H1 has updated its routing table accordingly

Before continuing, fix the mask error on H1 and delete the default route:

ip route del default

nmcli con mod eth0 ipv4.addresses 192.169.10.100/24
nmcli con up eth0

Do this - Use reserved addresses

Add two new OL9 PC nodes H3 and H4 and cable them to the switch.

Log on to H3 as root, then:

nmcli con add type ethernet ifname eth0 con-name eth0
nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.255/24
nmcli con up eth0

Log on to H4 as root, then:

nmcli con add type ethernet ifname eth0 con-name eth0
nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.0/24
nmcli con up eth0

On all hosts (H1-4):

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

Start a capture on H3 cable.

On H1:

ping -c1 192.168.10.0

ping -b -v -c4 192.168.10.255

What just happened

• Assigning the reserved addresses did not raise any error! (This may be platform-dependent. Linux is being permissive here)
  • 192.168.10.0, the first address in the range, is reserved as the address of the whole segment. However, nobody enforced this rule, so when used as a host address, other hosts interpret it as such
  • 192.168.10.255, the last address in the range, is reserved as the segment's broadcast address. The host accepts it, but other hosts still rightly interpret it as the broadcast address, which is why they don't answer ARP requests for it, while they all answer the ICMP broadcast.

The key takeaway here is never to assign to a host the subnet's reserved addresses, i.e. network ID and subnet ID, to avoid failures that are hard to troubleshoot.

Do this - the exception

Add another OL9 Router node R2 and connect the two routers together. The following instructions assume R1.eth1 - R2.eth0.

On R1:

nmcli con add type ethernet ifname eth1 con-name eth1
nmcli con mod eth1 ipv4.method manual ipv4.addresses 172.16.1.0/31
nmcli con up eth1

On R2:

nmcli con add type ethernet ifname eth0 con-name eth0
nmcli con mod eth0 ipv4.method manual ipv4.addresses 172.16.1.1/31
nmcli con up eth0

ping -c1 172.16.1.0

What just happened

• A /31 prefix defines a range of only 2 addresses. Such a range would only consists of reserved addresses (the subnet ID and broadcast ID) leaving no host addresses
• RFC 3021 defines both addresses as host addresses in the context where the subnet is assigned to a point-to-point link, as is the case here
• This is how R1 and R2 are able to communicate normally using addresses that would otherwise be reserved.

Do this - find the boundary

Predict first

For 192.168.10.0/25:

On H1:

nmcli con mod eth0 ipv4.addresses 192.168.10.100/25
nmcli con up eth0

ip route get 192.168.10.125
ip route get 192.168.10.126
ip route get 192.168.10.127
ip route get 192.168.10.128

Move the boundary again and predict first

For 192.168.10.0/28:

On H1:

nmcli con mod eth0 ipv4.addresses 192.168.10.11/28
nmcli con up eth0

ip route get 192.168.10.14
ip route get 192.168.10.15
ip route get 192.168.10.16

What just happened

• /25 gives 128 address with 126 usable. The boundary moved from .255 to .127
• /28 gives 16 addresses with 14 usable. The boundary moved from .127 to .15
• ip route get did the arithmetic automatically to locate the edge. Start with this whenever you get Network unreachable error.