• No results found

Closed-Loop Orchestration Solution

N/A
N/A
Protected

Academic year: 2022

Share "Closed-Loop Orchestration Solution"

Copied!
108
0
0

Loading.... (view fulltext now)

Full text

(1)

STOCKHOLM SVERIGE 2019,

Closed-Loop Orchestration Solution

Sluten Orchestreringslösning

SONIA FERNANDES PEREIRA NEJAT HAMID

KTH

(2)

(3)

Closed-Loop Orchestration Solution

Sluten Orchestreringslösning

Nejat Hamid

Sonia Fernandes Pereira

Degree Project in Computer Engineering First cycle, 15 ECTS

Supervisor at KTH: Anders Cajander Examiner: Ibrahim Orhan

TRITA-CBH-GRU-2019:035 KTH

The School of Technology and Health 141 52 Flemingsberg, Sweden

(4)
(5)

Abstract

Computer networks are continuously evolving and growing in size and complexity.

New technologies are being introduced which further increases the complexity. Net- work Service Orchestration is all about pushing configuration out into the network devices automatically without human intervention. There can be issues that causes the orchestration to fail. In many cases manual operations must be done to recover from the error which is very contradicting since the goal of orchestration is that it should be fully automated.

There is some indication that the errors that are being solved manually could be de- tected and handled by a feedback mechanism. This thesis work aimed to build on current insight and if possible, verify that the feedback mechanism is a viable method.

After consideration on different ways to solve the research question, the choice fell on creating a test environment where the approach was tested. The test environment was used to investigate if a network orchestration system could be integrated with a feedback mechanism. The result of this project presents a way to automatically de- tect a network failure and send feedback to a Network Service Orchestrator. The or- chestrator is then able to identify and correct the error.

Keywords

Network Service Orchestration, Network Automation, feedback mechanism, manual configuration

(6)
(7)

Sammanfattning

Datornätverk utvecklas kontinuerligt och växer i storlek och komplexitet. Nyteknik införs som ytterligare ökar komplexiteten. Nätverksservice orkestrering handlar om att skicka ut konfiguration automatiskt till enheter i nätverket utan mänsklig in- blandning. Det kan finnas problem som gör att orkestreringen misslyckas. I många fall måste manuella åtgärder utföras för att lösa problemet, vilket är mycket motsä- gelsefullt, eftersom målet med orkestrering är att det ska vara fullt automatiserat.

Det finns indikationer på att fel kan detekteras och hanteras av en återkopplings- mekanismen. Detta examensarbete syftar till att bygga på aktuell insikt, och om möj- ligt, verifiera att återkopplingsmekanismen är en möjlig metod.

Efter överväganden på vilka olika sätt som projektmålet kunde uppnås föll valet på att skapa en testmiljö där ansatsen kunde testas. Testmiljön användes för att utreda om ett nätverksorkestreringssystem kan integreras med en återkopplings mekanism.

Resultat av projektet presenterar ett sätt att automatiskt upptäcka ett nätverksfel och skicka återkoppling till ett nätverksorkestreringssystem. Nätverksorkestreraren kan sedan detektera och åtgärda felet.

Nyckelord

Nätverksservice orkestrering, Nätverksautomatisering, återkopplingsmekanism, manuell konfiguration.

(8)
(9)

Acknowledgements

This report is a part of a degree project within the field of computer engineering, at Royal Technology institute. This work was done full time during half the spring of 2019. The thesis corresponded to 15 higher education credits and was performed by Nejat Hamid and Sonia Fernandes Pereira.

We would like to thank our supervisor Anders Cajander for the support during the project.

We want to thank everyone at Data Ductus for their help and expertise in the imple- mented systems.

(10)
(11)

Glossary

IOT Use of the internet with physical devices and daily objects.

OPEX Operation Expense, a continue cost to maintain

a device, service or system.

CAPEX Capital Expense, a cost for new production or

investment.

Cloud Computing Datacenter available for users over the inter- net.

QoS Measurement of a service performance

YANG A data modelling language to configure net- work devices.

Telnet Client-server protocol used to establish a con- nection to TCP port 23.

SSH Cryptographic network protocol used for re- mote command execution.

CLI (Command-line interface) Used to interact with a computer program by writing command to the program.

XML Extensible Markup Language (XML) is a

markup language that defines a set of rules for encoding documents in a format that is human and machine readable.

(12)
(13)

Content

1 Introduction ... 1

1.1 Problem ... 1

1.2 Goals ... 2

1.3 Delimitations ... 3

2 Theory and background ... 5

2.1 Network Automation ... 5

2.2 Network Function Virtualization ... 5

2.3 Software Defined Networking ... 5

2.4 Orchestration ... 6

2.5 Network Service Orchestration ... 6

2.5.1 Challenges with NSO ... 7

2.5.2 Benefits with NSO ... 8

2.6 Different Network Orchestrations Solutions ... 9

2.6.1 Cisco Network Service Orchestrator Network ... 9

2.6.2 Oracle Communications Service and Network Orchestration Solution ... 9

2.6.3 Blue Plant Network Orchestration Software ... 10

2.7 Netrounds ... 10

2.8 Principles of feedback control ... 11

2.9 Previous studies ... 11

3 Methodology ... 13

3.1 Working method ... 13

3.1.1 Methods for pre-study ... 13

3.1.2 Methods for verification ... 14

3.2 Test environment ... 14

3.3 Network Orchestration Solution ... 15

3.3.1 Network Element Driver ... 15

3.3.2 NSO Services ... 16

3.4 Network design and topology ... 16

3.5 Controller function ... 16

3.6 Test and assurance platform ... 17

3.7 Closed-Loop Orchestration Solution model ... 17

3.8 Test and experiments ... 17

3.8.1 Test to verify feedback mechanism ... 18

3.8.2 Test to verify error correction ... 18

(14)

4 Results ... 19

4.1 Network Topology ... 19

4.2 Service Applications ... 20

4.3 Feedback mechanism ... 20

4.4 SNMP handler and Alarm generator ... 21

4.5 Closed loop orchestration solution ... 23

4.6 Tests ... 24

4.6.1 Test to verify feedback mechanism ... 24

4.6.2 Test to verify error correction ... 25

5 Analysis and discussion ... 29

5.1 Discussion of the result. ... 29

5.2 Discussion of the testbed ... 29

5.3 Economical aspect ... 30

5.4 Environmental impacts ... 30

5.5 Social and ethical aspect ... 31

6 Conclusions ... 33

6.1 Future works ... 33

7 References ... 35

Appendix A – Installation of VMware Fusion, VIRL and VM Maestro ... 37

A1. Install VMware Fusion Pro ... 38

A.2 Install and configure VIRL ... 38

A.3 Install VM Maestro ... 48

Appendix B – Building the network ... 55

B1. Creating a custom network connection ... 55

B2. Building a custom network. ... 65

Appendix C – Getting started with Network Services Orchestrator. ... 77

C1. Installing Apache Ant on Mac ... 78

C2. Installation of NSO ... 79

C3. Using NSO ... 80

Appendix D – Connecting VIRL and NSO. ... 81

D1. Configure device ... 81

D2. Connect NSO and VIRL ... 83

Appendix F - Configuration for remote connection from NSO to a device. ... 89

(15)
(16)
(17)

1 | INTRODUCTION

1 Introduction

The computer network infrastructure is an essential component of any business op- eration. A network consists of multiple elements that are interconnected and geo- graphically distributed. These elements can be routers, firewalls, switches and nu- merous of physical and virtual devices.

Networks are continuously evolving and growing in size and complexity. New tech- nologies are being introduced which further increases the complexity. Networks are expanding with new technologies like 5G and cloud computing. The introduction of Internet of Things (IoT) devices will further contribute to more advanced networks.

To manage the challenges with network expansion, automatization has become one of the hottest topics in the industry today. Network Service Orchestration (NSO) of- fers a solution to control, orchestrate and handle new users, services and network configuration automatically.

1.1 Problem

Due to the significant growth of network infrastructures and increasing traffic vol- umes, network operators are faced with challenges to control and maintain new net- work services.

In order to handle a large-scaled network, companies need experts and sufficient resources. The evolution in different dimensions as IoT and virtualization is a big challenge to face. One of the areas of networking that is affected is configuration management. In traditional network management, network operators have config- ured the network manually. But the network operators are having difficulties in keeping up with the amount of new services and devices that are constantly being introduced. They struggle to obtain sufficient competence to coordinate, handle and operate the fast-growing networks and its services. The growing complexity also has an impact in quality assurance where testing and verification is prohibited [1].

In the report “Enterprise Networks in Transition: Taming the Chaos” from oracle, they rank the following challenges for a network with a variety of technologies [2]:

• Control

• Cost

• Quality of Service

• Security

(18)

2 | INTRODUCTION

These challenges of facing new protocols, technologies, delivery models and the need for business to be more flexible, have increased the need of network automation [3].

Network service orchestration is all about pushing configuration out into the net- work automatically without human intervention. The assumption is that the devices are reachable, and that the configuration is valid. In reality there can be any number of issues that causes the orchestration to fail. In many cases manual operations must be done to recover from the error which is very contradicting since the goal of or- chestration is that it should be fully automated.

Network Service Orchestration is still in its infancy and the issue related to faulty updates are true show stopper. There is some indication that feedback mechanism could be used to overcome some/all of the problems and this thesis work aim to build on current insight and if possible, verify that feedback mechanism is a viable method to make NSO useful in practice.

1.2 Goals

The goal with this project is to investigate and evaluate if a Network Service Orches- tration can be integrated with a feedback mechanism to have a closed loop orches- tration solution. This will be accomplished by dividing the project in two parts:

Goals for pre-studies phase:

• A general study about NSO and network automatization to deepen the knowledge in the field and create an understanding to help in the implemen- tations of the solution.

• Determine what kind of tools that are needed to apply the solution to our problems?

• Studies on previous solutions and methods to help in the creation of a system integrated with NSO and feedback mechanism.

Goals for verification phase:

• The results from the pre-study will help to guide a way to verify if the feedback mechanism is a valid option theoretically.

• To investigate a way for the feedback mechanism to automatically detect er- rors from the network and how to notify the Network Service Orchestrator.

• To search a way for the network service orchestration to identify the faulty device and automatically update its configuration.

• In some way verify that a problem has been detected and that actions has been taken to restore the service.

(19)

3 | INTRODUCTION

1.3 Delimitations

The delimitations in this project are:

There are many issues that causes the orchestration to fail where the purpose of this project is to evaluate if a feedback mechanism can solve those problem. This project will not investigate and analyze the root cause of the fail. This thesis will mainly focus on how the feedback mechanism can be used as network assurance and increase the QoS.

(20)

2 | INTRODUCTION

(21)

5 | THEORY AND BACKGROUND

2 Theory and background

This chapter presents the background of the problem and the theoretical framework to demonstrate a solution.

2.1 Network Automation

The main goal of network automation is to simplify the tasks involved in configuring, managing and operating network equipment, network topologies, network services and network connectivity [4].

Cisco [5] writes in their report that automation matters because it accomplishes three things:

1. It frees the team that handles the monotonous processes for example a new user that needs an IP address for a web server to work on a higher level and task, to focus on the customers and stakeholders.

2. Customers get a better and predictable experience because the automated processes are executed in a consistent way and downstream processes don’t have to deal with errors and variability.

3. For an organization automation leads to faster time to market, lower costs and increased productivity. Development, testing and deployment shortens be- cause the automated processes can run on demand, at machine speed, night and day.

2.2 Network Function Virtualization

As a network expands it became necessary to implement new services. In order to implement those services, it is needed to add more hardware like routers and fire- walls in the network and also have more professional experts who can manage the new and old hardware configurations.

NFV is a virtualization technology which helps networks deploy new services without the necessity of adding a physical hardware to the network. It takes functions that traditionally was deployed as hardware like routers, firewalls, load balancers, Intru- sion Detection System IDS/ Intrusion Prevention System IPS, VPN, application fire- walls and instead deploying them as software [3]. The advantage of NFV can be that it helps reducing the investment on a new equipment, the time invest to config it and save some energy. A disadvantage of NFV can be its performance. Studies show that virtualizing can have some unacceptable network latency. [6]

2.3 Software Defined Networking

The development of Software Define Networking (SDN) evolves around the fact that network has been growing fast. It underlines the problem with the configuration of a lot of hardwares like routers and switches at low level. The configuration may in- clude high level policy, the operators need to know everything about the hardware which can get out of hand when the network is growing. The configuration is done manually which can be a problem in a huge network. The operators also need to manage the network careful when it has high traffic.

(22)

6 | THEORY AND BACKGROUND

There are two facts that make the management of network hard. One is the growth of the network and the other is the low-level configuration in each device. SDN came up with a solution that regulate the network from a central controller. The controller is some software which monitors the network. In the SDN network the equipment's became more like a packet delivery device while the configuration and the logic im- plemented in the controller. On one hand this helps the organization by making it easy to implement new services and on the other hand by introducing an idea to cen- tralize a network.

2.4 Orchestration

Orchestration is a term that is used in many different areas. The authors in the paper

“Network Service Orchestration: A survey” [9] describe orchestration as a function to “coordinate the integrated behavior and operations to dynamically adapt and op- timize resources in response to changing context following business objectives and policies”. Orchestration and automation are considered as separate processes, in some context as in web services. But in network service lifecycle the scope of orches- tration also encompasses automation. In networking it refers to the programmatic control of underlying infrastructure including existing networks and technologies, such as SDN and NFV.

2.5 Network Service Orchestration

Network Service Orchestration or NSO, is an application that was developed to help network operators keep up with the demands and challenges of network manage- ment. It is designed to orchestrate a broad range of environments, platforms, multi- ple vendors and technology. The software can be used to help network operators con- figurate and automate multiple network elements.

An orchestrator can be classified according to its functionality [9]:

• Service Orchestration (SO): responsible for interaction with other com- ponents and is responsible for service composition and decomposition.

• Resource Orchestration (RO): is in charge of mapping virtual and/or physical service requests to resources.

• Lifecycle Orchestration (LO): handles the management of workflows, processes and dependencies across service components.

This paper only focuses on service orchestration.

The goal of a service orchestrator is to control a system when it comes to provision, management and re-optimization of network services [10]. Cisco [11] define service orchestration as “a new way of automating the lifecycle management of services in the network, through the programmatic configuration of all physical and virtual ele- ments participating in a service, in a single, end-to-end transaction and the auto- mated monitoring and redeployment of services to maintain customer SLAs”.

(23)

7 | THEORY AND BACKGROUND

The authors of “Network Service Orchestration standardization: A technology sur- vey” identify following properties of a service orchestrator [10]:

• Coordination: A network consists of a wide range of network and computa- tion systems. The infrastructure also includes a set of resources as network bandwidth, CPU and storage. The service orchestrator is responsible for man- agement and configuration of the different technologies and domains.

• Automation: The growing infrastructure provides significant workload for the troubleshooting, configuration and management of network services. The key goal of network service orchestration is to minimize the human interven- tion and provide automation capabilities.

• Resource provision and monitor: another key goal of a service orches- trator is its ability to enable dynamic and flexible resource control.

2.5.1 Challenges with NSO

NSO was designed to improve the instantiating and operating of network services, but there exist some challenges that need to be considered. This section presents the challenges with NSO according to Network Service Orchestration Survey [9].

Interoperability: the network infrastructure is often organized in different do- mains that differs in geographical location, management, administrative limitations and technology. The challenge for the service providers is to create and handle ser- vice over unique and owned interfaces, which makes integration and startup a diffi- cult task to achieve.

Resource and service modulation: Network services must be effectively mod- eled to handle resource requirements, configuration parameters, management poli- cies and performance measurements.

Network Service Lifecycle management: to ensure correct operation of a ser- vice the network service lifecycle is fundamental. It consists of all processes for de- ployment, execution and termination of a network service.

Performance and service assurance: the use of orchestration technologies makes network infrastructures virtualized and software-based. The virtual functions and services create challenges when it comes to performance and service assurance.

Scalability: the orchestration process must be able to handle the growth of net- works and services to support the huge number of connected nodes.

Security: the security must be considered in implementation of NSO. Service de- ployment involves automated processes that creates and deletes network elements without human intervention. A critical security problem that can occur is insertion of malicious code that can perform attacks, intercept valuable information and even destroy a service.

(24)

8 | THEORY AND BACKGROUND

2.5.2 Benefits with NSO

There are a lot of benefits and features of NSO [12]. They are listed in Table 2.5.1.

Table 2.5.1 Benefits and features of NSO

Feature Benefit

Model based • Accelerate additions and change to de-

vice vendors and

• Improves service agility and flexibility

Transactional • No manual fallout

• No stale configuration

Real-time, fine-grained, deep configuration changes (device and services)

• Allows centralized full control of all de- vices and services

Configuration database synchronized with net- work

• Promotes accurate and efficient use of network resources

Full-service lifecycle management (create, modify and decommission)

• Provides flexible dynamic service to end users

• No manual fallout

Multivendor and multiservice support • Use one system, one user interface, and one API to manage the whole network

Comprehensive set of northbound APIs, ren- dered from the models

• Easily integrates without northbound system such as operation support sys- tems (OSSs) and self-service portals

Networkwide unified command-line interface (CLI)

• Provides a power tool for the network engineers

• Builds trust

Extensible through APIs and package manager • Provides DevOps model for orchestra- tion

Smart licensing • Offers simple compliance assurance

with reporting of license entitlements and current use

(25)

9 | THEORY AND BACKGROUND

2.6 Different Network Orchestrations Solutions

There are both commercial and open source solutions to implement network auto- mation. The open source platforms are economical for the short term and allows quick trial [13]. But the success of using an open source platform depends on the community support. In this section the major commercial products will be presented because they are considered mature and robust solutions.

2.6.1 Cisco Network Service Orchestrator Network

Cisco [14] NSO is a model driven platform based on YANG language for automating a network. It provides a single interface for all network devices and services. The solution uses a common modeling language and data store. It fully automates the creation, deletion, and run-time service definitions. NSO accomplish this by using the same common data models and modeling language to describe services and de- vices.

Traditionally operators had to use one tool for the data center network, one for the WAN and one tools to manage firewalls and so on. NSO provides a multi-domain orchestration instead of using different tools for every domain. NSO can span over multiple domains and technologies.

NSO has three components:

1. A model-based interface that provides a full lifecycle service management. It generates a single API into the entire network by using YANG modeling lan- guage.

2. A configuration data store that is fast, highly scalable and available. It can store state of every device and service in the network.

3. Uses network element drivers to mediate access to both Cisco and none-Cisco physical and virtual devices.

2.6.2 Oracle Communications Service and Network Orchestration Solution

The Oracle Communication Network Service Orchestration solution provides an end-to-end orchestrator that can manage both hybrid physical and virtual networks.

The solution provides an open, multi-domain and cross-layer orchestration plat- form. The core design principles for the solution is its modularity, extensibility and re-usability which enables a faster time-to-market, reduce maintenance cost and lev- erage economies of scale [15].

(26)

10 | THEORY AND BACKGROUND

Key business benefits

• Reduces costs related to implementation by offering a rapid modular integra- tion to other systems.

• Provides a unified approach across virtualized and physical networks by eas- ing the transition to NFV and SDN.

• The time-to-market reduces dramatically when introduces to new technolo- gies and design of new services.

• On-demand customer-driven services and complex connectivity services that enhances the customer experience.

• Responds instantly to changing demands with network scaling and dynamic service.

• System and processes simplify trough encapsulation, modularity and reuse across all domains and services.

The solution allows the network operator to make virtualized vs. physical deploy- ment decisions based on policy. It provides an automated orchestration frame- work that integrates manual processes for installing physical network equipment and deploying. The service providers can also plan, build and optimize their net- work because the solution offers network resource management capabilities.

2.6.3 Blue Plant Network Orchestration Software

Blue Planet [16] offers a network orchestration software that reduces the complexity in networks by enabling a more open and programmable network. The solution of- fers and end-to-end service that can automate and orchestrate multiple technologies and vendor domains.

2.7 Netrounds

Netrounds is a software-based test and service assurance platform. It is programma- ble and suitable for both physical, hybrid and virtual networks. Netrounds has a traf- fic generating test. It allows NFV orchestrators to remotely monitor, assure and test their network service. It reduces the need for implementing hardware for a test. It also allows to remotely identify the root cause of the network issue [17]. The Control center is the core component of Netrounds. It provides a user-friendly web GUI where operators can set up and run tests. They can continuously monitor real-time and aggregated result metrics (Netrounds Documentation 2.27.0). The control cen- ter remotely controls devices by using test agents. These test agents can be placed in strategic locations across the network and continuously perform quality monitoring.

They are maintained and remotely updated through Netrounds Control center.

(27)

11 | THEORY AND BACKGROUND

Test agents capabilities include:

• Measurement of internet performance (HTTP, Ping, Speedtest)

• Network performance (UDP, TCP,)

• IPTV and OTT vides, VoIP telephony and SIP, mobile radio, and remote packet inspection.

2.8 Principles of feedback control

The principles of feedback control can be used in many fields and system. It has been a crucial part of almost all engineering system [18]. Recently it has been applied in networking management. Feedback is all about taking care of the output of a system and generating input that can modify the features and behavior of the system itself.

This principle can be used for networking by implementing a controller. The closed loop controller is a feedback control mechanism that can receive a calculated error based on calculations between measured process variables and a target set point [19].

The role of the controller is to minimize the error and try to solve the problem.

2.9 Previous studies

Previous studies on how to build a closed loop orchestrations solution by using a network service orchestration product are very few. There are also very few details publicly available and most of them are marketing material.

In the paper by McNamara [20] a presentation is made about building a closed loop network management. In that work a realistic testbed was used to emulate the net- work. The benefit of using a realistic testbed is the use of interfaces with real control- lers, policies and traffic, so that their effect can be analyzed in a real manner when policies change. The closed loop management solution was built by using a combi- nation of network, controller, analytics and policy. Mininet, a virtual network emu- lator was used to manage the network. The selection of Mininet was based on the well documented and extensible Python API that allows a quick and easy testing of different network scenarios. As the network controller, Floodlight SDN was used to read network configuration and status from the network and to configure modifica- tions on the network. The authors built their own analytic component as a python program to monitor the network and forward insight to the policy component that may require intervention.

(28)

12 | THEORY AND BACKGROUND

(29)

13 | METHODOLOGY

3 Methodology

This chapter describes the methods chosen to achieve the goals. It also gives a brief reasoning behind them. A literature study was performed to determine which tools that could be used to accomplish a Closed-Loop Orchestration solution. Several testbeds were developed based on the chosen methods. Various tests were performed to validate the solution and achieve the goal in section 1.2.

Section 3.1 presents the methods that was used to conduct the pre-study and imple- mentation phase. Section 3.2 presents the test environments that was available to use. Section 3.3 present the network design and topology. Section 3.4 presents the network service orchestrator. Section 3.5 presents the programming language avail- able for controller function. Section 3.6 presents the model that devised as a basis for the prototype. Finally, section 3.7 presents the test and experiments that was con- ducted.

3.1 Working method

In this section a presentation is given about different methods that could be used for this project. The section is divided in two parts, one for methods for pre-study and one for verification.

3.1.1 Methods for pre-study

Methodologies that could be used in this thesis to reach the goal were a literature study, survey and interview.

Using surveys is a good approach to collect information. It is also a good way of col- lecting feedback about some subjects. But it was not chosen to use the survey method because a survey is often used to explore a very known subject or topic. Network service orchestration and automation is in its infancy therefore, the survey is not seen as a suitable method.

The second approach was an interview. Interview with expertise in the subject or people who are affected by the subject is a good way of finding liable information.

But Interviews was not chosen because the difficulties of finding experts in the area.

However, lectures and consulting were given by Dr Stefan Vallin who is a network orchestration and automation expert.

The third approach was to use a literature study. This method is useful to gather information and documentation on works on the field of study. It helps to give a foundation and theory building on the subject. The challenge with this approach is that it can be hard to find a reliable source if the subject is new.

(30)

14 | METHODOLOGY

The method that was relevant to use for this project where literature study. In addi- tion to that, a design and simulation of a simple network architecture was performed.

The literature study was conducted to get an overall understanding of the subject.

Previous work in the field where analyzed and used as an understanding of the pro- ject. The purpose of the network infrastructure design was to achieve the initial goals and test the chosen solution.

3.1.2 Methods for verification

Method that was used for verification was implementation methodology. This method can be used for developing new solutions for different problems. The goal for this thesis was to verify if a feedback mechanism can be used together with Net- work Service Orchestration, therefore the implementation methodology was consid- ered a suitable method for this work.

To analyze and verify the created solution different tests was created. The focus of the tests was to verify the feedback mechanism, but also that NSO could detect and correct the error.

3.2 Test environment

Testing and verifying a network solution on a real network are a challenge. There- fore, it was decided to use a virtual environment. These technologies give a flexible environment for educators, researchers and operators to create functional models of current, planned, or theoretical networks [21]. During the pre-study two network simulation tools were discovered: Cisco Virtual Internet Routing Lab (VIRL) and Mininet.

VIRL is a complex and powerful cisco software. The advantages with VIRL, is that it has many features like graphical topology editor and the possibility to define link parameters. The disadvantages with VIRL is that it is not open source. It also re- quires significant memory resources.

Mininet is an alternative option that is open source and free. The advantages with Mininet is that it has low resource requirements and that topologies can be easily changed by scripting. The disadvantages with Mininet are that it does not support MPLS and VPN tunneling.

The goal with this project was to create several testbeds that support all kinds of packets and protocols. The setback with Mininet for not supporting MPLS and VPN tunneling was the deciding factor for using VIRL.

For this project Virtual Internet Routing Lab (VIRL) was used to create a small net- work to test the solution. In order to run Cisco VIRL an hypervisor was installed separately. For this project VMware Fusion Pro was used as a hypervisor. VMware

(31)

15 | METHODOLOGY

Fusion is a virtual machine that can be used on a Mac computer. It is powerful and can be used to run hundreds of other operating systems like Windows and Linux. For detailed information about the installation and configuration go to appendix A.

3.3 Network Orchestration Solution

In chapter 2 three different Network Service Orchestration solutions where pre- sented: Oracle, Cisco and Blueplanet. They all are major commercial solutions that where valid option for this project. The requirements that had to be meet for this thesis was to use an orchestrator that was:

• Able to support a number of vendors.

• Ease of customization.

• Could be integrated with the virtual environment.

After consideration, Cisco’s solution was chosen as an orchestrator. The first reason was based on the integration of previous choice of virtual environment. During the pre-study it was discovered that Cisco NSO was the most suitable Orchestration So- lution for VIRL. The second reason was that both are Cisco software products and therefore had information on how to connect them. The third reason was that the Cisco solution where well documented and had communities to help understand how it could be used for network automation. Detailed information on installation and configuration can be found in appendix C

3.3.1 Network Element Driver

NSO gives the ability to remotely manage and handle devices. It is also possible to manage multi-vendor devices like routers, switches, firewalls, servers which can be both virtual and physical. The interfaces on the devices can be managed by Network Element drivers that can make device configuration commands. Network Element Driver’s (NED) can communicate with the device by using the native protocol that it supports.

List of native protocols that NSO supports [22]:

• Network Configuration Protocol (NETCONF)

• Representational State Transfer (REST)

• Extensible Markup Language (XML)

• Command line interface (CLI)

• Simple Network Management Protocol (SNMP)

NETCONF, SNMP and CLI was three options that was analyzed to use for commu- nication with the device. A majority of the existing devices do not speak NETCONF and SNMP [22]. The common way to configure devices is through CLI. Therefore, CLI was chosen to manage the router in the VIRL simulation from NSO. For detailed information on how NSO was connected to the router on VIRL see appendix D.

(32)

16 | METHODOLOGY

3.3.2 NSO Services

Configuration can be pushed remotely from NSO to a device. This can be accom- plished by either manually enter commands in the NSO command line or create ser- vice applications that automatically sends pre-defined configurations. The applica- tion transforms service request to corresponding device configuration. For this pro- ject a simple service was created to automatically connect to the device.

3.4 Network design and topology

Different topologies where discussed and tested during the pre-study. The require- ments that had to be meet was that the network topology was simply, easy to test and configure. The main focus of this thesis was to verify the feedback mechanism.

Therefore, it was chosen not to focus on creating a complex topology. The network infrastructure consisted of a single router that was connected to a L2 External Flat tool. This tool is a Layer 2 solution that can be used to provide external reachability to the topology in the VIRL simulation. The IP addresses in the topology are reacha- ble externally by using telnet or SSH. The network where designed in VM Maestro which is a GUI application used with VIRL. VM Maestro provides two perspectives [23]:

• Design Perspective: gives the ability through a palette and property pane to create and editing network topologies.

• Simulation Perspective: consists of panes for managing and working with running simulations. The simulation gives the ability to view live visualiza- tions, stop and restart individual nodes, stop entire simulations and extract configuration changes made during a simulation.

For detailed information on how the network was build go to appendix B.

3.5 Controller function

The choice of programming language for the controller function depends on which language the network orchestration solution support. Cisco NSO solution can sup- port Erlang, Java and Python. For this work Java was chosen based on previous ex- perience.

(33)

17 | METHODOLOGY

3.6 Test and assurance platform

Although NSO is used to automatically manage and configure networks their still can exit issues that needs to be addressed. These issues are many times end-to-end ser- vices on network components that is not configured by NSO. To solve this problem a test and assurance platform can be used. Netrounds is an automated testing and monitoring solution that was discovered can be used together with Cisco NSO. Be- cause of limited information and challenges to connect VIRL with Netrounds it was decided to create a simple Java script. The purpose of this scripts was to monitor the device and send messages to NSO.

3.7 Closed-Loop Orchestration Solution model

The closed loop orchestration model was designed to accomplish a repeating cycle of communication between different systems. The closed loop management was imple- mented with three different systems (table 3.7.1):

Table 3.7.1 System used for the closed-loop orchestration solution

VIRL Network simulation that consisted of a router.

NSO Used to manage and push device configuration to the connected device.

Sensor A java script used to simulate monitor functions. The script consisted of a test that sends a message to NSO when the test failed.

3.8 Test and experiments

To investigate if the feedback mechanism is a viable method to make NSO useful in practice, use cases where specified. There were different use cases discussed before the implementation of the closed-loop orchestration solution. Due to the difficulties experienced during the implementation the use cases was based on what was possi- ble to test. Purpose of the tests was to verify if the goals specified in section 1.2 was accomplished and worked as intended. Two tests where created: one to verify the feedback mechanism and a second to verify that NSO could identify and correct the error.

(34)

18 | METHODOLOGY

3.8.1 Test to verify feedback mechanism

The first test that was used was to verify if a link failure could be detected by the script and if a notification was received by the network orchestrator. The feedback mechanism was used to monitor the GigabitEthernet 0/0 interface of the router. The test consisted of a simple ping function to validate the interface status.

Based on the pre-study of NSO it was decided to use Simple Network Management Protocol (SNMP) to send notification from the script to NSO. SNMP is used for re- mote network Management. It consists of a SNMP agent and SNMP manager. The agent is located at the device and the Manager is placed on device that manages the network [24]. In this case the script is the agent and the NSO the manager.

A failed test trigged a SNMP notification that was sent to NSO. The NSO should then be able to catch the message and generate an alarm to notify that the link is down.

3.8.2 Test to verify error correction

The second test was used to verify that NSO could identify the error and remotely correct it. To test this functionality a configuration on the router was manually changed. The script is then supposed to detect the change and generate a SNMP mes- sage to NSO. When NSO receives the message, an alarm is supposed to be generated.

NSO should then be able to identify the error and push configuration to the remotely router and correct the detected error.

(35)

19 | RESULTS

4 Results

This chapter presents the result of the configuration and implementation of the closed loop orchestration solution. Section 4.1 presents the network infrastructure that was built for this project and configurations. Section 4.2 describes the service that was used to push configurations to the router. Section 4.3 present the feedback mechanism that was designed. Section 4.4 describes the controller that was written in NSO. Section 4.5 presents the overall architecture of the closed loop orchestration solution. Finally, results from the tests are presented in section 4.6.

4.1 Network Topology

The network topology was designed in VM Maestro and consisted of a router con- nected to a L2 External Flat tool (figure 4.1.1).

The network IP addresses and configurations were autogenerated trough VM Mas- tro autoNetkit. The router was accessible externally from the GigabitEthernet 0/0 interface (figure 4.1.2). The management port 172.16.1.x (in this example

172.16.1.68) was used by NSO to communicate and push configurations. Detailed information on how to connect NSO and VIRL can be found in appendix D.

Figure 4.1.1. Network devices to manage and monitor

Figure 4.1.2. Configuration on GigabitEthernet0/0 interface

(36)

20 | RESULTS

4.2 Service Applications

A service application was developed to easily connect the router in the virtual net- work with NSO. This allows remote connectivity without manually entering com- mands in NSO CLI. In order to connect correctly to the router, the service needs a remote name, password and if needed secondary password. These inputs need to be same as the cisco router in the simulation to remotely connect and manage devices (figure 4.2.1).

The service application also needs to specify device name, address and a port to map the authgroup created with the router. (Appendix F).

4.3 Feedback mechanism

The feedback mechanism was accomplished by creating a script to monitor the router in the virtual network. The intention was to detect if the router is reachable by sending continuous ping request. The script keeps monitoring the router. If the ping request fails, the script sends SNMP notification to NSO as shown in figure 4.3.1.

Figure 4.2.1. Authgroup created to connect remotely to device on the virtual network.

Figure 4.3.1. Statement to monitor device and send message.

(37)

21 | RESULTS

The SNMP notification had a trap ID, IP address and port specified. The trap ID symbolized a ping request failure that NSO interpreted as link failure. NSO listen to the specified IP address and port to be able to receive notifications.

When the ping request fails the script creates a SNMP notification and sends it through the port. The notification contains the trap ID and further information for example SNMP version and time. The notification is sent through the IP address and port number as shown in figure 4.3.2

4.4 SNMP handler and Alarm generator

In order for NSO to be able to receive notifications the SNMP notification receiver must be enabled. The operator must configure the IP address and port number to listen for notifications. The primary parameters are shown below in figure 4.41.

Figure 4.3.2. Creation and Sending of SNMP notification

Figure 4.4.1. Primary parameters to enable SNMP notification receiver

(38)

22 | RESULTS

By default, nothing happens with SNMP notifications. For this to be possible a func- tion must be created to listen to traps and do something useful with it. A controller was created in NSO to listen to SNMP notifications and handle the message. The controller interprets the trap OD and generates alarm to notify the operator about problem. Figure 4.4.2 shows the statement that controlled the trap ID and created an alarm text to notify about the link status.

The alarm was created by the controller and had the following parameters (figure 4.4.3):

• Managed device

• Managed object

• Alarm type

• Severity

• Alarm text

• Timestamp

Figure 4.4.2. Statement to control trap ID and create alarm text

Figure 4.4.3. Creation of Alarm

(39)

23 | RESULTS

4.5 Closed loop orchestration solution

Figure 4.5.1 illustrate the closed loop orchestration solution that was designed. The script monitors the link in the router. If the link is unavailable the script creates and sends a message to NSO. The SNMP controller in NSO receives the message and generates an alarm.

Figure 4.5.1. Overall view of closed-loop orchestration solution

(40)

24 | RESULTS

4.6 Tests

In this section the tests are presented in several steps. The first test was created to verify that the script was able to detect a link failure and send a notification to NSO.

The second test was created to verify that NSO could identify the error and correct it remotely.

4.6.1 Test to verify feedback mechanism

The first test is presented in five steps. The interface in the router was manually shut- down. The written script that was used to monitor the link status, detects the link failure and sends a message to NSO. The orchestrator receives the message and gen- erates an alarm.

Step 1. To simulate a link failure the interface was manually shutdown on the router.

Step 2. The script detects the link failure and sends SNMP message.

Figure 4.6.1.1. All interface are up

Figure 4.6.1.2. After manually shutting down GigabitEthernet0/0 the interface is down

Figure 4.6.1.3. Console output displaying sending of ping request and SNMP message.

(41)

25 | RESULTS

Step 3. NSO receives the message and an alarm is displayed on the NSO CLI termi- nal.

Step 4. Detailed information about the alarm can be displayed using the “show alarm alarm-list" command. The alarm in figure 4.6.3 shows number of alarms found, different kind of timestamp, which device the alarm came from, severity of the alarm and the alarm text.

Figure 4.6.1.5. Alarm information display in NSO

4.6.2 Test to verify error correction

When a device is remotely connected to NSO the configuration of the device is saved in a database. Figure 4.6.2.1 shows a short xml output of the information saved in the database.

Figure 4.6.2.1. XML output of interface information saved in the database Figure 4.6.1.4. Alarm displayed on NSO.

(42)

26 | RESULTS

If a change is made in the remotely connected device this action is not detected by NSO. Here is where the feedback mechanism fits in where an external system can be used to detect the change and notify NSO. The previous test in section 4.6.1 pre- sented this action.

The second test that was created, was used to verify if NSO after receiving an alarm was able to identify the error and remotely correct it. To test this functionality the hostname of the router was manually changed. The test will be presented in 6 steps:

Step 1. The hostname of the remotely connected router was manually changed.

Step 2. An alarm is displayed on NSO.

Step 3. NSO is able to detect the error. The compare-config function compares the information in the database with the current configuration and is able to detect a configuration diff.

Figure 4.6.2.3. Alarm generated on NSO.

Figure 4.6.2.4. Output detected error.

Figure 4.6.2.2. Hostname changes on router.

(43)

27 | RESULTS

Step 4. To correct the error a service was created to push the correct configuration back to the router. The figure 4.6.2.5 displays a short part of the service.

Step 5. The service was called to push back the correct hostname to the router. Fig- ure 4.6.2.6 shows a log message that is displayed on the router and the hostname change.

Step 6. To verify if the pushed configuration corrected the error from NSO, a check- sync can was performed. In figure 4.6.2.7 the result is in sync, which means that the service was able to correct the error.

Figure 4.6.2.5. Output of host service code.

Figure 4.6.2.6. Log message displayed on router.

Figure 4.6.2.7. Sync message displayed on NSO.

(44)

28 | RESULTS

(45)

29 | ANALYSIS AND DISCUSSION

5 Analysis and discussion

This chapter will discuss and analyze the results of chapter 4. The discussion will focus on the implementation and integration of the testbed and virtual tools. Section 5.1 consists of discussion regarding the result. Section 5.2 consists of discussion re- garding the testbed. Finally, section 5.3, 5.4 and 5.5 describes the economic, envi- ronmental, social and ethical aspect.

5.1 Discussion of the result

The pre-study took more time than expected because the systems where new and advanced. But it provided enough knowledge to design a simple testbed to verify the goals. Based on the pre-study and previous knowledge a simple network infrastruc- ture was built in the virtual environment. The external system was able to detect a link failure and also managed to send a notification to NSO. NSO was then able to receive the notification and generate an alarm to notify the operator.

The detected error was supposed to generate an alarm and automatically push the correct configuration back to the router. But because of problems with the VIRL en- vironment it was not possible to achieve the automatization. The problem with the VIRL environment was the limited access to reach devices inside the virtual network (further discussion of VIRL difficulties in section 5.2). Each device inside the net- work only had access through one port called the management port. If this port was down there were no external access inside the network, thereby limiting the ability of automatic orchestration from NSO. However, the solution demonstrated the feed- back mechanism where an error could be detected and displayed.

To verify that the Closed-Loop Orchestration solution could be accomplished a sec- ond test was created. The test was used to verify that NSO could be able to identify an error and correct it remotely. On that test the hostname of the router was manu- ally changed. The script was not created to discover that kind of problem. The de- sired solution was to use an existing assurance platform that could detect various errors. Due to problems experienced during the pre-study to integrate an existing platform with VIRL, the script was created as an alternative solution. Therefore, manual actions had to be performed to simulate external reception of a message on NSO. However, putting the two tests together shows that it is possible to accomplish a Closed-Loop Orchestration solution.

5.2 Discussion of the testbed

The creation of the testbed and integration of three different systems was harder than expected. The initial solution that was intended to use consisted of a testbed integrated with NSO, VIRL and Netrounds. The where no previous studies that used the same solution and documentation. During the pre-study a lot of sources stated that VIRL and NSO can be used together. But there were very few documents on how

(46)

30 | ANALYSIS AND DISCUSSION

to connect the two systems together. The documents that was found were few years old. The fact that both systems are continuously updating makes it even harder to use old documentations. Therefore, a lot of time in the beginning of the implemen- tation was spent researching and testing different solutions to make the systems work together.

The VIRL network simulation environment is a powerful tool, but it was extremely hard to connect the simulation to the internet. The initial solution was to build a network that have two offices connected through VPN and used MPLS traffic. But this plan was hard to execute due to the internet connection problem.

The initial solution that was considered, was to use Netrounds as a test and monitor- ing system. In order to use Netrounds, the test agents are supposed to be installed inside the virtual simulation (VIRL). The problem with the internet discussed above made it impossible with the given amount of time for this project to integrate Netrounds test agents with VIRL devices. This problem was solved by writing a script to simulate the functionality of Netrounds in a very small scale. The fact that it was possible to send a SNMP notification from the script to NSO is an indication that Netrounds could be used. The reason is that Netrounds have the possibility to mon- itor a device and send SNMP notification.

5.3 Economical aspect

There are many benefits of using a network service orchestrator, which was de- scribed in chapter 2. One of them is the economical aspect. If NSO is implemented successfully it will produce cost savings because the required staff level shrinks. The cost of errors will also reduce because NSO avoids human errors. It lowers the OPEX and CAPEX by offering complete vendor independence and automation of key pro- cesses which dramatically improves the cost structure. The feedback mechanism which also manage the problem leads to a lower operational cost and improvs oper- ating margins.

5.4 Environmental impacts

There are almost insignificant environmental impacts identified in this thesis. The installation and use of a network service orchestrator and assurance platform doesn't require additional hardware. They are both programmable, software-based automa- tion technologies that can be integrated with current devices. However, one can dis- cuss the environmental impact of growing network infrastructure and new technol- ogies that is continuously being introduced. The physical devices have more or less an environmental impact. But development of virtual machines like cloud-based servers can reduce the negative impact.

(47)

31 | ANALYSIS AND DISCUSSION

5.5 Social and ethical aspect

There are no ethical conditions identified in this thesis. However, one can discuss the social aspect of the solution. Chapter 1 introduces the problem with growing net- works and how the network operators struggle to keep up. By using network auto- mation, the operators no longer have to learn all the complexities of physical and virtual infrastructure. The network service orchestration can configure services pro- grammatically, without manual management. It can in one single transaction ad- dress the fully lifecycle of a service which includes, testing, monitoring and assur- ance. Thus, decrease the load on the operators.

(48)

32 | ANALYSIS AND DISCUSSION

(49)

33 | CONCLUSIONS

6 Conclusions

The fast-growing network infrastructure leads to increasing network traffic. It in turn leads to difficulties in managing the network and specially configuration and troubleshooting. Manual configuration and management of expanding networks can be time and cost consuming. Network Orchestration can be a solution to automati- cally handle the devices in networks and decrease the load of manual configuration.

However, there still exists problems to detect errors in networks.

The essential benefit and contribution of this project is to show how an external sys- tem can be used as a feedback mechanism to make Network orchestration more pow- erful. The feedback mechanism contributes with detecting network errors and notify the Network Orchestrator to generate error management. These insights demon- strate a possibility for a Closed-Loop Orchestration solution of full automation from configuration, management, monitor, error detection, error notification and error handling.

6.1 Future works

This project presents a basic and simple system to detect a link failure. The created system can be expanded to handle different kind of network failure in a very ad- vanced approach. Another suggestion can be to use an existing network orchestra- tion assurance platform for monitor, testing and provide feedback.

Furthermore, it might be desirable to provide automation by using artificial intelli- gence/machine learning as an alternate approach for network failure detection.

(50)

34 | CONCLUSIONS

(51)

35 | REFERENCES

7 References

[1] Danish Rafique, Luis Velasco, “Machine Learning for Network Automation: Over- view, Architecture, and Applications,” Journal of Optical Communications and Net- working 2018, vol. 10, no. 10

[2] Enterprise Networks in Transition: Taming the Chaos, Oracle Communications, September, 2018.

[3] Jason Edelman, Scott S.Lowe and Matt Oswalt, Network Programmability and Automation: Skills for the Next-Generation Network Engineer. Sebastopol, Califor- nia: O’Reilly Media, 2018.

[4] Paul Mihaila, Titus Balan, Radu Curpen, Florin Sandu, “Network Automation and Abstraction using Python Programming methods”, 6th International Conference on Recent Achievements in Mechatronics, Automation, Computer Science and Ro- botics, September 10, 2017

[5] The Business Benefits of Automation and Orchestration, Cisco White Paper, 2016.

[6] The key to a successful automation project: Learnings from 40+ completed net- work automation projects, Data Ductus White Paper, 2018.

[7] Hyojoon Kim, Nick Feamster, “Improving Network Management with Software Defined Networking”, IEEE Communications Magazine, February 2013, vol. 51, pp.114-119

[8] Bo Han, Vijay Gopalakrishnan, Lusheng Ji, Seungjoon Lee, “Network Function Virtualization: Challanges and Opportunities for Innovations”, IEEE Communica- tions Magazine, February 2015, vol.53, pp.90-97

[9] Nathan F. Saraiva de Sousa, Danny A. Lachos Perez, Raphael V.Rosa, Mateus A.

S. Santos, Christian Esteve Rothenberg, “Network Service Orchestration: A Survey”, November 13, 2018.

[10] Charalampos Rotsos, Daniel King, Arsham Farshad, Jamie Bird, Lyndon Faw- cett, Nektarios Gergalas, Matthias Gunkel, Kohei Shiomoto, Aijun Wang, Andreasa Mauthe, Nicholas Race. David Hutchisom, “Network Service Orchestration stand- ardization: A technolgy survey”, Computer Stamndards & Interfaces 2017, vol. 54, pp.203-215

[11] Service Orchestration & Network Virtualization: A Lifecycle View, December 2015, Cisco White Paper

[12] Cisco Network Services Orchestrator Enabled by Tail-f, Cisco Data Sheet

(52)

36 | REFERENCES

[13] A Primer on Network Service Orchestration, E-BOOK, [Online: 2019-03-20], https://www.anutanetworks.com

[14] Cisco Network Services Orchestration (NSO): The Bridge to Automation, Cisco White Paper.

[15] Oracle Communications Service and Network Orchestration Solution, Oracle Data Sheet.

[16] Blue Planet Network Orchestration Software: The Next Leap Forward in Net- work Virtualization

[17] https://www.netrounds.com/company/#story [Online: 2019-03-29]

[18] Monir Hossain, Mahbub Hassan, Harsha R. Sirisena, “Adaptive Resource Man- agement in Multi-Service Mobile Wireless Cellular Networks Using Feedback Con- trol”, IEEE 60th Vehicular Technology Conference 2004, Vol. 6, pp.3984-3988 [19] Panza Gianmarco, Sara Grulli, “An IP cross-layer scheduler with closed-loop control for QoS provisioning in NGNs,” Wireless Network, 2015, vol. 21, pp.1985- 1997

[20] Joseph McNamara, John Keeney, Liam Fallon, Sven van der Meer, Enda Fallon,

“A Testbed For Policy Driven Closed Loop Network managament”, 2018.

[21] Joel Obstfeld, Simon Knight, Ed Kern, Qiang Sheng Wang, Tom Bryan, Dam Bourque, “VIRL: The Virtual Internet Routing Lab”, Computer Communication Re- view, 25 February 2015, vol. 44, pp.557-578

[22] NSO 4.7 NED Development, Cisco NSO documentation

[23] Introduction to VM Maestro, http://virl.cisco.com/intro.vmm.php, [Online:

2019-04-16]

[24] Jiri Hosek, Karol Molnar, Lukas Rucka, Milan Bartl, “SNMP-based acquisition system for DiffServ parameters”, Telecommunication Systems, 2013, Vol.52(3), pp.1595-1604.

(53)

37 | APPENDIX A – INSTALLATION OF VMWARE FUSION, VIRL AND VM MAESTRO

Appendix A – Installation of VMware Fusion, VIRL and VM Maestro This section will present the download, installation and configuration of Cisco VIRL and VMware Fusion. For this project a MacBook Pro with macOS High Sierra version 10.13.6 was used. The instruction that follows may vary if using another system like Windows and Linux.

In order to run Cisco VIRL, you must verify that your machine meets the following minimum hardware requirements:

• The host system must be able to access the internet.

• A minimum of 8GB of RAM and four core CPU must be allocated to the VIRL virtual machine. This is required for better performance and functionality but also allows larger simulations.

• Intel VT-x / EPT or AMD-V / RVI virtualization extensions present and ena- bled in the BIOS.

• 70GB of free disk space for installation.

In order to run Cisco VIRL, you must have installed one of the following supported Hypervisor:

• VMware Fusion Pro v5.02 or later (including v6.x or v7.x).

• VMware Workstation for Windows or Linux v8.04 or later (including v9 ->

v12)

• VMware Player v5.02 or later (including v6.x and 7x).

• VMware Workstation Player 12 or later.

• VMware ESXi 5.1/5.5/6.x using vSphere Client: ESXi 5.1U2 (Build 1483097), ESXi 5.5U1 (Build 1623387), ESXi 6.0 (Build 2494585).

For this project VMware Fusion Pro version 11.0.3 was used as hypervisor. The VMware Fusion disk image was obtained from the VMware Fusion Web site. The hypervisor can only be used in 30 days for free. If you are planning to use it for more than 30 days you must purchase it for 176,95€.

(54)

38 | APPENDIX A – INSTALLATION OF VMWARE FUSION, VIRL AND VM MAESTRO

A1. Install VMware Fusion Pro

1. Download the VMware Fusion disk from the VMware Fusion Web site (https://www.vmware.com/products/fusion/fusion-evaluation.html)

2. The VMware fusion disk image is saved to your default download directory.

3. Double-click the VMware Fusion .dmg file to mount it.

4. Drag the VMware Fusion icon into the Applications folder icon.

When staring VMWare Fusion, the Virtual Machine Library window appears. This window makes it able to work with virtual machines.

A.2 Install and configure VIRL

In order to use Cisco VIRL you must purchase a license from the the Cisco Learning Network store. As of today, there exists no free version of VIRL and the VIRL license can only be purchased for $199. The license are only valid for 365 days.

Once you have the license you need to create an account on The Cisco Learning Net- work store do download the VIRL OVA file. Once you are logged in you can display all your orders and download the Personal Edition 1.5x for VIRL. For this thesis VIRL version 1.5.145 was used.

Once you have downloaded the VIRL OVA use the following steps to deploy VIRL OVA:

1. Start VMware Fusion Pro.

2. Select File > Import.

3. Locate VIRL on your local machine.

(55)

39 | APPENDIX A – INSTALLATION OF VMWARE FUSION, VIRL AND VM MAESTRO

4. Import the ova file and follow the prompts.

5. Wait for the ova to be imported into VMware Fusion Pro.

6. Once the ova file is imported you can locate your VIRL virtual machine on the VMware Fusion library window (see figure A.1).

The VIRL virtual machine requires a minimum of 8GB of RAM. If your virtual ma- chine supports it you can increase the amount of RAM used by cisco VIRL (see A.2).

Once this is completed you can power on the virtual machine. VMware will boot up the virtual machine and you have to wait until this is completed.

For the first time when you start the VIRL virtual machine you have to follow man- datory one-time procedures which will take approximately 5 to 10 minutes (see fig- ure A.3).

References

Related documents

Stöden omfattar statliga lån och kreditgarantier; anstånd med skatter och avgifter; tillfälligt sänkta arbetsgivaravgifter under pandemins första fas; ökat statligt ansvar

46 Konkreta exempel skulle kunna vara främjandeinsatser för affärsänglar/affärsängelnätverk, skapa arenor där aktörer från utbuds- och efterfrågesidan kan mötas eller

För att uppskatta den totala effekten av reformerna måste dock hänsyn tas till såväl samt- liga priseffekter som sammansättningseffekter, till följd av ökad försäljningsandel

The increasing availability of data and attention to services has increased the understanding of the contribution of services to innovation and productivity in

Generella styrmedel kan ha varit mindre verksamma än man har trott De generella styrmedlen, till skillnad från de specifika styrmedlen, har kommit att användas i större

Figure 3: Plot of the grade of "premium" for Parking brake, Information and Seat belt chimes.. peared to be important also in the four chimes with

Industrial Emissions Directive, supplemented by horizontal legislation (e.g., Framework Directives on Waste and Water, Emissions Trading System, etc) and guidance on operating

The EU exports of waste abroad have negative environmental and public health consequences in the countries of destination, while resources for the circular economy.. domestically