Re: RFC: Disable defered bridge hooks by default

[Patrick McHardy <kaber@trash.net>]

Amin Azez wrote:
> Intercepting some traffic types and sending them via alternate gateways,
> (i.e. VPN gateways if the VPN is up) for errr... people who don't want
> to change the network default gateway for the whole network; also, for
> managing certain services for multi-subnet'd segments. I guess its part
> of the fashion to do things in layer2 these days as it involves less
> infrastructure change. For them.
> 
> I think Philip was right and my slight suggestion is wrong; I can't
> "look ahead" as ebtables would need to process the "look ahead" also,
> and influencing the look ahead (as well as counting the look-ahead packets)
> 
> I think cracking open the bridge code to fit the same model as the ip
> routing code, so it works out how to bridge it at just the same point
> the routing code calculates a route and then output device; but saves
> the answer for later when the final hooks have been traversed.

The routing code shouldn't know anything about the bridge FDB.

> I think if ebtables becomes the answer it will just grow to be as big as
> iptables with all the extra matches iptables has, just as iptables has
> extra -p tcp and -p udp matches.

Thats where MARK will be useful, but only if the target is available
in ebtables. SNAT based on bridge port won't be possible anymore.