Hi, On Thu, Oct 31, 2019 at 02:41:00PM +0100, Lukas Wunner wrote: > Introduce a netfilter egress hook to complement the existing ingress hook. > > User space support for nft is submitted in a separate patch. > > The need for this arose because I had to filter egress packets which do > not match a specific ethertype. The most common solution appears to be > to enslave the interface to a bridge and use ebtables, but that's > cumbersome to configure and comes with a (small) performance penalty. > An alternative approach is tc, but that doesn't afford equivalent > matching options as netfilter. A bit of googling reveals that more > people have expressed a desire for egress filtering in the past: > > https://www.spinics.net/lists/netfilter/msg50038.html > https://unix.stackexchange.com/questions/512371 > > I am first performing traffic control with sch_handle_egress() before > performing filtering with nf_egress(). That order is identical to > ingress processing. I'm wondering whether an inverse order would be > more logical or more beneficial. Among other things it would allow > marking packets with netfilter on egress before performing traffic > control based on that mark. Thoughts? Would you provide some numbers on the performance impact for this new hook? Thanks.
