5412 switch with high cpu utilisation from mIpPktRecv

[chipmcwristy]

Hello

Ive been trying to nut down a particular problem that's been plaguing one of my client sites. About 2 months back we starting experiencing some poor network performance which we initially thought was the 5412's management module (Which it could still be), when I connect to the console of the switch while we experience the problem its cpu utilisation ranges from 50-80% consistently and I was at one point advised to go into edomtset and run ghs lt to get an overview of what was causing the high usage which seems to be mIpPktRecv at around 20-30% (Under normal circumstances cpu is around 1-3% tops). We have been able to work out by basically shutting down ports  that when the issue occurs its coming from a link to a distribution switch on another floor of the building, so if we shutdown the link the high cpu usage disappears, bring the link up within a minute or two comes back again (Additionally reboot the remote switch and problem goes away generally for the remainder of the day). To make it harder to pinpoint it doesnt happen 24/7 nor every day at a certain time no matter how much we have tried to find a pattern. So to rules a few things out after clutching at straws

- Have used a brand new switch at the remote end and the problem remains

- Have attempted to pinpoint a single device / port at the remote end but it seems to vary day to day

- Have reimaged all workstations connected to the switch in case of softare problem

- Have tried different ports and patch leads at the 5412

- Have spanning tree on at the 5412 (Also tried with it off)

- Have made sure everything has the newest firmware

The strangest part is the 5412 and 2910 have been in use for about 2 years without an issue and then all of a sudden we have this issue. We have another 9 2910's and 3 2920 on site that are all fine so Im wondering if its something in the 5412. The only other process showing high usage was InetSrv at 5-10% so not sure if thats relevant. Im not an expert on the cli side so was hoping someone has some tips or pointers for me to use to find the cause ? Any tips are grealy appreciated

P.S. This thread has been moved from Switches, Hubs, Modems (Legacy ITRC forum) to ProCurve / ProVision-Based. - Hp Forum Moderator

[Vince-Whirlwind]

What does the "mlp" in "mlppktrcv" mean, do you know?

Do you have IGMP configured on all your VLANs? Is the querier disabled on all switches except the core(s)?

What kind of switch is the remote switch?

What model switches hang off it?

What changed prior to the issue occurring, in terms of software upgrades, etc...?

What firmware does the 5412 run?

[chipmcwristy]

I think the mIpptrcv simply by the name is multicast packet recieve but dont know for sure.

IGMP is yes configured on the vlan and always has been, we recently also verified the igmp querier is disbaled on all but he 5412 core switch.

The remote switch is a 2910al-24 (Although we ruled it out more or less by putting a 2920-24 in there as well with the same result).

No switches hanging off this remote 2910, 15 computers and one printer.

Nothing hardware wise changed, we would have upgraded the firmware routinely on the fleet of switches but have multiple 2910's with the same firmware without any problems. The 5412 is running the latest we coudl find K_15_16_0005

[Vince-Whirlwind]

I wonder if the printer has IPX, AppleTalk or IPv6 running onit

[Vince-Whirlwind]

What other config do you have on your switches?
STP including BPDU protection etc; any PIM;
Any packet captures?

[chipmcwristy]

Sorry for the delayed response, but you headed me in the right direction with the ipv6 side of things. Turned out that there was a known bug in the intel nic driver in use with a particular bios revision on our fleet of desktops whereby when the affected machines went to sleep or low standby mode they would send an ipv6 flood. In itself a single machine can be handled ok, but have 5 or 10 them and things are quite different which is why it was so difficult to pinpoint as we would wake the machine of a morning automatically, and given enough time and no usage they would go back to sleep if no one was using it that day. So a combination of an updated intel nic driver and a bios patch from lenovo resolved the issues