Project report 6

1. PROJECT REPORT
SEMESTER - VI
Submitted to:
BHARATI VIDYAPEETH UNIVERSITY
Amplify DITM, Pune
Submitted by:
Akash Raj guru, B.Sc. IT III year
BVU Amplify DITM, Pune

2. “Software Defined Networking”
By
AKASH RAJGURU
A PROJECT REPORT
Submitted to
BHARATI VIDYAPEETH UNIVERSITY
In partial fulfillment of the requirement
For the award of the
BACHELOR OF SCIENCE
In
INFORMATION TECHNOLOGY
BHARATI VIDYAPEETH UNIVERSITY
Amplify DITM, Pune
April-2014

3. BONOFIDECERTIFICATE
Certified that this project report titled “Software Defined Networking”
is the bonafide work of Mr.Akash Rajguru who carried out the research
under my supervision. Certified further ,that the best of my knowledge
the work reported herein does not form part of any other project
report or dissertation on the basis of which a degree or award was
conferred on an earlier occasion on this or any other candidate.
Date: project guide
Prashant Hinduja
Place:

4. TABLEOFCONTENTS
Chapter 1: Software Define Networking 1
 Introduction 1
 What is SDN? 1
 The need for a new Network Architecture 2
 Limitation of current Network technology 3
 SDN Architecture 6
 SDN Implementation 9
 Benefits of SDN 10
 SDN myths 11
Chapter 2:OpenFlow 15
 Introduction 15
 What is openflow? 15
 Inside openflow 15
 Benefits of openflow based SDN 17
Chapter 3: SDN Controller 20
 Introduction 20
 What are SDN controllers 21
Chapter 4: openvSwitch 23
 Introduction 23
 Supported platform 24
 Features 25
Chapter 5: MININET 27
 Introduction 27
 What is mininet? 27
 Mininet simple workflow 27
 Mininet tool for exploring openflow and SDN 31
 MODULE 1: manually entering flow entry into openvSwitch in mininet 37

5. Chapter 6: Floodlight Controller 44
 Introduction 44
 Features highlights 44
 Floodlight controller applications 45
Chapter 7: Avior 1.3 48
 Introduction 48
 Controller Overview 48
 Switch Overview 49
 Device Overview 49
 Flow Manager 50
 MODULE 2: Providing static flow using avior 1.3 51
Chapter 8: Visual Network Description 62
 Introduction 62
 Features 62
 MODULE 3: creating custom topology(mesh) using VND 63
Chapter 9: References 71

6. ACKNOWLEGEMENT
The final projecthas been vary memorableand unique experience for me. It
opened up a new venue of grabbing knowledge which will certainly stand me
helpful in the years to come.
I am very thankfulto my projectguide Mr. PrashantHinduja(HOD IT) for giving me
opportunity to do projectthrough my courseof B.Sc. ITand for the excellence
guidance for the projectwork and explaining the importance of projectwork in
my life and for my career helping me in designing to projectwork.
My sincerely thanks to Mr. PrashantHinduja sir(Projectguide) for his valuable
support and making my projectsuccessfully and sincerethanks to Mr.
S.Subramaniamsir for the project idea.

7. 1 | P a g e
CHAPTER 1: SOFTWAREDEFINE NETWORKING
INTRODUCTION
Software Defined Networking (SDN) is an emerging network architecture
where network control is decoupled from forwarding and is directly
programmable.This migration of control, formerly tightly bound in individual
network devices, into accessible computing devices enables the underlying
infrastructure to be abstracted for applications and network services, which
can treat the network as a logical or virtual entity.
SDN allows network administrators to manage network services through
abstraction of lower level functionality. This is done by decoupling the
system that makes decisions about where traffic is sent (the control plane)
from the underlying systems that forward traffic to the selected destination
(the data plane).
Control Plane :- In routing, the control plane is the part of the router architecture
that is concerned with drawing the network map, or the information in a routing
table that defines what to do with incoming packets. Controlplane functions,
such as participating in routing protocols, run in the architectural control element
Data Plane:- In routing, the forwarding plane, sometimes called the data plane, defines the
part of the router architecture that decides what to do with packets arriving on an inbound
interface. Most commonly, it refers to a table in which the router looks up the destination
address of the incoming packet and retrieves the information necessary to determine the path
from the receiving element, through the internal forwarding fabric of the router, and to the proper
outgoing interface
W HAT I S S DN?
The physical separation of the network control plane from the
forwarding plane, and where a control plane controls several
devices

8. 2 | P a g e
THE NEED FOR A NEW NETWORK ARCHITECTURE
The explosion of mobile devices and content, server virtualization, and adventof
cloud services areamong the trends driving the networking industry to reexamine
traditional network architectures. Many conventionalnetworks arehierarchical,
built with tiers of Ethernet switches arranged in a tree structure. This design made
sensewhen client-server computing was dominant, but such a static architecture
is ill-suited to the dynamic computing and storageneeds of today’s enterprise
data centers, campuses, and carrier environments. Someof the key computing
trends driving the need for a new network paradigm include:
•Changing traffic patterns: Within the enterprisedata center, traffic patterns
have changed significantly. In contrastto client-server applications where the bulk
of the communication occurs between one client and one server, today’s
applications access differentdatabases 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. At the sametime, users are changing
network traffic patterns as they push for access to corporatecontent and
applications fromany type of device (including their own), connecting from
anywhere, at any time. Finally, many enterprisedata centers managers are
contemplating a utility computing model, which might include a private cloud,
public cloud, or some mix of both, resulting in additional traffic across thewide
area network.
•The “consumerizationof IT”: Users are increasingly employing mobile personal
devices such as smartphones, tablets, and notebooks to access the corporate
network. ITis under pressureto accommodate these personaldevices in a fine-
grained manner while protecting corporate data and intellectual property and
meeting compliance mandates.
• The rise of cloud services: Enterprises haveenthusiastically embraced both
public and private cloud services, resulting in unprecedented growth of these
services. Enterprisebusiness units now wantthe agility to access applications,
infrastructure, and other ITresources on demand and à la carte. To add to the

9. 3 | P a g e
complexity, IT’s planning for cloud services mustbe done in an environmentof
increased security, compliance, and auditing requirements, along with business
reorganizations, consolidations, and mergers thatcan change assumptions
overnight. Providing self-serviceprovisioning, whether in a private or public cloud,
requires elastic scaling of computing, storage, and network resources, ideally
froma common viewpointand with a common suite of tools.
• “Big data” means more bandwidth: Handling today’s “big data” or mega
datasets requires massiveparallel processing on thousands of servers, allof which
need direct connections to each other. The riseof mega datasets is fueling a
constantdemand for additional network capacity in the data center. Operators of
hyper scale data center networks facethe daunting task of scaling the network to
previously unimaginablesize, maintaining any-to-any connectivity without going
broke.
LIMITATIONS OF CURRENT NETWORKING TECHNOLOGIES
Meeting current market requirements is virtually impossible with traditional
network architectures. Faced with flat or reduced budgets, enterprise IT
departments aretrying to squeezethe mostfromtheir networksusingdevice-level
management tools and manual processes. Carriers face similar challenges as
demand for mobility and bandwidth explodes; profits are being eroded by
escalating capital equipment costs and flat or declining revenue.
Existing network architectures were not designed to meet the requirements of
today’s users, enterprises, and carriers; rather network designers are constrained
by the limitations of currentnetworks, which include:

10. 4 | P a g e
• Complexity that leads to stasis: Networking technology to date has consisted
largely ofdiscretesets ofprotocolsdesigned to connecthostsreliably overarbitrary
distances, link speeds, and topologies. To meet business and technical needs over
the last few decades, the industry has evolved networking protocols to deliver
higher performance and reliability, broader connectivity, and more stringent
security.
Protocols tend to be defined in isolation, however, with each solving a specific
problem and without the benefit of any fundamental abstractions. This has
resulted in one of the primary limitations of today’s networks: complexity. For
example, to add or move any device, IT must touch multiple switches, routers,
firewalls, Web authentication portals, etc. and update ACLs, VLANs, quality of
services (QoS), and other protocol-based mechanisms using device-level
management tools. In addition, network topology, vendor switch model, and
softwareversion all must be taken into account. Due to this complexity, today’s
networksarerelatively static as ITseeksto minimize the riskof servicedisruption.
The static natureof networksisin starkcontrastto the dynamic natureof today’s
server environment, where server virtualization has greatly increased the
number of hosts requiring network connectivity and fundamentally altered
assumptions about the physical location of hosts. Prior to virtualization,
applications residedon a singleserverandprimarily exchanged trafficwith select
clients. Today, applications are distributed across multiple virtual machines
(VMs), which exchange traffic flows with each other. VMs migrate to optimize
and rebalanceserverworkloads,causingthephysicalend pointsof existing flows
to change(sometimesrapidly) overtime. VM migration challenges many aspects
of traditionalnetworking,fromaddressingschemesandnamespacesto thebasic
notion of a segmented, routing-based design.
In addition to adopting virtualization technologies, many enterprises today
operatean IPconvergednetworkforvoice, data, and video traffic. While existing
networks can provide differentiated QoS levels for different applications, the
provisioningofthoseresourcesishighly manual. ITmustconfigureeach vendor’s
equipment separately, and adjust parameters such as network bandwidth and
QoS on a per-session, per-application basis. Because of its static nature, the
network cannot dynamically adapt to changing traffic, application, and user
demands.

11. 5 | P a g e
• Inconsistent policies: To implement a network-wide policy, IT may have to
configure thousands of devices and mechanisms. For example, every time a new
virtual machine is brought up, it can take hours, in some cases days, for IT to
reconfigure ACLs across the entire network. The complexity of today’s networks
makes it very difficult for ITto apply a consistent set of access, security, QoS, and
other policies to increasingly mobile users, which leaves the enterprise vulnerable
to security breaches, non-compliance with regulations, and other negative
consequences.
 Inability toscale: As demands on the data center rapidly grow, so too must
the network grow. However, thenetwork becomes vastly more complex
with the addition of hundreds or thousands of network devices that must
be configured and managed. IThas also relied on link oversubscription to
scale the network, based on predictable traffic patterns; however, in
today’s virtualized data centers, traffic patterns are incredibly dynamic and
therefore unpredictable.
Mega-operators, such as Google, Yahoo!, and Facebook, face even more
daunting scalability challenges. These service providers employ large-scale
parallel processing algorithms and associated datasets across their entire
computing pool. As the scope of end-user applications increases (for example,
crawling and indexing the entire world wide web to instantly return search
results to users), the number of computing elements explodes and data-set
exchanges among compute nodes can reach petabytes. These companies need
so-called hyperscalenetworks thatcan providehigh-performance, low-cost
connectivity among hundreds of thousands—potentially millions—of physical
servers. Such scaling cannotbe done with manual configuration.
To stay competitive, carriers mustdeliver ever-higher value, better-
differentiated services to customers. Multi-tenancy further complicates their
task, as the network mustservegroups of users with different applications and
different performanceneeds. Key operations that appear relatively
straightforward, such as steering a customer’s traffic flows to provide
customized performancecontrolor on-demand delivery, are very complex to
implement with existing networks, especially at carrier scale. They require

12. 6 | P a g e
specialized devices at the network edge, thus increasing capital and operational
expenditure as well as time-to-market to introduce new services.
• Vendor dependence: Carriers and enterprises seek to deploy new
capabilities and services in rapid responseto changing business needs or
user demands. However, their ability to respond is hindered by vendors’
equipment productcycles, which can range to three years or more. Lack of
standard, open interfaces limits the ability of network operators to tailor the
network to their individual environments.
This mismatch between marketrequirements and network capabilities has
broughtthe industry to a tipping point. In response, theindustry has created the
Software-Defined Networking (SDN) architectureand is developing associated
standards
SDN ARCHITECTURE
Software-Defined Networking (SDN) is an emerging architecture that is dynamic,
manageable, cost-effective, and adaptable, making it ideal for the high-
bandwidth, dynamic nature of today's applications. This architecture decouples
the network controland forwarding functions enabling the network control to
become directly programmableand the underlying infrastructureto be
abstracted for applications and network services. The OpenFlow protocolis a
foundational element for building SDN solutions. The SDNarchitecture is:
 Directly programmable: Network controlis directly programmablebecause it is
decoupled fromforwarding functions.
 Agile: Abstracting controlfromforwarding lets administrators dynamically
adjustnetwork-widetraffic flow to meet changing needs.
 Centrally managed: Network intelligence is (logically) centralized in software-
based SDN controllers that maintain a global view of the network, which
appears to applications and policy engines as a single, logical switch.
 Programmatically configured: SDNlets network managers configure, manage,
secure, and optimize network resources very quickly via dynamic, automated

13. 7 | P a g e
SDNprograms, which they can write themselves because the programs do not
depend on proprietary software.
 Open standards-based andvendor-neutral: When implemented through open
standards, SDNsimplifies network design and operation becauseinstructions
are provided by SDN controllers instead of multiple, vendor-specific devices
and protocols.
AboveFigure: depicts a logical view of the SDN architecture. Network intelligence
is (logically) centralized in software-based SDNcontrollers, which maintain a
global view of the network. As a result, the network appears to the applications
and policy engines as a single, logical switch. With SDN, enterprises and carriers
gain vendor-independentcontrol over the entire network froma single logical
point, which greatly simplifies the network design and operation. SDNalso greatly
simplifies the network devices themselves, sincethey no longer need to

14. 8 | P a g e
understand and process thousands of protocolstandards butmerely accept
instructions fromthe SDN controllers.
Perhaps mostimportantly, network operators and administrators can
programmatically configurethis simplified network abstraction rather than having
to hand-codetens of thousands of lines of configuration scattered among
thousands of devices. In addition, leveraging the SDNcontroller’s centralized
intelligence, ITcan alter network behavior in real-time and deploy new
applications and network services in a matter of hours or days, rather than the
weeks or months needed today. By centralizing network state in the control layer,
SDNgives network managers the flexibility to configure, manage, secure, and
optimize network resources via dynamic, automated SDN programs. Moreover,
they can write these programs themselves and not wait for features to be
embedded in vendors’ proprietary and closed softwareenvironments in the
middle of the network.
In addition to abstracting the network, SDNarchitectures supporta set of APIs
that make it possibleto implement common network services, including routing,
multicast, security, access control, bandwidth management, traffic engineering,
quality of service, processor and storageoptimization, energy usage, and all forms
of policy management, custom tailored to meet business objectives. For example,
an SDNarchitecture makes it easy to define and enforce consistentpolicies across
both wired and wireless connections on a campus.
Likewise, SDNmakes it possibleto manage the entire network through intelligent
orchestration and provisioning systems. TheOpen Networking Foundation is
studying open APIs to promotemulti-vendor management, which opens the door
for on-demand resourceallocation, self-serviceprovisioning, truly virtualized
networking, and securecloud services.
Thus, with open APIs between the SDN controland applications layers, business
applications can operate on an abstraction of the network, leveraging network
services and capabilities without being tied to the details of their implementation.
SDNmakes the network not so much “application-aware” as “application-
customized” and applications not so much “network-aware” as “network-
capability-aware”. As a result, computing, storage, and network resources can be
optimized.

15. 9 | P a g e
SDN IMPLEMENTATION
SDN isimplementedatGoogle’sdatacenter, Letlook
Inter-Datacenter WAN with centralized TE
using SDN and OpenFlow
Background
Google offers many different services - Google Web Search, Google+, Gmail,
YouTube, and Google Maps - that are core to Google’s mission to organizethe
world’s information and make it universally accessibleand useful. In order to
servea global user basewith speed and high availability, large volumes of data
need to be moved fromone region to another making these applications/services
very WAN-intensive.
When we look at the management, cost and performanceof infrastructure,
economies of scale have worked out well for storageand compute components
but not necessarily for the WAN. This is for a variety of reasons such as non-linear
complexity and interaction of networking devices, manual configuration and
management and non-standard vendor configuration APIs. Werequirea WAN
whereeconomies of scale deliver cost efficiency, higher performance, better fault
tolerance and manageability. We need to manage the WANas a fabric and not as
a collection of individual boxes.
Overview of Google’s SDNsolution
Google’s WAN is organized as two backbones – an Internetfacing (I-scale)
network that carries user traffic and an internal (G-scale) network that carries
traffic between datacenters. These two backbones havevery different
requirements and traffic characteristics. Itis the G-scalenetwork in which Google
has deployed an OpenFlow powered SoftwareDefined Networking (SDN)
solution. When Google started this effortthere was no network device available
that had OpenFlow supportand could meet our scale requirements - so Google
built its own network switch frommerchant silicon and open sourcerouting
tacks with OpenFlow support. Thelist of features developed was minimal but
sufficient for Google’s use case.

16. 10 | P a g e
Each site is comprised of multiple switch chassis to providescalability (multiple
terabits of bandwidth) and fault tolerance. Sites are connected together and
multiple OpenFlow controllers communicate with the switches using OpenFlow.
Multiple controllers ensure that there is no single point of failure.
On this WAN fabric we built a centralized traffic engineering (TE) service. The
servicecollects real-time utilization metrics and topology data fromthe
underlying network and bandwidth demand fromapplications/services. With this
data, it computes the path assignments for traffic flows and then programs the
paths into the switches using OpenFlow. In the case of changing demand or
network events, the servicere-computes path assignments and reprograms the
switches.
We have the above SDNsolution deployed in the G-scaleWAN today where it is
serving datacenter-to-datacenter traffic.
Benefits of SDN
• Unifiedviewof the network fabric With SDN we get a unified view of the
network, simplifying configuration, managementand provisioning.
• Highutilization Centralized traffic engineering provides a global view of the
supply and demand of network resources. Managing end-to-end paths with
this global view results in high utilization of the links.
• Faster failure handling Failures whether it be link, node or otherwiseare
handled much faster. Furthermore, thesystems convergemorerapidly to
target optimum and the behavior is predictable.
• Faster time tomarket/deployment With SDN, better and more rigorous
testing is done ahead of rollout accelerating deployment. The development
is also expedited as only the features needed are developed.
• Hitless upgrades thedecoupling of the controlplane fromthe
forwarding/data planeenables us to performhitless softwareupgrades
without packet loss or capacity degradation.
• Highfidelity test environment Theentire backboneis emulated in software
which not only helps in testing and verification but also in running “what-if”
scenarios.
• Elastic compute Compute capability of network devices is no longer a
limiting factor as control and management resides on external
servers/controllers. Large-scalecomputation, path optimization in our case,
is done using the latest generation of servers.
Challenges

17. 11 | P a g e
• OpenFlowprotocol The OpenFlow protocolis in its infancy and is bare
bones. However, as our deployment shows, it is good enough for many
network applications.
• Fault tolerant OpenFlowcontrollers To providefaulttolerance, multiple
OpenFlow controllers mustbe provisioned. This requires handling master
election and partitions between the on controllers.
Partitioning functionality Itis not very clear what functionality should reside in
the network devices and whatshould reside in external controllers. Configuration
of functionality residentin the network device remains an open question.
Flow programming For large networks, programming of individualflows can take
a long time.
Summary
Google’s datacenter-to-datacenter WAN successfully runs on an SDNand
OpenFlow enabled network. Itis the largest production network at Google. SDN
and OpenFlow haveimproved manageability, performance, utilization and cost
efficiency of the WAN.
SDN MYTHS
SDN is Equalto Virtualization
.
 Network virtualization is just one application of the broaderSDN meaning.SDN is
described as a mechanism,while network virtualization is a solution. SDN can be
applied to graphic engineering,security, policy or network virtualization while network
virtualization itself, is a solution setcustomers use to change structure of their
network. SDN can be paired with server virtualization , but is nota necessity. Simply
implementing network functions in software is not SDN. Virtualization and SDN have
their own identities and remain separate.
SDNOnly Has Financial Impacts
.
 Industry professionals believeSDN may allow for commoditized networking
equipment to be the way of the future, thus reducing costs. While reduced
costs are at the top of mostdecision-makers’ lists, this isn’t the only driving

18. 12 | P a g e
forcebehind SDN. In an ideal world, SDNwould drivedown costs while
offering ITprofessionals a mechanismthat encompasses elasticity, flexibility,
and interoperability.
SDNis a HardwareKiller
.
 As SDN has emerged, its moniker as a “hardwarekiller” has developed. The
truth is, a successful SDNneeds to be paired with high-performing hardware,
network operating systems, and a general awareness of what’s happening with
the controller and applications. Given this web dependency and SDN’s
reliability on existing hardware, there is actually a substantialopportunity for
hardwareinnovation to occur despite claims of looming doom.
SDNPresents Significant Security Liabilities
.
 Security concerns have always been a focal point (and challenge) for IT
professionals. So, when new concepts emerge like SDN, security concerns are
always quick to follow. Despite somepotential risks, SDNwill simplify
extending network segments beyond the building perimeter, increasing the
chances of data remaining secure. Vague boundaries makeit difficult for IT
professionals to determine where to install firewalls. SDN can allow internal
and perimeter traffic to be routed through one central firewall.
As the SDNmarket continues to grow, its definition, capabilities, and effects on IT
will all come into better focus. Like anything else, it will take time for it to become
fully established, and until then, it will be a classic case of “wait and see.”
However, wehope these myths and some of our input has helped clear some of
the convoluted air surrounding theSDN space.
Myth:SDNis all aboutdata center networking
Reality: SDNspans morethan justthe data center. As network professionals
move to using more private cloud alternatives, they’re experiencing challenges—

19. 13 | P a g e
especially around networking. Consequently, many are looking to SDNfor
solutions. However, SDNis not only important to the data center as it also applies
to broader network applications, including campus and branch installations and
will likely havea big impact in the way services areprovided in the SP spaceas
well.
Myth:SDNis only aboutreducing capitalexpenditures(CAPEX)
Reality: As morekey networking functions becomesoftware-based, therewill be
a corresponding decreasein CAPEX for computing hardware. In addition to these
savings, , the greatest potential for SDN will be its ability to enable more
automation in networking. Presently, so much networking functionality is
managed manually. As SDNadoption and the resulting network automation
expands, the savings in operating expenses (OPEX) areexpected to outpace the
anticipated decreases in CAPEX.
Myth:SDNis only aboutsoftware
Reality: SDNis about leveraging software, butthe key point is that the softwareis
being unleashed fromthe hostnetworking devices. Further, SDNprovides for an
incentive and platform for new innovations that will emerge and influence
hardwaredevelopment to ensurefuture technology can handle the new
capabilities being built into the network management software.
Myth:SDNis all aboutcentralization
Reality: Although centralization is important, SDNalso is about ensuring
decentralization or distribution of the key elements of the Internet. Networks are
inherently decentralized, particularly for forwarding, and there is no value in
centralizing everything. The objective of SDNis to create the right balance
between network centralization and decentralization.
Myth:SDNis all aboutOpenFlow
Reality: OpenFlow was theearly version of SDN, but OpenFlow is justan open
standard protocolthat enables testing of experimental solutions. OpenFlow-
enabled switches are now commercially-available, however, OpenFlow is only a
small component of the larger SDNtrend. Since this is one of the myths we have

20. 14 | P a g e
heard mostfrequently, we’ll take a deeper dive into the differences between SDN
and OpenFlow in a futurepost.
Myth:SDNadoption is going to happen immediately
Reality: Likemost new computing strategies, it will take time beforeSDN is
broadly adopted. That is not to say it is not being considered by many who are
planning to move in this direction; however, it is important to recall that
governmentagencies have built networks they need to operate in supportof
today’s missions. As network professionalslearn moreabout how SDN will
benefit their operations, justas they have considered incremental adoption of
cloud computing, SDN gradually will take on a more significant role in Federal
networking environments.

21. 15 | P a g e
CHAPTER 2 : OPENFLOW
INTRODUCTION
Stanford University and the University of California at Berkeley.
OpenFlowis a programmable network protocoldesignedto manage and
direct traffic among routers and switches from various vendors. It separates
the programming of routers and switches from underlying hardware. It is
the result of a six-year research collaboration between
WHAT IS OPENFLOW?
OpenFlowis considered the first software-definednetworking (SDN)
standard. It defines the open communications protocolin SDNs that
enables the Controller to interact with the forwarding plane and make
adjustments to the network, so it can better adapt to changing business
requirements. With OpenFlow, entries can be added and removed to the
internal flow-table of switches and potentially routers to make the network
more responsive to real-time traffic demands.
Any device that would like to participate in this environment must support
OpenFlowwith a standardized interface. This interface exposes the
internal workings of the device, which enables the Controller to push down
changes to the flow-table. Once the devices are OpenFlow-enabled,
network administrators can use them to partition traffic, control flows for
optimal performance,and start testing new configurations and applications.
INSIDE OPENFLOW
OpenFlowis the first standard communications interface defined between
the control and forwarding layers of an SDN architecture. OpenFlow allows
direct 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 led to the characterization of today’s networking devices as monolithic,
closed,and mainframe-like. No other standard protocoldoes what
OpenFlowdoes,and a protocollike OpenFlowis needed to move network

22. 16 | P a g e
control out of the networking switches to logically centralized control
software.
OpenFlowcan be compared to the instruction set of a CPU. As shown in
Figure 2, the protocolspecifies basicprimitives that can be used by an
external software application to program the forwarding plane of network
devices,just like the instruction set of a CPU would program a computer
system.
The OpenFlow protocol is implemented on both sides of the interface
between network infrastructure devices and the SDN control software.
OpenFlow uses the concept of flows to identify network traffic based on
pre-defined matchrules that can be statically or dynamically programmed
by the SDN control software. It also allows IT to define how traffic should
flow through network devices based on parameters such as usage
patterns, applications, and cloud resources. Since OpenFlow allows the
network to be programmedon a per-flow basis,an OpenFlow-basedSDN
architecture provides extremely granular control, enabling the network to
respond to real-time changes at the application, user, and sessionlevels.
Current IP-based routing does not provide this level of control, as all flows

23. 17 | P a g e
between two endpoints must follow the same path through the network,
regardless of their differentrequirements.
The OpenFlow protocol is a key enabler for software-defined networks and
currently is the only standardized SDN protocol that allows direct
manipulation of the forwarding plane of network devices. While initially
applied to Ethernet-based networks, OpenFlow switching can extend to a
much broaderset of use cases.OpenFlow-based SDNs can be deployed on
existing networks, both physical and virtual. Network devices can upport
OpenFlow-based forwarding as well as traditional forwarding, which makes
it very easy for enterprises and carriers to progressively introduce
OpenFlow-based SDN technologies, even in multi-vendor network
environments.
The OpenNetworking Foundation is chartered to standardize OpenFlowand
does so through technical working groups responsible for the protocol,
configuration, interoperability testing, and other activities, helping to ensure
interoperability betweennetwork devices and control software from different
vendors. OpenFlow is being widely adopted by infrastructure vendors, who
typically have implemented it via a simple firmware or software upgrade.
OpenFlow-based SDN architecture can integrate seamlessly with an
enterprise or carrier’s existing infrastructure and provide a simple migration
path forthose segments of the network that need SDN functionality the most.
BENEFITSOF OPENFLOW-BASEDSOFTWARE-DEFINED NETWORKS
For enterprises and carriers alike, SDN makes it possible for the network
to be a competitive differentiator, not just an unavoidable cost center.
OpenFlow-based SDN technologies enable IT to address the high-
bandwidth, dynamic nature of today’s applications, adapt the network to
ever-changing business needs, and significantly reduce operations and
management complexity.
The benefits that enterprises and carriers can achieve through an
OpenFlow-basedSDN 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 to manage groups of devices from individual vendors, IT can use

24. 18 | P a g e
SDN-based orchestration and management tools to quickly deploy,
configure,and update devices across the entire network.
• Reduced complexity through automation: OpenFlow-basedSDN 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. These automation tools will reduce operational
overhead, decrease network instability introduced by operator error, and
supportemerging IT-as-a-Service and self-serviceprovisioning models.
In addition, with SDN, cloud-based applications can be managed through
intelligent orchestration and provisioning systems,further reducing
operational overhead while increasing business agility.
• Higher rate of innovation: SDN adoption accelerates business
innovation by allowing IT network operators to literally program—and
reprogram—the network in real time to meet specific business needs and
user requirements as they arise. By virtualizing the network infrastructure
and abstracting it from individual network services,forexample, SDN
and OpenFlow give IT— and potentially even users—the ability to tailor
the behavior of the network and introduce new services and network
capabilities in a matter of hours.
• Increasednetwork reliability and security: SDNmakes it possible for
IT to define high-level configuration and policy statements, which are
then translated down to the infrastructure via OpenFlow.An OpenFlow-
based SDN architecture eliminates the need to individually configure
network devices each time an end point, service, or application is added
or moved,or a policy changes, which reduces the likelihood of network
failures due to configuration or policy inconsistencies.
Because SDN controllers provide complete visibility and control over the
network, they can ensure that access control, traffic engineering, quality
of service,security, and other policies are enforced consistentlyacross
the wired and wireless network infrastructures, including branch offices,
campuses,and data centers. Enterprises and carriers benefit from
reduced operational expenses,more dynamic configuration capabilities,
fewer errors, and consistent configuration and policy enforcement.
• More granularnetworkcontrol: OpenFlow‘s flow-basedcontrolmodel
allows IT to apply policies at a very granular level, including the session,
user, device,and application levels, in a highly abstracted, automated
fashion. This control enables cloud operators to supportmulti-tenancy

25. 19 | P a g e
while maintaining traffic isolation, security, and elastic resource
management when customers share the same infrastructure.
• 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. For instance, a carrier could introduce
a video service that offers premium subscribers the highest possible
resolution in an automated and transparent manner. Today, users must
explicitly select a resolution setting, which the network may or may not be
able to support, resulting in delays and interruptions that degrade the

26. 20 | P a g e
CHAPTER 3: SDNCONTROLLER
INTRODUCTION
An SDNcontroller is an application in software-defined networking (SDN) that
manages flow controlto enable intelligent networking. SDNcontrollers are based
on protocols, such asOpenFlow, thatallow servers to tell switches whereto
send packets.
The controller is the coreof an SDNnetwork. Itlies between network devices at
one end and applications at the other end. Any communications between
applications and devices have to go through the controller. The controller also
uses protocols such as OpenFlow to configurenetwork devices and choose the
optimal network path for application traffic.
In effect, the SDN controller serves as a sort of operating system(OS) for the
network. By taking the controlplane off the network hardwareand running it
as softwareinstead, the controller facilitates automated network management
and makes it easier to integrate and administer business applications.
Vendors of SDN controllers include Big Switch Networks, HP, IBM, VMWareand
Juniper. Here's a brief look at the Big Switch product, Big Network Controller:
Like Big Switch's other SDN products, thecontroller is based on OpenFlow, which
enables softwareto run on numerous types of hardware, rather than being tied
down to proprietary equipment from one supplier.
The Big Network Controller abstracts the network fromthe hardware. According
to the company, its controller makes it possibleto controlthe entire network
froma single console. The Big Network Controller is based on the open source
Floodlight controller code, which is available under an Apache2.0 license. The
company also offers as a free and open sourceSDNcontroller based on Floodlight

27. 21 | P a g e
WHAT ARE SDNCONTROLLERS?
A Controller in a software-defined network (SDN) is the “brains” of the network. It
is the strategic control point in the SDNnetwork, relaying information to the
switches/routers ‘below’ (via southbound APIs) and theapplications and business
logic ‘above’ (via northbound APIs). Recently, as organizations deploy
more SDNnetworks, theControllers havebeen tasked with federating between
Controller domains, using common application interfaces, such as the open virtual
switch database (OVS DB).
The SDN Controller platformtypically contains a collection of “pluggable”
modules that can performdifferent network tasks. Someof the basic tasks
including inventorying whatdevices are within the network and the capabilities of
each, gathering network statistics, etc. Extensions can be inserted that enhance
the functionality and supportmore advanced capabilities, such as running
algorithms to performanalytics and orchestrating new rules throughoutthe
network.
One of the most well-known protocols used by SDNControllers to communicate
with the switches/routers isOpenFlow. Others arebeing developed, while more
established networking protocols arefinding ways to run in an SDNenvironment.
For example, the InternetEngineering Task Force(IETF) working group –the
Interfaceto the Routing System(i2rs) –is developing an SDNstrategy that
enables the Controller to leverage proven, traditional protocols, such as OSPF,
MPLS, BGP, and IS-IS.
The type of protocols supported can influence the overallarchitecture of the
network – for example, while OpenFlow attempts to completely centralize
packet-forwarding decisions, i2rs splits thedecision making by leveraging
traditional routing protocols to execute distributed routing and allowing
applications to modify routing decisions.

28. 22 | P a g e

29. 23 | P a g e
CHAPTER 4: OPENVSWITCH
INTRODUCTION
OpenvSwitch, sometimes abbreviated to OVS, is a production-quality open
sourceimplementation of a distributed virtual multilayer switch. The main
purposeof Open vSwitch is to providea switching stack for hardware
virtualization environments, whilesupporting multiple protocols and standards
used in computer networks.
WHAT IS OPEN VSWITCH?
Open vSwitch is a multilayer softwareswitch licensed under the open
sourceApache 2 license. Our goal is to implement a production
quality switch platform that supports standard managementinterfaces
and opens the forwarding functions to programmatic extension and
control.
Open vSwitch is well suited to function as a virtual switch in VM
environments. In addition to exposing standard controland visibility
interfaces to the virtual networking layer, it was designed to support
distribution across multiple physicalservers. Open vSwitch supports
multiple Linux-based virtualization technologies including
Xen/XenServer, KVM, and VirtualBox.

30. 24 | P a g e
Supported Platforms
Open vSwitch can operate both as a softswitch running within the hypervisor,
and as the control stack for switching silicon. Ithas been ported to multiple
virtualization platforms and switching chipsets. Itis the default switch
in XenServer 6.0, theXen Cloud Platformand also supports Xen,KVM, Proxmox
VE and VirtualBox. Ithas also been integrated into many virtualmanagement
systems includingOpenStack, openQRM, OpenNebulaand oVirt. Thekernel
datapath is distributed with Linux, and packages are available
for Ubuntu, Debian, andFedora. Open vSwitch is also supported
on FreeBSD and NetBSD. TheOpen vSwitch release in development has been
ported to DPDK.

31. 25 | P a g e
FEATURES
Open vSwitch supports thefollowing features:
 Visibility into inter-VM communication via NetFlow, sFlow(R), IPFIX, SPAN,
RSPAN, and GRE-tunneled mirrors
 LACP (IEEE802.1AX-2008)
 Standard 802.1Q VLANmodelwith trunking
 BFD and 802.1ag link monitoring
 STP (IEEE802.1D-1998)
 Fine-grained QoS control
 Supportfor HFSCqdisc
 Per VMinterface traffic policing
 NIC bonding with source-MACload balancing, active backup, and L4 hashing
 OpenFlow protocolsupport(including many extensions for virtualization)
 IPv6 support
 Multiple tunneling protocols (GRE, VXLAN, IPsec, GREand VXLANover IPsec)
 Remote configuration protocol with C and Python bindings
 Kernel and user-spaceforwarding engineoptions
 Multi-table forwarding pipeline with flow-caching engine
 Forwarding layer abstraction to ease porting to new softwareand hardware
platforms

32. 26 | P a g e
SUPPORTED PLATFORM
• Default witch in
 Xen
 KVM
 Supported in ESXi
 Integrated in
 OpenStack, OpenNebula, vSphere
 Supports
 Ubuntu ,Fedora

33. 27 | P a g e
CHAPTER 5: MININET(AN INSTANT VIRTUAL NETWORKON YOUR LAPTOP)
INTRODUCTION
Mininet creates a realistic virtual network,running realkernel,
switch and applicationcode,on a single machine (VM, cloud or
native), in seconds,with a single command.
Because you can easily interact with your network using the
Mininet CLI (and API), customize it, share it with others, or deploy it on real
hardware, Mininet is useful for development, teaching, and research.
Mininet is also a great way to develop,share, and experiment
with OpenFlow and Software-DefinedNetworking systems.
Mininet is actively developed and supported,and is released under a
permissive BSD Open Source license. We encourage you
to contribute code,bug reports/fixes,documentation, and anything else that
can improve the system!
WHAT IS MININET?
Mininet is a network emulator.It runs a collectionof end-hosts,switches,
routers, and links on a single Linux kernel. It uses lightweight virtualization
to make a single system look like a complete network, running the same
kernel, system, and user code.A Mininet host behaves just like a real
machine; you can ssh into it (if you start up sshd and bridge the network to
your host) and run arbitrary programs (including anything that is installed
on the underlying Linux system.) The programs you run can send packets
through what seems like a real Ethernet interface, with a given link speed
and delay. Packets get processedby what looks like a real Ethernet switch,

34. 28 | P a g e
router, or middlebox,with a given amount of queueing. When two
programs,like an iperf client and server, communicate through Mininet, the
measured performance should match that of two (slower) native machines.
In short, Mininet's virtual hosts, switches, links, and controllers are the real
thing – they are just created using software rather than hardware – and for
the most part their behavior is similar to discrete hardware elements.It is
usually possible to create a Mininet network that resemblesa hardware
network, or a hardware network that resemblesa Mininet network, and to
run the same binary code and applications on either platform.
5.3MININET SAMPLE WORKFLOW
Mininet enables you to quickly create, interact with, customize and share a
software defined network prototype, and provides a smooth path to running
on hardware. This page illustrates the basic Mininet workflow, and many
additional details are available in the Mininet walkthrough, the
OpenFlowtutorial, and Mininet documentation.
5.3.1Creating a Network
You can create a network with a single command.For example,
sudo mn --switch ovsk --controller ref --topo tree,depth=2,fanout=8 --test
pingall
starts a network with a tree topology of depth 2 and fanout 8 (i.e. 64 hosts
connected to 9 switches), using Open vSwitch switches under the control of
the OpenFlow/Stanford reference controller, and runs the pingall test to
check connectivity between every pair of nodes. (This takes about 30
seconds on my laptop.)

35. 29 | P a g e
5.3.2Interacting with a Network
Mininet’s CLI allows you to control, and manage your entire virtual network
from a single console.For example, the CLI command
mininet> h2 ping h3
tells host h2 to ping host h2’s IP address. Any available Linux command or
program can be run on any virtual host. You can easily start a web server on
one host and make an HTTP requestfrom another:
mininet> h2 python -m SimpleHTTPServer 80 >&
/tmp/http.log &
mininet> h3 wget -O - h2
5.3.3Customizing a Network
Mininet’s API allows you to create custom networks with a few lines of
Python. For example, the following script
1
2
3
4
5
6
7
8
from mininet.net import Mininet
from mininet.topolib import TreeTopo
tree4 = TreeTopo(depth=2,fanout=2)
net = Mininet(topo=tree4)
net.start()
h1, h4 = net.hosts[0], net.hosts[3]
print h1.cmd('ping -c1 %s' % h4.IP())
net.stop()
creates a small network (4 hosts, 3 switches), and pings one host from
another (in about 4 seconds with the current version.)
The Mininet distribution includes several text-based and graphical (see
above) applications which we hope will be instructive and inspire you to
create cool and useful apps for your own network designs.

36. 30 | P a g e
5.3.4Sharing a Network
Mininet is distributed as a virtual machine (VM) image with all dependencies
pre-installed, runnable on common virtual machine monitors such as
VMware, Xen and VirtualBox. This provides a convenient container for
distribution; once a prototype has been developed, the VM image may be
distributed to others to run, examine and modify. A complete, compressed
Mininet VM is about 1GB.(Mininet can also be installed natively - apt-get
install mininet on Ubuntu.) If you are reading a great SIGCOMM (or
other) paperabout a Software-Defined Network, wouldn’t you like to be able
to click, download and run a living, breathing example of the system? If so,
considerdeveloping aMininet versionof your own system that you can share
with others!
5.3.5 Running on Hardware
Once a design works on Mininet, it can be deployed on hardware for real-
world use, testing and measurement.
To successfully port to hardware on the first try, every Mininet-emulated
componentmustact in the same way as its corresponding physicalone.The
virtual topology should match the physical one; virtual Ethernet pairs must
be replaced bylink-level Ethernet connectivity. Hosts emulated as processes
should be replaced by hosts with their own OS image. In addition, each
emulated OpenFlowswitch should be replaced by a physical one configured
to point to the controller. However, the controller does not need to change.
WhenMininet is running, the controller“sees” aphysicalnetwork of switches,
made possible byan interface with well-defined state semantics.

37. 31 | P a g e
MININET TOOL FOR EXPLORING OPENFLOW AND SDN
Mininetisa greate wayto learnSDN and OpenFlow aswell as SDN controllerandSDN application
Let’slaunchmininetwithdefaulttopology
Let’slookat shme mininetcommands:
Mininet>help

38. 32 | P a g e
Display nodes:
Mininet>nodes
Mininet>dump
Mininet>net
Let see host 1 ping host2 in default topology
Mininet> h1 ping h2
You can see here that first ping took longer then other pings in above figure.
Remember this is SDN network using openflow.
For the first packet of any flow the switch has to notify the SDN controller.

39. 33 | P a g e
There is an another way to intract with host(h1) and (h2) in mininet by using
Xterm command.
Pingall command let you ping from every host to every host
To see TCP and UDP bandwidth between hosts the command is iperf
Mininet>ipref

40. 34 | P a g e
Some other topologies available in mininet
Mininet> sudo mn –topo=single,4
Same basictopologywith4 hosts

41. 35 | P a g e
Mininet>sudomn –topo=linear,4
Create lineartopologywith4switchesand4 hosts

42. 36 | P a g e
Mininet>sudomn –topo=tree,2,2
Thiswill create tree topologywith2level deepandfanoutof 2

43. 37 | P a g e
MODULE 1: MANUALLYENTERING FLOW-ENTRYINTO OPENVSWITCH(OVS)
 Ovs-ofctl commandaddmanual flow entriestoOVS
 Flowentriesonamopenflowswitchcontrolsthe behaviorof packet
 Flowentriesare typically installeddynamicallywithanSDN Controller
Step1
Let’stake simple topologywith1switch,3 hostswithoutcontroller
Command:
$ sudomn –topo=single,3–controller=none–mac
Topologylookslike

44. 38 | P a g e
3. Let’s see how the ports are mapped
Command:
Mininet>dump
4.Let’s see the link between the nodes
Command:
Mininet> net
5.Let’s see how s1-eth1 -eth2 -eth3 are mapped to openFlow ports
Command:
Mininet> sh ovs-ofctl show s1

45. 39 | P a g e
6.so now let’s ping all hosts using pinall command
Mininet> pingall
As you can see in above figure there is no ping among ant host connected to switch. This is
because switch is not connected to SDN controller so it does not know what to do with
packets.
So now we have seen that there is no connectivity between any hosts without controller.The
main resion behind this is there is no flow entry in the switch
7.Let’s add our first floe rntry which is normal
Mininet> sh ovs-ofctl add-flow s1 actions=normal
Here we have not specified any mach condition ,only provided action this means it mach
every packet. The action=normal means traditional L2 switch behavior. All we are telling
switch s1 ,just do normal L2 forwarding.
Let’s test this with pingall command
Now all the hosts are pinging each other’s

46. 40 | P a g e
8.Let see s1 all of its flow entries
Mininet> sh ovs-ofctl dump-flow s1
9.Let delete all flow entries
Mininet> sh ovs-ofctl del-flows s1
Try to see flow entry again after delete
10.One we have deleted this fow entry , no again there will be no connection between the
hosts because there is no flow entry in the switch
11.Now let’s do some actual matching means lets configure some static flow to switch
We will configure a flow entry, which says anything on port1 send to port 2 and vise versa .

47. 41 | P a g e
For this we have to add two flow entry’s to switch from mininet CLI
Mininet> sh ovs-ofctl add-flow s1 priority=500,in_port=1,action=output:2
Mininet> sh ovs-ofctl add-flow s1 priority=500,in_port=2,action=output:1
So ant thing from port1 goes to port2 and anything from port2 goes to port1
Let check thid by pinging h3 from h1
Mininet> h1 ping h3
As you can see they can ping eachother
Lets ping h1 to h2
Here h2 is on port3 and there is no flow available for this port so switch will drop the packet
Mininet> h1 ping h2
And we can see destination host unreachable
Lets do ping all for better understanding what is happening
Mininet> pingall

48. 42 | P a g e
Let see the dump-flow again
12. Earlier we have defined priority of 500
Priority is a critical concept. If the packet arrive at openflow switch and have 10 flow entry’s
that matches the packet ,only the flow entry having highest priority will be used and all other
will be ignored.
Lets test this priority concept by providing new flow entry
Mininet> sh ovs-ofctl add-flow s1 priority=32768,action=drop
This flow entry has the higher priority of 32768 and action here is drop also it does not have
any match condition listed which means this rule will match with every packet , and now
every packet well be drop .
Lets again try to ping h1 to h3

49. 43 | P a g e
Packets are dropped.
Let see dunp-flow again
The third rule prevent any connectivity.

50. 44 | P a g e
CHAPTER 6: FLOODLIGHT CONTROLLER
INTRODUCTION
The Floodlight Open SDNController is an enterprise-class, Apache-licensed, Java-
based OpenFlow Controller. Itis supported by a community of developers
including a number of engineers fromBig Switch Networks.
OpenFlow is a open standard managed by Open Networking Foundation. It
specifies a protocolthrough switch a remote controller can modify the behavior
of networking devices through a well-defined “forwarding instruction set”.
Floodlight is designed to work with the growing number of switches, routers,
virtual switches, and access points that supportthe OpenFlow standard.
Floodlight is an OpenFlow controller built on work that began at Stanford
University and UC at Berkeley and now continues among a community of open
sourcedevelopers along with engineers at SDNand network virtualization startup
Big Switch Networks Inc.Floodlightis available via a free download for third-party
application development and is released under an Apache2.0 license, which
enables the softwareto be included in commercial packages.
Feature Highlights:
 Offers a module loading systemthat make it simple to extend and enhance.
 Easy to set up with minimal dependencies
 Supports a broad range of virtual- and physical- OpenFlow switches
 Can handle mixed OpenFlow and non-OpenFlow networks –it can manage
multiple “islands” of OpenFlow hardwareswitches
 Designed to be high-performance– is the core of a commercial productfrom
Big Switch Networks.
 Supportfor OpenStack (link) cloud orchestration platform

51. 45 | P a g e
FOR DEVELOPERS,FLOODLIGHT OFFERS THESE ADVANTAGES:
 Itis designed to allow third parties to easily modify the softwareand develop
applications.
 Itis written in Java.
 The Floodlight website has severalcoding examples along with directions on
how to build the product.
 REST APIs areincluded to simplify application interfaces to the product.
Floodlight controller applications
While the controller is a key component in SDN, it provides only the means to
manage or direct the network that lies beneath. Applications that interface to the
controller determine network policies that guide this granular network
management. The open sourcecommunity, Big Switch developers and several
cloud and network vendors havebeen working steadily on creating a plethora of
open-sourceFloodlightapplications.
Some Floodlight applications include the following:
 The Virtual Networking Filter identifies packets that enter the network but do
not match an existing flow. The application determines whether the source
and destination are on the same virtual network; if so, the application signals
the controller to continue flow creation.
 The Circuit Pusher then creates a flow and provisions switches along the path
to the packet's destination.
 The Static FlowPusher is used to create a flow in advanceof the initial packet
in the flow entering the network.
 Firewall modules givethe same protection to devices on the software-defined
network as traditional firewalls on a physicalnetwork. Access ControlList rules
control whether a flow should be set up to a specific destination.

52. 46 | P a g e
Floodlight is Java-based and intended to run with standard jdk tools and ant and can optionally be run in
Eclipse.
Prerequisites
Linux
 Ubuntu 10.04 (Natty) or higher. (Has been run with Ubuntu 10.04 with Ant versions 1.8.1 or
lower).
 Install JDK, Ant. You can optionally choose to install eclipse but it is not required.
sudo apt-get install build-essential default-jdk ant python-dev eclipse
Download And Build
Floodlight is simple to download from Github and build.
$ git clone git://github.com/floodlight/floodlight.git
$ cd floodlight
$ ant
Note: This uses the master version of Floodlight.
Running Floodlight
Assuming java is in your path, you can directly run the floodlight.jar file produced by ant.
$ java -jar target/floodlight.jar
Floodlight will start running and print debug output to your console.

53. 47 | P a g e
Floodlight Controller Browser GUI

54. 48 | P a g e
CHAPTER 7: AVIOR 1.3
INTRODUCTION
Avior is an open sourceprojectdeveloped by the Marist College/IBM Joint Study
OpenFlow research team. Avior was designed to fill a void in the realm of
floodlight administration while propelling the forward development of open
sourceFloodlight applications. The application runs independently of the
controller and communicates with the controller using the default restAPI.
Currently the application supports a couple of features…
 Display of basic network information (switches, hosts, controller info)
 More importantly it has a complete flow manager that will allow you to add,
modify, and delete currentflows on the network, all without having to glance at
python scripting or the restAPI JSONonce!
The application is quite simple at the moment, but it will be updated
in accordancewith future Floodlight development. Our immediate concern is to
expand the network information feature to fully exploit the capabilities of the rest
API. After that is completed, we hope to work closely with Floodlight developers
to understand the futureof Floodlight and in turn, our application.
Controller Overview
This is the welcoming screen for Avior. Here you will see some very basic information about the controller
including the hostname, the JVM memory bloat, whether and controller is providing JSON data, and lastly the
modules currently loaded.

55. 49 | P a g e
Switch Overview
This is the detailed switch overview. Here you will find information about the switch pertaining to the
hardware and firmware. Next you will have a table of the different ports and their associated traffic counters.
Lastly you will see the various flows on that switch. Both dynamic and static flows are displayed here with the
priority, match, action, packets, bytes, age, and timeout displayed. All of this updates in real time.
Device Overview
This is a very basic device overview of the network. Listed here are the various devices on the network, with
information about the MAC address, the IP address, the attached switch DPID, the attached switch port, and
the time it was last seen.

56. 50 | P a g e
Flow Manager
The flow manager is a tool provided by Avior that is useful in making testing much easier for floodlight. You
can view the static flows for each switch by selecting it, and then furthur investigate the values of each flow by
clicking on their corresponding names. If you would like to make a new flow you simply click on 'New Flow',
enter the name value, and then continue to add any other necessary features. To add actions to the flow, simply
click on the actions row to bring up an action manager. Changing the match is just as simple. Once you have
all the settings configured, hit 'Push' and error checking will be done automatically. If your flow is valid, it will
be pushed and you will get a message as to whether or not the switch is holding that flow. Lastly, you can
delete a single flow or delete all flows pertaining to a switch by clicking on the buttons up top.

57. 51 | P a g e
MODULE 2: PROVIDING STATIC FLOW USING AVIOR 1.3
Here we will pushstaticflowfromcontroller floodlighttothe openflow switchinthe mininet.
 Firstwe run the native instance floodlightcontroller.
 Thenwe will connectthiscontrollertothe mininettopology.
 Andthenwill pushthe staticflow tothe switchfromcontrollerandtestthe flow

58. 52 | P a g e
Nowwe will connectmininettopologywithfloodlightcontroller

59. 53 | P a g e
Nowour mininettopologyisconnectedtofloodlightcontroller
So letdopingall
NowletsopenAvior1.3 fromterminal

60. 54 | P a g e
Give yourfloodlightipandclicklaunch
Thisaviorapplicationgui screen

61. 55 | P a g e
Nowletsopenfloodlightbrowsergui console

62. 56 | P a g e
Let see linkbetweennodes

63. 57 | P a g e
Let see switchinavior

64. 58 | P a g e

65. 59 | P a g e
Nowlettestthe flow
H1 ispingingh3 because h1 ison port 1 whichis allow andh3 ison port 2 whichisallowed
Letspingh2 fromh1 ,,h2 ison port3 and switchdoesnothave flow forport 3 so packetshould
be drop

66. 60 | P a g e
As youcan see above h1 can’t pingh2
Letspingh1 fromh3
Andsee the result
As youcan see above pingishappeningtest2flow entry
Letspingh2 fromh3 and see whathappen

67. 61 | P a g e
Finallyletsdopingall tounderstandthe flow

68. 62 | P a g e
CHAPTER 8: VISUAL NETWORK DESCRIPTION
INTRODUCTION
Visual Network Description – VND (SDN version) is a web-based
graphical user interface for the authoring of generic network scenarios (also
referred to as experiments)which allows the automatic generation of NSDL,
and can be further applied forthe simulation and analysis of these scenarios.
The VND (SDN version) allows the authoring of Software Defined Network
experiments and the automatic generation of Mininet and Openflow
Controllers Scripts besidesgenerating NSDL files. These scripts are related
to network scenarios,flowtables,and QoS configurations created ina simple
and friendly GUI.
The VND (SDN version) aims at faciliting the creation of general network
scenarios (experiments) for further simulation under different OpenFlow
tools, such as mininet. For this purpose,VND (SDN version) exports Python
scripts for the descriptionof rules and flow tables in orderto be executed on
Openflow Controllers. Further interoperability is also provided by the
automatic generation of NSDL, which can be imported by any NSDL-
compliant simulation and analysis tool. The VND´s (SDN version) main
target public area novice professionals, students and also expert SDN
developers.
It´s main features are:
• Authoring of SDN Network Scenarios via GUI
• Automatic creation of Mininet Scripts
• Automatic creation of OpenflowControllers Scripts.
• Automatic creation of NSDL files.

69. 63 | P a g e
MODULE 3: CREATING CUSTOM TOPOLOGY (MESH TOPOLOGY)USING VISUAL NETWORK
DESCRIPTION
In thismodule we will create customtopologyusingvisual networkdescription.the topology whichwe
will create will be meshtopology.We willbe configuringdifferentlinksbetweenswitcheswithdelay,
linkbandwidth,queue size.
So letstart creatingthismodule
Firstwe go to http://www.ramonfontes.com/vnd/

70. 64 | P a g e
2.Nowwe will use objectsfromthe librarytocreate our customtopology.See picture blow.
The final createddesignmodel look like this

71. 65 | P a g e
3. now nexttaskisto configure eachlinkinthistopology.Because withoutconfiguringlinksthis
topologywill notwork .

72. 66 | P a g e
4. Aftercompletingthe linkconfiguring,bandwidth,delay,queue size,loss.letsexportthistopology
To use in mininet.
WhenyouselectoptionExportas mininetscript,apythoncodedfile will be createdandthisfile should
be run in mininet.
Copyand past thisscriptin mininet/custom
Nowwe have to run thisscriptfrom terminal.Soletssee how we cando this.
Firstoff all thisscript has extensionof .sh,sowe have toconvertthisinto .pyextensioninorder
to run thisscriptin mininet.
Commandis:
Andthe followingcommands:

73. 67 | P a g e
Nowfinallythiscommandwillrunthistopologyinmininet.
Thistopologyshouldbe connectedtoremote controller.
TopologyCode mininetScript.py
#!/usr/bin/python
"""
Scriptcreatedby VND- Visual NetworkDescription(SDN version)
"""
frommininet.netimportMininet
frommininet.node importController,RemoteController,OVSKernelSwitch,OVSLegacyKernelSwitch,
UserSwitch
frommininet.cliimportCLI
frommininet.logimportsetLogLevel

74. 68 | P a g e
frommininet.linkimportLink,TCLink
def topology():
"Create a network."
net = Mininet( controller=RemoteController,link=TCLink,switch=OVSKernelSwitch)
print"*** Creatingnodes"
s1 = net.addSwitch( 's1',listenPort=6634,mac='00:00:00:00:00:01' )
s2 = net.addSwitch( 's2',listenPort=6635,mac='00:00:00:00:00:02' )
s3 = net.addSwitch( 's3',listenPort=6636,mac='00:00:00:00:00:03' )
s4 = net.addSwitch( 's4',listenPort=6637,mac='00:00:00:00:00:04' )
h13 = net.addHost( 'h13',mac='00:00:00:00:00:13', ip='10.0.0.13/8' )
h14 = net.addHost( 'h14',mac='00:00:00:00:00:14', ip='10.0.0.14/8' )
c17 = net.addController( 'c17', controller=RemoteController,ip='127.0.0.1',port=6633 )
print"*** Creatinglinks"
net.addLink(s4,h14,3, 0, bw=100, delay='0ms',max_queue_size=200,loss=0)
net.addLink(h13,s1,0, 3, bw=100, delay='0ms',max_queue_size=200,loss=0)
net.addLink(s3,s2,3, 3, bw=100, delay='10ms',max_queue_size=150,loss=0)
net.addLink(s3,s4,2, 2, bw=1, delay='100ms',max_queue_size=2,loss=90)
net.addLink(s2,s4, 2, 1, bw=100, delay='10ms',max_queue_size=150,loss=0)
net.addLink(s1,s2,2, 1, bw=1, delay='100ms',max_queue_size=2,loss=90)
net.addLink(s1,s3,1, 1, bw=100, delay='0ms',max_queue_size=150,loss=0)
print"*** Startingnetwork"
net.start()
s4.start( [c17] )
s3.start( [c17] )
s2.start( [c17] )

75. 69 | P a g e
s1.start( [c17] )
c17.start()
print"*** RunningCLI"
CLI( net)
print"*** Stoppingnetwork"
net.stop()
if __name__ == '__main__':
setLogLevel( 'info')
topology()
Customtopologyusingmininetexamplestopology
Mesh.py
"""Customtopologyexample
Two directlyconnectedswitchesplusahostfor eachswitch:
host--- switch--- switch--- host
Addingthe 'topos'dict witha key/valuepairtogenerate ournewlydefined
topologyenablesone topassin '--topo=mytopo'fromthe commandline.
"""

76. 70 | P a g e
frommininet.topoimportTopo
classMyTopo( Topo):
"Simple topologyexample."
def __init__( self ):
"Create customtopo."
# Initializetopology
Topo.__init__( self )
# Addhosts andswitches
S1 = self.addSwitch( 's1')
S2 = self.addSwitch( 's2')
S3 = self.addSwitch('s3')
S4 = self.addSwitch('s4')
H1 = self.addHost( 'h1')
H2 = self.addHost('h2')
SwitchList= (S1,S2,S3,S4)
# Addlinks
for index inrange(0,len(SwitchList)):
for index2inrange(index+1,len(SwitchList)):
self.addLink(SwitchList[index] ,SwitchList[index2])
self.addLink(H1,S1)
self.addLink(H2,S3)
topos= { 'mytopo':( lambda:MyTopo() ) }

77. 71 | P a g e
9 REFERENCES
1. http://searchsdn.techtarget.com/feature/OpenFlow-protocol-primer-Looking-under-the-hood
2. http://searchsdn.techtarget.com/tip/SDN-basics-Understanding-centralized-control-and-
programmability
3. http://searchdatacenter.techtarget.com/answer/How-does-the-OpenFlow-protocol-ease-
traffic-in-the-data-center-network
4. http://demo.ipspace.net/get/OpenFlow#Videos
5. https://www.youtube.com/watch?v=Vh3TAP9RIE8
6. http://www.ramonfontes.com/visual-network-description/
7. http://openvswitch.org/
8. http://mininet.org
9. http://sdn.cs.wisc.edu/bootcamp/session1
10. http://www.projectfloodlight.org/getting-started/
11. http://geni-app-developer-documentation.readthedocs.org/en/latest/examples/example-
3.html
12. http://www.openflowhub.org/blog/blog/2012/11/18/open-source-and-floodlight-the-biggest-
opportunity-for-sdn/
13. http://networkstatic.net/floodlight-openflow-controller-using-the-static-flow-entry-pusher/
14. http://openflow.marist.edu/avior/gettingstarted.html
15. http://www.techrepublic.com/blog/it-security/software-defined-networking-how-it-affects-
network-security/#.
16. http://www.opencontrail.org/i-studied-opencontrail/