SD-WAN 19.2.3 - vBond create unexpected connection to vEdges

[Ruben_IT]

Hi, 

we have a SD-WAN laboratory working correctly to show to our customers

We have verified that the vBond and vEdge keep connection permanent between them.

The Cisco theory always says that the vBond connection with the vEdge are temporal.

We have seen the connection permanent in a NAT router that we have configured in the middle of connection between vbond and vedge, and we can confirm this connecion in the vBond server and the vEdge Router.

Everything is working but....

Which is the reason?, we dont understand why this connection is UP when the theory explain that this connection must goes down.

Maybe this behaviour is something about stun server?

Thanks for your help,

Best REgards,

SHOWs from devices:

vBond address:  100.0.0.3:

vEdge-1 system ip 50.1.10.1 Address:  Public IP    172.16.100.71

vEdge-2 system ip 50.1.20.1 Address:  Public IP    172.16.101.71

vEdge-3*  system ip 50.1.30.1  Address:  Public IP    172.16.102.71

CSR1Kv 

From VBOND:

vbond# show orchestrator connections

PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC ORGANIZATION INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE NAME UPTIME -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

0 vedge dtls 50.1.10.1 100 1 172.16.100.71 12346 172.16.100.71 12346 biz-internet up SD-WAN POC - 4xxx 0:01:01:18

0 vedge dtls 50.1.20.1 101 1 172.16.101.71 12346 172.16.101.71 12346 biz-internet up SD-WAN POC - 4xxx 0:01:01:19

0 vedge dtls 50.1.30.1 102 1 172.16.102.71 12346 172.16.102.71 12346 biz-internet up SD-WAN POC - 4xxx 0:00:59:55 

NAT Devices:

NAT-ROUTER#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.106.103.2:4465 172.16.103.71:4465 100.0.0.3:4465 100.0.0.3:4465
icmp 172.106.103.2:4583 172.16.103.71:4583 100.0.0.3:4583 100.0.0.3:4583
icmp 172.106.103.2:4701 172.16.103.71:4701 100.0.0.3:4701 100.0.0.3:4701
icmp 172.106.103.2:4823 172.16.103.71:4823 100.0.0.3:4823 100.0.0.3:4823
icmp 172.106.103.2:4947 172.16.103.71:4947 100.0.0.3:4947 100.0.0.3:4947
icmp 172.106.103.2:5053 172.16.103.71:5053 100.0.0.3:5053 100.0.0.3:5053
icmp 172.106.103.2:5195 172.16.103.71:5195 100.0.0.3:5195 100.0.0.3:5195
udp 172.106.103.2:12346 172.16.103.71:12346 100.0.0.3:12346 100.0.0.3:12346

From one vEdge Router:

vEdge_Router# show control connections

PEER PEER CONTROLLER PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR PROXY STATE UPTIME ID ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

vsmart dtls 50.1.1.3 10 1 192.168.1.72 12346 192.168.1.72 12346 biz-internet No up 0:01:10:55 0

vbond dtls 0.0.0.0 0 0 100.0.0.3 12346 100.0.0.3 12346 biz-internet - up 0:01:10:56 0

vmanage dtls 50.1.1.2 10 0 192.168.1.71 12346 192.168.1.71 ..................

[Ruben_IT]

Hi again,

BINGO, this was the correct debug command

i attach the file with the debug

The ORIGIN of this problem, is another problem like i have suffered int the solution.

the connectigon stay up because there is no correct connnection PING (icmp) with the VbOND SERVER, 

i have asked in other link

[Ruben_IT]

the original problem that we think that can be the source of the problem is reported in this link;

https://community.cisco.com/t5/sd-wan-and-cloud-networking/sdwan-loss-ping-vpn-0-with-2-wan-separate-transport-in-vmanage/td-p/4502812SDWAN-LOSS PING VPN 0 with 2 wan separate transport in vManage troubl. - Cisco Community

we suppose that the connection goes up, but, the icmp  in the debug is falling (vtracker) and we think that this error is the problem to dont release the connection

local7.debug: Nov 29 15:17:04 Madrid VDAEMON[1354]: vdaemon_find_next_active_wan_intf[1470]: %VDAEMON_DBG_MISC-1: Next wan interface to connect to vmanage = none
local7.info: Nov 29 15:17:07 Madrid DHCP_CLIENT[1355]: %Viptela-Madrid-DHCP_CLIENT-6-INFO-1300005: No response for dhcp discover packets for interface eth0
local7.debug: Nov 29 15:17:08 Madrid VDAEMON[1354]: vdaemon_find_next_active_wan_intf[1470]: %VDAEMON_DBG_MISC-1: Next wan interface to connect to vmanage = ge0_0
local7.debug: Nov 29 15:17:08 Madrid stray: setsockopt: Bad file descriptor
local7.debug: Nov 29 15:17:10 Madrid RESOLVD[1350]: resolv_gw_handle_ping_result[132]: Default gateway 172.16.100.1 in VPN 0 is now reachable
local7.debug: Nov 29 15:17:11 Madrid VDAEMON[1354]: vdaemon_send_tloc_info[8143]: %VDAEMON_DBG_MISC-1: Delay sending DOWN TLOC on :ge0_0
local7.debug: Nov 29 15:17:11 Madrid VDAEMON[1354]: vdaemon_send_tloc_info[8148]: %VDAEMON_DBG_ERROR-1: Delay sending UP TLOCs as the ifname:ge0_0 vsmart_connections are 0
local7.info: Nov 29 15:17:11 Madrid VDAEMON[1354]: %Viptela-Madrid-vdaemon-6-INFO-1400002: Notification: 11/29/2021 15:17:11 control-connection-state-change severity-level:major host-name:"Madrid" system-ip:50.1.10.1 personality:vedge peer-type:vbond peer-system-ip::: peer-vmanage-system-ip:0.0.0.0 public-ip:100.0.0.3 public-port:12346 src-color:biz-internet remote-color:biz-internet uptime:"0:00:00:00" new-state:up
local7.info: Nov 29 15:17:11 Madrid VDAEMON[1354]: %Viptela-Madrid-vdaemon-6-INFO-1400002: Notification: 11/29/2021 15:17:11 security-vsmart-entry-added severity-level:major host-name:"Madrid" system-ip:50.1.10.1 serial:"E48DC99732F9DEF1"
local7.debug: Nov 29 15:17:11 Madrid ZEBRA[1360]: RTM_NEWROUTE ipv4 unicast proto boot
local7.debug: Nov 29 15:17:11 Madrid ZEBRA[1360]: RTM_NEWROUTE 50.1.1.3/32 gate: 50.1.1.3, ifindex: 18
local7.debug: Nov 29 15:17:11 Madrid stray: setsockopt: Bad file descriptor
local7.info: Nov 29 15:17:11 Madrid VDAEMON[1354]: %Viptela-Madrid-vdaemon-6-INFO-1400002: Notification: 11/29/2021 15:17:11 security-vsmart-entry-added severity-level:major host-name:"Madrid" system-ip:50.1.10.1 serial:"E48DC99732F9DEF3"
local7.debug: Nov 29 15:17:11 Madrid ZEBRA[1360]: RTM_NEWROUTE ipv4 unicast proto boot
local7.debug: Nov 29 15:17:11 Madrid ZEBRA[1360]: RTM_NEWROUTE 50.1.1.2/32 gate: 50.1.1.2, ifindex: 18
local7.debug: Nov 29 15:17:11 Madrid stray: setsockopt: Bad file descriptor
local7.debug: Nov 29 15:17:11 Madrid VTRACKER[1359]: vip_execute_handle_parent[122]: [/usr/bin/timeout -k 5 10 /bin/ping -c 1 -W 1 -w 1 100.0.0.3] exited with ret: 1, output: PING 100.0.0.3 (100.0.0.3) 56(84) bytes of data. From 172.17.100.1 icmp_seq=1 Destination Host Unreachable --- 100.0.0.3 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
local7.debug: Nov 29 15:17:11 Madrid VDAEMON[1354]: vdaemon_dtls_verify_peer_cert[911]: %VDAEMON_DBG_MISC-1: Validating device certificate.. serial # (E48DC99732F9DEF3) "SD-WAN POC - ----------"

[Ruben_IT]

OK, 

this is not the reason,

We have re-configred the default-route in MPLS transport to avoid loss ping.

We have configured a summary route to connect and we have removed the 0.0.0.0/0 route.

With this change, we have recovered ping from VPN0 without loss and without specify source.

BUT, the tunnel doesnt goes down, and stay UP

and now, there is no error in the connection-history in the vEdge device

(attach show commands)

THANKs for your time, 

we follow looking for the solution

Regards

[ashok_boin]

Hi Ruben,

I don't think there could be any issue w.r.t any configurations here. It should be a software glitch in contrast to the expected behaviour in docs.

Regards...

Ashok.