Date: Fri, 06 May 2011 16:17:00 -0500 From: =?ISO-8859-1?Q?Erik_N=F8rgaard?= <norgaard@locolomo.org> To: questions@freebsd.org Subject: Link and network level in the tcp/ip stack Message-ID: <4DC4654C.2020902@locolomo.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DC4654C.2020902>