chris.bowman
1 Copper

6224 QinQ *SOLVED*

 

 

I've a customer with a trunking 20 VLAN's to port 1 on my 3524, I've setup the 3524 as switchport mode customer  (QinQ) on vlan 1000, I have a trunk from my 3524 to a 6224 which contains this vlan 1000, at the 6224 I wish to strip the outer QinQ tag, and send it out to a router which has multiple vlan subinterfaces matching the vlans of the cusomters trunk.  

 

So for example lets say :

Customer Switch (Trunk VLAN 2-21)=> Dell 3524 E1 (QinQ on VLAN 1000) <=> 3524 G1 (TRUNK VLAN 1000) => 6224 G1 (TRUNK VLAN 1000) <=> 6224 G24 (Need to strip outer tag 1000 here) => (Trunk VLAN 2-21) Router

 

From what I can tell, the 6224 to my surprise only supports what you guys call "DVLAN-Tunnell", which would allow me to tunnel a QinQ tagged frame THROUGH the switch but not allow me to strip it at the switch, and send the vlans contained within to a device directly connected to the 6024.

 

If this is correct, then why on the Technical Specs for this switch does it clearly say QinQ which is 802.1ad, it seem's the 6224 does not support 802.1ad ? My hope is I've overlooked something, and will be promptly corrected! 🙂

 

Thanks in advance!

 

Chris

 

 VLAN  
VLAN support for tagging and port-based as per IEEE 802.1Q
Double VLAN tagging (QinQ)
Up to 1024 VLANs supported
Dynamic VLAN with GVRP support
Voice VLAN support
0 Kudos
14 Replies
Highlighted
peterhd
1 Copper

Re: 6224 QinQ

I believe "switchport mode customer" on 3524 should do the same thing as "mode dvlan-tunnel" on 6224 and "switchport mode dot1q-tunnel" on Cisco.

Try configuring "mode dvlan-tunnel" only on port 24 of your 6224 and make this port member of vlan 1000.

 

 

 

 

0 Kudos
chris.bowman
1 Copper

Re: 6224 QinQ

 

   Appreciate the response Peter.  I did implement the configuration you suggested, and several variations of it, such as setting vlan 1000 as untagged, with a pvid of 1000.  The end result either way is that frames still contain the outer and inner tag when exiting port 24.  Just to reaffirm, I did not have "mod dvlan-tunnel" set on any other interface on the switch, simply a trunk on PORT1 with QinQ frames coming in as vlan 1000 and PORT 24 set as shown below.  I do have a call in to Dell as well on this, however the person they're saying is "The Guy" I really need to talk to is on vacation till next Wednesday.  I'll update when I fin out more!  Thanks again 🙂

 

spanning-tree disable
switchport mode general
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000 tagged
mode dvlan-tunnel

 

 

 

0 Kudos
bh1633
3 Cadmium

Re: 6224 QinQ

On the 6200, ports in "mode dvlan-tunnel" add dvlan tag to ingress traffic and strip it on egress.

The following config should be a good example for you.  It has this behaviour:

  • 1/g1 - ingress traffic has outer tag of vlan 1000 added and is switched as vlan 1000 traffic, traffic in vlan 1000 (outer most tag) can be egressed and has outermost tag stripped
  • 1/g24 - ingress traffic with outermost tag of 1000 is switched as vlan 1000 traffic, traffic in vlan 1000 (outermost tag) can be egressed and retains outermost tag
  • so your vlan 2-21 traffic ingressing the switch on port 1/g1 will be able to egress port 1/g24 with an outer tag of 1000.  And your outer tagged vlan 1000 traffic ingressing on port 1/g24 will be able to egress the switch on port 1/g1 with the outer tag (vlan 1000) removed. 

configure
vlan database
vlan  1000
exit
stack
member 1 2
exit
ip address 192.168.2.1 255.255.255.0
no spanning-tree
!
interface ethernet 1/g1
switchport mode general
switchport general pvid 1000
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000
exit
!


interface ethernet 1/g24
switchport mode general
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000 tagged
mode dvlan-tunnel
exit
exit

0 Kudos
chris.bowman
1 Copper

Re: 6224 QinQ

 

   Right, makes sense.  The problem however is at a 3524 I'm already adding the outer tag 1000 at ingress which is wrapped around customer vlans 2-21,  from the 3524 I have a trunk setup with vlan 1000 which ingresses at port 1 on the 6224.  I'm arriving at the 6224 with the outer tag already present at port 1.  The goal would be to be able to strip the existing outer tag 1000 that was added by the 3524 at port 24 on the 6224 which would then of course be egressing vlans 2-21.  

   I did out of curiousity try your configuration exactly as you wrote, and as you can see below a tcpdump of whats egressing from 1/g24, unfortunately the outer tag is not getting stripped, which would be expected with regards to what we've seen so far.  I'm using the default global config for the dvlan-tunnel of 802.1q ethertype, also it may help in case the config you mentioned did work for you, Im running firmware version  2.2.0.3 which is the latest.

 

EDIT: I just re-read your post bh and realized that the outer tag should still exist on egress from 1/g24 with your suggestion, but I need it to strip the outer tag at egress on 1/g24, and add the outer tag back on ingress 1/g24.   To note, is seems like if I just removed "mode dvaln-tunnel" from 1/g24, and made 1/g24 untagged 1000 pvid 1000 that this would work, but it does not.  Sorry about that, Thanks!

So what I have setup for this specific test :

WINDOWS HOST => 3524-1 E3 (UNTAGGED VLAN 3 PVID 3) <=> 3524-1 G1 (TRUNK 2-21) =>6224-1 G1 (UNTAGGED 1000 PVID 1000) <=> 6224-1 G24 (TAGGED 1000 MODE DVLAN) => FreeBSD Box (For Testing)

17:17:26.772757 00:01:02:12:34:56 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 1000, p 0, ethertype 802.1Q, vlan 3, p 0, ethertype ARP, arp who-has 172.17.104.1 tell 172.17.104.2

interface ethernet 1/g1
switchport mode general
switchport general pvid 1000
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000
exit

interface ethernet 1/g24
switchport mode general
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000 tagged
mode dvlan-tunnel
exit

 

Thanks again for all the input!

 

Chris

 

One thing I wanted to add, under standards, 802.1ad isn't mentioned, so it seems that indeed there may be no "Service Provider Bridge" as it exists in the 35xx series of switches, unfortunately when I purchased the switch I just noticed the "QinQ" bit, and assumed it supported QinQ as at least I know it. :

 Standards Supported  
IEEE 802.1AB
IEEE 802.1D
IEEE 802.1Q
IEEE 802.1p
IEEE 802.1w
IEEE 802.1x
IEEE 802.2
IEEE 802.3
IEEE 802.3I
IEEE 802.3u
IEEE 802.3x
IEEE 802.3z
IEEE 802.ab
IEEE 802.3ac
IEEE 802.3ad
IEEE 802.3ae
IEEE 802.3ak

 

 

0 Kudos
peterhd
1 Copper

Re: 6224 QinQ

Hmm, it looks like the Q-in-Q logic is reversed on 6224s when compared to all other switches.

For some reason it seems that "mode dvlan-tunnel" needs to be added to all ports except the customer port, while on all other equipment the equivalent of this command needs to be added only to customer port.

Chris, could you try this:

inte e 1/g1    (double tagged port towards 3524)
switchport mode trunk
swithport trunk allowed vlan add 1000
mode dvlan-tunnel

inte e 1/g24  (port where outer tag should be stripped)
switchport mode access
switchport access vlan 1000

 

Eventually try this:

inte e 1/g1
switchport mode general
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000 tagged
mode dvlan-tunnel

inte e 1/g24
switchport mode general
switchport general pvid 1000
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan add 1000

If any of the above works, the logic is reversed.

0 Kudos
chris.bowman
1 Copper

Re: 6224 QinQ

   I've attempted the examples you gave Peter, and every other variation I could think of 🙂  None of these work, but Dell Engineering is looking into this, and should have a definitive answer soon. 

  Thanks again for the help however!

Chris Bowman

 

 

0 Kudos
chris.bowman
1 Copper

Re: 6224 QinQ

Here's the solution from Dell, and this does work!

Peter you where very close to having the correct config.  Thanks everyone for the assistance!

 

 

Strip off the outer vlan tag and Trunk the inner vlans from the 6224 port G24 Uplinking to a Router

Customer Switch (Trunk VLAN 2-21)=> Dell 3524 E1 (QinQ on VLAN 1000) <=> 3524 G1 (TRUNK VLAN 1000) => 6224 G1 (TRUNK VLAN 1000) <=> 6224 G24 (Need to strip outer tag 1000 here) => (Trunk VLAN 2-21) Router

The 6224 port G1 must be configured as follows:
General Mode
Dvlan mode
pvid 1000
vlan 1000 Tagged

 

The 6224 port G24, uplink to the router should be configured as follows:
General or Trunk Mode
pvid 1000
Vlan 1000 Untagged
Vlans 2-21 Tagged
Can Remove vlan 1, if desired

The Router Port should have sub-interfaces for vlans 2-21

0 Kudos
peterhd
1 Copper

Re: 6224 QinQ

Well, if the above config is needed, then it looks like some bug.

Do you really need "vlan 2-21 tagged" on port 24 (the customer port) ??

If that's the case,  it would mean that for every customer vlan, metro ethernet provider needs to add that vlan in his configs to get it work. This is a serious problem.

Customer ports are supposed to accept all VLANs without any special configuration and should just add the configured outer (provider's) tag.

 

The Q-in-Q config syntax on 3524s is much better - you just add "switchport mode customer" and "switchport customer vlan 1000" to the customer port and you're done.

Let's hope Dell changes 6224s to the same syntax in some future firmware release.

0 Kudos
chris.bowman
1 Copper

Re: 6224 QinQ

 I agree, the syntax is about as non-intuitive as it gets on the 6224's regarding QinQ.   On top of that, I've found a problem with this new configuration as well, I'm still testing, but it seems the only reason it was working was a fluke, once I locked down the default VLAN 1 on both the 6224, and the router I'm testing to, in short, it breaks.  Why I'm not sure yet, nothing adds up, but I'm doing some packet captures now to see what was passing with 1 enabled verses not, I suspect that somehow address tables on the switch where being updated improperly with VLAN 1 allowed, seems buggy.  I'll add some packet dumps when I have something conclusive to report.

0 Kudos