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.
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
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!
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. :
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
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.
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.
peterhd
22 Posts
4465
0
Posted March 27th, 2009 01:00
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.