Re: L2protocol-tunnel: Difference between access mode and

From: joe_astorino@comcast.net
Date: Thu Feb 19 2009 - 03:04:22 ARST


Thank you for the response Scott! It's certainly nice to have the opportunity to talk to the guy that WROTE the lab : ) That always helps. You are correct in that I did NOT tag the native VLAN. The native VLAN is just the default (VLAN 1). I suppose this makes sense since I believe CDP, STP and others run on VLAN 1. I thought I tried making the native VLAN different on all links just for fun, and had the same issue, but I did not make that native VLAN the same one that was pruned everywhere else....it was just some arbitrary other VLAN. I'll play some more with it. Right now I am reading what I have found to be the best paper on the subject so far: The section of the 3550 config guide related to dot1q tunneling and l2protocol-tunnel at http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1_11_ea1/configuration/guide/swtunnel.html#wp1010798

One thing that strikes me there is this sentence: " If an encapsulated PDU (with the proprietary destination MAC address) is received from a tunnel port or access port with Layer 2 tunneling enabled, the tunnel port is shut down to prevent loops."

I kind of don't get that. I mean isn't that what we are doing with the solution that WORKS?! Cat1 sends the frame out a trunk port and it arrives on an L2TP access port on Cat4. When Cat4 sends it out it's Q-Q L2TP port I presume it is encapsulated with this proprietary MAC address. Then, Cat2 receives it on a Q-Q L2TP port and sends it off to Cat3 after decapsulation. So when Cat2 receives it from Cat4 is it not receiving an encapulated PDU from a tunnel port? It seems like things should be shut down based on that description, but in fact this is the situation where it is working (ey yi yi!)

- Joe
----- Original Message -----
From: swm@emanon.com
To: "joe astorino" <joe_astorino@comcast.net>, "Groupstudy CCIE R/S" <ccielab@groupstudy.com>
Sent: Wednesday, February 18, 2009 11:34:13 PM GMT -05:00 US/Canada Eastern
Subject: Re: L2protocol-tunnel: Difference between access mode and dot1q-tunnel

It's not so much that access-mode works but dot1q tunnel mode doesn't... What's happening is some broadcast/multicast is getting forwarded.

You did the right thing by removing the access vlan from any other trunk links/switches so there would be no loop.

But looking at your configuration, did you perhaps NOT use the dot1q tag native vlan command set? If you aren't tagging them, the intermediary switches will receive and interpret the frames rather than double tagging them. Try adding that and see what happens. Or equally, you may change your native vlan to that same vlan which does not go across other trunk ports/switches, and that may accomplish the same thing.

Keep in mind I'm just going from memory from when I wrote that lab. While it was quite fun, I have no idea if anything was changed since my departure.

Cheers,

Scott

---- Message from joe_astorino@comcast.net at 2009-02-19 02:54:17 ------
>Hi guys,
>
>I am having a difficult time understanding why I am getting this problem. Basically, I am working on IPexpert volume 1, lab 5 which is L2 tunneling. Part of this lab involves tunneling a trunk from Cat1 --> Cat4 --> Cat2 --> Cat3. If I set up my tunneling ports as access ports everything works fine (I have already pruned the access vlan I am using from all other trunks). However, if I change the ports to dot1q-tunnel mode instead of being access ports, I keep getting ports going err-disabled due to loop detection. Nothing else has changed in my configuration so I am confused.
>
>I understand the fundamental difference I think. I know dot1q-tunnel uses q-q technology to encapsulate a tag inside another tag -- usually used in SP environments. I just don't understand why this would cause a loop but the access port mode does not, when nothing else has changed. Here is a rough picture of what I have. All switches are dual connected to all other switches over fa0/19-24
>
>
>Cat1-----------------------Cat3
>| |
>| |
>| |
>| |
>Cat2-----------------------Cat4
>
>
>I don't know how else to show it, but also Cat1/Cat4 are connected and Cat2/Cat3 are connected.
>
>Cat1: Fa0/19-20 ---> Cat4
>Cat1: Fa0/21-22 ---> Cat3
>Cat1: Fa0/23-24 ---> Cat2
>
>Cat2: Fa0/19-20 ---> Cat3
>Cat2: Fa0/21-22 ---> Cat4
>Cat2: Fa0/23-24 ---> Cat1
>
>Cat3: Fa0/19-20 ---> Cat2
>Cat3: Fa0/21-22 ---> Cat1
>Cat3: Fa0/23-24 ---> Cat4
>
>Cat4: Fa0/19-20 ---> Cat1
>Cat4: Fa0/21-22 ---> Cat2
>Cat4: Fa0/23-24 ---> Cat3
>
>So the basic idea for this task is to make Cat1 trunk to Cat3 by taking the path Cat1 Fa0/19 ---> Cat4 Fa0/19 ---> Cat2 Fa0/22 ---> Cat3 Fa0/19
>
>The VLAN I chose to add for tunneling was VLAN 13. I added it only on Cat2 and Cat4. It is ONLY trunked on fa0/22 between Cat2 and Cat4.
>
>If I make Cat1 fa0/19 and Cat3 fa0/19 static 802.1q trunk ports and make Cat4/Cat2 ports Fa0/19 and Fa0/22 access ports in VLAN 13 with also l2protocol-tunnel turned on, it accomplishes the task!
>
>However, if I change NOTHING else and make Cat4/Cat2 Fa0/19 and Fa0/22 dot1q-tunnel instead of access I get Fa0/19 on Cat4 and Cat2 going err-disabled due to loop detection. I am utterly confused!
>
>- Joe A
>
>
>Blogs and organic groups at http://www.ccie.net
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net



This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:12 ARST