Does anyone have QinQ working?

[petecarlson]

Passing traffic through a Q port to another Q port on the switch appears to work fine.

Passing traffic from a Q port out a T port to another switch doesn't seem to work. Does anyone have this working and if so, what switches does it work with?

[sirhc]

Yes, it has been tested to work but you fail to provide important information for anyone to help you.

I would post up your VLAN Tab and describe what your using.

Also keep in mind that there was a FIX for QinQ in the last firmware release but we have no idea what firmware your running?

NOTE: MSTP is still being tested so use MSTP at your own risk.

FIXED/CHANGED
- Fixed temp sensors showing crazy values in very cold environments - RC3
- Fixed getting "unexpected link change" messages due to port bounce, watchdogs, etc - RC3
- Fixed port bounce being 1 hour off after daylight savings time changes - RC3
- Fixed VLAN tab layout getting messed up when you delete a VLAN - RC3
- Fixed mac table refresh button causing entire page to reload - RC3
- Fixed problem with QinQ when using untagged VLANs - RC3 <=====
- Fixed fan control handling negative temperatures - RC4
- Fixed input voltage graph labels - RC4

ENHANCEMENTS
- Added MSTP - RC3
- Changed UI layout on QOS tab - RC3
- Changed dumb DC models to temporarily disable POE when input voltage falls too low instead of disabling POE in the configuration - RC3
- Changed valid DC input voltage range to 9-72V in GUI for newer board revs - RC3
- Changed valid upper range for dc output voltage from 51V to 53V - RC3
- Changed input voltage graph to auto-scale - RC3
- Automatically disable flow control on ports using QOS bandwidth limits to prevent packet locks - RC3
- Added restart timer to DC power supply to help in very cold environments with cold starts - RC3
- Added log message when time is set by NTP after boot is finished - RC3
- Added logging when STP selects new root port - RC3
- Added POE startup delay option on Power tab - RC3
- Added root path cost on STP tab - RC3
- Added portDuplex SNMP stat from CISCO-STACK-MIB - RC3
- Added ifAdminStatus to SNMP stats - RC3


KNOWN ISSUES
- Some language templates need help - please contact us to help

RC3 Released 1/3/2017
RC4 Released 1/3/2017

[petecarlson]

I previously read through all the change logs and upgraded the switch in my lab to 1.4.7rc4 to test his. Reading through all of the posts that reference QinQ in the forum, I am seeing multiple cases of people seeing similar issues but not seeing any resolution and thus I posted looking for working examples, specifically, looking for what models of switches they were trunking to and how they are configured.

I wasn't so much looking for a resolution to the issue I am seeing as looking for people with working configs passing traffic from a Q tagged port through a T tagged port to another switch.

Here's an example config that doesn't work.

Port 14 T 700 connected to Cisco 4948 port gi1/48 configured switchport mode trunk, allow vlan 700 and appropriate MTUs set to allow for the extra 4 bytes.

With ports 10 and 11 set U 700, the trunk to the 4948 works fine and the MAC table for VL700 on the 4948 populates with the MACs from devices connected to ports 10 and 11. As soon as I set either 10 or 11 to Q, the mac address table for VL 700 on the 4948 clears and does not repopulate.

For example:
P10 set to Q700
P11 set to U700
P14 set to T700

Will break the trunk between the Netonix Switch and the 4948. The MAC table for VL700 on the 4948 clears as soon as there is a change to Q700 on P10 and does not repopulate. Even with nothing connected to P10, the MAC table for VL700 on the 4948 does not repopulate with the MAC of the device connected to P11.

The simple case of:

P10 set to Q700
P14 set to T700

Also does not work.

Chris, could you describe the setup where it has been tested to work? I'd like to duplicate it in my lab, get it working, and then test with various hardware connected to the trunk port.

[sirhc]

appropriate MTUs set to allow for the extra 4 bytes

What is your MTU set to?

1528 is for normal VLANs, with QinQ I would bump to 1532

[petecarlson]

Currently at 1600. I had it set at 1504 on the cisco and 1536 on the Netonix but then bumped it to 1600 on both ends just to make sure.

[petecarlson]

Chris et. al,

Could you confirm this is the expected behavior?
With a port set at Q 500.
If a packet enters it tagged 0x8100.3000 it would have a 0x8100.500 packet added to it to look like:

0x8100.500 0x8100.3000

If another port on the switch is set to T 500 it will just pass the packet out unmolested? (0x8100.500 0x8100.3000)

[Eric Stern]

Chris et. al,

Could you confirm this is the expected behavior?
With a port set at Q 500.
If a packet enters it tagged 0x8100.3000 it would have a 0x8100.500 packet added to it to look like:

0x8100.500 0x8100.3000

Yes.

Chris et. al,

If another port on the switch is set to T 500 it will just pass the packet out unmolested? (0x8100.500 0x8100.3000)

Yes.

[petecarlson]

There is something odd going on here.

P14 connected to 4948 set as a trunk port allow 700.
P14 set as T700
P5 set as T700

If I connect port 5 to a 450i AP and tag QinQ 2000 with S VLAN 700 (QinQ type 0x8100 set on AP), it works fine. The double tagged packet passes through the netonix switch correctly. As soon as I set any other port to Q700, this stops working even with nothing connected to the Q port.

I also noticed that if I plug something (without a vlan set so VL1) into the Q port and then allow all vlans on the cisco trunk port, I see the mac address of the device connected to the Q port in the MAC address table of the cisco ON VLAN 1... How could that happen? We know that the cisco only sees the outside tag of a 0x8100 0x8100 double tagged packet, and we know that a 0x8100 0x8100 packet passing through the switch to the cisco works, so the packet being passed to the cisco can't be tagged 0x8100.700 0x8100.1. It is either being untagged before it is sent to the cisco, or it is being tagged with something other then 0x8100 on the outer tag and the cisco is ignoring the outer tag.

Is it possible that the Netonix is tagging 0x88a8 on the outer tag when Q is set on a port?

[petecarlson]

Rather then guess, I decided to test this out.

With Q 700 set on a port: Client connected to the Q port: (for brevity I didn't bother adding the C VLAN but it acts the same way)

Broadcast, ethertype 802.1Q-QinQ (0x88a8), length 346: vlan 700, p 0, ethertype IPv4, 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 68:5b:35:b2:ac:25 (oui Unknown), length 300

With double tagged 0x8100 coming in a T port while another unused port is tagged Q on the VLAN:

Broadcast, ethertype 802.1Q-QinQ (0x88a8), length 350: vlan 700, p 0, ethertype 802.1Q, vlan 2003, p 0, ethertype IPv4, 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 68:5b:35:b2:ac:25 (oui Unknown), length 300

With double tagged 0x8100 coming in a T port (No ports tagged Q on the vlan)

Broadcast, ethertype 802.1Q (0x8100), length 350: vlan 700, p 0, ethertype 802.1Q, vlan 2003, p 0, ethertype IPv4, 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 68:5b:35:b2:ac:25 (oui Unknown), length 300

So it appears that if Q is set on any port in the same vlan, it changes 0x8100 0x8100 packets that come in on a different trunk port to 0x0x88a8 0x8100 packets. I would rate this as a bug.

When traffic ingresses a Q port, it adds a 0x0x88a8 vlan tag and not a 0x8100 vlan tag. Not a bug, but this behavior should documented as it breaks compatibility with a ton of hardware, i.e cisco.

I'll poke around in the cli, but is there any chance you could make QinQ EtherType a configurable option?

[Eric Stern]

To be clear, this is working as per the 802.1ad standard (https://en.wikipedia.org/wiki/IEEE_802.1ad). The inner tag (C-TAG) is 0x8100, the outer tag (S-TAG) is 0x88a8.

Will look into making this configurable to allow interoperability with other equipment that do not follow the standard.