Port security offers three violation mode options:

protect—Drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the maximum value.
restrict—Drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the maximum value and causes the SecurityViolation counter to increment.
shutdown—Puts the interface into the error-disabled state immediately and sends an SNMP trap notification.

Protect and restrict behave the same w/r/t forwarding behavior, but restrict generates log messages and a counter, and protect does not. I can't see why I wouldn't want that information, in case I need to troubleshoot or verify operation.

Is this just a case of an old option hanging around despite a newer and better alternative? Or is there some scenario I'm not thinking of where the log entries and counters would be a problem?

  • Also, to add to Ron's answer. There is a method of deploying Port Security that allows the ports to auto recover after a certain amount of hours. In those deployments, you may not care about the log messages and are content with the network auto recovering from error conditions, and/or when the correct device is reconnected to the switch. From a security and audit trail point of view, however, it is probably always wise to log when you can.. – Eddie Apr 11 '16 at 4:18

It really depends on your philosophy and resources. You can quickly fill a switch log with violations, making it hard to troubleshoot real problems (switch logs can only be so big). You really need to use a separate logging server with something like this.

You want to log violations. To some people it is enough to just drop the traffic. In some cases, the extra overhead and traffic of logging a lot of violations is too much, or they may not have the logging infrastructure necessary to take advantage of it. The three different modes give you the flexibility to choose.

  • I suppose you could be in a situation where you expect tons of violations ask the time. I was assuming a setup where violations are unexpected. – P1h3r1e3d13 Apr 9 '16 at 14:38
  • 1
    There are many different network designs out there. You shouldn't get stuck in a single way of thinking. It's alright to prefer one way over another as a best practice, but don't limit yourself, especially when you work on other networks. That could lead you to want to completely redesign a working network, and that usually isn't worth the risk and/or cost it poses. – Ron Maupin Apr 9 '16 at 14:43
  • Of course there are. I've just never had cause to use port security outside of an academic or lab context. I'm trying to find out how it's used in the real world. – P1h3r1e3d13 Apr 9 '16 at 14:48
  • That was the point of my comment. Many networks are done "on the cheap," without the benefit of a good supporting infrastructure, like a logging server. A network may also already be overloaded, close to overloaded, or the owners may not want to design for the extra overhead of extra traffic to a logging server. It can also be frustrating while troubleshooting a problem to have the switch logs filled with violations which keep incrementing, while you are looking for something else. – Ron Maupin Apr 9 '16 at 14:57
  • 1
    Personally, I think the best practice is to shut the port down until you can investigate why there are violations. Often, it can be from users connecting unauthorized equipment (switch, hub, WAP, etc.), which presents a security risk to the network. Forcing a user to ask for help to restore the network allows you to discover the situation. – Ron Maupin Apr 9 '16 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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