Message-ID: <6F5DE7538AFCDA45A114F5E7510424A7027D839E@hq-exchange01.bytemobile.com>
Date:	Thu, 2 Jun 2011 13:33:04 -0700
From:	"Jeff Haran" <jharan@...emobile.com>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	<netdev@...r.kernel.org>
Subject: RE: forwarding pings out ingress interface

> -----Original Message-----
> From: Nicolas de Pesloüan [mailto:nicolas.2p.debian@...il.com]
> Sent: Thursday, June 02, 2011 12:47 PM
> To: Jeff Haran
> Cc: netdev@...r.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



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists