QinQ WS-6-MINI

[mike99]

It work from netonix to netonix. It's aslo been tested with other devices. Not sure which one but I remember TPID 8100 (ethertype / config VLAN "D") was request for compatibility with device that are not compatible with QinQ using TPID 88a8.

Looking at your pcap with Wireshark, "ethertype==qinq" or "ethertype==88a8" filter give me no result. It don't seem to have any QinQ encapsulation in this pcap while on above tcpdump, those are fujitsu devices MAC OUI while on your pcap, it's only pcengine, realtek and ubiquiti MAC OUI.

MIrroring of Netonix port 6 would be interesting to compare.

Did you replace the pcap file since then ?

[weiti]

Think Not. But I need to rebuild the setup as I had to test another scenario.

Will do the rebuild the next few days and then repost an updated dump.

[weiti]

Mike,

found some time to rebuild the tests and hopefully simplify the scenario and also provide correct pcap's.

First i reduced the test to only include some vlans on my production/home network, additional i changed the OVS config to strip 0x88a8 Headers on ingress so i work
on the OVS with the provided single tagged vlans (for example 210). On egress the 0x88a8 header are added.





I created two pcap files at the same time:

First one ( netonix-qinq-2019-06-23-mirror.pcap) from a mirror Port on the Netonix

Second one ( netonix-qinq-2019-06-23-ovs.pcap) on the uplink port (eth0) of the linux system

I tried to ping from Test Laptop (172.18.21.99/24) to test Namespace system (172.18.21.234/24) and you can see the packet in the OVS (Frame 15+16) and Mirror (Frame 17) Dump. On the Mirror Port you only see ARP Requests, no Replies. Also no MAC Learning on VLAN 42 for the Namespace System happen, as the reply doesn't arrive.

I tried to ping from test Namespace system (172.18.21.234/24) to Test Laptop (172.18.21.99/24) and you can see the packet in the OVS Dump (Frame 84) with correct headers (from my point of view).

With every ping i see an RX Drop on Port 5 on the Netonix, which brings me to the idea, that the packet is dropped by the Netonix, but for what reason!?

Additional, if i add my management connection to the netonix switch sometimes the QinQ Port seems to loose his functioning. I then see no packets in the Mirror/OVS Dumps. I remove the management connection (port 1, VLAN 1 U) the QinQ Function restores.

I can arrange access (https) to the netonix device if this helps.

regards,
tim

[mike99]

Edit: Strangely, wireshare can filter ethertype 88a8 on capture but if I look at the header, it's there, type ad 0x88a ID 42.
I don't see any problem and the answer except the ARP answer is 50 bytes. Could the Netonix drop all paquet under 64 bytes ?
Droping packets under 64 bytes would follow 802.3 original standard. Not sure if it was change later in an other standard.
Check OVS frame 15 and 16. The 15 (ARP resquest) is 64 bytes and the 16 (ARP answer) is 50 bytes.

[mike99]

I read a little more about it and frame under 64 bytes must be dropped. The phy of the device sending the ARP reply should pad the frame up to 64 bytes. From what kind of device is it originated ? The 0e:b4:8e OUI is unassign ? Is it a linux VM ? What kind of VM, KMV ? If so, what kind of driver for the KVM ?

Edit : Which version of openvswitch ? Seem like padded was not initially implemented and only added latter.
http://docs.openvswitch.org/en/latest/topics/design/
http://man7.org/linux/man-pages/man7/ovs-actions.7.html

[weiti]

Mike,

thanks for the information. Yes i saw the 50 byte reply but don't thought about the 64 byte limitation.

I use OpenvSwitch Version 2.10.1. The "Test System" is Linux Namespace on the OVS Host itself (which runs on Debians Testing/Buster/10.0).

Will look for an workaround ... but i think i tested it also with a RasperryPI as Test host and get the same error.

Thank you for your investigations.

Will inform on further testings.

regards,
tim

[weiti]

Quick Test with static ARP set, as arp replies are to small frames:

11:46:23.496423 0e:b4:8e:f6:d5:93 > f0:9f:c2:ce:fc:67, ethertype 802.1Q-QinQ (0x88a8), length 106: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype IPv4, 172.18.21.234 > 172.18.21.1: ICMP echo request, id 10130, seq 84, length 64
11:46:24.520417 0e:b4:8e:f6:d5:93 > f0:9f:c2:ce:fc:67, ethertype 802.1Q-QinQ (0x88a8), length 106: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype IPv4, 172.18.21.234 > 172.18.21.1: ICMP echo request, id 10130, seq 85, length 64

It seems that also "longer" pakets aren't processed correctly (i adder static arp entries on both sides).

11:48:09.261901 f0:9f:c2:ce:fc:67 > 0e:b4:8e:f6:d5:93, ethertype 802.1Q-QinQ (0x88a8), length 106: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype IPv4, 172.18.21.1 > 172.18.21.234: ICMP echo request, id 1157, seq 3, length 64
11:48:09.262232 0e:b4:8e:f6:d5:93 > f0:9f:c2:ce:fc:67, ethertype 802.1Q-QinQ (0x88a8), length 106: vlan 42, p 0, ethertype 802.1Q, vlan 210, p 0, ethertype IPv4, 172.18.21.234 > 172.18.21.1: ICMP echo reply, id 1157, seq 3, length 64

I hadn't full access currently to the netonix, will look on that again the next free time slot.

regards,
tim

[weiti]

Long time not working on this ... but now found some time.

I removed the complete config and upgraded firmware to 1.5.3 (just in case). Afterwards i configured two ports as Q and tested "normal" QinQ transport on the Netonix Mini which seems to work as expected. I can add my test system in any vlan i trunked into the QinQ Ports.

If i then changed one Q Port (Port6) to T, i see the correct transforming from 8021q tagged pakets to 8021ad tagged. But when i changed my configuration to 802.1ad plus 802.1q on the Test System, i see RX Drops on Port 6 and the communication doesn't work.

All dumps seem fine, what can be done?

regards,
tim