From: Jared Scrivener (jscrivener@ipexpert.com)
Date: Sun Feb 01 2009 - 03:51:07 ARST
Woot... My first suggestion matched the suggested workaround. Now if only
I'd pretended I know the specific bug number too, then I'd be a geek. :)
Cheers,
Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
Technical Instructor - IPexpert, Inc.
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
Mailto: jscrivener@ipexpert.com
-----Original Message-----
From: Hobbs [mailto:deadheadblues@gmail.com]
Sent: Sunday, 1 February 2009 12:49 AM
To: jscrivener@ipexpert.com
Cc: NET HE; szmetal@gmail.com; ccielab@groupstudy.com
Subject: Re: RSPAN causing an l2protocol tunnel-like effect
Hey, check this out. The explanation is not very descriptive, but the
workaround is exactly as expected.
CSCse90468
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fet
chBugDetails&bugId=CSCse90468&from=summary
Symptom:
RSPAN traffic may become unidirectional or one way on a 3750/3560 that
carries
the RSPAN traffic ONLY.
Workaround:
Disable CDP on any device(s) adjacent to the switch port that is the
RSPAN monitor souce.
I think we got the bugger. I feel too lazy to upgrade right
now...maybe tomorrow :)
On Sat, Jan 31, 2009 at 10:27 PM, Jared Scrivener
<jscrivener@ipexpert.com> wrote:
> Well... I'm pretty sure there may be a way to resolve this by... wait for
> it...
>
> Putting the newer IOS on both of the switches and testing again. :)
>
> If that works (and you still care about what bug caused the issue) then
you
> could always login to Cisco's website and check the bug tracker.
>
> Cheers,
>
> Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
> Technical Instructor - IPexpert, Inc.
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> Mailto: jscrivener@ipexpert.com
>
>
> -----Original Message-----
> From: Hobbs [mailto:deadheadblues@gmail.com]
> Sent: Sunday, 1 February 2009 12:24 AM
> To: NET HE
> Cc: szmetal@gmail.com; jscrivener@ipexpert.com; ccielab@groupstudy.com
> Subject: Re: RSPAN causing an l2protocol tunnel-like effect
>
> Thank you Net. I just tried my 3550s and it doesn't happen on them
> either. I think I have narrowed it down to one my 3560's as the issue.
> It only happens when SW1 is my RSPAN destination. And they do run
> different codes:
>
> SW1#sho ver | inc bin
> System image file is "flash:/c3560-advipservicesk9-mz.122-25.SEE4.bin"
> SW2#sho ver | inc bin
> System image file is "flash:/c3560-advipservicesk9-mz.122-40.SE.bin"
>
> R1---SW1----SW2----Monitor
> SW1: RSPAN source
> SW2: RSPAN destination.
> I do not get the behavior.
>
> Monitor----SW1---SW2---R2
> SW1: RSPAN destination
> SW2: RSPAN source
> SW1 sees R2 as CDP neighbor.
>
> Thank you all for your help.
>
> On Sat, Jan 31, 2009 at 9:14 PM, NET HE <he_net@hotmail.com> wrote:
>> Hobbs,
>>
>> I don't have 3560, but I used 2 3550 and a router to lab your senario up,
>> and didn't have the problem you mentioned.
>>
>> My topology is sw2(3550) -- sw1(3550) -- R5(2500)
>>
>> Before I labbed up the RSPAN, I checked up the CDP neighbors on R5 and
> SW2,
>> R5 showed SW1, and SW2 showed sw1.
>>
>> On sw1,
>> vtp mode transparent
>> vlan 999
>> remote-span
>> monitor session 1 source interface fa0/5
>> monitor session 1 destination remote vlan 999 reflector-port
>> fa0/10
>>
>> on SW2,
>> vtp mode transparent
>> vlan 999
>> remote-span
>> monitor session 1 source remote vlan 999
>> monitor session 1 destination int fa0/7 ingress vlan 1
>>
>> After 10 minutes, then i checked the cdp neigh again, no change. R5
showed
>> sw1, and sw2 showed SW1.
>>
>> Hope it helps.
>>
>> Best Regards,
>> Net (Xin) He
>>
>>
>>
>>
>>> Date: Sat, 31 Jan 2009 20:01:44 -0700
>>> Subject: Re: RSPAN causing an l2protocol tunnel-like effect
>>> From: deadheadblues@gmail.com
>>> To: szmetal@gmail.com
>>> CC: jscrivener@ipexpert.com; ccielab@groupstudy.com
>>>
>>> Hi Shawn,
>>>
>>> "Encapsulation replicate" would be put on the eventual destination
>>> command on SW1. In this case, the issue is happening before that step.
>>> I have wiped out and cleaned the config up a couple times starting
>>> with creating the vlan first. Still had no luck. I did read about
>>> RSPAN not being able to support l2 protocols - however, I am not
>>> trying to, monitor l2 protocols. Perhaps because CDP is enabled, this
>>> is what they mean and I should in fact turn it off...but lab tasks
>>> often have you set up monitoring a port connected to a router...
>>>
>>> It appears that something is broken here. SW1 must be removing the
>>> vlan999 tag, then looking at the packet natively. If SW2 was removing
>>> the tag, then my monitor would not end with the traffic, which it is -
>>> monitoring is working, source from the RSPAN vlan.
>>>
>>> I do appreciate all the suggestions, I'm kind of curious if anyone
>>> else has labbed this or could lab this up. It just takes two 3560's
>>> and a router...
>>>
>>> On 1/31/09, Shawn Zandi <szmetal@gmail.com> wrote:
>>> >
>>> >
>>> > Did you use "encapsulation replicate"? cause there's a hardware
>>> > limitation
>>> > on 3560s as mentioned in documentation if you have high-traffic load,
>>> > and
>>> > RSPAN does not support BPDU packet monitoring or other Layer 2 switch
>>> > protocols.
>>> >
>>> > also it's recommended that you configure an RSPAN VLAN before you
>>> > configure
>>> > an RSPAN source or a destination session,
>>> >
>>> > Make sure RSPAN VLAN is configured only on trunk ports and not on
> access
>>> > ports.
>>> >
>>> >
>>> > --
>>> > Sincerely,
>>> > Shawn Zandi
>>> >
>>> >
>>> > On Sun, Feb 1, 2009 at 12:10 AM, Hobbs <deadheadblues@gmail.com>
wrote:
>>> >
>>> > > Yep, the output is below. I am worried because this could screw up
>>> > > things on a lab if cdp neighboring was required to be a certain way.
> I
>>> > > could turn it off on R2 but if cdp was required...not good.
>>> > >
>>> > > SW1#sho vlan remote-span
>>> > > Remote SPAN VLANs
>>> > > --------------------------
>>> > > 999
>>> > >
>>> > > SW2#sho vlan rem
>>> > > Remote SPAN VLANs
>>> > > --------------------------
>>> > > 999
>>> > >
>>> > > Also, I thought maybe the native vlan could cause problems if it was
>>> > > the rspan vlan, but my native vlan is 1. I just don't see how this
is
>>> > > happening, vlan999 is tagged and packets to sw1 should arrive as
>>> > > tagged. It should then strip off the header and send it to the
>>> > > monitoring destination port.
>>> > >
>>> > > Other things I tried:
>>> > > -Tagging the native vlan just for kicks (R2 is on vlan 150 btw)
>>> > > -Monitoring a source vlan, instead of port on sw2.
>>> > > -Changing native vlan to a non-existing vlan.
>>> > >
>>> > > very strange...
>>> > >
>>> > > On Sat, Jan 31, 2009 at 12:52 PM, Jared Scrivener
>>> > >
>>> > >
>>> > >
>>> > > <jscrivener@ipexpert.com> wrote:
>>> > > > That's definitely odd and not something I've encountered before.
>>> > > >
>>> > > > If you do "sh vlan remote-span" on both switches are they both
> aware
>>> > > > it
>>> > is
>>> > > > an RSPAN VLAN?
>>> > > >
>>> > > > Cheers,
>>> > > >
>>> > > > Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
>>> > > > Technical Instructor - IPexpert, Inc.
>>> > > > Telephone: +1.810.326.1444
>>> > > > Fax: +1.810.454.0130
>>> > > > Mailto: jscrivener@ipexpert.com
>>> > > >
>>> > > >
>>> > > > -----Original Message-----
>>> > > > From: Hobbs [mailto:deadheadblues@gmail.com]
>>> > > > Sent: Saturday, 31 January 2009 2:36 PM
>>> > > > To: jscrivener@ipexpert.com
>>> > > > Cc: Cisco certification
>>> > > > Subject: Re: RSPAN causing an l2protocol tunnel-like effect
>>> > > >
>>> > > > Ok, just to remove any doubt. I got my laptop connected to SW1 now
>>> > > > and
>>> > > > removed R5 :)
>>> > > >
>>> > > > So now R2 packets are being sent to remote-span VLAN999, to sw1
and
>>> > > > then along to my laptop, monitoring is working...but sw1 still
sees
>>> > > > R2
>>> > > > as cdp neighbor.
>>> > > >
>>> > > > I would think that SW1 is supposed to know that vlan 999 is an
>>> > > > rspan-vlan not take everything literal....
>>> > > >
>>> > > > On Sat, Jan 31, 2009 at 12:30 PM, Hobbs <deadheadblues@gmail.com>
>>> > > > wrote:
>>> > > >> Jared,
>>> > > >>
>>> > > >> Thanks for the reply, but the issue isn't with R5, I was using it
>>> > > >> test
>>> > > >> my monitoring by running debug ip packet. I can remove as needed
>>> > > >> and
>>> > > >> the issue remains.
>>> > > >>
>>> > > >> The issue is with SW1 seeing R2 as a CDP neighbor - THIS should
> not
>>> > > >> be
>>> > > >> happening. Suppose I had a monitoring device on SW1....why does
> SW1
>>> > > >> see R2 as a neighbor?
>>> > > >>
>>> > > >> thanks,
>>> > > >>
>>> > > >>
>>> > > >> On Sat, Jan 31, 2009 at 12:21 PM, Jared Scrivener
>>> > > >> <jscrivener@ipexpert.com> wrote:
>>> > > >>> Hey Hobbs,
>>> > > >>>
>>> > > >>> It appears that your switch is copying ALL frames (from layer 2)
>>> > received
>>> > > >>> via R2 and outputting them to R5. That includes CDP frames.
>>> > > >>>
>>> > > >>> R5 thinks that R2 is a CDP neighbor as a result of this. CDP
>>> > adjacencies
>>> > > >>> require duplex to be matching (as they assume that CDP
> adjacencies
>>> > > >>> are
>>> > on
>>> > > >>> the same physical link) but it appears that R2 is half-duplex.
>>> > > >>> This is
>>> > > >>> giving you CDP errors.
>>> > > >>>
>>> > > >>> My first question is "why" are you doing this (spanning a router
>>> > > >>> to
>>> > > > another
>>> > > >>> router), but I'm sure you're doing it to learn something new. :)
>>> > > >>>
>>> > > >>> Just disable CDP on R2's interface and your issue should resolve
>>> > itself
>>> > > >>> (assuming changing the duplex on R2 doesn't help).
>>> > > >>>
>>> > > >>> Cheers,
>>> > > >>>
>>> > > >>> Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ________________________________
>> How fun is this? IMing with Windows Live Messenger just got better.
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:09 ARST