Need help with QinQ

[troy]

Adding the first 2 VLANs and Trunk ports works great:



However, when I add my QinQ VLAN, I lose communication on ports 5-6.



I've also tried it with Port 4 set to Trunk, but no luck.

All 3 Trunk ports are set to carry VLAN 1-4095.

1) Management
2) Internet/Courtesy Port
3) Unused
4) UniFi AP (3 C-VLANs in S-VLAN 504)
5) Calix (needs all VLANs)
6) Rocket 5AC (needs all VLANs)

Any suggestions?

Thanks!

[Eric Stern]

You can try this firmware.

firmware/testing/wispswitch-1.4.7rc1.bin

[troy]

Tried it, no luck.

It's a minor thing for now, but hopefully we'll get it working in an upcoming release.

Thanks!

[petecarlson]

Lets say you have two netonix switches connected together on trunk ports. Say T504 and T79. If you tag another port on one of the switches Q 504, the trunk will stop passing traffic. If you then tag Q 504 on one of the ports on the other switches, the trunk will start passing traffic again. Both single tagged 0x8100 and double tagged 0x88a8.0x8100 frames pass correctly.

It would seem that the switch is changing the behavior of any trunk port which includes a Q VLAN in such a way that it makes it incompatible with another switches trunk port that does not yet contain a Q VLAN so it isn't really the same as T anymore, perhaps QT. I am guessing that the switch changes the ethertype, without telling you, on any trunk port that contains a vlan that is set to Q somewhere on the switch.

Not sure what Calix gear you are connecting to, but the E7-2 default ethertype on a trunk port is 0x8100. You can change it to 0x88a8 and see if it works but I'm not sure what that would do to your other single tagged 0x8100 vlans. I have an E7-2 racked in my lab and will test it out when I have time.

The long and short of it is that most (all?) gear will pass double tagged 0x8100 packets the same way they pass single tagged 0x8100 packets but in order to bridge 0x88a8.0x8100 packets the gear needs to support that and I don't think airmax does so your rocket link won't work.

Chris mentioned on my other post that there is new rc firmware coming out that supports double tagging. Not sure if he meant double tagging 0x8100 (PLEASE PLEASE PLEASE) or if he meant being able to add an S tag(0x88a8) and a C tag (0x8100) to and interface. If it is the former, it should solve your problem.

[brianblac]

I have this same problem, setting any port to Q causes loss of connectivity to the switch.

Same results with latest firmware and latest RC.

[sirhc]

There is nothing wrong with QinQ as several other people that I have seen on this forum are using it fine.

We are adding more configuration options for VLANs such as most recently "D" (Double Tagged) for some specific requests by other users.

But you can not just change a U or T to Q and have it work unless the device you are connected to is properly setup for QinQ

We did not write the QinQ function, it is a function of the switch core, and the switch core programing is written by Vitesse the chip/switch core maker which is owned by Microsemi which is one of the largest semiconductor manufacturers in the world.

All we write is the interface (UI and CLI) that sets up your requested configuration and the parts that control the MOSFETs and Current Sensors, SNMP, Stats, and such.

The VSC-7427 switch core is a mature product by Vitesse (over 5 years old) and is used in many other switches on the market.

[brianblac]

It would seem that the switch is changing the behavior of any trunk port which includes a Q VLAN in such a way that it makes it incompatible with another switches trunk port that does not yet contain a Q VLAN so it isn't really the same as T anymore, perhaps QT. I am guessing that the switch changes the ethertype, without telling you, on any trunk port that contains a vlan that is set to Q somewhere on the switch.

I agree with what Pete is saying above, I have never seen a behavior like this which is why I asked, in a lot of scenarios there could be any number of switches between the Netonix and whichever switch is at the far end doing the other end of the qnq.

I have never seen a switch that you cant put a port in qnq mode and have the switch just carry that tag out of its trunk port to go down the line. It shouldnt affect the already functioning traffic / tags of the trunk interface - the qnq traffic should just travel out of the trunk with its newly encapsulated tag.

I hope I am making sense here. Thanks for the response.

By the way, with your new double tagged feature being 0x8100 I can accomplish what I need to by matching that ethertype on the upstream switch that is doing the other side of the qnq, I've tested it and it works great. The above question is more of a curiosity at this point.

[brianblac]

I made a development here, for some reason if I move the QnQ vlan up the list directly underneath the management vlan it all works.

If I have the QnQ vlan third in the list I lose connectivity to the device. I sent Troy a PM hoping he will try it also.

I was able to replicate the issue in the latest release and latest RC.

[troy]

Good reading and I think I know what/where the problem is. Calix defaults to using 0x8100 for the outer tag.

Our gateway (MikroTik) had no problem with this either, as it also uses 0x8100 by default:

Code: Select all

 /interface vlan
add interface=ether2 name=ether2.504 vlan-id=504
add interface=ether2.504 name=ether2.504.3 vlan-id=3
add interface=ether2.504 name=ether2.504.4 vlan-id=4

So, I guess I need to get with Calix or wait for Netonix to implement the new "D" feature before I can use Netonix switches for breaking out double tagged vlans on our network.

[brianblac]

Troy, the D feature already works on the latest RC, I've tested it with multiple other switches now.