bh1633
3 Cadmium

Re: 6224 QinQ

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

0 Kudos
chris.bowman
1 Copper

Re: 6224 QinQ

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!

 

0 Kudos
Highlighted
peterhd
1 Copper

Re: 6224 QinQ

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.

 

 

 

0 Kudos
speedcolo
2 Bronze

Re: 6224 QinQ

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.

0 Kudos
stokkeland
1 Copper

Re: 6224 QinQ

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 🙂