cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8495
Views
0
Helpful
6
Replies

Invalid mac-addresses tripping port-security

swim_or_die
Level 1
Level 1

Greetings,

We are experiencing multiple port security violations from the same mac-addresses.  These addresses are not the mac-addresses of the hosts plugged into the switch port, and do not show up in the cam table or in our network management tool.  These events occur across multiple switches (6509's and 4506's) and appear to happen at random.  The events occur while the hosts are plugged into the switches.  Please review the technical information below and let me know if you have any insight.

The two most common mac-addresses are:

0000.0000.1807

422f.0000.0000

Sample switch port config:

interface GigabitEthernet4/24
switchport
switchport access vlan 11
switchport mode access
switchport port-security
switchport port-security mac-address sticky
switchport port-security mac-address sticky xxxx.xxxx.f38e
no ip address
spanning-tree portfast
end

Excerpt from logs:

Feb 17 12:20:02.524 EST: %PM-SP-4-ERR_DISABLE: psecure-violation error detected on Gi4/24, putting Gi4/24 in err-disable state
Feb 17 12:20:02.528 EST: %PORT_SECURITY-SP-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 422f.0000.0000 on port GigabitEthernet4/24.
Feb 17 12:20:02.625 EST: %PM-SP-STDBY-4-ERR_DISABLE: psecure-violation error detected on Gi4/24, putting Gi4/24 in err-disable state

switch#sh port-security int g4/24
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode            : Shutdown
Aging Time                : 0 mins
Aging Type                : Absolute
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses  : 0
Sticky MAC Addresses      : 1
Last Source Address        : xxxx.xxxx.f38e
Last Source Address VlanId : 11
Security Violation Count  : 0

6 Replies 6

Ganesh Hariharan
VIP Alumni
VIP Alumni

Greetings,

We are experiencing multiple port security violations from the same mac-addresses.  These addresses are not the mac-addresses of the hosts plugged into the switch port, and do not show up in the cam table or in our network management tool.  These events occur across multiple switches (6509's and 4506's) and appear to happen at random.  The events occur while the hosts are plugged into the switches.  Please review the technical information below and let me know if you have any insight.

The two most common mac-addresses are:

0000.0000.1807

422f.0000.0000

Sample switch port config:

interface GigabitEthernet4/24
switchport
switchport access vlan 11
switchport mode access
switchport port-security
switchport port-security mac-address sticky
switchport port-security mac-address sticky xxxx.xxxx.f38e
no ip address
spanning-tree portfast
end

Excerpt from logs:

Feb 17 12:20:02.524 EST: %PM-SP-4-ERR_DISABLE: psecure-violation error detected on Gi4/24, putting Gi4/24 in err-disable state
Feb 17 12:20:02.528 EST: %PORT_SECURITY-SP-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 422f.0000.0000 on port GigabitEthernet4/24.
Feb 17 12:20:02.625 EST: %PM-SP-STDBY-4-ERR_DISABLE: psecure-violation error detected on Gi4/24, putting Gi4/24 in err-disable state

switch#sh port-security int g4/24
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode            : Shutdown
Aging Time                : 0 mins
Aging Type                : Absolute
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses  : 0
Sticky MAC Addresses      : 1
Last Source Address        : xxxx.xxxx.f38e
Last Source Address VlanId : 11
Security Violation Count  : 0

Hi Steve,

This message means that the port manager detected a misconfiguration or misbehavior  and placed the interface in an error-disabled state. A recovery
is attempted after the configured retry  time (the default is 5 minutes). On PoE switches, this message might appear when a device that can  be powered by either a PoE switch port or by AC power is not being powered by an external AC  power source and is connected to a port that has been configured with the power inline never  interface configuration command.

You have entered sticky command in inetrface mode then  the interface converts all the dynamic secure MAC addresses, including those that were dynamically learned before sticky learning was enabled, to sticky secure MAC addresses.

The sticky secure MAC addresses do not automatically become part of the configuration file, which is the startup configuration used each time the switch restarts. If sticky learning is disabled, the sticky secure MAC addresses are converted to dynamic secure addresses and are removed from the running configuration.

Configure switchport port-security maximum 5 and if more than that number is reached then make that port to shutdown port by configuring

switchport port-security violation {restrict | shutdown} 

Hope to Help !!

If helpful do rate the post

Ganesh.H

Kevin Dorrell
Level 10
Level 10

This can happen when the attached host has a bug in the driver, and generates gash frames from invalid addresses but with a good CRC.  I have had a particular problem with this from HP Digital Sender scanner machines.  The only ways I could get over it was either to increase the number of permitted mac addresses to 2, or to set the port-security violation action to protect rather than shutdown.

If the source address is invalid, it will not get put into the CAM table, regardless.  However, it might well trip the port securioty, as you have observed.

You might also check that the port is not running with a duplex mismatch.  With some host NIC drivers this can result in aborted frames with aparently invalid MAC source addresses, but good CRC.

Kevin Dorrell

Luxembourg

oleg.bogdanov
Level 1
Level 1

Seeing the same symptoms on 3750s.  Packet trace reveals no packet with the violating reported MAC was sent.  The reported MAC is actually in the datagram of a valid TCP packet sourced from a valid MAC.  Switch seems to be interpreting that location in the packet as the start of a new packet.  TAC case open.  Awaiting resolution.

I take that back.  Problem is with the hosts' broadcom NICs (Broadcom NetXtreme Gigabit Ethernet). Turning off "Large Send Offload" in the Windows drivers seems to fix the issue.  With that feature on it seems to mangle frames and put them on the wire (with valid CRCs as mentioned above).

-Oleg

I was wondering if there was any other changes that you made because I seem to be having the same error. I tried turning off the Large Send Offload and the port still error disables.

Thanks,

Alex

Not to my knowledge.  Just disabling that setting was the fix for us.  Though I believe a reboot was required for some of the machines.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco