Port Security and MAC address table

[Edwin Summers]

BLUF:  Does port security using sticky MAC addresses (on a 3750 platform) also affect the switch's MAC address table, or is port security entirely separate from the MAC address table?

Background:

I ran into an issue with two firewalls in an active-passive HA configuration.  Each firewall (call them FW-primary and FW-secondary) is connected to a separate stack of 3750 switches (SW-primary, SW-secondary).  They are singly connected, FW-primary to SW-primary and FW-secondary to SW-secondary.  SW-primary and SW-secondary are interconnected via a L2 trunk.

The issue was that some end-user traffic was being black-holed.  Investigation found that only the end-user traffic that was connected to SW-secondary was having problems, and revealed that SW-secondary's MAC table had an entry for the shared Firewall gateway IP pointing towards FW-secondary, instead of the inter-switch trunk.  Further investigation revealed that sticky MAC port security was enabled on the firewall-facing switch interfaces, and that the interface on SW-secondary facing FW-secondary had sticky-learned the gateway MAC address.  Initial resolution was to clear the sticky MAC learning on the interface, and traffic immediately began flowing correctly.

I was under the impression that port security was entirely separate from the MAC table.  The documentation I have read is a bit ambiguous, as it does not directly say that sticky-learned MAC addresses will be added as permanent (static) entries to the MAC address table.  However, some previous posts on this forum seem to indicate that sticky MAC addresses will also be added to the MAC address table as static entries, and will not age-out unless port security aging is enabled.

Can someone confirm the operation of port security in relation to the MAC table?  In one respect, it seems prudent from a security perspective to have them linked.  If you expect to learn one (or a few) MACs on a port and not have them change, then the switch should also always send traffic for that MAC to that port (to avoid a MAC spoof/take-over).

Thanks for any insight!  Links to documentation appreciated as well.  Unfortunately my lab is unavailable for the week so I cannot test at the moment.

[Peter Paluch · Accepted solution]

Hello Edwin,

I was under the impression that port security was entirely separate from the MAC table.

No, it is not. Secure MAC addresses, either dynamic, static or sticky, are placed into the MAC address table. Static and sticky secure addresses will also be put into the running-config. However, these addresses are not in some separate table because despite their secure status, forwarding traffic to these MAC addresses must be as efficient as forwarding traffic to any other address known by the switch. Hence, these addresses must be placed into the MAC address table.

However, some previous posts on this forum seem to indicate that sticky  MAC addresses will also be added to the MAC address table as static  entries, and will not age-out unless port security aging is enabled.

Yes, this is correct. Secure MAC addresses will be added to the MAC address table as static addresses unless port security aging is enabled.

Please feel welcome to ask further.

Best regards,

Peter

[Edwin Summers]

Thanks, Peter - very helpful.  Mainly looking for solid confirmation that sticky secure addresses are added as static entries.  Literature seemed to suggest as such, and I appreciate your confirmation.  It does make sense from a DoS/MitM point of view.  You wouldn't want the traffic directed to another port due to ARP spoofing.

Thanks!

Ed

[Peter Paluch]

Hello Edwin,

You are very welcome!

There is also another aspect to adding the secure MAC addresses to the MAC address table: If an address learned or configured on one secure interface is seen on another secure interface in the same VLAN, it is considered a security violation. The reason is that a secure MAC address is not supposed to move or to be hijacked by another device. Learning a MAC address that is already associated to a different secured port is therefore considered a security violation.

Best regards,

Peter