Virtual Ization Clouds DN

Virtualization, Cloud &
Software Defined Network (SDN),

By
Hari T.S. Narayanan
1 NFV and sd-wan Timmins Training Consulting

1. Introduction

SErvers
• Servers are typically hosted on dedicated platform
• Dedicated Platform: Both h/w and s/w are
developed and fine tuned for a purpose (service)
• A single such platform is provisioned, configured,
and deployed predominantly with a single service

Current Status
• Vendors develop proprietary dedicated platforms
• Offer solutions on this platform with proprietary software
• This idea suits vendors:
– Such a server offers better performance for about an year and half
until the next generation of servers are ready
– It protects vendors’ investment in R & D
– It allows vendors to cross sell and upsell
– Keeps the customer locked to the vendor
• This is however, not good for customers!
Why this is not good for customers?
• Scaling up means buying more such servers
• Two Year life cycle of servers adds to capital cost
• Scaling down (of a service) is not a viable option
• The process of configuring and getting these proprietary nodes
operational is slow and riddled with scalability problem
• Configuration is error prone - brings down service availability
• The skill set needed for the above process needs to be often
upgraded and it is not portable
• Vendor lock-in implies premium price and in-flexibility
Solution
• The following principle is used in addressing this issue in
current innovations:
Using Abstraction, Virtualization, and Cloud orchestration
create open source solutions that can run on general purpose
hardware platforms:
1. Control and reduce escalating Operational and Capital
expenditures
2. Drive profit through agile & innovative services
• The above principle appears in many different context in this
presentation
Classical Design Patterns
• The following three are primary classical design
patterns
• This presentation requires a sound understanding
of the first two at the least
1. Abstraction
2. Virtualization
3. Modularity
Abstraction
• Provides a friendlier interface to shared
resources in general, by hiding
unnecessary details
• Examples: OS, File System

Modularity
• Breaks down a complex problem into a
number of sub-problems.
• This makes it easier to develop and maintain
the solution. It also helps to re-use broken
down components.
Example: TCP/IP Networking Stack

2. Virtualization

Virtualization (1)
• Virtualization often appears with abstraction and difficult to
differentiate
• Virtualization typically makes one physical resource appear like
multiple virtual resources.
• These virtual resources can have additional functions supported.
• Virtualization is used in computing since the days of Virtual Memory
• There are a number of applications of Virtualization: VM*, VC, …
• Utilization is the primary objective for initial application s of
virtualization

Virtualization (2)
• In this presentation we discuss the following virtualizations:
1. Virtual Machine (VM)
2. Virtual Network
3. Virtual Switch
4. Virtual Router
5. Virtual(ized) Networking Function (VNF)
6. Virtual Device (Cisco’s Virtual Device Context –VDC)

1. Virtual Machines (VM)
• Gordon Moore’s law is slowing down, not dead yet;
resulting in larger computing power supported by growing
storage capacity and large network bandwidth
• Virtual Machine (VM) is one of the many solutions offered
to exploit this abundant power
• VM’s initial motivation is to increase the utilization of this
abundantly present physical power on single machine/host

VM Operation
• Multiple VMs can run on a single
physical machine
• Hypervisor is the Virtualization
enabler, a thin layer of middleware
(application)
• When a VM is created, a default set of
virtually sliced hardware is assigned
to it by Hypervisor
• Commercial Hypervisors:
– VMWare Workstation Player, Infrastructure
Oracle’s VM VirtualBox, KVM, …

Bare Metal & Container
• Other variations of VM – No host OS and No guest OS
VM on Bare Metal +Hypervisor
Container
Hypervisor (VMware ESX and ESXi)
https://nickjanetakis.com/blog/comparing-virtual-machines-vs-docker-containers
Operating System (OS)
• Processor, memory, and I/O devices
have grown in complexity and power
over the years
• A set of programs are created to manage
and share these complex resources
• This set of programs is collectively
referred to as OS or Operating System
• Other programs depend on OS to access
these resources
• OS provides abstracted and virtual view
(in some cases) of these resources
NFV and sd-wan Timmins Training Consulting
Benefits of VM
• Multiple VMs can run on a single host
• Platform independence – for both Host and Guest OS
• Problem isolation and easier management
• A live VM can be moved from one physical host to
another (VM Migration)
• VMs can be easily replicated to handle rapid scaling to
match the demand
• The main challenge is in automating & managing VMs.
How DO We Address The issues listed in
Slide #5?
• Scaling up means buying more such servers
• Two Year life cycle of servers adds to capital cost
• Scaling down (of a service) is not a viable option
• The process of configuring and getting these proprietary nodes
operational is slow and riddled with scalability problem
• Configuration is error prone - brings down service availability
• The skill set needed for the above process needs to be often upgraded
and it is not portable
• Vendor lock-in implies premium price and in-flexibility

CLOUD

2. Network Virtualization
• Unlike VLAN and VPN, this
virtualization presented here is VNet1 VNet2
applications’ view of the network
• Network can be virtualized (and
abstracted) using Networking
Network Hypervisor
Hypervisors
• Network virtualization provides
Net 1 Net 2
– Abstraction (overlay)
– Virtualization (multiple views)
– Sercurity
Examples of network hypervisors: OpenStack Neutron,
– Isolation (data & fault)
Open Daylight (ODL), ONF OpenFlow
Benefits
• Virtual networks of multiple users can be overlaid on top
of a single physical network
• Operator friendly common interface (abstraction) to
complex network – multiple application can make use of
this.
• This makes it easier to create policies for different view of
the networks – rather than over a complex physical
network – mapping is taken care by the SDN
Example
• An operator wants to specify the following CP action: node A
should be isolated from node B
• There are two issues here:
– Complexity of network exposed to the operator
– Invalidation of CP action when topology changes
A→B
A
B
A→B
Physical Network
Example (Continued)
• Virtualization of global network can easily
eliminate the above two issues
– Operator sees is a single node
(Virtualized global network) to which A A→B
both and A and B are connected B
– Operator suggests that there should
not be any packet flow from A to B Virtual Network
in this node
• The single node is the abstracted view of
the global network!!

3. Virtual Switch
• When multiple VMs are run on a single
host, often we have the necessity to
switch packets among them
• This is supported by virtualized
(software) switch.
Example: Open vSwitch OpenvSwitch
• These switches are also capable of
routing packets with other virtual
switches and h/w switches
5. Virtualized Networking Function
(VNF)
• There are a number of Networking functions
– Firewall, DPI, IDS, NAT, DHCP, Name servers
– Media Servers, VoIP Servers
– Mobile servers: PGW/SGW, PCRF
– Security Servers: RADIUS, Diameter nodes
–…

VNF
• VNF removes networking function’s dependency on
the proprietary h/w platform
• This is done by packaging the networking function to
run as a virtual machine (VM) on any open,
commodity platform
• Additionally, this VM can be hosted in cloud as SaaS
• Example: Firewall, IDS
VNF and NFV
• Network Function Virtualization (NVF) is the
framework that is built with Virtualized
Networking Functions (VNFs)
• Network Function Virtualization (NFV) leverages
standard IT virtualization technology with VNF
• This enables agile service deployment for Network
Operators and Service Providers.
Legacy versus VNF based Solution
Purpose
Built with General
custom Purpose
ASIC – H/W
Physical
Appliances
https://f5.com/about-us/news/articles/ensuring-programmability-in-nfv-deployments-19574
Issues with legacy scenario
• Hardware-based appliances rapidly reach end of life
• This puts service providers in repeated cycle of procure-design-
integrate-deploy with little or no revenue benefit
• Lifecycles of these appliances are becoming shorter as technology
and service innovation accelerates
• Every new service requires a new server to be commissioned,
configured, integrated, and supported – cost implications are not
good!
• Both Scaling up and Scaling down is not feasible in this context!

Benefits of VNF
• Reduces Capital and Operational costs by eliminating the need for
new server platforms (both h/w & OS) and frequent upgrades
• Offers Service Agility with automation
• Reduces Operational cost by sharing resources across services and
clients
• Scales up and down quickly in tune with the demand using cloud
optimization or native cloud application
• Creates a flexible network by enabling feasible solutions even for
smaller customer base
• Offers multiple deployment options
VNF Challenges & Requirements
• Interoperability of server functions
• Performance
• Interworking with existing NMS, EMS, and OSS
– ETSI and MEF are managing some of the standardization in this
area
• A consistent MANO framework
• Automation – it is a key component of VNF
• Security & Resilience
NFV - Standard’s Organization
• NFV specifications are from ETSI

• The major contribution of NFV ETSI is NFV
Reference Architecture

ETSI NFV Reference Architecture

3. Software Defined Network
(SDN)

Understanding Software Defined Network
(SDN)
• This is a diluted version
• Assumption: Router function and Route Table

Router or Gateway
• Router’s primary role is to forward
packets between networks using route
table
• The route table is built by Routing Subnet 2
192.168.2
programs that are running on these

routers GW
• Routing programs exchange routing Subnet 1 Subnet 3

192.168. Subnet 5
messages using TCP/IP stack to come 1 192.168.5 192.168.
3
up with the routing table at each

router Subnet 4
192.168.
To Internet
• The routing table also eliminates loops 4.
and cycles in packet path.

Routing Programs
• There are a number of routing programs
supported by their respective routing
protocols
• RIP (Routing IP) is one of the earliest routing
protocols or routing programs

RIP Operation - Example
NET2 4 C NET2 5 C
RIP Message NET3 8 C NET3 9 C RIP Message
From C
NET6 4 C NET6 5 C From C after
NET8 3 C NET8 4 C
NET9 5 C NET9 6 C Increment
NET1 7 A
NET1 7 A NET2 5 C
NET2 2 C
Old Routing NET6 8 F
Router NET3 9 C Updated
NET6 5 C Routing
Table NET8 4 E D NET8 4 E Table
NET9 4 F NET9 4 F

Grouping Network Functions
• Network functions are grouped into the following 3
categories/planes:
– Data/user/forwarding Plane (the core message exchanging
functions – the core stack)
– Control Plane (functions like RIP, that enable core message
exchanging)
– Management plane (FCAPS functions)
• All the 3 planes depend on each other in a complex and ad-hoc
way (now)
Current Network Element Design
Management
• In legacy/current networking, control and
Plane
data planes are tightly coupled and both
Management Interface
coexist on Networking Element(NE) Network Element
• One control plane per one data plane Management Plane
• Management plane mainly exist off-network

Control Plane
over one or more management hosts
Data Plane

Data Plane
• Data Plane is built on well defined abstractions
• Applications are written on Reliable Transport
• Reliable Transport is based on Best effort global
packet delivery
• Global delivery based on Best effort local frame
delivery
• Local delivery based on Local physical transfer of bits

Control Plane
• The real problem lies with the control plane in its current form of
deployment
• No abstraction to support Routing, Isolation, & Traffic Engineering
• Every new function is built from scratch in an ad-hoc way
• Number of proprietary solutions dominate this group with purpose built
platforms
• Complexity (of routers and other nodes) is growing with no easier way out

Characteristics of Legacy Control Plane
• Monolithic design
• Vertically integrated (S/W, H/W, and Network)
• Purpose-built (Built with ASIC and Proprietary s/w)
• Proprietary
• Tightly coupled (S/W is bound to purpose-built h/w)
• H/W oriented (Built with speed in mind – h/w up)

ONF’s Objective
• Transform Network industry like Computer Industry
(Unbundled entities)

What is SDN?
• The physical separation of the network

control plane from the forwarding/data
plane, and where a control plane
controls several physical/software
forwarding planes.

Software Defined Network (SDN) solution
• Decouples data and control layers with a well-defined
interface (OpenFlow)
– The decoupled control layer can be hosted anywhere
– Logically centralized (sometime hierarchical)
• Delivers the ability to program network behavior from
remote control layer using a standard protocol –
OpenFlow
• Enables the control layer to offer an open API
Open Network Foundation
• The ONF is an operator led consortium
• Transforming networks into Agile Platforms for
Service Delivery
• SDN OpenFlow is a specification from ONF
• Besides OpenFlow, ONF offers SDN based projects
and solutions
• CORD is ONF Agile Platform for Access Networks
SDN Architecture
1. Network control plane is a logically centralized
directly programmable application
2. It is Agile: Administrators can dynamically adjust
network-wide traffic flow to meet changing needs
3. Network controller maintains a global view of the
network – Applications that use the controller can
have individual virtual view of the network
4. SDN lets network applications to programmatically
configure, manage, secure, and optimize network
resources
5. Vendor independent and Open Standard
Characteristics of SDN
• Plane Separation
• Simplified Networking (Forwarding) Elements
• Logically Centralized Controls
• Network Automation
• Virtualization & Isolation
• Openness
SDN and OpenFlow
Open vSwitch (OVS)

OpenFlow
• OpenFlow includes switch* specification & a switch - controller
communication protocol, and a reference Controller
• Switches have forwarding tables that maps
– header → (action, counter)
• Action is applied to ingress packet with matching header
• Header can have exact fields or wildcarded fields
• Variety of actions – modify header, forward, drop, etc
• Counter – to measure rate and aggregation of packets that
meet certain conditions
Controller-Switch Interface

SDN Benefits
• 1-to-1 binding between control and data plane is broken; many-to-
many is possible now.
• Two planes can evolve independently
• Separation encourages independent innovations
• Service provider is not stuck with a single vendor anymore
• Co-ordinated Management and Agile Deployment
• Logically centralized Controller offers better view of the network
• Managing common data at a centralized site enables scalable
solutions
SDN and Virtualization
• Both decouple s/w functions from purpose-built networking elements –
SDN may be enhanced by virtualization
• SDN and NFV are independent
– SDN with no NFV is often seen in Data Centers
– NFV with no SDN is a possibility for Value Added Network Functions
• They mutually complement each other
– SDN offers application aware traffic control with a virtual view of
network
– NFV brings capacity, speed & flexible deployment and reduced cost

Some ONF Projects
1. CORD: ONF Central Office Solution
2. Mininet: Network Simulator for controller
development and testing
3. O-NOS: OpenFlow and OpenFlow Controller
4. Open Transport: Configuration and control
interfaces for transport networks in SDN

3.1 Mininet

What is Mininet?
• Mininet is an emulation orchestration system for SDN Networks
• SDN network with emulated Open Flow switches, hosts, and
links is made possible by Mininet
• Emulated networks are specified using Mininet CLI or Python
scripting
• To a large extent Mininet entities behave similar to discrete
hardware elements, especially the host nodes.
• The Mininet host can do almost anything the Linux host does!

Why Mininet?
• You can develop, test, and run real OpenFlow
control programs with Mininet
• Complex networks can be emulated with
Mininet
• Emulation saves time and money
• Mininet is from Open Source
SDN - Mininet
C0
S1
H1 H2 H3

Mininet Limitations
• Runs in real time – simulation of faster links not
possible
• All the emulations are done with single Linux
Kernel – limits the size of emulation - use of fast
links discouraged to conserve resources
• Mininet host shares “/etc” folder with Ubuntu host
– this can cause file collision
3.2 Open virtual Switch (OvS)
Virtual Router
http://www.openvswitch.org/

What is Open vSwitch (OVS)?
• It is a multilayer software
switch licensed under the
open source Apache 2 license.
• It supports standard 2 1
management interface 3 5
• Its forwarding functions can

be programmatically
configured
4 6

Features Supported
1. Standard 802.1Q VLAN with both Trunk and Access ports
2. NIC bonding with or without LACP in upstream switch
3. Netflow, sFlow ( R ) and mirroring for increased visibility
4. OpenFlow 1.0 Support
5. QoS (Quality of Service) configuration, plus policing
6. Tunneling with GRE, VXLAN, etc
7. High-performance forwarding using a Linux kernel module

OVS Architecture
Tools/Protocols
ovs-switchd Servers

OVS Components and Tools (1)
• ovs-vswitchd, a daemon that implements the switch, along
with a companion Linux kernel module for flow-based
switching.
• ovsdb-server, a lightweight database server that ovs-
vswitchd queries to obtain its configuration.
• ovs-dpctl, a tool for configuring the switch kernel module.
• ovs-vsctl, a tool for querying and updating the
configuration of ovs-vswitchd.
OVS Components and Tools (2)
• ovs-ofctl, a utility for querying and controlling

OpenFlow switches and controllers.
• ovs-pki, a utility for creating and managing the
public-key infrastructure

OVS Modes
• Normal Mode: Behaves like a layer-2

switch
• Flow Mode: Flow table content decides
the behaviour

OpenFlow Demonstration with Mininet
https://www.youtube.com/watch?v=l25Ukkmk6Sk
Specifying Controller
• In this example we use default reference controller C0 for a reason
• The default controller C0 uses Loopback interface of the switch
• Non default, Non-local controller need to be explicitly specified
• Launch the “single,4” mininet as follows:
sudo mn --topo=single,4 --mac

• This mininet runs with default reference controller

Start Wireshark
• In another Putty shell, start Wireshark as a background job:
sudo wireshark &
• Start the capture in loopback adapter
• Set the view filter to “of” (open flow)
• From the Putty shell, where mininet is running do the
following: h1 ping –c2 h2
• Stop capturing in Wireshark – we have what we want.
• A comprehensive OpenFlow Wireshark trace is here.

Managing Flow Table with Controller
Utilities
• In new Putty Shell do the following (This slide content is ahead of its time!)
– sudo ovs-ofctl show s1
– sudo dpctl dump-flows tcp:127.0.0.1:6634 (default all switches)
– sudo ovs-ofctl dump-flows tcp:127.0.0.1:6634
– sudo dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2
– sudo dpctl add-flow tcp:127.0.0.1:6634 in_port=2,actions=output:1
– sudo ovs-ofctl dump-flows tcp:127.0.0.1:6634

Non-default Forwarding
• sudo mn --controller=remote,ip=127.0.0.1,port=6633

vRouter
Virtual ROUTER
https://wiki.opencord.org/pages/
viewpage.action?pageId=1278093

Border Network Gateway (BNG)
Example:
Cisco’s
ASR/ISR

Virtual Router (vRouter)
• In the disaggregated CORD architecture we use a virtual
router (vRouter) service to replace BNG
• The vRouter service does not implement all functionality
that exists in traditional BNG devices.
• However, it does implement the functionality necessary to
provide Internet access to CORD in a disaggregated fashion.

vRouter Design
• The design of the vRouter service is split into two
main parts that are relatively independent from
one another – control plane and data plane.
• The vRouter has some data plane devices which it
is in control of, and from the external point of view
those devices appear as though they are a single
router, supporting a set of routing protocols.
Control Plane & Data Plane of vRouter
The Data Plane can be physical or virtual!!

Role of vRouter in CORD
• It provides Internet access to the subscribers and services within CORD.
• Logically, it is the final service in the chain that a user's traffic traverses
before exiting the CORD system.
• Physically, it is the interface between CORD and the provider’s upstream
network.
• The vRouter service provides Internet-as-a-service to other services within
the CO.
• The vRouter is implemented as a network control application running on
ONOS.

Control Plane
Access Network

Cisco’s CSR 1000V
Virtualization – Don’t assume presence of automation

4. Cloud

Cloud
• A radically different service paradigm for
delivering computing
• In Cloud, a computing service that is
normally owned and used in user premises
is delivered from the network cloud
• Services offered by cloud include: Software,
Storage, Platform, Infra-structure, and
Desktop
• Your laptop becomes a simple front end
http://nwctrail.com/2018/04/10/global-cloud-
when you access cloud applications storage-service-market-status-2018-2022-mega-
onedrive-box-spideroak/

Cloud Service Models
• In general, Cloud service providers offer 3 different service
models
– Software as a Service (SaaS)
– Platform as a Service (PaaS)
– Infrastructure as a Service (IaaS)
• There are other lesser known models: DaaS, StorageaaS, NaaS,
etc.

Cloud and VM
• Cloud operation is critically dependent on VMs
– VM enables cloud to be rapidly-elastic, operationally
less expensive
– Other features like multi-tenancy, availability, recovery
are enhanced by VM technology
Cloud = F(Virtualization, Automation)

SaaS with VM
• Every user of a SaaS is hosted with a VM
• When the demand increases for service, VMs are
cloned
• Cloning can be automated
• Imagine doing SaaS without VM!
• When there is no demand, host is used for other
purpose
Cloud Deployment Models
• Private Cloud
• Public Cloud
• Hybrid Cloud
• Community Cloud

Cloud Platforms
• Amazon AWS
• Microsoft Azure
• Google Cloud Platform (GCP)
• OpenStack (Initiated by RackSpace in 2010)

Benefits of Cloud
• Ubiquitous access
• Availability
• Flexibility
• Maintenance issues left to the experts
• Reduced Capital & Operational Expenditure
• Better control over Service use – offers ways to
innovative packaging
• Environmentally friendly

OpenStack as Virtual Infrastructure Manager (VIM)
Horizon

OpenStack Tools
https://www.mirantis.com/software/openstack/
https://opensource.com/resources/what-is-openstack

Nova
• Nova is the underlying cloud computing fabric controller for the OpenStack cloud.
• All activities needed to support the life cycle of instances within the OpenStack
cloud are handled by Nova.
• Nova manages all the compute resources, networking, authorization, and
scalability needs of the OpenStack cloud.
• Nova is a management platform and does not provide any virtualization
capabilities by itself; instead, it uses libvirt APIs to interact with the supported
hypervisors.
• Nova exposes its capabilities through a web services API that is compatible with
that of EC2 of Amazon Web Services.

OpenStack Instance & Instance Types
• An instance is a virtual machine provisioned by OpenStack on one
of the nova-compute servers.
• Nova has the concept of instance types.
• Each instance type is defined with certain quantity of Processor,
RAM, and hard disk.
• Nova calls instance types as ‘flavors’ and lets you add to the list of
flavors.
• By default Nova has 5 types – m1.tiny, m1.small, m1.medium,
m1.large and m1.xlarge.

Flavor List
m1.medium: Memory: 4096MB, VCPUS: 2, Storage: 40GB, FlavorID: 3, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
m1.large: Memory: 8192MB, VCPUS: 4, Storage: 80GB, FlavorID: 4, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
m1.tiny: Memory: 512MB, VCPUS: 1, Storage: 0GB, FlavorID: 1, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
m1.xlarge: Memory: 16384MB, VCPUS: 8, Storage: 160GB, FlavorID: 5, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB
m1.small: Memory: 2048MB, VCPUS: 1, Storage: 20GB, FlavorID: 2, Swap: 0GB, RXTX Quota: 0GB, RXTX Cap: 0MB

Server Creation API
• When you create a server, the operation asynchronously
provisions a new server.
• The progress of this operation depends on several factors
including location of the requested image, network I/O, host
load, and the selected flavor.
• The progress of the request can be checked by performing a
GET on /servers/``id``, which returns a progress attribute
(from 0% to 100% complete).
• The URL to the newly created server is returned
OpenStack System
https://cssoss.wordpress.com/2011/04/27/openstack-beginners-guide-for-ubuntu-11-04-installation-and-configuration/
Server Configuration

Tacker AS MANO
• Tacker is an OpenStack
project for building
VNFM and NFVO to
deploy and operate
Virtual Network
Functions and Network
Services on an NFV
infrastructure platform
like OpenStack.
https://wiki.openstack.org/wiki/Tacker
Tacker Use Cases
• vCE: Tacker API can be used by SP's OSS / BSS or an NFV Orchestrator to
deploy VNFs in SP's network to deliver agile network services for remote
Customer networks
• vCPE: Tacker API can be used by SP's OSS / BSS or an NFV Orchestrator to
manage OpenStack enabled remote CPE devices to deploy VNFs to provide
locally network services at the customer site.
• vPE: Tacker API can be used by SP's OSS / BSS or an NFV Orchestrator to
deploy VNFs within SP's network to virtualize existing network services
into a Virtual Function.

OpenStack Heat
• Heat implements an orchestration engine to launch
multiple composite cloud applications based on
templates in the form of text files that can be treated
like code.
https://wiki.openstack.org/wiki/Heat
Heat Python Applications
• Heat: The Heat tool is a CLI which communicates with the heat-api to
execute AWS CloudFormation APIs.
• Heat-api: The Heat-api component provides an OpenStack-native ReST
API that processes API requests by sending them to the Heat-Engine over
RPC.
• Heat-api-cfn: The Heat-api-cfn component provides an AWS-style Query
API and processes API requests by sending them to the Heat-engine over
RPC.
• Heat-engine: The Heat engine does the main work of orchestrating the
launch of templates and providing events back to the API consumer.
Heat Operation
• A Heat Orchestration Template (HOT), version controlled, describes the infrastructure for a cloud
application
• Infrastructure resources: servers, floating ips, volumes, security groups, users, etc.
• Heat also provides an autoscaling service that integrates with Telemetry, so you can include a scaling
group as a resource in a template.
• Templates can also specify the relationships between resources (e.g. this volume is connected to this
server). This enables Heat to call out to the OpenStack APIs to create all of your infrastructure in the
correct order to completely launch your application.
• Heat manages the whole lifecycle of the application - when you need to change your infrastructure,
simply modify the template and use it to update your existing stack. Heat knows how to make the
necessary changes. It will delete all of the resources when you are finished with the application, too.
• Heat primarily manages infrastructure, but the templates integrate well with software configuration
management tools such as Puppet and Chef. The Heat team is working on providing even better
integration between infrastructure and software.

Heat Template - Example 1
https://www.ibm.com/support/knowledgecenter/SS4KMC_2.5.0.5/com.ibm.ico.doc_2.5/r_heat_template_examples.html
Heat Template - Example 2

5. WAN

Wide Area Network
• WAN offers connectivity
over larger geographical BO1
locations
• WAN is high latency, scarce
WAN (SP
bandwidth, bandwidth Internet Network)
managed, and expensive
network HO BO2
• The diagram on the right
shows one use case of WAN BO3

WAN Use Cases
• ISP Backhaul
• Enterprise Connectivity
• Mobile Backhaul (3G, 4G, …)
• Enterprise Data Centre (DC) Connection
• DC-DC connection
• VoIP Back bone
WAN Requirement
• Service Provider owns the network infra-structure
• WAN service is offered to multiple clients by typically
overlaying Virtual Private Networks (VPN) of each
client on top
• Thus, WAN is expected to offer the following features:
– Privacy
– Isolation

WAN Technologies
• WAN connectivity with MPLS
– Virtual Private Circuits with labels
• WAN connectivity with Carrier (Metro) Ethernet
– Virtual Private circuits with VLAN Tags
• WAN connectivity with Broadband IPSec
– Virtual Private Networks with Tunnels
• WAN connectivity with dedicated T1/E1 – Leased Lines
• WAN connectivity with Frame Relay – Leased Circuits

WAN VPN Topologies
• Point-to-Point
• Star (Hub-and-Spoke)
• Partial Mesh
• Full Mesh

WAN Customer Premises Equipment
(CPE) & PE
• CPE is carrier owned and customer located – connects Client
network to WAN
• CPE AKA Customer Edge (CE) or Business Gateway (BG)
• A managed CPE is controlled & managed by the service provider
• A non-managed CPE is controlled & managed by the client
Source: Hybrid WAN – Best Practices

WAN Optimization
• The following are some of the popular WAN
optimization techniques:
Protocol spoofing
– Deduplication
Forward Error Correction
– Compression .
Traffic shaping
– Latency optimization
Simple rate limits
– Caching/proxy
Equalizing

MPLS Virtual Network Services
1. VLL — A scalable point-to-point piping service that
carries customer traffic between two customer sites.
2. VPLS — A multipoint-to-multipoint Ethernet bridging
service that bridges customer Ethernet traffic among
geographically separated locations.
3. VPRN — A multipoint-to-multipoint IP routing service
that routes customer IP traffic among different sites

Carrier Ethernet Services
• Metro Ether offers L2 services within Metro area
– E-LINE & E-LAN
Source: Hybrid WAN – Best Practices

IPSec VPN
• IPSec VPN is a point-to-point secure
connection over Internet
• It is used in connecting small branch office or
home office to central office over Internet
• It is cheaper and viable as WAN solution in
many use cases
Tunneling Protocols
• UDP based tunnels allow multiple logical end points to
originate from or terminate at the same UDP Port Number.
• This offers traffic isolation and multiple p-2-p connections
• Generic Routing Encapsulation (GRE) with IP
– Lower message overhead
• Virtual Extensible LAN (VXLAN) with UDP
– Supports NAT
• NVGRE (Network Virtualization GRE)
Issues with the current WAN (1)
• Purpose built CPE with proprietary applications is at the center of current WAN issues
– It is expensive and time consuming task to Install, configure, and manage these
CPEs
– Small branch offices cannot afford such a CPE, some cannot manage it too
– With a large number of branches, this unaffordable cost increases linearly.
– New services requires changes to all branches and already clogged HO data
center
– Manual configuration leads to poor performance due to un-predictable link status
– WAN connectivity with a passive standby leads to poor utilization. Aggregation is
not easy to support across multiple technologies
– Distributed WAN Routing protocol hosted on these CPEs takes several seconds to
converge from outages
– Segmentation is desirable but the logistics and cost make it unaffordable.
Changing Traffic Pattern
Legacy WAN Traffic
• Inefficient hairpin traffic
increasing the distance between
end points
• Branch sites need larger band-
width for SaaS & other cloud
applications like Virtual Reality,
Augmented Reality, and Online
games
• Changing traffic pattern during
different parts of the day need to
be handled efficiently Source: Cisco SD-WAN
Issues with the current WAN (2)
• Internet, SaaS and cloud‐hosted applications are still backhauled over private
networks and through the centralized corporate data center.
• Expensive private networks are congested with SaaS, AR, VR, and Realtime VoIP
• Complex CLI‐based configuration and troubleshooting requires lengthy training
cycles for network operations staff.
• Step function upgrades with long deployment time.

THANKYOU
Timmins Training Consulting
A27-07, Mercu Summer Suites, 8, Jalan Cendana, Kuala Lumpur, 50250, Malaysia. ||
www.consult-timmins.com || info@consult-timmins.com

Virtual Ization Clouds DN

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Virtual Ization Clouds DN

Uploaded by

Copyright:

Available Formats

Virtualization, Cloud &

Software Defined Network (SDN),

1 NFV and sd-wan Timmins Training Consulting

2 NFV and sd-wan Timmins Training Consulting

3 NFV and sd-wan Timmins Training Consulting

8 NFV and sd-wan Timmins Training Consulting

9 NFV and sd-wan Timmins Training Consulting

10 NFV and sd-wan Timmins Training Consulting

11 NFV and sd-wan Timmins Training Consulting

12 NFV and sd-wan Timmins Training Consulting

13 NFV and sd-wan Timmins Training Consulting

14 NFV and sd-wan Timmins Training Consulting

Hypervisor (VMware ESX and ESXi)

18 NFV and sd-wan Timmins Training Consulting

19 NFV and sd-wan Timmins Training Consulting

23 NFV and sd-wan Timmins Training Consulting

25 NFV and sd-wan Timmins Training Consulting

29 NFV and sd-wan Timmins Training Consulting

• NFV specifications are from ETSI

32 NFV and sd-wan Timmins Training Consulting

33 NFV and sd-wan Timmins Training Consulting

34 NFV and sd-wan Timmins Training Consulting

35 NFV and sd-wan Timmins Training Consulting

programs that are running on these

• Routing programs exchange routing Subnet 1 Subnet 3

up with the routing table at each

• The routing table also eliminates loops 4.

and cycles in packet path.

37 NFV and sd-wan Timmins Training Consulting

38 NFV and sd-wan Timmins Training Consulting

• Management plane mainly exist off-network

40 NFV and sd-wan Timmins Training Consulting

41 NFV and sd-wan Timmins Training Consulting

42 NFV and sd-wan Timmins Training Consulting

43 NFV and sd-wan Timmins Training Consulting

44 NFV and sd-wan Timmins Training Consulting

• The physical separation of the network

45 NFV and sd-wan Timmins Training Consulting

Open vSwitch (OVS)

52 NFV and sd-wan Timmins Training Consulting

54 NFV and sd-wan Timmins Training Consulting

55 NFV and sd-wan Timmins Training Consulting

56 NFV and sd-wan Timmins Training Consulting

57 NFV and sd-wan Timmins Training Consulting

59 NFV and sd-wan Timmins Training Consulting

61 NFV and sd-wan Timmins Training Consulting

• Its forwarding functions can

62 NFV and sd-wan Timmins Training Consulting

2. NIC bonding with or without LACP in upstream switch

3. Netflow, sFlow ( R ) and mirroring for increased visibility

4. OpenFlow 1.0 Support

5. QoS (Quality of Service) configuration, plus policing

6. Tunneling with GRE, VXLAN, etc

7. High-performance forwarding using a Linux kernel module

64 NFV and sd-wan Timmins Training Consulting

• ovs-ofctl, a utility for querying and controlling

66 NFV and sd-wan Timmins Training Consulting

• Normal Mode: Behaves like a layer-2

67 NFV and sd-wan Timmins Training Consulting

sudo mn --topo=single,4 --mac

69 NFV and sd-wan Timmins Training Consulting

70 NFV and sd-wan Timmins Training Consulting

71 NFV and sd-wan Timmins Training Consulting