Exact trace of outbound packet based on routing table

Question

Say I have a routing table

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.2     30
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.0.0    255.255.255.0         On-link       192.168.0.2    286
      192.168.0.2  255.255.255.255         On-link       192.168.0.2    286
    192.168.0.255  255.255.255.255         On-link       192.168.0.2    286
===========================================================================

and I want to send a ping request to 192.168.0.3.

Newly created a packet with destination 192.168.0.3 (and source 127.0.0.1?) appears on the network. It will hit the rule 192.168.0.0/24 with interface 192.168.0.2. The packet gets source changed to 192.168.0.2 (based on this answer). It didn't hit the first rule, so it cannot use the gateway at the moment, yet somehow the packet leaves.

What are next steps in this case and why?

user10489 · Answer 1 · 2023-01-22T05:57:09.303

The packet doesn't start with the source 127.0.0.1, it likely starts with either the source * (aka 0.0.0.0) or 192.168.0.2 which should be the local host's IP.

If the IP was something other than 192.168.0.0/24, it would head for the default route (first rule),
and to get to the default route target, it would use the route 192.168.0.0/24 via interface 192.168.0.2 (which would then replace * as source if it didn't start that way).
This could be further routed, but not to internet, as 192.168.0.0/16 is a reserved address. Presumably, 192.168.0.1 is a NAT router, and it would translate the local address+port to its own WAN ip and a different (connection unique) source port, and retranslate the reply back.

Since the target 192.168.0.3 matches 192.168.0.0/24, it would go directly to that network, via the same rule 2 above, and there routing would stop and ethernet takes over (presumably). Ethernet would send an arp request for 192.168.0.3 (assuming it wasn't already in the arp cache) and when it got a reply, send the packet directly to the destination with 192.168.0.2+local mac --> 192.168.0.3+reply mac.

The addresses 127.0.0.0/8 are unroutable and if the source starts with that, the packet will never leave the local machine. The source IP is in control of the application; it can bind a specific source IP, usually one of the host's interface ip's, but typically the source IP is left unbound by the application and will default to * with some (semi-)random port.

I think it can't go directly, because when I removed the gateway rule, ping didn't reach the target at first: `ping 192.168.0.3 Pinging 192.168.0.3 with 32 bytes of data: Reply from 192.168.0.2: Destination host unreachable. Reply from 192.168.0.3: bytes=32 time=5ms TTL=64` GIven that, how come the default route is selected when it's back? There is still `192.168.0.0/24` available - doesn't it apply because it was chosen the last time? — Jon, Jan 22 '23 at 10:23

Exact trace of outbound packet based on routing table

1 Answers1