this post was submitted on 27 Jul 2024
7 points (88.9% liked)
Network Engineering
586 readers
1 users here now
All things enterprise network engineering, design, and architecture.
Rules
- No low effort posts
- No home networking topics
- No memes
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
First. It uses the source IP to craft the response, then does a lookup in its routing table to figure out on which interface is used for transmission. If necessary it will do an ARP request to figure out the MAC as well.
OK this is what I was thinking too. So consider this scenario:
srcPCnic1 - 192.168.1.100/24 DG: 192.168.1.1 dstPCnic1 - 192.168.2.100/24 dstPCnic2 - 192.168.1.101/24 DG: 192.168.1.1
Topology: srcPCnic1 -> RTR -> dstPCnic1 Assume srcPCnic1 is also connected to dstPCnic2 via a switch. (Sorry if its difficult to imagine with the crude description)
On srcPC execute:
ping 192.168.2.100
RTR will route the packet to dstPC. dstPC receives the packet on nic1. dstPC sends the Response packet via nic2.Is the above understanding correct?
I believe so, yes. The routing table should result in the PC sending the response via the direct route, as opposed to via the defGW. I'm not 100% sure, though. There could be some "default" behavior of using the same nic as the one the packet was received on, stemming from the original 192.168.2.0/24 destination.
I recently tested this using wireshark. When I run packet capture on nic1 of dstPC I see ping request packets coming, but no response packets leaving the interface. On nic2 I don't see any packets leaving either. So kind of stumped what is happening. It seems the computer just drops the response packet and it never makes it till any nic. But still don't have a good explanation of WHY the packet gets dropped.
Probably rp filtering.
https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html