VMware SD-WAN™ by VeloCloud® Troubleshooting: DHCP

Products

• VMware SD-WAN by VeloCloud

Issue/Introduction

This article will address several common issues encountered with DHCP when using VMware SD-WAN by VeloCloud.  Each issue will include troubleshooting solutions.
 

Symptoms:

Clients connected to a VMware SD-WAN Edge do not receive DHCP IP Addresses.

• The IP Addresses assigned to clients are outside of the DHCP address range.

• IP Addresses randomly shift between clients.

• Hosts will randomly stop receiving IP Address.

• DHCP Service stops working after a configuration change.

Environment

VMware SD-WAN by VeloCloud

Resolution

Clients connected to a VMware SD-WAN Edge do not receive an IP Address via DHCP

This is one of the most common scenarios and there a variety of potential causes.  The most common causes are:

1. DHCP is not enabled and configured at the right interface, either VLAN or Layer 3 port including sub-interfaces.

2. The number of IP Addresses configured is less than the number of users in the broadcast domain, meaning the Edge has run out of addresses to assign to clients.

3. There's a network issue somewhere between the Edge and client that is not allowing packets to pass through in one, or both directions.

Another symptom of this issue is that these same clients may end up using an IP Address in the range 169.254.x.x which was not configured at the Edge level.

169.254.x.x addresses are commonly referred to as APIPA addresses. (Automatic Private IP Addressing). APIPA is a Microsoft Windows feature and this particular symptom will usually occur in small non-routed businesses and the Windows-using DHCP clients will assign themselves an IP address and subnet mask when no DHCP server is available.

By default, clients with APIPA addresses will attempt every so often to communicate with a DHCP server. If a lease frees up, the client will request a new address and configure the new address offered by the DHCP server.

The IP Addresses assigned to clients are outside of the DHCP address range

Even after ensuring configuration details at the Edge level are correct, there may be times when this symptom is reported. One typical cause is related to the possibility of a "rogue" DHCP server in the same broadcast domain.

A packet capture at both the Edge and the client level (if possible) may help determine if another server is present on the network.

Ensure DHCP Offer packets seen at client level come with the Source MAC Address of the interface in the Edge. Note: this troubleshooting step will not be applicable if there is a DHCP relay device between of the Edge and the end user.

If packet capture options are limited at the client level, or if a DHCP Relay device is being used, there would need to be a detailed analysis of the broadcast domain.

Clients report that IP Addresses randomly shift between clients or addresses stop being handed out

This can be the result of two conditions:

• The DHCP lease time may cause clients to renew their IP Addresses too often.
• The DHCP range is smaller than the number of users in the broadcast domain.

Adjusting these parameters at the VLAN/Interface level can help alleviate the problem for clients.

DHCP Service stops working after a configuration change

One typical cause seen for this condition is while configuring custom DHCP Option values. A  combination of an incorrect Code option, Data Type and Value can cause DHCP service at the Edge to fail when initializing. Keep in mind that, options offered by the VMware SD-WAN Orchestrator below do not restrain users from adding incorrect combinations of options.

Put another way, the Orchestrator may not catch a configuration mistake while configuring DHCP custom options is one possibility for this symptom.

It is recommended that a custom DHCP option configuration is verified against the vendor specifics or RFC to use the appropriate format at the DHCP Server level, in this case the Edge.

Note: If using a Syslog server, look for the entry EDGE_DHCP_BAD_OPTION.
 

Workaround:

To fix a configuration problem, a user will need to navigate to Configure > Edges, select the appropriate Edge to modify and click on the Device tab. Note that DHCP on VLANs can also be modified at the Profile level, but any such changes here are applied to all Edges using the Profile.

On the Configure > Device page, VLAN. Identify the proper VLAN and click on it. The interface page will be displayed and at the bottom, the DHCP section will be shown for IPV4 and IPV6, example:

Depending on the symptoms identified, the user may need to employ one or both of the following strategies:

a) Expand the IP pool or range of addresses given out to accommodate the additional hosts using the Num. Addresses section. 

Another best practice is to define the DHCP start to reserve a number of IP Addresses in the subnet for static assignation and avoid having the Edge hand these out for client use. This depends on the requirements and number of clients per subnet. By default the DHCP assignment start with .13 and first 12 IP's wont be available in DHCP. User could manually edit the DHCP start address as per their requirement.

b) Reduce the lease time of those addresses, to avoid having addresses in use by clients that are no longer active on the network. The options for this section are: 15 minutes, 1 hour, 4 hours, 12 hours, 1 day and 1 week. 

In the event that the Edge is only acting as a DHCP Relay, then it is required to validate all parameters from the DHCP Server itself.

 

Additional Information

Impact/Risks:

Please consult the following article to see if any planned configuration change will be disruptive:

VMware SD-WAN Edge Configuration Changes That Can Trigger an Edge Service Restart