How do you set packet priority in the netdev table?

For Developers
1

Hi!

I want to change the kernel priority of DHCPv6 packets using nftables.

chain mangle_postrouting {
        type filter hook postrouting priority mangle; policy accept;
        oifname "eth1.832" udp dport 547 meta priority set 0:6
}

The above code works. This is a rule in the mangle_postrouting chain in the fw4 table.

table netdev filter
flush table netdev filter

table netdev filter {
        chain egress {
                type filter hook egress device eth1 priority filter; policy accept;
                udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for DHCPv6 packets"
        }
}

The above code fails to set the priority code point (PCP) in the VLAN tag 832. Nevertheless, the rule is applied since I can see in my tcpdump capture that the DSCP is correctly modified.

I really don't get it. DHCPv6 packets can be filtered with the two rules. One of the rules can modify PCP and DSCP while the other can only modify DSCP. Moreover, the rule in the netdev table is applied at the egress hook which is after the postrouting hook in the output path.

2

All works correctly. 2nd example does not touch vlans

3

@brada4

No, the rule in the netdev table should modify the kernel packet priority.

  table netdev filter {
        chain egress {
                type filter hook egress devices = { eth0, eth1 } priority 0;
                meta priority set ip saddr map { 192.168.10.2 : abcd:2, 192.168.10.3 : abcd:3 }
        }
  }

Source: Netfilter mailing list

Then, the kernel packet priority should be mapped to the PCP value 6 using egress-qos-map.

This works with the rule in the mangle_postrouting chain in the table fw4. So, I don't understand the issue.

4

eth1.832 vs eth1

5

I don't think so!

NETDEV ADDRESS FAMILY

The Netdev address family handles packets from the device ingress and egress path. This family allows you to filter packets of any ethertype such as ARP, VLAN 802.1q, VLAN 802.1ad (Q-in-Q) as well as IPv4 and IPv6 packets.

Source: man 8 nft

I can see in the tcpdump capture that the rules specified in the netdev table are applied to the 802.1Q frames.

6

Any ideas or explanations?

7

Documentation is scarce, probably you need to filter extra by 11Q VLAN, or use VLAN device as netdev.

8

Your posts contradict. One says wrong netdev sets pcp on other netdev while op says it is wrong that it does not.

9

You've misunderstood what I meant.

The nftables rule in the netdev family table is made up of several statements. One of these statements is intended to modify the PCP by changing the internal priority of DHCPv6 packets. The other statement in this rule modifies the DSCP of DHCPv6 packets. In my tcpdump capture, I see that the DSCP is correctly modified while the PCP remains unchanged. To check that I could modify the PCP, I removed this rule and then added a similar rule in the mangle_postrouting chain in the table fw4 (hook postrouting). In a new tcpdump capture, I can see that the DHCPv6 Solicit packets have their PCP and DSCP modified correctly.

10

vlans should be completely independent from main LAN.

11

I don't understand what you mean?

12

You expect eth0 netdev rule to alter eth0.835 traffic, it should never happen.

13

Yes, I do.

But I need an explanation so I sent a mail to the Netfilter mailing list.

14

Sorry, I have hard time understanding how your problem is related to OpenWRT or fw4:

  • you say fw4 works fine
  • netdev table you created does not work right, though you say once its worng it modifies vlan from base netdev, other time it is wrong that it does not.
  • hire secretary to do your post.
15

It's you who doesn't understand what I'm trying to say. You make me feel like I'm repeating myself all the time. I've already told you in numerous ways that my rule in the netdev family table applied to the eth1 device modifies the DSCP of packets encapsulated in 802.1Q frames. You assert, without ever substantiating your statement, that this is not possible. And then claim that I'm perpetually contradicting myself.

I don't know what my problem is exactly. Either I've misunderstood things and a note should be added to the nft manual page (Netfilter project). Or there's a bug in OpenWrt.

Things don't make sense to me. We can specify how to change the internal priority of packets. The documentation specifies that this can be done in order to define a correspondence between this priority and the PCP. It should also be recognized that the PCP is added to a frame via a VLAN tag.

16

The code is not intended to do that, if there is some ambiguity in what it does report bug to netfilter. If in doubt replay rule on RHEL and check outcome.

17

How do you explain that a Netfilter project developer can specify the internal priority of packets in a non-VLAN interface?

Logically, this internal priority is linked in some way to the packet encapsulated in a frame. If this frame is not an 802.1Q frame, how can we define a PCP? Would this frame be magically transformed into an 802.1Q frame?

18

Yes, if you add PCP it adds magically Q heading.

19

This still doesn't explain why or how the correspondence between internal priority and PCP becomes effective.

20

If we continue with this line of reasoning, it would be pointless to specify this internal priority if we couldn't modify the PCP by adding a VLAN tag.