Re: L2protocol-Tunneling Sanity Check

Posting to the list in case anybody else is curious of my findings. After
extensive labbing and testing here is what I found to be true:

- If I configure the cross-switch link as a trunk everything works
perfectly and consistently

- Even though the trunk serves no real purpose here (I am only using a
single VLAN end to end) the fact that I make it a trunk (switchport mode
trunk) definitely seems to trigger something in the code that makes this
feature work through more than one switch

- I believe that if you wish to do l2protocol-tunneling through more than a
single switch, the interswitch links need to be trunked for consitant
results.
- Note -- We are NOT talking about Q-Q here, although the two are usually
tied together. IF you actually wanted to send multiple vlan's / user
traffic through these links, you would require Q-Q to pass the VLANs across
the SP side

On Fri, Dec 9, 2011 at 10:10 AM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> Unbelievable.
>
> Write erase
> del flash:vlan.dat
> reload
> reconfigure everything
>
> MAGIC!
>
>
>
>
> On Fri, Dec 9, 2011 at 9:38 AM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:
>
>> Hey Paul!
>>
>> Thanks for taking the time to replicate the topology. I guess I am
>> currently at a loss because my 3550 is also running the exact same code as
>> yours. Here is my very specific setup. My 3560 is running a different
>> version but at least that one shows it encapsulating CDP frames in the
>> output of "sh l2protocol-tunnel". The 3550 does not, even after a reload.
>>
>> R1 Fa0/0 --> Cat1 Fa0/1
>> Cat1 Fa0/24 --> Cat2 Fa0/24
>> Cat2 Fa0/2 --> R2 Fa0/1
>>
>> Configurations:
>> ----------------------
>>
>> Cat1 Fa0/1 & Cat2 Fa0/2
>> ------------------------------------
>>
>> switchport mode access
>> no cdp enable
>> l2protocol-tunnel cdp
>>
>> Cat1 & Cat2 Fa0/24
>> -----------------------------
>>
>> switchport mode access
>>
>>
>>
>>
>>
>> On Thu, Dec 8, 2011 at 8:13 PM, Paul Cocker <paul.cocker_at_gmx.com> wrote:
>>
>>> Joe,
>>>
>>> Seems to work for me as you expected it to ... I've included the images
>>> so you can compare. Same setup as you described (no l2protocol tunnel
>>> command on the inter-switch link).
>>>
>>> Paul
>>>
>>> Rack1SW1#sh ver | inc flash:
>>> System image file is "flash:c3560-advipservicesk9-**mz.122-46.SE.bin"
>>> Rack1SW1#sh l2protocol-tunnel | inc cdp
>>> Fa0/1 cdp ---- ---- 6
>>> 6 0
>>> Rack1SW1#
>>>
>>> Rack1SW3#sh ver | inc flash:
>>> System image file is "flash:/c3550-ipservicesk9-mz.**122-44.SE6.bin"
>>> Rack1SW3#sh l2protocol-tunnel | inc cdp
>>> Fa0/5 cdp ---- ---- 6 6
>>> 0
>>> Rack1SW3#
>>>
>>> Rack1R1#sh cdp nei
>>> Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
>>> S - Switch, H - Host, I - IGMP, r - Repeater
>>>
>>> Device ID Local Intrfce Holdtme Capability Platform Port
>>> ID
>>> Rack1R5 Fas 0/0 126 R S I 1841 Fas
>>> 0/1
>>>
>>> Rack1R5#sh cdp nei
>>> Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
>>> S - Switch, H - Host, I - IGMP, r - Repeater
>>>
>>> Device ID Local Intrfce Holdtme Capability Platform Port
>>> ID
>>> Rack1R1 Fas 0/1 159 R S I 3725 Fas
>>> 0/0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 09/12/2011 00:43, Joe Astorino wrote:
>>>
>>>> Hey everybody, I could use some assistance validating my sanity in this
>>>> situation. First, the topology
>>>>
>>>> R1 --- Cat1---Cat2---R2
>>>>
>>>> I am attempting to configure l2protocol-tunneling alone (without Q-Q at
>>>> all) such that R1 and R2 see each other as directly connected in CDP. I
>>>> thought for sure I had this configuration correct, but it wouldn't work.
>>>> Cat1 is a 3560 and Cat2 is a 3550. I am noticing behavior on the 3550
>>>> that
>>>> is not happening on the 3560. Note there are no trunks and every port
>>>> is an
>>>> access port in VLAN 1.
>>>>
>>>> My original thought was this: configure "no cdp enable" and
>>>> "l2protocol-tunnel cdp" on ONLY the edge ports of Cat1 and Cat2 that
>>>> connect to the routers. When I do this I see Cat1 encapsulating frames
>>>> in
>>>> "show l2protocol-tunnel" but Cat2 never shows any decapsulated or
>>>> encapsulated frames. When R1 sends a CDP frame, Cat1 should intercept
>>>> it
>>>> due to the l2protocol-tunnel CDP command, and rewrite the destination
>>>> MAC
>>>> to the proprietary Cisco MAC used for l2protocol-tunneling. That frame
>>>> should then be sent out the cross switch link to Cat2. Cat2 should see
>>>> that it also has "l2protocol-tunnel cdp" configured on the edge port
>>>> facing
>>>> R2 and rewrite the destination MAC back to the CDP multicast address and
>>>> forward to R2. The same should happen the other way.
>>>>
>>>> Again, the 3560 shows frames encapsulated but the 3550 does not yet they
>>>> have an identical configuration. First this led me to believe maybe an
>>>> IOS
>>>> bug in the 3550 12.2(44SE6) so I tried another version with the same
>>>> results. Every example I can find out there usually only does l2pt on a
>>>> single switch or if spanning multiple switches they are combining with
>>>> Q-Q. I understand those concepts fine, but I am not looking to do Q-Q
>>>> in
>>>> this example. I don't have another 3560 on hand to test with.
>>>>
>>>> I started second guessing myself and thinking I needed
>>>> "l2protocol-tunnel
>>>> cdp" on the edge ports AND the cross switch links on both ends. When I
>>>> do
>>>> that, it actually works but I don't think it works for the right
>>>> reasons.
>>>> Ultimately, in this type of setup can anybody confirm weather you need
>>>> "l2protocol-tunnel" on ALL ports between the source and destination or
>>>> just
>>>> on the edge ports.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Joe Astorino
>> CCIE #24347
>> Blog: http://astorinonetworks.com
>>
>> "He not busy being born is busy dying" - Dylan
>>
>>
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> Blog: http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>
>

-- 
Regards,
Joe Astorino
CCIE #24347
Blog: http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net