This topic is to discuss the following lesson:
Thanks for this great lesson.
I have a question regarding the vBond configuration.
My understanding is that the vBond only creates permanent DTLS tunnels with the vSmart and vManage and temporary DTLS tunnels with Wan Edge routers for discovery and authentication purposes. So at no point does the vBond need an IPSec encapsulation in its tunnel interface since it will never use IPSec.
So what’s the point of the ipsec encapsulation configuration under the tunnel interface ?
Sorry for the late reply. It seems that you’ve already had an answer from the Cisco community which is great!
It seems that the vBond orchestrator is the same image as the vEdge router. Technically, vBond doesn’t require the
encapsulation ipsec command but this is just the way you are required to configure it.
I hope this has been helpful!
Yes I got an acceptable answer in the Cisco Community.
i configured all devices from CLI and vmanage can reach vbond normally, but when i try to add vbon from GUI i am getting this err “Failed to add device
java.net.SocketTimeoutException: connect timed out”
I have tried to add vsmart controller as a device on vmanage however am getting errors SDWAN vSmart Failed to add device java.io. connection timeout. However i have added vbond successful and all controllers are reachable
It looks like the vSmart1 configuration has a different organization-name from the other two. It wouldn’t join properly in vManage NMS.
Thanks for pointing that out, it may be a typo. I will let Rene know to make any necessary changes.
Can you please explain why we need to configure tunnel interface to communicate between vManage ,vBond and vSmart.If we have DTLS connections between them , cant we use the physical interface.Actually if I remove the tunnel interface on vManage all the devices (vSmart,vBond) are down.Can you please explain why it behave like that ? Thanks
One of the fundamental design characteristics of Cisco’s SD-WAN solution is the fact that it uses an overlay network. This overlay network is created using VPN0 which is the tunnel interface configured in all the devices. It is also the overlay network via which all SD-WAN functionalities and mechanisms take place.
Why do we need it for the vManage, vBond, and vSmart devices to operate? Well, it’s just a matter of design. Could Cisco have designed it so that communication between these devices doesn’t go through the overlay network? Probably yes. However, I believe that they chose to deploy it like this for a couple of reasons:
- All of the vEdge devices need to communicate over the VPN0 overlay network, and will forward all of their user traffic over that same overlay network. Since communication must take place between the vEdge devices and the various controllers, it only makes sense to allow the controllers to use the same communication paths.
- In the lesson, the vManage, vBond, and vSmart are all in the same physical location. What if you want to deploy several of these in other physical locations? By using VPN0 it simplifies such communication in a scenario like that.
These are simply my thoughts about why they did it, and there may be additional reasons, but fundamentally, it is a design choice.
I hope this has been helpful!
Thanks so much for this lab.
I did the config on the vmanage but unfortunately, I cannot open it through GUI, any ideas?
Thanks and Best regards,
Can you tell us a little more about what you have done? When you attempt to open the GUI, what do you see? Have you successfully created the certificates as shown in the lesson, or was there a hitch somewhere? Let us know so we can help you troubleshoot further.
Thanks for your reply. I created the certificates exactly as shown in the lesson without any errors. Then I tried to open the IP though the browser with no success.
Is there anything else to do?
I am using also EVE Community edition.
There are a couple of things that could go wrong. Are you able to ping the IP address of the vManage controller from your PC? If you also can’t ping, it’s a connectivity issue.
Take a look at this picture:
To have connectivity between your PC and vManage directly (not through the console of EVE-NG) you need:
- Port groups in VMware ESX.
- Cloud interfaces in EVE-NG that map to the correct port-groups.
Also, if your computer is in another subnet than the subnet of your vManage controller, you’ll need to make sure vManage has a static route or default gateway to get out of its own subnet like I did here:
vmanage(config)# vpn 0 vmanage(config-interface-eth0)# ip route 0.0.0.0/0 10.1.0.254
I hope this helps!