cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1952
Views
3
Helpful
9
Replies

strange arp behavior, which hits the CPU much

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....

2013-11-05 15_43_04-ARP-flood2.jpg

best regards,

Sebastian

10.11.0.1 is the DG of the client..

1 Accepted Solution

Accepted Solutions

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

View solution in original post

9 Replies 9

Jan Hrnko
Level 4
Level 4

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

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

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

I hope that helps..its from the beginning to until I cutted it...filtered to just arp as u mentioned..

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.

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

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

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

That was the key as I see since a few days of no APR hitting the CPU..