QinQ WS-6-MINI

[weiti]

Hi,

i read hopefully all related posts concerning QinQ, but i think there is at least some problems left. I would like to use a WS-6-Mini to interconnect my Virtualization Hosts with 2-3 L2 Environments and let them provide VM Services in every VLAN existing in all L2 Environments.

My thoughts are the following:

L2 Environment Home -> WS-6-Mini Port 2
L2 Environment TEST -> WS-6-Mini Port 3
Virtualization Host (with OpenVSwitch) -> WS-6-Mini Port 6

Adding VLAN 42 as Q on Port 2 and T on Port 6
Adding VLAN 43 as Q on Port 3 and T on Port 6

With this configuration i can see correctly tagged Pakets (outer 802.1ad, inner 802.1q) on my Virtualization Host (dumping on the eth1 Interface directly without OVS involved).
OVS is divided into 3 Bridges (QinQ, HOME, TEST) and is configured to remove outer VLANS on passing traffic to HOME/TEST Bridges, which works correctly (i see expected traffic on the HOME/TEST Bridges tagged with the correct 802.1q inner vlans).

I can also add a VM/Namespace to the HOME Bridge and see responing ARP replys which are leaving my Host with the correct Tagging (outer 802.1ad, inner 802.1q), but the netonix switch doesn't learn any mac addresses on the T Port 6.

I assume the T config doesn't allow double tagged pakets on ingress!? So the pakets are dropped/rejected ( I see a constantly increasing drop rate on RX (RX Drops increasing).

Is there a way to configure the WS-6-MINI to allow double tagged pakets on T Port ingress? In my scenario it needs to be a T Port, as both L2 Environments should be sumarized on Port 6 with double tagged packets ingress (from OVS) and egress (to corresponding Q Ports).

If i should deliver some drawings or informations, no problem, just reply.

Thanks for any help & regards,
tim

[mike99]

The T option allow VLAN (ingress and egress) based on the outer TAG without checking if it's a S-VID or C-VID.

Exemple, if you configure a port with T on VLAN 125, all VLAN or QinQ where the outer most tag is 125 will flow through the port. So yes, T allow simple and double tag.

A schema would help.

[weiti]

HI mike99,

thanks for the reply. Yes, that was my thought before i build the test environment. I draw a diagram to hopefully explain it better.
I see the correct pakets on the Linux Host/OVS Switches but the direction back seems to have some issues.


Regards,
tim

[mike99]

That seem right. Maybe make a pcap file with tcpdump on eth1 to check if QinQ header match on both side ?

[weiti]

Hi Mike,

i try to attach a dump on eth1 of the kvm host, but it seems the file extensions are not allowed.
You can find the pcap file here: https://vpn02.weiti.org/eth1.pcap
There is some overhead in the capture, but you can find arp request from 172.18.21.176 to 172.18.21.1 which are from a vm on the kvm host to a gateway in vlan 210 of the HOME L2 Network.

For short i add some lines of the dump here, when i try to ping from a vm/namespace in Vlan 210 on the kvm host. You see the
arp request but no reply:

Code: Select all

17:47:19.262685 1e:9e:1f:d7:37:1e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q-QinQ (0x88a8), length 50: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype ARP, Request who-has 172.18.21.1 tell 172.18.21.176, length 28


i try also to mirror Port 6 on the netonix, but there i don't see the qinq header as it is added on egress and i don't see any ingress pakets.

From my point of view, the headers are correct in both directions. Or did i miss something?

regards,
tim

[weiti]

Hi,

additional i capture one ping try from HOME L2 Environment, there you can see the reply, so the arp request is getting through the netonix/ovs to the vm/namespace:

Code: Select all

 

19:57:07.620650 2c:d4:44:ae:bd:b8 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q-QinQ (0x88a8), length 68: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype ARP, Request who-has 172.18.21.176 tell 172.18.21.6, length 46
19:57:07.620793 1e:9e:1f:d7:37:1e > 2c:d4:44:ae:bd:b8, ethertype 802.1Q-QinQ (0x88a8), length 50: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype ARP, Reply 172.18.21.176 is-at 1e:9e:1f:d7:37:1e, length 28

 

Also i see drops on port 6 of the netonix:

Rx Drops -> 595

they are increasing with every packet from the kvm linux host.

regards,
tim

[mike99]

I currently can't check those pcap but have you tryed an higher mtu than the default one ?

[weiti]

HI Mike99,

yes, i used 1600 MTU from day one on .. higher shouldn't be needed, i think.

regards,
tim

[weiti]

Any new thoughts?

I had no idea where the problem exists. Does someone had a scenario in place, where the 2 or more
netonix switches forward (bidirectional) qinq tagged traffic through a T Port and it actually works?

regards,
tim

[weiti]

Hi,

sorry, but i think the QinQ support on the Netonix WS-6-MINI is somewhere broken. I removed all OVS incorporations only two Q ports one way works i see the packets and the "correct" responses, but on the other side nothing reaches.

Can someone please give me some information, if QinQ (only on netonix switch (Q Port 1 in, Internal Transport as QinQ, Q Port 6 out)) works on any production/lab installations?

thanks,
tim