QinQ: system doesn't allow traffic through a default flow in case qinq flow is on the same port

[andriidovhan]

Steps to reproduce:

1. create a default flow
2. create a qinq flow on the same port(src: oVlan=10, iVlan=100 / dst: oVlan=10, iVlan=200)
3. try to send traffic trough default flow with vlan (src=10, dst=10)

Actual result: System is not allowing traffic through the defaultFlow with VLAN

[IvanChupin]

Actual result: System allow traffic through the defaultFlow with VLAN.

Steps to reproduce:

1) Created two flows:

[ { "flow_id": "flow1", "source": { "switch_id": "00:00:00:00:00:00:00:02", "port_number": 10, "vlan_id": 10, "inner_vlan_id": 15 }, "destination": { "switch_id": "00:00:00:00:00:00:00:09", "port_number": 10, "vlan_id": 0, "inner_vlan_id": 0 }, "status": "Up", "maximum_bandwidth": 1000, }, { "flow_id": "flow2", "source": { "switch_id": "00:00:00:00:00:00:00:02", "port_number": 10, "vlan_id": 0, "inner_vlan_id": 0 }, "destination": { "switch_id": "00:00:00:00:00:00:00:09", "port_number": 10, "vlan_id": 23, "inner_vlan_id": 123 }, "status": "Up", "maximum_bandwidth": 1000, } ]

2) Generate traffic:

generate traffic with lab_service-{number} Req: curl --location --request POST 'localhost:8288/api/1/traffgen/tg2/address' --header 'Content-Type: application/json' --data-raw '{
"address": "192.168.1.4/30", "vlan": 10
}' Res: {"address": {"prefix": 30, "address": "192.168.1.4", "idnr": "90bb8ffc-b23a-11ed-adc8-0242ac110002", "vlan": [10]}}

3) Send traffic

Req: curl --location --request PUT 'localhost:8288/api/1/traffgen/tg2/address/90bb8ffc-b23a-11ed-adc8-0242ac110002/lldp' --header 'Content-Type: application/json' --data-raw '{ "mac_address": "e4:1d:2d:a5:f3:ac", "port_number": "e4:1d:2d:a5:f3:ac", "chassis_id": "00:02:03:04:05:00", "time_to_live": 100 }' Res: {"lldp_push": {"sent_packets": 1}

4) Make sure that traffic has been sent correctly and matches with the right default rule.

There are two ways to check, first way is to use console:

Go to the lab_service container : docker exec -it lab_service-{number} bash show flow table: ovs-ofctl -O OpenFlow13 dump-flows ofsw2

cookie=0x800000000a000a, duration=2812.993s, table=1, **n_packets=1**, n_bytes=64, priority=24576,in_port="ofsw2-10",**dl_vlan=10 actions=pop_vlan**,write_metadata:0x100000a8/0xf000fff8,goto_table:2
 cookie=0x810000000a000d, duration=2812.993s, table=1, n_packets=0, n_bytes=0, priority=24576,in_port=13,dl_vlan=10 actions=pop_vlan,write_metadata:0x100000a8/0xf000fff8,goto_table:2
 cookie=0x8000000000000008, duration=109933.389s, table=1, n_packets=0, n_bytes=0, priority=1 actions=goto_table:2
 cookie=0x400000000001c2c9, duration=2812.993s, table=2, n_packets=0, n_bytes=0, reset_counts priority=24586,metadata=0x100000a8/0xf000fff8,in_port="ofsw2-10",dl_vlan=15 actions=meter:278,set_field:4698->vlan_vid,output:"ofsw2-3",goto_table:3
 cookie=0x40c000000001c2c9, duration=2812.993s, table=2, n_packets=0, n_bytes=0, reset_counts priority=24586,metadata=0x100a00a8/0xfffffff8,in_port=13,dl_vlan=15 actions=set_field:00:00:00:00:00:02->eth_src,set_field:00:00:00:00:00:09->eth_dst,set_field:4698->vlan_vid,output:"ofsw2-3"
 cookie=0x400000000000fb91, duration=2314.868s, table=2, **n_packets=1**, n_bytes=64, reset_counts priority=24575**,in_port="ofsw2-10"** actions=meter:2000,push_vlan:0x8100,set_field:4498->vlan_vid,output:"ofsw2-3",goto_table:3
 cookie=0x40c000000000fb91, duration=2314.868s, table=2, n_packets=0, n_bytes=0, reset_counts priority=24566,metadata=0x100a0000/0xffff0000,in_port=13 actions=set_field:00:00:00:00:00:02->eth_src,set_field:00:00:00:00:00:09->eth_dst,push_vlan:0x8100,set_field:4498->vlan_vid,output:"ofsw2-3"
 cookie=0x8000000000000009, duration=109933.390s, table=2, n_packets=0, n_bytes=0, priority=1 actions=drop

Second way: use openTSB (http://172.19.123.246:4242/) set the right filters:

There is no traffic for flow1:

There is some traffic for flow2, which is our default flow.

[rtretyak]

1. Lldp packets are kinda 'special' and in some cases could follow a special pipeline different from regular traffic.

2. The above screenshots show that we were able to receive and process the packet on ingress port, but there is no evidence that is was properly tagged and processed on the destination point

   The best way to test it and I assume the way it was tested originally is by using regular 'traffExam' procedure available in traffgens. Where instead of just sending lldp it would start a complete 'iperf' session on both ends of the flow. There's should be someone who has postman steps on how to do that. If not let me know I'll look for it

[niksv]

Thank you @rtretyak ! Also we can uncomment this test https://github.com/telstra/open-kilda/commit/dfbd1c26ba5e1c54719ef22c2b70dee02586528f#diff-dd9386e8e52860c5fe035095b97a3e3f85643ffd008cbe9bc064cc9ea3d1ae6aR140

[artHalMirantis]

@IvanChupin the behaviour of the bug is still actual