Azure vWAN Orchestration made Simple

Shay Naeh

4 min readAug 25, 2020

Cloudify to Orchestrate Azure vWAN Central HUB and Remote Branches

Objectives

Use Cloudify as an Intet based orchestrator to provision and manage Azure virtual WAN (vWAN) and virtual HUBs
Use Cloudify to provision and manage Azure virtual Branches/CPEs
Push configuration to branches from the central HUB
Use Azure ARM templates as a basis and Cloudify to utilize these templates as a resource
Ability to add additional sites on the fly
All sites should be the same except for their name. Name is sent to the central HUB as a remote workflow ID to identify the site.
Make the above abstraction so it can utilize similar concepts in other clouds like AWS Transit.
Infrastructure as code — could be deployed as part of a CI/CD pipeline

Blueprints, Deployments and Workflows

Virtual WAN and Central HUB

One deployment brings up the virtual WAN and the central HUBs. It defines all the required inputs for the ARM template to provision the central HUB as a resource.

As we can see above the blueprint defines the HUB as a component. Here is the blueprint part that defines it

If we further dig down into the vwan-infra it simply populates an ARM template to provision the central HUB.

The central HUB is defined as a shared resource, which supports a remote workflow execution. Now when a new site is provisioned it has a relationship to the central HUB, which invokes the remote workflow in it’s “establish” life cycle operation. This allows the site to send its ID to the central hub and get back its configuration, which includes its IP, BGP, ASN number, network addresses, etc.

Remote Sites and Remote Workflows

If we look at the topology above we can see a TOSCA node named oregon-site-init. This node is responsible to send its ID to the central HUB as defined in the blueprint. You can see that the relation target is “vhub” and it happens in the “establish” life cycle operation.

Configuration is provided from the Central HUB

Upon the execution completion of the remote workflow the new site gets its parameters.

Updating the VPN Gateway connections

As part of the site provisioning you have to provision a vpn gateway or more precisely update the gateway connections while you have to remember the previous provisioned sites. Because everything is defined in the central HUB it is easy to keep the previous sites connections and their order. Here is the TOSCA node that is responsible for provisioning the gateway.

Jinja templates for rendering the Azure ARM Template

As part of iterating through the connections that can be a variable list, we use a Jinja template as part of the Azure Template to add the connections dynamically. Here is a snippet of the code that shows this:

Intent based Model

The concept of intent based model where you define “what” you do and not “how” you do it comes to full power here. As shown below only the site name changes between sites and everything else is the same. The central HUB is “smart” to configure each site differently based on the site ID. You can also see that it looks much simpler, shorter and manageable when using Cloudify blueprints vs. ARM Templates, which are abstracted by Cloudify. Furthermore, in the future you could define a Blueprint template and only send the site name as a parameter.

Infrastructure As Code

Everything defined above could be as part of an automatic CI/CD pipeline that is triggered by environment code changes. So when something is changed the Azure vWAN environment could be updated on the fly. The figure below shows each step of the CI/CD pipeline , where we create first the central HUB and then adding the sites in following steps.