DHCP Option 119 in VMware SD-WAN by VeloCloud Edges

Products

• VMware VeloCloud SD-WAN

Issue/Introduction

The DHCP server on some VCE's hands out option 119 with values that interfere with clients that need to reach resources via short DNS names. 

Environment

The environment in which the issue is seen:

• Customer enterprise using a public DNS (for example, Google.com)
• Edges with DHCP setting enabled under a VLAN or routed interface with an explicit DNS Search Path (DHCP option 119) not been defined.

Cause

For edges with DHCP setting enabled under a VLAN or routed interface with an explicit DNS Search Path (DHCP option 119) not been defined, when the edge or client in the LAN tries to resolve a hostname an unqualified (for example: hostname) or partially qualified (for example: hostname.corp) DNS name, the Edge incorrectly tries to look up that name under .nyansa.com, which will always return the address app.nyansa.com, which is incorrect for this case.

The nyansa hostname is associated with VMware SASE's Edge Network Intelligence application.

Corresponding logs:

testedge#ping "hostname"
PING app.nyansa.com (52.26.148.183): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- app.nyansa.com ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss


testedge#ping "hostname.subdoman.domain.com"
PING hostname.subdoman.domain.com (10.1.1.2): 56 data bytes
64 bytes from 10.1.1.2: seq_seg=0 ttl=249 time=22.3 ms
64 bytes from 10.1.1.2: seq_seg=1 ttl=249 time=21.4 ms

Resolution

 There's a simple workaround, define an explicit DNS Search Path (option 119) for each enabled DHCP server (on a VLAN or a routed interface) on the impacted edge. This will take out the naynsa defaults.

Additional Information

Issue was fixed in software 5.0.0.0 and the later versions.