Modelling Network Device Configuration with YAML
Modelling your server config into a code has been common practice, how about network config?
As far as my experience goes, network infrastructure operation still has a long way to go in approaching a DevOps practice. with the ever changing nature of an application development, it is better to drive the DevOps practice for network infrastructure operation. One of the important components in the DevOps practice is Infrastructure as a code (IaC), where the configuration, maintenance and provisioning are transformed into a code.
The IaC approach is commonly used in cloud based infrastructure. Nevertheless, I still believe we could still try approaching our network infrastructure as an IaC because one of its approaches is to turn the configuration of into a code.
So, with this spirit I want to invoke my idea on how we could use the IaC approach within our Network Infrastructure.
Use Case
Our use case for this story can be found in other article I’ve written:
The story covers how to build a simple data center network with a technology called BGP EVPN. This is a perfect use case because changes in a data center network are rapid and common, hence the IaC approach is needed to ease up the operational of the data center.
YAML File to Store our Configuration
YAML or YAML Ain’t Markup Language is a human-friendly data serialization language for all programming languages. YAML is often used to store configuration files, hence it is a perfect tool to turn our network infra configuration into a code.
Here is an example of a YAML syntax:
The YAML file often starts with three dashes at the top, but this is optional. The dashes indicate the start of a new YAML document, hence, we could create multiple YAML documents in a single file. However, I won’t use this because what I want to do is to store each configuration of the network device in our use case into a file.
The most important thing in YAML is its nodes. YAML nodes contain key-value pairs which can be freely defined. One thing to be noted is that the key should always be represented as a string, while the value can be other YAML data-type.
Also, YAML formatting approach is through a whitespace indentation, but we should use space instead of tabs. This indentation forms a parent-child relationship between nodes.
Turning Our Network Configuration Into Code
There is no specific approach on how we turn our network configuration in a code, in our case YAML syntax/code. The one thing we need to define our code is our knowledge within the network engineering technology.
My approach to define what we should put into our YAML code is to start by defining what is the configuration within the network interface of each network device. Here is the example on interface configuration in one of the switches in our topology:
From the configuration file, we could see that the configuration already works in hierarchical manners (i,e IP address, switchport type, etc) and each interface holds a different kind of purpose. Hence, from this we could transform the information into the YAML code:
Then we define the technology that is running in our network infrastructure. In our use case, the network topology is running a Data Center technology called BGP-EVPN. Here is the example of the configuration of BGP-EVPN for Arista vEOS:
From the configuration, only a few configurations are hierarchical, but we could group the configuration differently. For example the BGP peer can be an external BGP or EVPN peer through the address-family configuration. Hence, we could group BGP peers together into a list, and to differentiate we add the type of the Peer.
Also, BGP-EVPN requires which VLAN information should be carried and exchanged, hence we also add a list of VLAN in our YAML code. Here is the configuration of BGP-EVPN for our YAML file:
Within our network we also run VXLAN, which is also a common technology to be used in the Data Center network. VXLAN configuration covers the configuration of VXLAN Interface, VNI, etc. Here is the snippet of the VXLAN configuration.
From that configuration we could easily put it into our YAML code:
Also, we can’t forget the management information of the device, such as username, password, management IP, etc. Here is the YAML snippet for that:
Please be aware that this information is related to VirtualBox not the network hardware, because that’s how we access the virtual network on a VirtualBox.
Here is the whole YAML code for our single network device:
These templates should be applied to other devices which share the same functionality. For example, we don’t need the BGP EVPN configuration in our spine switch, hence we could omit the BGP EVPN code in our configuration file.
You could make your own interpretation of how you want to build your own YAML file because there is no restriction.
Conclusion
Converting a network device into code is not an easy task, and there is a lot of interpretation on how we structure our configuration in the YAML file. We could also model this configuration automatically by using JSON RPC, although not all network devices support such technology (especially the older one). Hence, converting manually seems, at least for me, more preferable at the moment.
By having these configuration files, we could use it to automate tasks or do a validation test in our network topology. I will cover this in my next story, so please stay tuned with me!
Thank you for reading!
