6224 QinQ *SOLVED*

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.

   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

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

   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. :

   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

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

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.

 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.

Here is the config you need. 

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

Ok! Changing this back to "Solved", BH, your config works, and makes more sense than the previous config I recieved from Dell.   I had tried this config before, and thought I was having trouble with it, well instead I was having trouble with the one setting up the testing, ME!   I won't go into a long detailed explanation of my error, but it the ability to reproduce the fault I was causing myself is fairly easy, and I've not figured out yet if why the Dell's behave this way, but I assume it's to prevent possible loops.

I was able to cause the following using a FreeBSD box  being used as a router with multiple VLAN's, I'm sure any *nix variant would work fine, this test requires arping to be installed :

FreeBSD Machine (Emulating Customer VLANs 2&3) <-> 3524QinQ 1000 <-> 6224QinQ 1000  <-> FreeBSD Router (VLAN 2&3)

1. Add 2 VLAN's to your *nix machine, 2 and 3 will work

2. Assign each VLAN interface an IP, I used 172.17.0.1/24 VLAN2, and 172.17.1.1/24 VLAN3 on the router, then 172.17.0.2/24 VLAN2 and 172.17.1.2/24 on the machine emulating customer vlans.

3. Ping from box emulating customer vlans to router, this works across both vlans, so we know QinQ is working properly.

4. Let's break things:

     b. ifconfig -a vlan2 on your box emulating customer vlans, get the mac address, lets say its 00:11:22:33:44:55

     a.  Run this on the box acting as a router "arping -s 00:11:22:33:44:55 -t ff:ff:ff:ff:ff:ff -i vlan3 172.17.1.10"

So what I've done is something that "should" never happen, I've sent a frame with a source address of 00:11:22:33:44:55 (MAC of a customer on VLAN2) out VLAN 3, when I do this the frame does forward, and I can see it via a packet dump on VLAN 3 on my customer emulated box.  However, frames destined to 00:11:22:33:44:55 on VLAN2 from the router will no longer be forwarded by the 6224 while the same MAC is being sent out via VLAN 3, maybe because the internal forwarding tables on the switch are confused by this behaviour.

So in short, I was causing my own problem when bridging a few VLAN's together, I know it doesn't seem a rational thing to do, but in short, the reasoning behind it was to use VLAN's for layer2 seperation up to the router, then at the router I'd bridge several together so all the VLAN's would use one virtual IP interface, second I have full control at layer2 if I chose to allow certain macs to bridge across from vlan to vlan at layer2 instead of having to route.  Problem was I meant to test WITHOUT the bridged setup, and well, overlooked that bit, never imagining that it would cause this problem.

Thanks again for all the help! At least in a traditional QinQ setup, this certainly does work on the 6224!

Chris, what you tried is not supposed to work with Q-in-Q. Note that the Q-in-Q switch could not differentiate between vlan2 and vlan3 traffic, as it only considers the outer tag which is vlan1000 in both cases. So it builds a single forwarding table for vlan1000, not two different ones for vlan1000+vlan2 and vlan1000+vlan3. When you send a packet with other end's MAC address, the switch relearns that MAC address on the wrong port and forwarding table gets broken.

Just for the record, the config I previously mentioned works as well, i.e.:

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

So the only annoyance on 6224 switches is that "mode dvlan-tunnel" logic is inverted - when you configure it on port g1, you in fact disable vlan tag recognition on all other switch ports. This is very counter-intuitive and the exact opposite to behaviour on 3524 and Cisco switches. Yet worse, one could easily break his network by configuring this command on the customer port - when this command is entered, all previously working trunk ports will stop recognizing vlan tags and all packets will suddenly get into default vlan.

Sorry to revive an old thread, but:

It sounds like on PowerConnect 62xx, the "mode dvlan-tunnel" command says something like "please receive and transmit doubly-tagged frames".  If I plan to run doubly-tagged frames across a core of switches in a new network, should I proactively define "mode dvlan-tunnel" on every trunk, network-wide, from day-1? Otherwise, it soundl like there will be much breakage the first time a Q-in-Q port is enabled.

i posted this same question of serverfault.com - and although all the answers are up above - some helpful dude clearified it for me - very simple actually:

Yes, you have to set dvlan-tunnel on all trunks that are not "customer facing".

Your customer ports leave as is.

but, you should be able to avoid much downtime if you script it all and paste it in - if you have a lot of trunk ports it will probably interrupt flow for a few milliseconds while your console-paste goes in :)