Netdev List
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Swarm NameRedacted <thesw4rm@pm.me>
Cc: netdev@vger.kernel.org
Subject: Re: Packet not rerouting via different bridge interface after modifying destination IP in TC ingress hook
Date: Wed, 5 Aug 2020 15:39:22 +0200	[thread overview]
Message-ID: <20200805133922.GB1960434@lunn.ch> (raw)
In-Reply-To: <20200805081951.4iznjdgudulitamc@chillin-at-nou.localdomain>

On Wed, Aug 05, 2020 at 08:19:57AM +0000, Swarm NameRedacted wrote:
> Hi,
> 
> I am trying to build a quick script via TC direct action and eBPF to
> modify the destination IP of a packet so that it is routed through a
> different bridge interface. Made a quick network diagram below to
> demonstrate it. 
> 
>       Packet (dst: 10.10.3.2)
>                 |
>                 |
>     ingress - (change dst to 10.10.4.1)
>                 |
>                 |
>                eth0
>                 |
>                 |
>       br0 - (addr: 10.10.3.1)
> __eth0______   ___ens19_______
>      |                |
>      |                |
>      |                |
>      |                |
> host: 10.10.4.1  host: 10.10.3.2
> 
> 
> 
> As shown, I send a packet from a separate client to eth0. eth0 is the
> WAN interface of its machine and ens19 is the LAN interface; both are
> connecting with bridge br0. Without modification, the packet goes
> straight through ens19 to 10.10.3.2. 
> 
> Theoretically, by modifying the destination IP to 10.10.4.1 at ingress,
> the packet should be rerouted to go back through eth0. However, in
> practice, I find that the packet still goes through ens19 after
> modification, and of course after that it never reaches anything. 
> 
> Why is it that ingress catches the packet before the bridging decision,
> but the packet isn't rerouted? Is there a better way to do this?
 
What is not clear is the subnet size. Is this all a /16 network? So
that 10.10.4.1 and 10.10.3.2 are in the same subnet? Or are these
different subnets, and you have a router somewhere you do not show in
your diagram? Is this redirect happening at L2, or L3? Maybe you even
have NAT involved, since you talk about WAN and LAN? Do you also need
to be modifying the destination MAC address?

You also need to think about at what layer in the stack is the IP
address being modified? A bridge works on L2. Is the packet being
bridges at L2 and sent out without an IP processing at L3? Do you
actually want to be using ebtables to modify the packet at L2?

But maybe take a step back. You are wanting to do something really
odd. What is your real use case. Maybe there is a better way to do
what you want. Please explain why you want to send a packet back out
the way it came in, with a different IP address.

	 Andrew

  reply	other threads:[~2020-08-05 19:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  8:19 Packet not rerouting via different bridge interface after modifying destination IP in TC ingress hook Swarm NameRedacted
2020-08-05 13:39 ` Andrew Lunn [this message]
2020-08-05 20:12   ` Swarm NameRedacted
2020-08-06  6:33     ` Ido Schimmel
2020-08-06  7:00       ` Swarm NameRedacted
2020-08-06  7:49         ` Ido Schimmel
2020-08-06  8:33           ` Swarm NameRedacted

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=20200805133922.GB1960434@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=netdev@vger.kernel.org \
    --cc=thesw4rm@pm.me \
    /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