A VM Gets No Network Address

A VM Gets No Network Address

The ARROW device is online, you deployed a VM onto the client network, and the VM never gets an address. In the VM console it has a 169.254.x.x address or none at all, and anything you try from inside it times out.

In almost every case the device is not the problem. The switch port the device is plugged into only accepts one MAC address, and the VM is a second one.

Why this happens

An ARROW device connects to the client network through a single cable. Every VM you deploy onto that network shares the cable but uses its own MAC address, so from the switch’s point of view a device with one VM is two machines on one port, a device with three VMs is four.

Many corporate access switches limit how many MAC addresses a port will accept. The feature is called port security, a sticky MAC list, a MAC allow list, or a single-host 802.1X or MAB policy depending on the vendor. When the device came online its MAC was learned and allowed. The VM’s MAC was not, so the switch silently drops every frame the VM sends. The VM asks for a DHCP lease over and over and the request never leaves the switch port.

Nothing on the device can work around this. It is a policy on the customer’s switch, and the customer’s network team has to change it.

Checking the port before you deploy

You do not have to deploy a VM to find out. The Switch port card on the ARROW Manager dashboard (also shown as a chip in the status strip on Virtual Machines) answers the question in advance:

• Switch: the name, model, and port number the switch advertises over LLDP or CDP, which is what the network team will ask for.
• 802.1X on port: whether the switch is running port authentication, in which case each VM also needs an entry in the customer’s NAC.
• Verdict: Accepts a second MAC address, Refuses a second MAC address, or Not yet tested.

The verdict comes from one of three sources. If a VM already holds an address on the client network, that is proof and nothing is transmitted. On a Meraki switch, which drops frames from an unlisted address rather than shutting the port, the device tests automatically a minute after boot. On every other switch the test is yours to start with Test with the next VM’s MAC: it sends three ARP requests from the MAC address the next VM will use and listens for a reply, which is exactly what a VM does when it boots.

Why the test asks first

Some switches, Cisco Catalyst in its default port-security mode among them, shut the port down when a second MAC address appears. Deploying a VM would trigger that too, so the test does not add a risk that deploying did not already carry; it moves the moment of discovery to one you chose. If it happens, the device falls back to its cellular connection, the card reports the port as shut down, and the network team re-enables the port and raises its MAC limit in the same change. The result is kept across reboots, so the port is tested once, not every time.

How ARROW Manager reports it after a deploy

ARROW Manager watches every VM it deploys onto the client network. About a minute and a half after the VM starts, if it still has no usable address, the device listens to the VM’s traffic for 30 seconds and works out which of these is true:

What ARROW Manager says	What it means
The switch port is refusing this VM’s MAC address	The VM is sending DHCP and ARP, nothing on the network answers it, and the device itself reaches its gateway on the same port. This page.
No DHCP lease for this VM	The network answers the VM’s ARP, so the port accepts the MAC, but no DHCP server offers it a lease. The DHCP server or NAC is withholding an address for an unregistered MAC; the fix is a reservation or NAC entry, not a port change.
The VM is not asking for an address	The VM sent nothing. The problem is inside the guest: the interface is down or the DHCP client is not running.
The appliance uplink is down	The device cannot reach its own gateway, so no VM can either. Fix the device’s connection first.

The verdict appears in three places:

• A red alert on the VM’s card under Virtual Machines, with the evidence, the switch’s name, model, and port number when the switch advertises them, and the exact steps for the network team.
• A notification in the bell menu, which resolves itself once the VM gets a lease.
• The Check switch port action on any running VM’s card, which runs the same check on demand. It takes about 30 seconds, or up to a minute and a half the first time after a reboot while the device identifies the switch.

ARROW Manager re-checks a failing VM every few minutes for the first 45 minutes, so once the port is fixed the alert clears on its own and the VM comes up without any action on the device.

The device never transmits as the VM

The check is passive. It only reads the traffic the VM and the switch already put on the wire. The device never sends anything from the VM’s MAC address itself, because on some switches a port-security violation shuts the port down, which would take the whole device offline.

What to send to the network team

Copy the switch name, port, and both MAC addresses from the alert on the VM’s card. The request is the same everywhere:

The ARROW appliance on switch <name> port <N> is allowed on the port with MAC <appliance MAC>.
It hosts a virtual machine that uses a second MAC address on the same port: <VM MAC>.
Please allow a second MAC address on that port, or add <VM MAC> alongside the appliance MAC.
Each additional VM on the appliance will need one more.

If you will deploy several VMs on the device, ask for the limit to be raised to the number you need rather than one at a time.

Vendor-specific steps

ARROW Manager names the switch vendor and model when the switch advertises them over LLDP or CDP, and prints the matching steps in the alert. They are collected here for reference.

Cisco Meraki (MS series)

Meraki switches are configured in the dashboard, not the CLI. The behaviour comes from the port’s Access policy.

1. Switching > Switch ports, filter on the switch, open the port.
2. Under Access policy:
   • Sticky MAC allow list: raise the limit from 1 to the number of MACs needed, or add the VM MAC to the list. The limit can be set from 1 to 20.
   • MAC allow list: add the VM MAC next to the appliance MAC.
   • 802.1X or MAC-based access policy: set the policy’s Host mode to Multi-Host or Multi-Auth for this port, or register the VM MAC in the NAC.
3. Save. The VM takes a lease within a minute.

To confirm before changing anything, open Switching > Monitor > Event log, filter on the switch and port, and look for the access-policy denial for the VM MAC. The port’s Clients view will list only the appliance.

Cisco IOS and IOS-XE (Catalyst)

On the interface:

switchport port-security maximum 2

or add the address explicitly:

switchport port-security mac-address <VM MAC>

If the port went into the err-disabled state from an earlier violation, shutdown then no shutdown it. On 802.1X or MAB ports, use authentication host-mode multi-host or multi-auth, or register the MAC in ISE.

Check with show port-security interface <port> and show authentication sessions interface <port> details.

Aruba and HPE

AOS-Switch: port-security <port> learn-mode static address-limit 2, or add the MAC with port-security <port> mac-address <VM MAC>. AOS-CX: port-access port-security client-limit 2. For MAC-auth ports, raise the client limit or add the MAC in ClearPass.

Juniper (Junos)

Under switch-options interface <port>, raise interface-mac-limit to 2 or more, or add the VM MAC under allowed-mac. For 802.1X, set supplicant multiple.

Ubiquiti UniFi

Devices, select the switch, Ports, open the port. Under Port Security, add the VM MAC to the allowed list or turn port security off for the port. If 802.1X control is on, set it to Auto with multi-host, or add the MAC to the RADIUS MAB list.

Fortinet FortiSwitch

Raise set max-mac-count on the port’s security policy or add the MAC. For 802.1X, use MAC authentication bypass and register the VM MAC.

Any other switch

Look for port security, a MAC limit, a sticky or allowed MAC list, or an 802.1X or MAB policy in single-host mode on the port. Raise the limit to 2 or more, add the VM MAC, or change the host mode to multi-host.

If the port cannot be changed

Some networks will not allow more than one address per port as policy. Your options are:

• Deploy the VM on the cellular bridge instead. On a device with a cellular modem, a VM on the cellular bridge is NATed out through the modem and never appears on the client network, so the switch never sees its MAC. The VM is still reachable over the ARROW VPN. See VM Deployment.
• Ask for the appliance to be moved to a port without the limit, such as a port intended for a small switch or an access point.

A static IP on the VM does not help: the switch drops the frames before any address matters.

Related Documentation

• VM Deployment
• Receiving a Device: site conditions that block the device
• ARROW Manager Troubleshooting
• Static IP for a VM