Marko Milivojevic wrote:
On Sun, Nov 29, 2009 at 08:46, Scott Morris <[email protected]> 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: [email protected]
Telephone: +1.810.326.1444
Live Assistance, Please visit: http://www.ipexpert.com/chat
eFax: +1.810.454.0130
_______________________________________________
cisco-nsp mailing list [email protected]
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
[email protected]
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
