FULLTEXT01

(1)

School of Innovation Design and Engineering Västerås, Sweden

Thesis for the Degree of Bachelor of Science in Engineering - Computer Network Engineering, 15 credits

AUTOMATED NETWORK CONFIGURATION

A COMPARISON BETWEEN ANSIBLE, PUPPET, AND SALTSTACK FOR NETWORK CONFIGURATION

Samuel Wågbrant

[email protected]

Valentin Dahlén Radic

[email protected]

Examiner: Thomas Nolte

Mälardalen University, Västerås, Sweden

Supervisor: Václav Struhár

Mälardalen University, Västerås, Sweden

Company Supervisors: Casper Möllberg and Claes Karlsson

ATEA Sverige AB, Eskilstuna, Sweden

09/06/2022

(2)

Abstract

Automating the configuration of network devices contributes to faster configuration and helps increase consistency compared with manual configuration. In this thesis, we compare the automation tools Ansible, Puppet, and SaltStack and evaluate their performance when configuring network devices. To evaluate the automation tools this thesis consists of a comprehensive overview and a set of performance experiments. The comprehensive overview focuses on comparing the automation tools and their capabilities whilst the set of performance experiments focuses on comparing the performance of the automation tools. The comprehensive overview reveals that all automation tools we investigate can achieve automated network configuration. However, the approach to configure network devices varies between the automation tools. For the configuration of network devices Ans- ible is more capable than Puppet and SaltStack. The lack of documentation and support for Puppet and SaltStack leads to an increase in usage complexity. The performance experiments reveal that Ansible and SaltStack have a better performance than Puppet for a lower number of configuration changes. However, with an increasing number of configuration changes, Ansible shows a noticeable difference whilst Puppet and SaltStack do not.

(3)

List of Figures

1 Flowchart used during this thesis . . . 8

2 Network Topology built at Atea . . . 12

3 Virtual Network Topology made in GNS3 hosted on the VMware ESXI server . . . 13

4 Physical Network Topology . . . 14

5 Average configuration time when configuring three changes on physical routers . . 17

6 Average amount of bytes sent when configuring three changes on physical routers . 18 7 Average network bandwidth used when configuring three changes on physical routers 18 8 Average configuration time when configuring ten changes on physical routers . . . 19

9 Average amount of bytes sent when configuring ten changes on physical routers . . 19

10 Average network bandwidth used when configuring ten changes on physical routers 20 11 Average configuration time when configuring three changes on virtual routers . . . 21

12 Average amount of bytes sent when configuring three changes on virtual routers . . 22

13 Average network bandwidth used when configuring three changes on virtual routers 22 14 Average configuration time when configuring ten changes on virtual routers . . . . 22

15 Average amount of bytes sent when configuring ten changes on virtual routers . . . 23

16 Average network bandwidth used when configuring ten changes on virtual routers . 23 17 Average configuration time when configuring three changes with Ansible on physical and virtual routers . . . 25

18 Average configuration time when configuring ten changes with Ansible on physical and virtual routers . . . 25

19 Average amount of bytes sent when configuring three changes with Ansible on physical and virtual routers . . . 25

20 Average amount of bytes sent when configuring ten changes with Ansible on physical and virtual routers . . . 26

21 Average network bandwidth used when configuring three changes with Ansible on physical and virtual routers . . . 26

22 Average network bandwidth used when configuring ten changes with Ansible on physical and virtual routers . . . 26

23 Average configuration time when configuring three changes with Puppet on physical and virtual routers . . . 27

24 Average configuration time when configuring ten changes with Puppet on physical and virtual routers . . . 27

25 Average amount of bytes sent when configuring three changes with Puppet on physical and virtual routers . . . 27

26 Average amount of bytes sent when configuring ten changes with Puppet on physical and virtual routers . . . 28

27 Average network bandwidth used when configuring three changes with Puppet on physical and virtual routers . . . 28

28 Average network bandwidth used when configuring ten changes with Puppet on physical and virtual routers . . . 28

List of Tables

1 Properties of the automation tools Ansible, Puppet Bolt and SaltStack . . . 10

2 Average configuration time when configuring physical routers . . . 20

3 Average amount of bytes sent when configuring physical routers . . . 20

4 Average network bandwidth used when configuring physical routers . . . 21

5 Average configuration time when configuring virtual routers . . . 24

6 Average amount of bytes sent when configuring virtual routers . . . 24

7 Average network bandwidth used when configuring virtual routers . . . 24

(5)

1. Introduction

Manual configuration of network devices might seem like a simple task at first. However, with networks increasing in size and additional network devices connected, can make manual network configuration a daunting task. Larger networks with an increasing amount of network devices contribute to more complex and time-consuming configurations. Introducing automated network configuration to a network engineer’s daily workload can significantly decrease the number of errors and complexity experienced with manual configuration. Automated network configuration helps contribute to faster configuration and increases consistency compared with manual configuration.

Network automation is part of what is defined as Infrastructure as Code (IaC) whose purpose is to remove manual control of configuration and management to software [1]. Introducing software to help with the management of networks can increase productivity and decrease the number of errors. Software vendors are presenting automation tools to help with automating networks.

Several automation tools were initially developed to configure and manage servers by using software agents installed on the device to be configured. However, configuration of servers significantly differs from configuration of network devices. As network devices (routers, network switches) use closed and proprietary Operating Systems they often do not allow the installation of a software agent. A workaround exists by using a remote access protocol such as Secure Shell (SSH) which is how many automation tools today configure network devices.

The step to automating a network can be large and comprehensive if a network engineer lacks the necessary knowledge and experience. Not only is basic knowledge of programming a prerequis- ite but also a decision has to be made considering which automation tool is to be implemented.

With many different software vendors creating their products the choice can easily be overwhelming. This leads to the purpose and main question of this thesis; How do different automation tools compare when dealing with the configuration of network devices? The thesis provides an overview, analysis, and performance comparison of the automation tools: Ansible¹, Puppet², and SaltStack³. We investigate how different automation tools manage and perform automated configuration of network devices. Additionally, we provide a set of experiments to evaluate the performance of the selected automation tools.

This thesis aims to provide network engineers and IT technicians a better understanding of how network automation can be implemented and how different kinds of automation tools vary from each other. The ever-growing network industry increases the need for implementing automation in some capacity when scaling networks.

1https://www.ansible.com/

2https://www.puppet.com

3https://www.saltproject.io/

(6)

2. Problem Formulation

This thesis aims to investigate how different automation tools differ from each other when configuring network devices. The purpose is to ease the selection process of choosing an automation software tool and to help raise network configuration efficiency. Implementing network automation and deciding an automation tools can be difficult and overwhelming with all the available choices.

Since this thesis focuses on configuration of network devices the selection of available automation tools is limited. When selecting an automation tool for network configuration several factors need to be taken into consideration.

The research questions tackled in this thesis are:

RQ1: What automation tools can be used for the automated configuration of network devices?

RQ2: What are the capabilities of the automation tools?

RQ3: How do the automation tools compare in terms of performance, network usage, and usage complexity?

RQ4: How scalable are the automation tools?

RQ5: What are the challenges and missing functionality in automation tools?

Since there are many different manufacturers of network devices that may react and provide different results we have chosen to restrict the experiment to one network device vendor. The experimental environment consists of Cisco devices which is one of the largest vendors of network devices today. The experiment is conducted in a virtual environment and a physical environment.

Both environments are limited in the number of devices available. The virtual environment is limited to the capacity of the hosting server whilst the physical environment is limited to the number of devices available for use.

(7)

3. Background

Computer networks traditionally consist of a number of end-devices (computers, phones, printers, internet of things devices), servers and network devices (routers, switches). While servers provide data and services to other end-devices, network devices such as routers and switches ensure that data is transmitted to the right destinations. Network devices require correct configuration to deliver data to the right destination and can be configured via remote access protocols such as SSH.

With the use of software, the configuration process can be automated by communicating to the network devices through the use of a remote access protocol. For testing a network configuration, it is common to use virtualization (e.g. Graphical Network Simulator-3 (GNS3)). This allows the creation of a scalable virtual environment for conducting various types of tests and experiments (e.g., performance tests, load tests, functional tests) without the need for physical equipment.

Automating server and network infrastructure with software is defined within the scope of IaC. In the following section, we introduce concepts and technologies used later in this thesis.

3.1 Network devices and protocols

The following section describes network devices and network protocols used during this thesis.

The experimental environment implemented in this thesis is a network consisting of routers and switches. For the automation tools to connect to a network device an SSH connection has to be established.

3.1.1 Routers

Routers are essential devices when building multiple networks. The primary function of a router is to connect networks and thus build the internet [2]. The router’s primary task is to receive and forward data packets by their IP address to the correct destination. The router does this by keeping a routing table stored in its memory which contains information on where data packets are to be forwarded.

3.1.2 Switches

Similarly to routers, switches are integral and essential for building networks. The main function of a switch is to connect end devices (such as PC:s and servers) to a network [3]. A switch forwards packets based on the MAC (Media Access Control) address. Some switches have the capability to forward packets based on IP addresses and support some functionalities normally found in a router and thus lightening the load of the router.

3.1.3 Secure Shell (SSH)

SSH is a remote access protocol that encrypts traffic between endpoints [4]. SSH uses a client and server model, where the client establishes a connection to the server. With this connection, a tunnel is made which will enable the client and the server to transfer encrypted data between each other. To ensure the identity of the endpoints and that they are authentic, SSH uses symmetric encryption.

3.2 Virtualization

Virtualization is the process of sharing or splitting computer resources to create virtualized IT services (e.g. servers and network devices) separated from the physical hardware [5]. This allows for several virtualized systems to reside on the same physical hardware [6]. To meet different requirements, virtualization can be done through several means (e.g. hardware virtualization, application virtualization, and network virtualization) [7]. To enlarge the number of network devices used during our experiments in a cost-efficient way virtualization has been used with the network virtualization tool GNS3. With the use of virtualization, the experiment can scale to a number of network devices with less economic cost than what is possible with physical equipment.

When using virtualization there has to be a hypervisor that interacts with the physical hardware [8].

(8)

To virtualize our automation server the hypervisor software VMware ESXi⁴ and VirtualBox⁵ are used.

3.2.1 Graphical Network Simulator-3 (GNS3)

GNS3⁶ is a network virtualization tool used for virtualizing network devices [9]. It is an open- source virtualization tool licensed under GNU GPL⁷and is a widely used tool for designing, testing, and experimenting with different network topologies. GNS3 is one of the few virtualization tools that support multi-vendor implementations of network devices [10]. GNS3 virtualizes network devices by loading and running a real Operating System (OS) which means all functionalities and commands found in a physical device with the same OS are available for use on the virtualized network device in GNS3. By using GNS3 as our virtualization software, OS from network device manufacturers can be uploaded to the virtualized environment and create a virtualized network topology. This allows for greater control over the network topology and the number of devices can be scaled further without compromising economic cost compared to the creation of a physical network. GNS3 makes use of nested virtualization⁸ for virtualizing several devices on the same server. However, nesting several devices on the same server may come with a performance loss.

3.3 Infrastructure as Code (IaC)

IaC is a term for describing the process of automating server and network infrastructure with the use of software [1]. Involving software when provisioning and executing configuration changes on server and network infrastructure grants consistency not possible with manual configuration.

Implementing IaC removes the need for IT staff to manually manage repetitive and routine tasks.

With IaC implemented, several services and resources can dynamically be provisioned to users without the need for IT staff to manually manage it. With a well-managed system using IaC, everything can be logged. This eases troubleshooting when every change made is documented with a timestamp.

IaC has two main approaches for deployment: (1) declarative and (2) imperative [12]. Declar- ative deployment can easiest be described as what the eventual configuration should aim to be, consisting of requirements and constraints. The software then interprets the description and configures the target configuration. Imperative deployment can be described as how the software should reach the eventual configuration. Imperative deployment consists of a full-fledged plan for the software to follow from start to end.

IaC automation performs configuration via two different methods: (1) agent-based configuration and (2) agentless configuration [13]. Agent-based configuration operates with the use of agent software placed on the devices in the network. The network topology consists of several software agents on the desired devices with a central controller/master server managing all agents. The installed software agents search and fetch configuration from the controller to ensure they are running the correct and latest configuration. This method of fetching data from a central control server is often referred to as a pull configuration, because the software agents are pulling configuration from the control server. The alternative to an agent-based solution is running an agentless configuration method. When implemented, there is no additional software installed on the devices.

Hence, the network topology consists only of a controller/master server. The controller sends the configuration changes to all specified devices. This method of sending all the configuration changes to all devices is often referred to as a push configuration. The controller pushes the configuration changes to all specified devices.

4https://www.vmware.com/se/products/esxi-and-esx.html

5https://www.virtualbox.org/

6https://www.gns3.com/

7https://www.gnu.org/licenses/gpl-3.0.en.html

8Nested virtualization is when a hypervisor runs one or several other hypervisors with their own respective virtual machines [11]

(9)

3.3.1 Infrastructure as Code for Networking

Implementing IaC in networking and automating it with the help of automation tools help reduce the costs and complexity of network operations [14]. Research from 2020 [14] demonstrates that approximately 95% of network configurations are done manually and that up to 70% of policy violations are because of human error. The use of an automation tool enables rapid configuration, batch configuration, and lowers the risk for human errors when configuring network devices. One of the largest benefits of implementing an automation tool is that every configuration change is located in one file [15]. This allows for greater network control and eases troubleshooting. Nor- mally if a network error occurs due to a configuration mistake, it would be necessary to manually check several network devices. Instead, the error can be pinpointed directly to a misconfigured configuration file. This is valuable today since network uptime is considered a number one priority for most clients because network downtime can contribute to a major loss of revenue and custom- ers [14]. Implementing network automation can help decrease downtime of unexpected failures and errors by containing the problem in a single configuration file.

The problem that emerges with the automation of network devices is the limitations these devices have [14]. Closed and proprietary OS mean no additional software can or should be installed on these devices, thus removing the ability to use a pull configuration via an agent-based configuration method. Different software vendors have approached this challenge with their products to adapt to a push configuration methodology. This is either done by completely switching to an agent-less solution or by utilizing additional server resources to create proxy agents. The proxy agent will fetch configuration changes in a pull configuration manner and then relay the configuration via SSH to the target device. However, this method of configuring network devices may not be desirable since it requires additional server resources to install the proxy agents. Among the more popular automation tools (in the number of users) are Ansible, Puppet, SaltStack, Chef, Cloudformation, and Terraform [16]. Ansible, Puppet, SaltStack, and Chef are considered configuration management tools which means they configure and manage software on servers and network devices. Cloudformation and Terraform are considered orchestration tools which means they pro- vision servers and network devices. Since this thesis aims to investigate automated configuration of network devices we have chosen to compare configuration management tools and more specifically Ansible, Puppet, and SaltStack. These three automation tools either do all their operations in a push configuration manner or have the ability with an addition to the original software that allows them to use a combination of push and pull configuration.

(10)

4. Related Work

Ohldin [17] examines router configuration using Python scripting, focusing on the execution time, amount of bytes sent, and the amount of packets sent during manual configuration relative to automated configuration with Python scripting. Ohldin investigates how configuration time and bandwidth usage affect a scaling network when comparing a virtualized environment and an environment with physical equipment. Ohldin connects the two environments with the virtualization software VMware Workstation. In the experiment, a GNS3 server is constructed and used to build a virtualized network consisting of network equipment with the Cisco Internetwork Operating Sys- tem (IOS). In the case study, three different cases were investigated. The first case with manual configuration, the second case with a simple Python script to configure the devices, and the last case with automation based on a self-made automation system. In the experiment, each case is used with one router, three routers, and seven routers. The measurements are analyzed with Wire- shark. Ohldin analyzes data to find patterns that could be of interest. This research relates to our thesis in terms of the measuring data and the automation process. What Ohldin demonstrates is how automated configuration compares to manual configuration. Our thesis focuses on automation tools rather than automation with self-written Python scripts. One detail that differs from our thesis and this experiment is that our thesis is measuring a larger sample of devices and also compares how the automation tools performs on virtualized and physical network devices. Our thesis researches what functionalities the automation tools possess.

Kostromin [18] lists the following six points about Software Configuration Management (SCM) tools: SCM tools need to support a wide range of OS, full control at every stage of node configurations for the computing infrastructure, easy deployment with minimal preparation of user nodes, free distribution, server-side initialization of slave node configuration changes, and node management using the SSH protocol. In this paper the discussion focuses on the well-known SCM tools. The survey lists the most popular SCM tools which are Ansible, Chef, Puppet, and Salt- Stack. He then goes on to explain the difference between agent and agentless architecture. Ansible is the only one with a fully agentless architecture while SaltStack is limited with its agentless architecture because it works slower than its main architecture. In this study, Kostromin chose Ansible and Puppet because they both use or can use a push delivery method. The survey lists the advantages and disadvantages of both Ansible and Puppet. Puppet is a well-known and stable product and is in continuous development. The Graphical User Interface (GUI) is user-friendly and supports a large variety of OS. The disadvantage is the poor performance compared to the automation systems written in Python. Puppet is written in Ruby and it is necessary to learn the proprietary Puppet language to define configurations. Ansible is described as a high-performance system which uses an agentless architecture. It is a system that has low overheads and is easy to learn. However, Ansible for all its benefits is a relatively new system and Windows support is only possible through PowerShell. In the experimental environment, Kostromin constructed ten hosts with two different OS. The survey then compares the time taken to configure the nodes with manual, Ansible, and parallel SSH. One table illustrates that manual configuration for ten nodes is multiple times slower than both parallel SSH and Ansible. Ansible is slower than Parallel SSH.

Kostromin talks about limitations to the study and why Parallel SSH is unacceptable for numer- ous heterogeneous nodes in an environment. He continues with the limitation of parallel SSH and its complexity of maintaining and deployment of scripts. Ansible does not share this limitation.

Kostromin concluded that Ansible is advantageous to use because it provides an improvement in the quality of development, testing, and distribution of modules. This study relates to our thesis concerning network automation and the advantages of using an automation tool to configure nodes in a network. Kostromin looks at the configuration time which is one of the aspects we take into consideration when comparing multiple automation tools. The survey lists four SCM tools, of which we have chosen three to compare and analyze.

Mazin et al. [19], compare automation scripts using Python and manual configuration. They look at configuration times, amount of errors, and applicability. They construct a network of 36 Cisco devices which they configure manually and by using an automation script with Python. They also check 765 Cisco devices and if the devices are active or not by using a Python program. They

(11)

measure the configuration time by starting a stopwatch at the start of the test and then stopping it when the last device is configured. The manual configuration takes 5797 seconds to configure 36 Cisco devices. During the manual configuration test, two errors are detected when reviewing the configuration files. The configuration consist of seven steps. Step one is checking if the IP address were pingable, the second step is to log in to the Cisco device, the third is changing the password, the fourth change is to configure the enable-password, the fifth is to receive the version, hostname, and uptime, the sixth step is to save the IP address and previous steps in a Excel sheet.

The last step is to send the Excel sheet attachment by email. Mazin et al. discover that it is a large contrast between manual configuration and automated configuration. Manual configuration takes 5797 seconds for the 36 Cisco devices, while automation only takes 120 seconds. For each device, this becomes even more clear, manually configured devices take 161.02 seconds and the Python program takes 3.33 seconds. This is equivalent to two percent of the manual configuring time. They suggest that an enterprise with network automation can change passwords on a large number of devices in a short amount of time. Network automation would increase the security of the network. Their conclusion is that network automation improves the efficiency of configuration in terms of speed and error reduction. Mazin et al. research’s is significant for this thesis as they compare manual configuration and network automation. They look at error reduction which is a large part of automation and at the time savings achieved which are comparable with this thesis’

aim to look at different automation tools execution time.

Lee et al. [20] set out to answer the question of how we should automate network configuration. The paper investigates where the complexity lies in network configuration. They collect data in form of configuration files from three different networks of varying sizes. In two of the networks there are a mix of Juniper and Cisco routers. They then search for the most used commands in the configuration files. They use the metric of Lines of Code (LOC) to measure the complexity of the code and their findings are that routing policies are the ones with the most LOC. They examine if the configuration changes frequently and if the changes are smaller or larger. They could see that most often the changes are fifteen LOC or less. Their conclusion is based on four parts. They draw the following conclusions. Firstly, individual commands should be made manually if the changes are small for the daily operations. Secondly, they should be able to describe the policies which would be set in motion incrementally. Thirdly, automation could classify network elements with high impact and risk. Operators could then prioritize those responses to the network elements accordingly. Fourthly, automation can look for patterns and let the operators view possible configurations and ensure consistency over the network. Our thesis aims specifically to evaluate the performance of automation tools. The purpose of the study is to determine when it is inefficient to use automation regarding the number of configuration changes. This helps us set a parameter on the minimum and maximum number of configuration changes.

(12)

5. Method

To perform and conduct an analysis of the automation tools a theoretical and performance comparison is made. To perform the theoretical and performance evaluation this thesis consists of a literature overview and an experiment. The method used is visually represented by the flowchart seen in Figure1.

Overview of documentation

Designing the

experiment Conduct

experiment Analyze results Conclusion Figure 1: Flowchart used during this thesis

The thesis is initiated with a literature overview to receive a more in-depth view of the software and equipment used. The literature overview then continues with identifying relevant sections in related work useful for our thesis. This includes documentation from developers of the selected automation tools and previous research done in our field of study. During the literature overview, planning of the experiment will commence [21, p. 85]. The experimental environment is then as- sembled and relevant tests and measurements are performed on different sized networks. This is done to evaluate and identify how the automation tools perform on networks with different amounts of installed network devices. After the experiment is conducted the results are analyzed and de- termined if they are relevant or if the experiment has to be redone for new data to be collected.

When experimenting it is important to minimize external factors that can impact and influence the results. By performing our experiment in a closed network environment we can control most dependent and independent variables during the experiment.

The experiment together with the literature overview provides us the results and data required to perform an evaluation. The evaluation’s objective is to answer the research questions asked at the beginning of the thesis. Lastly, the evaluation includes a comparison of other non-functional properties of the automation tools such as setup complexity and configuration complexity.

(13)

6. Ethical and Societal Considerations

During this thesis, we consider there is no ethical stance to consider. No confidential information is used. Our experimental setup is unavailable from the public internet and no sensitive network information will be used. IP addresses used belongs to the private IP ranges and login information is unique and created solely for this thesis. Since this thesis involves a comparison of three different automation tools from different major companies it is important we remain impartial to ensure our results and measurements remain unbiased.

When dealing with automation in general there is commonly an ethical discussion involving the societal considerations on whether or not automation will make manual labor obsolete. This includes network automation where an engineer will implement automation to a network and thus, removing the necessity of engineers dealing with day-to-day tasks. However, it is important to note that when an increasing amount of companies choose to switch from manual tasks to automation there will be a lack of competence to implement these changes. In many cases, engineers will not loose their jobs but will instead be relocated to a different job with new tasks. Network automation may remove some professions but new ones will be created. During this thesis, we will not take a stand on whether network automation is right or wrong. However, the results we present may be used as a basis for a pro-network automation argument.

(14)

7. Overview of the Automation Tools

The overview identifies potential automation tools that are suitable for configuring network devices.

Even though there are many automation tools available there are only a handful of options compatible and optimal for configuring network devices. We chose three different automation tools compatible with configuring network devices. One of the main reasons Ansible, Puppet, and Salt- Stack are compatible for configuring network devices is that they offer an agent-less option. This is preferred because it is difficult and not recommended to install agents on closed proprietary OS.

The overview seeks to find similarities and differences between the automation tools and what capabilities they possess. We research and gather information from official documentation from Ansible⁹, Puppet¹⁰, and SaltStack¹¹. Even though the automation tools are capable of achieving the same goal they achieve it differently. The technical information makes it possible for us to analyze theoretical similarities and differences. The overview is presented in Table1 and a more in-depth description of the automation tools can be found in the following sections.

Ansible Puppet Bolt SaltStack

Operating System Linux, macOS Linux, macOS, Windows Linux, macOS

Initial Release February 2012 October 2018 March 2011

Current Release 5.0.1 (2021-12-02) 3.22.1 (2022-03-30) 3004.1 (2022-03-28)

Written in Python Ruby Python

Source code Open Open Open

Declarative/Imperative Both Both Both

Agent/Agentless Agentless Agentless Agentless(Proxy agents)

Push/Pull Push Push Both

Communication Protocol SSH SSH/WinRM SSH and SCP

Script language YAML YAML/Puppet Language YAML/SLS(Salt State File)

License GNU GPL-3.0 Apache-2.0 Apache-2.0

Terminology Playbook/Hosts Manifest/Targets States/Pillars Table 1: Properties of the automation tools Ansible, Puppet Bolt and SaltStack

7.1 Ansible

Ansible is a configuration management, deployment, and software provisioning tool used for automating network configuration and management developed by RedHat Inc [22]. Ansible is open- source and built upon the programming language Python which allows for great flexibility and control. To execute commands Ansible relies on user-written scripts using YAML syntax. Ansible is developed to be in its entirety an agentless solution. When using Ansible only an initial install- ment has to be done on the hosting server. To be an agentless system Ansible relies on SSH to install and configure devices.

To configure devices Ansible relies on the use of a hosts file and a playbook file [23]. The hosts file contains the hosts to configure. The file has to contain an IP address or a domain name to a host to allow for remote connection. Additional login information should be specified to allow an SSH connection. Hosts can be grouped in the hosts file which makes it possible to reference the group name upon execution and all hosts linked to the group name will be configured. Another essential part of Ansible is the playbook file. The playbook file contains instructions and acts as a template for how Ansible should proceed with the configuration. Within the playbook file, a host or a group from the hosts file is specified to declare where the configuration should be targeted.

Several commands can be specified in the same playbook file and Ansible will execute them one after the other. To ease the creation of a playbook file Ansible supports the use of predefined modules. Using modules will prompt Ansible to use a declarative deployment. When using modules

9https://www.ansible.com/

10https://www.puppet.com/docs/bolt/latest/bolt.html

11https://www.saltproject.io/

(15)

the playbook file will not contain any configuration commands for the routers. We instead define what the eventual configuration should aim to be and Ansible will decide the ideal course of action to reach the desired state.

7.2 Puppet

Puppet is an open-source configuration management tool created by Puppet Labs Limited and built upon the programming language Ruby. Originally Puppet is an agent-based solution, but as described in section3.3.1 this solution is not applicable for network devices which lead to the creation of an alternative tool that uses agent-less configuration. Puppet Bolt is an addition to Puppet. Puppet Bolt adds the ability to configure via an agent-less method and thus, enabling configuration of network devices. Puppet Bolt can configure devices through SSH or Windows Remote Management (WinRM). However, since this thesis is aiming to configure network devices, Puppet Bolt is used together with SSH. Similar to Ansible, Puppet Bolt utilizes user-written scripts using YAML syntax to define which changes and commands should be executed.

Similarly to Ansible, Puppet Bolt requires two separate files to be configured. These two files contain the targets and the configuration changes that will be applied. The targets are defined in Puppet Bolts inventory file whilst the file containing the configuration changes is defined in a manifest file. The inventory file contains all information required to establish an SSH connection.

Similar to Ansible, targets can be grouped which enables configuration changes to be targeted at a group instead of referencing one target at a time. With Puppet Bolt, commands can be issued separately via the command line. However, this is often not desirable when several commands are to be issued. Commands can instead be accumulated in a manifest file to make the process more efficient. Manifest files can be written in either YAML or custom Puppet language. Several commands can be specified in the same manifest file and Puppet Bolt then executes them one after the other. Puppet Bolt supports the use of modules similar to Ansible. However, the modules available for Cisco devices do not support the router OS used in our experiment. This means that Puppet Bolt is used by sending configuration commands to the routers.

7.3 SaltStack

SaltStack also known as Salt, is an open-source configuration management tool created by Salt Stack Inc and built upon the programming language Python. SaltStack is originally an agent-based solution similar to Puppet and faces identical problems with network devices not being able to use agent-based configuration. SaltStack has made an open-source addition to the original program to enable agent-less configuration for network devices. Salt SSH works as the name suggests over SSH. Salt SSH uses YAML as its scripting language for defining changes and commands to execute.

However Salt SSH faces issues when connecting to network devices and a workaround is the use of proxy agents. When configured, the proxy agent will gather and receive updates from the master which it will relay and apply to the network devices through SSH.

A proxy agent together with help of the Network Automation and Programmability Abstrac- tion Layer with Multivendor support (NAPALM) Python library enables a more manageable and efficient workflow compared to Salt SSH for configuring network devices with SaltStack. NAPALM contains functions for configuring Cisco devices and eases the configuration process. The imple- mentation consists of one salt-master and a salt-proxy per network device which are both manually configured. Both can be located on the same server or device. When the salt-proxy is initiated it will contact the salt-master and when the connection is established between the salt-master and the salt-proxy it will try to connect to the specified network device it is assigned to. One proxy agent can only manage one network device which means several proxy agents have to be created for implementing a solution with SaltStack. When the salt-proxy has established a connection to the salt-master and the network device the salt-proxy will gather or receive configuration changes from the salt-master which shall be applied to the network device. When there is no configuration change to be made the connection to the salt-master and the network device will remain active.

This methodology is based upon the agent-based configuration method which implies that the

(16)

agents should remain active at all times.

8. Network Topology and Execution of Measurements

In this section, we provide details on how the experimental environment is set up and how the measurements are conducted. The testing and measurements are carried out on both virtual and physical equipment. The virtual equipment is constructed with the network simulation software GNS3 at Atea. Experimenting on physical equipment is conducted at Mälardalens University.

8.1 Virtual Network Setup

The network topology is constructed in collaboration with Atea using their equipment. The network architecture consists of a firewall, one router, two switches, one VMware ESXi server, one Access Point, and one Wireless Controller. See Figure 2 for a visual representation of how the network is designed.

VMware Esxi

Router Firewall

Switch 1

Internet

Access Point Switch 2

Wireless Controller

Figure 2: Network Topology built at Atea

The network is secluded from the production network used at Atea which means no external traffic hampers the result. The router is configured as a "router on a stick" where several Virtual Local Area Network (VLAN) are configured. Three VLANs are configured (10, 15, and 20). VLAN 10 acts as a server network where all the physical equipment is allocated with an IP address from this VLAN, VLAN 15 acts as a management VLAN to enable management traffic on the network, and VLAN 20 is created as a client network so different clients (such as computers and virtual machines) can connect to the network. The Access Point and Wireless Controller are part of the network topology to enable a wireless connection to the network.

8.1.1 VMware ESXi

The VMware ESXi server is configured with five different virtual machines. One GNS3 server, an Ansible machine, a Puppet machine, a SaltStack machine, and a Windows Server 2019 machine.

The Windows Server 2019 acts as a Dynamic Host Configuration Protocol (DHCP) server. With a DHCP server on the network, there is no need for us to manually set static IP addresses on every single device. The DHCP server allows us to easily join new devices to the network. To enable the virtual machines to connect to the rest of the network all of the virtual machines are configured within VMware ESXi with a bridged network adapter. Enabling this setting will connect the virtual machines’ network card to the physical machine’s network card.

The GNS3 server is installed according to Appendix A as a virtual machine on the VMware ESXi server. When the GNS3 server is installed the remaining configuration is done by remote connection to the GNS3 server, either via the GNS3 desktop application or by connecting through

(17)

a web browser. After establishing a connection to the GNS3 server via the IP address and port number specified by the GNS3 server’s interface on the virtual machine a testing setup is constructed. The test setup consists of virtual routers that run a Cisco IOS and more specifically the c7200-advipservicesk9-mz.152-4.S5 OS.

The Ansible, Puppet, and SaltStack virtual machines are all installed with Ubuntu version 20.04.

For the automation tools to work on equal footing with each other, it is decided they should operate with the same OS. As seen in Table 1 an OS based on Linux would be able to run all automation tools. Ubuntu is a popular Linux distribution with a package management system based on Debian and it is chosen for its user-friendly User Interface [24]. Communication between the virtual machines hosting the automation tools to the virtual network topology hosted by GNS3 is internal since all the virtual machines are directly connected through the VMware ESXi server.

8.1.2 Virtual Network Topology

The virtual network topology is built within GNS3 for testing the automation tools. The topology is built on the VMware ESXi server with a Cisco image¹²for a Cisco 7200 router. Due to resource limitations of the server, the virtual environment is limited to twenty network devices. Figure3 shows the topology of the virtual network.

Bridge to Physical Network

Virtual environment

Figure 3: Virtual Network Topology made in GNS3 hosted on the VMware ESXI server The switches seen in Figure3 are integrated GNS3 Ethernet switches. These switches are used to connect the virtual routers and to connect the virtual routers to the bridged network adapter which enables them to communicate with the network outside of the GNS3 server. The reason for using several switches is that the GNS3 standard switches have a limited amount of interfaces.

This means that several switches are needed to connect all the virtual routers. All routers are preconfigured with a default configuration to enable an SSH connection. The default configuration consisted of: assigning an IP address to an interface, creating a user to enable login, and the activation of SSH.

8.2 Physical Network Setup

The measurements performed on the physical equipment are identical with those we performed on the virtual equipment. The automation tools are configured identically and tasked to configure the same configuration changes done on the virtual equipment. The automation tools are installed on virtual machines hosted on VirtualBox.

The experiments with physical equipment, use a total sixteen Cisco 2811 routers with Cisco IOS 12.4 are used. Sixteen routers are used because of a limited number of routers available. The physical routers are preconfigured with an identical default configuration as the virtual routers to

12The Cisco IOS is built using a binary image which is uploaded to the network device [25].

(18)

enable an SSH connection. The physical routers are all connected to a single Cisco 2960 switch.

The switch connects all physical routers. The virtual machine connects to the switch which enables the automation tools to configure the physical routers. Configuring the virtual machines within VirtualBox to use a bridged network adapter, enables the virtual machine to communicate with the physical network. See Figure4 for a visual representation of the physical network topology.

Figure 4: Physical Network Topology

8.3 Execution of Measurements

To gather enough data to analyze, a script¹³is written to automate our automation configuration.

The script is written in the command language Bash, which specializes in Linux shell scripting.

The script allows us to execute a task several times after each other without the need for manual intervention. This provides us the ability to gather more data to analyze which in turn provides us a more precise result. The script consists of three different tasks. The first task is to initiate the automation tool and measure the time to complete the configuration changes. The execution time is then directed to a text file where it is stored for us to collect once the script is finished. The second task of the script is to measure the amount of data that is sent during the first task. The calculated amount of data is redirected to a separate file for us to collect once the script is finished.

After the second task is done the automation tool has configured all routers that are specified to be configured. The last task of the script is to clear and revert all the network devices to a state they held before the script is initiated. After the third task is completed the script restarts and continues the process once again. Each of the experiments are repeated 50 times. See AppendixE for the script used during the measurements. The automation tools perform the following changes:

Set login banner:

- This sets the specified text as a banner when someone logs in to the device.

Apply IP address to two interfaces:

- This applies two different IP addresses to two different interfaces and activates them.

13Scripting is used to automate certain tasks with programming.

(19)

Set a static IP route:

- This sets a static IP route and applies it to the router’s routing table.

Configure a management Virtual Routing and Forwarding (VRF):

- This sets and configures a VRF named management.

Set a Network Time Protocol (NTP) server:

- This configures a NTP server on the router.

Set a Access Control List (ACL):

- This will configure an ACL to limit entry to the network.

Set a new hostname:

- Configure a new hostname on the router.

Add a new user:

- This will configure a new user on the router with a username and a password.

Add a description to an interface:

- This will add a description to an interface to document its properties.

8.4 Ansible

The installation of Ansible is done on a virtual Ubuntu machine through the Command Line Interface (CLI), see AppendixBfor installation and deployment. Once the installation is completed an Ansible configuration file is created and by default found at /etc/ansible/ansible.cfg. This file needs some tweaking to allow us to configure network devices via SSH. We also change a setting that will allow Ansible to configure several devices at once. Per default, Ansible will only configure five devices simultaneously. This is done to put Ansible on equal footing with the other automation tools. The last edit we make to the configuration file is to make Ansible display the execution time after it is finished. The changes we make in the configuration file are:

fork = 20

host_key_checking = False callback_whitelist = timer

After these changes are made to the configuration file a hosts file is created. The hosts file contains the information needed for Ansible to establish a connection. Within the hosts file groups can be constructed to simplify management. If the same configuration is to be established on several devices, a group can be created and called upon instead of individually calling several network devices. The next step is to create a playbook file. A playbook file contains the network device’s configuration changes. The configuration changes we write in the playbook file use YAML syntax.

For our measurements, two different playbook files are created. One contains three configuration changes and one contains ten configuration changes. Since we make a change to Ansible’s configuration file it displays the time to execute the playbook file. This time is captured by our script and stored in a text file for us to collect once the measurements are completed. For instruction on how to construct a hosts file and a playbook file in detail, see AppendixB.

8.5 Puppet

The installation of Puppet Bolt is done on a virtual Ubuntu machine through the CLI, see Ap- pendixC for installation and deployment. Unlike Ansible we do not change the configuration of Puppet Bolt since it operates the way we intend with a fresh installation. After the installation is complete we create an inventory file that uses YAML syntax. Similar to Ansible, groups can be constructed within the inventory file to simplify management. The inventory file contains the necessary information for Puppet Bolt to establish an SSH connection to the network devices. The next step is to create a manifest file. A manifest file contains all the configuration changes which

(20)

are to be carried out by Puppet Bolt. Two manifest files are created, one containing three configuration changes and one containing ten configuration changes. Puppet Bolt displays by default the run time after each execution. This run time is captured by our script and stored in a text file for us to collect once the measurements are completed. For instructions on how to construct an inventory file and a manifest file in detail, see AppendixC.

8.6 SaltStack

The installation of SaltStack is done on a virtual Ubuntu machine through the CLI, see AppendixD for installation and deployment. After the installation is completed we do not change the configuration of SaltStack, because like Puppet Bolt it operates the way we intend with a fresh installation.

Once the installation is complete the next step is to create pillar files. The pillar files contain all the necessary information needed for SaltStack to establish an SSH connection. One pillar file is created for every network device we wish to configure. The pillar files are then summarized in a top file. The top file contains a destination to every pillar file and associates the pillar files with an alias. Both the pillar file and the top file use YAML syntax. After constructing the top file, the Salt Master and the Salt proxy agents can be initiated. One Salt proxy agent is initialized for every network device we wish to configure. Once the Salt proxy agents establish a connection to their target device they will wait for instructions from the Salt Master and keep the connection established to the target device. The configuration changes are written with Cisco IOS commands in an ordinary text file. When the Salt Master initiates the configuration with proxy agents, it will send the configuration file which contains the commands. Then the Salt proxy agents distribute the file to their target devices via the data communication protocol Secure Copy (SCP). Two of these configuration files are created which contain three and ten configuration changes. To capture the time it takes to configure all the changes we use the Bash command time. The time command displays the time it takes to complete a command. This time is then captured by our script and stored in a text file for us to collect once the measurements are completed. For instruction on how to construct a pillar file and a top file in detail, see AppendixD.

(21)

9. Results

The following section presents the results of the experiment we conduct with the three automation tools Ansible, Puppet, and SaltStack. The experiment consists of measuring the performance and network usage generated by the automation tools. During the experiment, we measure the time needed to complete the configuration and capture the amount of bytes sent during the configuration process. Every automation tool is tested with four different quantities of network devices and two different quantities of configuration changes. Additionally, we conduct measurements to evaluate the differences between using a virtual and a physical environment. This results in sixteen different measurements performed by each automation tool. However, this excludes SaltStack because GNS3 does not support functions to allow SaltStack to configure virtual network devices. For each measurement, we execute 50 times to gather a sufficient amount of data to analyze.

9.1 Experimental Results

In this section, we evaluate the performance of the automation tools by measuring the time of completion for the automation tool to configure all changes on the specified number of routers. To evaluate the network usage of the automation tools the amount of bytes sent during the configuration change is captured, see section8.3for an explanation on how we measure the time and amount of data sent during the configuration phase. With knowledge of the amount of bytes sent and the configuration time we are able to calculate the amount of bytes sent per second. With knowledge of the network bandwidth, we are able to determine the network usage of the automation tools.

Lastly, our measurements are conducted to determine how scalable the automation tools are when the number of network devices are increased, which is our fourth research question. To ensure the measurements are fair the automation tools configure the same changes. See section 8.3 for the changes used in this thesis.

9.1.1 Measurements conducted on physical equipment

During the measurements on physical routers, all three automation tools are evaluated by performing eight different tests. During the first four tests we measure the configuration time, network bandwidth, and total data transferred when applying three changes on one, five, ten, and sixteen routers. During the other four tests we measure the time, network bandwidth, and total data transferred when applying ten changes on one, five, ten, and sixteen routers. We conduct these two types of measurements to evaluate the automation tools when applying a small number of changes and when applying a larger number of changes.

7 12 17 22 27 32 37 42 47 52

1 5 10 16

SECONDS

Average Configuration Time - Three Changes

Ansible Puppet Saltstack

Figure 5: Average configuration time when configuring three changes on physical routers

Figure 5 illustrates the average time of configuration when configuring three changes on an increasing numbers of physical routers. All three automation tools increase their configuration time at a steady rate when the number of routers are increased with the exception of the configuration time of SaltStack from five routers to ten routers. During this interval the configuration time levels

(22)

out. The reason SaltStack does not increase as the other automation tools is due to its use of individual proxy agents configuring their separate routers. See section7.3for an in-depth explanation of proxy agents. Excluding this exception, the configuration time increases for all automation tools when the number of routers is increased. Puppet retains a higher configuration time throughout all measurements. However, Puppet has a lower standard deviation than Ansible and SaltStack through out all measurements. This means Puppet has a more consistent configuration time and does not fluctuate as much as Ansible and SaltStack between individual measurements.

0 50000 100000 150000 200000 250000 300000 350000 400000 450000 500000

1 5 10 16

BYTES

Average Bytes Sent - Three Changes

Figure 6: Average amount of bytes sent when configuring three changes on physical routers

Figure 6 illustrates the average amount of bytes sent when configuring three changes on an increasing number of physical routers. All three automation tools increase the amount of bytes sent at a similar rate with Puppet sending the least amount of bytes throughout all measurements excluding the last. During the last measurement SaltStack almost retains the same amount of bytes sent when configuring ten routers and only increases by a small margin. This deviation is due to its use of proxy agents which can provide inconsistent readings. See section 7.3 for an in-depth explanation of proxy agents.

0 0,005 0,01 0,015 0,02 0,025 0,03

1 5 10 16

MB/S

Network Bandwidth - Three Changes

Figure 7: Average network bandwidth used when configuring three changes on physical routers

Figure 7 illustrates the average network bandwidth used when configuring three changes on an increasing number of physical routers. All three automation tools increase the amount of bytes sent during the configuration when the number of routers are added except for SaltStack. Dur- ing the configuration of ten routers the data sent by SaltStack spikes. What we notice is that SaltStack sends a similar amount of data when configuring ten routers and sixteen routers, see figure6. However, due to the configuration of ten routers having a lower configuration time than the configuration of sixteen routers, the resulting calculation of network bandwidth leads to the configuration of ten routers having a higher average network bandwidth usage. The reason Salt- Stack sends the same amount of data is due to the use of proxy agents. Even though the proxy agents are not tasked with updating any configuration they send periodic data to the routers to ensure the connection is still alive. See section 7.3 for an in-depth explanation of proxy agents.

(23)

This means that SaltStack should be sending more data than the other automation tools since it has a constant connection to the routers even when there is no configuration to be made. When analyzing the configuration time and network bandwidth we see that whilst Ansible and SaltStack have a lower configuration time they achieve a higher network bandwidth usage compared to Pup- pet. This means that Ansible and SaltStack send more data in a shorter amount of time compared to Puppet.

7 17 27 37 47 57 67 77 87

1 5 10 16

SECONDS

Average Configuration Time - Ten Changes

Figure 8: Average configuration time when configuring ten changes on physical routers

Figure 8 illustrates the average configuration time when configuring ten changes on an increasing number of physical routers. Most notable during these measurements is that Ansible now has a longer configuration time compared to Puppet and SaltStack. Even though the number of configuration changes have increased, the configuration time for Puppet and SaltStack is unaffected compared to the configuration time when configuring three changes. This is due to Ansible using modules to configure the routers whilst SaltStack and Puppet send commands to the routers. See section7.1 for an in-depth explanation of Ansible modules. The only difference from the configuration of three changes to ten changes for Puppet and SaltStack is that they send seven more commands to the routers which does not result in a major performance loss.

0 200000 400000 600000 800000 1000000 1200000 1400000 1600000

1 5 10 16

BYTES

Average Bytes Sent - Ten Changes

Figure 9: Average amount of bytes sent when configuring ten changes on physical routers

Figure9illustrates the average amount of bytes sent when configuring ten changes on an increasing number of physical routers. During the measurements Puppet and SaltStack send approximately the same amount of bytes whilst Ansible sends more bytes. This is due to its use of modules. When the number of modules are increased, Ansible starts sending data at a higher rate than Puppet and SaltStack. Ansible modules are resource heavy resulting in more data sent.

Figure 10 illustrates the average network bandwidth used when configuring ten changes on an increasing number of physical routers. The figure reveals the same trend for Ansible and Puppet when configuring three changes except for SaltStack which possesses a higher network bandwidth usage than Ansible, see figure7. It is expected that SaltStack will use more network bandwidth

(24)

0 0,005 0,01 0,015 0,02 0,025 0,03 0,035

1 5 10 16

MB/S

Network Bandwidth - Ten Changes

Figure 10: Average network bandwidth used when configuring ten changes on physical routers

than the other automation tools because of its use of proxy agents. All automation tools use approximately the same amount of network bandwidth when configuring one router but when the number of routers increases, SaltStack and Ansible use more network bandwidth compared to Puppet which is the same trend we see when configuring three changes. For a summarized view of the data displayed in the figures5,6,7,8,9, and10when configuring three and ten changes on physical routers, see tables2,3, and 4.

Three changes Ansible (s) Puppet (s) SaltStack (s)

One router 8,7094 13,9652 9,5549

Five routers 12,2512 20,9046 11,9627 Ten routers 17,7332 34,4678 11,4940 Sixteen routers 24,3243 50,5748 17,1171

Ten changes Ansible (s) Puppet (s) SaltStack (s)

One router 39,7883 14,4132 8,8470

Five routers 42,9093 21,2846 11,5768 Ten routers 59,9732 35,1334 11,5695 Sixteen routers 89,1005 51,3418 16,9961

Table 2: Average configuration time when configuring physical routers

Three changes Ansible (B) Puppet (B) SaltStack (B) One router 27 645,4 19 967,8 33 666,7 Five routers 141 500,6 96 225,1 147 925,2 Ten routers 279 165,9 193 987,4 293 990,0 Sixteen routers 442 787,9 309 014,6 299 913,5

Ten changes Ansible (B) Puppet (B) SaltStack (B) One router 79 016,4 28 632,2 34 690,2 Five routers 353 475,8 140 344,2 151 473,9 Ten routers 816 700,2 282 838,7 297 756,2 Sixteen routers 1 432 895,0 451 825,0 510 334,4

Table 3: Average amount of bytes sent when configuring physical routers

When we analyze the data from tables 2, 3, and 4 we notice that the scalability of the automation tools depends on the number of configuration changes we apply. When configuring three changes SaltStack and Ansible have similar performance whilst Puppet has a lower performance.

(25)

Three changes Ansible (MB/s) Puppet (MB/s) SaltStack (MB/s)

One router 0,0032 0,0014 0,0035

Five routers 0,0116 0,0046 0,0124

Ten routers 0,0158 0,0056 0,0256

Sixteen routers 0,0183 0,0061 0,0176

Ten changes Ansible (MB/s) Puppet (MB/s) SaltStack (MB/s)

One router 0,0020 0,0020 0,0039

Five routers 0,0082 0,0066 0,0131

Ten routers 0,0136 0,0081 0,0257

Sixteen routers 0,0161 0,0088 0,0301

Table 4: Average network bandwidth used when configuring physical routers

However, when the number of configuration changes is increased SaltStack and Puppet are unaffected. SaltStack has the best performance when configuring three and ten changes which means SaltStack should have the best performance if we were to add even more routers. But what speaks against SaltStack is its use of proxy agents. If the number of routers is increased, the number of proxy agents increases. The process of configuring proxy agents is not effective if there is a large number of network devices to configure. With this in mind, Ansible and Puppet with their use of a pure push methodology are more scalable when the number of devices to configure are increased.

9.1.2 Measurements conducted on virtual equipment

During the measurements on virtual routers, the automation tools we test are Ansible and Pup- pet. Due to a limitation in our virtualization software GNS3, SaltStack could not configure virtual routers¹⁴. The measurements we conduct on the virtual routers are of the same type that we test on physical routers. This allows us to evaluate the differences and similarities when using the automation tools on physical and virtual routers. Due to the overhead created when virtualizing several routers the automation tools should come with a performance loss compared to the data gathered from measurements on physical routers.

0 10 20 30 40 50 60

1 5 10 20

SECONDS

Average Configuration Time - Three Changes

Ansible Puppet

Figure 11: Average configuration time when configuring three changes on virtual routers

Figure 11illustrates the average time of configuration for Ansible and Puppet when configuring three changes on an increasing number of virtual routers. Unlike the measurements we conduct on the physical equipment, Ansible performs worse than Puppet on virtual routers. This is due to Ansible’s use of modules. The modules determine if the configuration is already present. During the experiment we see that the maximum CPU power of the hosting server is in use. We see that the limitation of the hosting server affects the performance of Ansible whilst Puppet is unaffected.

14The OS used for the virtual routers does not support SCP file transmission. SaltStack relies on SCP to configure network devices.

FULLTEXT01

School of Innovation Design and Engineering Västerås, Sweden

Thesis for the Degree of Bachelor of Science in Engineering - Computer Network Engineering, 15 credits

AUTOMATED NETWORK CONFIGURATION

A COMPARISON BETWEEN ANSIBLE, PUPPET, AND SALTSTACK FOR NETWORK CONFIGURATION

Samuel Wågbrant

Valentin Dahlén Radic

Examiner: Thomas Nolte

Supervisor: Václav Struhár

Company Supervisors: Casper Möllberg and Claes Karlsson

09/06/2022

Contents

List of Figures

List of Tables

1. Introduction

2. Problem Formulation

3. Background

3.1 Network devices and protocols

3.2 Virtualization

3.3 Infrastructure as Code (IaC)

4. Related Work

5. Method

6. Ethical and Societal Considerations

7. Overview of the Automation Tools

7.1 Ansible

7.2 Puppet

7.3 SaltStack

8. Network Topology and Execution of Measurements

8.1 Virtual Network Setup

8.2 Physical Network Setup

8.3 Execution of Measurements

8.4 Ansible

8.5 Puppet

8.6 SaltStack

9. Results

9.1 Experimental Results