mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Willy Tarreau <willy@w.ods.org>
To: jonathan@jonmasters.org
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: ipt_ROUTE loopback
Date: Thu, 17 Nov 2005 05:38:53 +0100	[thread overview]
Message-ID: <20051117043853.GH11266@alpha.home.local> (raw)
In-Reply-To: <35fb2e590511161901t7a615992s123a22cd8403511d@mail.gmail.com>

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


  reply	other threads:[~2005-11-17  4:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-17  3:01 Jon Masters
2005-11-17  4:38 ` Willy Tarreau [this message]
2005-11-17 13:52   ` Bill Rugolsky Jr.
2005-11-18  1:13   ` Jon Masters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051117043853.GH11266@alpha.home.local \
    --to=willy@w.ods.org \
    --cc=jonathan@jonmasters.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®