Unit V ND

CP5201 Network Design and Technologies – UNIT V
UNIT V SOFTWARE DEFINED NETWORKS

Introduction – Centralized and Distributed Control and Data Planes – Open Flow – SDN
Controllers – General Concepts – VLANs – NVGRE – Open Flow – Network Overlays – Types
– Virtualization – Data Plane – I/O – Design of SDN Framework
INTRODUCTION
In the SDN architecture, the control and data planes are decoupled, network intelligence and state are
logically centralized, and the underlying network infrastructure is abstracted from the applications. As a
result, enterprises and carriers gain unprecedented programmability, automation, and network control,
enabling them to build highly scalable, flexible networks that readily adapt to changing business needs
OpenFlow-based SDN is currently being rolled out in a variety of networking devices and software,
delivering substantial benefits to both enterprises and carriers, including:
• Centralized management and control of networking devices from multiple vendors;
• Improved automation and management by using common APIs to abstract the underlying networking
details from the orchestration and provisioning systems and applications;
• Rapid innovation through the ability to deliver new network capabilities and services without the need to
configure individual devices or wait for vendor releases;
The Need for a New Network Architecture The explosion of mobile devices and content, server
virtualization, andadvent of cloud services are among the trends driving the networking
industry to reexamine traditional network architectures. Many conventionalnetworks are hierarchical, built
with tiers of Ethernet switches arranged ina tree structure
Changing traffic patterns: Within the enterprise data center, traffic patterns have changed significantly. In
contrast to client-server applications where the bulk of the communication occurs between one client and
one server, today‘s applications access different databases and servers, creating a flurry of ―east-west‖
machine-to-machine traffic before returning data to the end user device in the classic ―north-south‖ traffic
pattern
The ―consumerization of IT‖: Users are increasingly employing mobile personal devices such as
smartphones, tablets, and notebooks to access the corporate network
csestudymate.wordpress.com Page 1
The rise of cloud services: Enterprises have enthusiastically embraced both public and private cloud
services, resulting in unprecedented growth of these services. Enterprise business units now want the agility
to access applications, infrastructure, and other IT resources on demand and à la carte.
―Big data‖ means more bandwidth: Handling today‘s ―big data‖ or mega datasets requires massive
parallel processing on thousands of servers, all of which need direct connections to each other. The rise of
mega datasets is fueling a constant demand for additional network capacity in the data center
Limitations of Current Networking TechnologiesMeeting current market requirements is virtually

impossible with traditionalnetwork architectures. Faced with flat or reduced budgets, enterprise
ITdepartments are trying to squeeze the most from their networks usingdevice-level management tools and
manual processes. Carriers face similarchallenges as demand for mobility and bandwidth explodes
Complexity that leads to stasis: Networking technology to date hasconsisted largely of discrete sets of
protocols designed to connect hostsreliably over arbitrary distances, link speeds, and topologies
Inconsistent policies: To implement a network-wide policy, IT may haveto configure thousands of devices
and mechanisms. For example, everytime a new virtual machine is brought up, it can take hours, in some
casesdays, for IT to reconfigure ACLs across the entire network
Inability to scale: As demands on the data center rapidly grow, sotoo must the network grow. However,
the network becomes vastly more complex with the addition of hundreds or thousands of networkdevices
that must be configured and managed
Vendor dependence: Carriers and enterprises seek to deploy newcapabilities and services in rapid
response to changing business needs or user demands. However, their ability to respond is hindered by
vendors‘equipment product cycles, which can range to three years or more. Lack ofstandard, open
interfaces limits the ability of network operators to tailor thenetwork to their individual environments
Software-Defined Network Architecture
Perhaps most importantly, network operators and administrators canprogrammatically configure this
simplified network abstraction rather thanhaving to hand-code tens of thousands of lines of configuration
scatteredamong thousands of devices. In addition, leveraging the SDN controller‘scentralized intelligence,
IT can alter network behavior in real-time anddeploy new applications and network services in a matter of
hours or days
Likewise, SDN makes it possible to manage the entire network through intelligent orchestration and
provisioning systems. The Open NetworkingFoundation is studying open APIs to promote multi-vendor
management,which opens the door for on-demand resource allocation, self-serviceprovisioning, truly
virtualized networking, and secure cloud services
Inside OpenFlowOpenFlow is the first standard communications interface defined betweenthe control and
forwarding layers of an SDN architecture.
OpenFlow allowsdirect access to and manipulation of the forwarding plane of network devices such as
switches and routers, both physical and virtual (hypervisor-based).
It is the absence of an open interface to the forwarding plane that has ledto the characterization of today‘s
networking devices as monolithic, closed,and mainframe-like OpenFlow can be compared to the instruction
set of a CPU.
OpenFlow-based SDN architecture can integrateseamlessly with an enterprise or carrier‘s existing

infrastructure and providea simple migration path for those segments of the network that need
SDNfunctionality the most.
Benefits of OpenFlow-Based Software-DefinedNetworks

For enterprises and carriers alike, SDN makes it possible for the networkto be a competitive differentiator,
not just an unavoidable cost center.
OpenFlow-based SDN technologies enable IT to address the highbandwidth,dynamic nature of today‘s
applications, adapt the network toever-changing business needs, and significantly reduce operations
andmanagement complexity.
The benefits that enterprises and carriers can achieve through an OpenFlow-based SDN architecture
include
Centralized control of multi-vendor environments: SDN control software can control any OpenFlow-
enabled network device from any vendor, including switches, routers, and virtual switches.
Rather than having tomanage groups of devices from individual vendors, IT can use SDN-based
orchestration and management tools to quickly deploy, configure, and update devices across the entire
network.
Reduced complexity through automation: OpenFlow-based SDN offers a flexible network automation
and management framework, which makes it possible to develop tools that automate many management
tasks that are done manually today.
Higher rate of innovation: SDN adoption accelerates business innovation by allowing IT network
operators to literally program—and reprogram—thenetwork in real time to meet specific business needs
and user requirementsas they arise.
Increased network reliability and security: SDN makes it possible for IT to define high-level
configuration and policy statements, which are then translated down to the infrastructure via OpenFlow
Enterprises and carriers benefit from reduced
operational expenses, more dynamic configuration capabilities, fewer errors, and consistent configuration
and policy enforcement
More granular network control: OpenFlow‗s flow-based control model allows IT to apply policies at a
very granular level, including the session, user, device, and application levels, in a highly abstracted,
automated fashion.
Better user experience: By centralizing network control and making state information available to higher-
level applications, an SDN infrastructure can better adapt to dynamic user needs
Centralized and Distributed Control and Data PlanesWith this model, once a centralized controller
derives the desired forwarding behavior, forwarding instructions for packets are downloaded to the
appropriate networkdevices.
The communication between the controller and the network devices can use some form ofstandardized
protocol such as OpenFlow to facilitate standardized network device programming
Overlay NetworksThe use of overlay networking technologies is another common characteristic to a

number of SDNarchitectures. Overlay networks, provide a construct for the creation of logical networks
that can be leveraged by edge devices and applications. Overlay tunneling technologies such as VXLAN,
enable the creation of logical networks on top of the existing physical network without having to explicitly
involve the underlying physical network
SDN Solution Taxonomy

Within any networking solution, one can classify network characteristics within the following
broadcategories:
Control Plane FunctionIn its simplest form, the control plane provides layer-2 MAC reachability and
layer-3 routinginformation to network devices that require this information to make packet forwarding
decisions.
In thecase of firewalls, the control plane would include stateful flow information for inspection. Control
planefunctionality can implemented as follows:
Distributed - Conventional routers and switches operate using distributed protocols for control, i.e.where
each device makes its own decisions about what to do, and communicate relevant informationto other
devices for input into their decision making process. For example, the Spanning TreeProtocol (STP), Fabric
Path, and routing protocols such as IS-IS and BGP provide distributedcontrol of packet forwarding
functionality to networking devices.
Centralized - In this case, a centralized controller provides the necessary information for a networkelement
to make a decision. For example, these controller(s) instruct networking devices on whereto forward
packets by explicitly programming their MAC and FIBs.
The control plane functionality can be further classified as follows
Layer-2 Reachability Control This control mechanism provides Layer 2 MAC reachability information. It
can either be implemented in a distributed manner like bridging and data-plane learning, or in a centralized
manner with a controller-based device.
Layer-3 Reachability ControlThe Layer 3 control mechanism provides Layer 3 routing and reachability
information to all participating devices. Conventional routing protocols are distributed, while an SDN
based systemtypically involves downloading controller-derived Layer 3 forwarding tables to various
devices, usingstandardized or open protocols
Data Plane / Control Plane CollocationThe main function of network devices and appliances is to
forward user-generated data traffic within thenetwork infrastructure; the particular forwarding policies are
dependent upon the type of device. Suchnetwork elements can be one of the following:
Collocated—These are devices that use distributed control planes and which have control plan anddata
plane functions that are collocated, i.e., no external entity is required for the device to makedecisions.
These appliances can be physical or virtual. All of Cisco‘s physical devices, the AdaptiveSecurity
Appliance (ASA) 1000v, and Cloud Services Router (CSR) 1000v are examples of deviceswith collocated
control plane + data plane.1
Dislocated—The functionality of the device is distributed across multiple elements, under thecontrol of a
centralized element, i.e. the data plane and control plane of the device are dislocated.
The functionality of the device is dependent on instructions coming from the centralized element.
The OpenFlow enabled Cisco 3750-X and 3650-X devices, the Nexus 1000v, and the newlydeveloped
Virtual Provider Edge (vPE) solution are examples of devices with dislocated control
plane and data plane. Devices that use distributed control planes may have dislocated control planeand data
plane functions; devices with centralized controllers implicitly have dislocated controlplane and data plane
function
HEADER COUNTERS ACTIONS
ServicesServices such as load-balancers or firewalls can be FIELDS
implemented with either autonomous or dependentforwarding decision making capabilities. Examples
would include a virtual-autonomous appliance likethe ASAPacket in Parsing
1000v,
from or a virtual-dependent
header appliance such as
network fields
an Open Virtual Switch (OVS) with acentralized firewall controller. Autonomous stateful service
appliances inspect and maintain statemachines for traffic flows at each device, where as dependent service
appliances employ a centralizedcontrol device to externally control the service behavior
Notify
controller about
packet using
Overlay NetworksTenant segmentation can be provided by conventional means suchPACKET-
as VLANs,
INmessage
or an
overlay method such
as VXLANs. As outlined previously, an overlay network within a SDN environment is a construct forthe
creation of logical networks that can be leveraged by edge devices and appliances. Tenantsegmentation
based on VLANs is normally considered a characteristic of a non-SDN systems, whileoverlay networks are
considered a key component of an SDN-based solution.
The OpenFlow ProtocolThe OpenFlow protocol is the most commonly used protocol for the southbound
interface of SDN,
which separates the data plane from the control plane. The white paper about OpenFlow points out the
advantages of a flexibly configurable forwarding plane. OpenFlow was initially proposed by Stanford
University,
OverviewThe OpenFlow architecture consists of three basic concepts. (1) The network is built up
byOpenFlow-compliant switches that compose the data plane; (2) the control plane consists of one ormore
OpenFlow controllers; (3) a secure control channel connects the switches with the control plane.
In the following, we discuss OpenFlow switches and controllers and the interactions among themThe
header fields can match different protocols depending on the OpenFlow specification, e.g., Ethernet, IPv4,
IPv6 or MPLS. The ―counters‖ are reserved for collecting statisticsabout flows.
They store the number of received packets and bytes, as well as the duration of the flow.
The ―actions‖ specify how packets of that flow are handled. Common actions are ―forward‖, ―drop‖,
―modify field‖, etc.

A software program, called the controller, is FIELDS
responsible for populating and manipulating the
flowtables of the switches. By insertion, modification and removal of flow entries, the controller canmodify
the behavior of the switches with regard to forwarding. The OpenFlow specification defines the protocol
that enables the controller to instruct the switches. To that end, the controller uses a secure control channel
Three classes of communication exist in the OpenFlow protocol: controller-to-switch, asynchronousand
symmetric communication. The controller-to-switch communication is responsible for feature
detection,configuration, programming the switch and information retrieval. Asynchronous communication
is initiated by the OpenFlow-compliant switch without any solicitation from the controller
Match Perform
against
tables actions
on packet
The basic packet forwarding mechanism with OpenFlow is illustrated in Figure 3. When a switch receives a
packet, it parses the packet header, which is matched against the flow table. If a flow table entry is found
where the header field wildcard matches the header, the entry is considered. If several
such entries are found, packets are matched based on prioritization, i.e., the most specific entry or the
wildcard with the highest priority is selected
OpenFlow SpecificationsWe now review the different OpenFlow specifications by highlighting the
supported operationsand the changes compared to their previous major version and summarize the features
of thedifferent versions. Finally, we briefly describe the OpenFlow Configuration and Management
ProtocolOF-CONFIG protocol, which adds configuration and management support to OpenFlow switches
OpenFlow 1.0The OpenFlow 1.0 specification was released in December, 2009. As of this writing, it is the
mostcommonly deployed version of OpenFlow. Ethernet and IP packets can be
matched based on the sourceand destination address. In addition, Ethernet-type and VLAN fields can be
matched for Ethernet, thedifferentiated services (DS) and Explicit Congestion Notification (ECN) fields,
and the protocol field canbe matched for IP. Moreover, matching on TCP or UDP source and destination
port numbers is possible
OpenFlow 1.1OpenFlow 1.1 was released in February, 2011. It contains significant changes compared
toOpenFlow 1.0. Packet processing works differently now. Packets are processed by a pipeline of
multipleflow tables. Two major changes are introduced: a pipeline of multiple flow tables and a group
table.

OpenFlow 1.2OpenFlow 1.2 was released in
FIELDS
December, 2011. It comes with extended protocol
support, inparticular for IPv6. OpenFlow 1.2 can match IPv6 source and destination addresses, protocol
number,flow label, traffic class and various ICMPv6 fields. Vendors have new possibilities to extend
OpenFlowby themselves to support additional matching capabilities.
A type-length-value (TLV) structure, which iscalled OpenFlow Extensible Match (OXM), allows one to
define new match entries in an extensible way
OpenFlow 1.3OpenFlow 1.3 introduces new features for monitoring and operations and management
(OAM).
To that end, the meter table is added to the switch architecture. A meter is directly attached to a flow table
entry by its meter identifier and measures therate of packets assigned to it
Meter Meter Bands COUNTERS

Identifier OpenFlow 1.4OpenFlow 1.4 was released in October
2013. The ONF improved the support for the
OpenFlowExtensible Match (OXM).
TLV structures for ports, tables and queues are added to the protocol,and hard-coded parts from earlier
specifications are now replaced by the new TLV structures.
Theconfiguration of optical ports is now possible. In addition, controllers can send control messages ina
single message bundle to switches
SDN ControllersThe SDN Controller is a logically centralized entity in charge of (i) translating the
requirements from the SDN Application layer down to theSDN Datapathsand (ii) providing the SDN
Applications with an abstract view of the network (which may include statistics and events). An SDN
Controller consists of one or more NBI Agents, the SDN Control Logic, and the Control to Data-Plane
Interface (CDPI) driver.
Definition as a logically centralized entity neither prescribes nor precludes implementation details such as
the federation of multiple controllers, the hierarchical connection of controllers, communication interfaces
between controllers, nor virtualization or slicing of network resources.
SDN ApplicationSDN Applications are programs that explicitly, directly, and programmatically
communicate their network requirements and desired network behavior to the SDN Controller via a
northbound interface (NBI). In addition they may consume an abstracted view of the network for their
internal decision-making purposes.
An SDN Application consists of one SDN Application Logic and one or more NBI Drivers. SDN
Applications may themselves expose another layer of abstracted network control, thus offering one or more
higher-level NBIs through respective NBI agent
SDN DatapathThe SDN Datapath is a logical network device that exposes visibility and uncontested
control over its advertised forwarding and data processing capabilities. The logical representation may
encompass all or a subset of the physical substrate resources.
An SDN Datapath comprises a CDPI agent and a set of one or more traffic forwarding engines and zero or
more traffic processing functions. These engines and functions may include simple forwarding between the
datapath's external interfaces or internal traffic processing or termination functions.
One or more SDN Datapaths may be contained in a single (physical) network element—an integrated
physical combination of communications resources, managed as a unit. An SDN Datapath may also be
defined across multiple physical network elements.
This logical definition neither prescribes nor precludes implementation details such as the logical to
physical mapping, management of shared physical resources, virtualization or slicing of the SDN Datapath,
interoperability with non-SDNnetworking, nor the data processing functionality, which can include OSI
layer
DN Control to Data-Plane Interface (CDPI)The SDN CDPI is the interface defined between an SDN
Controller and an SDN Datapath, which provides at least (i) programmatic control of all forwarding
operations, (ii) capabilities advertisement, (iii) statistics reporting, and (iv) event notification. One value of
SDN lies in the expectation that the CDPI is implemented in an open, vendor-neutral and interoperable
way.
SDN Northbound Interfaces (NBI)SDN NBIs are interfaces between SDN Applications and SDN
Controllers and typically provide abstract network views and enable direct expression of network behavior
and requirements. This may occur at any level of abstraction (latitude) and across different sets of
functionality (longitude). One value of SDN lies in the expectation that these interfaces are implemented in
an open, vendor-neutral and interoperable way
SDN Control Plane

Centralized - Hierarchical – DistributedThe implementation of the SDN control plane can follow a
centralized, hierarchical, or decentralized design. Initial SDN control plane proposals focused on a
centralized solution, where a single control entity has a global view of the network.
While this simplifies the implementation of the control logic, it has scalability limitations as the size and
dynamics of the network increase. To overcome these limitations, several approaches have been proposed
in the literature that fall into two categories, hierarchical and fully distributed approaches. In hierarchical
solutions
Controller PlacementA key issue when designing a distributed SDN control plane is to decide on the
number and placement of control entities.
An important parameter to consider while doing so is the propagation delay between the controllers and the
network devices,especially in the context of large networks. Other objectives that have been considered
involve control path reliability,fault tolerance, and application requirements
SDN flow forwarding (sdn)

Proactive vs Reactive vs Hybrid OpenFlow uses TCAM tables to route packet sequences (flows). If flows
arrive at a switch, a flow table lookup is performed.
Depending on the flow table implementation this is done in a software flow table if a vSwitch is used or in
an ASIC if it's implemented in hardware. In the case when no matching flow is found a request to the
controller for further instructions is sent.
This is handled in one of three different modes. In reactive mode the controller acts after these requests and
creates and installs a rule in the flow table for the corresponding packet if necessary.
SDMNSoftware-defined mobile networking (SDMN) is an approach to the design of mobile networks

where all protocol-specific features are implemented in software, maximizing the use ofgeneric and
commodity hardware and software inboth the core network and radio access network.[40] It is proposed as
an extension of SDN paradigm to incorporate mobile network specific functionalities.
SD-WANAn SD-WAN is a Wide Area Network (WAN) managed using the principles of software-defined
networking.
The main driver of SD-WAN is to lower WAN costs using more affordable and commercially available
leased lines, as an alternative or partial replacement of more expensive MPLS lines. Control and
management is administered separately from the hardware with central controllers allowing for easier
configuration and administration.
General ConceptsSoftware-Defined Networking (SDN) is an idea which has recently reignited theinterest
of network researchers for programmable networks and shifted the attentionof the networking community
to this topic by promising to make the process ofdesigning and managing networks more innovative and
simplified compared to thewell-established but inflexible current approach
The separation of the logically centralized control from the underlying data plane has quickly become the
focus of vivid research interest in the networking community since it greatly simplifies network
management and evolution in a number of ways
SDN History and EvolutionWhile the term programmable is used to generalize the concept of the
simplified network management and reconfiguration, it is important to understand that in reality it
encapsulates a wide number of ideas proposed over time, each having a different focus (e.g., control- or
data-plane programmability) and different means of achieving their goals.
Early History of Programmable NetworksAs already mentioned, the concept of programmable networks
dates its originsback in the mid-90s, right when the Internet was starting to experience widespreadsuccess.
Until that moment the usage of computer networks was limited to a smallnumber of services like e-mail
and file transfers
Two of the most significant early ideas proposing ways of separating the controlsoftware from the
underlying hardware and providing open interfaces for managementand control were of the Open Signaling
(OpenSig) working group and from theActive Networking initiative
OpenSig - The Open Signaling working group appeared in 1995 and focused on applying the concept of
programmability in ATM networks. The main idea was the separation of the control and data plane of
networks, with the signaling between the planes performed through an open interface
Active Networking The Active Networking initiative appeared in the mid-90s and was mainly supported
by DARPA . Like OpenSig, its main goal was the creation of programmable networks which would
promote network innovations.
The main idea behind active networking is that resources of network nodes are exposed through a network
API, allowing network operators to actively control the nodes as they desire by executing arbitrary code
Virtual LANs (VLANs) and VTPCollision vs. Broadcast DomainsA collision domain is simply defined
as any physical segment where acollision can occur. Hubs can only operate at half-duplex, and thus all
portson a hub belong to the same collision domain.
Layer-2 switches can operate at full duplex. Each individual port on a switchbelongs to its own collision
domain. Thus, Layer-2 switches create morecollision domains, which results in fewer collisions.Like hubs
though, Layer-2 switches belong to only one broadcast domain.
A Layer-2 switch will forward both broadcasts and multicasts out every portbut the originating port
Only Layer-3 devices separate broadcast domains. Because of this, Layer-2 switches are poorly suited for
large, scalable networks.
The Layer-2 header provides no mechanism to differentiate one network from another, only one host from
another
Virtual LANs (VLANs)By default, a switch will forward both broadcasts and multicasts out everyport but
the originating port. However, a switch can be logically segmentedinto separate broadcast domains, using
Virtual LANs (or VLANs).
Each VLAN represents a unique broadcast domain:
• Traffic between devices within the same VLAN is switched.
• Traffic between devices in different VLANs requires a Layer-3 device to communicate

Broadcasts from one VLAN will not be forwarded to another VLAN. The logical separation provided by
VLANs is not a Layer-3 function. VLAN tags are inserted into the Layer-2 header.
Thus, a switch that supports VLANs is not necessarily a Layer-3 switch. However, a purely Layer-2 switch
cannot route between VLANs
Advantages of VLANs
VLANs provide the several benefits:
Broadcast Control – eliminates unnecessary broadcast traffic,

improving network performance and scalability.
Security – logically separates users and departments, allowing

administrators to implement access-lists to control traffic between
VLANs.
Flexibility – removes the physical boundaries of a network, allowinga user or device to exist anywhere.
VLANs are very common in LAN and campus networks. For example, usernetworks are often separated
from server networks using VLANs.
VLANs can span across WANs as well, though there are only limitedscenarios where this is necessary or
recommended.
VLAN Membership
VLAN membership can be configured one of two ways:

• Statically
• Dynamically
Statically assigning a VLAN involves manually assigning an individual orgroup of ports to a VLAN. Any
host connected to that port (or ports)immediately becomes a member of that VLAN. This is transparent to
thehost - it is unaware that it belongs to a VLAN.
VLANs can be assigned dynamically based on the MAC address of thehost. This allows a host to remain in
the same VLAN, regardless of whichswitch port it is connected to.
Dynamic VLAN assignment requires a separate database to maintain the
MAC-address-to-VLAN relationship. Cisco developed the VLANMembership Policy Server (VMPS) to

provide this functionality.In more sophisticated systems, a user‘s network account can be used todetermine
VLAN membership, instead of a host‘s MAC address.Static VLAN assignment is far more common than
dynamic, and will be thefocus of this guide.
Creating VLANsBy default, all interfaces belong to VLAN 1. To assign an interface to adifferent VLAN,
that VLAN must first be created:
Switch(config)# vlan 100

Switch(config-vlan)# name SERVERS
The first command creates VLAN 100, and enters VLAN configurationmode. The second command
assigns the name SERVERS to this VLAN.
Note that naming a VLAN is not required.
The standard range of VLAN numbers is 1 – 1005, with VLANs 1002-1005reserved for legacy Token Ring
and FDDI purposes.
A switch operating in VTP transparent mode can additionally use theVLAN range of 1006 – 4094. These
are known as extended-range VLANs.
VTP is covered in great detail later in this guide.
To remove an individual VLAN:

Switch(config)# no vlan 100
Note that VLAN 1 cannot be removed. To remove a group of VLANs
Statically Assigning VLANs

To statically assign an interface into a specific VLAN:
Switch(config)# interface gi1/10
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 100
The first command enters interface configuration mode. The secondcommand indicates that this is an
access port, as opposed to a trunk port.This will be explained in detail shortly
VLAN Port TypesA VLAN-enabled switch supports two types of ports:

• Access ports
• Trunk ports
An access port is a member of only a single VLAN. Access ports are mostoften used to connect host
devices, such as computers and printers. Bydefault on Cisco switches, all switch ports are access ports
Trunk portA trunk port is not a member of a single VLAN. The traffic from any or all
VLANs can traverse trunk links to reach other switches.
Uplinking access ports quickly becomes unfeasible in large switchingenvironments. The following
illustrates the advantage of using trunk ports
VLAN Frame-TaggingWhen VLANs span multiple switches, a mechanism is required to identifywhich

VLAN a frame belongs to. This is accomplished through frametagging, which places a VLAN ID in each
frame
Frame Tagging ProtocolsCisco switches support two frame tagging protocols:

• Inter-Switch Link (ISL)
• IEEE 802.1Q
The tagging protocol can be manually specified on a trunk port, ordynamically negotiated using Cisco‘s
proprietary Dynamic TrunkingProtocol (DTP).
Inter-Switch Link (ISL)Inter-Switch Link (ISL) is Cisco‘s proprietary frame tagging protocol. ISL
supports several technologies:
• Ethernet
• Token Ring
• FDDI
• ATM
ISL encapsulates a frame with an additional header (26 bytes) and trailer (4bytes). Thus, ISL increases the
size of a frame by 30 bytes.
The header contains several fields, including a 15-bit VLAN ID. The trailercontains an additional 4-byte
CRC to verify data integrity.Normally, the maximum possible size of an Ethernet frame is 1518 bytes.
This is known as the Maximum Transmission Unit (MTU). Most Ethernetdevices use a default MTU of
1514 bytes.
ISL increases the frame size by another 30 bytes. Thus, most switches willdisregard ISL-tagged frames as
being oversized, and drop the frame. Anoversized frame is usually referred to as a giant. Somewhat
endearingly, aslightly oversized frame is known as a baby giant.
NVGRE Network Virtualization using Generic Routing Encapsulation (NVGRE) is a network

virtualization technology that attempts to alleviate the scalability problems associated with large cloud
computing deployments. It uses Generic Routing Encapsulation (GRE) to tunnel layer 2 packets over layer
3 networks. NVGRE is described in the IETF RFC 7637.Its principal backer is Microsoft
Network Virtualization using GRENetwork virtualization involves creating virtual Layer 2 and/orLayer 3
topologies on top of an arbitrary physical Layer 2/Layer 3network. Connectivity in the virtual topology is
provided bytunneling Ethernet frames in IP over the physical network.
Virtualbroadcast domains are realized as multicast distribution trees. Themulticast distribution trees are
analogous to the VLAN broadcastdomains. A virtual Layer 2 network can span multiple physicalsubnets.
Support for bi-directional IP unicast and multicastconnectivity is the only expectation from the underlying
physical network.
If the operator chooses to support broadcast and multicasttraffic in the virtual topology the physical
topology must supportIP multicast. The physical network, for example, can be a conventional hierarchical
3-tier network, a full bisection bandwidthClos network or a large Layer 2 network with or without
TRILLsupport
NVGRE EndpointNVGRE endpoints are gateways between the virtual and the physicalnetworks. Any
physical server or network device can be a NVGREendpoint. One common deployment is for the endpoint
to be part of ahypervisor.
The primary function of this endpoint is to encapsulate/decapsulate Ethernet data frames to and from the
GREtunnel, ensure Layer-2 semantics, and apply isolation policy scopedon TNI.
The endpoint can optionally participate in routing andfunction as a gateway in the virtual subnet space. To
encapsulate an Ethernet frame, the endpoint needs to know location information forthe destination address
in the frame
Network virtualization frame formatGRE encapsulation as specified in RFC 2784 and RFC 2890 is used
forcommunication between NVGRE endpoints. The Key extension to GREspecified in RFC 2890 is used to
carry the TNI. The packet formatfor Layer-2 encapsulation
Broadcast and Multicast TrafficThe following discussion applies if the network operator chooses
tosupport broadcast and multicast traffic. Each virtual subnet is assigned an administratively scoped
multicast address to carry broadcast and multicast traffic.
All traffic originating from within a TNI is encapsulated and sent to the assigned multicast address. Asan
example, the addresses can be derived from a administrativelyscoped multicast address as specified in RFC
2365 for IPv4(organization Local Scope 239.192.0.0/14), or an Organization-Localscope multicast address
for IPv6 as specified in RFC 4291.
Thisprovides a wide range of address choices. Purely from an efficiency standpoint for every multicast
address that a tenant uses thenetwork operator may configure a corresponding multicast address inthe PA
space.
To support broadcast and multicast traffic in the virtual topology the physical topology must support IP
multicast.Depending on the hardware capabilities of the physical networkdevices multiple virtual broadcast
domains may be assigned the samephysical IP multicast address
Unicast TrafficThe NVGRE endpoint encapsulates a Layer-2 packet in GRE using thesource PA
associated with the endpoint with the destination PAcorresponding to the location of the destination
endpoint.
As outlined earlier there can be one or more PAs associated with anendpoint and policy will control which
ones get used forcommunication.
The encapsulated GRE packet is bridged and routednormally by the physical network to the destination.
Bridging usesthe outer Ethernet encapsulation for scope on the LAN.
The onlyassumption is bi-directional IP connectivity from the underlying physical network. On the
destination the NVGRE endpoint decapsulates the GRE packet to recover the original Layer-2 frame.
Traffic flows similarly on the reverse path
IP FragmentationRFC 2003 section 5.1 specifies mechanisms for handling fragmentationwhen
encapsulating IP within IP. The subset of mechanisms NVGREselects are intended to ensure that NVGRE
encapsulated frames arenot fragmented after encapsulation en-route to the destination NVGREendpoint,
and that traffic sources can leverage
Path MTU discovery. A future version of this draft will clarify the details around setting the DF bit on the
outer IP header as well as maintaining perdestination NVGRE endpoint MTU soft state so that ICMP
Datagram TooBig messages can be exploited
Address/Policy Management & RoutingAddress acquisition is beyond the scope of this document and
can beobtained statically, dynamically or using stateless address auto configuration. CA and PA space can
be either IPv4 or IPv6.
In factthe address families don't have to match, for example, CA can beIPv4 while PA is IPv6 and vice
versa. The isolation policies MUST beexplicitly configured in the NVGRE endpoint.
A typical policy tableentry consists of CA, MAC address, TNI and optionally, the specificPA if more than
one PA is associated with the NVGRE endpoint.
Ifthere are multiple virtual subnets, explicit routing informationMUST be configured along with a default
gateway for cross-subnetcommunication. Routing between virtual subnets can be optionallyhandled by the
NVGRE endpoint acting as a gateway
Cross-subnet, Cross-premise CommunicationOne application of this framework is that it provides a

seamless path for enterprises looking to expand their virtual machine hosting capabilities into public
clouds.
Enterprises can bring their entire IP subnet(s) and isolation policies, thus making the transition to or from
the cloud simpler. It is possible to move portions of a IPsubnet to the cloud however that requires additional
configurationon the enterprise network and is not discussed in this document
Internet ConnectivityTo enable connectivity to the Internet, an Internet gateway isneeded that bridges the
virtualized CA space to the public Internetaddress space.
The gateway performs translation between thevirtualized world and the Internet, for example, the NVGRE
endpoint can be part of a load balancer or a NAT. Section 4 has morediscussions around building GRE
gateways.
ManageabilityThere are several protocols that can manage and distribute policy;however this document
does not recommend any one mechanism.Implementations SHOULD choose a mechanism that meets their
scale requirements.
Deployment ConsiderationsOne example of a typical deployment consists of virtualized serversdeployed

across multiple racks connected by one or more layers ofLayer-2 switches which in turn may be connected
to a layer 3 routingdomain.
Even though routing in the physical infrastructure will workwithout any modification with GRE, devices
that perform specializedprocessing in the network need to be able to parse GRE to get accessto tenant
specific information. Devices that understand and parsethe TNI can provide rich multi-tenancy aware
services inside
Network Scalability with GREOne of the key benefits of using GRE is the IP address scalabilityand in
turn MAC address table scalability that can be achieved.
NVGRE endpoint can use one PA to represent multiple CAs. This lowersthe burden on the MAC address
table sizes at the Top of Rackswitches. One obvious benefit is in the context of servervirtualization which
has increased the demands on the network infrastructure
Security ConsiderationsThis proposal extends the Layer-2 subnet across the data center andincreases the
scope for spoofing attacks. Mitigations of suchattacks are possible with authentication/encryption using
IPsec orany other IP based mechanism.
The control plane for policydistribution is expected to be secured by using any of the existing security
protocols
Network OverlaysNetwork overlays dramatically increase the number of virtual subnets that can be
created on a physical network, which in turn supports multitenancy and virtualization features such as VM
mobility, and can speed configuration of new or existing services. We‘ll look at how network overlays
work and examine pros and cons.
Now virtualization is forcing broadcast domains to grow, in part to enable features such as VM mobility.
One way to do this is through the use of VLANs. The 802.1q standard defines the VLAN tag as a 12-bit
space, providing for a max of 4,096 VLANs (actual implementation mileage will vary.) This is an easily
reachable ceiling in multitenant environments where multiple internal or external customers will request
multiple subnets
Aiming for FlexibilityA need for flexibility in the data center also opens the door to network overlays.
That is, the data center network needs to be flexible enough to support workloads that can move from one
host to another on short notice, and for new services to be deployed rapidly.
VMs in a data center can migrate across physical servers for a variety of reasons, including a host failure or
the need to distribute workloads. These moves traditionally require identical configuration of all network
devices attached to clustered hosts. There is also a requirement for common configuration of upstream
connecting switches in the form of VLAN trunking, and so on
How It WorksFrom a high-level perspective, all three proposed standards operate in the same way.
Endpoints are assigned to a virtual network via a Virtual Network ID (VNID). These endpoints will belong
to that virtual network regardless of their location on the underlying physical IP network.
Diagram 1 focuses on virtual workloads running in VMs. The same concept would apply if using a physical
switch with the VEP functionality. This would allow physical devices to be connected to the overlay
network as pictured in Diagram 2 below.
With a physical switch capable of acting as the tunnel end-point, you can add both physical servers and
appliances (firewalls, load balancers, and so on) to the overlay. This model is key to a cohesive deployment
in mixed workload environments common in today's data centers.
Encapsulation techniques are not without drawbacks, including overhead, complications with load-
balancing and interoperability issues with devices like firewalls.
The overhead with any overlay can come in two forms: encapsulation overhead of the frame size and
processing overhead on the server from lack of ability to use NIC offload functionality. Both NVGRE and
VXLAN suffer from the second problem due to encapsulating in IP within the soft switch. STT skirts the
processing overhead problem by using a TCP hack to gain Large Segment Offload (LSO) and Large
Receive Offload (LRO) capabilities from the NIC.
Without a granular method of providing flow control, network traffic will bottleneck and lead to congestion
that can be detrimental to the network as a whole. This will be more apparent as traffic scales up and
increases the demand on network pipes.
In Diagram 4 we see all traffic from the VMs on both hosts traversing the same path, even though two are
available. The same would be the case if the links were bonded such as with LACP--one physical link in
the bond would always be used. This problem leaves an available link unused, and can result in
performance problems if traffic overwhelms the one link being used
The last drawback is the challenge with devices such as firewalls. These devices use header information to
enforce policies and rules. Because these devices expect a specific packet format, they may be stymied by
encapsulated frames.
In designs where firewalls sit in the path of encapsulated traffic, administrators will have to configure
specific rules, which may be looser than traditional design.
Network overlays provide for virtualized multitenant networks on shared IP infrastructure. This provides
for a more scalable design, from 4096 virtual networks to 16 million or more.
In addition, a network overlay enables the flexibility and rapid provisioning required by today's business
demands. Using overlays, services can be added, moved and expanded without the need for manual
configuration of the underlying network infrastructure.

Unit V ND

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

Unit V ND

Uploaded by

Copyright:

Available Formats

CP5201 Network Design and Technologies – UNIT V

UNIT V SOFTWARE DEFINED NETWORKS

Limitations of Current Networking TechnologiesMeeting current market requirements is virtually

Software-Defined Network Architecture

OpenFlow-based SDN architecture can integrateseamlessly with an enterprise or carrier‘s existing

Benefits of OpenFlow-Based Software-DefinedNetworks

Overlay NetworksThe use of overlay networking technologies is another common characteristic to a

SDN Solution Taxonomy

HEADER COUNTERS ACTIONS

HEADER COUNTERS ACTIONS

Meter Meter Bands COUNTERS

SDN Control Plane

SDN flow forwarding (sdn)

SDMNSoftware-defined mobile networking (SDMN) is an approach to the design of mobile networks

• Traffic between devices in different VLANs requires a Layer-3 device to communicate

Broadcast Control – eliminates unnecessary broadcast traffic,

Security – logically separates users and departments, allowing

VLAN membership can be configured one of two ways:

MAC-address-to-VLAN relationship. Cisco developed the VLANMembership Policy Server (VMPS) to

Switch(config)# vlan 100

To remove an individual VLAN:

Statically Assigning VLANs

VLAN Port TypesA VLAN-enabled switch supports two types of ports:

VLAN Frame-TaggingWhen VLANs span multiple switches, a mechanism is required to identifywhich

Frame Tagging ProtocolsCisco switches support two frame tagging protocols:

NVGRE Network Virtualization using Generic Routing Encapsulation (NVGRE) is a network

Cross-subnet, Cross-premise CommunicationOne application of this framework is that it provides a

Deployment ConsiderationsOne example of a typical deployment consists of virtualized serversdeployed

You might also like