Why nic with incorrect subnet mask can still ping the gate way?

Question

At first, my network config was like this:

$ ip a
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 3c:97:0e:bd:b1:68 brd ff:ff:ff:ff:ff:ff
    inet 10.66.65.2/24 brd 10.66.65.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::3e97:eff:febd:b168/64 scope link 
       valid_lft forever preferred_lft forever

$ ip r
default via 10.66.65.254 dev em1  proto static 
10.66.65.0/24 dev em1  proto kernel  scope link  src 10.66.65.2  metric 1

in this way, the network subnet mask is incorrect. I don't have the access to internet but I can ping gateway 10.66.65.254.

Then I flush the route table and ip address of em1 and restart nic. And I have a new route table and ip:

$ ip a s dev em1
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 3c:97:0e:bd:b1:68 brd ff:ff:ff:ff:ff:ff
    inet 10.66.65.2/23 brd 10.66.65.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::3e97:eff:febd:b168/64 scope link 
       valid_lft forever preferred_lft forever
$ ip r
default via 10.66.65.254 dev em1  proto static 
10.66.64.0/23 dev em1  proto kernel  scope link  src 10.66.65.2  metric 1

and I can access the internet now.

What I think have happened before I change restart the nics is like: the packet to the internet have a destination of say 172.1.1.1 and 10.66.65.2 as source, so it look up the route table and go out thought em1, then the gateway received the packet, but when the packet is going back to em1, the gateway cannot find an appropriate route entry for 10.66.65.2/24, so it dropped the packet, so I can't access the internet.

But I am wondering why I can ping the gateway, why is it able to send packet to me this time?

Thanks

Answer 1

Your mask was fine to start with, at least so far as contacting the gateway is concerned. In fact, this line,

   inet 10.66.65.2/24

makes sure that your gateway and you belong to the same subnet, and in fact you did access your gateway, and got a response back. So the reason why you could not access the Internet is to be sought elsewhere. Two possibilities: 1) your gateway was off-line, 2) your DNS wasn't correctly set in /etc/resolv.conf.

However, please notice also that, after flushing your network information, the subnet you automatically receive from the DHCP, 10.66.65.0/23, is wider than the above. It completely contains 10.66.65.0/24, so that you were able to connect to your gateway even when you had the smaller subnet, but you missed out on the possibility to link to other machines in your LAN. So, besides correcting the file /etc/resolv.conf, you may want to change the subnet to the wider, correct version. You can do it by invoking DHCP as follows:

ip link set dev em1 down
ip addr flush dev em1
ip link set dev em1 up
dhclient -v em1

The -v (= verbose) option prints to standard output the various steps of the negotiation with the DHCP server, but it is not available on all dhclient versions.

If instead you have a NIC with a static IP address, you can change the subnet as follows:

ip link set dev em1 down
ip addr flush dev em1
ip link set dev em1 up
ip addr add 10.66.65.2/23 dev em1

and that's it.

Answer 2

Host 10.66.65.2 with a /24 means it thinks 10.66.65.0 through 10.66.65.255 are on the same subnet, so it would of course think that the router 10.66.65.254 was on its same subnet.

Host 10.66.65.2 with a /23 means it thinks 10.66.64.0 through 10.66.65.255 are on the same subnet, so it would of course think that the router 10.66.65.254 was on its same subnet.

If the /23 subnet was correct, it would have meant that some subnet broadcasts would've been mishandled by your host, and it would have meant that your host would have had to rely on the gateway to forward frames that it should have directly addressed to the 10.66.64.x hosts. Or, more likely, the gateway would have sent ICMP redirect notices to your host, informing it that it could address those packets directly to their destination hosts at the link layer.

The subnet mask misconfiguration was probably not the source of your failure to get Internet connectivity.