10-23-2003 10:08 AM - edited 03-13-2019 02:13 AM
I recently ran into a problem while deploying 30 new 7940 and 7 new 7960 phones. These phones were connected to three different 3550 switches. The port configurations on these switches is:
description user port
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,1002-1005
switchport mode trunk
switchport voice vlan 2
no ip address
spanning-tree portfast
Even though the phones were supposed to be running on VLAN 2, they were getting DHCP addresses from VLAN 1. The "Network Configuration" menu on the phones showed an "Operational VLAN ID" of 2 but they would not communicate. The only way we could get these phones to come up was to set the switch ports to access mode and make them members of VLAN 1.
Once the phones upgraded their software from the factory P0030301MFG2 to P00303030200, I could re-configure the switch ports to their original dot1q trunk configuration and everything worked fine.
It seems to me that there is a problem between the original firmware and the 3550 switch. Has anybody else experienced this problem?
11-03-2003 08:13 AM
In 3.3 by default ip phones cnf files are not written into the tftpath so it might well be that you have the old file there and that the new one is stored in memory. So it looks like the 7940 and 7960 bunch that you recieved still had factory settings from Cisco.
11-05-2003 02:28 PM
The problem, as I saw it was that the phone never even got to the point of requesting its config becuase CDP and/or IP was not working correctly. The phone showed that it should be on VLAN 2 but was getting and IP address off of VLAN 1. The phone was never even getting to the point of trying to get its config from CallManager becuase it wasn't communicating with the network properly.
11-05-2003 04:27 PM
Here's an interesting tid-bit. I have had a similar situation w/ wireless clients. Currently I have four VLAN's per site...1 for management, 1 for data, 1 for voice and 1 for wireless. The wireless clients would end up pulling addresses from various IP subnets.
After a few days of working w/ TAC, turns out that because I had Superscopes (1 for each site) and then had the four individual scopes within it...the Wireless clients would pull from the first available scope.
Take the superscopes away....works like a champ.
Again...it's a long shot that you're doing this...but hope it helps!
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: