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
- 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 
).
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
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
I have tried adding the vedge but each time i add using the wan edge list, it fails. It says vedge is unreachable even though i can ping the vedge from the vmanage:
here is the output of control connection history:
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vbond dtls 0.0.0.0 0 0 100.0.1.1 12346 100.0.1.1 12346 public-internet challenge_resp RXTRDWN BIDNTVRFD 5 2021-10-01T16:28:03+0300
vbond dtls 0.0.0.0 0 0 100.0.1.1 12346 100.0.1.1 12346 public-internet up RXTRDWN VECRTREV 0 2021-10-01T16:24:58+0300
vmanage dtls 10.0.1.3 1 0 100.0.1.3 12346 100.0.1.3 12346 public-internet up RXTRDWN VECRTREV 0 2
Hi Rene,
i have loaded many different version lower then 20.x … and when i issue the command show certificate serial … im getting only the uuid but i get nothing next to serial number :
Its blank ? how were you able to get the serial ?
Hello @patrickdenis ,
That is strange. You mean the show certificate serial command on a vEdge router? Which version did you use?
Rene
I am using 20.3. I followed the steps to onboard all of the controllers as well as obtain the viptela.serial file from the virtual smart license website. I have uploaded the serial file to the vManage controller and verified IP reachability from my vEdge to the vManage, vBond and vSmart. The organizational name also matches across all of these devices (as is recommended in the lesson).
After generating the cert on the vManage system, I run “show control local-properties” and get the following:
vEdge1# show control local-properties
personality vedge
sp-organization-name some-org-string
organization-name nwl-sdwan-lab2
root-ca-chain-status Installed
certificate-status Installed
certificate-validity Valid
certificate-not-valid-before Oct 25 19:39:57 2021 GMT
certificate-not-valid-after Apr 17 19:39:57 2027 GMT
dns-name 10.1.0.2
site-id 2
domain-id 1
protocol dtls
tls-port 0
system-ip 172.16.1.1
chassis-num/unique-id 9457a1ea-7f1d-8b77-2c59-60acb243c173
serial-num B88A9DCCB13740E7
subject-serial-num N/A
token Invalid
keygen-interval 1:00:00:00
retry-interval 0:00:00:18
no-activity-exp-interval 0:00:00:20
Aborted: by user
vEdge1#
Then I follow the recommendations for using the chassis-num + token combination at the end of section 2 and I get this:
vEdge1# show control local-properties
personality vedge
sp-organization-name some-org-string
organization-name nwl-sdwan-lab2
root-ca-chain-status Installed
certificate-status Not-Installed
certificate-validity Not Applicable
certificate-not-valid-before Not Applicable
certificate-not-valid-after Not Applicable
dns-name 10.1.0.2
site-id 2
domain-id 1
protocol dtls
tls-port 0
system-ip 172.16.1.1
chassis-num/unique-id 9457a1ea-7f1d-8b77-2c59-60acb243c173
serial-num No certificate installed
subject-serial-num N/A
token 5c12ae5d92e34cdd89b5e0ae2bd28ed2
keygen-interval 1:00:00:00
retry-interval 0:00:00:18
no-activity-exp-interval 0:00:00:20
So it goes from Cert = valid; Token = invalid to Cert = invalid; Token = valid. The vEdge never shows up as having used the valid certificate under vManage > Configuration > Certificates. Do you need some additional software licensing or something to onboard vEdges in this lab environment?
Hello team,
Will there an onboarding process for the CSR1000V as the command syntax are slightly different (controller mode) or is it not possible to do in a lab environment such as EVE-NG?
-Houa