See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/345952324

Engineering Internship report: Implementation of an SD-WAN architecture

on the Tunisie Telecom network

Technical Report · July 2019

DOI: 10.13140/RG.2.2.28146.32965

CITATIONS READS

0 7,136

1 author:

Ouerghi Firas
École Nationale d'Ingénieurs de Tunis
5 PUBLICATIONS 2 CITATIONS

SEE PROFILE

All content following this page was uploaded by Ouerghi Firas on 16 November 2020.

The user has requested enhancement of the downloaded file.

 National Engineering School of Tunis

ICT Department

Engineering Internship report

developed by :

Ouerghi Firas
Ben Amor Elyes
Antabli Alaa

Implementation of an SD-WAN architecture on

the Tunisie Telecom network

Host Company :

Tunisie Telecom

supervised by :

Mr.Rfaa Houerbi
Mrs.Awatef Mdhaffer
Mr.Mohammed Mustapha Ayed

ACADEMIC YEAR : 2019/2020

Acknowledgements

I would like to extend my sincere thanks to all the team members of tunisie telecom for
their support in this internship.
I am greatly indebted to Mr. Rafaa HOUERBI for his constant supervision and guidance
as well as for providing me with the necessary information in regards to the project and
also for his continuous support in completing the internship.
I would also like to extend my deepest gratitude to Mr. Mohamed Mustapha AYED,
Mrs. Soumaya MEHERZI and Mrs.Awatef MDHAFEER for their kind cooperation which
helped me in the completion of my second year internship. My appreciation goes also
Mrs.Arwa CHAIBI and Ms.Fatma GHANDOUR who have willingly helped me out with
their abilities.

1
abstract

Based on the SDN (Software Defined Network) concept, which consists of separating the
control plan and the data plane in the network nodes, SD-WAN provides an essential
solution to the problem of managing WAN wide area network connectivity.
This involves putting in place an application allowing the supervision and management of
the network according to a hybrid architecture (MPLS, high-bandwith Internet, 4G,...).
Thanks to the programmability of the nodes, this application makes it possible to deter-
mine in real time an optimal routing of the application traffic according to the constraints
required by it (QOS, security, etc...) and the network conditions (bandwith, congestion,
etc...).
This allows a better distribution of the load and a reduction of the operating costs. The
SD-WAN solution can be combined with Network Function Virtualization (NFV) techno-
logy to provide new network services.
This solution allows virtual services to be inserted in the cloud and on-site through more
flexible automation of business processes.
A number of suppliers already offer SD-WAN solutions, such as Cisco, Huawei, Juniper,
IBM, Vmware.
The objective of this internship is to test the solutions offered by several suppliers in
a virtual environment. Key Words : SDN-WAN, SDN, NFV, Openflow, ODL, CISCO
VIPTELA, CONTRAIL.

2
Table des matières

List of Figures 5

List of tables 7

List of acronyms 8

General Introduction 9

1 Entreprise presentation 11

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1 Presentation of Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Organization chart of Tunisie Telecom . . . . . . . . . . . . . . . . . . . . 12

1.3 Internship objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Network Function Virtualisation 13

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 NFV Architectural Framework . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Relationship with Software Defined Networks (SDN) . . . . . . . . . . . . 15

2.4 Fields of Application and Use Cases . . . . . . . . . . . . . . . . . . . . . . 16

3
TABLE DES MATIÈRES 4

2.5 Benefits of Network Functions Virtualisation . . . . . . . . . . . . . . . . . 17

2.6 Challenges for Network Functions Virtualisation . . . . . . . . . . . . . . . 18

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Software Defined Networks 20

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Definition : What is SDN ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Software defined networking background . . . . . . . . . . . . . . . . . . . 20

3.3 Traditional Network Approach Vs SDN Approach . . . . . . . . . . . . . . 22

3.4 Software Defined Networking Architecture . . . . . . . . . . . . . . . . . . 23

3.5 OpenFlow Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.1 Mechanism of operation of OF-protocol . . . . . . . . . . . . . . . . 25

3.5.1.1 OpenFLow Messages . . . . . . . . . . . . . . . . . . . . . 27

3.5.1.2 Flow Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.1.3 Traffic matching . . . . . . . . . . . . . . . . . . . . . . . 31

3.6 SDN use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Software Defined WAN 34

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 SD-WAN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 SD-WAN Architecture - Edge Appliances . . . . . . . . . . . . . . . 36

4.2.2 SD-WAN Architecture - Cloud-Based SD-WAN . . . . . . . . . . . 36

4.3 SD-WAN Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

TABLE DES MATIÈRES 5

4.4 Traditional WAN VS SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.0.1 Traditional WAN . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.0.2 SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Benefits of SD-WAN for Enterprises . . . . . . . . . . . . . . . . . . . . . . 40

4.6 Case of study : Juniper solution . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.1 Juniper Contrail overview . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.2 Contrail Solution Components . . . . . . . . . . . . . . . . . . . . . 41

4.6.3 Use Cases and deployment . . . . . . . . . . . . . . . . . . . . . . . 42

4.6.3.1 Topology to deploy . . . . . . . . . . . . . . . . . . . . . 42

4.6.3.2 ZTP : Zero touch provisioning . . . . . . . . . . . . . . . . 43

4.6.3.3 Network failover . . . . . . . . . . . . . . . . . . . . . . . 45

4.6.3.4 Application firewall Policies . . . . . . . . . . . . . . . . . 46

4.6.3.5 Site to site ipsec vpn . . . . . . . . . . . . . . . . . . . . . 48

4.6.3.6 SSL proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6.3.7 Dynamic path selection . . . . . . . . . . . . . . . . . . . 53

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

General conclusion 55

Bibliographie 56

Annexes 57

A 58
Liste des figures

1.1 Organization chart of Tunisie Telecom[1] . . . . . . . . . . . . . . . . 12

2.1 NFV architecture[3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Network Functions Virtualisation Relationship with SDN[4] . . . 16

2.3 Benefits of Network Functions Virtualisation[5] . . . . . . . . . . . . 18

3.1 SDN Vs leagacy Network Architecture[6] . . . . . . . . . . . . . . . 22

3.2 SDN Architecture[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 OpenFlow communication[8] . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Reactive Mode [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5 Proactive Mode [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6 Flow Table [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 Flowchart detailing packet flow through an OpenFlow switch [12] 31

3.8 Packet flow through the processing pipeline [13] . . . . . . . . . . . 32

4.1 Simple SD-WAN Architecture [14] . . . . . . . . . . . . . . . . . . . 35

4.2 Detailed SD-WAN Architecture [15] . . . . . . . . . . . . . . . . . . 35

4.3 Traditional WAN [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 SD-WAN [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Juniper SD-WAN enabled devices[18] . . . . . . . . . . . . . . . . . 42

6
LISTE DES FIGURES 7

4.6 Test topology[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.7 ZTP Template creation[20] . . . . . . . . . . . . . . . . . . . . . . . . 44

4.8 ZTP config push and test results [21] . . . . . . . . . . . . . . . . . 44

4.9 Failover scenario1[22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.10 Failover scenario2[23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.11 Create and Configure a firewall policy[24] . . . . . . . . . . . . . . . 47

4.12 Policy pushed to the SRX/VSRX[25] . . . . . . . . . . . . . . . . . 47

4.13 Firewall Policy result[26] . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.14 firewall policy to allow hosts of site A to ping hosts of site B[27] 49

4.15 IPsec tunnel creation and successful ping[28] . . . . . . . . . . . . . 49

4.16 Import Certificate[29] . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.17 SSL Proxy Profile Created[30] . . . . . . . . . . . . . . . . . . . . . . 51

4.18 SSL Proxy Policy Created[31] . . . . . . . . . . . . . . . . . . . . . . 51

4.19 Load the certificate[32] . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.20 Test result[33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.21 SLA profile [34] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.22 SD-WAN Policy [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.23 Test results [36] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Liste des tableaux

4.1 Legacy WAN VS SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8
List of acronyms

TT : Tunisie Telecom.
WAN : Wide Area Network.
SDN : Software Defined Networking.
SD-WAN : Software Defined Networking-Wide Area Network.
NFV : Network Function Virtualization.
NFVI : Network Functions Virtualization Infrastructure.
VNF : Virtual Network Function.
NFV MANO : NFV Management and Orchestration.
M2M : Machine-to-Machine communications.
SLA monitoring : service-level agreement monitoring.
VPN : Virtual Private Network.
OVSDB : Open vSwitch Database.
ONF : Open Networking Foundation.
TLS : Transport Layer Security.
ZTP : Zero Touch Provisioning.
SSL : Socket Security Layer.

9
General Introduction

Enterprise networks are the last frontiers to be undergoing the rapid transformation initia-
ted by computer virtualization and the adoption of cloud delivery models. Virtualization
and cloud technologies brought new levels of IT flexibility, efficiency and cost benefits while
leaving the underlying networks unchanged. As mobile devices and new applications en-
tered enterprise workloads, networks struggled to meet the demands placed upon them.

Network bottlenecks arise from the traditional architecture that is based on hardware-
centric, proprietary and outdated technologies. Software Defined Networking (SDN) pro-
mises the solution to many of these problems with a software based solution. The sophis-
ticated software platform enables a transition from the proprietary hardware devices to
software defined networks that are programmable, agile and decoupled to keep pace with
the innovations in enterprise IT.

Software-Defined WAN (SD-WAN) is the extension of SDN that is transforming the en-
terprise branch office. With SD-WAN, no longer are the advantages of SDN limited to
the data center. SD-WAN abstracts network hardware into a control plane and multiple
data planes that can be used with cloud based management and automation to simplify
the delivery of services to the branch office. This work is all done with the manage-ability,
performance and reliability assurances that enterprises expect.

SD-WAN is in the spotlight and is gaining popularity in the IT world. With any new
disruptive technology and many adjacent solution providers go into a frenzy to gain a
piece of the market. This activity is part of the IT hype cycle. However, vendors who
provide solutions with real, measurable benefits often emerge as industry leaders and go
on to define the technology space.

10
Chapitre 1

Entreprise presentation

Introduction

My internship took place within the company Tunisie Telecom. In this part, we will
introduce the host company and discuss this internship objectives.

1.1 Presentation of Tunisie Telecom

The National Telecommunications Office is created following the promulgation of Law

number 36 of 17 April 1995. The Office subsequently changed its legal status pursuant to
Decree number 30 of 5 April 2004, to become a public limited company called ”Tunisie
Telecom”.
This company counts among the largest telecommunications operators in the region. Mar-
ket leader of telecommunications in Tunisia, the incumbent, global, integrated operator is
present on the mobile and the Internet. It is aimed at the general public as well as third
party companies and operators.
With nearly 7 million subscribers, the operator today embodies the values of proximity,
accessibility and universality by always striving for a better quality of service and cus-
tomer satisfaction through its 84 sales agencies, its numerous call centers and its 13,000
points of sale. It employs more than 8,000 agents, where 42 of whom are executives.

11
1.2 Organization chart of Tunisie Telecom 12

1.2 Organization chart of Tunisie Telecom

Figure 1.1 – Organization chart of Tunisie Telecom[1]

1.3 Internship objectives

As part of its policy that aims to follow technological progress and to improve its services,
TT is deploying and testing several SD-WAN architecture from different vendors (juniper
,cisco,....). The main reason of my internship is to test and deploy the proposed solutions
on the TT network infrastructure in order to distinguish the most suitable one.

Conclusion

In this chapter, we began with a presentation of the host company in which i described
our objectives and missions during this internship. In the next chapter, we will dive into
more sophisticated topics like Network function virtualization and sdn.
Chapitre 2

Network Function Virtualisation

Introduction

This chapter attempts to answer an important question about How do we virtualize a

network. Before attempting an answer we have to look through some basic information
such as What exactly is network virtualization, and how does it relate to the virtualiza-
tion, also How does network virtualization fit into the grand scheme of network functions
virtualization (NFV) and software-defined networking (SDN).

2.1 Definition

Network functions virtualization (NFV) is proposed aiming to virtualize an entire class

of network component functions using virtualization technologies. The objective is to de-
couple the network functions from the network equipment. A network function is now a
virtual instance of customized software program called a virtual network function (VNF).
This object can be created on demand, launched into operation wherever needed without
the need for installation of new equipment (on any virtual or physical servers at data
centers, gateways, routers). It can be moved at will and terminated when its function
is no longer needed [2]. The NFV enables network functions to be executed as software
instances in a virtual machine (VM) on a single or multiple hosts instead of customized
hardware equipment.

13
2.2 NFV Architectural Framework 14

2.2 NFV Architectural Framework

In a traditional enterprise network, most network-related operations are carried out by

proprietary, purpose-built hardware devices that each perform a specific task, such as
routing network traffic or balancing data loads. Although this approach is widely imple-
mented and the technology is mature, it can be costly, inefficient and inflexible, especially
with today’s dynamic workloads and massive sets of heterogeneous data.
NFV architecture delivers virtualized services, which can replace costly proprietary de-
vices and address many of their limitations.[1]
The vision for NFV also includes containers to host networking operations, but the focus
has primarily been on VMs. NFV architecture is built on three components : virtual net-
work functions (VNFs), the NFV infrastructure (NFVI) and an administrative framework
that handles management, automation and network orchestration (MANO).[2]

Figure 2.1 – NFV architecture[3]

— The NFVI (Network Functions Virtualization Infrastructure) :NFVI is the envi-

ronment in which VNFs run. This includes Physical resources, virtual resources
and virtualization layer, described below.
2.3 Relationship with Software Defined Networks (SDN) 15

— VNF (Virtual Network Function) :the software equivalent of a network function,

able of run over the NFVI. It can be complement with an element Management
System (EMS) which interacts and manages an individual VNF and its distinctive
features.
— The NFV Management and Orchestration [3] :NFV MANO (network functions
virtualization management and orchestration), also called MANO, is an archi-
tectural framework for managing and orchestrating virtualized network functions
(VNFs) and other software components. NFV MANO has three main functional
blocks : NFV orchestrators, VNF managers and virtualized infrastructure mana-
gers (VIMs). Together, these blocks are responsible for deploying and connecting
functions and services when they are needed throughout the network.

1. NFV orchestrators consist of two layers – service orchestration and resource

orchestration – which control the integration of new network services and VNFs
into a virtual framework. NFV orchestrators also validate and authorize NFV
infrastructure (NFVI) resource requests.

2. VNF managers oversee the lifecycle of VNF instances.

3. VIMs control and manage NFV infrastructure, which encompasses compute,

storage, network resources.

2.3 Relationship with Software Defined Networks (SDN)

Network Functions Virtualisation is highly complementary to Software Defined Networ-

king (SDN). Network Functions Virtualisation can be implemented without a SDN being
required, although the two concepts and solutions can be combined and potentially grea-
ter value accrued.
Network Functions Virtualisation is able to support SDN by providing the infrastructure
upon which the SDN software can be run. Furthermore, Network Functions Virtualisation
aligns closely with the SDN objectives to use commodity servers and switches as shown
in Figure 2.3.
2.4 Fields of Application and Use Cases 16

Figure 2.2 – Network Functions Virtualisation Relationship with SDN[4]

2.4 Fields of Application and Use Cases

Network Functions Virtualisation is applicable to any data plane packet processing and
control plane function in mobile and fixed networks, for example :
— Switching elements : routers.
— Tunnelling gateway elements : IPSec/SSL VPN gateways.
— Traffic analysis : DPI, QoE measurement.
— Software-Defined Branch and SD-WAN.
— Service Assurance, SLA monitoring, Test and Diagnostics.
— Security functions : Firewalls, virus scanners.
To highlight the use of NFV, we can find below some examples of network function virtua-
lization use cases that demonstrate how NFV is being used to address a range of challenges
as well as provide enhanced solutions to these and other networking hurdles(obstacles) in
order to enhance services and reduce outgoings.[4]

— Network Virtualization : In order to optimize the network services, consumers look

to network virtualization to decouple their network functions such as DNS, caching,
2.5 Benefits of Network Functions Virtualisation 17

IDS, and firewalling from the proprietary hardware that was, until recently, the
dominant solutions, so as to enable them to run on software instead.
— Mobile Edge Computing : Using network function virtualization allows edge devices
to perform computational services and provide network functions by generating and
utilizing either a single or multiple virtual machines (VM).
Network Functions Virtualisation in mobile networks can also be used to create
core network instances optimized for specific services, e.g. for Machine-to-Machine
communications (M2M).
— Video Analytics : Enterprises have been turning to NFV and SDN architectures in
order to reduce network resource utilization and improve latency.This could, when
combined with using video analytics at the network edge, reduce bandwidth use by
up to 80% according to some researches made by some experts in the IT industry.
— Security : Many security vendors are already offering virtual firewalls to protect
VMs, however, in reality, firewalls are just one of nearly every security device or
component that will eventually be virtualized using network functions virtualiza-
tion as well as software-defined networking.

2.5 Benefits of Network Functions Virtualisation

We believe the application of Network Functions Virtualisation brings many benefits to

network operators, contributing to a dramatic change in the telecommunications industry
landscape.
Here are some of the benefits that are being approved by many companies like Cisco,
Juniper,Nokia and many others.

— Reduce equipment costs and reduce power consumption.

— Services can be rapidly scaled up/down as required. In addition, service velocity is
improved by provisioning remotely in software without any site visits required to
install new hardware.
— Optimizing network configuration and/or topology in near real time based on the
actual traffic/mobility patterns and service demand.
— Supporting multi-tenancy that allows network operators to provide connectivity
for multiple users, applications or internal systems or other network operators.
2.6 Challenges for Network Functions Virtualisation 18

— Reduce energy consumption by exploiting power management features in standard

servers and storage, as well as workload consolidation and location optimisation.

Figure 2.3 – Benefits of Network Functions Virtualisation[5]

2.6 Challenges for Network Functions Virtualisation

There are a number of challenges to implement Network Functions Virtualisation.The

most known challenges are described below[5].
— Automation :Network Functions Virtualisation will only scale if all of the functions
can be automated. Automation of process is paramount to success.
— Network Stability : Ensuring stability of the network is not impacted when ma-
naging and orchestrating a large number of virtual appliances between different
hardware vendors and hypervisors. This is particularly important when, virtual
functions are relocated, or during re-configuration events (e.g. due to hardware
and software failures) or due to cyber-attack.
— Migration and co-existence of legacy and compatibility with existing platforms :Im-
plementations of Network Functions Virtualisation must co-exist with network ope-
rators’ legacy network equipment and be compatible with their existing Element
Management Systems. Network Functions Virtualisation must work in a hybrid
network composed of classical physical network appliances and virtual network
appliances.
2.6 Challenges for Network Functions Virtualisation 19

Conclusion

Network Functions Virtualisation is already occurring. In a few years, we can expect the
communications industry to look and feel similar to the IT industry. There will be a wider
range of business models more suited to a software industry. Operations complexity will
be abstracted away by more automation and self-provisioning will be more common.
The next chapter will be dedicated to discuss the SDN technology including its background
and the grounds on which this technology rests.
Chapitre 3

Software Defined Networks

Introduction

In this chapter we are going to focus on the network aspects of software-defined-network

while giving sufficient coverage on the SDN architecture,the mechanism of the openflow
protocol and how it works.At the end we are going to mention some SDN use cases.

3.1 Definition : What is SDN ?

Software-Defined Networking (SDN) is an emerging architecture that is dynamic, mana-

geable, cost-effective, and adaptable, making it ideal for the high-bandwidth, dynamic
nature of today’s applications. This architecture decouples the network control and for-
warding functions enabling them to become directly programmable and the underlying
infrastructure to be abstracted for applications and network services. [6]

3.2 Software defined networking background

The huge growth in mobile devices and the data they use along with server virtualisation
and the use of cloud services as well as many other changes have caused many in the

20
3.2 Software defined networking background 21

telecommunications industry to reexamine the network architectures that have been used
for many years[7].

Many of these networks are tiered and have a very hierarchical structure with many Ether-
net switches arranged in a tree structure.
This form of static telecommunications network design topology made much sense when
client serving computing was the main method of working. However this form of net-
work architecture is ill suited to the dynamic computing and storage needs that have
evolved around new computer usage scenarios with data centres, carrier environment and
campuses.

Today, the traffic patterns in data networks have significantly changed. Often today’s
applications access a variety of different sources and servers and this creates a flurry of
activity of data requests from a variety of different sources.

In addition to this, users are changing the way they work and this also has a major impact
on the data network traffic. Often users will want to access data from a variety of physical
locations, not just accessing the data from the office. As data requests often travel via a
VPN, and from different areas of the globe, this is a far cry from the requests that some
years ago tended to be from one machine to another in defined locations.

Cloud services are yet another driver for the use of software defined networking. Enter-
prises often need to access IT resources on demand. They do not want to have their own
fixed set of assets they need to increases to meet the demand peaks. Instead it makes
sense to have a common cloud resource provided by a third party that can act to average
out the peaks and troughs of a number of different enterprises and still being able to pro-
vide additional resource as required. As might be imagined, this results in more data flow
across the networks in a variety of different directions. To meet these needs and others, a
far more flexible and agile data network architecture is needed.
3.3 Traditional Network Approach Vs SDN Approach 22

3.3 Traditional Network Approach Vs SDN Approach

A traditional network architecture is composed of three main components :

the Data Plane, the Control Plane, and the Management Plane.

— The Control Plane :

It is the architectural network component defining the traffic routing and the net-
work topology.
— The Data Plane :
refers to the architecture layer which deals with the traffic physically based on the
configurations given from the Control Plane.
— The Management Plane :
handles the wider network configuration and con- trol,and is responsible for the
management of processes across all of the network stack’s layers.

Figure 3.1 – SDN Vs leagacy Network Architecture[6]

In the classic network architecture, the Data plane and the Control plane are merged and
any modification to the system depends on the network’s physical devices, protocols, and
the software they support.
3.4 Software Defined Networking Architecture 23

The changes can be done to the overall system are limited as the network equipment
restrain logical network traffic flows. Machines function without support and present limi-
ted awareness towards the extended network. On the other hand, and as shown in Figure
3.1, SDN decouples the two above-mentioned planes. It integrates the network logic at
the controller level. A controller detached of the two Planes strategically centralizes the
network’s logic in a way that enables users to choose which programmable characteristics
can be moved from the physical devices onto the controller.
The SDN’s dynamic, flexible and scalable infrastructure simplifies operations and grants
the ability to try new business routes that are otherwise unable to explore.

3.4 Software Defined Networking Architecture

The SDN architecture is based on the idea of the separation between control and data
planes and it is composed of major layers as mentioned in Figure 3.2[8].

Figure 3.2 – SDN Architecture[7]

— Application layer :
It is an open area to develop as much innovative application as possible by levera-
ging all the network information about network topology, network state, network
statistics, etc. There can be several types of applications which can be developed
3.4 Software Defined Networking Architecture 24

like those related to network automation, network configuration and management,

network monitoring, network troubleshooting, network policies and security. Such
SDN applications can provide various end-to-end solutions for real world enterprise
and data centre networks.
— Control layer :
It is the land of control plane where intelligent logic in SDN controllers would reside
to control network infrastructure.
This is the area where every network vendor is working to come up with their own
controller and framework products. Here in this layer, a lot of business logic is being
written in controller to fetch and maintain different types of network information,
state details, topology details, statistics details, and more.
Since SDN controller is for managing networks, so it must have control logic for
real world network use-cases like switching, routing, L2 VPN, L3 VPN, firewall
security rules, DNS, DHCP, and clustering.
Several networking vendors and even open source communities are working on the
implementation of these use-cases in their SDN controllers. Once they get imple-
mented, these services expose their APIs (typically REST based) to the upper layer
(Application layer), something which makes life easy for network administrators
who then use apps on top of SDN controllers to configure, manage and monitor un-
derlying network. Control layer lies in middle and it exposes two types of interfaces
Northbound and Southbound.
— Infrastructure layer
It is composed of various networking equipment which forms underlying network
to forward network traffic. It could be a set of network switches and routers in the
data centre. This layer would be the physical one over which network virtualization
would be laid down through the control layer (where SDN controllers would sit and
manage underlying physical network).
— Northbound APIs :
It represents one of the key abstraction of the SDN ecosystem, since it is the
interface that will be used by administrators and operators to specify their control
applications.
Indeed, the main purpose of the interface is to avoid the details of the physical
3.5 OpenFlow Protocol 25

infrastructure as well as those of the implementation of the SDN controller.

thus the Northbound APIs should allow administrators to specify applications that
describe the desired network behavior and not how it is implemented.
— Southbound APIs :
represents the interface that connects each switch from the data plan to the SDN
controller.
Through this interface, the controller configures and manages all the switches under
its authority. Currently, it exists several types of Southbound API such as Open
vSwitch Database (OVSDB) and Openflow.

3.5 OpenFlow Protocol

OpenFlow (OF) is considered the most commonly used southbound API in SDN, which
is being continuously developed and standardized by open networking foundation (ONF).
OF provides an abstraction layer that enables the SDN controller to securely communicate
with OF-enabled forwarding elements[9].

3.5.1 Mechanism of operation of OF-protocol

To ensure the exchange of information between switches and controller, the Openflow
protocol established an encrypted TLS communication between network nodes and the
controller.
3.5 OpenFlow Protocol 26

Figure 3.3 – OpenFlow communication[8]

This channel enables encrypted messages to be transmitted and the authentication of the
switchs towards the controller. As shown in Figure 3.3.

Once this TCP session is set on port 6653/6633. The controller and switch begin negotia-
ting the protocol version, then update and exchange flow tables.

OpenFlow enabled devices can operate in two different modes

— Reactive mode :
This mode consists of filling the flow table of the OF devices as and when sending
a packet from a source to its destination.
For example When ”PC 1” sends a packet to the Switch, the latter queries its
controller on the destination path, the response or what is called the action will be
communicated to the switch through the established secure channel. This will be
done at each jump where the destination is not yet configured in the flow table of
the device. In this mode it is imperative that the controller and switches are near
one of the others to decrease latency.
3.5 OpenFlow Protocol 27

Figure 3.4 – Reactive Mode [9]

— Proactive mode :
This mode consists of preconfiguring all switches before the source emits its mes-
sage. This can give us some flexibility on the distance between the controller and
the switches.

Figure 3.5 – Proactive Mode [10]

3.5.1.1 OpenFLow Messages

The OpenFlow protocol defines three message types, each of those types is composed of
multiple sub-types as explained below[10] :

— Controller-to-switch :
Controller-to-switch messages are initiated by the controller and used to directly
3.5 OpenFlow Protocol 28

manage or inspect the state of the switch. This type of messages may or may not
require a response from the switch and are categorized in the following subtypes.

1. Features :
Upon establishment of the TLS session, the controller sends a feature request
message to the switch. The switch must reply with a features reply message
that specifies the features and capabilities that are supported by the switch.

2. Configuration :
The controller is able to set and query configuration parameters in the switch.
The switch only responds to a query from the controller.

3. Modify-State : These messages are sent by the controller to manage the state
of the switches. They are used to add/delete or modify flow table entries or to
set switch port priorities.

4. Read-State :
These messages collect statistics from the switch flow tables, ports, and the
individual flow entries.

5. Send-Packet :
These are used by the controller to send packets out of a specified port on the
switch.

6. Barrier :
Barrier request/reply messages are used by the controller to ensure message
dependencies have been met or to receive notifications for completed operations.

— Symmetric messages :
Symmetric messages are initiated by either the switch or the controller and sent
without solicitation. There are three symmetric message subtypes in OpenFlow
protocol as follows :

1. Hello :
Hello messages are exchanged between the switch and controller upon connec-
tion setup.

2. Echo :
Echo request/reply messages can be sent from either the switch or the controller,
and must return an echo reply. These messages can be used to indicate the
3.5 OpenFlow Protocol 29

latency, bandwidth, and/or liveliness of a controller-switch connection (that is

a heartbeat).

3. Vendor :
These messages provide a standard way for OpenFlow switches to offer additio-
nal functionality within the OpenFlow message type space for future revisions
of OpenFlow.

— Asynchronous messages :
Asynchronous messages are initiated by the switch and used to update the control-
ler of network events and changes to the switch state. Switches send asynchronous
messages to the controller to denote a packet arrival, switch state change, or an
error. There are four main asynchronous messages as follows :

1. Packet-in :
For all packets that do not have a matching flow entry or if a packet matches
an entry with a send to controller action, a packet-in message is sent to the
controller. If the switch has sufficient memory to buffer packets that are sent
to the controller, the packet-in message contains some fraction of the packet
header (by default, 128 bytes) and a buffer ID to be used by the controller
when it is ready for the switch to forward the packet. Switches that do not
support internal buffering (or have run out of internal buffer space) must send
the full packet to the controller as part of the message.

2. Flow-Removal :
When a flow entry is added to the switch by a flow modify message (the Modify
State section), an idle timeout value indicates when the entry should be removed
due to the lack of activity as well as a hard timeout value. The hard timeout
value indicates when the entry should be removed, regardless of activity. The
flow modify message also specifies whether the switch should send a flow removal
message to the controller when the flow expires. Flow modify messages, which
delete flow entries may also cause flow removal messages.

3. Port-status :
The switch is expected to send port-status messages to the controller as the
port configuration state changes. These events include changes in port status
(for example, disabled by the user) or a change in the port status as specified
3.5 OpenFlow Protocol 30

by 802.1D (Spanning Tree).

4. Error :
The switch is able to notify the controller of problems using error messages.

3.5.1.2 Flow Tables

The operation of an Openflow equipment is based on the use of a several flow tables (in
pipeline). A flow table is a data structure that performs packet forwarding and lookups.
Each entry of an Openflow table contains five main parts[11] :

Figure 3.6 – Flow Table [11]

— A filter that captures packets following a set of header fields.

— A list of actions to apply to packets returned by the filter.
— A priority to define which rule should be applied in the case where several rules of
the same table apply on an incoming packet.
— Counters that keep statistics on the number of packets and bytes processed.
— Timeouts : maximum amount of time or idle time before flow is expired by the
switch.
— cookie : opaque data value chosen by the controller. May be used by the controller to
filter flowstatistics, flow modification and flow deletion. Not used when processing
packets.
3.5 OpenFlow Protocol 31

An Openflow filter, can be built using several header fields, we cite below the most im-
portant ones :
— Ethernet : source, destination, type, VLAN ID.
— Ipv4 : source, destination, upper protocol, Tos.
— TCP/UDP : source port, destination port.
Regarding actions, an Openflow switch exposes actions similar to those found in traditional
IP equipment, as shown in the list below :

— Switch the packet to one or more output ports.

— Drop the packet .
— Edit the header fields of a package.
— Encapsulate he packet and send it to the SDN controller.

3.5.1.3 Traffic matching

Figure 3.7 – Flowchart detailing packet flow through an OpenFlow switch [12]

When receiving a packet, an OpenFlow Switch performs the functions shown in Fi-
gure(3.7).
The switch starts by performing a table lookup in the first flow table, and based on pipe-
line processing, may perform table lookups in other flow tables (see Figure 3.8).
Packet match fields are extracted from the packet.Packet match fields used for table loo-
kups depend on the packet type, and typically include various packet header fields, such
as Ethernet source addressor IPv4 destination address. In addition to packet headers,
3.6 SDN use cases 32

matches can also be performed against the ingress port and metadata fields.
Metadata may be used to pass information between tables in a switch. The packet match
fields represent the packet in its current state, if actions applied in a previous table using
the Apply-Actions changed the packet headers, those changes are reflected in the packet
match fields.A packet matches a flow table entry if the values in the packet match fields
used for the lookup match those defined in the flow table entry.
If a flow table entry field has a value of ANY (field omitted), it matches all possible values
in the header. The packet is matched against the table and only the highest priority flow
entry that matches the packet must be selected.
The counters associated with the selected flow entry must be updated and the instruction
set included in the selected flow entry must be applied. If there are multiple matching
flow entries with the same highest priority, the selected flow entry is explicitly undefined
and the packet can either be dropped or sent to the controller[14].

Figure 3.8 – Packet flow through the processing pipeline [13]

3.6 SDN use cases

Over the years, organizations have introduced SDN into their networks. SDN has been
introduced because of its benefits, and the upcoming sections highlight the most prominent
real-life applications of SDN in networks and how they have been adopted[12].

— A network operating system :

The SDN platform can act as a network operating system, providing packet delivery
3.6 SDN use cases 33

to other applications. SDN is a platform allowing other applications to drive, use

the network for their specific requirements. Always remember that SDN doesn’t
do any packet delivery on its own, but it requires SDN applications to define how
packets needs to get delivered in a network.
— Network Access Control :
One of the SDN use cases is NAC. The SDN controller can identify the newly
connected devices, checks its status, and what it needs to access and push the flow
settings back to the SDN enabled switches.
— Integration with private cloud (VMware, OpenStack) :
With increased use of VMware vSphere and OpenStack in data centers, the need
to integrate the network with cloud infrastructure is increasing. An SDN network
can get integrated with cloud application and provide the ability to create virtual
networks, tenant isolation, and even create overlay networks using VXLAN.
— SD-WAN :
Another change in WAN and SD-WAN is the increase of reliability of consumer
grade Internet connections. Many organizations prefer to use multiple cheap, high
bandwidth Internet links instead of using an expensive limited bandwidth MPLS
connection from their service provider. To answer this trend, which leads to popping
up of SD-WAN products and vendors, service providers started to standardize a
provisioning method of delivering an MPLS link and one (or more) Internet links to
clients, which is called local Internet breakout. SD-WAN utilizes the local Internet
breakout to build a secure tunnel to service provider networks and runs an SDN
software with enough intelligence to understand what traffic should be routed via
MPLS and via the Internet link.

Conclusion

In this chapter i highlighted a theoretical and detailed study on the SDN system and its
global architecture and basic components. The next chapter will be totally dedicated to
the extension of this technology to the WAN also known as SD-WAN.
Chapitre 4

Software Defined WAN

Introduction

In recent years, software defined wide-area networking (SD-WAN) solutions have evolved
to address many challenges.
In this chapter we will introduce the SD-WAN technology and its benefits for enterprises,
its characteristics, and why this technology is more reputed than traditional WAN. Finally
we will discuss the juniper solution tested in Tunisie Telecom.

4.1 Definition

The software defined wide area network (SD-WAN) is a specific application of software
defined networking (SDN) technology applied to WAN connections such as broadband in-
ternet, 4G, LTE, or MPLS, to more effectively route network traffic between headquarters
or data centers, remote and branch offices, and the cloud[13].

4.2 SD-WAN Architecture

There are two basic SD-WAN architectures, edge appliances and cloud-based SD-WAN.
Both edge appliances and cloud-based SD-WAN involve a controller function for pushing

34
4.2 SD-WAN Architecture 35

out policies and distributing routing information and a management console for dash-
board, reporting and policy configuration. Where they differ is in the location of the
virtual overlay and how they provide advanced services. The following Figures 4.1/4.2
shows us the simple and detailed global architecture of SD-WAN.

Figure 4.1 – Simple SD-WAN Architecture [14]

Figure 4.2 – Detailed SD-WAN Architecture [15]

4.3 SD-WAN Characteristics 36

4.2.1 SD-WAN Architecture - Edge Appliances

With edge appliances, the SD-WAN virtual overlay stretches from location to location.
Appliances are installed at each site and, once connected to the Internet, retrieve configu-
ration profiles from the SD-WAN controller. The SD-WAN devices configure themselves
and joining or construct a virtual overlay with other devices. Each device runs the policy-
based routing algorithms needed to steer traffic to the most appropriate link based on
application requirements and underlying link quality.

4.2.2 SD-WAN Architecture - Cloud-Based SD-WAN

With Cloud-based SD-WAN, the virtual overlay is formed between the points of presence
(PoPs) of the Cloud SD-WAN service. The PoPs connect to each other across a priva-
tely managed backbone. There are appliances at each location, but in contrast to edge
architecture, Cloud-based SD-WAN appliance run “just enough” functionality to send traf-
fic to the nearest PoP. Software in the PoP applies the necessary security and network
optimizations before forwarding the traffic along the optimum path to its destination.

4.3 SD-WAN Characteristics

SD-WAN implementations have incorporated WAN technologies and functions that have
been developed over the years such as VPN, WAN Optimization, IPsec tunneling, hybrid
WAN, deep packet inspection, policy management, service assurance and analytic while
incorporating newer SDN, NFV, and Service Orchestration technologies.
While SD-WAN service offerings will vary among service providers, these Sections below
discuss fundamental capabilities of SD-WAN managed services[14].

— Secure, IP-based Virtual Overlay Network :

SD-WAN provide secure, IP-based virtual overlay networks that typically uses
IPsec tunnels over Internet or MPLS underlay networks. SD-WANs support any
topology,like full/partial mesh and hub spoke.
4.4 Traditional WAN VS SD-WAN 37

— Transport-independence of Underlay Network :

SD-WANs operate over any type of wireline or wireless access networks such as
internet over LTE /MPLS over fiber.
— Service Assurance of each SD-WAN Tunnel :
Service assurance is a critical part of any managed network service, including SD-
WAN managed services. QoS performance, like packet loss and packet latency, is
measured over each SD-WAN tunnel in real-time.
— High Availability through Multiple WANs :
Each WAN underlay network can use a different wireline or wireless access provider
providing SD-WAN tunnel diversity.
— Policy-based Packet Forwarding :
SD-WANs use policies to make application forwarding (or blocking) decisions for
SD-WANs tunnels over each WAN. Policies can be based on each application or
application grouping, like real-time media or conferencing application.
— Service Automation via Centralized Management, Control and Orchestration :
Service automation is achieved via centralized management, control and orchestra-
tion of SD-WAN tunnels with automatic configuration of SD-WAN. This automa-
tion is achieved by using ZTP (Zero Touch Provisioning) where all configuration
information is pre-populated into the centralized management system.

4.4 Traditional WAN VS SD-WAN

4.4.0.1 Traditional WAN

A traditional WAN connects multiple local area networks (LANs) to each other through
routers and virtual private networks (VPN), and is used for connecting organizations
that have more than one location. Traditional WANs mostly rely on multiprotocol label
switching (MPLS), which provides resilient and efficient network traffic flow. This allows
you to prioritize the voice, video, and data traffic on your network. Figure 4.1 describes
the Traditional WAN architecture.
4.4 Traditional WAN VS SD-WAN 38

Figure 4.3 – Traditional WAN [16]

4.4.0.2 SD-WAN

SD-WAN is a unique approach to wide area networking because it combines traditional

WAN technologies, such as MPLS and broadband connections. This allows organizations
to route traffic to remote locations and multiple offices, and provides enhanced capabilities
for monitoring and managing network traffic while reducing networking costs. SD-WAN
measures the traffic and selects the best route for each data packet in real-time. Figure
4.2 describes the SD-WAN architecture.

Figure 4.4 – SD-WAN [17]

below a table summarizing the main differences between legacy WAN SD-WAN[15].
4.4 Traditional WAN VS SD-WAN 39

Legacy WAN Vs SD-WAN

Parameters Legacy WAN SD-WAN

Bandwidth When bandwidth chokes due to When bandwidth costumer

high utilization by users or appli- location chokes :
cation : — using a secondary
— Wan optimization solution link to provide better
is introduced with incurs. experience.
— Wan bandwidth is increa-
sed or additional link is ta-
ken.

Provisioning High time for setting new setup Low time for setting new se-
and configuration tup and configuration.

Configuration Manually configuration using CLI Automatic configuration

with the ZTP concept.
Performance in Low since branches need to back High since branches can
the cloud haul to the hub devices access directly applications
hosted in the cloud (reduce
the delay).
Infrastructure Complex management of Centralized control of ser-
service branches and multiple devices vices and multiple branches
(reduce the number of de-
vices).

Table 4.1 – Legacy WAN VS SD-WAN

4.5 Benefits of SD-WAN for Enterprises 40

4.5 Benefits of SD-WAN for Enterprises

For the enterprises with significant numbers of branch offices, stitching multiple WAN-
related technologies together is an onerous commitment. SD-WAN delivers a strong set
of business results to fulfill many of the unmet needs of enterprises.
The most known benefits of SD-WAN are listed below[16] :

— Flexibility and automation from decoupling of the hardware-centric data plane

functionality from the software-centric control plane.

— On-demand network services instantiation, such as security services like VPN, or a

firewall based on business-defined policies, with a virtual service delivery platform
from the secure cloud gateways.

— Automation and the intelligence-in-the-cloud gateway head end eliminate the bot-
tleneck of network traffic.

— A unified policy framework enables SD-WAN to orchestrate custom policies across

hundreds and thousands of branches efficiently from an intuitive, UI-based portals.

— real-time monitoring, historical reporting and troubleshooting tools are part of the
cloud management portal.

— Rapid deployment and Internet-as-WAN options enable IT to connect users in pop-

up, temporary branches with reliable connectivity.

— Cloud-based orchestration, configuration and business- policy enforcement auto-

mates the deployment of numerous branches from a central location.
4.6 Case of study : Juniper solution 41

4.6 Case of study : Juniper solution

4.6.1 Juniper Contrail overview

Juniper Contrail SD-WAN delivers a simple, secure multitenant, multisite, and multi-
cloud SD-WAN and branch solution. Contrail combines hybrid WAN connections MPLS,
broadband, legacy interfaces, and wireless 4G/LTE to connect branch sites. And support
virtual CPE like multicloud endpoints in clouds like AWS and Azure. It also dynamically
determines the optimal path for specific application traffic based on policies, while assu-
ring consistent and reliable WAN services that align with business objectives using user
and application-level visibility, analytics, and active/passive quality of experience .
Contrail SD-WAN doesn’t stop at the WAN edge. It unifies security and management
inside the branch as well for LAN and Wi-Fi. It fully orchestrates Juniper Networks EX
Series Ethernet Switches to enable LAN services for users, IoT devices, and wireless access
points.

4.6.2 Contrail Solution Components

— Contrail Service Orchestration :

Juniper Contrail Service Orchestration includes a web-based management interface
for defining policies, managing locations, and visualizing performance behavior,
automating the provisioning and management of devices running SD-WAN and
SD-branch services.
— SRX Series Services Gateways :
These physical devices combine SD-WAN, NGFW, and UTM services with routing
and switching in a single, high- performance, cost-effective device. Two SRX Series
firewalls at a single branch site can be paired in an active/passive arrangement,
doubling traffic throughput and delivering twice the availability of the branch’s
WAN.
— vSRX Virtual Firewall :
The vSRX Virtual Firewall delivers the same features as its physical SRX Series
counterparts, providing the comprehensive security required by SD-WAN in a vir-
tualized form factor. The vSRX can run on a branch-based virtualization platform
4.6 Case of study : Juniper solution 42

or public cloud Infrastructure as a Service on AWS.

— SD-WAN Gateways and Hubs :
There is at least one hub device which is owned by the service provider and resides
within the provider’s point of presence (POP) and shared by multiple customers
acting as SD-WAN Gateway and terminating tunnels from one or more spoke
devices. In an enterprise environment, the cloud hub is owned by the customer and
resides in the enterprise data centre.

Figure 4.5 – Juniper SD-WAN enabled devices[18]

4.6.3 Use Cases and deployment

This section is dedicated to demonstrate the juniper solution proposed by TT. For that
we are going to detail every scenario that we have tested.

4.6.3.1 Topology to deploy

All along this lab we are going to perform our tests on this topology, consisting of :
— First site : One physical juniper SRX device connected to internet throw 2 links
one MPLS and an other internet ADSL. This site will act as a gateway for two pc’s
— Second site : One virtual srx hosted on my pc and connected to internet throw a
4G/LTE link and will act as a gateway to an internal virtual machine hosted on
my computer.
4.6 Case of study : Juniper solution 43

Figure 4.6 – Test topology[19]

4.6.3.2 ZTP : Zero touch provisioning

Zero Touch Provisioning (ZTP) allows you to provision new Juniper Networks devices in
your network automatically, with minimal manual intervention. You can use either ma-
nagement ports or network ports on your switch to connect to the network. When you
physically connect a device to the network and boot it with a default factory configu-
ration, the device upgrades (or downgrades) the Junos OS release and auto installs the
configuration file created by the administrator using the cso ready to use templates.

1. Creating the site template, this template will contain all the device configuration
from general device settings like time zone, geo-location, site name, to WAN and
LAN settings like DHCP services, address pool and link cost and type.
4.6 Case of study : Juniper solution 44

Figure 4.7 – ZTP Template creation[20]

2. Now that the configuration has been pushed to the device from the cso, The rou-
ter is automatically detected and displayed on the web platform, the pc directly
connected to the vsrx can get an ip address and ping the outside world.

Figure 4.8 – ZTP config push and test results [21]

4.6 Case of study : Juniper solution 45

4.6.3.3 Network failover

WAN failover can prevent network disruptions and downtime by transferring traffic from
a degraded or failed connection to a redundant link(ADSL/4G-LTE). Failover can be
automated to ensure continuous availability and provide a seamless experience for users
and customers with no need to restart, reconnect, or log in to applications again. To test
this scenario we will break the MPLS link connected to the physical SRX once this link
is cut the device automatically switch our internet traffic on the backup internet link.

Figure 4.9 – Failover scenario1[22]

Figure 4.10 – Failover scenario2[23]

4.6 Case of study : Juniper solution 46

4.6.3.4 Application firewall Policies

Many dynamic applications use HTTP static ports to tunnel non-HTTP traffic through
the network. Such applications can permit traffic that might not be adequately controlled
by standard network firewall policies, leading to a security threat. Standard policies func-
tion based on IP addresses and ports, and therefore are not effective with these dynamic
applications. To avoid these security issues, an additional security control for policies was
introduced that functions based on the application ID.
The security policies provide firewall security functionality by enforcing rules for the traf-
fic, which pass through the device, is permitted or denied based on the action defined in
the rules. The application firewall port in the policies provides additional security control
for dynamic applications.
An application firewall provides the following features :
— Permits, rejects, or denies traffic based on the application in use.
— Identifies not only HTTP but also any application running on top of it, letting
you properly enforce policies. For example, an application firewall rule could block
HTTP traffic from Facebook but allow Web access to HTTP traffic from other
websites.
The application firewall policy is defined by a collection of rule sets. A rule set defines the
rules that match the application ID detected, based on the application signature. After
you create an application firewall policy by adding rules, you can select that policy to be
the active policy on your device. Using the CSO, here a step by step demonstration for
the firewall application to block the juniper official website.

1. Create and Configure a firewall policy.

In this step we are going to choose our source where the policy will be deployed(SRX/VSRX),
then we are going to apply an action (Deny/Allow/Block) to the source that can
be either an ip address, a port number or a specific application.
4.6 Case of study : Juniper solution 47

Figure 4.11 – Create and Configure a firewall policy[24]

2. Pushing the policy to the SRX/VSRX.

Figure 4.12 – Policy pushed to the SRX/VSRX[25]

3. Test the policy.

As shown below we succeeded to block the juniper.net website.
4.6 Case of study : Juniper solution 48

Figure 4.13 – Firewall Policy result[26]

4.6.3.5 Site to site ipsec vpn

IPsec VPN provides means for securely communicating among remote computers across
a public WAN such as the Internet. A VPN connection can link two LANs (site-to-site
VPN) or a remote dial-up user and a LAN. To secure VPN communication that passes
through the WAN, we can create an IPsec tunnel to allow data to be securely transferred
between two sites.

To perform this option we are going to create an IPsec tunnel between my site (FirasVsrx)
and the physical srx site so that any machine of my LAN ; that have an ip address in the
70.70.70.1/24 pool can ping any other machine in the LAN of the physical srx site that
have an ip address in the 10.10.10.1/24 pool.
4.6 Case of study : Juniper solution 49

Figure 4.14 – firewall policy to allow hosts of site A to ping hosts of site B[27]

As shown bellow the ipsec tunnel is created successfully, site A hostes can now ping site
B hosts securely.

Figure 4.15 – IPsec tunnel creation and successful ping[28]

4.6 Case of study : Juniper solution 50

4.6.3.6 SSL proxy

Secure Sockets Layer (SSL) is an application-level protocol that provides encryption and
decryption technology for the Internet by residing between the server and the client.
SSL, also called Transport Layer Security (TLS), ensures the secure transmission of data
between a client and a server through a combination of privacy, authentication, confiden-
tiality, and data integrity. SSL relies on certificates and private-public key exchange pairs
for this level of security.
We are going to describe below how to create an SSL proxy.

1. Import Certificate.
The certificate can be generated with openSSL package under linux.

Figure 4.16 – Import Certificate[29]

4.6 Case of study : Juniper solution 51

2. Create SSL Proxy Profiles.

After uploading the certificate we have to create an ssl proxy profile to defines SSL
behavior for the SRX Series device.

Figure 4.17 – SSL Proxy Profile Created[30]

3. Create SSL Proxy Policy.

In this step we are going to create a policy based on ssl proxy by providing the
source and the destination.
This policy must be applied to the profile that has the same certificate name defined
in our first step.

Figure 4.18 – SSL Proxy Policy Created[31]

4. Load certification on ubuntu client’s firefox.

In this final step we have to import the certificate and make the test.
4.6 Case of study : Juniper solution 52

Figure 4.19 – Load the certificate[32]

Figure 4.20 – Test result[33]

4.6 Case of study : Juniper solution 53

4.6.3.7 Dynamic path selection

Ensures application flows get the best available network path based on their priorities
and live network traffic conditions. This improves application performance and availabi-
lity by routing traffic over different links when network issues arise. The way dynamic
path selection functions do vary widely. The technology should continually check multiple
link characteristics to make the right decision and work on a per-app-session basis. Dyna-
mic path selection is particularly beneficial for real-time applications, such as Skype for
Business and video.

To perform this task we are going to create an SLA profile to forward Microsoft traffic on
links that meets a specific criteria.
For that the link that will be responsible of forwarding this traffic should have latency
under 100ms and a packet loss not bigger than 5%.

1. Define our SLA profile that meets our application need.

Figure 4.21 – SLA profile [34]

2. Applying that SLA profile to our SD-WAN policy.

4.6 Case of study : Juniper solution 54

Figure 4.22 – SD-WAN Policy [35]

3. As shown below after the degradation of first link performance because wan0 didn’t
meet our policy agreement all the Microsoft traffic has been switched to the second
link that respects better our needs.

Figure 4.23 – Test results [36]

4.6 Case of study : Juniper solution 55

Conclusion

SD-WAN is a software-based approach to wide area networks — essentially a virtual

WAN. It can be used to connect any application using any connection technology, whe-
ther MPLS, 4G, 5G, or broadband internet. SD-WAN offers quality-of-service controls to
differentiate traffic in multiple ways, and it offers business-driven solutions for challenges
such as latency, configuration, and performance. While SD-WAN will build on the past
successes of more mature technologies like SDN and WAN, it may hold the key to the
promising future of our vast and growing global network ecosystem.
General conclusion

In a nutshell, this internship has been an excellent and rewarding experience. I can
conclude that there have been a lot I’ve learnt from my work at TT. Needless to say, the
technical aspects of the work I’ve done are not flawless and could be improved provided
enough time. As someone with no prior experience with SDN and SD-WAN whatsoever I
believe my time spent in research and discovering it was well worth it. Two main things
that I’ve learned : the importance of time-management skills and self-motivation.

56
Bibliographie

[1] https ://www.telcocloudbridge.com/blog/a-cheat-sheet-for-understanding-nfv-

architecture/,viewed on 08/08/2019.

[2] https ://searchnetworking.techtarget.com/definition/NFV-MANO-network-

functions-virtualization-management-and-orchestration

[3] https ://www.telcocloudbridge.com/blog/a-beginners-guide-to-nfv-management-

orchestration-mano/

[4] https ://www.lanner-america.com/blog/5-examples-nfv-use-cases/

[5] ,”NFV White Paper” ,Published on October 22-24, 2012 at the “SDN and OpenFlow
World Congress”, Darmstadt-Germany, viewed on 13/08/2019.

[6] ONF Official Website,https ://www.opennetworking.org/sdn-definition/

[7] Siamak Azodolmolky, Software Defined Networking with OpenFlow

[8] Patricia Morreale & James Anderson, Software Defined Networking : Design and
Deployment

[9] Chuck Black & Paul Goransson, Software Defined Networks : A Comprehensive Ap-
proach

[10] ONF,OpenFlow Switch Specification Version 1.3.1 (Wire Protocol0x04) September

6, 2012

[11] Siamak Azodolmolky, Software Defined Networking with OpenFlow

[12] Smiler. S, OpenFlow Cookbook Kingston

[13] John Wiley & Sons,”Software-Defined WAN For Dummies”.

[14] John Wiley & Sons,”Software-Defined WAN For Dummies”.

[15] https ://ipwithease.com/sd-wan-vs-traditional-wan/,viewed on 14/08/2019.

[16] John Wiley & Sons, Software-Defined WAN For Dummies.

57
 Annexe A

58

View publication stats