WS-12-250-DC: QinQ crash, MAC Table refresh hang

[sirhc]

I tested it with a second Netonix switch, same problem. Please take a few minutes to reproduce it, there seems to be a bug in the firmware. When adding a QinQ vlan to a mixed port, that is also used for managment, I leads to loss of connection/revert.

- Port 14: Management vlan (1) untagged, other vlans tagged.
- Port 3: Vlan 123 "Q", port 14 "T"

Then save and access is lost until the switch reverts.

I will ask Eric to verify if the revert is not working with QinQ VLAN changes.

I already said I will ask Eric to look to see if revert is broken on making a QinQ change? It might actually take a day or 2 to look into it.

Then save and access is lost until the switch reverts.

Are you saying it "does" or "does not" revert to the previous config when you make a change to "Q" on the VLAN Tab after the allotted time out?

[RSENG-Eric]

Even if this issue could never be solved, the WISP switch is still a far superior product to anything that the other guys make and abandon after the second software revision!

It is normal to pass QinQ VLANs as tagged between switches. The intermediate switches do not usually look further than the first tag, so if the MTU is configured for the extra overhead, it will forward normally through the switch.


We use QinQ ports on Cisco ME3400 switches and Calix switches regularly. This is a simple snippet of how this works on a cisco:

vlan 3
name HeartlandRing
!
vlan 12
name DeSoto
mtu 1600
!
vlan 18
name Highlands
mtu 1600
!
vlan 60
name Nomadix
!
interface GigabitEthernet0/1
description PTP800 to **** MGMT
switchport mode access
switchport access vlan 18
!
interface GigabitEthernet0/11
description UB PTP to ****
port-type nni
switchport trunk native vlan 3
switchport trunk allowed vlan 3,12,18,60
switchport mode trunk
!
interface GigabitEthernet0/13
description Netonix Port 1
port-type eni
switchport access vlan 18
switchport mode dot1q-tunnel
!
interface GigabitEthernet0/16
description PTP800 to ****
port-type nni
switchport trunk native vlan 3
switchport trunk allowed vlan 3,12,18,60
switchport mode trunk
!
interface Vlan3
ip address 10.13.3.65 255.255.255.0
no ip route-cache
!

[cegner]

For me, it _does_ revert. But I don't get why I loose access at all. It's seems to be a bug.

[sirhc]

For me, it _does_ revert. But I don't get why I loose access at all. It's seems to be a bug.

Its not a bug, you lose access because something is configured wrong and it reverts after the specified period to the previous config as designed.

I am not sure why you do not understand that if the network and switch are responding correctly and then you change a U to a Q that other changes will have to take place on other equipment talking to the switch before it will function correctly again?

Changing a U or T to a Q on a port is big change in VLAN topology and will require other changes to occur with the equipment on either end of the switch to function properly.

If the port was a U and now is a Q the behavior of how packets are handled changes vastly.

If it was a U the port expected to receive Untagged packets but now as Q if it receives a packet which could be Untagged or Tagged it will encapsulate it within an outer VLAN Tag.

If it was a U the port stripped all VLAN Tags off when packets leave the port but now as a Q it will only strip off the outer Tag leaving a second inner Tag intact if one exists or simply pass a now non tagged packet.

If it was a T the port would only accept Tagged packets with the proper VLAN ID but now as a Q it will accept ALL packets and encapsulate them inside a VLAN Tag, if it was already a Tagged VLAN packet it is now nested under the new outer VLAN packet ID.

If it was a T then packets leaving the port would be left intact with their VLAN Tag(s) but now as a Q it will strip the outer VLAN Tag leaving either a simple 802.1q VLAN Tag or an Untagged packet if it was not a nested VLAN or QinQ.

So when changing a T or U to a Q it REQUIRES configuration changes to occur to devices on either side of the switch to now deal which what is going to happen to the packets as the behavior has completely changed.

[sirhc]

Here, read from this post on QinQ by Mike99 who was bench testing QinQ when we first released it to insure it worked and he understood how to use it.

viewtopic.php?f=6&t=974&p=7508&hilit=QinQ#p7465

I would suggest doing as Mike99 did and BENCH TEST your configuration before trying to implement it on a live tower.

If your working on a bench you can DISABLE the Revert feature on the Device/Configuration Tab to give yourself time to make other changes to other equipment.

[cegner]

I am well aware about how QinQ works and it's already implemented in our network with Juniper, Cisco and Mikrotik equipment.
As you keep telling me that it is not a bug but incorrect configuration... I sent you detailed description and screenshots. Which behaviour would you expect after saving my configuration steps?

[Eric Stern]

I tested it with a second Netonix switch, same problem. Please take a few minutes to reproduce it, there seems to be a bug in the firmware. When adding a QinQ vlan to a mixed port, that is also used for managment, I leads to loss of connection/revert.

- Port 14: Management vlan (1) untagged, other vlans tagged.
- Port 3: Vlan 123 "Q", port 14 "T"

Then save and access is lost until the switch reverts.

I tried duplicating this problem but it seems to work fine.

Before

After

Is this the same test you are doing?

[petecarlson]

Reopening an old thread. I think I have a similar issue with a Netonix switch in my lab. Upgraded to 1.4.7rc4.

Netonix switch is connected to a cisco 4948. Port 14 T VL700 - 4948 port gi1/48 switchport mode trunk allowed vlan add 700.

If I have port 10 and 11 U VL700, it works fine and the MAC table on the 4948 populates correctly with the MAC addresses of the devices connected to ports 10 and 11 of the Netonix.

If i change port 10 from U VL700 to Q VL700, the MAC table for gi1/48 clears and does not repopulate the MACs from port 10 OR 11.

Same deal if I E port 11. If I have any port set to Q on VL700 and port 14 set to T on VL 700, port 14 stops trunking any traffic on VL700.