Specialization Software-defined Networking (Winter 2015/2016)

From NET Wiki
Jump to navigation Jump to search
Imbox content.png Note: Since 25th March is Easter Friday, the course and final presentations that are scheduled for 25th March will be shifted to a date in the last two weeks of April. We can decide on the exact day on the 21st March, on the first day of the course.


Imbox content.png Note:

In order to register, please subscribe to the mailing list "Sdn_course_16@gwdg.de" by subscribing at the following site (and write a message of the SDN course(s) that you plan to attend): https://listserv.gwdg.de/mailman/listinfo/sdn_course_16


Details

Workload/ECTS Credits: 150h, 5 ECTS
Module: AI: M.Inf.1230: Specialization Software-defined Networks (SDN)); ITIS: 3.32
Lecturer: Dr. Mayutan Arumaithurai
Teaching assistant: Sameer Kulkarni
Time: March 21-25; 09.00-17.00
Place: IfI 2.101
UniVZ tba


Course Overview

Software-defined networking (SDN) has recently attracted both researchers in academia and big players in communication technologies, and is currently probably the 'hottest' topic in computer networking. This course is a continuation of the "Introduction to SDN" course and we will focus on gaining an advanced knowledge of SDN. The course is organized as a block course. Please see the following "Schedule" table for a detailed structure. The course will focus on reading and understanding recent papers in the SDN field to gain an in depth understanding of the current state of the art and potential research topics. We will also do a lot of exercises to familiarize ourselves with SDN tools.

For all parts of the course, exercises will be provided, in which students must obtain at least 50% of the total points and active participation in the group discussions to be admitted to the examination of this course. The exam is taken by submitting a report of 10-15 pages summarizing the lessons learned during the lectures and exercises as well as the research papers investigated (a LaTeX template will be provided). Depending on the number of attendees, several parts will be conducted in teams of students.

Link to UniVZ

Schedule

Date Morning Session I Morning Session II Afternoon Session I Afternoon Session II
Time 9:15 - 10:45 11:00 - 12:30 14:00 - 15:30 15:30 -
21`.03.2016 Lecture I: Enhancing Data Plane Exercise I: Data Center topology Group Discussion I Exercise II: Simple load balancer
22.03.2016 Lecture II: Northbound API Exercise III: Pox Firewall Group Discussion II Exercise IV: Pyretic Firewall
23.03.2016 Lecture III: Enhancing Data Plane - II Exercise V: Kinetic Firewall Group Discussion III Exercise VI: Kinetic-pox loadbalancer
24.03.2016 Exercise VII: kinetic, pyretic debugging Exercise VIII: Service Chaining I Group Discussion IV Exercise IX: Service Chaining II
xx.xx.2016 (Since 25th March is Easter Friday, see note above) "Preparation for final presentation" "Preparation for final presentation" Final presentations I Final presentation II

Requirements

  • Basic knowledge in computer networking (e.g., successful completion of the course "Computer Networks") and object oriented programming is required.
  • Completion of the course "Introduction to SDN", exceptions can be obtained on a case by case basis.
  • Each participant is required to actively attend the course and earn 50% of the points of the exercise.
  • Written report at the end of the course. The report should include the following:
    • Exercises results + code
    • Short report on the group discussion papers
    • Report on the paper presented by team-X for the final presentation

Exercises


General Hints

  • Use the following option to get more debug info while using pox
    • $ ./pox/pox.py log.level --DEBUG misc.of_tutorial
    • NOTE: There are two "-" (i.e. --) used for options in mininet/pox. In the wiki, sometimes the two lines join up and show as one line.

21 March

  • Get the Image from Mayutan/Sameer/peers

Exercise I: Data Centers

  • (30P) Warmup (simple Tree) ($ => commands on VM, > => commands on mininet/pox, Q => Question)
    • $ sudo mn --topo tree,3 --mac --arp --switch ovsk --controller remote
    • $ h1 ping h8 (Q: What do you observe?)
    • $ ./pox/pox.py
    • $ h1 ping h8 (Q: What do you observe?)
    • $ ./pox/pox.py samples.spanning_tree
    • $ h1 ping h8 (Q: What do you observe?)
  • (40P) Create your own simple tree
    • copy dcsimple.py ([1]) to mininet/custom/
    • modify dcsimple.py to create hosts, switches and connections for a three level tree
    • $ sudo mn –-custom dcsimple.py -–topo simple
    • Check with ping
  • (30P) Create your own Fattree
    • copy dcfat.py ([2]) to mininet/custom/
    • modify dcfat.py to create a fat tree (level 0: so & s1, level 1: s2 & s3, level 2: s3, s4, s5, s6, Level 3: Hosts)
    • $ sudo mn –-custom dcfat.py -–topo fat
    • check with ping
    • $ sudo mn –-custom dcfat.py -–topo fat --controller remote
    • $ ./pox/pox.py samples.spanning_tree
    • check with ping

Exercise II: Load balancers

  • Setup will be as shown in Figure [3]
  • (40P) Pre-defined servers
    • AIM: Http requests from different clients will be directed to different pre-defined servers
    • $ sudo mn --topo single,6 --mac --arp --controller remote
    • $ ./pox.py log.level –-DEBUG misc.ip_loadbalancer –-ip=10.0.1.1 –-servers=10.0.0.1,10.0.0.2
    • Start HTTP servers on h1, h2
      • > xterm h1,h2
      • h1$ python –m SimpleHTTPServer 80
      • h2$ python –m SimpleHTTPServer 80
    • Get webpage from clients (h3)
      • > xterm h3
      • h3$ curl 10.0.1.1
    • Observe in Pox controller, which server is it connecting to. Continue to obtain webpage from the same client and one other client and observe the results
      • Are both servers getting an equal share
  • (60P) Modified Load_balancer
    • Now modify pox/pox/misc/ip_loadbalancer.py to select server in a round robin fashion

22 March

Exercise III: Firewall

  • Topology is the same as that used for loadbalancing
  • (40P) Simple firewall
    • We will be using the load-balancer experiment as basis
    • put blocker.py (https://dl.dropboxusercontent.com/u/1652374/SDN_course_WS2015-2016/Exercises/ex3/blocker.py) in pox/ext/blocker.py
    • $ sudo mn --topo single,6 --mac --arp --controller remote
    • $ ./pox.py forwarding.l2_learning blocker py
      • Note that there is a space between blocker and py to enable interactive mode
      • or $ ./pox.py forwarding.l2_learning blocker.py --ports=80,8888,8000
    • start Webserver in h1
      • h1$ python -m SimpleHTTPServer 80
    • Try to perform curl or wget from h2 to h1
      • h2$ curl 10.0.0.1
    • Then block port 80 in pox controller
      • pox> block(80)
    • Now, again try the following and report what happens
      • h2$ curl 10.0.0.1
  • (60P) Advanced Firewall ( I will give you hints)
    • Topology [4]
    • Aim: Implement a layer 2 firewall that runs alongside the MAC learning module on the POX OpenFlow Controller. Your firewall should be agnostic to the underlying topology. Take MAC pair list as input and install it on the switches in the network
    • Note that MAC learning can be done in conjunction with firewall. Therefore you might have to assign priority to each application.
    • Copy firewall.py from [5] into pox/pox/misc folder
    • Start editing firewall.py
      • Write code to block h1 to h2 (Mac IDs: 00:00:00:00:00:01, 00:00:00:00:00:02)
    • Do the following to quickly test code
      • $ ./pox.py --verbose forwarding.l2_learning misc.firewall
      • $ sudo mn --topo single,3 --controller remote --mac
      • $ dpctl dump-flows tcp:127.0.0.1:6634

Exercise IV: Pyretic Firewall

  • Aim: Pyretic based firewall
  • Topology [6]
  • Put the following files in folder: pyretic/pyretic/examples
  • $ sudo mn --controller remote --topo=single,3 --mac --arp
  • (20P) Run the pyretic hub example
      • $ pyretic.py –v high pyretic.examples.pyretic_hub
    • Verify that the hosts can ping each other
      • > xterm h1 h2 h3
      • h2$ tcpdump -xx -n -i h2-eth0
      • h3$ tcpdump -xx -n -i h3-eth0
      • h1$ ping -c1 10.0.0.2
    • Observe what happens when you do
      • h1$ ping -c1 10.0.0.5
    • Look into the hub code: pyretic/pyretic/examples/pyretic_hub
  • (20P) Run the pyretic switch example
      • $ pyretic.py –v high pyretic.examples.pyretic_switch1
    • Verify that the hosts can ping each other
      • > xterm h1 h2 h3
      • h2$ tcpdump -xx -n -i h2-eth0
      • h3$ tcpdump -xx -n -i h3-eth0
      • h1$ ping -c1 10.0.0.2
    • Observe what happens when you do
      • h1$ ping -c1 10.0.0.5
    • Look into the switch code: pyretic/pyretic/examples/pyretic_switch1.py
  • (60P) Implement a layer 2 firewall that runs alongside the MAC learning module on the pyretic OpenFlow Controller.
    • Your firewall should be agnostic to the underlying topology
    • Write code to block h1 to h2 and h2 to h1 (Mac IDs: 00:00:00:00:00:01, 00:00:00:00:00:02)

23 March

  • Exercise V: Firewall (contd. ) [7] (Exempt: )
  • Exercise VI: Pyretic firewall [8] (Exempt: )

24 March

(Exempt: )

(Exempt: )

25 March

  • Exercise IX: Pyretic Debugging (Exempt: Omar, Martin, Thomas, Sameer, Eeran)

HINT: You might have to use the "$ dpctl dump-flows tcp:127.0.0.1:6634" or "mininet> dpctl dump-flows" command frequently.

    • In this debugging exercise, we take solutions available in the Internet for the gardenwall problem and try to fix bugs in it.
    • We have done kinetic firewall in exercise VII and imitated the same firewall using pox in exercise VIII. Now, we will imitate the same firewall using pyretic.
    • The basic solution is taken from the Internet [9], test if it is able to block h1 when "infected". Note that we will only use the "infected == True" for this exercise.
      • Copy the above code into /home/mininet/pyretic/pyretic/examples as gardenwall_internetsolution.py
      • start controller (in /home/mininet/pyretic folder): pyretic.py pyretic.examples.gardenwall_internetsolution
      • start mininet: sudo mn --controller=remote --topo=single,3 --mac --arp
      • check h1 ping h2
      • Now infect h1 (in /home/mininet/pyretic/pyretic/kinetic folder): python json_sender.py -n infected -l True --flow="{srcmac=00:00:00:00:00:01}" -a 127.0.0.1 -p 50001
      • check h1 ping h2. We should be able to observe that this traffic is blocked.
      • Now, we move on to the debugging part
        • check h2 ping h3, what happens?
        • Now, modify the given code to allow h2 traffic to pass through to h3, when h1 is "infected".
    • Now, check if the "exempt" case is working fine too
    • if time permits, check and improve code to allow h1 to ping h2
    • If time permits, try fixing this code for the "infected" case.
Retrieved from "https://wiki.net.informatik.uni-goettingen.de/index.php?title=Specialization_Software-defined_Networking_(Winter_2015/2016)&oldid=4194"