DSCP values are dropped on egress

[rr-santos]

Expected Behavior

Whenever packets marked with a DSCP value arrive to the switch its value should be preserved on egress, if there are no specific forwarding rules that explicitly change this behavior.

Actual Behavior

Packets marked with a DSCP value have their DSCP value set to 0 on egress.

Steps to Reproduce the Problem

Switch configuration

On the switch, configure a bridge with two ports:

ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 1
ip link set port7 master swbridge
ip link set port8 master swbridge
ip link set swbridge up
ip link set port7 up
ip link set port8 up

Server

In this example, enp8s0f0np0 is connected to port7 and enp8s0f1np1 to port8 on the switch, respectively.

Terminal 1

Install iperf3, setup 2 namespaces, assign IP addresses. and start iperf3 server on ns0:

apt install iperf3 -y
ip netns add ns0
ip netns add ns1
ip link set enp8s0f0np0 netns ns0
ip netns exec ns0 ip a a 192.51.0.2/24 dev enp8s0f0np0
ip netns exec ns0 ip link set enp8s0f0np0 up
ip link set enp8s0f1np1 netns ns1
ip netns exec ns1 ip a a 192.51.0.1/24 dev enp8s0f1np1
ip netns exec ns1 ip link set enp8s0f1np1 up
ip netns exec ns0 iperf3 -s

Terminal 2

Start traffic capture on ns0:

ip netns exec ns0 tcpdump -venli enp8s0f0np0

Terminal 3

Start traffic capture on ns1:

ip netns exec ns0 tcpdump -venli enp8s0f1np1

Terminal 4

Start iperf3 client on ns1 setting the DSCP value with the --dscp option:

ip netns exec ns1 iperf3 -c 192.51.0.2 -t 1 --dscp 10

Observable results

The terminal capturing traffic on ns0 will show the DSCP value set to 0 on all packets. On ns1, it is possible to observe the configured value on the tos field:

Terminal 2

ethertype IPv4 (0x0800), length 42058: (tos 0x0, ttl 64, id 1207, offset 0, flags [DF], proto TCP (6), length 42044)
    192.51.0.1.53068 > 192.51.0.2.5201: Flags [P.], cksum 0x2499 (incorrect -> 0xe92a), seq 1118429446:1118471438, ack 1, win 502, options [nop,nop,TS val 1037566304 ecr 3609952640], length 41992
ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 14871, offset 0, flags [DF], proto TCP (6), length 52)
    192.51.0.2.5201 > 192.51.0.1.53068: Flags [.], cksum 0x8090 (incorrect -> 0xfd89), ack 1118471438, win 24557, options [nop,nop,TS val 3609952640 ecr 1037566304], length 0

Terminal 3

ethertype IPv4 (0x0800), length 63778: (tos 0x8, ttl 64, id 22415, offset 0, flags [DF], proto TCP (6), length 63764)                                                    
    192.51.0.1.53068 > 192.51.0.2.5201: Flags [P.], cksum 0x7971 (incorrect -> 0xbc23), seq 960328118:960391830, ack 1, win 502, options [nop,nop,TS val 1037566171 ecr 3609952507], length 63712  
ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 11531, offset 0, flags [DF], proto TCP (6), length 52)                             
    192.51.0.2.5201 > 192.51.0.1.53068: Flags [.], cksum 0x2278 (correct), ack 960391830, win 24557, options [nop,nop,TS val 3609952507 ecr 1037566171], length 0                                    

Specifications

• Version: BISDN Linux 3.7.1
• Platform: accton-as4610 and agema-ag5648
• Subsystem:

[hwoesner]

If you google for 'DSCP trust' you will find various discussions around this. Apparently there is a general configuration that a switch removes DSCP bits while a router should pass them unchanged.
So it may be more of a missing feature, or a broader discussion if there should be a "default switch" or "default router" configuration in BISDN Linux.
The "default switch" would then, for instance, create the swbridge and bind ports to it, while the "default router" would pre-configure router settings like the above.

[rr-santos]

I guess the points here would then be 1) document that BISDN Linux comes with this DSCP trust feature disabled by default, and 2) have DSCP trust configurable in the switch as a feature. Still, I do find odd that a plain L2 bridge configuration ends up with this behavior by default.