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

[cegner]

Port 3 is a PTP link to a customer.
Port 14 goes to a router, that is QinQ capable.

MTU is set to 9000 on both ports.

The customer has an ethernet transport service with us, so all untagged or tagged frames entering port 3 shall be forwarded through S-VLAN 252 (double tagged frames). The router connected to Port 14 strips the outer tag and forwards all frames via MPLS L2Circuit to another location. So I guess this is exactly what your are describing. Setting port 3 in U mode accepts untagged frames only, and drops tagged ones, so I guess I have to use Q mode.

I am accessing the switch over Port 14 with untagged frames (VID 1). Configuring the S-VLAN 252 shouldn't affect management access to the switch, but it does.

Access the MAC Table page works fine for the first time. But when I click the refreh icon or enter some VLAN ID as filter, the loading dialog appears for ever. I have to reload the complete page then. I'm using Firefox 44 here.

[cegner]

NOTE: I edited your post above and changed it to uploaded images as the place you had the pics hosted was spamming me with add Tabs.
You can simply upload images to the forums by clicking "Upload attachments" below the box where you type your post.

Thanks! Will use that function next time.

[sirhc]

Access the MAC Table page works fine for the first time. But when I click the refreh icon or enter some VLAN ID as filter, the loading dialog appears for ever. I have to reload the complete page then. I'm using Firefox 44 here.

Can you try Chrome and see if you have the same issues, maybe this is a BUG with FireFox????

I am not sure what you mean by loading dialog, please post a screen grab.

Also please post a screen grab of the Device/Status Tab

And you are sure this is v1.3.9 as there was a fix for MAC table display in v1.3.9

[cegner]

You're right, it seems to be a Firefox problem, Chrome works.
Firefox console shows the following error message:

Code: Select all

TypeError: row.children[0].innerText is undefined

Yes, it's really 1.3.9 ;)

[Eric Stern]

You're right, it seems to be a Firefox problem, Chrome works.

This will be fixed in the next release.

[RSENG-Eric]

I too, am having this issue. When we try to go from a Tagged uplink port to some Q ports, we lose access to the switch, This past time that I tried it, the revert didn't take place, and I had to console in, remove the Q vlan and reboot the switch.

This is the working config:

When I apply this configuration, I lose access to the switch and it didn't revert:

[sirhc]

I am not sure why your revert did not work? Is it disabled on the Device/Configuration Tab?

QinQ has been tested to work fine by us and several other people.

You can not simply change a U or T to Q and expect thing to work without changing the other network components as you have to change the other devices in your network to deal with the new configuration.

Another thing you NEED to do when moving to QinQ is increase your MTU to handle the added header/packet size

[RSENG-Eric]

The revert feature is working fine for other settings changes. I tested it with another VLAN change, it worked as expected. I hadn't changed the MTU setting before making the the QinQ change, but since I was having trouble pinging through a 32-byte ping, which wasn't part of the VLAN being QinQ tunneled, I don't think that that would be the issue. All traffic appears to stop switching. Perhaps, I'm not doing it correctly. I use QinQ tagging in our network a great deal, but I'm using the interface on the ring switch that feeds the wisp switch at the tower site. I'm trying to move the QinQ tagging to the WISP switch so that I can incorporate more flexibility. My ring switch is configured to pass the QinQ VLAN to the WISP switch as a tagged VLAN, along with the other VLANs, and this is the same setup that is used to send all of the VLANs into the Cisco router.

Can Netonix take a few minutes to create a simple tutorial for QinQ tagging that I can follow to see if that solves my problem?

[sirhc]

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

If a port has a Q on it and a packet exiting that port has VLAN Tag 2 nested inside VLAN Tag 1 then the packet will exit the port with only VLAN Tag 2 as the outer VLAN ID 1 is stripped off.

If a packet exits a port with a Q with just 1 VLAN ID and no inner nested VLAN Tag then the packet will leave the port as an Untagged packet as the only single non nested VLAN Tag was removed exposing a bare Untaged packet.

A packet entering a Q port will be encapsulated with a VLAN ID tag so if the packet is already encapsulated with an existing VLAN ID that VLAN is encapsulated or nested within a new outer VLAN ID tag.

All Q ports do on ingress packets is encapsulate or nest any packet even already VLAN tagged packets inside another VLAN ID tag (nested), Untagged packets become encapsulated with a single normal VLAN ID Tag.

All Q ports do on egress is remove the outer VLAN tag if nested leaving the inside VLAN tag or if not nested the packet leaves as Untagged.

QinQ packets leaving a T port with nested VLAN tags would leave with both VLANs alone still nested.

QinQ or nested packets leaving a U port would have both VLAN tags removed leaving as normal Untagged packets.

We did not write this, it is part of the switch core code and QinQ is a standard, all we did was write the interface that allows you to configure it.

[cegner]

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.