Wired

Looking further into this it appears as if the log entries are new in 10.13.1161 and 10.16.1030  which we were not seeing before 10.13.1140 so it appears to be a functionality change in logging.

The problem I was investigating had been some clients just were not authenticating via mac-auth, no radius request was being sent and these logs had appeared at the same time so wrongly associated the two. We spent some time trying to get the clients (WAPs in this case) to authenticate, tried a different WAP still didn't work. A port that was also failing to authenticate had a data line with a very slightly broken pair 1+2 that was causing rapid flapping of the port. Once we fixed the data line the multiple ports that had been failing to authenticate started to work. 

Anyway, one of the stranger problems I've seen for a while and annoyingly I cannot be certain it was the bad data line that was the root cause. If that is the case though it's a bit concerning a bad data line can cause such a problem on a switch.

If you have a bad data line in the cable, and the switch is not receiving any data, I think the message is quite accurate. How I read it is that the switch did not see any MAC address on the port, so it can't authenticate.

What would you have expected the switch to do instead in this situation?

Looking further into this it appears as if the log entries are new in 10.13.1161 and 10.16.1030  which we were not seeing before 10.13.1140 so it appears to be a functionality change in logging.

The problem I was investigating had been some clients just were not authenticating via mac-auth, no radius request was being sent and these logs had appeared at the same time so wrongly associated the two. We spent some time trying to get the clients (WAPs in this case) to authenticate, tried a different WAP still didn't work. A port that was also failing to authenticate had a data line with a very slightly broken pair 1+2 that was causing rapid flapping of the port. Once we fixed the data line the multiple ports that had been failing to authenticate started to work. 

Anyway, one of the stranger problems I've seen for a while and annoyingly I cannot be certain it was the bad data line that was the root cause. If that is the case though it's a bit concerning a bad data line can cause such a problem on a switch.

Thanks Herman,

In the case of the bad data line it's exactly how I would expect (no MAC, therefore no auth) however we had two other ports that the lines were fine and MACs being seen but still getting the error messages and no radius auth requests. As soon as the bad line was fixed the other two ports started to authenticate without a problem.

My concern here is one bad data line appears to have been doing something to the switch that prevented other switch ports from authenticating. The failure mode of the data line was such that it was flapping very quickly so I can see it's possible to have saturated some timers/buffers/rate limits. Strangely some ports on the switch were authenticating fine, it was just a few in very close proximity to the problematic data line that had issues. Having fixed the data line I unfortunately can't go back to the broken state to troubleshoot further.

If you have a bad data line in the cable, and the switch is not receiving any data, I think the message is quite accurate. How I read it is that the switch did not see any MAC address on the port, so it can't authenticate.

What would you have expected the switch to do instead in this situation?

Looking further into this it appears as if the log entries are new in 10.13.1161 and 10.16.1030  which we were not seeing before 10.13.1140 so it appears to be a functionality change in logging.

The problem I was investigating had been some clients just were not authenticating via mac-auth, no radius request was being sent and these logs had appeared at the same time so wrongly associated the two. We spent some time trying to get the clients (WAPs in this case) to authenticate, tried a different WAP still didn't work. A port that was also failing to authenticate had a data line with a very slightly broken pair 1+2 that was causing rapid flapping of the port. Once we fixed the data line the multiple ports that had been failing to authenticate started to work. 

Anyway, one of the stranger problems I've seen for a while and annoyingly I cannot be certain it was the bad data line that was the root cause. If that is the case though it's a bit concerning a bad data line can cause such a problem on a switch.