Cisco SD-WAN vEdge Onboarding

Hello Houa

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.

I hope this has been helpful!

Laz

Can we add ISR 4000 Router in Eve-Ng

Can we use BGP on Overlay VPN 0 Network instead of static routing. Thanks for the answer

Hello Himanshu

Take a look at this NetworkLessons note about supported Cisco IOS images on EVE-NG.

By the looks of it, the ISR4000 is not on the list, but using a Qemu image, you can get a Cisco ISRv 17.x to function.

For more info, you can further explore the EVE-NG support pages which will give you a more complete idea of what alternatives you have.

I hope this has been helpful!

Laz

Hello Venus

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:

I hope this has been helpful!

Laz

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 ?

Hello Venus

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.

I hope this has been helpful!

Laz

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

Hello 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.

Thanks so much for pointing this out!

I hope this has been helpful!

Laz

What is the difference between biz-internet and public-internet color. In what transport should i use biz-internet and public-internet? Thanks

Hello Venus

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 hope this has been helpful!

Laz

Hi @olim26m ,

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.

Rene

1 Like

Great and very clear lesson.

  • 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”

Hello Rami

How to get the serialFile.viptela file is shown in the previous lesson:

Specifically you can find it in section 4 titled Serial File.

This depends upon the correctness of your serialFile.viptela file. Make sure that your file is correct and try again. Some additional information about the validity of these files can be found at this Cisco/Viptela documentation:

I hope this has been helpful!

Laz

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.

Hello Greg

Great to hear that the issue has been resolved! Thanks so much for keeping us up to date and posting your solution here, it is of great help.

Thanks again!

Laz