VMware Cloud Community
DoratheExplorer
Enthusiast
Enthusiast
Jump to solution

DHCP NACK Vlan tagging

Hi,

We put VLAN tagging on our VI3 servers and noticed when we build a new VM (from a template) it has issues with obtaining a new IP address.

We currently only have a couple of VLAN port groups defined.

The DHCP server is on one of these VLAN's that are defined on the ESX host.

DHCP is showing NACKs for the VM server trying to obtain a new address.

A couple of reboots and changing the Ethernet Adapter to a dfiferent Network seems to resolve, but can't see why it initially doesn't get a new IP address.

Any ideas ?

Thanks.

Reply
0 Kudos
1 Solution

Accepted Solutions
bertdb
Virtuoso
Virtuoso
Jump to solution

the packets generated by VMs are just tagged when they leave the box (more accurately, when they enter the vswitch). And when receiving a frame, it is untagged before it is presented to the VM. So the VM is unaware of the VLANs, and the VLAN behaviour doesn't affect MAC addressing or doesn't induce packet filtering.

Can you check whether your switches have something like a "default VLAN" ? Some switches have this, and when set to a certain VLAN number, they will send the packets for that VLAN \_untagged_ over trunk ports (like the link(s) to the ESX server). The ESX doesn't handle that the way those switches do. They put received untagged packets in the default VLAN, and ESX has no default VLAN. So if you have that feature on your switches, you need to use an unused VLAN number as the default on your physical switches.

View solution in original post

Reply
0 Kudos
3 Replies
bertdb
Virtuoso
Virtuoso
Jump to solution

the packets generated by VMs are just tagged when they leave the box (more accurately, when they enter the vswitch). And when receiving a frame, it is untagged before it is presented to the VM. So the VM is unaware of the VLANs, and the VLAN behaviour doesn't affect MAC addressing or doesn't induce packet filtering.

Can you check whether your switches have something like a "default VLAN" ? Some switches have this, and when set to a certain VLAN number, they will send the packets for that VLAN \_untagged_ over trunk ports (like the link(s) to the ESX server). The ESX doesn't handle that the way those switches do. They put received untagged packets in the default VLAN, and ESX has no default VLAN. So if you have that feature on your switches, you need to use an unused VLAN number as the default on your physical switches.

Reply
0 Kudos
DoratheExplorer
Enthusiast
Enthusiast
Jump to solution

Well it appears that the native vlan was defined as one of the tagged vlan's I was using. Changed and the problem seems to of gone away.

What I'm confused with is the native vlan should only be used for untagged packets i.e those that do not have an ethernet adapter assigned.

As all the VM's were assigned network cards, why did it cause the grief.

Thanks for your help. Got the network guys thinking.

Reply
0 Kudos
bertdb
Virtuoso
Virtuoso
Jump to solution

this is the situation: you have a cable that carries ethernet frames, and for outgoing packets, the ESX attaches a tag with the VLAN number to each frame. The physical switch recognizes the tags and puts the packets in the correct VLAN.

For incoming packets, the same mechanism would work.

Only, the physical switch has this concept of a native VLAN. When it would receive an ethernet frame without a tag, it will interpret that as being in the "native" VLAN. However, it never receives untagged frames because the ESX tags all frames.

The problem is that when the physical switch sends frames that are in the native VLAN, it doesn't attach a tag to those frames either. It expects the receiving switch to "know" that untagged frames are in that special (configured) VLAN number. But the ESX virtual switch doesn't have that concept, and doesn't understand where those untagged frames need to go. It will refuse to put them in any VLAN, and so they won't arrive at their intended destination.