11-05-2013 06:48 AM - edited 03-07-2019 04:26 PM
hello there,
I have a client where I can see in a trace on that client that it get a lot of arp replies. That hits my CPU of the Router to over 60%. As soon as I "shut" the port the CPU is back to normal. When I enable the client, it comes back after a while sometimes minuntes, sometimes hours..
Can anyone tell my what that is....
best regards,
Sebastian
10.11.0.1 is the DG of the client..
Solved! Go to Solution.
11-11-2013 12:31 AM
I have seen this before on our network where we had servers with teamed broadcom NICs sending out thousands of ARPs to the switch SVI and ramping the processor right up.
In the end, updating the NIC drivers resolved the issue.
We couldnt even control it as it would be random servers that would do it at random times of the day. Because the ARPs were unicast aswell we could not use anykind of rate limitation or apply any filtering.
Mario
11-05-2013 11:05 AM
Hi Sebastian,
Could you please post more comprehensive .pcap file so we can really see for ourselves, what is going on? As for that one line, I really cannot conclude anything. If you see overwhelming number of ARP replies, then there should be great amount of ARP requests from the PC in the first place.
One more thing, is that Router port connected to a LAN through another device(switch,hub)? Are any other PCs in the LAN generating so much ARP requests or is it only the case of this particular PC? Is it a server or just regular PC?
Sorry for all these questions, but it is really hard to say anything right now... we need more information first. Thanks!
Best regards,
Jan
11-05-2013 11:26 AM
Hi Jan,
the files is quiet big and i have toruble to shorten it..but I try it. I checked that already with a colleauge and we can't see anything which makes sense.
On the Switch in the debug arp I can see that:
Nov 4 07:16:35: IP ARP: arp_process_request: 0.0.0.0, hw: 0019.9983.d359; rc: 3
Nov 4 07:16:35: IP ARP: rcvd rep src 0.0.0.0 0019.9983.d359, dst 10.11.0.1 Vlan10
Nov 4 07:16:35: IP ARP: ignored gratuitous arp src 0.0.0.0 0019.9983.d359, dst 10.11.0.1 c464.132d.d4c3, interface Vlan10
Nov 4 07:16:35: IP ARP: sent rep src 10.11.0.1 c464.132d.d4c3,
dst 0.0.0.0 0019.9983.d359 Vlan10
Nov 4 07:16:35: IP ARP: arp_process_request: 0.0.0.0, hw: 0019.9983.d359; rc: 3
Nov 4 07:16:35: IP ARP: rcvd rep src 0.0.0.0 0019.9983.d359, dst 10.11.0.1 Vlan10
11-05-2013 12:18 PM
Hi Sebastian,
try to filter the file to ARP messages only or upload it somewhere on your web server and post it here as a link.
Ok so there is a switch in between the Router and the PC, right? It looks strange though, I am not sure at this point but src ip shouldn't be 0.0.0.0 - the PC does not have any IP address nor is getting one through DHCP? You didn't mention that.
The .pcap file would be really helpful I think... there are just too many questions and doubts without it.
Best regards,
Jan
11-05-2013 01:40 PM
I hope that helps..its from the beginning to until I cutted it...filtered to just arp as u mentioned..
11-05-2013 01:42 PM
The PC has a valid IP so everything look fine, just the arp is strange...and yes there are switches between the PC and the Layer3 Switch, 3750X where the SVi is installed.
11-05-2013 02:24 PM
Hi Sebastian,
would you mind posting sanitized configs of those switches as well, please? Strange enough, there is target ip address 0.0.0.0 in the arp reply and that's what puzzles me, really. There should be IP address of the PC - 10.11.5.243... and there are other strange things going on.
One more thing, do you think you could post mac address table of the switch in between?
Thanks!
Best regards,
Jan
11-10-2013 11:57 PM
Hi Jan,
Sorry to answer so late, as I get no from the remote location there are some unmanaged Switches in between and I guess there is the problem I will try to find it out and let u know when I have a result.
regards,
Sebastian
11-11-2013 12:31 AM
I have seen this before on our network where we had servers with teamed broadcom NICs sending out thousands of ARPs to the switch SVI and ramping the processor right up.
In the end, updating the NIC drivers resolved the issue.
We couldnt even control it as it would be random servers that would do it at random times of the day. Because the ARPs were unicast aswell we could not use anykind of rate limitation or apply any filtering.
Mario
11-14-2013 03:03 AM
That was the key as I see since a few days of no APR hitting the CPU..
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide