[nftables] packet (filtering) flow NIC vs. PPPoE?

[nftables] packet (filtering) flow NIC vs. PPPoE?

[ѽ҉ᶬḳ℠]

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
}

ip protocol { 6, 17 } flow add @fte;
ip6 nexthdr { 6, 17 } flow add @fte;


Why would the packet filtering have to take place on the PPPoE netdev 
but the flowatable happens with the NIC instead?

Re: [nftables] packet (filtering) flow NIC vs. PPPoE?

[ѽ҉ᶬḳ℠]

On 28/09/2020 23:35, ѽ҉ᶬḳ℠ 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
> }
>
> ip protocol { 6, 17 } flow add @fte;
> ip6 nexthdr { 6, 17 } flow add @fte;
>
>
> Why would the packet filtering have to take place on the PPPoE netdev 
> but the flowatable happens with the NIC instead?
>

Is this perhaps due to:

nft_flow_offload -> NDO hook

utilising the NIC's hardware flow tables?  If so how is the NIC's 
flow-table capability transparent to the user, querying the NIC with 
ethtool for 'flow' does not produce anything.

Re: [nftables] packet (filtering) flow NIC vs. PPPoE?

[Pablo Neira Ayuso]

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?

> 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;

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?

Re: [nftables] packet (filtering) flow NIC vs. PPPoE?

[ѽ҉ᶬḳ℠]

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?