Networking in the Cloud Age – (Infrastructure-as-Code using Ansible) Part 1

In a previous post we discussed some network automation approaches that  can provide significant infrastructure improvements with little to no upfront investments. In this blog, we’ll review two of the  approaches  that can help move your infrastructure  from the  Iron Age   to the cloud era.

The diagram below depicts a Datacenter (DC) infrastructure consisting of a pair of Juniper border routers, End of Rows (EORs) or spine switches and Top of Rows(TORs) or leaf switches. Although there are several other elements that makes up a  typical DC infrastructure. To  keep things simple for now, we will limit our discussion to the TORs and EORs network elements. In subsequent blogs, i’ll tie all elements together and even extend the setup to include NSX and AWS.


So  how do we  represent our infrastructure in a programmatic manner also known as Infrastructure-as-Code (IAC), as well how do we automate configuration management and device provisioning ?

Using Ansible, we can  translate our network topology  into blueprints using a language called YAML. Unlike colorful Visio diagrams that are only human readable, the blueprints are both human and machine readable.But thats not the only thing !

The other thing  that makes Ansible powerful is its ability to separate code from the actual data. Codes are the  static or generic  software placeholders.They are constants that can  be reused and even shared outside of an organization .

If codes are generic constant or placeholders, then Data are those unique variable that plugs into a code to complete the representation of your infrastructure. Data is unique to your environment and they change based on your company policies, business requirements etc.

Infrastructure as Code

By decoupling Code from Data, we enable a level of abstraction that simplifies the definition of  services that utilizes your infrastructure, reduce provisioning errors and the cost associated with managing the infrastructure.

So back to our example using a pair of TOR and EOR. We will  develop a methodology to represent our  code for deploying  TORs and EORs in a Jinja2 template. The accompanying  Data is  defined  in YAML files. (You can also have your data defined in a CMDB or even an excel spreadsheet).

In part 2, We’ll review what the infrastructure code and data looks like. We will then execute what Ansible calls playbook against our network infrastructure to generate appropriate configuration for each functional sub-blocks (TORs,EORs etc). Afterwards, we will push those configurations to our network devices without any human intervention.