Unusal port security behaivor

[rekdal163]

Hi,

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

thanks!

[petenixon]

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.

[rekdal163]

Petenixon,

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.

[petenixon]

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

[Johannes Luther]

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:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556