[c-nsp] Strange CDP Observation

[Jeremy Bresley]

Marko Milivojevic wrote:
> On Sun, Nov 29, 2009 at 08:46, Scott Morris <smorris at ine.com> wrote:
>   
>> While not normal, think about what makes it occur.
>>
>> If it REALLY WAS your own CDP frame, then your link should be down due
>> to loopguard.  Even with a hub there, a hub is a repeater, so is ti
>> feasible to see your own stuff?
>>     
>
> Well, not really - otherwise it would be pretty hard to do "external
> loopback" solutions, as well as testing links using Ethernet loopback
> - which is still doable. I haven't seen "looped" status on Ethernet
> for a long time.
>
> I think there are several explanations for this problem:
>
> 1. Most obvious is that there is a simple loop somewhere. That needs
> to be investigated in MW configuration.
>
> 2. Don't forget that CDP is Cisco proprietary protocol. Other
> equipment usually doesn't have any special processing for these
> multicast frames. Furthermore, I have seen really bad multicast
> implementations where multicast frames would be flooded on all ports -
> including the one it was received from. This is what could be
> happening to you - MW is simply returning you back your multicast
> traffic. It *shouldn't* but it does.
>
> 3. You could be having some more creative problem, like Y-loop (you
> have A-to-B communication, but you are also getting this traffic back
> to A - A-to-A).
>
> In any case, I would focus my investigation on what's going on in the
> microwave part of the setup.
>
> --
> Marko Milivojevic - CCIE #18427
> Senior Technical Instructor - IPexpert
>
> Mailto: markom at ipexpert.com
> Telephone: +1.810.326.1444
> Live Assistance, Please visit: http://www.ipexpert.com/chat
> eFax: +1.810.454.0130
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

I've seen this behavior in 2 situations.

1) There really is a cable connecting two ports together.  Depending on 
spanning-tree configuration, this can be very bad.  The example I'm 
thinking of was the result of a patch-field where something got plugged 
in incorrectly.

2)  There's a non-Cisco vendor sitting in the middle with two ports 
connected.  I know from experience that a Foundry switch configured with 
FDP support but not CDP support will pass CDP packets through, but not 
interpret them itself.

3)  There's a device such as an IPS sitting on that port.  We have a 
client with a TippingPoint IPS that appears as a transparent bridge and 
passes the CDP packets through.  So when this is plugged into 2 ports on 
the same switch (on two different VLANs), it sees itself on the far end 
port.

Hope this and the other suggestions lets you narrow down what the 
problem is.  Please post what the end result was back to the list, I'm 
sure you have several of us curious now.

Jeremy Bresley
brez at brezworks.com