For many years we've had the following vlan and port security config on our 3560s:-
switchport access vlan 520
switchport mode access
switchport voice vlan 560
switchport port-security maximum 2
switchport port-security maximum 1 vlan access
switchport port-security aging time 5
switchport port-security violation protect
switchport port-security aging type inactivity
This has worked great on 12.2(37)SE1, 12.2(40)SE and 12.2(46)SE. However since 12.2(50)SE, and I've tried all the versions since then, we have a problem with 7900 phones and ATA186s taking upwards of 20 minutes before they can get a valid IP number.
The problem on the newer IOSes seems to be related to the inactivity aging.
On the older IOS versions the mac address of the voice device appears on the voice vlan straight away.
On the newer IOS versions the mac address of the voice device appears on the DATA vlan and seems to be stuck there until the inactivity aging removes it. It then gets re-learned, sometimes on the voice vlan, and sometimes on the data vlan. If you're unlucky and it gets re-learned on the data vlan you've got to wait until the inactivity time ages the address out again. Repeat until the mac address eventually gets learned on the voice vlan.
Any ideas on how I can fix this problem, or if it's a known bug? I don't want to be stuck on 12.2(46)SE forever.
It seems you are suffering IOS bug CSCta73593. Please see bug details:
|port-security in 12.2(50)SE is not working properly with IP phone.|
1) Mac address behind the phone will not be secured when the PC removes even before the cam aging expired.
When port-security is enabled, if the PC connected to the back of the phone removed, the CAM entry of the PC will removed from the CAM table immediately before the CAM aging time expired. The CAM entry of the PC will populate again in the CAM table when the PC reconnects to the back of the phone.
The problem only happens with the following combination:
3560 with c3560-ipbase-mz.122-50.SE1
7941/61 with SCCP41.8-4-3S
-Downgrade to release earlier than 12.2(50)SE such as 12.2(46)SE
It is triggered by a new feature enabled in 12.2(50)SE. The new feature is called host presence.
Cisco IP phones with old firmware have no ability to notify the switch of link state changes on the IP phone's access port. When a device attached to the access port is disconnected or disabled administratively, the switch is unaware of the change. Cisco IP phones with new firmware (8-4-x) can send a CDP message containing a host presence type length value (TLV) indicating the changed state of the access port link. To recognize the host presence TLV, the switch must be running Cisco IOS Release 12.2(50)SE or later release.
It is still opened so I suggest downgrading to an old IOS or opening a Cisco TAC for recommendation.
Thanks for the reply.
However I don't think this is my issue. My problem also occurs on phones without PCs connected through them and on ATA186s, which don't even have ports to allow you to connect a PC to them.
I have a similar problem. I use a Cisco 2960 with IOS 12.2(50)SE5. I have several phones on the network, over 80. My 6911, 7945, and 7965 phones work perfectly but my 7937 gets stuck at "Configuring VLAN" - it doesn't go beyond that stage.
Could you recommend any solution for me? I don't want to downgrade the IOS to a lower version!
As I raised the original question I thought it might be useful to let you know what happened to us.
We escalated the issue through TAC and the problem wasn't bug CSCta73593. In fact the problem wasn't with V12.2(50)SE and later. It was actually the earlier versions that had the bug, which we'd been exploiting without even knowing it.
The Cisco documentation states than when a trunk is in port security violation protect mode it stops learning MAC addresses across all VLANs when any one of the VLANs hits its defined maximum addresses. So when the port learnt the 1 MAC address on the access vlan it stopped learning addresses on the voice vlan.
IOS 12.2(46)SE and earlier had a bug where this stopping of learning didn't happen.
So as the behaviour we were seeing was "as documented" we had no choice but to change to port security violation restrict mode.
Thanks a million for the update, Jonathan.
However, I'm not using port security at all on any of my switches - so this can not be my issue. I still wonder why I have problems with only the conference stations (7937) and all other phone types work ok?
It is a new deployment.
Could you please try removing the voice VLAN setting on the port and check what happens?
i.e. if you have VLAN10 for data and VLAN20 for voice, try this on the ports with 7937 phone connected:
no switchport voice vlan 20
switchport access vlan 20
I've tried that already. As a matter of fact, it was the first thing I tried because we don't want a data VLAN on conference station phones since it is in the conference room and it is not tied to anyone we can hold responsible. When "switchport access vlan 50" (VLAN 50 being my voice VLAN) didn't work, I tried "switchport voice vlan 50" but it is still not working.
Have you tried in a different switch model and/or IOS? If yes, you could sniffer the traffic of the phone with Wireshark and check what messages the phone is sending and receiving.
I'm yet to try with another switch. All my switches (except for the 2960s we just got) are not PoE...so I've not been able to toy with that. However, I'd try getting another switch and try the Wireshack option too.
My conference phones are now working perfectly. I realized the conference phones do not have a way of locating the firmware - so the path to the firmware has to be defined for the phones to work well. The other phones (6911, 7945 and 7965) can locate the firmware on their own, but not the conference phone!
I think Cisco needs to build the same kind of intelligence in other phones to the conference station as well.