[c-nsp] bridging to second-dot1 vlan

[Tony]

Hi Brian,


> 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 ?

Thanks,
Tony.





>________________________________
> From: Brian Turnbow <b.turnbow at twt.it>
>To: Tony <td_miles at yahoo.com>; "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net> 
>Sent: Wednesday, 5 September 2012 12:13 AM
>Subject: RE: [c-nsp] bridging to second-dot1 vlan
> 
>Hi Tony,
>
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of Tony
>> Sent: martedì 4 settembre 2012 15:24
>> To: cisco-nsp at puck.nether.net
>> Subject: [c-nsp] bridging to second-dot1 vlan
>>
>> Hi all,
>>
>> I have a situation where I would like to configure bridging on a 7609 from
>> a normal VLAN interface to a double-tagged WAN interface.
>>
>> Configuration is like this:
>>
>> ===
>> int gig7/7
>> switchport trunk encap dot1g
>> switchport trunk allowed vlan 202
>>
>> int gig1/2/4.30570202
>>  encapsulation dot1Q 3057 second-dot1q 202
>>  bridge-domain 202 dot1q
>> ===
>>
>> Where gig7/7 is connected to a 3750 as a trunk and I then have a device
>> connected to an access port on the 3750 that is in vlan 202.
>>
>> The gig1/2/4 port is a SPA-5GE card in a SIP-400 and that port goes to a
>> carrier that hands off services as tagged VLAN's (one outer VLAN for each
>> service) and we then create a dot1q inner VLAN.
>>
>> When I configure the bridging as above it would appear that the traffic
>> works correctly in one direction, but that in the other direction (traffic
>> inbound on the SPA to local LAN interface) only the OUTER dot1q tab is
>> getting stripped off so that when the traffic gets to the end device is
>> still has VLAN 202 on the frame instead of being a non-vlan frame. This
>> shows up in a packet capture on the end device like this:
>>
>
>Not sure I follow you here. Since port g7/7 is a trunk port the vlan stays on.
>This is correct.
>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.
>
>
>Brian
>
>
>
>
>> 22:00:35 00:13:1a:e9:a3:44 > 00:17:c5:16:43:7a, ethertype 802.1Q (0x8100),
>> length 64: vlan 202, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4),
>> Request who-has 192.168.2.1 (00:17:c5:16:43:7a) tell 192.168.2.11, length
>> 46
>>
>> Where the critical part is "ethertype 802.1Q (0x8100), length 64: vlan 202"
>> which shows that the packet coming in still has the vlan 202 tag on it and
>> so the device ignores it, because it doesn't do VLAN sub-ints.
>>
>> Software is 12.2(33)SRD4. Hardware is as described above, Gig7/7 is just a
>> "plain" LAN port (WS-X6516-GE-TX).
>>
>>
>>
>> Any suggestions on whether what I'm trying to achieve is possible and what
>> I might do to achieve it with the hardware/software at hand ?
>>
>>
>>
>> Thanks,
>> Tony.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>---
>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.
>
>
>
>