When we talk about onboarding, the term simply means that we are preparing a device to be added to the already existing network environment. When we use this term in the context of the vEdge device, it means that we are preparing the vEdge device, whether a hardware device or a virtual device, such as a CSR1000V, to be added to the network and be recognized and controlled by the vManage, vSmart, and vBond devices.
All of this can be done in a lab environment such as EVE-NG. There is no essential difference. All of the labs performed by Rene in the lessons are actually run in an EVE-NG environment. The following lesson shows how this environment has been prepared:
Other lab options are also available and can be found here.
Cisco SD-WAN supports BGP, OSPF, and Overlay Management Protocol (OMP) for unicast overlay routing. For more information on how to configure BGP on the overlay network, take a look at the following CIsco documentation:
Hi Rene - What if we have the Vmanage on the Cisco Cloud and the Hardware Wan Edge Certificate Authorization is [On Box Certificate(TPM/SUDI Certificate)] based on Vmanage settings . Does the procedure on the video also applies to Cisco ISR 4351 that i will be onboarding to SDWAN. ^^
Additionally , SDWAN Controller is on 20.x version whereas the Cisco ISR 4351/k9 is on the 17.3.4 version. What onboarding procedure should i be using in that case please ?
The option for using the On Box Certificate is somewhat different, but not by much. You can take a look at it here:
Just for clarification, you cannot use an enterprise root CA for authentication hardware devices using TPM/SUDI.
TPM is short for Trusted Platform Module. This is a standard used for secure cryptoprocessors, which are dedicated physical microcontrollers designed to secure hardware through integrated cryptographic keys. The term TPM is sometimes used to refer to the physical chip on the device itself.
SUDI is short for Secure Unique Device Identifier. When used in conjunction with TPM, it proves hardware origin and a hardware-derived secure boot process to prevent unauthorized code from running during the booting on a Cisco platform. The SUDI is an X.509v3 certificate that is actually stored in hardware on the device.
As such, when using an ISR4321 for example, which is a physical device with TPM/SUDI hardware, only the On Box Certificate option can be used.
Concerning the version numbers, when using hardware, it is best to use the recommended versions of controllers and IOS XE SD-WAN. The following documentation shows these recommendations:
You can see here that for versions 18.x, 19.x, and 20.x of the controllers, version 17.3.4 of the IOS XE SD-WAN is recommended. Note here that the version number of the controllers (which is a Viptella version number) and those of the IOS XE SD-WAN do not correspond. So there is no restriction beyond simply ensuring that compatibility is verified by Cisco.
Hi,
i have a question regarding VPN 0. As far as i understand it belongs to the Underlay network.
Here it is referenced as part of Overlay.
See section 1.1.2 VPN0 (Overlay Network)
I believe it should be changed to VPN0 (Underlay Network).
See also
I got a little confused. Could you please clarify and perhaps change it?
Thanks again for this great traininng lesson !!!
Olli
To start off, I can say that according to Cisco documentation, where the VPN 0 resides is not that clear-cut. As described in the documentation you linked to:
The underlay is defined as the physical network infrastructure that employs traditional routing mechanisms.
The overlay is formed by multiple IPsec tunnels and can be defined as a network of VPNs that provide segmentation and where actual user traffic is served.
VPN 0 is the transport VPN. It contains the interfaces that connect to the WAN transports. It serves to allow underlay peering for routing. Static or default routes or a dynamic routing protocol needs to be configured inside this VPN in order to get appropriate next-hop information so the control plane can be established and IPsec tunnel traffic can reach remote sites.
I tend to agree with you that it does operate more on the underlay side of things since it is used for underlay peerings for routing protocols, but because it is a VPN, it also has the characteristic of an overlay entity. In any case, I will let Rene know to look this over and make any necessary clarifications on the lesson.
The color assigned to each tunnel interface is simply used to differentiate between the different WAN connections being used. The biz-internet and public-internet WANs are simply names given to each type of WAN. These are not standardized names, but just the names given to these specific WANs. You can call them whatever you like, and you can assign whatever color you like to them.
In addition, you can choose to transport whatever you like over each individual WAN. The names and colors used in the lesson are only for demonstration purposes. You can choose to use names that are more meaningful to the specific application you will be using in your topology.
I made some changes to the lesson. Usually, the underlay is the “physical” network and the overlay is the “virtual” network. VPN0 is the transport network and most of the traffic is DTLS/TLS or IPSec. However, other protocols like NETCONF, SSH, NTP, DNS, and HTTPS are also possible. Since VPN0 is used for transport, I agree it belongs more to the underlay side than the overlay. It’s a bit of a grey area though.
I need to know how I can generate (serialFile.viptela)
Also I followed same steps but when I click on “Configuration > Certificates > WAN Edge List and click on Send to Controllers” it give this message “No new updates to be sent to device”
I’m running vManage 20.5.1.2. After running the “request vedge-cloud activate chassis-num …” on my vEdge, back on vManage Certificates page, the left-side icon then changes to “CSR Generated” and a CSR is now available from right-side menu. The vEdge is still not fully onboarded (no BFD sessions) - what now?
— UPDATE: I figured this out - I generated the CSR for the new vEdge device on the vManage Certificates page, then I went to vManage CLI, copied CSR to /home/admin, and signed the CSR (using same openssl signing command as before) to create a CRT. Then I went back to vManage Certificates page, clicked “Install Certificate” and pasted the CRT. After this, the Certificate status changed to “Installed” and the vEdge was fully onboarded.
Hi Rene /Network lesson team ,
Hope you are doing good , i have one doubt if i have existing setup of SD WAN fabric up and running and i want to onboard one more vedge device into the fabric and certificate authority i have one of the controller (vmanage/vsmart/vbond) but i need to find which device is basically working as a CA , can you please help me with it how to find the certificate authority (ROOT CA )device within the fabric itself.strong text
If you have a topology that is already deployed by someone else, and you come in fresh, and you want to onboard a vEdge, it can be difficult. You must find out what device is operating as the CA. Now in a lab environment, you would configure either the vManage, vSmart, or vBond devices to act as the CA delivering self-signed certificates. In a production network, however, you would use some automated solution with an external CA to sign certificates. This is further
In any case, if there is no other way to find out, you could export the certificate on one of the routers and look at it on a computer. This NetworkLessons note on why we trust a website certificate gives more information on how to do that.
Alternatively, you can go into the vManage GUI and check the controller certificate authorization settings to see if it is the issuer. More on that can be found at this lesson:
Unfortunately, there’s no single show command that will give you this info, you’ll have to do some digging. This is one of the situations where you can see the importance of documentation when creating and maintaining a network.