Intent Based Networking showcase: VPN service

This post was originally published Aug 29 on Sebastian Grabski’s blog Orchestrated Things

“…seeing is believing, isn’t it?”
Intent Based Networking is one of my favorite topics, especially due to fact that it embraces the power of proper orchestration and automation. I covered already “declarative networking” where I presented the importance of orchestration DSL in describing network environments. In another post I discussed the role of orchestration itself, explaining that you do not need to rip & replace your network to make it intent based. Now it is a time to showcase it a bit more. Nothing speaks better for itself as a good demo. For the sake of the example I picked reasonably simple service, which can be understood by most of the audience: hub and spoke VPN.

Meet the team at SDN World Congress in the Pod Zone on EXPO Floor 1! Contact Us!

In this document I’m going to make a walk through the sample modeling of VPN service in Cloudify DSL. For the sake of the example and clarity, service is simplified and I’m using artificial types & relationships in a DSL, I call them “phantoms”. I use them quite often during trainings and workshops as they help to demonstrate what’s happening behind the scenes of the orchestration process. If you look into the code of the types, all they do is printing on a console that given action (start/stop/link/unlink) is taking place. I’m afraid that if I’ll use fully featured types and relationships, we’ll miss educational aspect of this example – as blueprints will become much more complex. I hope that you’ll forgive me this simplification for the cause.
Full code can be found in here
Hub & spoke VPN is nothing more than a set of nodes and “pseudo-wires” that connect them together.

It models very nicely in Cloudify DSL (which is TOSCA based):

HQ:
type: cloudify.nodes.vRouter
relationships:
- type: cloudify.relationships.rtr_connected_to_vpn
target: vpn1
- type: cloudify.relationships.rtr_connected_to_vpn
target: vpn2
- type: cloudify.relationships.rtr_connected_to_vpn
target: vpn3
branch-1-rtr:
type: cloudify.nodes.vRouter
relationships:
- type: cloudify.relationships.rtr_connected_to_vpn
target: vpn1
branch-2-rtr:
type: cloudify.nodes.vRouter
relationships:
- type: cloudify.relationships.rtr_connected_to_vpn
target: vpn2
branch-3-rtr:
type: cloudify.nodes.vRouter
relationships:
- type: cloudify.relationships.rtr_connected_to_vpn
target: vpn3
vpn1:
type: cloudify.nodes.Vpn
vpn2:
type: cloudify.nodes.Vpn
vpn3:
type: cloudify.nodes.Vpn

What we can see above is a blueprint, which is VPN declaration in Cloudify DSL. In intent based networking terms this is called the intent. I’d like to bring your attention the essence of Cloudify DSL – which is the use of relationships. Please take a look at HQ node, how relationships with 3 VPN’s is established.
Blueprint is only representing the intent, now we need implement it. In Cloudify terms for a change we need to upload blueprint to Cloudify Manager and create deployment:
Step1: upload blueprint to Cloudify Manager
Step2: create “deployment” & execute “install” workflow on a deployment
Step1:

cfy blueprint upload -b branch-1 ./branch-1-blueprint.yaml
cfy blueprint upload -b branch-2 ./branch-2-blueprint.yaml
cfy blueprint upload -b branch-3 ./branch-3-blueprint.yaml

(I uploaded all three blueprints in this stage)
Step2:

cfy deployment create ACME-vpn -b branch-3
cfy executions start -d ACME-vpn install

As a result we should see in a Cloudify Manager deployment of our 3 sites VPN:

Now it’s a time to showcase the intent based topology change by downgrading existing VPN to 2 sites. We have another blueprint which is reflecting the state (intent) of VPN with 2 sites: branch-2-blueprint.yaml (initially uploaded with the name branch-2). I’m going to execute UPDATE workflow on ACME-vpn deployment, where as a parameter, I’m going to specify blueprint which represents desired state (2 branches):

cfy deployments update ACME-vpn -b branch-2

It’s important to understand what’s happening behind the scenes. Update workflow is one of most important lifecycle management tools in Cloudify as its allowing to change the state of the deployment. In our case, initial state was reflecting 3 sites and desired state will be 2 sites. What workflow does, it calculate diff between existing and desired blueprint and as a result it’s removing or adding missing nodes with relevant relationships. In our case we’ll get following result:

Good demo is helping to explain the concept, however best is to see it in action. Therefore I decided to make quick recording of this demo to present the flow:

As we have seen in the above example, proper use of declarative, TOSCA based orchestration engine can help in building intent based network services. Cloudify DSL is very well equipped to reflect networking intent by leveraging concept of nodes and relationships. Lifecycle management capabilities of Cloudify, which are implemented through workflows ( update workflow in case of this demo) – are allowing to change/alter the state of the network in a declarative, intent-driven way.