[ovs-discuss] Issue with double tagged packets

Tony van der Peet Tony.vanderPeet at alliedtelesis.co.nz
Tue Feb 26 01:29:30 UTC 2019


Hi all

I would like some help with an issue with double tagged packets. I have reviewed the mailing list archive but didn't see anything relevant.

Here is my rules table:

duration=3189s, n_packets=1, n_bytes=500, priority=1000,dl_vlan=10,actions=pop_vlan,write_metadata:0xa/0xffff,goto_table:1
duration=3186s, n_packets=0, n_bytes=0, priority=0,actions=drop

table_id=1, duration=3188s, n_packets=0, n_bytes=0, priority=1000,vlan_tci=0x1000/0x1000,actions=drop
table_id=1, duration=3187s, n_packets=1, n_bytes=500, priority=900,metadata=0xa,
  actions=push_vlan:0x8100,set_field:4106->vlan_vid,push_vlan:0x88a8,set_field:4406->vlan_vid,output:2

table_id=254, duration=3317s, n_packets=0, n_bytes=0, priority=2,recirc_id=0,actions=drop
table_id=254, duration=3317s, n_packets=0, n_bytes=0, priority=0,reg0=0x1,actions=controller(reason=)
table_id=254, duration=3317s, n_packets=0, n_bytes=0, priority=0,reg0=0x2,actions=drop
table_id=254, duration=3317s, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop

The intention is that single tagged packets get sent to port 2, but double tagged packets get dropped.

However, when I send a packet whose debug (dp_netdev_upcall) is as follows:

skb_priority(0), skb_mark(0), ct_state(0), ct_zone(0), ct_mark(0), ct_label(0), recirc_id(0), dp_hash(0),
in_port(4), packet_type(ns=0,id=0),
eth(src=00:00:ee:01:01:01,dst=00:4d:23:23:fd:bc),
eth_type(0x88a8), vlan(vid=10,pcp=0), encap(eth_type(0x8100))
dl_vlan=10, dl_vlan_pcp=0, vlan_tci1=0x0000, dl_src=00:00:ee:01:01:01, dl_dst=00:4d:23:23:fd:bc, dl_type=0x8100

you will see from the above counters that the packet is actually forwarded, even though it's double tagged.

In other words, the priority 1000 rule in table 1 does not appear to be noticed.

Here is what the dpif flow looks like:

recirc_id(0),in_port(4),packet_type(ns=0,id=0),eth_type(0x88a8),vlan(vid=10,pcp=0),encap(eth_type(0x8100)),
packets:0, bytes:0, used:never, actions:pop_vlan,push_vlan(vid=10,pcp=0),push_vlan(tpid=0x88a8,vid=310,pcp=0),2

I am running code from the master branch as of 31/Dec/2018.

Questions:

1 - Does my rules table look like a plausible thing to expect to work in OpenFlow?
2 - Would you also expect this to work in Open vSwitch?
3 - I suspect that if there is an issue with this scenario, it's just something overlooked in implementing QinQ.

- Is it likely to be something we could fix easily in Open vSwitch?

- Or is the code just not structured in a way that would lend itself to a fix?


(I ask this because my initial investigations show that at the point where the debug is obtained, flow match information appears to be determined but the actions in the flow haven't yet been addressed, which makes me wonder if this is an easy fix at all).

I would like to make this work, but on the other hand, I can probably avoid the need for this sort of check, so it's not super critical for me.


And I will keep debugging and trying to work this out, but I suspect it could be something quite deep...

Any help appreciated.

Cheers
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190226/c256ba80/attachment.html>


More information about the discuss mailing list