01-31-2009 11:08 AM - edited 03-06-2019 03:47 AM
Hello,
I have the following:
R5---sw1---sw2---R2
After setting up RSPAN on the switches (3560s), sw1 sees R2 as a CDP neighbor.
I have a monitor session on sw2 destined for a remote vlan as follows:
SW2#sho run | inc mon
monitor session 1 source interface Fa0/2
monitor session 1 destination remote vlan 999
On sw1 I start getting these messages:
00:50:32: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on
FastEthernet0/13 (not half duplex), with R2 Ethernet0/0 (half duplex).
00:51:32: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on
FastEthernet0/13 (not half duplex), with R2 Ethernet0/0 (half duplex).
Sure enough, Sw1 now sees R2 as a cdp neighbor on the port connected to sw2
SW1#sho cdp ne | inc 0/13
SW2 Fas 0/13 125 R S I WS-C3560-2Fas 0/13
R2 Fas 0/13 165 R S I 3640 Eth 0/0
fyi, sw1 has the following config:
SW1#sho run | inc mon
monitor session 1 destination interface Fa0/5 ingress untagged vlan 100
monitor session 1 source remote vlan 999
I have defined vlan 999 as a remote-span vlan on both switches
Any ideas?
thank you
01-31-2009 11:31 AM
I should note that I am using R5 just to debug ip packet and see if monitoring works because I don't have a PC connected right now. The crux of the issue is the segment between SW1,SW2 and R2.
01-31-2009 09:52 PM
Found the issue, looks like a bug:
02-01-2009 05:14 AM
Hello Bryan,
the bug description describes a little different scenario where the RSPAN vlan causes the loss of CDP neighborship when a CDP speaker is connected to RSPAN source port.
In your case you see CDP frames sent by R2 propagated back to sw1 you can complain of bi-directional behaviour.
The RSPAN vlan has some specific properties including the fact that it disables MAC address learning.
It should be R2 to see CDP frames coming from the left to the right of your network schema being R2 connected to the RSPAN destination port.
You have an unexpected feedack back to sw1 of CDP frames originated by R2.
CDP frames have multicast destination.
The end result as you noted is a behaviour similar to 802.1Q in Q tunneling.
To stop these unwanted messages you can disable CDP on R2 interface as suggested in the bug workaround
Hope to help
Giuseppe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide