RSPAN casuing l2protocol tunneling-like behavior

dodgerfan78 · ‎01-31-2009

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

dodgerfan78 · ‎01-31-2009

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.

dodgerfan78 · ‎01-31-2009

Found the issue, looks like a bug:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCse90468&from=summary

Giuseppe Larosa · ‎02-01-2009

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