We have a 1335 and a 1224 with a trunked port between them. On the 1224 we have one ATM on port 5 that sporadically becomes locked out due to sticky mac port violation. We tried using a different port on the 1224 but with same results. Before moving to a new port, I made sure the mac address was not tied to the previous interfaced. The ATM machines only provide one MAC address. out of 200 ATMs, this is the only one that is doing this. We have had Diebild tech verify on site that this atm is only providing one mac address. The mac address is not configured anywhere else on the 1335 or the 1224.Not sure why the port keeps locking down. I went ahead and allowed two mac address for port 5 to see maybe if another MAC is trying to access the network from that port. Below are the configs for this location.
Thank you for posting in the Support Community. By allowing the possibility of another MAC address to connect on Ethernet port 0/5 in the NetVanta 1224 port-security configuration, you will be able to troubleshoot what is changing. If you issue the command debug port-security, you should be able to see what caused the violation (which by default will shutdown the port), and verify what state the port is in, and how it arrived in the state. For additional reference, view the Configuring Port Access Control in AOS document.
Furthermore, when a security violation occurs, you can specify what action you want to take. You can specify that the interface becomes protected, which means that the interface does not learn any new secure addresses (nor allow these new sources to pass traffic) until the number of currently active secure addresses drops below the maximum setting. You can also specify that access to the interface is restricted, which creates a log of the event in addition to protecting the port, or that the interface on which the violation has been detected is shut down and a log of the event is created.
Also, I would recommend upgrading the firmware on the NetVanta 1335 to AOS version 18.03.01.00 as there have been port-security enhancements in that version of firmware.
Please, let me know if you have any additional questions or information. I will be happy to help in any way I can.
Levi
Thank you for posting in the Support Community. By allowing the possibility of another MAC address to connect on Ethernet port 0/5 in the NetVanta 1224 port-security configuration, you will be able to troubleshoot what is changing. If you issue the command debug port-security, you should be able to see what caused the violation (which by default will shutdown the port), and verify what state the port is in, and how it arrived in the state. For additional reference, view the Configuring Port Access Control in AOS document.
Furthermore, when a security violation occurs, you can specify what action you want to take. You can specify that the interface becomes protected, which means that the interface does not learn any new secure addresses (nor allow these new sources to pass traffic) until the number of currently active secure addresses drops below the maximum setting. You can also specify that access to the interface is restricted, which creates a log of the event in addition to protecting the port, or that the interface on which the violation has been detected is shut down and a log of the event is created.
Also, I would recommend upgrading the firmware on the NetVanta 1335 to AOS version 18.03.01.00 as there have been port-security enhancements in that version of firmware.
Please, let me know if you have any additional questions or information. I will be happy to help in any way I can.
Levi
Thanks Levi for the information. Please mark discussion as answered.
Thanks for your help in this concern, I do have some more quetion concerning the debug and restrict. How much information will the debug provide for 1224 and how much of that will be forwards to the syslog server. Is this feature something that has to be iniated and then monitored via GUI or CLI until the event occurs? With the restrict feature, is there anyway to verify that the other device that is trying to gain access is not truely gaining access?
Unfortunately, debug information is not able to be sent to a syslog server at this time. Therefore, this is something that would have to be monitored via the CLI and captured via a terminal emulation program. Here is a post on how to do that: https://supportforums.adtran.com/message/2929#2929.
With the switchport port-security violation restrict command, the new address is not learned and data from that address is not allowed to pass.
Levi
Ok, setup a Tera Term session to log the debug and wsa actually able to capture the event but I did not see anthing more then;
2012.06.02 03:53:18 PORT_SECURITY.eth 0/5 has encountered a Port-Security violation
2012.06.02 14:53:16 PORT_SECURITY.eth 0/5 has encountered a Port-Security violation
Should the debug not provide something with a little bit more detail?
That is all the debug information that is displayed for the debug port-security command when a violation occurs. So, now you know that port has reached the maximum allowed and will perform the violation action it is configured for. During this violation you can issue the show port-security interface ethernet 0/5 address command to display the secure MAC addresses for that interface.
Levi
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
Levi