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
Any comments or ideas would be nice..
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?
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.
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!
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.