ipt_ROUTE loopback

ipt_ROUTE loopback

[Jon Masters]

Folks,

I'm trying to find an easy way to have a Linux box completely ignore
the local routing table and have traffic destined for one interface go
out of a loopback cable and back into the other rather than traversing
the local routing within the host, viz:

eth0
x.x.x.x
   |
   | <--- loopback cable
   |
eth1
y.y.y.y

This is completely against normal practice, but useful for test. I've
so far tried playing around with iproute2 and have this evening built
up ipt_ROUTE, which seems more promising. I can get traffic forced out
of the "correct" interface and bypass the local routing table, but it
always has the destination MAC of the first interface when it reaches
the second.

So, I can bodge the destination MAC (I'm still deciding how to do that
- maybe I'll take apart ipt_ROUTE and have it do MAC rewriting too)
but I'm curious as to whether there's a "right" way to do this that
I've so far missed? I've considered using the briding code in some
weird kind of transparent-yet-not-really bridge setup, but I don't
really want to do that.

Any suggestions? This seems like something others must have also
wanted to do. I'm happy to break things in doing it, but I'm hopeful
for a "you missed this page...".

Jon.

Re: ipt_ROUTE loopback

[Willy Tarreau]

On Thu, Nov 17, 2005 at 03:01:46AM +0000, Jon Masters wrote:
> Folks,
> 
> I'm trying to find an easy way to have a Linux box completely ignore
> the local routing table and have traffic destined for one interface go
> out of a loopback cable and back into the other rather than traversing
> the local routing within the host, viz:
> 
> eth0
> x.x.x.x
>    |
>    | <--- loopback cable
>    |
> eth1
> y.y.y.y
>
> This is completely against normal practice, but useful for test. I've
> so far tried playing around with iproute2 and have this evening built
> up ipt_ROUTE, which seems more promising. I can get traffic forced out
> of the "correct" interface and bypass the local routing table, but it
> always has the destination MAC of the first interface when it reaches
> the second.
> 
> So, I can bodge the destination MAC (I'm still deciding how to do that
> - maybe I'll take apart ipt_ROUTE and have it do MAC rewriting too)
> but I'm curious as to whether there's a "right" way to do this that
> I've so far missed? I've considered using the briding code in some
> weird kind of transparent-yet-not-really bridge setup, but I don't
> really want to do that.
> 
> Any suggestions? This seems like something others must have also
> wanted to do. I'm happy to break things in doing it, but I'm hopeful
> for a "you missed this page...".

You missed this page...  :-)

You need to use Julian Anastasov's "send-to-self" patch from ssi.bg/~ja/.
The problem is not with ipt_route, but with the local addresses. If you
want the packet to go out, you need to remove the local route for the
destination. The packet will then go out, but when it will come back,
the system won't take it because its destination won't match a local
route. Try "ip r l t local" to see what I mean.

With Julian's patch, IIRC, you write '1' into /proc/sys/net/ipv4/$IF/loop,
then you define some cross-routes for destinations with the respective
sources from the opposite interfaces, then all packets routed out with
a 'looped' interface address in their source will effectively go out.

I also suggest that you get his whole '-ja' patch, and that you look
in Documentation/networking/ip-sysctl.txt in which he adds some
documentation about this (and I believe there was a more complete
example on his site).

Good luck,
Willy

Re: ipt_ROUTE loopback

[Bill Rugolsky Jr.]

On Thu, Nov 17, 2005 at 05:38:53AM +0100, Willy Tarreau wrote:
> You need to use Julian Anastasov's "send-to-self" patch from ssi.bg/~ja/.
> The problem is not with ipt_route, but with the local addresses. If you
> want the packet to go out, you need to remove the local route for the
> destination. The packet will then go out, but when it will come back,
> the system won't take it because its destination won't match a local
> route. Try "ip r l t local" to see what I mean.
> 
> With Julian's patch, IIRC, you write '1' into /proc/sys/net/ipv4/$IF/loop,
> then you define some cross-routes for destinations with the respective
> sources from the opposite interfaces, then all packets routed out with
> a 'looped' interface address in their source will effectively go out.
> 
> I also suggest that you get his whole '-ja' patch, and that you look
> in Documentation/networking/ip-sysctl.txt in which he adds some
> documentation about this (and I believe there was a more complete
> example on his site).

I've used Julian's patch; it worked fine.  But while trying to debug some
issues with a 4xE1/T1 card, I had to do external loopback with an
unpatched 2.4 kernel.  IIRC, the following did the trick:

for p in 0 1
do
   /sbin/ip link set dev hdlc$p up multicast on
   /sbin/ip addr add dev hdlc$p local 192.168.$p.1 peer 192.168.$p.2
   echo 0 > /proc/sys/net/ipv4/conf/hdlc$p/rp_filter
done

# Trick the kernel into sending the packets over the wire
/sbin/iptables -t mangle -F
/sbin/iptables -t nat -F
/sbin/iptables -t nat -A POSTROUTING -d 192.168.0.2 -j SNAT --to 192.168.1.2
/sbin/iptables -t nat -A POSTROUTING -d 192.168.1.2 -j SNAT --to 192.168.0.2
/sbin/iptables -t nat -A PREROUTING -t nat -d 192.168.1.2 -j DNAT --to 192.168.0.1
/sbin/iptables -t nat -A PREROUTING -t nat -d 192.168.0.2 -j DNAT --to 192.168.1.1

To test, send traffic to either 192.168.0.2, or 192.168.1.2, e.g.,

    ping -T tsandaddr 192.168.0.2

Regards,

	Bill Rugolsky

Re: ipt_ROUTE loopback

[Jon Masters]

On 11/17/05, Willy Tarreau <willy@w.ods.org> wrote:

> You missed this page...  :-)

Excellent, as I hoped.

> You need to use Julian Anastasov's "send-to-self" patch from ssi.bg/~ja/.
> The problem is not with ipt_route, but with the local addresses. If you
> want the packet to go out, you need to remove the local route for the
> destination. The packet will then go out, but when it will come back,
> the system won't take it because its destination won't match a local
> route. Try "ip r l t local" to see what I mean.

Yes. But the ROUTE target could also do this if I hacked up its route
function. I realised the problem was in the local routing table (as I
mentioned earlier) but it looks like this patch will save me
re-implementing yet another wheel.

Cheers,

Jon.