RE: [LARTC] Re: Routing that doesn't route

[Julian Anastasov <ja@ssi.bg>]

	Hello,

On Fri, 1 Mar 2002, Greg Scott wrote:

> > ip route add 172.16.0.0/20 via 172.16.16.3 dev eth1 src 172.16.16.1
>
> That's not really what I want to do.  I want everthing bound for the
> 0.0/20 subnet, no matter the source, to route thru 16.3.  16.1 is the

	Right, just test it. The src parameter has different purpose,
it is not a key for selecting the traffic, it is a result. It will
be used for traffic originated from the 16.1 box. OTOH, it is
difficult to pass non-negotiated traffic (subnets) through the
IPSec tunnel. Make sure you can really pass traffic with any
source through this tunnel. But this is different issue.

> That's why I think I'm looking at a kernel bug.  Note the physical
> path inside the Linux box.  The packet comes in eth1 and I want to
> sent it back out eth1.  I think that's the key.  I am trying to route
> a packet out the same interface on which it came in.

	Check the device flags I mentioned first.

> > 	If clearing all send_redirects and rp_filter flags to 0 and
> > using correct preferred source IP addresses does not help then you
> > hit a kernel bug. Try with recent kernel.
>
> But this all works well with similar testing using the 2.2 kernel on
> the other end.  It's the 2.4.2-2 kernel that ships with Red Hat 7.1
> giving me problems.

	ok, stop the ICMP redirects and see the difference.

> - Greg

Regards

--
Julian Anastasov <ja@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/