cloud-init booting vManage

Automating Viptela SDWAN controller deployment:

Hello – One of the areas that I do a lot of work these days is in experimentation of various technologies. I needed a way to quickly deploy and build Cisco Viptela SDWAN environments whether that be in AWS, VMware, or KVM. Like many, I started searching for and looking for all the ways this could be done. As you might imagine, I found a lot of blogs and information on the topic.

My plan was to use terraform to help me deploy the controllers and edge devices in an automated way. Sure, there are plenty of ways to do this, but each of these ways left me thinking something was missing. So this post is less about the ways we can complete this task and more about what I did *not* find along my journey.

We’ll start with vManage. For the unitiated, the vManage is the controller responsible for network management, among other details. Managemetn of itself, of the SDWAN network, and of the controllers and edge devices. A key difference that you’ll notice when deploying vManage is that you have to have a second storage device attached. That storage device is for the database that will be created and used and must be at least 100GB according to the prevailing documentation. When you start up the controller instance you’re prompted to log in. After you log in for the first time you’re asked to select a secondary disk, then asked to format this disk. vManage then reloads and carries out the disk addition and formatting.

This is my focus today. That’s a very manual process. One that I would like to avoid in my project for short term build needs. You may have noticed that throughout the documentation related to vEdge you can generate a cloud-init file to bootstrap the edge device. So the question becomes – Can you use cloud-init for vManage?

Yes – you can. First, let me tell you that cloud-init isn’t new. Not only that cloud-init user-data is widely used in deploying instances in AWS as well. While you don’t have the luxury of having one generated for you, we’re going to talk about how we can bootstrap the vManage build process so that the questions asked on first boot are answered. We’d also like to be able to configure as much as makes sense while the vManage is booting up as well.

We’re going to start out by creating a file called ‘user-data’. The file might look something like the following. We’ll examine the parts to better understand them.

Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0

--==BOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"

#cloud-config
vinitparam:
 - format-partition: 1
 - vbond: 10.10.10.10
 - host-name: vmanage
 - org: "XXXXXXXX"
 - rcc: True

ca_certs:
  remove-defaults: False
  trusted:
  - |
    -----BEGIN CERTIFICATE-----
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    -----END CERTIFICATE-----

There are two parts to user-data. First, thing to note is these files are essentially YAML formatting. The first part is cloud-config. Sometimes you may see a file name associated in cloud-init files, but you won’t need it here. In this first section is where you define the initial parameters. As you can see there are a few things we can do here. First right off the bat “format-partition” set to 1. This takes care of being asked what disk to use and if we want to format it.

Some of the other parameters are self explanatory, org, vbond, etc. But you can also add a certificate to be added to the deployment as well. Notice that the boundaries of the parameters for cloud-config are defined as ‘boundary’ and set as such going forward into the user-data file. They can be anything, doesn’t have to say boundary.

Now that we have that out of the way we’ll explore the second part of this multi-part file. The second part is cloud-boothook. Note that this second part below is directly below the cloud-config part above.

--==BOUNDARY==
Content-Type: text/cloud-boothook; charset="us-ascii"

#cloud-boothook
!
system
 system-ip 10.10.10.250
 site-id 100
 host-name vmanage
 sp-organization-name "Some org"
 aaa
  user admin
   password admin
!
vpn 0
 ip route 0.0.0.0/0 10.10.20.1
 no interface eth0


 interface eth1
  ip address 10.10.20.20/24
  no shutdown

  tunnel-interface
   allow-service all
  !
--==BOUNDARY==

In this next part, the cloud-boothook, is where we can define the configuration that gets applied to vmanage. As you can see this is standard CLI config so anything here is simply run at boot when the config is loaded. in essence, you can take care of completely configuring the vManage without having to have manually configured anything so far. Convert this file to an iso image and attach it as a cdrom and away you go!

One thing to note is that cloud-init bootstrapping works in 19.x and 20.x code trains for Cisco Viptela based SDWAN controllers.

In my next update, we’ll talk about the vSmart and how to format the cloud-init for that controller.

Be safe and be healthy.