VOIP Vlan DHCP conflict

[most_ahdy]

Hi,

  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.

Thanks,

Mostafa Aly

[jephph]

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.

[most_ahdy]

I am already configured it kindly find it

[jephph]

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..

[Anonymous]

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

  no shutdown

  switchport mode access

  switchport access vlan 3

  no lldp send-and-receive

!

Thanks,
Matt

[most_ahdy]

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.

Thanks,

Mostafa Aly

[most_ahdy]

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.

Thanks,

Mostafa Aly

[jephph]

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.

[most_ahdy]

  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?

Thanks,

Mostafa Aly

[jephph]

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.

[Anonymous]

When the following DHCP option is set with ,Layer2Tagging=True,VlanID=2 it will cause the phone to reboot and send a DHCP request via an 802.1Q frame tagged with the specified VLAN:

option 157 ascii TftpServers=0.0.0.0,FtpServers=10.10.20.1:/ADTRAN,FtpLogin=polycomftp,FtpPassword=password,Layer2Tagging=True,VlanID=2

As jephph suggested if the port is hard set to an access port (not a trunk port) only for a particular VLAN, a DHCP request will get sent only for that VLAN and in theory be processed by the DHCP server also in that VLAN.  If you set all of the ports the phones are plugged into as access ports for the voice VLAN you lose the ability to connect a PC to the port on the back of the phone.  This is typically used when there is only one cable drop from the wiring closet to an office so the same cable can be used for the phone and the PC.

There should not be more than one DHCP server in each VLAN or they will conflict.  I have seen many instances where a network device of some sort (wireless router, switch, etc) had DHCP enabled and no one was aware of it.  All network devices should be checked for DHCP, especially if you ever see phones randomly not boot up properly. 

The other common issue is servers are ignoring VLAN tags as explained in my response above: .  Again, the solution to that is to configure the port the external DHCP server is on as an access port in the appropriate VLAN.

Thanks,
Matt

[most_ahdy]

Hi Matt,

   Could you please explain the below in more detail.

matt wrote:

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. 

Thanks,

Mostafa Aly

[Anonymous · Accepted solution]

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.

Thanks,
Matt

[Anonymous]

Mostafa,

I went ahead and flagged this post as "Assumed Answered".  If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,
Matt

[most_ahdy]

Hi Matt,

  Thank you for your reply , I think there is some issue with the forum , replies to my post no longer forwarded to my email, I have to check the forum periodically.

so the point is :

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.

There is some thing wrong in my external DHCP server it belong to native vlan and it replies to tagged DHCP request.

But as a note, my external DHCP server is a normal pc , could Network Interface Card of this pc understand the tagged traffic?this confuse me , I have an understanding that NICs of pcs can not understand Tagged traffic so it should ignore it and drop it.

Thanks,

Mostafa aly

[Anonymous]

Mostafa,

I would suspect that is something that is configurable for the adapter settings and depends on the manufacturer and current drivers loaded for the NIC.

Thanks for letting me know about e-mails not going through.  I have not heard that complaint from anyone else, but it appears some mail server changes happened recently.  You may need to have your e-mail administrator white list the e-mail servers listed on our page in the Help section.

Thanks,
Matt

[Anonymous]

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Matt