45
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
This isn't actually correct. An ip address assignment for a host with an IP requires both the address and the subnet mask. One cannot be assigned without the other. Even more strictly speaking the address by itself isn't useful to the network stack except as a destination, and isn't used anywhere in the network stack of the host. There is always a subnet mask, sometimes the mask is assumed to be /32 (255.255.255.255), sometimes /24, whatever. But whenever you are talking about assigning an ip address to any IP speaker, it must include the mask.
The routing table on every IP speaker will include at a minimum a single host-route. That is the IP of the system itself with a /32 mask and the configured interface of that IP. Whether it's eth0, a bonded interface, a loopback etc.
Once you have that single host route, additional routes can be added as needed. These routes require an address, a subnet, and a next-hop. The next hop can be a directly attached interface, or an IP that the is reachable by another route in the host routing table.
If you have only a host route, as OP has, then the system has no network knowledge, so there are no reachable next hop IPs. So you would have to use a directly connected interface, like the OP did. Once you tell the system 192.168.0.0/24 is reachable through that interface, then any IP Packets that have that network as their destination will use that interface with a source of the one IP it has. In the case of two servers connected back to back, assuming the other server knows where the source of the packet came from, there is no problem sending traffic back.
So to answer the OPs question, there is no difference between one host route, then a static route pointing to an interface, and just a directly connected interface with your server IP on it. They are two different routes that may have different administrative distances, but assuming you aren't doing anything exotic, for all intents and purposes they are the same.
If you are talking about layer2 concepts like broadcasts, the host-route configured server can still receive broadcasts, but only broadcasts with destination ip of 255.255.255.255, not scoped broadcasts like 192.168.0.255 since it will ignore all traffic that isn't unscoped broadcast or a full match to it's own IP address.