PT.zip (49.6 KB)
Hi Laz,
Apologies for the long post.
Thank you very much for the detailed response.
One thing I don’t understand is that if H1 sees that a packet with the source IP of H2 arrives with the source MAC address of R1, why is it that H1 doesn’t map R1’s MAC address with H2’s IP address? For all H1 knows, what happened was it received a ping from a device that is in its own subnet, so H1 populates its ARP cache with this information.
Please allow me to introduce another related topic:
I’ve experimented with this scenario in Packet Tracer and found something interesting. Not sure if it’s a PT bug or something that works like this in real life (I have no access to real gear yet to experiment with). The interesting thing I found was if the ARP table of at least one host contains the MAC-to-IP mapping of the other host (it doesn’t matter which host this is), then the ping succeeds. It doesn’t matter which host thinks it’s in the same subnet as the other one, and who plays which role (sender or receiver).
Please note that I’ve changed the IP addresses from our earlier example, just for convenience (it was easier for me to change the subnet masks this way as I was experimenting).
Topology, default gateway, and host settings:
Both host’s ARP caches are empty. First ping attempt fails: PC0 thinks it’s in the same subnet as PC1; PC1 thinks it’s in a different subnet than PC0.
Second ping attempt succeeds: both hosts think they’re on the same subnet. The ARP caches of both hosts are now populated.
Third ping attempt succeeds: PC0 thinks it’s in the same subnet as PC1; PC1 thinks it’s in a different subnet than PC0.
Here are all possible scenarios. All pings succeed:
Sender thinks it’s in the same subnet as the receiver; sender’s ARP cache populated, receiver’s not:
Sender thinks it’s in the same subnet as the receiver; sender’s ARP table not populated, receiver’s is populated:
Sender thinks it’s in a different subnet; sender’s ARP cache not populated, receiver’s is populated:
Sender thinks it’s in a different subnet; sender’s ARP cache populated, receiver’s not
I’ve also played around with the tracert command.
To get the behavior where the traffic from PC1 goes through the router, you first
- start with an empty ARP cache,
- change the subnet mask of PC1 so that it’s in the /8 subnet (this will clear its arp cache),
- ping PC1 from PC0,
- change the subnet mask of PC1 so that it’s in the /24 subnet (other masks probably work as well),
- ping PC1 from PC0,
- do a tracert from PC0 to PC1,
- do a tracert from PC1 to PC0.
How the tracert command doesn’t work:
- start with an empty ARP cache,
- change PC1’s subnet to /8,
- issue a tracert from PC0 to PC1,
- change PC1’s subnet to /24,
- issue a tracert from PC1 to PC0.
Sometimes the above steps don’t work, but when I’ve restarted Packet Tracer, they did. So this all might be a PT bug.
I’ve uploaded the Packet Tracer lab for your convenience.
Can you please help me out what’s going on here?
Have a nice week.
Attila