LLC / CDP Flood

OK help please.

On wire shark I am seeing 200+ packets a second coming from a single device for CDP/LLC. At first it looked easy and tracing the source mac back to a Mitle phone I first rebooted the device, then shut down the port when that did not help.

But I am still seeing 200+ packets a second arriving at my PC with the port in a shut down state.

two questions,

1. On a 3com switch will shutting down a port stop CDP/LLC traffic??

2. Assuming it does, which means this traffice is coming from a different source, how do I track it down? Every thing seems to lead back to the same port/device in the logs.

Cheers

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

DevilWAH

Oh things get stranger...

1. unplugged the phone from switch X that has the mac address in question. but still seeing that packets coming in to wire shark.

2. Created an ACL on the core switch to deny this mac address and applied it to the interface connected to switch X in the incoming direction (towards CORE). Packets stop in my capture. So it is deficiently coming from the switch to which the phone in question is attached.

3. Switch X does not have the mac address in its CAM table, or any where I can see in its configuration, and the phone is no longer attached. So how is is still sending

34067    577.721079000    Mitel_4d:55:bb    CDP/VTP/DTP/PAgP/UDLD    CDP    121    Device ID: SEP08000F4D55BB  Port ID: Port 1
34072    577.739294000    Mitel_4d:55:bb    CDP/VTP/DTP/PAgP/UDLD    CDP    121    Device ID: SEP08000F4D55BB  Port ID: Port 1
34073    577.739903000    Mitel_4d:55:bb    CDP/VTP/DTP/PAgP/UDLD    CDP    121    Device ID: SEP08000F4D55BB  Port ID: Port 1

??

And why the Hell is 3COM such a pain to trouble shoot compared to CISCO, I don't care if CISCO cost twice as much I will be strongly suggesting that when we come to upgrade the core it is to cisco and not HP/3COM.

networker050184

The packets could possibly be looping. Remember, the frames are forwarded via destination address. For CDP this is a multicast address (that escapes me at the moment) and there is not a TTL value in a L2 frame that prevents looping. Sounds like maybe the switch lost its mind or something else is happening...

DevilWAH

networker050184 wrote: »

The packets could possibly be looping. Remember, the frames are forwarded via destination address. For CDP this is a multicast address (that escapes me at the moment) and there is not a TTL value in a L2 frame that prevents looping. Sounds like maybe the switch lost its mind or something else is happening...

01:00:0c:cc:cc:cc

I have a feeling this might be the issue, Planing a reboot on the switch to see if that cures there issue as tried restarting things like CDP, lldp etc with no joy.

its creating about 250Pks so if i can't stop it in the next hour it gets a reboot at home time

One good thing about this is its a great example for my business case to move away from a flat network with servers and users on the same VLAN...

And the case for moving to CISCO, honestly trying to see what is going on with 3COM is terrible. even trying to filter the mac address table for a single address is a hassle. unlike CISCO where you can do some thing like "show mac-address table | in 55bb" with 3COM you have to put in the whole mac address in the correct format... a pain when jumping from device to device.

DevilWAH

Just a bit more on this,

the link back to core is on a aggrated group of 2 ports

G1/0/28 and G2/0/28

shutting down G1/0/28 does nothing

shutting down 2/0/28 Stops the error!

So I am thinking maybe a bad SFP, might try swapping that out before I reboot the device.

networker050184

Well keep in mind the way traffic is forwarded over links in a bundle. It will be hashed and a single link will be used for certain traffic.

DevilWAH

networker050184 wrote: »

Well keep in mind the way traffic is forwarded over links in a bundle. It will be hashed and a single link will be used for certain traffic.

But then I would expect that once I shut down the currently used link it will fail over to the remaining link. and the error would show there.

What I am seeing is that if I have port A up only there is no error showing... If I have Port B up only I get the error..

so each time an agrated link with a single member. one port good other port bad.

networker050184

That makes sense, but I can't see a SFP being responsible for something like this but I suppose anything can happen.

DevilWAH

I agree, I doubt it will fix anything.

I have a feeling I will reboot the switch later and all will be fine, and I will never know the exact cause

But I will Swap the SFP just in case as that will avoid a complete reboot if it does happen to work

DevilWAH

Jsut to catch up on this its all solved now.

I did try a SPF swap out but as expected no change...

Thankfully this is a stack of 6 switch's and I had a few ports dotted around spare. So I moved the current live ports of the second switch in to others in the stack (second switch was the one which ahd the affected uplink port) and still seeing the error.

Then rebooted the single switch and problem gone with out any user down time

I think it will have to go down as one of those issues that I will never know the exact cause but a looping issue due to bug in code I am sure would not be a bad guess. For now will just monitor to insure it dose not come back!

Cheers for the help.

Aaron