Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Unusal port security behaivor


since we implemented port security a couple of years ago we have seen some odd behaivor on a few occasions, where a port will go err-disable for psecure-violation. when we go look at the source mac that caused the issue there is some garbage mac address like 0000.0000.0001 involved. just chalked this up to static or pfm as security cameras footage showed no physical access. however a couple of days ago we had a switch lock down 4 ports inside of a couple of seconds. logs show no access to the switch, physical security was also checked with no access shown. any idea what might cause something like this to happen ? We are running  WS-C3560G-48PS switches on the 12.2(55)SE1 software.

I have attached logs

I think you will quickly see that existing mac addresses somehow became associated with the wrong ports on the switch, therby disabling those ports.

the log shows all activity for that day, I would have expected to see a port down for both ports involved if it were a physical move but that is not the case so somthingelse is at work here.


any feedback is appreciated



Everyone's tags (1)
New Member

The ports will enter into a

The ports will enter into a state of err-disabled because the default max addresses allowed is one. If you change the maximum number of macs learned on the interface, the port will no longer drop.

New Member

Petenixon,thanks for your


thanks for your reply.

I understand the reason the switch is shutting the port, what I do not understand is why it is seeing this second bogus mac address on a port that has not changed state.


New Member

If you can attach a topology

If you can attach a topology diagram, we can work out why smiley

Pretty old post - but here's

Pretty old post - but here's some feedback for documentation purposes.

Typically I encounter this in lab environments, where virtual clients (ESXi) are used. So you have switch port towards an ESXi server port, which is mapped to a vSwitch.

In the "Teaming and Failover" settings inside the corresponding vSwitch, set the option "Notify switches" to "No".

This will prevent the sending of those bogus frames with the MACs 00:00:00:00:00:01 - XX (RARP frames).

The technical description, why these frames are sent is documented here:

CreatePlease to create content