ASSINGMENT NO.

AIM : Prepare setup for Mininet network emulation environment with the help of Virtual box and Mininet.
Demonstrate the basic commands in Mininet and emulate different custom network topology (Simple,
Linear, and Tree).View flow tables.

THEORY :

Mininet is one type of network emulator used to simulate the network with collection of end-hosts,
switches, routers and link on a single Linux kernel. The Mininet tool uses lightweight virtualization to
create a single system look like a complete network which running the same kernel, system, and user code.
Mininet is commonly used by the open source SDN community as a simulation, verification and testing
tool.
In SDN network simulation is done by using lightweight Mininet software. The platform like Mininet is
providing all required infrastructure to simulate network. Some of the requirements are
1. Speed of deployment
2. Predictable Output
3. Ease of use
For network simulation many tools are available. Three main options were discovered during research such
as Cisco Virtual Internet Routing Lab (VIRL), Mininet and virtualizing devices using images.
The Cisco proprietary software VIRL consists of real networking equipment operating systems in the form
of modifier images. Defining link parameters and graphical topology editor are some features of VIRL.
The experimental result with VIRL was conclude that it is unstable and requires significant memory
resources and difficulty for linking SDN controller to the devices.
The working experience with virtualized device images was quite good but problem with this method is
consumed high memory and slow start. Also additional configuration requires each device in order to work
with OpenFlow.
The Open source flexible Mininet software was created with support of OpenFlow. It is de facto standard
for making experiments with OpenFlow and SDN. It supports different types underlying controller
technologies. For this lab open vSwitch was chosen as open source, popular, reliable and efficient solution.
After consideration, Mininet was chosen as network simulation software. Also there some advantages of
Mininet such as low resource requirements and fast startup time. Device, topologies and links behavior can
be easily changed by scripting. More, Mininet interfaces can be easily listened by network sniffer.
The Mininet is switch oriented software so layer three functions such as routing protocols and MPLS should
be implemented on the controller. As the labs will be OpenFlow focused features of the SDN controllers
such as BGP-speaker, VPN tunneling or MPLS configuration are out of the main focus of the lab and their
lack is not significant.
Following figure shows a simple Mininet network comprised of three hosts, a virtual OpenFlow switch,
and an OpenFlow controller. All components are connected over virtual Ethernet links that are then
assigned private net-10 IP addresses for reachability. Mininet supports very complex topologies. Mininet
allows you to create custom topologies for that reason it mostly used for experimentation purpose.

Figure: Simple Mininet Network

Mininet Installation:
Native Installation from Source
This option works well for local VM, remote EC2, and native installation. It assumes the starting point of a
fresh Ubuntu, Debian, or (experimentally) Fedora installation.
We strongly recommend more recent Ubuntu or Debian releases, because they include newer versions
of Open vSwitch. (Fedora also includes recent OvS releases.)
To install natively from source, first you need to get the source code:

git clone https://github.com/mininet/mininet

Note that the above git command will check out the latest and greatest Mininet (which we recommend!)
If you want to run the last tagged/released version of Mininet - or any other version - you may check that
version out explicitly:

cd mininet
git tag # list available versions
git checkout -b mininet-2.3.0 2.3.0 # or whatever version you wish to install
cd ..

Once you have the source tree, the command to install Mininet is:

mininet/util/install.sh [options]

Typical install.sh options include:

 -a : install everything that is included in the Mininet VM, including dependencies like Open
vSwitch as well the additions like the OpenFlow wireshark dissector and POX. By default
these tools will be built in directories created in your home directory.
 -nfv : install Mininet, the OpenFlow reference switch, and Open vSwitch
 -s mydir : use this option before other options to place source/build trees in a specified
directory rather than in your home directory.
So, you will probably wish to use one (and only one) of the following commands:

To install everything (using your home directory): install.sh -a

To install everything (using another directory for build): install.sh -s mydir -a
To install Mininet + user switch + OvS (using your home dir): install.sh -nfv
To install Mininet + user switch + OvS (using another dir:) install.sh -s mydir -nfv

You can find out about other useful options (e.g. installing the OpenFlow wireshark dissector, if it’s not
already included in your version of wireshark) using
install.sh -h

After the installation has completed, test the basic Mininet functionality:

sudo mn --switch ovsbr --test pingall

Displaying Custom Topology on Miniedit

1-> sudo apt update
2-> sudo apt install python3-pip
3-> sudo pip3 install ryu
4-> sudo apt install git
5-> git clone https://github.com/mininet/mininet
6-> ls (to check the file mininet)
7-> cd mininet/
8-> ls (check file util)
9-> cd util/
10-> sudo ./install.sh -a (it will take long time 10 minutes)
11-> sudo mn
1->(mininet> pingall )
2->exit
12->sudo mn -c
14->sudo mn --topo single,3 --mac --switch ovsk --controller remote
1->pingall
2->exit
15->cd mininet/
16->sudo apt install python3
17->cd mininet/
18->cd examples/
19->cd sudo python3 ./miniedit.py

Mininet Commands
Interact with Hosts and Switches
Start a minimal topology and enter the CLI:

$ sudo mn
The default topology is the minimal topology, which includes one OpenFlow kernel switch
connected to two hosts, plus the OpenFlow reference controller. This topology could also be
specified on the command line with --topo=minimal . Other topologies are also available out of the
box; see the --topo section in the output of mn -h .
All four entities (2 host processes, 1 switch process, 1 basic controller) are now running in the
VM. The controller can be outside the VM, and instructions for that are at the bottom.
If no specific test is passed as a parameter, the Mininet CLI comes up.
Display Mininet CLI commands:

mininet> help

Display nodes:

mininet> nodes

Display links:

mininet> net

Dump information about all nodes:

mininet> dump

You should see the switch and two hosts listed.

If the first string typed into the Mininet CLI is a host, switch or controller name, the command is
executed on that node. Run a command on a host process:

mininet> h1 ifconfig -a

You should see the host’s h1-eth0 and loopback ( lo ) interfaces. Note that this interface ( h1-eth0 )
is not seen by the primary Linux system when ifconfig is run, because it is specific to the network
namespace of the host process.
In contrast, the switch by default runs in the root network namespace, so running a command on
the “switch” is the same as running it from a regular terminal:

mininet> s1 ifconfig -a

This will show the switch interfaces, plus the VM’s connection out ( eth0 ).
For other examples highlighting that the hosts have isolated network state, run arp and route on
both s1 and h1 .
It would be possible to place every host, switch and controller in its own isolated network
namespace, but there’s no real advantage to doing so, unless you want to replicate a complex
multiple-controller network. Mininet does support this; see the --innamespace option.
Note that only the network is virtualized; each host process sees the same set of processes and
directories. For example, print the process list from a host process:

mininet> h1 ps -a

This should be the exact same as that seen by the root network namespace:

mininet> s1 ps -a

It would be possible to use separate process spaces with Linux containers, but currently Mininet doesn’t
do that. Having everything run in the “root” process namespace is convenient for debugging, because it
allows you to see all of the processes from the console using ps , kill , etc.

Test connectivity between hosts

Now, verify that you can ping from host 0 to host 1:

mininet> h1 ping -c 1 h2

If a string appears later in the command with a node name, that node name is replaced by its IP address;
this happened for h2.
You should see OpenFlow control traffic. The first host ARPs for the MAC address of the second, which
causes a packet_in message to go to the controller. The controller then sends a packet_out message to
flood the broadcast packet to other ports on the switch (in this example, the only other data port). The
second host sees the ARP request and sends a reply. This reply goes to the controller, which sends it to
the first host and pushes down a flow entry.
Now the first host knows the MAC address of the second, and can send its ping via an ICMP Echo
Request. This request, along with its corresponding reply from the second host, both go the controller and
result in a flow entry pushed down (along with the actual packets getting sent out).

Repeat the last ping :

mininet> h1 ping -c 1 h2

You should see a much lower ping time for the second try (< 100us). A flow entry covering
ICMP ping traffic was previously installed in the switch, so no control traffic was generated, and the
packets immediately pass through the switch.
An easier way to run this test is to use the Mininet CLI built-in pingall command, which does an all-
pairs ping :

mininet> pingall
Changing Topology Size and Type
The default topology is a single switch connected to two hosts. You could change this to a different topo
with --topo , and pass parameters for that topology’s creation. For example, to verify all-pairs ping
connectivity with one switch and three hosts:
Run a regression test:

$ sudo mn --test pingall --topo single,3

Another example, with a linear topology (where each switch has one host, and all switches connect in a
line):

$ sudo mn --test pingall --topo linear,4

Parametrized topologies are one of Mininet’s most useful and powerful features.

OUTPUT:
CONCLUSION : Thus we have Prepared setup for Mininet network emulation environment with the help
of Virtual box and Mininet. Demonstrated the basic commands in Mininet and emulate different custom
network topology.
 ASSIGNMENT NO: 2

AIM: After studying open source POX and Floodlight controller, Install controller and run custom
topology using remote controller like POX and floodlight controller. Recognize inserted flows by
controllers.

THEORY

FLOODLIGHT

The Floodlight is very popular Open SDN Controller which is Java based, Apache-licensed an Enterprise-
class controller. It is supported by community of developers including a number of engineers from Big
Switch Networks. Big Switch Networks is a market leader in Software-Defined Networking and a strong
proponent of OpenFlow technology. Floodlight SDN controller that used Beacon controller as its
foundation, as beacon is an open source controller developed at Stanford.
Before we dig deep into Floodlight Controller, let like to clarify the term ‘Floodlight’ as it is used by the
Big Switch’s opensource program. The term ‘Project Floodlight’ is used as an umbrella-term to cover
multiple projects such as Floodlight Controller, Indigo, LoxiGen, and OFTest.
When we run the controller, both northbound and southbound operations of the controller become active
and the controller as well as set of configured module applications will run too. The northbound REST
APIs exposed by all the running modules becomes available via the specified REST port. To retrieve the
information and invoke the services, the applications can interact with each other by sending the http REST
command. At the southbound, the floodlight provider module will start start listening on the OpenFlow-
specified TCP-port for connections from the OpenFlow switches.Floodlight supports OpenFlow version
1.0, 1.3 and 1.4 are in the pipeline process. It is robust and easy to use controller.
POX

POX provides a framework for communicating with SDN switches using either the OpenFlow or OVSDB
protocol. Developers can use POX to create an SDN controller using the Python programming language.
It is a popular tool for teaching about and researching software defined networks and network applications
programming.

POX can be immediately used as a basic SDN controller by using the stock components that come bundled
with it. This is the scenario we will cover in this tutorial.

Developers may create a more complex SDN controller by creating new POX components. Or, developers
may write network applications that address POX’s API. In this tutorial, we only briefly discuss
programming for POX.

POX components

POX components are additional Python programs that can be invoked when POX is started from the
command line. These components implement the network functionality in the software defined network.
POX comes with some stock components already available.

The POX stock components are documented in the POX Wiki and the code for each component can be
found in the ~/pox/pox directory on the Mininet 2.2 VM image.
OUTPUT:
CONCLUSION : Thus we have studied open source POX and Floodlight controller and installed
controller and implemented program to run custom topology using remote controller like POX and
floodlight controller.
 ASSIGNMENT NO: 3
AIM: Create a SDN environment on Mininet and configure a switch to provide a firewall functionality
using POX controller.

THEORY:

Firewalls:
A Firewall is a necessary part of any security architecture and takes the guesswork out of host
level protections and entrusts them to your network security device. Firewalls, and especially
Next Generation Firewalls, focus on blocking malware and application-layer attacks, along
with an integrated intrusion prevention system (IPS), these Next Generation Firewalls can react
quickly and seamlessly to detect and react to outside attacks across the whole network. They
can set policies to better defend your network and carry out quick assessments to detect invasive
or suspicious activity, like malware, and shut it down.

Need Firewalls

Firewalls, especially Next Generation Firewalls, focus on blocking malware and application-
layer attacks. Along with an integrated intrusion prevention system (IPS), these Next
Generation Firewalls are able to react quickly and seamlessly to detect and combat attacks
across the whole network. Firewalls can act on previously set policies to better protect your
network and can carry out quick assessments to detect invasive or suspicious activity, such as
malware, and shut it down. By leveraging a firewall for your security infrastructure, you’re
setting up your network with specific policies to allow or block incoming and outgoing traffic.

SDN firewall on POX controller:

Software Defined Network (SDN) is a revolutionary networking paradigm system in which

network control plane is separated from data plane and assigned to a devoted software
program called controller running at a control layer. SDN makes networks wholly controlled
through software applications and gives a hope to change the limitations of current networks
infrastructures. Since the emergence of SDN, it has introduced a radical change in network
architecture which simplified the control of networks, but on the other hand many challenges
have arisen. One of the fundamental issues which exposed due to the new architecture of
SDN is the security risks. Network firewall is an essential component for securing traffic by
enforcing security policies. This study aims to implement some firewall functionalities on
SDN through writing some firewall applications that run on the top of the SDN POX
controller. The firewall application which is working at layer2, layer3 and layer4 capable of
detecting the traffic and enforcing specified rules. Our firewall filters packets based on their
headers and matches them against the predefined policies. If there is matching found, the
packet is blocked otherwise it is forwarded. We have selected POX a python-based SDN
controller and Open vSwitch for the experiment.

CODE:
from mininet.net import Mininet
from mininet.cli import CLI
from mininet.link import Intf
from mininet.log import setLogLevel, info
from mininet.node import Controller, OVSKernelSwitch, RemoteController

def myNetwork():

net = Mininet( topo=None,controller=RemoteController)

info( '*** Adding controller\n' )

c0 = net.addController('c0', controller=RemoteController, ip="172.16.87.155")
info( '*** Add switches\n')
s1 = net.addSwitch('s1')
s2 = net.addSwitch('s2')
 s3 = net.addSwitch('s3')

info( '*** Add hosts\n')

h1 = net.addHost('h1', ip="10.0.0.1")
h2 = net.addHost('h2', ip="10.0.0.2")
h3 = net.addHost('h3',ip="10.0.0.3")
h4 = net.addHost('h4',ip="10.0.0.4")
h5 = net.addHost('h5',ip="10.0.0.5")
h6 = net.addHost('h6',ip="10.0.0.6")

info( '*** Add links\n')

net.addLink(h1, s1)
net.addLink(h2, s1)
net.addLink(h3, s1)
net.addLink(s1, s3)
net.addLink(s2, s3)
net.addLink(h4, s2)
net.addLink(h5, s2)
net.addLink(h6, s2)
info( '*** Starting network\n')
net.start()
CLI(net)
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
myNetwork()
OUTPUT:
CONCLUSION : Thus we have studied and Created a SDN environment on Mininet and configured a
switch to provide a firewall functionality using POX controller.
 ASSIGNMENT NO: 4

AIM: Using Mininet as an Emulator and POX controller, build your own internet router. Write simple
router with a static routing table. The router will receive raw Ethernet frames and process the packet
forwarding them to correct outgoing interface. You must check the Ethernet frames are received and the
forwarding logic is created so packets go to the correct interface

THEORY:

OpenFlow Controller
Modern Internet switches make millions of decisions per second about whether or not to forward an
incoming packet, to what set of output ports it should be forwarded, and what header fields in the packet
may need to be modified, added, or removed. This is a very complex task.
The OpenFlow control plane (controller) differs from the legacy control plane in three key ways.
1) It can program different data plane elements with a common, standard language such as OpenFlow.
2) It exists on a separate hardware device than the forwarding plane, unlike traditional switches, where
the control plane and data plane are instantiated in the same physical box. This separation is made
possible because the controller can program the data plane elements remotely over the Internet.
3) The controller can program multiple data plane elements from a single control plane instance.
The OpenFlow controller is responsible for programming all the packet-matching and forwarding rules
in the switch. Whereas a traditional router would run routing algorithms to determine how to program
its forwarding table, that function or an equivalent replacement to it is now performed by the controller.
Any changes that result in recomputing routes will be programmed onto the switch by the controller.

Routing Table –
A routing table is a set of rules, often viewed in table format, that's used to determine where data packets
traveling over an Internet Protocol (IP) network will be directed. This table is usually stored inside the
Random Access Memory of forwarding devices, such as routers and network switches.
Static Routing –
static routing is a form of routing that occurs when a router uses a manually-configured routing entry, rather
than information from dynamic routing traffic. In many cases, static routes are manually configured by a
network administrator by adding in entries into a routing table, though this may not always be the case

Basic Packet Forwarding

After receiving the packet, switch performs the functions as shown in figure 2.9 The switch starts by
performing a table lookup in the first flow table and may perform table lookup in other flow tables based
on pipeline processing.

Figure2.9 Basic Packet forwarding with OpenFlow Switch

There can be two types of flow entry

1) Exact match – when all the parameters of the flow entry are uniquely defined and there is no wild
card field. They always have highest priority.

2) Wildcard match - When any one parameter of the Flow entry is wildcard then it is known as wild
card flow entry. A wild card flow entry can match more than one type of packets

If a packet satisfy the matching condition of both exact and wildcard flow entries than it will hit the exact
flow entry.
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. Then, the switch updates the counters of that flow table
entry. Finally, the switch performs the actions specified by the flow table entry on the packet, e.g., the
switch forwards the packet to a port.
Otherwise, if no flow table entry matches the packet header, the switch generally notifies its controller
about the packet, which is buffered when the switch is capable of buffering. To that end, it encapsulates
either the unbuffered packet or the first bytes of the buffered packet using a PACKET-IN message and
sends it to the controller; it is common to encapsulate the packet header and the number of bytes defaults
to 128. The controller that receives the PACKET-IN notification identifies the correct action for the packet
and installs one or more appropriate entries in the requesting switch. Buffered packets are then forwarded
according to the rules; this is triggered by setting the buffer ID in the flow insertion message or in explicit
PACKET-OUT messages. Most commonly, the controller sets up the whole path for the packet in the
network by modifying the flow tables of all switches on the path.

CODE:
from mininet.topo import Topo
from mininet.net import Mininet
from mininet.node import Node
from mininet.log import setLogLevel, info
from mininet.cli import CLI
class LinuxRouter( Node ):
"""A Node with IP forwarding enabled.
Means that every packet that is in this node, comunicate freely with its interfaces."""
def config( self, **params ):
super( LinuxRouter, self).config( **params )
self.cmd( 'sysctl net.ipv4.ip_forward=1' )
def terminate( self ):
self.cmd( 'sysctl net.ipv4.ip_forward=0' )
super( LinuxRouter, self ).terminate()
 class NetworkTopo( Topo ):
def build( self, **_opts ):
r1=self.addNode("r1",cls=LinuxRouter,ip=None)
r2=self.addNode("r2",cls=LinuxRouter,ip=None)
r3=self.addNode("r3",cls=LinuxRouter,ip=None)

self.addLink(r1,r2,params1={ 'ip' : '10.0.0.1/24' },params2={ 'ip' : '10.0.0.2/24' })

self.addLink(r2,r3,params1={ 'ip' : '10.0.1.1/24' },params2={ 'ip' : '10.0.1.2/24' })
topo = NetworkTopo()
net = Mininet( topo=topo )
net.start()
#ip route add ipA via ipB dev INTERFACE
#every packet going to ipA must first go to ipB using INTERFACE
net["r1"].cmd("ip route add 10.0.1.2 via 10.0.0.2 dev r1-eth0")
net["r3"].cmd("ip route add 10.0.0.1 via 10.0.1.1 dev r3-eth0")
#this command is just to r3 ping r2 work, because it will use the correct ip
net["r3"].cmd("ip route add 10.0.0.2 via 10.0.1.1 dev r3-eth0")
net.pingAll()
CLI( net )
net.stop()
OUTPUT
CONCLUSION : Thus we have studied and Using Mininet as an Emulator and POX controller, build our
own internet router. The router receives raw Ethernet frames and process the packet forwarding them to
correct outgoing interface.
 ASSIGNMENT NO. 5

AIM: Study in details Cloud seeds automates IAAS using SDN and a high-performance network from
Juniper SDN Framework.

THEORY:

Juniper Networks, Inc. is an American multinational corporation. The company develops and markets
networking products, including routers, switches, network management software, network security
products, and software-defined networking technology.

To realize its vision of a new class of automated IaaS services, CloudSeeds needed to create a new network
platform, one that provided seamless, high-performance routing, switching, SDN, and security.

CloudSeeds has developed A.C.R.E. (Advanced Cloud Resource Elements), which uses standard prebuilt
cloud components to create a highly dynamic Infrastructure-as-a-Service (IaaS) layer combining deep
automation and complete virtualization to create turnkey solutions for its customers.

To realize its vision of a new class of automated services, CloudSeeds needed to create a new network
platform, providing seamless, high-performance routing, switching and intense security measures.
Most critically, it needed an open architecture that could be controlled and configured by software.
CloudSeeds, based in Hamburg, Germany, was founded in 2013 to help establish virtualized
infrastructures and IT services to companies that are growing rapidly and need scalability for
their business objectives.

Kevin Fibich, founder and managing director at Cloud Seeds, had worked in a number of operational
IT environments and recognized the need for a new class of software-defined IT services based
on a highly scalable, flexible, and automated platform. CloudSeeds developed its new approach,
known as A.C.R.E. (Advanced Cloud Resource Elements), using standard pre-built cloud components
creating a
highly dynamic laaS (Infrastructure-as-a-Service) layer-combining deep automation and complete
virtualization to create turnkey solutions for its customers. The platform delivers new data
center and IT infrastructure that can scale as its customers' needs change and grow, without
customers having to worry about the day-to-day management of IT hardware. CloudSeeds
operates dedicated cloud setups for their customers-managed and operated on its premises-as
data security is a key topic in the German commercial enterprise sector with customers pressing
for data sovereignty.

Kevin Fibich said, "Our customers can sometimes be overwhelmed by their own

rapid success and as a result they need to rapidly deploy new infrastructure. We call this a
'friendly DDoS' (distributed denial of service) attack, as their existing network may be
overwhelmed by legitimate customer demand. It is a luxury problem for
them to have, and our automated software-defined services help them overcome it."

CloudSeeds is enjoying high growth as it takes on new customers, attracted by the business
flexibility and scale it offers, and is currently expanding its team.

Business Challenge To help create virtualized infrastructures and provide IT services to its customers,
CloudSeeds needed an open architecture that could be controlled and configured by third-party software.
It also needed a network platform that could scale ahead of its requirements, and provide a highly resilient
service to enable its customers’ businesses to grow.

Technology Solution CloudSeeds used a number of Juniper systems to create its new software-defined
A.C.R.E. platform. These include the QFX5100 Ethernet Switch, MX80 3D Universal Edge
Router, SRX1400 and vSRX Services Gateways, and Contrail Networking to orchestrate the network and
create different virtual networks.

Business Results The new network has made CloudSeeds’ vision of zero-touch provisioning a reality. At
the same time, the Juniper solution allows the rapid uptake of IaaS services by CloudSeeds’ customers,
making their businesses far more agile and responsive."
PRODUCT FAMILY

Technology Product families

 T-series: Multichassis IP/MPLS Core Routers

 MX Series: Edge routers
 M Series: Combined IP/MPLS edge routers
Routing
 PTX Series: Packet transport routers
 ACX Series: Universal access routers

 EX Series: Enterprise Ethernet switches

 WLAN Products: Controllers, access points and software
Switching
 QFX Series: Datacenter switches

 SRX Series: Security products for data centers and branch locations
Security

 Junos Operating System

 Junos Space: Service Oriented Architecture development environment for network
applications
 Contrail: Brand of software defined networking software and networking
Software
controllers
 Marvis: Mist's AI Network Assistant that is also compatible with Juniper's switches
through its Wired Assurance feature.

 AP41: The most popular enterprise-grade Access Point available through Mist.
Tailored for WiFi, BLE, and IoT.
WLAN  AP43: An upgraded AP41 with WiFi 6
 AP61: A long-range access point ideal for outdoor use like college campuses
Contrail

Contrail offers intelligent networking, increased security, and advanced analytics—all with automation—
for multicloud and telco cloud.

MX Series Routers

A robust portfolio of SDN-enabled routers, the MX Series provides industry-leading system capacity,
density, security, and performance with unparalleled longevity.
QFX Series Switches

QFX network switches deliver industry-leading throughput and scalability, a comprehensive routing stack,
the open programmability of Junos OS, and the broadest set of EVPN-VXLAN and IP fabric capabilities.
Find your solution for data center spine and leaf switches, campus distribution and core, or data center
gateway and interconnect.
CONCLUSION : Thus we have studied in details Cloud seeds automates IAAS using SDN and a high-
performance network from Juniper SDN Framework.