09-18-2019 02:12 AM - edited 09-20-2019 02:20 AM
I've started performing firmware upgrades on the PCoIP thin clients that my company uses, but during the restart phase of the upgrade the port security on the switch gets triggered and puts the port into err-disabled state.
Here's an example config from a port that connects to a thin client (all ports connected to thin clients are configured the same):
interface GigabitEthernet0/7 switchport access vlan 10 switchport mode access switchport port-security switchport port-security mac-address sticky switchport port-security mac-address stick xxxx.xxxx.xxxx vlan access spanning-tree portfast end
So yeah, I don't really know why a port would get disabled when the thin client reboots as part of a firmware upgrade. When one is rebooted or turned off normally it does not trigger the port security. Are there any logs I can look at that might tell me? The MAC address doesn't change, which was my first thought when I started looking into this.
All switches are C3560 running IOS 12.2(55)SE5.
Thanks!
Solved! Go to Solution.
09-18-2019 04:45 AM
and the default violation action is to errdisable the port. You can change the violation action so that the port doesn't erridsable.
09-18-2019 02:19 AM
Hi there,
When you encounter one of these incidents can you share the output of:
sh int status err-dis
sh port-security
cheers,
Seb.
09-18-2019 03:06 AM - edited 09-18-2019 03:07 AM
Hi,
From show interfaces status err-disabled:
Port Name Status Reason Err-disabled Vlans Gi0/16 PCoIP err-disabled psecure-violation
From show port-security:
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) --------------------------------------------------------------------------- Gi0/16 1 1 1 Shutdown
Thanks.
09-18-2019 03:58 AM
Any other devices attached to same interface on the switch?
Try entering "show port-security address" and see if the MAC matches up with the MAC on the device.
09-18-2019 04:39 AM
Hi there,
Try adding:
! switchport port-security maximum 2 !
...to one of the effected switchports. It could be that the PCoIP device shares its ethernet interface with a remote management function like Intel vPro.
cheers,
Seb.
09-18-2019 04:45 AM
and the default violation action is to errdisable the port. You can change the violation action so that the port doesn't erridsable.
09-18-2019 05:38 AM
I've seen a similar bug on 3750Gs (which are just 3560s with stackwise capability--essentially).
I'm sure it sounds really silly but try this before your next firmware upgrade. Go to the interface for the PCoIP client you're going to upgrade and enter "no switchport port-security" and "switchport port-security" (clear the command and then put it right back). Last time I had a similar bug, where sticky macs weren't being learned correctly and ports were erroring out unpredictably, rebooting the stack did not help, but manually clearing out the port-security command and reissuing it on every interface (with a "range" command once I'd verified it was a fix) resolved the problem forever. I think I was running 12.2(40)SE2 at the time...
Please rate and mark if this is helpful! Thanks!
-Zac
09-20-2019 02:18 AM
In case anyone comes across this, I decided to work around the issue by following cmarva's suggestion of changing each port's violation action from the default "shutdown".
I decided to use the "protect" violation action, and since this will still disallow unauthorized devices from connecting by dropping their packets, it is a suitable solution.
Thanks.
11-06-2020 07:45 AM
So I just had this issue upgrading a 3560, and it caused a restriction of a MAC-address of a connected 9200 switch. It was difficult to determine the cause of the issue because the port did not register a violation, the only indication that we had was a server to server connection not working and anything from the 9200 switch would not respond to the server connected to the 3560. We are probably going to use Zach's advise and try to look at resetting the port security.
We had upgraded form 12.2.50SE3 to 12.2.55SE12. Although we have to back it down to 12.2.55SE9 because of a bug that does not allow the logging to register the IP address, it comes up as UNKNOWN.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide