Page MenuHomeVyOS Platform
Create Task
Maniphest T2942

traffic-policy does not classify by VLAN
Needs testing, HighPublicBUG
Actions

Description

In Traffic Policy you configure traffic classes by defining some kind of matching criteria. One of those criteria can be VLAN ID. I have found several possible commands in VyOS CLI that could do the job (I am not sure what the differences of these commands should be) but in my tests none of them matched traffic by VLAN ID.

In my lab, traffic tagged with VLAN ID 40 was coming into eth1 interface.

set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth0 address '20.20.20.1/24'

set interfaces ethernet eth1 description 'LAN'
set interfaces ethernet eth1 address '192.168.10.254/24'
set interfaces ethernet eth1 address '192.168.20.254/24'
set interfaces ethernet eth1 vif 40 address '192.168.40.254/24'

set protocols static interface-route 192.168.0.0/16 next-hop-interface eth1
set protocols static route 20.20.20.0/24 next-hop 20.20.20.20

set traffic-policy shaper ASDF bandwidth '100kbps'
set traffic-policy shaper ASDF class 40 bandwidth '40%'
set traffic-policy shaper ASDF default bandwidth '2%'

set interfaces ethernet eth0 traffic-policy out 'ASDF'

Having the configuration above, none of the following 3 commands (nor any of their combinations) matched VLAN40 traffic:

set traffic-policy shaper ASDF class 40 match VLAN-MATCH interface 'eth1.40'
set traffic-policy shaper ASDF class 40 match VLAN-MATCH vif 40
set traffic-policy shaper ASDF class 40 match VLAN-MATCH ether protocol '802.1Q'

Tests done with both 1.2 and 1.3 versions, no difference.

Details

Version
1.2.x ; 1.3
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

Unknown Object (User) created this task.Oct 1 2020, 2:37 AM
pasik subscribed.Oct 1 2020, 9:21 AM
Unknown Object (User) added a comment.Oct 2 2020, 2:30 AM

We found one case when it does work (for both Crux and 1.3), which can lead to further investigation: when the policy is applied to a PPPoE client interface and the class traffic is matched with the command naming the subinterface (the first of the 3 options above).

The following examples work ok.

1.3:

set interfaces ethernet eth0 vif 40 address '192.168.40.254/24'
set interfaces pppoe pppoe0 access-concentrator 'asdf'
set interfaces pppoe pppoe0 authentication password 'asdf'
set interfaces pppoe pppoe0 authentication user 'asdf'
set interfaces pppoe pppoe0 source-interface 'eth1'
set interfaces pppoe pppoe0 traffic-policy out 'asdf'
set traffic-policy shaper asdf bandwidth '10Mbit'
set traffic-policy shaper asdf class 10 bandwidth '1Mbit'
set traffic-policy shaper asdf class 10 match VLAN interface 'eth0.40'
set traffic-policy shaper asdf default bandwidth '1kbit'
set traffic-policy shaper asdf default ceiling '100%'

Crux:

set interfaces ethernet eth0 vif 40 address '192.168.40.254/24'
set interfaces ethernet eth1 pppoe 0 password 'asdf'
set interfaces ethernet eth1 pppoe 0 user-id 'asdf'
set interfaces ethernet eth1 pppoe 0 traffic-policy out asdf
set traffic-policy shaper asdf bandwidth '10Mbit'
set traffic-policy shaper asdf class 10 bandwidth '1Mbit'
set traffic-policy shaper asdf class 10 match VLAN interface 'eth0.40'
set traffic-policy shaper asdf default bandwidth '1kbit'
set traffic-policy shaper asdf default ceiling '100%'

If we use the same examples above but, instead of applying the policy to a PPPoE interface, we apply it directly to an ethernet interface, then it fails to match VLAN traffic.

fegauthier subscribed.Oct 2 2020, 11:49 AM
dmbaturin changed the task status from Open to Needs testing.Jan 9 2024, 6:24 PM
dmbaturin triaged this task as High priority.
dmbaturin added a project: VyOS 1.4 Sagitta.
dmbaturin set Issue type to Unspecified (please specify).
Viacheslav edited projects, added VyOS 1.5 Circinus; removed VyOS 1.4 Sagitta, vyatta-cfg-qos.Apr 12 2024, 12:56 PM
talmakion subscribed.May 25 2024, 2:47 PM

Is this meant to be possible this way?

There is no tag on the interface where the tc is attached. The traffic in question has been brought in and routed so we have it at layer 3. This would be better done with a fwmark on the ingress and matching that on the egress?

I'd like to help with this one but I'm not sure how to approach it:

  • Should VyOS automagically handle a fwmark for ingress traffic? (I doubt it)
  • Should the qos policy doco make it clearer how the traffic match occurs? (I might be able to whip something up for this)
dmbaturin added a project: Restricted Project.Sep 16 2024, 4:15 PM
dmbaturin removed a project: Restricted Project.Oct 14 2024, 8:46 AM
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
dmbaturin changed Issue type from Unspecified (please specify) to Bug (incorrect behavior).
vyosbot added a project: Bugs.Oct 14 2024, 11:32 AM