Confused with Subnet Mask

casperguy

Reputable
Aug 19, 2014
1
0
4,510
3 Machines with following details. (IP address / subnet mask / Default gateway)

Machine A = 10.100.200.222 / 255.255.0.0 / 10.100.100.1
Machine B = 10.100.100.221 / 255.255.0.0 / 10.100.100.1
Machine C = 10.100.100.220 / 255.255.255.0 / 10.100.100.1

Router = 10.100.100.1 / 255.255.255.0

Machine A can communicate with B.
Machine B can communicate with C.
Machine A CANNOT communicate with C.

Why can Machine B communicate with C eventhough the subnet mask is different , but not Machine A?
Can someone please explain?
Many Thanks
Casper.
 
Solution
It shouldn't work but it does because of how ARP is implemented under ethernet. You can not assume it will work in something like frame relay or where there are layer 2 firewall enforcing rules.

The reason it works is because of how broadcasts are implemented and the fact that ARP packets do not contain the layer 3 ip broadcast address.

So any ip that is within what you think is your subnet you will send a ARP to the broadcast mac address of FF:FF:FF:FF:FF:FF.

So even though 10.100.0.0/16 has a broadcast of 10.100.255.255 and 10.100.100.0/24 has a broadcast of 10.100.100.255 both are sent to the same FF:FF:FF:FF:FF:FF mac address. Since a ARP packet only contains the senders ip and the address it is looking for but no masks or...

trymeran

Reputable
Aug 19, 2014
9
0
4,520
Hey, Casperguy

Why haven't you changed the IP on machine A? If the subnet mask is 255.255.255.0 then all pc's must be 10.100.100.X where X could be any available port on the network. 255 represent the number that all pc's must have before the available port. Example: If the subnet is 255.255.255.0 then all pc's must have the same number in the IP address like: 192.168.1.X where X could be any port available. First determine wich is the correct subnet mask and then make the changes needed in the IP address.

I really wish you can solve this, mate. Good luck...
 

johnsonma

Distinguished
Jan 19, 2012
1,395
0
19,290


C can communicate with B because the third octet is the same. If the first three octets are the same then 255.255.0.0 or 255.255.255.0 will work. 10.100.200.222 / 255.255.0.0 would not communicate with C because C is setup so it only will communicate with a machine that has a 10.100.100.x address.




 
It shouldn't work but it does because of how ARP is implemented under ethernet. You can not assume it will work in something like frame relay or where there are layer 2 firewall enforcing rules.

The reason it works is because of how broadcasts are implemented and the fact that ARP packets do not contain the layer 3 ip broadcast address.

So any ip that is within what you think is your subnet you will send a ARP to the broadcast mac address of FF:FF:FF:FF:FF:FF.

So even though 10.100.0.0/16 has a broadcast of 10.100.255.255 and 10.100.100.0/24 has a broadcast of 10.100.100.255 both are sent to the same FF:FF:FF:FF:FF:FF mac address. Since a ARP packet only contains the senders ip and the address it is looking for but no masks or anything this works. Once a device gets a mac address it sends all traffic via mac so they never bother to check the subnet again.

Now 10.100.200.222 CAN in some platforms actually talk to 10.10.100.220 when the subnets do not match but it depends on even more implementation dependencies.

Generally ARPs are send in both directions so 10.100.200.222 would arp 10.100.100.220 and likely receive a reply, some platforms enforce the subnet and do not reply. So now 10.100.200.222 knows how to send traffic to 10.100.100.220. If the subnet was correct 10.100.100.220 would do a arp for 10.100.200.222 and all would be well but because the subnet does not match it will actually send traffic destined for 10.10.200.222 to 10.100.100.1. Now if 10.100.100.1 allows for traffic to hairpin though it will forward the traffic to 10.10.200.222 assuming its subnet is /16 in this case. So now you have async routing traffic from 10.100.200.222-10.100.100.220 will go via mac and traffic 10.100.100.220-10.110.200.222 will go via the gateway address.

You really can't depend on this working consistently across platforms because it really should not work, it just depends how much effort was put in to enforce the rules.

 
Solution