Cisco SD-WAN vEdge Onboarding

This topic is to discuss the following lesson:

Hi Rene,

We need more documents on SDWAN like creating policies/Templates (CLI/GUI) TLOC/TLOC Extensions/Local and Centralized Policies etc.,

When we can expect… Please update us…

HI Rene,
I have watched and read ur SD-Wan lectures till onboarding vedge
I have couple of doubts may sound dumb but asking anyway
Let me explain how i understood so u can clarify

1.Hardware level
In actual hardware the vEdge will be a actual hardware router which is compatible with the SDwan image
But what about vsmart, vbond and vmanage are they actually 3 seperate hardware we have to take console of in real life scenario

  1. Certificate
    (ROOT CA is like a ideal certificate to compare with so that we can trust as it matches the private key we generated)-this is my understanding till now
    Like lets say i am generating a vedge CSR using command
    request csr upload home/admin/vedge1_csr
    and then copying it to vmanage and then signing it in vmanage and then copying it again from vmanage to vedge using
    vEdge1# request download scp://admin@10.1.0.1:/home/admin/vedge1.crt

Then whats the use of copying ROOT CA in vedge at the first place as we signed the vedge certificate in Vmanage and then copied it to vedge and installed it in vedge
request certificate install home/admin/vedge1.crt

so why should we install the ROOT CA certificate anywhere other than vManage as the certificates are signed in vManage

3.Default Route
we are giving default route in the controllers in the switch and the vedge so that all the components are reachable to each other

DC switch : ip route 0.0.0.0 0.0.0.0 10.65.91.254
All 3 controllers : ip route 0.0.0.0/0 10.1.0.254

vedge towards routed interface :
ip route 10.1.0.0/24 10.65.91.100

Here what i dont get is about the vEdge interface “ge0/1 ip adress”

interface ge0/0 can reach 10.65.91.100(default gateway) as its ip adress is 10.65.91.1/24
They are in same subnet

But what about interface ge0/1 ip address 10.65.92.1/24
They are in different subnet right
How can 10.65.92.1/24 reach the default gateway 10.65.91.100 /24

4 . TLOC color
color is used by the vedge to understand the difference between 2 links i suppose

But whats a TLOC (fullform of TLOC to get better understanding) that part is bit shady
Whats the significance of the keyword color

Thanks RENE
it was awesome till now
hoping u reply all my 4 doubts

Hello Athi

Rene is currently working on a series of lessons on SD-WAN. They’ll be coming out over the next couple of weeks. Some have already been published. Check back periodically at the following page to see all of the new lessons that are coming out:

I hope this has been helpful!

Laz

Hello Anoop

The vEdge routers and the vBond orchestrator can be deployed as either hardware or VMs. The vManage and vSmart controllers are only available as VMs. The VMs can be run on-premises on ESXi or KVM, or they can be hosted on cloud providers like AWS or Azure. Take a look at the following lesson for more details:

You must first generate the CSR on the vEdge router. This creates a file stored in the /home/admin folder of the vEdge router. That file can only be created by the vEdge router. It is unique to that router. This file must be signed by the vManage controller, and then installed on the vEdge router. If you skip the creation of this file on the vEdge router, then the certificate process will not take place correctly.

Yes, it seems that the topology is incomplete. There is no information about the 10.65.92.0/24 subnet, and there is no info about the configuration of vEdge2. I will let Rene know to clarify.

A TLOC is a transport locator, similar to an RLOC used in LSIP. A TLOC contains the following data:

  • System IP, which is the “label” given to the particular controller, much like a router ID is given to an OSPF router
  • Transport colour, used to differentiate different transports or links, like you mention
  • Encapsulation type, which includes information about data plane connectivity. This can be either IPSec or GRE. For example, a GRE TLOC will not establish a data plane tunnel with an IPSec TLOC. They must be the same.

More information about TLOCs can be found at the following Cisco documentation:

I hope this has been helpful!

Laz

Hey everyone I am stuck on the step to add vedge…
(vbond,vmanage,vsmart all seem to be up and recongnized…

I have went through the this adding vedge step 3 times… and stilll have come up short…

when i got into the vmanage GUI … I dont see anything listed under WAN edge list !! please help !

Hello Brent

There are several things that may be going on here. I assume that you’ve already confirmed that you are reproducing the commands in both the vManage1 and the vBond1 controllers with the correct chassis numbers and serial numbers, based on the chassis and serial numbers that you have in your output (and not those of the lesson :stuck_out_tongue: ).

When you click on the Send to Controllers, what output do you see? Is there any progress information appearing? If so, please share this. Also, ensure that network connectivity is established.

Some debug commands that may be helpful to see what (if any) requests are being made to the WAN edge devices can be found here:

Some useful debugs are debug platform software sdwan tracker as well as debug vdaemon.

I hope this has been helpful!

Laz

This issue is real and i had the same problem and i tried 3 times to recreate the Lab from scratch but each time i got stuck in the vEdge onboarding. The vmanage does not take any action after receiving the command: request vedge add chassis-num kkkk serial-num xxxx
It could be a recent bug. The only difference in my Lab setup is that i am using a newer version of software for my controllers 20.3.3.
To resolve this, i had to upload a WAN edge list by Uploading a signed file (.viptela file) from Cisco Plug and Play using my smart account (software.cisco.com).
After that you, type on the vedges the command:
request vedge-cloud activate chassis-number xxxx token xxxx
The Chassis and token numbers are generated from the cisco plug and play site and included in the uploaded list. You just have to pick one of each. Once you do that it becomes relatively smoother and easy to onboard edge devices. I suggest if this section could be updated for easier understanding. The current onboarding method listed in the lesson does not work for my version of controller software.
Apart from this, everything else went smoothly for me. Thanks to Rene and team, for doing a great job so far and keeping things simple.

Hello Emecar

Thanks for the update! I’ll let Rene know to take a look and consider making any adjustments to the content.

Thanks again!

Laz

Hi @brentinmiami @emecar123

I tried this again with version 20.3.3 and I am running into the same issue. I’m adding some more examples now. The solution where you create the .viptela file from Cisco Plug and Play is the correct one.

It’s too bad this doesn’t work on the newer versions. Avoiding creating the viptela file saved some time.

I’m writing another lesson now to show how to do this. Should be up today or tomorrow.

Rene

For everyone running into the same issue. Here is the fix:

I’ll add a link from the vEdge onboarding lesson to this one.

Rene

NIce! Thanks for the prompt response

1 Like

Hello Rene,

I have one doubt about the tunnel encapsulation, in the configuration we are creating the tunnel over ge 0/0 but not mentioning the tunnel encapsulation type but did in the tunnel over ge 0/1.Why is that? The communication of vEdge router to controllers will be through secure IPsec tunnel or through GRE tunnel and if my VPN0 interface is building the tunnel my source interface will be ge0/0 or ge0/1 but what will be the tunnel tunnel destination?

Hello Anjan

I apologize for the late reply to this one… It seems that there was a command missing in the lesson. The following command must be added to both the Ge0/0 and Ge0/1 interfaces:

encapsulation ipsec

Although this was included in the final configs, it wasn’t in the lesson. Rene has since updated it.

Also, even though we have both the ge0/0 and ge0/1 interfaces, we are using ge0/0 because of this route:

vedge(config)# vpn 0
vedge(config-vpn-0)# ip route 10.1.0.0/24 10.65.91.100

And, the next hop is reachable through ge0/0.

If you want to use both the ge0/0 and ge0/1 interfaces, then you need to add a second route:

vedge(config)# vpn 0
vedge(config-vpn-0)# ip route 10.1.0.0/24 10.65.92.100

Does that make sense?

I hope this has been helpful!

Laz