Benefits of automating configuration files

For those of you reading this article, you might be wondering if you don't have to go through the trouble of creating a configuration file using Ansible and just create it manually. I think there are some people who think so.

It's certainly fine if it's a configuration file for a few switches, but if you have a large network with dozens or more switches, it becomes a very time-consuming task. There is also a high possibility that mistakes will occur.

However, looking at the contents of the configuration file, there are no major differences between the switches, only some parameters are different.
In exactly such situations, by using Ansible's template module, you can easily create configuration files for dozens of switches, and you can easily expand the configuration in the future. It also greatly reduces the chance of typos.

In summary, there are three points below.

Efficiency

⇒ Processing is much faster than manual operation

accuracy

⇒ Fewer human errors

Scalability

⇒ Easily expandable from a 10-unit configuration to a 100-unit configuration

3 benefits of using Ansible

This benefit applies not only to the template module but also to Ansible itself. Ansible is a very powerful tool that significantly reduces the burden on users.

What is Ansible's template module?

First of all, what is a template module? I would like to talk about this.

The template module is a module that can use the template engine for python called Jinja2. This makes it possible to automatically create dozens of configuration files without much effort.

Specifically, Jinja2's template file allows you to use control statements such as for statements and if statements in combination with variables, and it is possible to create a configuration file with parameters changed for each switch all at once.

Now, I would like to actually put it into operation and show you how it works.

Auto-configuration overview and environment

Now let's actually create a configuration file using Ansible. This time, we will create a startup-config that can configure a BGP cross network with OcNOS. After applying the settings, the network created will be exactly the same as the configuration created in the previous article.

environment
·server
-Ubuntu 16.04
　
・White Box switch
-Edgecore: AS7726-32X x 2 & AS7326-56X x 2

・NOS
-OcNOS 1.3.9

BGP cross network diagram

Ansible directory structure

The following directory structure and roles are recommended for automatically creating configuration files with Ansible.

├── hosts #inventory file
│
├── make_conf.yaml #Playbook file
│
└── roles
│
├── leaf
│ │
│ ├── tasks
│ │ └── main.yml #Task to create leaf config
│ │
│ ├── templates
│ │ └── leaf.j2 #Jinja2 template file for leaf
│ │
│ └── vars
│ └── main.yml #stores leaf switch variables
│
└── spine
│
├── tasks
│ └── main.yml #Task to create spine config
│
├── templates
│ └── spine.j2 #Jinja2 template file for spine
│
└── vars
└── main.yml #Store leaf switch variables

Now, let's take a look at the specific contents of the configuration files (hosts, Playbook) to be placed in these directories.

*The configuration files introduced below can be downloaded by answering the questionnaire in the document download form at the end of this article.

hosts

Playbook

Next, we will look at the contents of spine in the roles directory.

The following is a task that uses the template module to create a configuration file and then copies it to the /tmp/confgs directory.

spine/tasks/main.yml

In the Jinja2 template file shown below, you can use if and for statements to create a configuration file with different parameters for each switch.

In the figure above, variables are in red, and if and for statements are in blue.

spine/templates/spine.j2

The figure below is a file that lists the variables used in templates.

The leaf in the roles directory is almost the same as spine, so I will omit it.

spine/vars/main.yml

Run playbooks with Ansible

Next, we will run the playbook described above.

Playbook execution screen

I can confirm that it runs correctly and that four configuration files are created.

4 configuration files created

Next, apply the created file to each switch.

(Although I will not introduce it in this article, it is of course possible to set OcNOS using Ansible to automatically enter a white Box.)

After applying the settings, you can see that the BGP session is successfully established.

BGP results

In addition, the route is also advertised, and it can be confirmed that pings can be sent to the loopback of each switch.

BGP ping execution result

The above is how to automatically create a configuration file using Ansible.

This concludes our series on tools for automating network construction using Ansible. In the next article, we will introduce ZTP, which automates the switch construction phase.

These people are using the remote verification service.

Here are some testimonials from people who have actually used the service.

 

Furukawa Network Solution Co., Ltd.

“Recently, the number of remote service environments is increasing, but I was impressed with the ease of access to the evaluation equipment.

The materials you provided were easy to understand, and we were able to proceed smoothly with the intended verification. ”

Related information

[Ansible for Beginners] Automatically build a BGP cross-network! Starting network construction with Ansible Part 1

Automatic configuration of white Box switches with OcNOS and ZTP

How to automatically configure a white Box switch network for beginners ~ZTP x An...