Like you, I have seen "looped" in a long time on ethernet, but I haven't
really had a need to test an ethernet port like that in forever!
Assuming that works in the same fashion that it does on a serial line,
the router will detect "looped" by virtue of receiving its own
keepalives back. Not by CDP or any higher level frames.
I don't recall loopguard being turned off (from doing the L2 Tunneling
entertaining configurations) but I haven't verified that! After you (or
Joe) mentioned it being turned off, I got to thinking about it though.
The looping caused there was from a CDP frame being received on a
DIFFERENT port (same switch though) where it would think of it as an STP
failure...
I'm still leaning towards duplicate configurations as it's the simplest
answer to create this difficulty. While it COULD be a more inane
design-related thing, those are typically more obvious when someone
attempts to figure out why a problem is occurring.
Just my two cents. :)
*Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M #153, JNCIS-ER, CISSP, et al.
JNCI-M, JNCI-ER
evil_at_ine.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
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
Blogs and organic groups at http://www.ccie.net
Received on Sun Nov 29 2009 - 08:33:08 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:29 ART