I have a serious problem in DHCP causing a randomly unbootable ip phones because they can not obtain an ip address or obtain wrong ip address as below:
I have NV7100 with show version output as attached.
I have two vlan in my network one for Data "vlan 3" and one for VOIP "vlan 2"
This NV7100 act as a DHCP server for voip vlan.
Another device in Data Vlan act as DHCP server for Data VLAN
Recently I have strange problem of that my IP phone could not be booting randomly because It can not obtain the right IP address "got an ip address belong to Data VLAN" or can not obtain IP address at all.
When I disabled the second DHCP server which provide ip address for Data Vlan all thing go fine with no problem.
So what may be the cause of that the IPphone obtain the wrong IP.
Kindly find the attached output of debug Ip dhcp-server command during my IP phones registeration .
Kindly find the attached output of the other DHCP server log.
All trunk ports will see broadcast traffic from any VLAN allowed over the trunk. DHCP requests are sent as broadcasts so naturally if an external DHCP server is attached to a trunk port it will see these requests. These frames would be sent to the trunk port with a tag for the VLAN ID the request came in on. If the server does not honor VLAN tags properly it would process and respond to these DHCP requests intended for a different VLAN. That would result in contending DHCP servers between it and the AOS DHCP server. Unless the external server needs to facilitate DHCP for multiple VLANs there is no need for it to be plugged into a trunk port. The sample configuration listed here will resolve that problem: . Otherwise, the server would need to be evaluated to see why it is processing DHCP traffic tagged for a VLAN that it is not supposed to participate in.
Perhaps a dumb question .... Did you include the Opt157 string in the config of your Data VLAN DHCP server. If not, give it a try and see if that perks things up.
That sure looks like the VOIP pool to me. Take a closer look at my earlier post: I had recommended adding it to your DATA VLAN scope on your DATA VLAN DHCP SERVER..
Another thing to check is that the external data VLAN DHCP server is plugged into a port set as an access port for the right VLAN. We have seen external DHCP servers ignore VLAN tags, so if they are connected to a trunk port on the unit it would result in DHCP not working from the NetVanta. Here is an example configuration assuming the external DHCP server for VLAN 3 is plugged into port 0/3 on the NetVanta 7100 :
interface eth 0/3
description DATA VLAN DHCP SERVER
switchport mode access
switchport access vlan 3
no lldp send-and-receive
oooh, yes, I got this, but what the benefit of option 157 to the Data Vlan? I know that this option is used by IPphones to reach to ftp,ntp,..etc servers.
Yes, you are right , but if we assumed that the two DHCP servers is configured locally in NV7100, how it could differentiate between the requests from the different vlans.
Short answer is this: phone sends out DHCP request on VLAN 1, then the VLAN 1 (Data VLAN) DHCP server responds with a VLAN 1 IP offer, along with opt 157. The phone interprets this response as an instruction to restart itself and sends the subsequent DHCP request to VLAN 2 so that it can be allocated a VLAN 2 ip address, along with all of the other attributes that should be allocated to a VLaN 2 device.
so why IPphone will interpret opt 157 from the external DHCP server as an instruction to restart itself and do not interpret the same opt as instruction to restart when received from NV700 DHCP server?
I guess I've never really thought about it -- same way I don't think about why water flows from my faucet when I twist it -- it just happens. My guess would be that it's embedded in the firmware of the phone. If the phone sees a different VLAN in the opt 157 that it originally booted up on, it's obligated to restart and join that other VLAN. If you take the switchport that the phone is connected to and make it a member of ONLY the voice VLAN, you'll notice that the phone boots up much quicker, as it skips the original "Vlan discovery" process.