VLAN IDと優先順位をebtablesと一致させます。

この説明は実際には意味がありませんが、カーネルにあります。linux/net/bridge/netfilter/ebt_vlan.c:

  if (GET_BITMASK(EBT_VLAN_ID)) {
      if (!!info->id) { /* if id!=0 => check vid range */
          if (info->id > VLAN_N_VID) {
              pr_debug("id %d is out of range (1-4096)\n",
                   info->id);
              return -EINVAL;
          }
          /* Note: This is valid VLAN-tagged frame point.
           * Any value of user_priority are acceptable,
           * but should be ignored according to 802.1Q Std.
           * So we just drop the prio flag.
           */
          info->bitmask &= ~EBT_VLAN_PRIO;
      }
      /* Else, id=0 (null VLAN ID)  => user_priority range (any?) */
  }

私が知る限り、コアebtablesの一方では、空でないVLAN ID（VID）を持つルールを受信するときにprio（PCP）フラグ/オプションが無視されるように強制します。 。回避策。

アカウントがなければ、公式の802.1Q文書を確認することは困難ですが、2005年版ではこのコメントの説明が見つかりませんでした。 VID = 0はPCPのみを意味することを知っていますが、PCPがVID = 0を意味するか、2つのパラメータ間に相互作用がないという意味ではありません（何も記録されていないことを意味します）。

メモ:nftablesそのような制限はありません。

nft add table bridge filter
nft add chain bridge filter forward '{ type filter hook forward priority -200; policy accept; }'
nft add rule bridge filter forward ether type vlan vlan id 5 vlan pcp 3 counter drop

提供された内容を返します（ここでは、リトルエンディアンとしてマークされたデバッグバイトコードを含む0x8100ではなく0x81など）。

# nft --debug=netlink list chain bridge filter forward -a
bridge filter forward 2 
  [ payload load 2b @ link header + 12 => reg 1 ]
  [ cmp eq reg 1 0x00000081 ]
  [ payload load 2b @ link header + 14 => reg 1 ]
  [ bitwise reg 1 = (reg=1 & 0x0000ff0f ) ^ 0x00000000 ]
  [ cmp eq reg 1 0x00000500 ]
  [ payload load 1b @ link header + 14 => reg 1 ]
  [ bitwise reg 1 = (reg=1 & 0x000000e0 ) ^ 0x00000000 ]
  [ cmp eq reg 1 0x00000060 ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 drop ]

table bridge filter {
    chain forward { # handle 1
        type filter hook forward priority -200; policy accept;
        vlan id 5 vlan pcp 3 counter packets 0 bytes 0 drop # handle 2
    }
}