1

We have a couple of Cisco 9300 switches. We had the switch configured using STIGS. A couple users have complained that their Avaya phones restarted. I started running the show logs and noticed the following:

Sep 11 19:25:00.133 GMT: %PM-4-ERR_RECOVER: Attempting to recover from storm-control err-disable state on Gi2/0/22
Sep 11 19:25:00.821 GMT: %ILPOWER-5-DETECT: Interface Gi2/0/22: Power Device detected: IEEE PD
Sep 11 19:25:01.820 GMT: %ILPOWER-5-POWER_GRANTED: Interface Gi2/0/22: Power granted
Sep 11 19:25:05.110 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/22, changed state to up
Sep 11 19:25:06.110 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/22, changed state to up

Sep 12 11:06:13.036 GMT: %SW_DAI-4-PACKET_RATE_EXCEEDED: 17 packets received in 207 milliseconds on Gi3/0/24.
Sep 12 11:06:13.036 GMT: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi3/0/24, putting Gi3/0/24 in err-disable state
Sep 12 11:06:14.037 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/0/24, changed state to down
Sep 12 11:06:15.037 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet3/0/24, changed state to down
Sep 12 11:08:13.030 GMT: %PM-4-ERR_RECOVER: Attempting to recover from arp-inspection err-disable state on Gi3/0/24
Sep 12 11:08:14.423 GMT: %ILPOWER-5-DETECT: Interface Gi3/0/24: Power Device detected: IEEE PD
Sep 12 11:08:15.443 GMT: %ILPOWER-5-POWER_GRANTED: Interface Gi3/0/24: Power granted
Sep 12 11:08:18.639 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet3/0/24, changed state to up
Sep 12 11:08:19.639 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/0/24, changed state to up

Sep 12 11:53:23.761 GMT: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 29 milliseconds on Gi3/0/14.
Sep 12 11:53:23.761 GMT: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi3/0/14, putting Gi3/0/14 in err-disable state
Sep 12 11:53:24.761 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/0/14, changed state to down
Sep 12 11:53:25.763 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet3/0/14, changed state to down

Most of the ports of configured as follows:

interface GigabitEthernet3/0/24
description PC
switchport access vlan 1234
switchport mode access
switchport nonegotiate
switchport block unicast
switchport voice vlan 60
switchport port-security maximum 3
switchport port-security mac-address sticky
switchport port-security mac-address sticky xxxx.xxxx.xxx1 vlan voice
switchport port-security mac-address sticky xxxx.xxxx.xxx2
switchport port-security
storm-control broadcast level 40.00
storm-control unicast level 80.00
storm-control action shutdown
spanning-tree portfast
spanning-tree bpdufilter disable
spanning-tree bpduguard enable
spanning-tree guard root
end

Not sure if raising the storm-control levels while still complying with STIGS would solve the problem.

Improve this question
1
  • My first instinct is to capture the traffic on that port to see exactly what's going on. It could be a bad host tripping the very things you want tripped.
    – Ricky
    Sep 13 at 17:42

1 Answer 1

Reset to default
0

While the first message from your log excerpts hints at storm control being the culprit .....

Attempting to recover from storm-control err-disable

... the latter occurrences are a clear hint that Dynamic ARP inspection thinks it's too much noise:

Sep 12 11:06:13.036 GMT: %SW_DAI-4-PACKET_RATE_EXCEEDED: 17 packets received in 207 milliseconds on Gi3/0/24.

Sep 12 11:06:13.036 GMT: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi3/0/24, putting Gi3/0/24 in err-disable state

So ...

Not sure if raising the storm-control levels while still complying with STIGS would solve the problem.

I dont' think so. I would think storm control and Dyn. ARP Inspection are entirely different things. If at all, you might have to tweak DAI's thresholds, which seems to be possible on the Catalyst 9300 (Link)

ip arp inspection limit {rate pps [burst interval seconds] | none}

However this is intriguing:

switchport block unicast

That's essentially disabling Unknown-Unicast-Flooding on this port. Be sure to understand the implications of this, especially for ARP traffic throughout these two broadcast domains (PC VLAN and Voice VLAN).

A looong shot: Could UUF blocking possibly indirectly force your end devices to ARP at increased rates, in turn crossing DAI's ARP thresholds, triggering the errdisable-by-arp-inspection?

spanning-tree bpduguard enable

spanning-tree guard root

...These two together are somewhat mutually exclusive. guard root, in order to do its job and prevent the port from becomig the root port -implies that the port would first have to receive/ingest a BPDU and look at it - but by that time, bpduguard will have shut down the port already.

Improve this answer
4
  • I was told once to set no spanning-tree bpdufilter. What would you recommend I try?
    – Rick
    Sep 13 at 15:36
  • @Rick no spanning-tree bpdufilter essentially disables STP for that port - so loops go unnoticed. You should only ever do so if BPDUs are disturbing proper link functions and you are dead sure there can be no loop.
    – Zac67 ♦
    Sep 13 at 18:02
  • I'm about to just change to storm-control action trap for the time being for the storm control errors at least.
    – Rick
    Sep 14 at 12:10
  • The default setting for ip arp inspection limit for the Cisco 9300 is 15 pps. I notice that I can only set per interface. What rate would be recommended to not raise the level too much?
    – Rick
    Sep 19 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.