[c-nsp] bridging to second-dot1 vlan

[Brian Turnbow]

Hi Tony,

See below

>> The 3750 would be the device "removing" the vlan tag
>> If you want the 6500 to remove the tag the port needs to be an access port, not a trunk port.

>My assumption that the inner tag is not being manipulated properly is based on sniffing traffic on the 3550 (sorry, >it's a 3550, not 3750) by spanning the port (gig0/1) that is connected to gig7/7 on 7609. It has a number of other >VLAN's on this trunk port that all appears to behave "normally".

>A packet capture shows ( tcpdump -nei rl1 -vv ether dst ff:ff:ff:ff:ff:ff):

>10:53:54.962025 00:13:1a:bf:22:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 >(len 4), Request who-has 202.x.x.x tell 202.x.x.x, length 46
>10:53:56.940678 00:13:1a:e9:a3:44 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 202, p 0, >ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.10 tell 192.168.2.11, length 46

>You can see the difference, one has a VLAN tag at the front, the other one doesn't. They are both within a VLAN >though, the traffic for 202.x.x.x is within VLAN 117 (just a "normal VLAN terminated as L3 interface on the 7609, >not trying to bridge this one). Given that they are both trunked VLAN's on the 3550 gig0/1, and the traffic in vlan >117 doesn't show the VLAN tag in tcpdump I assume the 3550 has already stripped it off before forwarding it on to >it's destination (and the span session). If this is true, then it would follow that my packet for vlan 202 most >likely has TWO 202 tags (inner & outer), which comes back to the bridge-domain command not supporting the second->dot1q vlan. Ideally it should strip off both VLAN tags (inner & outer) and then put the traffic into the bridged >VLAN (202), but it doesn't look like it is doing this. It looks more like that it is stripping the outer vlan >(3057) and then leaving the inner one (202) and then applying the bridged vlan (202). If I could capture packets as >they egress the 7609 gig7/7, or something in between the two devices to capture then I could verify this, but I >can't do either.

>I think this is also supported by if I change the config of my bridge command to "bridge-domain 202 dot1q-tunnel", >I then see packets with both the inner & outer tags still on them, eg:

>11:03:07.866731 00:13:1a:e9:a3:44 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 3057, p 0, >ethertype 802.1Q, vlan 202, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.10 tell >192.168.2.11, length 46


>Do you think if I can loop my packets through another switch/cable I will be able to strip the extra vlan 202 tag >off ?


I think I understand better what you are wanting to do.
You just need to add the second vlan on top of existing 202 on the outgoing interface?
In this case you don't need to domain Bridge the traffic, traffic on the same vlan is bridged by default, so just remove it.



Note that most providers will do this by adding the second "service provider" vlan at the customer ingress.
the 6500 needs a "wan" port to do so , so the 6516 won't work.
This helps avoid any vlan overlaps and segregate the networks etc.
i.e customer vlans are theirs and network vlans are yours 




Brian







---
This e-mail is intended only for the addressee named above. 
As this e-mail may contain confidential or privileged information, 
if you are not the named addressee, you are not authorized to retain, read, 
copy or disseminate this message or any part of it.   
 
Please consider your environmental responsibility before printing this e-mail.