strange arp problem

[Sebastian Helmer]

Dear all,

I have an host who hits the CPU of the core switch almost once a week. Do you have any ideas how I can prevent that.           

I see at the core in the debug arp this:

Aug 25 06:31:50: IP ARP: arp_process_request: 0.0.0.0, hw: 0019.9974.c20a; rc: 3

Aug 25 06:31:50: IP ARP: rcvd rep src 0.0.0.0 0019.9974.c20a, dst 10.0.0.1 Vlan10

Aug 25 06:31:50: IP ARP: ignored gratuitous arp src 0.0.0.0 0019.9974.c20a, dst 10.0.0.1 c464.132d.d4c3, interface Vlan10

Aug 25 06:31:50: IP ARP: sent rep src 10.0.0.1 c464.132d.d4c3,

                 dst 0.0.0.0 0019.9974.c20a Vlan10

I see followd the mac by sho mac add add 0019.9974.c20a and see it on the Port 1/0/10 on Switch XYZ..

her I configured some strom-control but they are not working as I hoped. I also played with lower levels like 1% and no pps as I configured here, but also no match.

Port config where I found the mac addr.

switchport access vlan 10

switchport mode access

switchport port-security violation protect

storm-control broadcast level pps 100

storm-control multicast level 50.00

storm-control action trap

no cdp enable

no cdp tlv server-location

no cdp tlv app

spanning-tree portfast

Any comments or ideas would be nice..

regards,
Sebastian

[Rolf Fischer]

Hi Sebastian,

two approaches come to my mind:

1) DAI (Dynamic ARP Inspection) which prevents ARP-spoofing and limits ARP traffic on a switchport-level (enabled per VLAN). It requires DHCP snooping because it uses the binding table to decect ARP spoofing.

2) CoPP (Control Plane Policing) which is configured at the core and limits the amount of traffic destined to the control plane (ICMP, ARP, Routing-Protocol traffic, etc.).

I wonder what exactly the host 0019.9974.c20a does, would it be possible to do a trace on that switchport?

Regards

Rolf

[christiano.tsuma]

Sebastian,

As mentioned above CoPP would be a good choice to limit ARP traffic to the router. You need to trace down that MAC Address and figure out whether its a rogue or perhaps node with micsonfiguration.

CoPP or rate limiting will hide the symptoms but will not cure whatever host is causing your issues.

[Sebastian Helmer]

Thank you both, i agree but I want to secure the business on that remote location so CoPP is an option until I found the problem in deep.

thanks

regards,

Sebastian

[Majed Saeed]

Hi Sebastian ,

Use storm-control unicast level command in interface , because you have tried only broadcast and multicast .

R,

Majed

[Rolf Fischer]

So DAI is no option? Generally I'd recommend to implement security enforcement as close to the source as possible. Of course, you can implement CoPP in addition.

Regards

Rolf

[Sebastian Helmer]

Rolf,

it is but the location isn't really small and as far as I remeber and u mentioned in your post, DAI needs a close work between DHCP and the ARP table. I'm not sure if I could get that on-site. I have to look at that feature in deep first. It would maybe the best solution anyway, but I'm not sure as mentioned if I have the requirement for it.

I let u know!

regards,

Sebastian

[Rolf Fischer]

u mentioned in your post, DAI needs a close work between DHCP and the ARP table. I'm not sure if I could get that on-site.

DAI uses the DHCP snooping binding table to ensure that the client is using a valid IP source-address.

If you haven't enabled DHCP snooping or the client's IP-addresses are not assigned by DHCP, you can't use features like DAI or IP source guard (you could configure static bindings but that's no not really an option).

In this case, CoPP may appear as the less effort approach, but it also requires a lot of preparation as well.

Regards

Rolf