Does anyone have QinQ working?

[petecarlson]

I would agree with one caveat.

Lets say you have two ports on the switch set to T 500. They pass double tagged 0x8100 0x8100 traffic unmolested.

You then tag a third port to Q 500. At that point, the switch starts remarking the outside tag on traffic between the first two ports as 0x88a8 instead of 0x8100.

I'd guess this is a linux issue. The kernel is consuming the outside tag and then libcap is rewriting it with 0x88a8 instead of 0x8100

[petecarlson]

I redesigned to use 0x88a8 tags across the Netonix switches and ran into something funny.

If I connect two Netonix switches together on port 1 configured with management VLAN 5

SW1 Port 1 T5
SW1 Port 2 U5 (for local mgmt)

SW2 Port 1 T5
SW2 Port 2 U5 (for local mgmt)

Plugged into SW1 managing SW2 over the trunk:
I Add VLAN 500 to SW2 and add it to port 1.
I Add VLAN 500 to SW1 and add it to port 1.
If I tag Q on port 6 (not connected to anything yet) of SW2, I loose access to SW2.
If I then tag Q on port 6 (not connected to anything yet) of SW1, the trunk between SW1 and SW2 starts working again and I get access back to SW2.

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.

Can anyone explain this?

[sirhc]

I have a new firmware being released today with some fixes to QinQ


- added support for new WS-26 models
- added Double Tagged to VLAN configuration
- changed fan control to also use CPU and PHY temp
- changed valid temp range on Status page meters
- fixed Apply/Save becoming active when looking at MSTP configuration even though nothing changed
- fixed port number in log messages