I was exploring direct links between machines, and basically failed to break something.
I assigned IP address 192.168.0.1/24 to eth0 in two ways.
A. Adding 192.168.0.1/24 as usual
# ip addr add 192.168.0.1/24 dev eth0
# ping -c 1 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.051 ms
--- 192.168.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.051/0.051/0.051/0.000 ms
#
B: Adding 192.168.0.1/32 and adding a /24 route
# ip addr add 192.168.0.1/32 dev eth0
# # 192.168.0.2 should not be reachable.
# ping -c 1 192.168.0.2
ping: connect: Network is unreachable
# # But after adding a route, it is.
# ip route add 192.168.0.0/24 dev eth0
# ping -c 1 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.053 ms
--- 192.168.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms
#
Does this mean that adding an IP address with prefix is just a shorthand for adding the IP address with /32 prefix and adding a route afterwards? That is, does the prefix length has no meaning and the real work is done by the route entries?
Or is there any functional difference between the two methods?
Here is another case, these two nodes can reach each other via direct connection (no router in between) but don’t share a subnet.
Node 1:
# ip addr add 192.168.0.1/24 dev eth0
# ip route add 192.168.1.0/24 dev eth0
# # Finish the config on Node B
# nc 192.168.1.1 8080 <<< "Message from 192.168.0.1"
Response from 192.168.1.1
Node 2:
# ip addr add 192.168.1.1/24 dev eth0
# ip route add 192.168.0.0/24 dev eth0
# # Finish the config on Node A
# nc -l 0.0.0.0 8080 <<< "Response from 192.168.1.1"
Message from 192.168.0.1
It is a postfix representing the subnet „set bit“ prefix. Can we agree on this ?
No, because this is common terminology that has no reason to be messed with, even if it is technically unclear.
If there is one thing we can all agree on is that we do not want to go back to writing out the subnet masks manually, especially not with IPv6 ones being 4 times as long.
IPv6 subnet masks are long, but super easy because of hexadecimal. A bunch of
Fs, then[EC8]?then a bunch of0s.That doesn’t sound right, even with hex you would still have 8 possible values (well, 6 if you don’t count all 1 and all 0) for the byte where the netmask switches from 1s to 0s or only 4 (2 if you don’t count all 1 and all 0) for the half-byte.
I listed the 5 possible digits. What’s missing?
Never mind, I didn’t think it through properly earlier. Not quite sure what I was thinking at the time but probably got distracted. Obviously you have 5 possible values between 0 and 4 bits being 1.
1111 = 0xF 1110 = 0xE 1100 = 0xC 1000 = 0x8 0000 = 0x0