01-19-2016 08:45 AM - edited 03-17-2019 05:33 AM
I am used to declaring a PC/phone switchport combination such as:
switchport access vlan 1050
switchport mode access
switchport voice vlan 2005
trust device cisco-phone
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQos-4.0-CiscoPhone-Input-Policy
service-policy output AutoQos-4.0-Output-Policy
This registers phones correctly on the Voice subnet I've defined and also assigns the correct subnet to the PC.
Printers are declared like:
switchport access vlan 1101
switchport mode access
spanning-tree portfast
Phones connected to these switchports are also able to connect successfully to CUCM but will receive an IP address in the wrong subnet.
Any thoughts on why this is happening?
Unfortunately, we're using Novell to issue DHCP addresses.
Thanks much.
Solved! Go to Solution.
01-19-2016 10:06 AM
Most llikely, you have option 150 setup on data DHCP scope so when these phones send out DHCP request, it is grabbing IP from data subnet and registering with call manager with data subnet vs voice subnet.
-Deven Gandhi
*Please rate all useful post
01-19-2016 10:08 AM
Hi Thats what i would expect to happen the phone will receive an ip address whether vlan is correct or not thats what will happen in most standard setups the question is why are you plugging phones into a data vlan thats not set for voice ,Its nothing to be concerned about either dhcp server has no concept of command voice vlan
01-19-2016 10:06 AM
Most llikely, you have option 150 setup on data DHCP scope so when these phones send out DHCP request, it is grabbing IP from data subnet and registering with call manager with data subnet vs voice subnet.
-Deven Gandhi
*Please rate all useful post
01-19-2016 04:59 PM
Both Deven and Mark are correct here. The Novell DHCP server administrator probably defined the Option 150 that tells a phone how to reach CUCM at a global level instead of only within the scopes that cover the voice subnets. They can certainly change that if they feel like it; even Microsoft supports it and any modern Novell install is running on SUSE which probably leverages dhcpd like any other GNU/Linux system on the planet.
Additionally, in the absence of DHCP 150, 66, or the rarely known about default DNS query a phone will default back to the last config it had in memory and use the servers defined there. In other words, even if the DHCP server isn't handing out a DHCP Option 150 at all, the phone will still register if it has ever done so before.
Lastly, as Mark was saying, the voice VLAN was only invented to prevent companies from having to redesign their entire network subnetting, including every statically assigned device, to deploy IP phones. Think about it for a moment: your /24 DHCP scope is 70% exhausted and you need to deploy 150 phones within that same network segment. Without a voice VLAN you would be forced to change the subnet for the entire network segment. It was a essentially a way to remove objections to VoIP originally; however, other decisions got made after that invention including that lazy brat AutoQoS. It bases the conditional trust model for physical phones off of the presence of an 802.1p CoS header which can only exist because of the Voice VLAN concept which introduces an 802.1q header.
01-20-2016 09:09 AM
Great points. Thanks, Jonathan.
01-19-2016 10:08 AM
Hi Thats what i would expect to happen the phone will receive an ip address whether vlan is correct or not thats what will happen in most standard setups the question is why are you plugging phones into a data vlan thats not set for voice ,Its nothing to be concerned about either dhcp server has no concept of command voice vlan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide