forwarding pings out ingress interface

forwarding pings out ingress interface

[Jeff Haran]

Running Redhat Enterprize 6.0, seeing the following behavior.

Two Ethernet network segments: 172.30/16 and 169.254.160/24.

Three "devices":

[linux] is the blade running RHEL6.0. It has multiple network interfaces
and has IP forwarding enabled.
[host] is an IP host of some sort.
[lb] is an L3 load balancer.

They are connected like so:

[host] 172.30.0.254 <-> 172.30.0.2 [lb] 169.254.160.20 <-> 169.254.160.1
[linux]

I have not shown the other network interfaces that [linux] is attached
to for brevity in the diagram.

One of the peculiarities of [lb] is if [host] pings it at 172.30.0.2, it
will not respond to the ping itself but instead forward the ping to
[linux]. I realize this is broken, but I have to deal with it (its
cooked into [lb]'s silicon). [lb]'s vendor assures me that if [linux]
would only forward the ping back to [lb] out the same interface it came
in on, then [lb] will generate a ping response back to [host].

My problem is [linux] won't forward the ping back to [lb]. [linux] has a
route to 172.30/16 out the interface that connects it to [lb] and I can
see from tcpdump that [linux] is getting the ICMP Echo requests with
source address 172.30.0.254 and destination address 172.30.0.2, but
nothing gets transmitted out that interface in response.

Now if I modify the route on [linux] to so that packets it receives that
are destined to 172.30/16 are forwarded out another of its network
interfaces, it forwards the pings out that interface just fine. It seems
like [linux] just doesn't want to forward pings it receives on a given
interface back out that same interface.

I am wondering if there is some switch under /proc or /sys that I need
to modify to get [linux] to forward the pings out the interface.
Is there such a thing that defaults to preventing this for security
reasons maybe?

In digging into this I discovered that /proc/1/net/stat/rt_cache was
reporting some non-zero statistics under the "in_martian_src" source
column. I figured maybe that [linux]'s stack was for some reason
determining that these pings were martians and dropping them so I
echo'ed 1 to log_martians. What I then see is a bunch of logs like this:

2011-06-01T17:55:51.103140-07:00 s01b01 kernel: martian source
169.254.160.7 from 169.254.160.6, on dev eth3
2011-06-01T17:55:51.103147-07:00 s01b01 kernel: ll header:
ff:ff:ff:ff:ff:ff:e4:1f:13:f6:60:d8:08:06

I don't know if this is related to the immediate ping problem, there are
other linux hosts on 169.254.160/24 that I've omitted from the diagram,
but I am truly perplexed at the lines beginning with "ll header".
Reading the code that generates these logs, ip_handle_martian_source()
in net/ipv4/route.c, it suggests that what is being shown in those "ll
header" lines is the MAC header of these packets it considers martians.

What is perplexing is that "08:06" at the end of the line. That's the
Ethertype for ARP, not IP. Why are ARP frames being treated as IP
packets? They shouldn't even be getting to ip_handle_martian_source() if
I am following the receive path correctly.

Just thought somebody on this list might have some insights into what I
am seeing here.

Thanks,

Jeff Haran
Bytemobile

Re: forwarding pings out ingress interface

[Nicolas de Pesloüan]

Le 02/06/2011 21:10, Jeff Haran a écrit :
> Running Redhat Enterprize 6.0, seeing the following behavior.
>
> Two Ethernet network segments: 172.30/16 and 169.254.160/24.
>
> Three "devices":
>
> [linux] is the blade running RHEL6.0. It has multiple network interfaces
> and has IP forwarding enabled.
> [host] is an IP host of some sort.
> [lb] is an L3 load balancer.
>
> They are connected like so:
>
> [host] 172.30.0.254<->  172.30.0.2 [lb] 169.254.160.20<->  169.254.160.1
> [linux]
>
> I have not shown the other network interfaces that [linux] is attached
> to for brevity in the diagram.
>
> One of the peculiarities of [lb] is if [host] pings it at 172.30.0.2, it
> will not respond to the ping itself but instead forward the ping to
> [linux]. I realize this is broken, but I have to deal with it (its
> cooked into [lb]'s silicon). [lb]'s vendor assures me that if [linux]
> would only forward the ping back to [lb] out the same interface it came
> in on, then [lb] will generate a ping response back to [host].
>
> My problem is [linux] won't forward the ping back to [lb]. [linux] has a
> route to 172.30/16 out the interface that connects it to [lb] and I can
> see from tcpdump that [linux] is getting the ICMP Echo requests with
> source address 172.30.0.254 and destination address 172.30.0.2, but
> nothing gets transmitted out that interface in response.

As per RFC3927, section 2.6.2 "[a] host MUST NOT send a packet with an IPv4 Link-Local destination 
address to any router for forwarding." Your linux host use 169.254.160/24, which is in the IPv4 
Link-Local range. So it is normal for your linux host not to reply to a ping request coming from 
outside of the local subnet.

Why do you use an IP in the link local range? For as far as I remember (but I failed to find the 
exact section), this RFC also forbid static configuration of an IP in this range.

	Nicolas.

RE: forwarding pings out ingress interface

[Jeff Haran]

> -----Original Message-----
> From: Nicolas de Pesloüan [mailto:nicolas.2p.debian@gmail.com]
> Sent: Thursday, June 02, 2011 12:47 PM
> To: Jeff Haran
> Cc: netdev@vger.kernel.org
> Subject: Re: forwarding pings out ingress interface
> 
> Le 02/06/2011 21:10, Jeff Haran a écrit :
> > Running Redhat Enterprize 6.0, seeing the following behavior.
> >
> > Two Ethernet network segments: 172.30/16 and 169.254.160/24.
> >
> > Three "devices":
> >
> > [linux] is the blade running RHEL6.0. It has multiple network interfaces
> > and has IP forwarding enabled.
> > [host] is an IP host of some sort.
> > [lb] is an L3 load balancer.
> >
> > They are connected like so:
> >
> > [host] 172.30.0.254<->  172.30.0.2 [lb] 169.254.160.20<->  169.254.160.1
> > [linux]
> >
> > I have not shown the other network interfaces that [linux] is attached
> > to for brevity in the diagram.
> >
> > One of the peculiarities of [lb] is if [host] pings it at 172.30.0.2, it
> > will not respond to the ping itself but instead forward the ping to
> > [linux]. I realize this is broken, but I have to deal with it (its
> > cooked into [lb]'s silicon). [lb]'s vendor assures me that if [linux]
> > would only forward the ping back to [lb] out the same interface it came
> > in on, then [lb] will generate a ping response back to [host].
> >
> > My problem is [linux] won't forward the ping back to [lb]. [linux] has a
> > route to 172.30/16 out the interface that connects it to [lb] and I can
> > see from tcpdump that [linux] is getting the ICMP Echo requests with
> > source address 172.30.0.254 and destination address 172.30.0.2, but
> > nothing gets transmitted out that interface in response.
> 
> As per RFC3927, section 2.6.2 "[a] host MUST NOT send a packet with an IPv4
> Link-Local destination
> address to any router for forwarding." Your linux host use 169.254.160/24,
> which is in the IPv4
> Link-Local range. So it is normal for your linux host not to reply to a ping
> request coming from
> outside of the local subnet.

Nicolas,

Thanks for the response, but what you are saying above is not the case. The source and destination IP addresses in the ping are both on the 172.30/64 net, which is routable. [linux] has assigned addresses in the link-local  local range to its own interfaces, but in this case I just want [linux] to forward the IP packet unmodified (except for decrementing the TTL and the MAC addresses before the IP packet, of course). Plus, as I mentioned above [linux] forwards these packets fine if I set to route to the 172.30/16 nets out another of its interfaces.

The issue seems to be related to forwarding a packet out the same interface it came in on, but I am guessing here.
 
> Why do you use an IP in the link local range? For as far as I remember (but I
> failed to find the
> exact section), this RFC also forbid static configuration of an IP in this range.
> 
> 	Nicolas.

Same reason everybody uses these things. These networks are on chassis backplanes and they are supposed to be hidden from the outside world, particularly we don't want the packets with 169.254 net addresses in them to get routed outside of those networks. The 169.254 network is the closest thing in IPv4 that comes to providing this functionality.

Jeff Haran