All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
	bart.de.schuymer@pandora.be, stephen@networkplumber.org,
	pablo@netfilter.org, kaber@trash.net,
	netfilter-devel@vger.kernel.org
Subject: Re: team driver MAC NAT
Date: Tue, 12 Feb 2013 10:12:15 -0500	[thread overview]
Message-ID: <511A5BCF.20907@mojatatu.com> (raw)
In-Reply-To: <20130212140247.GB18057@minipsycho.orion>

Jiri,

This would be a good fit for  a tc action. This way such a feature can be
used by other netdevs (including plain bridge, and not just team)
The main question is how does the tc action learn about the MAC
addresses that
it needs to convert.

cheers,
jamal

On 13-02-12 09:02 AM, Jiri Pirko wrote:
> Hi all.
> 
> I have following situation:
> 
> host X  .............  eth0 -> br0 <- team0 <- eth2  ..............  switch  .........  host Z
> host Y  .............  eth1 ---^         ^---- eth3  .................^
> 
> Now to achieve RX traffic balancing on team0, I have to mangle src mac of
> all outgoing packets. If the packet goes through eth2, src mac will be set to
> eth2 mac, same happens on eth3. I have to magle ARP packets as well.
> 
> This would achieve something which might be called "MAC NAT".
> 
> To unmangle RXed packets back to the original MAC adresses (of host X and host Y)
> I need to track "connections".
> 
> Now the question is: Should this be integrated in netfilter infrastructure?
> I'm thinking something similar to existing conntrack. NF_HOOK will be placed
> in team driver rx/tx functions (similar to what bridge does).
> 
> I think this would be nicer than to do it independently just in team driver code.
> Also this MAC NAT (with tracking connections, unlike what bridge MAC NAT does)
> can be probably handy for other purposes as well (not sure what)
> 
> Thanks for any suggestions.
> 
> Jiri
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      reply	other threads:[~2013-02-12 15:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 14:02 team driver MAC NAT Jiri Pirko
2013-02-12 15:12 ` Jamal Hadi Salim [this message]

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=511A5BCF.20907@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=bart.de.schuymer@pandora.be \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiri@resnulli.us \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=stephen@networkplumber.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.