On premises vBond design

[SaidB]

Hi all,

I'm trying to wrap my head around the on premises vBond design.

I was reading the Cisco SDWAN design guide, and couldn't understand the reason why you would need a secondary vBond on the public internet if you have an on-premises vBond that is only reachable through the private MPLS.

I'm talking about this :

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

It says : 

"In deployment B, the controllers are reachable only through the private MPLS. An additional vBond is deployed on the Internet and acts as a STUN server for WAN Edge devices with Internet access and redirects them to the private controller IP addresses "

Why do we need the internet vBond to redirect WAN edge devices to the private vBond in the private MPLS ? In figure B, we can see that the WAN Edge device has connections to both transport, MPLS and internet. Why don't we just provide the WAN edge device with the on-premises MPLS-reachable vBond  IP address and voila !

Any insight would be highly appreciated.

Thanks

Said

[Kanan Huseynli]

Hi,

imagine you have scenario B, but you don't have vbond as STUN server. Here what happens:

router tries to establish control connection to configured vbond over internet interface (note that outer knows vbond using running-configuration, you should define vbond by IP or hostname) and it fails (because interface interface can't reach vbond IP private).

Note: you may ask question, why it cant reach? router has routing to vbond's IP (that is private) over mpls TLOC (inteface) in VPN0.

The answer is: one interface cant use another interface to reach controllers, it should have its own connection over itself.

When control connection to vbond fails over any interface, that interface can't reach vsmart, so TLOC can't be considered as valid.

However, if you use vbond as stun server, then router reaches vbond (that acts as STUN in reality) and TLOC can be considered valid.

I haven't done lab based on this scenario, but this is the general logic. Even, looks like you should define in interface that vbond over this interface acts as stun.

See what is written in command usage:

No overlay network control traffic is sent and no keys are exchanged over tunnel interface configured to use the Cisco vBond orchestrator as a STUN server. However, BFD does come up on the tunnel, and data traffic can be sent on it.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-sdwan-tunnel-interface-cmds.html#reference_vt3_ld4_qnb

HTH,

[SaidB · Accepted solution]

Hi Kanan,

Thank you for your reply.

It made me realize something : a vBond in the private MPLS network with no connectivity to the internet cannot act as a STUN server, that's why we need a second vBond that would act as the STUN server.

So what happens here is that the edge router that has 2 transports (MPLS and internet) would need first to connect to the public vBond STUN server through its public transport interface. If the edge router is behind a NAT the public vBond STUN server will provide the edge router with its internet transport interface post-NAT ip address + the private vBond ip address. 

Now the edge router will be able to talk the private vBond through its MPLS transport, receive all the vSmarts and vManage information it needs + it would be able to connect to the vSmarts and provide them with complete TLOC routes information, including the post NAT IP address on its internet transport interface. Without the public vBond STUN server, the last part wouldn't have been possible, and the other edge routers wouldn't be able to create data-plane ipsec tunnels towards the edge router public transport interface, as they wouldn't have known its post-NAT IP address.

Thank you again

Regards

Said  

[Naseer Anjan]

I think, you can mark it resolved one since you explained it already that why vBond has to be in dedicated zone and communicated with NAT public IP by other SDWAN components.