Switch not learning MAC for devices that idle for long periods of time

[ChrisMorris07759]

We use Catalyst 2960X switches running 802.1X at our branch locations. With devices that idle for long periods of time, like a printer, we typically add "authentication control-direction in" to the configuration to get around them showing as unauthorized after a long period of inactivity and their authorization session has timed out. The security systems at many of our branches has its main panel connected to our switch for connectivity back to the security company, and several (but not all) of these panels will become unreachable to the security company. My hunch is its related to an idle timeout of some kind, but sometimes when the panel is unreachable there is an authentication session present in the switch but there is no MAC address seen on the port. We have to shut/no shut the port to get the MAC address to show up again and then the panel can be communicated with. As a test we removed the 802.1X configuration from one of the ports and there have been no communication issues with that panel since. We initially were adding "authentication control-direction in" to these ports since it works with printers but we did not have much success with it. It should also be noted that this particular model of panel is present at many of our branches but only a small subset of them have this issue. One was even replaced entirely and the issue persisted with the new panel.

I'm still new to 802.1X and how it works especially at the switchport level, here is what we typically run on our access ports at the branch. Would someone be able to help me identify which part of this configuration is potentially causing a problem?

interface GigabitEthernet1/0/1

 switchport access vlan XXX

 switchport mode access

 switchport voice vlan XXX

 srr-queue bandwidth share 1 30 35 5

 priority-queue out

 ipv6 nd raguard attach-policy HOST_RAGUARD

 authentication event fail action next-method

 authentication event server dead action authorize

 authentication event server dead action authorize voice

 authentication event server alive action reinitialize

 authentication host-mode multi-domain

 authentication order mab dot1x

 authentication priority dot1x mab

 authentication port-control auto

 authentication periodic

 authentication timer reauthenticate 36000

 authentication timer inactivity 60

 authentication violation replace

 mab

 snmp trap mac-notification change added

 snmp trap mac-notification change removed

 no snmp trap link-status

 mls qos trust device cisco-phone

 mls qos trust cos

 dot1x pae authenticator

 dot1x timeout quiet-period 300

 dot1x timeout tx-period 15

 spanning-tree portfast edge

 spanning-tree bpduguard enable

 spanning-tree guard root

 service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY

[Georg Pauwen]

Hello,

the default MAC address table aging time on the 2960X is 300 seconds (could be 600, verify that with the command 'show mac address-table aging-time vlan XXX).

Either way, in your case it might just be easier to just configure static MAC address entries for your printers, as in the example below. That way, the specific MAC addresses will never time out.

2960X(config)# mac-address-table static 11ca.36bbddf71 vlan XXX interface GigabitEthernet 0/0/1

[ChrisMorris07759]

I had done this with one of the panels with issues and it seems that it's incompatible somehow with 802.1X. When the panel was idle for long enough even with the static MAC entry it wasn't reachable, it was only after I removed the static MAC entry that it was reachable again. Also just to clarify, we don't have this issue with our printers as long as the control-direction command is set. It's only the security system controller that continues to experience this problem even with the control-direction command set.

[Georg Pauwen]

Hello,

I am not sure how exactly these panels work, but you might want to disable keepalives (no keepalive) on these ports, which usually causes the ports to be up/up all the time...

[ChrisMorris07759]

I can give that a shot, I looked through a "show run all" on the interfaces to see if there's a default value for that command and it doesn't appear in the output at all, not even a "no keepalive" which I thought was strange.

The interesting thing about these panels is that even when they're not accessible the port remains in the up/up state, which is another thing that's been confusing. For some context on the panels themselves, I'd say the NICs in them are on par with the most basic, "dumb" industrial controls that exist. I can't recall if we've tried this, mostly because I don't think it would work/matter, but a lot of times with NICs like these you have to explicitly set speed and duplex, usually to 10/half but sometimes 100/half or 100/full. They auto-negotiate to 100/full and like I said seem to work fine in most scenarios, there's just a handful of specific devices that have this problem.