Link and network level in the tcp/ip stack

[Erik Nørgaard]

Hi:

This is a generic question about may, should and must:

I have the following setup:

    192.168.28/24
  +---------------+
  |.196		 |.1
SRV		GW--------- RN
  |.28		 |.1
  +---------------+
    10.225.162/24

The server, SRV, has default gateway set to 192.168.28.1, no routing has 
been configured for the 10.225.162/24 network. The gateway is a router, 
no NAT or firewall. Yup, we do have this setup, don't ask why.

Now, the remote node RN pings the server on 192.168.28.196 fine, no 
problem. Then it pings 10.225.162.28 and get destination unreachable.

OK, so I did tcpdump first on the 10.225.162.28 interface, and saw icmp 
echo requests coming in, but no replies going out. Then I did tcpdump on 
the other interface and got this:

13:39:43.233419 arp who-has 192.168.28.1 tell 10.225.162.28

obviously no reply, wrong network.

So, the system strips the link layer and completely forgets about it? 
with the added overhead of having to figure things out again to send a 
reply? Since the server also keeps an updated arp table it's not like 
the link layer is completely delegated to the nic to take care of.

For incoming connections, I would assume that the link address is 
preserved for replying, no need to send any arp requests. This also 
means that no routing would need to be defined on the 10.225.162.28 
interface to receive connections from non-local nodes.

What is the may/should/must protocol recommendation on this?

I can't figure whether keeping the link layer for the reply will 
introduce loop problems or rather solve them.

Thanks, Erik