DHCP "no_offers_received" for a specific VLAN?

Solved
cabricharme
Getting noticed

DHCP "no_offers_received" for a specific VLAN?

I am hoping it's something simple.

 

Getting "DHCP problem" type 'extra: no_offers_received, vap: 0, vlan: 255' errors in Meraki on VMs set to that VLAN 255.

 

  • All other VLANs - no issue, with VMs getting their DHCP IPs just fine.
  • The vSwitch is set up just like those for other VLANs, all default settings, with the VLAN ID triple-checked that it's set correctly.
  • Ditto, other VLANs and their DHCP configuration in Meraki: nothing stands out, no apparent differences with the problem VLAN
  • The funny things:
    • VMs set to the default "VM Network" vSwitch (with no VLAN ID set) - get their DHCP IPs from that 255 subnet. (Because that VLAN ID is highest / last?)
    • Physical devices on that VLAN - no DHCP issues. E.g. when a switch port is set to "access" with VLAN ID 255 - the devices on it will get their VLAN 255 IPs.
  • ESXi NICs are set to "trunk" on switches, with the same VLAN 255 as a "primary native VLAN"
  • DHCP, VLANs are all set up on Meraki MX (no DHCP configs on the switches)

 

I am guessing:

  • The root cause has something to do with the primary native VLAN on ESXi NICs being the same as the problem VLAN?
  • if I set the ESXi NICs to a different primary native VLAN, it'll start working? (That's certainly an option - yet assuming we need to ESXis and certain VMs on the same VLAN, what are my options? Why is the current setup not working?)

 

Thanks!

1 Accepted Solution
Mloraditch
Kind of a big deal
Kind of a big deal

You created a vSwitch that is tagging packets to vlan 255, but the switch ports you have physically connected to the hardware host are set to native vlan 255. That does not work. If you tag packets with the vlan of the native vlan on the port they are connected to the packets will never pass correctly.

Unless there is some other purpose to this new vSwitch I'd just change the vms to us the vSwitch with no tagging and be done with it. You've already stated the VMs on the untagged vSwitch work correctly with their vlan 255 IP addresses.

If you want to understand tagging more: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/C...

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.

View solution in original post

6 Replies 6
Mloraditch
Kind of a big deal
Kind of a big deal

Yes you can't tag packets with VLAN 255 if your native vlan on the switch side is 255. You either need to move the VMs to the native vSwitch or change the native vlan on the switch ports to be a vlan you aren't using tagged.

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
cabricharme
Getting noticed

Sorry I don't understand what this means.

Mloraditch
Kind of a big deal
Kind of a big deal

You created a vSwitch that is tagging packets to vlan 255, but the switch ports you have physically connected to the hardware host are set to native vlan 255. That does not work. If you tag packets with the vlan of the native vlan on the port they are connected to the packets will never pass correctly.

Unless there is some other purpose to this new vSwitch I'd just change the vms to us the vSwitch with no tagging and be done with it. You've already stated the VMs on the untagged vSwitch work correctly with their vlan 255 IP addresses.

If you want to understand tagging more: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/C...

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
cabricharme
Getting noticed


Unless there is some other purpose to this new vSwitch I'd just change the vms to us the vSwitch with no tagging and be done with it

Yes, most VLANs have group policies associated with them, and (I am guessing) a vSwitch with no tagging means no Meraki group policies applied? ("Untagged vSwitch" = no group policies, i.e. not secure - so we don't want to leave it like this?)

 

The end goal is to have a "management" or "infrastructure" VLAN for physical and virtual  devices like ESXis, IPMI, ILO, iDRAC ports, various virtual appliances like VMware replication, etc., and apply a single set of group policies to them.

 

... and looks like it's not an option to have ESXis' "native" VLAN be the same as that of a vSwitch?

 


If you want to understand tagging more: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/C...

I do, yet some of it is still flying over my head - at the moment I need something like "minimal working and secure configuration or best practice" with specific recommendations.

 

Thanks for the help!

Mloraditch
Kind of a big deal
Kind of a big deal

Meraki Group Policies are applied on the network level on either a client or vlan basis and your vSwitch being tagged or untagged has no relevance. 

If you have a  Meraki group policy on vlan 255 it will apply to all clients on that vlan no matter how they arrive on that vlan. They can be on an access port on 255, they can be on a trunk port where the native vlan is 255, they can be on your ESXi host if you had the native vlan set to (as an example) 299 and vSwitch with vlan 255 tagged. There are few more possible combinations as well.

The native vlan going to your ESXi host will work fine for a vswitch, That vswitch would just not have the vlan field defined.

It may behoove you to work with your partner (either Cisco or VMWare) or a more senior coworker if available so they can go through this with you in your environment and show you what this all looks like live.

Your goal of a management network that is isolated is generally a good one but I'd recommend consulting as I stated above or at least reading and labbing more with both the Meraki and VMWare documentation at a minimum.

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
cabricharme
Getting noticed

 


It may behoove you to work with your partner (either Cisco or VMWare) or a more senior coworker if available so they can go through this with you in your environment and show you what this all looks like live.

Your goal of a management network that is isolated is generally a good one but I'd recommend consulting as I stated above or at least reading and labbing more with both the Meraki and VMWare documentation at a minimum.

It would behoove me very much 🙂... This environment was designed by an MSP with senior VMware and Meraki specialists (before I joined the team), then was audited by said MSP - also with a senior Meraki specialist - and after that it became clear to me that figuring all this out is mostly on me.

 

Thanks again for the help.

Get notified when there are additional replies to this discussion.