MAC addresses showing up twice on same VLAN, disappears after port-security is enabled

[pheavens85]

So basically we have a VOIP setup with the PC connecting to the back of the phone. Nothing fancy. I wanted to turn port security on to only allow the phone and the PC to prevent hubs from being connected.

i notice when I check out the MAC addresses associated with that port that the phones VLAN is showing up in both the VOIP and Data VLAN

(81 is the Data VLAN. 126 is the VOIP VLAN)

Switch01#show mac address-table | i 1/0/8

  81    0024.7edb.3336    DYNAMIC     Gi1/0/8

81    0060.b955.dec6    DYNAMIC     Gi1/0/8

126    0060.b955.dec6    DYNAMIC     Gi1/0/8

After talking to colleauges we've just assumed this has something to do with the phone acting as a switch. I assumed that enabled 2 MAC addresses on the port woul dbe ok, as there are 2 MAC addresses, its just one of them is showing up twice.

When I enabled port-security, the port worked(i.e no security violation) BUT the phone MAC address appearing in the Data VLAN dissappeared.

Switch01#sh mac address-table | i 1/0/8

  81    0024.7edb.3336    STATIC      Gi1/0/8

126    0060.b955.dec6    STATIC      Gi1/0/8

Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action

                (Count)       (Count)          (Count)

---------------------------------------------------------------------------

    Gi1/0/8              2           2                  0         Shutdown

Thought this was a bit wierd. The act of turning on port-security seems to stop the MAC addresses form showing up but does not cause any effect on the port.

Now this line in the debug shows me exactly what I'm looking for: It's the MAC address that is now missing in VLAN 81:

Apr 12 06:54:45.878: PSECURE: swidb = GigabitEthernet1/0/8 mac_addr = 0060.b955.dec6 vlanid = 81

Can't rreally determine exactly what its doing, but this MAC addresses does not get associated with the port on the switch.

I suppose what I'm getting at is: Why does this MAC address go into the data VLAN? And why does it disappear after port-security is enabled when it is not causing a violation?

[rsimoni · Accepted solution]

Hi there,

I suppose that your switch is either a Cat2k or a Cat3k (a DSBU switch).

What you see is pretty normal as the IP phone keeps on sending untagged CDP frames which are learned by the switch on the data vlan (81 in your case) while it also send tagged frames (126) for voice traffic.

Not all platforms hanlde the learning of such untagged CDP frames the same way; some of them learn it while some other don't. Port-security feature might be affected by such difference, as in case the phone MAC is learned in the data vlan we need 2 mac-address for the phone and 1 for the PC behind it.

Bug "CSCea80105    inconsistent MAC counter w/ & w/o port-security; voice vlan " addressed this inconsistency.

The release notes include a broader explanation of what you see. I highlighted in red the part relevant to your question.

Symptom:
When a Cisco IP phone is connected to the switch, its MAC address is learned on both the PVID and the VVID. However, when the dynamic MAC addresses are flushed either manually or automatically due to topology change, or enabling/disabling of the port security or 802.1x feature, the IP phone's MAC address will only be re-learned on the VVID.

Condition:
The Cisco IP Phone is connected to a Cisco Catalyst 2970, 3560, or 3750.
The Cisco IP Phone is using software that does not contain the fix for CSCed84163.

Additional Information:
When configured for a Voice VLAN, the phone sends untagged CDP packets and tagged voice packets.  All frames from any devices connected to the IP Phone will be sent tagged with the access VLAN ID.

Catalyst 2940, 2950, 2950-LRE, 2955, and 3550 switches populate the secure address-table with the source MAC address from CDP packets.
Catalyst 2970, 3560, 3750, 4500, and 6500 switches do not populate the secure address-table with the source MAC address from CDP packets.

When using IP Phones with the fix for CSCed84163 and port-security configured on the switchport:
Catalyst 2940, 2950, 2950-LRE, 2955, and 3550 switches should be configured with a maximum of 2 secure addresses for the phone, plus additional MAC addresses for any devices connected to the IP Phone;
Catalyst 2970, 3560, 3750, 4500, and 6500 switches should be configured with a maximum of 1 secure address for the phone, plus additional MAC addresses for any devices connected to the IP Phone.

When this issue is resolved, the Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560, 3750, 4500, and 6500 will not populate the secure address-table with the source MAC address from CDP packets from IP Phones when the interface is configured with a Voice VLAN.The Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560, and 3750 will populate the secure addres-table with the source MAC address from CDP packets in all other cases.

regards,

Riccardo

[pheavens85]

Thanks for the response. The bug that you've linked to appears to be exactly what I'm seeing.

However I've had some problems with putting port-security that may or may not be related... I put the following port-security configuration on our switch:

switchport port-security

switchport port-security maximum 2

These ports are for NEC phones connecting to our network with PC's connecting out the back.

As soon as I rolled out the config I had several problems with phones shutting due to security violations.

Several onsite techs attanded and found that the phones would shut down when the PC was connected. I thought perhaps it was due to additional MAC address (as we mentioned above) missing from the mac table, so i increased the number of addresses allowed on the port to 5, shut, unshut and the port again went into security disable... There was definently no more than 5 MAC addresses on the port, but the act of plugging in the PC to the back of the phone would activate the port security shutdown.

Not sure if it is related but it seems to be something to do with just enabling the port security. I'll try to lab it and might start another topic if I don't think its the same bug.

[rsimoni]

indeed the new issue seems to be something else. The bug after all is not properly a defect but an harmonization of a behavior that was not consisent across cisco platforms.

keep us posted with the debug results from the NEC phones, and yes if you confirm that it is something else, as it seems now, go for a new post.

Riccardo