How does vBond notice a change in Global IP?

[yutashimamura2920]

I understand that vBond is facilitating the Tunnel connection between vManage and cEdge.
To establish a tunnel connection, both vManage and cEdge need to know each other's Global IP, and vBond provides this information.

In the architecture in the attached image, if the Global IP is changed on the FW side(no change on SD-WAN device), how can vBond notice the change?

If it is a Global IP change on sd-wan device, I believe vBond would be aware of it.
I would like to know how vbond notices when the Global IP is set on the FW side and changes the Global IP, and how to set up a Tunnel Session.

[M02@rt37]

Hello @yutashimamura2920,

vBond is not directly aware of changes to the Global IP address of external devices like firewalls, the IPsec tunnel and control-plane communication between cEdge routers and the vBond orchestrator remain unaffected by such changes. The key is that the cEdge's system IP address, used for secure communication and tunnel establishment, remains static regardless of the Global IP address changes on the cEdge or the firewall.

[yutashimamura2920]

Thank you for your reply! M02@rt37 

Is the Global IP information unnecessary to set up a TLS Tunnel Session between vManage and cEdge?

I was thinking that in order to set up a TLS Tunnel Session between vManage and cEdge, vManage and cEdge would need to know each other's Global IP.

[M02@rt37]

@yutashimamura2920,

As I know, in a Cisco SD-WAN deployment, the cEdge routers use a static system IP address for secure communication and tunnel establishment. This system IP address remains constant regardless of changes to the Global IP address assigned to the cEdge or external devices like firewalls. As a result, changes to the Global IP address of the firewall should not impact the IPsec tunnels or control-plane communication between cEdge routers and the vBond orchestrator. The cEdge's system IP address remains stable for communication with orchestrators.

[yutashimamura2920]

M02@rt37 
Thank you for your comment!
As the comment from @Kanan Huseynli , when public IP is changed, control-connection-state-change between vManage and cEdge should be down -> Up?
 But, as you said, System IP remains constant regardless of changes of Global IP.
Thank you!

[David Ruess]

I believe you may be referring to TLOC information. The TLOC route is sent via OMP from the Edge to vSmarts. I haven't tested it but I believe a change in address would prompt an update of the TLOC information. See below:

• TLOC routes advertise Transport Locators of the connected WAN transports, along with additional attributes such as public and private IP addresses, color, TLOC preference, site ID, weight, tags, and encryption keys.

-David

[Kanan Huseynli · Accepted solution]

Hi,

when global - public IP is changed, router traffic goes with new address (new to NAT) to controllers (in normal state, you have only connection to vsmart and vmanage from router's perspective). But this traffic with new IP address and controllers don't have this control peer, thus ignored for some time. As a results, controllers don't see hello traffic from router's previous IP and also router does not see hello from controllers (because un-NAT does not work for previous IP). Results is : control traffic is down.

Router tries to re-establish control connections, however in this case it should first go to vBond then other controllers. By this way, other controllers and vBond know new IP address.

Below relevant flap case, when external NAT IP is changed. In vShell, tail -f /var/log/vsyslog should show:

Aug 28 20:07:01 vmanage VDAEMON_7[5839]: %Viptela-vmanage-vdaemon_7-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"vmanage" system-ip:1.1.100.2 personality:vmanage peer-type:vedge peer-system-ip:1.1.1.1 peer-vmanage-system-ip:169.254.10.5 public-ip:172.20.2.1 public-port:12366 src-color:biz-internet remote-color:biz-internet uptime:"0:00:02:01" new-state:down
Aug 28 20:07:21 vmanage VDAEMON_7[5839]: %Viptela-vmanage-vdaemon_7-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"vmanage" system-ip:1.1.100.2 personality:vmanage peer-type:vedge peer-system-ip:1.1.1.1 peer-vmanage-system-ip:169.254.10.5 public-ip:172.20.1.111 public-port:12366 src-color:biz-internet remote-color:biz-internet uptime:"0:00:00:00" new-state:up

[yutashimamura2920]

@Kanan Huseynli 
Thank you for your comment and detailed explanation！
Let me make clear my understanding..
1. Change the Public IP address of the FW
2. TLS Tunnel between vManage and cEdge is down.
3. cEdge try to set control connection with vManage
4. cEdge try to connect to vBond, and give the Global IP address of FW and Private IP.(STUN Server : vBond, STUN client : vEdge)
5. vBond provide the global IP to vManage.
6. controll connection between vManage and cEdge is established.

is the above flow is correct?

[Kanan Huseynli · Accepted solution]

1. Change the Public IP address of the FW
2. TLS Tunnel between vManage and cEdge is down.
3. cEdge try to set control connection with vManage
4. cEdge try to connect to vBond, and give the Global IP address of FW and Private IP.(STUN Server : vBond, STUN client : vEdge)
5. vBond provide the global IP to vManage.
6. controll connection between vManage and cEdge is established.

Almost true but 2 points:

At step 4, vBond knows global IP by source IP of packet, also vBond can understand that device is behind NAT and provides public IP and port back to cEdge

At step 5, vBond does not provide public IP or port of cEdge to controllers (vmanage/vsmart), the opposite happens, vBond already knows public and port IP of vManage and vSmart and provide this information to cEdge, so sEdge can initiate traffic to controllers. (vBond is also STUN server for controllers).

Below is from CVD:

"Any SD-WAN control component or SD-WAN router may be unknowingly sitting behind a NAT device. Knowing what IP address/port to connect to from outside the network is crucial to successfully establishing control and data plane connections in the SD-WAN network. The SD-WAN Validator plays a crucial role and acts as a Session Traversal Utilities for NAT (STUN) server, which allows other control components and SD-WAN routers to discover their own mapped/translated IP addresses and port numbers. SD-WAN devices advertise this information along with their TLOCs so other SD-WAN devices have information in order to make successful connections."

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html#SDWANValidatorasaNATTraversalFacilitator

Also, as mentioned in last sentence,cEdge will advertise its own public IP/port as part of TLOC route so other routers can aware.

[yutashimamura2920]

@Kanan Huseynli ＠Thank you for your clarification
Let me ask one more quesrtion.

>vBond does not provide public IP or port of cEdge to controllers (vmanage/vsmart), 
To establish the control connection between vManage and vEdge, vManage have to know the Public IP address of cEdge or FW and cEdge have to know vManage Public IP address, right?
vManage don't have to know the new Public IP address of cEdge and FW?

I have thought vBond is the role to notify the public IP address of vEdge or FW to vManage.
If my understanding is wrong, I would appreciate it if you could let me know!

[Kanan Huseynli · Accepted solution]

This action is not needed, because vmanage will know it when vedge initiates connection to vmanage.

Edge router initiates connection, so vmanage will know it by dataplane (based on incoming traffic). vManage does not initiate connection. For NAT (pre and port IPs) it is necessary who initiates traffic. If vManage would, then yes there is need somehow to send that information to vmanage also, but there is not such step.

[yutashimamura2920]

@Kanan Huseynli 
Thank you!
I understand.