Symptom

-vEdge may not try to resolve vBond's URL using the configured secondary DNS server ip. -This issue may prevent control connection with the SDWAN controllers if the transport link fails or the connection times out. -Under vshell /var/log/tmplog/vdebug file, the following can be seen after enabling "debug vdaemon all high": local7.debug: Mar 16 18:46:38 VDAEMON[1193]: vbond_connect_to_peer_vbonds[7992]: %VDAEMON_DBG_MISC-3: Connecting to peer vbonds for wan if 'ge0_3'.. local7.debug: Mar 16 18:46:38 VDAEMON[1193]: vbond_connect_to_peer_vbonds[8074]: %VDAEMON_DBG_MISC-3: Requesting vBond DNS resolution for 'vbond-XXXXXX.viptela.net' on ge0_3.. local7.debug: Mar 16 18:46:38 VDAEMON[1193]: vip_dns_resolve_request[437]vip_dns_resolve_request local7.debug: Mar 16 18:46:38 VDAEMON[1193]: vip_dns_process_request[671]Request id: 3793 for domain vbond-XXXXXX.viptela.net local7.debug: Mar 16 18:46:42 VDAEMON[1193]: vip_dns_process_request[680]getaddrinfo failed [Name or service not known] -In one of the scenarios we saw on the field, the secondary DNS server was 8.8.8.8 while customer's primary server was a local one. -When the primary was failing, we can see that 8.8.8.8 is reachable but still unable to resolve the vBond URL: vEdge# ping vpn 0 8.8.8.8 source X.X.X.X Ping in VPN 0 PING 8.8.8.8 (8.8.8.8) from X.X.X.X : 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=101 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=107 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=108 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=116 ms ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 101.317/108.555/116.768/5.536 ms vEdge# -nslookup for the vbond is also working in the broken state: vEdge# nslookup vbond-XXXXXX.viptela.net nslookup in VPN 0: Server: Address 1: Name: vbond-XXXXXX.viptela.net Address 1: XXXXXXXXXXXXXXXXX.compute.amazonaws.com Address 2: XXXXXXXXXXXXXXXXX.compute-1.amazonaws.com vEdge#

Conditions

1.Configure 2 DNS server in vpn 0. 2.Configure primary DNS server which is not able to resolve DNS query 3.Configure seconday DNS server which is able to resolve DNS query vEdge# show run vpn 0 vpn 0 name Transport dns 8.8.8.8 secondary dns primary -A Link flap or control connection time out could trigger this issue.

Workaround

-Make the secondary DNS server which is reachable as primary: vEdge(config-vpn-0)# no dns vEdge(config-vpn-0)# dns 8.8.8.8 primary vEdge(config-vpn-0)# commit Commit complete. vEdge(config-vpn-0)# end -The control connection should come back up in a few minutes.

Further Problem Description