On 29/09/2020 17:06, Pablo Neira Ayuso wrote:
On Mon, Sep 28, 2020 at 09:35:00PM +0000, ѽ҉ᶬḳ℠ wrote:
Whilst testing NFTables's flow offload on a node with a PPPoE subscriber
line it turned out that the flow offload happens with the NIC netdev and not
(as I expected) the virtual PPPoE netdev.
Just for reference this being the NFT config (eth2 being the NIC)
flowtable fte {
hook ingress priority -100
devices = { eth2 }
counter
}
Could you describe your testbed?
The node being a router that may or may not (travelling) be on a xDSL
PPPoE subscriber line, which needs a bit of working around since nft
fails to init if the PPPoE netdev is in the config (netdev famility a/o
flowtable) but absent from the OS. For that purpose the workflow being:
* nft main conf file sans PPPoE (netdev famility a/o flowtable) when
booting the node
* loading a supplementary nft conf file in the event of PPPoE being up
with just PPPoE stanza for netdev and flowtable
Then monitored the logs about the flow offload and seen only entries for
flow offloads with the NIC but not PPPoE.
I suppose supplementing the main conf file is not such a good idea. Now
I copied the main conf file and added the PPPoE parts and getting that
file loaded in the event of PPPoE being up. Since then the logs showing
the offload with PPPoE working.
ip protocol { 6, 17 } flow add @fte;
ip6 nexthdr { 6, 17 } flow add @fte;
You can consolidate this rule with:
meta l4proto { tcp, udp } flow add @fte;
Thank you for the hint.
You might also want to use the existing protocol definitions, instead
of numeric protocols to make your ruleset more readable.
Why would the packet filtering have to take place on the PPPoE netdev but
the flowatable happens with the NIC instead?
What would you like to achieve with the flowtable?
