DEPARTMENT OF COMPUTER SCIENCE

AND ENGINEERING

CCS365 – SOFTWARE DEFINED NETWORKS

REG.NO…………………………………..…
NAME……………………………………….
 SRI RANGAPOOPATHI COLLEGE OF ENGINEERING
Alampoondi-604 151, Gingee - TK

BONAFIDE CERTIFICATE
NAME :

YEAR/SEM : Third / Sixth

BRANCH : Computer Science and Engineering

SUBJECT CODE : CCS365

SUBJECT NAME : SOFTWARE DEFINED NETWORKS

REGISTER NO :

Certified that this is a bonafide record of work done by the above student in the

CCS365 – SOFTWARE DEFINED NETWORKS LABORATORY during the Academic

year

Signature of Staff in charge Head of the Department

Submitted for the Practical Examination Held On

Internal Examiner External Examiner

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

[CCS365 SOFTWARE DEFINED NETWORKS LABORATORY]

FIFTH SEMESTER
EX.NO DATE NAME OF THE PAGE MARKS FACULTY
EXPERIMENTS NO SIGNATURE

1 Lab1: Introduction to SDN

2
Lab2: Renaissance, a self-stabilizing
control plane

3 Lab3:Adding Fault Tolerance to

Renaissance

Setup your own virtual SDN lab

i)VirtualBox/MininetEnvironmen
4 t for SDN - http://mininet.org
ii) https://www.kathara.org
iii) GNS3

Create a simple mininet topology with

SDN controller and use Wireshark to
capture and visualize the OpenFlow
5
messages such as OpenFlow FLOW
MOD, PACKET IN, PACKET OUT
etc.

Create a SDN application that uses

the Northbound API to program
6 flowtable rules on the switch for
various use cases like L2 learning
switch, Traffic Engineering, Firewall
etc.
Create a simple end-to-end network
service with twoVNFs using vim-
7 emu
https://github.com/containernet/vim-
emu 5) Install OSM and onboard and
orchestrate network service.
EX.NO:1 Introduction to SDN

DATE:

General Instructions

 In this series of labs, we will look at more advanced concepts in computer networks. We will
focus on Software Defined Networks (SDN), a new paradigm in network management used
nowadays in many large-scale deployments.
 The successful completion of the labs requires your provision of a report for each lab. All
exercises in the instructions must be answered unless stated otherwise. Your answers should
be concise; you don’t need more than a few lines to answer each question. Questions that
needs to be answered are within boxes. Some exercises ask you to discuss with your lab
partner. You do not need to provide written answers to those questions.
 Youshouldcompletethelabsingroupsoftwopersons—usethegroupyou’vecreated in ping pong
!You are of course encouraged to discuss with other groups, but all your submissions must be
the results of your own work. Once finished, upload your solution as a PDF document toping
pong, and don’t forget to identify both members of the group.
 Addition al documents, such as source code, are available on ping pong.
 It is assumed that you run the labs in the windows environment at Chalmers. We use a virtual
machine and Virtual Box to have access to a linux environment. You may use your own
computer, however we might not be able to provide support in that case.
 If you haven’t done it yet, please watch he videos on SDN by David Mahler. A link is
given on ping pong.

Software Defined Networks

 In conventional networks, the control and management are done locally by dedicated equip-
ment, such as routers and switches. Special algorithms, rules sets and specific hardware
(ASICs) are used to perform operations like packet routing and flow forwarding. Configura-
tion is device-centric, and topology changes, require human intervention or long transition
phases to come back to normal performance. The lack of flexibility can especially hinder
performances in high traffic networks such as Internet Service Providers backbones and
within datacenters.
 In SDN, the control and data planes are decoupled. The forwarding logic can now be programmed
and is not integrated into the hardware as before. The control plane can there forefully observe the
system and sends commands to the element so the data plane to configure them.
 The control plane is composed of one or more controllers. A controller centrally defines the
behavior of the network, by computing forwarding rule son request. Switches compose most
of the elements of the data plane (along with routers) and are called learning switches.
 Applicationplane Application

Controller
ControlPlane

DataPlane
Switch

Figure1:Architecture of Software Defined Networks(SDN)

Setup

 We will experiment with Software Defined Networks using Mininet 1.Mininet is a network
emulator that can emulate switches, controllers and execute application code. It is available
for many Linux distributions. If you are already using Linux, you can install it directly,
although were commend you to use a virtual machine (VM). Mini net makes updates to your
network interfaces to work and might affect your system.
 We will use VirtualBox2to run our virtual machine. Virtual Box is available for Windows,
Mac OS, and Linux. You can use another hypervisor of your choice, but be aware that we
will only support you for technical problems if you use Virtual Box.
 A virtual machine has been prepared for you. Download it on
pingpongorathttp://www.cse.chalmers.se/~ poirotv/files/EDA387_sdn.ova.zip.
 Start Virtual Box and use File →Import Appliance. Import the VM we gave you. It might
take a few minutes. Once it is done, you can start the VM. The credentials are given in the
following table:

User Password
sdn sdn
Table1:Virtual Machine Credentials

 Please refer to the appendix if you want to create your own virtual machine.

Testing your environment

 You should now have a working environment. You can try to start a very simple network with
the command:
1
http://mininet.org/2https://www.virtualbox.org/
wiki/Downloads

 $sudomn

 If everything is working, you should see something like this:

 Figure2: Starting Mininet

 You can now interact with the newly created network using the Command Line Interface
(CLI).By default, Mini net creates a network composed of two host machines, h1andh2, and
a switch in between,s1.A native controllerc0is also present. You will now try the connectivity
between the two hosts. Try the command ping all. You should see that no packets are
dropped. You can also try iperfto see the available bandwidth. Now, ping from one specific
host by using h1pingh2. Finally, you can execute any bash commands on a specific host by
using x term h1, where you replace h1by the name of the host. Once the new terminal is
created, check the network interfaces with if config. Once you are done, use the command
exit in the mini net CLI to stop the network.

Important!
Later on, Mini net might crash if you have errors in your scripts. Mini net won’t be able
to start anymore if that’s the case. To correct this behavior, use:
$sudomn-c
The-coption will clean Mini net’s internal files.

Part1-NetworkDiscovery

 Your environment is now ready and you should know how to interact with mininet. In this
first part, we will take a closer look at how OpenFlow creates the forwarding rule.
 From a terminal, go to the floodlight directory (in the VM we gave you, floodlight is located
in ∼/labs/lab1/) and starts your controller with the command:
 $java−jartarget/floodlight.jar

 It takes a few seconds to initialize the controller. Once it is ready (you should see Sending
LLDPpacketsoutofalltheenabledportsprintedregularly),openasecondterminaland
 Start the custom network topology we gave you, with the command:
 $sudopythontopolab1.py

 If everything is working correctly, you should see that the controller registered as witch.
 Question 1.In a conventional network, how can a switch know where to forward
an incoming packet? Please explain briefly the mechanism.
Question2.Ping from one host to another. You should see that at the very
beginning, the RTT is significantly longer. Why? Stop pinging and wait for
about 30 seconds, and try again. Is the RTT now stable? Why?
Question3.Plot the Round Trip Time(RTT)evolution over time. You need to
produce a plot with the run time as the x-axis and the RTT time as they-axis.
You need two curves, the RTT from h1 to h2, and the RTT from h2 to h1. One
measurement is not enough! You will need to rest ar both the network and the
controller many times and average over multiple measures.
Remember, if Mini net crashes or has any problem, use the command:$sudomn-c

Part2-UnderstandingOpenFlow

 We saw just before that a switch must learn what action it should execute if it receives a new
packet. We will now take a closer look at how OpenFlow behave in the presence of new
flows.
 Open anew terminal. Start Wire shark in super user mode with the command sudo wire shark
(at start up, a massager or should appear, this is normal).Start capturing in coming packets on
the loopback interface (lo).To only display the important packets, use openflow v4as the
display filter (don’t forget to press enter to activate the filter).In the other terminals, start the
controller and the mininet topology as before. You should see new traffic appearing in Wire

Question4.Explaintherolesofthedifferentpacketsyousee.Youcanusehttp:
//flow grammable.org/sdn/openflow/message-layer/ to understand them. We are
usingOpenflow1.3.Do not describe all the packets, but only the most important
ones! Typically at the very beginning, once the switch contacts the controller,
and when a new packet is received.

 We will now directly look into the memory of the switch. Open vSwitch, the software used to
run virtual switches, offers a command to look into the details of OpenFlow, ovs-ofctl.As
with Wires hark, you can see the communications between your switch and your controller.
Run
 $sudo ovs−ofctl snoop s1 −O OpenFlow13 You can

also just check the switch’s state with

 $sudoovs−ofctlshows1−OOpenFlow13
 Start pinging between the two hosts again. Now execute the command
 $sudo ovs−ofctl dump−flows s1 −O OpenFlow13 You

should see three flows.

 Question5.Explainwhateachflowrepresents.Brieflyexplainwhateachfieldis used for.
Question6.Imagine now that a web server is running on h1.h2 starts an HTTP request to
h1.What will happen? Describe briefly the messages exchanged between the switch and the
controller, and the flows that would appear in the dump-flows result. Note: you can try to
emulate the behavior by opening a terminal on h2 and by using the wget command and python-
m Simple HTTP Server.

Part3-Floodlight’sUserInterface

 We have seen how SDN work from the user perspective, and from the switch perspective. We will
now investigate how the controller views the network.
 Floodlight has two interfaces we can use: an API, and a user interface. While both the
network and the controller are running, connect to http://localhost:8080/ui/index. html.
 You should see a dashboard appearing, with the switches and the hosts discovered by the
controller. Look at the topology and discuss with your partner the different elements. Go then
to the Switches tab, and select the switch. Start pinging again. In the Flows table, do you see
the same flows as before? Discuss with your partner.
 Stop the network and the controller. We will now try a different topology. Start again the
controller, and start a new network with the command:
 $sudomn−−topo=tree,depth=3−−controller=remote,ip=0.0.0.0,port=6653

Question 7.How many switches are present ? What kind of topology is it? How
many switches must be programmed to ping from h1 to h8?

 We try again with a different topology, linear this time.

 $sudomn−−topo=linear,n=1,k=7−−controller=remote,ip=0.0.0.0,port=6653

Question8.How does the first RTT evolve with the number of switches to
cross?

Conclusion

 Inthislab,welookedatSDNasanewparadigmfornetworkmanagement.Weintroduced
theconceptsofcontrollersandlearningswitches,andhowOpenFlowallowsustoprogram
 our switches for flow forwarding. In the next lab, we will introduce you to the concept of
self-stabilizing control plane, and how we can tolerate failures in SDN.
 For the next lab, please read Renaissance: Self-Stabilizing Distributed SDN
Control Plane(the paper is present on ping pong).We do not require you to fully
understandallthedetailsofthepaperortobeabletodotheproofs.Butpaycloseattention
to algorithm 1, you will work with an implementation of that system during the
next session.

Appendix

Creating your own VM

 On your favorite OS,use the command:

 $sudoapt−get install it ant wire shark

 Git is a version control system, we will use it to download and install a specific version of
Mininet. Ant is used to build Java applications, and Wireshark 3is a packet analyzer that
listens and records all communications in the network.
 Once this is done, we will one the Mininet repository from Github. Use the command:
$gitclonehttps://github.com/mininet/mininet.gitmininet

 This will create directory and copy all the files .You then need to install Mininet. From the
same location, execute the following command:
$./mininet/utils/install.sh−rmf−V2.5.5−3

 By doing so, you are installing mininet and OpenFlow version1.3.

 Finally, we will use Floodlight4as our OpenFlow controller. It is open-source and written in
Java. Gotohttp://www.projectfloodlight.org/download/and download the version 1.2. To build
the controller, just use
 $ant build

 From with in the flood light repository.

Authors

 ThisseriesoflabswerecreatedbyValentinPoirot<poirotv@chalmers.se>andEmelie Ekenstedt
<emeeke@student.chalmers.se>.

 3
https://www.wireshark.org/4http://www.projectfloodlight.org/floodlight/
EX.NO:2 Renaissance, a self-stabilizing control plane
DATE:

General Instructions

 In this lab and the nextone, we will go more in-depth into SDN and we will investigate a self-
stabilizing control plane. We are giving you two controllers: a global controller and a local
controller. if you have not done it yet, please read the paper Renaissance: Self-Stabilizing
Distributed SDN Control Plane[2] present in ping pong.
 The successful completion of the labs requires your provision of a report for each lab. All
exercises in the instructions must be answered unless stated otherwise. Your answers should
be concise; you don’t need more than a few lines to answer each question. Questions that
needs to be answered are within boxes. Some exercises ask you to discuss with your lab
partner. You do not need to provide written answers to those questions.
 You should complete the labs in group softwopersons—use the group you’ve created in ping
pong! You are of course encouraged to discuss with other groups, but all your submissions
must be the results of your own work. Once finished, upload your solution as a PDF
document toping pong, and don’t forget to identify both member so the group.
 Addition al documents, such as source code, are available on pingpong.
 It is assumed that you run the labs in the windows environment at Chalmers. We use a virtual
machine and Virtual Box to have access to a linux environment. You may use your own
computers, however we might not be able to provide support in that case.

In-band and Out-of-Band Controllers

 Deploying a software-defined network can take two forms: with an in- band control plane,
where both the control and data planes are using common physical links, or with an out-of-
band control plane, where dedicated physical links are used to connect the switches and the
controllers.

 The latter is more expensive, since an operator must now maintain two physical networks,
but is usually a more reliable solution. In in-band deployments, the control traffic and the
data traffic are competing for the bandwidth, and link failures can cause a loss of connectivity
for the control plane, which cannot operate the necessary forwarding to support topology
changes.
 In-BandControlPlane Out-of-BandControlPlane

Figure1:Architecture of Software Defined Networks(SDN)

 In this lab, we will take a look at an in-band control plane, i.e. controllers are running on
hosts with in the network, unlike the precedent lab where the controller was running outside
the network.
Renaissance, Local and Global Controllers

 This time, you will have at your disposal modified version of the Floodlight controller. The
Renaissance algorithm has been (partially) implemented, and you will have to complete it.
Your modification should be consistent with the algorithm, i.e. it should guarantee that every
switch will be managed by a least one non-faulty controller and eventually that every non-
faulty controller will reach every switch in the network, and this with in a bounded delay of
communication with a bounded number of failures.
 We give below a high-level description of the algorithm. For more details, please see the
paper in ping pong.
 For simplicity, our implementation has split the task of discovering and computing paths in
the network from actually installing them at the switches by introducing a local and a global
controller. The global controller takes the role of making decisions of which rules should be
installed and keeps track of all switches in the network, while the local controller translates
the instructions that the switches receive from the global controller into instructions that they
understand.
 We will focus for now on the global controller. You can assume that the local controller
implementation is correct, but feel free to check how it works.

Part1-GlobalController

 In the floodlight global/src/main/java/net/floodlight controller/global controller/ directory,

open Global Controller. java. You will find here the(partial) implementation of Renaissance.

Algorithm1: Renaissance,high-level codedescription.[2]

1 Localstate:responses⊆ {m(j):pj∈ P}has the most recently received query replies;
2 curr Tag and prev Taga repi’scurrent and previous synchronization round, respectively;
3 Interface:myRules(G,j,tag):returns the rules of pi ons witch pj given at opology
Gon round tag;
4 doforever begin
 5 Remove from responses any reply from unreachable senders or not from round pre Tag
or curr Tag. Also, remove from responses any response from pi and then add a
record that includes the directly connected neighbors, N c(i); according to the
accumulated local topology, G, in responses then
7 Store curr Tag’s value in prev Tag and get a new and unique tag for curr Tag;
8 foreach switch pj∈ PS and pj’s most recently received reply do
9 if this is the start of a new synchronization round then
10 Remove from pj’s configuration any manager pk orruleo fpk that was
not discovered to be reachable during round prev Tag;
11 Add pi in pj’s managers (if it is not already included)and replace pi’s
12 foreachpj∈ Pthatisreachablefrompiaccordingtothemostrecentlyreceivedrepliesin
Responses do
13 sendtopj(withtagcurrTag)anupdatemessage(ifpj∈ PSisaswitch)andquery
pj’s configuration;

14 up on query reply m from pj begin

15 if there is no space in responses for storing m then
16 performa C-reset by including in responsesonly the direct neighborhood,Nc(i)
17 if m’s tag equals to curr Tag then include m in responses after removing the
previous response from pj;
18 up on arrival of a query(with a sync Tag) from pj begin
19 send to pj a response that includes the local topology, Nc(i), and sync Tag

The goal is to familiarize your self with the code. You should be able to
understand and explain what is the main function of each section. Discuss them
with your partner. You do not need to write your discussion in the report.

Attributes

 Lines 70 to 94 contains the different attributes used throughout the algorithm, such as the tags
associated to the iteration (here called previous Label and current Label), the set of all nodes
discovered so far (discovered Nodes), and the set of nodes to query for this iteration (querySet).
 Let us go abitfurther down in the code.
a. Main Task

o 171 public void start Up(Flood light Module Context context)throws Flood light
Module Exception{

o 186 install RulesTask=new Single ton Task (ses, new Runnable(){

o 187 @Override
o 188 public void run(){

 This is the main task of the algorithm. It is rescheduled and executed periodically. It
 corresponds to the doforever loop of Alg. 1.

b. NetworkQueries

o 432 private void query Network(){

 The query Network method implements the foreach loop, line12, ofAlg.1.

c. Topology

o 524 private void create Topology(Responser,List<SwitchNode>sNodes)

 The create Topology method allows the controller to build the topology only with the directly
connected neighbors of queried switches.

d. Paths

o 579 private String find Paths (Switch Node dpid1, Switch Node dpid2, List
<SwitchNode> pathNodes)

 As you can see, the implementation nof this function is missing.

 To keep the network operational, the global controller must compute the port used for forwarding
packets from one switch to any other point of the network. Find Paths construct a tree and do a
Breadth - First Search(BFS) to obtain the path.
 Thefunctionreturnstheporttouseontheswitchdpid1tocontacttheswitchdpid2.

e. Receive

o 715 public net.flood light controller. core. IListener. Command receive (IOFSwitch
ofSwitch, OFMessage message, Floodlight Context context)

 The controller executes receive upon reception of a packet. If the message can be decoded as a
control packet, a switch statement calls the correct method. If the message is not for the control
plane, e.g.a ping, it must be forwarded to the correct destination.
Part2-Running Renaissance

 Now, you’ll try to run the controllers in a network. Three different topologies are given in
pingpong:

• B4,Google’swide-areaSDN[3];

• Clos, afat-tree data-center architecture[1];and

• The back bone of Telstra, an Australian ISP[4].

 To run a network, you must first start with the controller, like in the previous lab. Start the local
controller. As you can see, it takes a few seconds for the controller to boot. Now, start the
network with the command:
 1$sudopythonb4.py
 The local controller should register all the new switches directly.
 We now want to start the global controller in-band. To do so, you need to open a terminal on one
of the hosts (xtermh1).Navigate to the location of the global controller, and start it.
 The controller will now periodically query all the switches he is aware of. Because the
implementation is in complete, the controller cannot discover the entire network.

Question1. Implement the find Paths method.

You need to use a Breadth-First Search (BFS) from the first switch dpid1
towards the second node dpid2 using the list path Nodes. Look at the
implementation of Switch Node to find the relationship between switches. The
method must return the port of dpid1 that connects towards dpid2, followed by a
“/” character.
For example, if the path from switch A to switch B passes through the port1
of switch A, your implementation should return “1/”.
To compile your code, use the ant command from the flood light directory.
Question 2.Show that your implementation is correct by demonstrating a few
paths on the B4 topology.
Note:The UI of floodlight has been deactivated. If you want, you can run the
topology with the floodlight from lab 1 to see the topology. You can also look at
the mininet script.To show that your path is correct, you can simply print the
path once it is created, and show with the topology that it is indeed the shortest
path.
Part 3-Evaluating Renaissance

 Run once more a network topology and both controllers. If your implementation is correct,
your global controller should now be able to discover the entire network. With B4, you
should have a query Set with 12 elements.
 We will now evaluate Renaissance. We choose two performance metrics : the discovery time,
i.e. the time required by a global controller to receive are ply from all node sin the network, and the
number of messages exchanged.

Question 3.Evaluate the discovery time distribution of Renaissance for three

network topologies: B4,Clos, and Telstra. The average time is not enough. Use a
violin plot or a box plot. The experiment must be repeated enough times for
significant results. After each experiment, you need to completely stop both the
network and the local controller.
Remember, if Mininet did not quit correctly, use sudomn-c.
Question 4.Evaluate the number of messages exchanged for three network
topologies: B4, Clos, and Telstra.
For an easier comparison between different topologies, divide the total number of mes-
sages by the number of nodes present in the network.
Again, use aviolinplot.
Conclusion

 In this lab, we studied Renaissance, a self-stabilizing distributed control plane. We look edat
the relationship between the algorithm and its implementation, and tested it on three real-
world topologies: B4, Clos, and Telstra. We then completed the implementation with a BFS-
tree building algorithm. Finally, we evaluated the performance of our modified
implementation.
 In the next lab, we will go even further with Renaissance. We will implement backup paths
for improved fault-tolerance, allow hosts to ping each other and use multiple global
controllers concurrently.
 EX.NO:3 Adding Fault Tolerance to Renaissance
DATE:

General Instructions

 In this lab, we will continue to work on Renaissance. This time, we will compute backup
paths to add fault tolerance to the system.
 The successful completion of the labs requires your provision of a report for each lab. All
exercises in the instructions must be answered unless stated otherwise. Your answers should
be concise; you don’t need more than a few lines to answer each question. Questions that
needs to be answered are within boxes. Some exercises ask you to discuss with your lab
partner.You do not need to provide written answers to those questions.
 You should complete the lab sin groups of two persons—use the group you’ve created in
pingpong! You are of course encouraged to discuss with other groups, but all your
submissions must be the results of your own work. Once finished, upload your solution as a
PDF document toping pong,and don’t forget to identify both member softhegroup.
 Addition all documents, such as source code, are available on pingpong.
 It is assumed that you run the labs in the windows environment at Chalmers. We use a virtual
machine and Virtual Box to have access to a linux environment.You may use your own
computers, however we might not be able to provide support in that case.

Backup Paths and Fault Tolerance

 Our current implementation is not very resilient against node failures. If a node fails, the
global controller must re compute the topology and install new rules on the switches. This
causes downtime for the system, during which communication is disrupted.
 The simplest way to resolve no defailures and add fault tolerance is to user edundancy. If a
failure happens along a path, a backup path can be used to forward traffic while the problem
is taken care of. We now speak of primary and secondary paths.
We introduce the find Backup Path method:
1private String find Backup Path (SwitchNode dpid1, SwitchNode dpid2,
List<SwitchNode>exclude Nodes, List<SwitchNode>sNodes)

 To be correct, the second ary path must not use the same output port as the primary path, i.e.,avoid
then ext no deal ong the path ifith as failed. An exclude Nodes list allows us to keep track so fal
ready used nodes (i.e.,the output port of the source node).

Question1.Implement the find Backup Path method.

You need to use a Breadth-First Search (BFS) from the first switch dpid1towards
the second node dpid2using the list path Nodes. Your path cannot use any node
present in exclude Nodes.
Like for find Paths in lab 2, the method must return the port to use followed by a
“/” character, e.g.“2/” if the switch dpid1 must use port 2 to contact dpid2 with
the backup path.
We now need to add this information to the rules. Luckily for us, the local controller’s
implementation is already able to handle backup paths. All we have to do is to concatenate the result
of find Backup Path to the String returned by find Paths.

Question2.Update your find Paths method to include the result to ffind Backup
Path. If the primary path uses port 1 and the secondary path uses port 4, your
function must return “1/4/”.
Do not forget to add the node used by your primary path in the exclude Nodes list
before computing the backup path!
Question 3.Show that your implementation is correct by demonstrating a few
paths on the B4 topology.

 Your implementation should now install both a primary path and a secondary, backup path
from every switch to every other node in the network. The network should now be resilient to
link failures. We will now demonstrate that backup paths are indeed used when the primary
link is down.
 In mininet, run the command:
 1links1s2down

 Check the B4 topology and choose one link to stop. If you want to stop more than one link,
remember that the network must remain connected, i.e. you shouldn’t cause network
segmentation.
 Now, look at the output of the global controller. You should see the current synchronization
label. The label increases every time the global controller receives replies from its entire
query set. If one node is not reachable, the label should not increase.

Question4.Are all switches reachable by the global controller, even in the

presence of link failures?

 You should now be convinced that the global controller can still reach all nodes in the
network, even if one link is down.
 But the implementation is still limited to at most one failed link per switch. We can make it
even more reliable by computing more backup path. We simply need to call find Backup Path
multiple times, until there is no additional path.

Question5.Update your find Backup Path to find all existing backup paths.
One way to do this is to recursively call the method and add the used ports to the
exclude Nodeslist at each iteration.If no more paths are available, the method should
return an empty string.
IfswitchAcancontactswitchBthroughtheports1,3and7,thenyourfindPaths
functionshouldoutput“1/3/7/”.

Allowing Data Packets Through

 To ensure self-stabilization,Renaissance considers all incoming packets as control packets by

default.The content is then matched to a set of well-defined set of possible control
 messages.If no matches are found, the implementation discards the packet.
 We will change this behavior to forward non-control packets.To simplify the problem, we
will assume that all packets on the data plane are using IPv4.Even more, all packets are using
ICMP, i.e.they are ping from one node to another.

Question6.Upon reception of an ICMP message,forward the packet to its correct

destination.
You need to update the receive method of the global controller.

 You can take inspiration from the way other TCP messages are handled.ICMP messages
can be tested if the protocol is equal to Ip Protocol.ICMP.
 To be able to test the ping, you need to run two global controllers in the network .Only a host
with a running global controller can ping other hosts.
Make a copy of the global controller directory. Open src/main/resources/flood light
default. properties. Modify the line:
 58 net.floodlightcontroller.globalcontroller.GlobalController.controllerIP=
10.0.0.1

 To the IP of these condhost,e.g.10.0.0.2.

 Once both global controllers are running and they have discovered the entire network, you
should be able to ping from one host to another.

Adding Global Controllers

We ran two global controllers in the same network to enable pinging. Remember that, to recover
from any faulty configuration, a global controller must erase the memory of all the switches it
contacts. One might wonder how two controllers can work in the same network without competing.

Question5.Update your find Backup Path to find all existing backup paths.
One way to do this is to recursively call the method and add the used ports to
the exclude Nodes list at each iteration.If no more paths are available, the
method should return an empty string.
If switch A can contact switchBthroughtheports1,3and7,then your find
Paths Function should output“1/3/7/”.

Allowing Data Packets Through

 To ensure self-stabilization, Renaissance considers all incoming packets as control packets by

default.The content is then matched to a set of well-defined set of possible control
messages.If no matches are found, the implementation discards the packet.
 We will change this behavior to forward non-control packets.To simplify the problem, we
will assume that all packets on the data plane are using IPv4.Even more, all packets are using
ICMP, i.e.they are ping from one node to another.
 Question6.UponreceptionofanICMPmessage,forwardthepackettoitscorrect
destination.
Youneedtoupdatethereceivemethodoftheglobalcontroller.

 You can take inspiration from the way other TCP messages are handled.ICMP messages
can be tested if the protocol is equal to Ip Protocol ICMP.
To be able to test the ping, you need to run two global controllers in the network.Only a host
with a running global controller can ping other hosts.
Make a copy of the global controller directory. Open src/main/resources/flood lightde-
fault.properties.Modify the line:
 58net.floodlightcontroller.globalcontroller.GlobalController.controllerIP =
10.0.0.1

 To the IP of these condhost,e.g.10.0.0.2.

 Once both global controllers are running and they have discovered the entire network, you
should be able to ping from one host to another.

Adding Global Controllers

We ran two global controllers in the same network to enable pinging.Remember that, to recover
from any faulty configuration, a global controller must erase the memory of all the switches it
contacts. One might wonder how two controllers can work in the same network without competing.

Question 7.What mechanism allows multiple controllers in the same network

without competition?
Question8.How does the algorithm deal with failed controllers?Check the
meaning of manager in the implementation.

Conclusion

In this lab, we build upon our implementation of Renaissance.We added fault tolerance with
backup paths and enabled pinging through the network.
More generally, this series of labs introduced you to the concepts of software defined net-
works.You used OpenFlow, the most frequently used protocol for switch and flow pro-
gramming.You also interacted with Mininet, a powerful network emulator often used in research on
SDN.
Finally, you had the chance to experiment with an implementation of a self-stabilizing
algorithm.You saw how an implementation differs from pseudocode, how to evaluate a system and
how self-stabilization can be implemented.
 Set up your own virtual SDN lab
EX.NO:4 i) Virtual box /Mininet Environment for SDN-http://mininet.org
ii) https://www.kathara.org
DATE:
iii) GNS3

AIM:

To set up your own virtual SDN lab using one of the three options:

Virtual box /Mininet, Kathara, or GNS3

PROCEDURE:

i) Virtual box / Mininet Environment for SDN-http://mininet.org

1. Download and install Virtual box from its [officialwebsite].

2. Download and install Mininet from its [official website].You can choose
to install Mininet as a virtual machine image, a native installation, or a
source code installation.
3. Launch Mininet and create a virtual network using the command line
interface or the graphical user interface. You can also use predefined network
topologies or custom scripts to create your network.
4. Connect your virtual network to an SDN controller, such as
OpenDaylight,using the OpenFlow protocol.You can download and install
OpenDaylight from its [official website].
5. Test and run different SDN applications and scenarios on your virtual
network using the Mininet commands or the SDN controller interface.
OUTPUT:
RESULT:

Thus, the setup of Virtual Box/ Mininet Environment for SDN was installed
successfully.
EX.NO:5 Create a simple mininet topology with SDN controller and use Wireshark to capture
and visualize the OpenFlow message suchas OpenFlow FLOWMOD,PACKET IN,
DATE: PACKET OUT etc,.

AIM:

1. Create a simple Mininet network with an SDN controller (Ryu).

2. Capture Open Flow messages,including FLOW_MOD,PACKET_IN,and
PACKET_OUT, using Wireshark.
3. Visualize the captured Open Flow messages for analysis.

PROCEDURE:

1. Install Mininet:
Ensure you have Mininet installed on your system.You can use a Linuxd istribution for
this task.
2. Install Ryu SDN Controller:
InstallRyu,a popular SDN controller,using pip:
Pip install ryu
3. Create the Mininet Topology:
Create a Python script (e.g., `mininet_topology.py`) to define your Mininet network
topologyandstartMininetwiththeRyucontroller.Here'sanexampletopologywitha single
switch and two hosts:
```python
From mininet.netimport Mininet
from mininet.topo import SingleSwitchTopo
from mininet.node importRemoteController
# Create a Mininet instance
net=Mininet(topo=SingleSwitchTopo(2),controller=RemoteController) #
Start Mininet
net.start()
```
4. Start the RyuController:
In a separate terminal,start the Ryu controller:
```
ryu-manager
```
5. Capture OpenFlow Messages with Wireshark:
 Star tWireshark and select your network interface(e.g., `eth0`).
 Apply a display filter to capture only OpenFlow messages.Use the filter
expression: `of`.
 Begin capturing packets by clicking the"Start"button inWireshark.

6. GenerateOpenFlowMessages:
In the Mininet terminal,you can use the Minine CLI to generate Open Flow messages. For
example, you can add a flow rule (FLOW_MOD) or generate traffic (PACKET_OUT).
 To add a flowrule (FLOW_MOD):
```
mininet>h1ovs-ofctl add-flow s1in_port=1,actions=output:2
```
To generate traffic (PACKET_OUT):
```
mininet>h1ping-c1 h2
```
7. Stop Wireshark Capture:
Stop capturing packets in Wireshark when you've generated enough OpenFlow messages.

OUTPUT:

 The Wireshark capture should display OpenFlow messages exchanged between the
Ryu controller and the Mininet switch. You will see messages like FLOW_MOD,
PACKET_IN, and PACKET_OUT, along with their details.

 Use Wireshark's visualization tools to analyze and inspect the captured OpenFlow
messages.You can filter,sort,and drill down into specific messages to understand the
communication between the controller and switches.
RESULT:

This setup allows you to observe and analyze the OpenFlow messaging in a simple SDN
network. You can further customize the Mininet topology and generate more complex
OpenFlow scenarios for testing and analysis.
EX.NO:6 CreateaSDNapplicationthatusestheNorthboundAPItoprogramflowtablerules on the
switch for various use cases like L2 learning switch, Traffic Engineering, Firewall
DATE: etc

AIM:
Develop an SDN application that uses the Northbound API to program flow table
Rules on SDN switches for different use cases: L2 learning switch,Traffic Engineering,and
Firewall.

PROCEDURE:

1. SetUp the Development Environment:

Install the Ryu SDN controller and any necessary Python libraries.

2. Create the Ryu SDN Application:

Create a Python script for your Ryu SDN application,which will implement the
Northbound API to program flow rules.

3. L2 LearningSwitch UseCase:
In your Ryu application, use the Northbound API to program flow rules for basic L2
learning.For example,when a packet arrives,add a flow entry to the switch's flowtable based
on the source MAC address and port.

4. Traffic Engineering UseCase:

Implement traffic engineering rules using the Northbound API. For instance, you can
define flow rules to optimize traffic paths or prioritize specific traffic based on application
requirements.

5. Fire wall Use Case:

Implement firewall rules using the Northbound API to drop or allowspecific traffic based
on criteria such as source/destination IP addresses, ports, or protocols.

6. Run the SDN Application:

Start your Ryu SDN application with the Ryu manager using the following command:
```
ryu-manager your_application.py
```

7. Test the SDN Application:

Create a virtual network or use a Mininet topology for testing your SDN application.
Generate traffic to see how the application programs the flowtable rules.
OUTPUT:

 For the L2 learning switch usecase, the application should program flow rules that
enable the switch to learn and forward traffic based on MAC addresses.

 In the traffic engineering use case,the application should optimize traffic paths or
prioritize certain types of traffic as per your defined rules.

 In the firewall usecase,the application should allow or block traffic based on your
defined criteria.

 The application's output should include log messages or other forms of feedback,
showing that it is functioning correctly.
RESULT:

The result is a working SDN application that leverages the Northbound API to program flow
table rules on SDN switches for different use cases. The application should effectively
control network traffic based on the specified policies and rules.
EX.NO:7 Create a simple end-to-end network service with two VNFs using vim-emu
https://github.com/containernet/vim-emu 5) Install OSM and onboard and
DATE: orchestrate network service.

AIM:
 Create a simple end-to-end network service with two VNFs using vim-emu.
 Install OSM and onboard and orchestrate the network service.

PROCEDURE:

1. Set Up the Environment:

Make sure you have a Linux system.You can setup a virtual machine or a dedicated
system.
-Install the required dependencies, including Docker and Docker Compose.

2. Install vim-emu:
Follow the instructions in the vim-emu GitHub repository
(https://github.com/containernet/vim-emu)toinstallvim-emu.

3. Create Network Topology:

Define a network topology using vim-emu. You can create a Python script that specifies
the network, VNFs, and their interconnections. For example, create a file named
`network_topology.py`:

```python
from mininet.net import Containernet
from mininet.node import Docker
from mininet.link import TCLink
from mininet.cli import CLI

net=Containernet()

vnf1=net.addDocker('vnf1',dimage="vnf1_image")
vnf2=net.addDocker('vnf2',dimage="vnf2_image")

net.addLink(vnf1,vnf2,cls=TCLink)

net.start()
CLI(net)
net.stop()
```

4. Create VNF Docker Images:

Build Docker images for your VNFs.Create a `Dockerfile` for eachVNF,specifying its
requirements and configurations. Build the images using Docker commands.
5. Launch the Network Topology:
Run your network topology with vim-emu:

```
Sudo python network_topology.py
```

This will start the network and deploy the VNFs.

6. Install OSM:
Follow the instructions on the OSM Git Hubrepository (https://osm.etsi.org)toinstall
OSM, which includes installing the OSM client and server components.

7. Onboard the Network Service:

Use the OSM client to onboard your network service.You'll need to provide a descriptor
(e.g., a TOSCA YAML file) for your service.

```
Osm ns-create<your_network_service_descriptor_file>
```

8. Instantiate the Network Service:

Instantiate the network service using OSM:

```
Osm ns-instantiate<ns-instance-name><your_network_service_name>
```

Replace`<ns-instance-name>`with a suitable name for your instantiated service.

OUTPUT:

 When running the network topology script with vim emu, you should see the
network and VNFs being deployed. You can test connectivity and traffic between
VNFs.

 After installing OS Mandon boarding the network service descriptor, you should see
your network service listed within OSM.

 When in stantiating the network service, OSM will orchestrate the deployment of
the VNFs and connect them according to your descriptor.
RESULT:

The result is a fully orchestrated end-to-end network service with two VNFs, established
using vim-emu and OSM. The network service is now ready to accept and process traffic as
specified in your descriptor.