Viptela vEdge Cloud not building control connections

[rudimocnik]

Hi

I am building a small lab on my laptop running ESXi and viptela controllers version 18.4.1.

I successfully installed vManage, vSmart, vBond as well as vEdgeCloud (one of each). I used tinyCA to sign certificates for the controllers and uploaded root certs on all components including vEdge. Every device has some initial config on with system ip, clock, org name, timezone, interfaces, (check the screenshot attached).

Next I went to PnP portal and did the following:

1. Created controller profile (with vpn0 ip add of vBond 10.0.0.3 should I be using vpn512 address?)
2. Added a device (Devices>Add Software Devices, PID:vedge-cloud-dna)
3. Associated the device with the controller profile
4. Downloaded "Provisioning File" (serialFile.viptela)

I uploaded the viptela file onto vManage and the list was pushed successfully to all controllers.

At this point I would expect for vEdge to finally be permited to join the overlay network. Considering it can ping all the controllers via vpn0 or vpn512 from and it has the root cert as well (even tho I believe this can be pushed from controllers). I also issued this command on vEdge to activate it with no luck: 

request vedge-cloud activate chassis-number 71591a3b-7d52-24d4-234b-58e5f4ad0646 token e0b6f073220d85ad32445e30de88a739

Is there a command to debug this?

Any tips would be greatly appreciated 

Rudi

[rudimocnik]

I noticed the time is way off on the vEdge compared to controllers. I statically set time on all devices. However, vEdge is still not joining.

[Edit 22.7.]

I issued all sorts of debug commands and none helped me debug the connection between vEdge and vBond. Is there a debug that can show me what is failing?

Secondly I did the Wireshark capture and I can see DTLS is failing. The good thing is the connectivity works but I am yet to find out what is causing the DTLS issue. I have re-imported vEdge list into vManage deleted and re-import CA cert into vEdge and tired to register again with the request control vedge-cloud command. ... No luck.

10.0.0.11 is vpn0 vEdge

10.0.0.3 is vpn0 vBond

[Edit 22.7.]

Looking at the output of the command below, it seems that vBond doesn't have a valid list of vSmart and vManage.

The vManage shows vBond as reachable however I noticed the "Control" is empty for vBond furthermore show control connection on vBond shows no connections. I am not sure if this is expected or not. 

[rudimocnik · Accepted solution]

So the issue was vBond wasn't accepting vEdge's chassis number. You can see this in the screenshot below (show control connection-history). This is from vEdge perspective.

The REMOTE ERROR "SERNTPRES" means vEdge's serial number or chassis-number is not present on the vBond's whitelist.

To check vBond's whitelist (see command and its output)

Next we need to check vEdge's chassis number

If you compare they are almost same, except the case. The vBond has the same chassis number only in capital letters. Si I did this same command I used before but this time I put the chassis number in caps (copy from vbonds list):

request vedge-cloud activate chassis-number 71591A3B-7D52-24D4-234B-58E5F4AD0646 token 7505cfac967c7ca0dd407caffb453462

and walaa control connections comes up.

If you wonder where did I get the lower case chassis from ...

vManage of course! 

I am running 18.4.1. version on all controllers and vedge.

[Alfonso Lopez]

Hi mocnikr,
I'm having similar trouble. Where did you find these troubleshooting commands? Were you able to find debugs for the vEdge-vBond connectivity?
Regards,

Alfonso

[rudimocnik]

Here are some of the resources I used. Also make sure the clock is synced between all your devices as well as CA if ur using your own. It best to use vManage as CA for testing. Check the tutorials below.

https://community.cisco.com/t5/networking-documents/sd-wan-routers-troubleshoot-control-connections/ta-p/3813237 (Troubleshoot)

https://sdwan-docs.cisco.com/Product_Documentation

https://codingpackets.com/blog/cisco-sdwan-self-hosted-lab-part-1

https://codingpackets.com/blog/cisco-sdwan-self-hosted-lab-part-2

[dgrinceac]

I had similar issue. At least the symptoms where very similar.

During different tests I was able to register all cloud vedges. I am confident that on the version 19.2.31 chassis ID is case insensitive. My issue was related to the fact that I didn't marked device as valid after generating the bootstrap file. Then I didn't push this information to controllers.

Here is workflow I followed after several trials and that worked pretty well for me:

1) Add basic (tiny) configuration to the vedge. Put information like system ip, site id, vbond ip/hostname, and vpn 0 relevant configuration to have ip connectivity. Validate IP connectivity with controllers if that is possible.

2) Install root chain ca on the vedge.

3) Generate bootstrap file and make sure you sent this to controllers from vmanage. Use "show orchestrator valid-vedge" command on the vbond to validate the list of devices.

4) Activate the virtual vedge by issuing command "request vedge-cloud activate chassis-number YOUR_CHASSIS_ID token YOUR_TOKEN". Not to mess up with the chassis number and token I saved bootstrap file to the file system and then simply copy pasted relevant information. It is purely optional as you can copy paste directly from vManage portal.

5) Verify the status by issuing "show control connection" or troubleshoot by "show control connections-history" and "show control local-properties"

The process to activate virtual cEdge is very similar with the small deviation in the tunnel-interface configuration and device activation.