Configuration and Management of Networks 2014 / 2015

! Departamento de Engenharia Electrotécnica Configuration and Management of Networks 2014 / 2015 Mestrado Integrado em Engenharia Electrotécnica e de Computadores 4º ano 8º semestre Final Lab part II: Simple SDN app using OpenFlow and Mininet http://tele1.dee.fct.unl.pt Pedro Amaral

1. PART II Configuring a network using OpenFlow. The goal is to make a first contact with the use of the OpenFlow protocol to control the switches of a hierarchical network. You will use the mininet simulator to simulate the OpenFlow controlled network. You will then connect an external controller to the topology. The controller uses OpenFlow to receive information from the switches (unmatched packets) and instruct the switches how to deal with them. In this project you will use code that is already available in the distribution of the POX controller development platform (Python based OpenFlow controller) to control the switches. The goal is that you analyse that code and understand the OpenFlow messages exchanged between the controller and the switches. You will start by setting up the mininet/openflow VM and setting up the POX controller development environment. You should then run mininet with a tree topology and connect it to the POX controller (running an example application python file) as it is described in the instructions. The exercise consists in changing the code of the controller example code (that acts like a hub) to act like a learning switch and push forwarding rules to the switches so that packets with known destination MAC addresses are sent to the learned port without controller intervention. 2. Instructions The instructions below use three different command prompts to indicate where commands should be run. Commands that should be run on your local machine are preceded by the prompt: you@yourmachine$ Commands that should be run directly in the VM console, or in an SSH session to the VM are preceded by the prompt: mininet@vm$ Commands that should be run in mininet are preceded by the prompt: mininet> There are also two different IP addresses you will need. Both of these IP addresses are associated with the host-only network created by the hypervisor you use to run the mininet VM (VirtuaBox or VmWare). The first is the IP address assigned to the host-only network adapter created on your local machine by VirtualBox (in VMware it is called a bridged networking adapter). We will refer to this IP as: <host_ip>. You can use ifconfig (or ipconfig in windows) to determine the IP address the hypervisor attributes to your local machine. In VmWare for example it is listed like a vmnet interface in the results of the ifconfig command.! 1

The second is the IP address assigned to host-only network adapter within the VM. We will refer to this IP as: <vm_ip>. This IP can be determined by running ifconfig -a within the VM to determine which. ifconfig in the VM should show two network interfaces. One should be a NAT interface that can be used to access the Internet, and the other should be a host-only interface to enable it to communicate with the host machine. For example, your NAT interface could be eth0 and have a 10.x IP address, and your host-only interface could be eth1 and have a 192.168.x IP address it can also be the other way around. You will need to try and ssh from your host OS to the IPs of the mininet VM until you succeed. ssh -X mininet@<vm_ip> 2.1 Set Up the Mininet/OpenFlow VM Note: These instructions assume your machine is running Linux. If you are running OS X or Windows, the set up process will be slightly different; instructions can be found in the OpenFlow tutorial at http:// www.openflow.org/wk/index.php/openflow_tutorial references to specific sections of this tutorial are included in the details below. A VMware virtual machine with the mininet installation is available in the course site or directly in the mining website. You should install VMplayer and open the VM file. Under the settings menu, on the right side panel you need to select the add device button and add another network adapter. On the properties of the network adapter select host-only and enable the dhcp server option. You can now boot the VM image file. The user name and password are: mininet. You should be able to connect from your host machine to the VM via SSH. In the VM Run the following to identify the IP address you should use to connect: mininet@vm$ ifconfig a In your host machine go to your network settings and check the IP address that you are using to reach the Internet. In the result of the above command in the VM one of the interfaces will have that same IP address and it is used for Internet connectivity. There should be another interface (the host-only network adapter) with a different IP address. This is the address that you should use to SSH in to the VM. When you connect via SSH, be sure to enable X11 forwarding using the X option in ssh: you@yourmachine$ ssh -X <vm_ip>. If you are running Mac OS X or Windows, you will need the appropriate tools for connecting to the VM via SSH and displaying GUIs using X. See the following parts of the OpenFlow tutorial for guidance:! 2

http://www.openflow.org/wk/index.php/openflow_tutorial#download_files and http://www.openflow.org/wk/index.php/openflow_tutorial#access_vm_via_ssh 2.2 Set Up Controller Development Environment Your SDN application can run atop several available controller platforms. In this project we describe how to use the POX (Phyton-based) controller. Obtain the latest version of POX from github (a software versioning platform on which the POX controller software is maintained): you@yourmachine$ git clone http://github.com/noxrepo/pox If you are using windows on your host machine install git from: http://msysgit.github.com/ and then run from the command line the above command to install pox. Just change in to the pox folder that should be created in your user area and you are ready to start using POX. 2.3 Using mininet Mininet emulates an OpenFlow network and end-hosts within a single machine. It includes built-in support to create several common topologies, plus it allows for construction of custom topologies using a python script. Since we are only considering tree-like data center topologies, will only use the tree topology built-in. To launch mininet with the network arranged in a binary tree topology with depth 3, run the following command (either directly in the VM console or in an SSH session to the VM): openflow@vm$ sudo mn --topo tree,3 --mac --arp --switch ovsk --controller remote,ip=<host_ip> Each of the part of the command does the following: sudo runs as root. mn runs mininet. --topo tree,3 creates a tree topology of depth 3 with the default fanout of 2 (i.e., binary). --mac makes the mac address of mininet hosts the same as their node number. --arp installs static ARP entries in all hosts. --switch ovsk uses Open vswitch in kernel mode for each of the switches. --controller remote,ip= <host_ip> the SDN controller will run outside of mininet in the IP of your host machine.! 3

The created topology with the above command is depicted in the following figure: The numbering of hosts and switches is according to the numbering used by mininet. Squares represent hosts and circles represent switches. Once mininet is running, you can obtain information about the network, generate traffic, and run commands on individual hosts. To display all of the elements in the network, run the nodes command within mininet: mininet> nodes Nodes starting with h are hosts, and nodes starting with s are switches. To display the list of links in the network, run the net command within mininet: mininet> net This will output a list of switches, and for each switch, list the hosts and switches connected to that switch (along with the network interface on each host and switch that is used for the link). One option to generate traffic is to run ping or iperf on individual hosts. To do so, you need to run a command on a specific host within mininet. This is achieved by typing the hosts name, followed by the command. For example, to send 10 ping packets to h2 from h1, run: mininet> h1 ping -c 10 h2 To run iperf, you ll need to start the iperf server on one host, running the command in the background, and then start the iperf client on another host. For example, to run an iperf server onh1 and an iperf client on h2, run: mininet> h1 iperf -s & mininet> h2 iperf -c h1 You can also provide other options to iperf, if desired. Also, you should kill the iperf server on h1, when you are finished: mininet> h1 kill `ps grep iperf cut -f2 -d ` Note that if you run ping or iperf without an SDN controller running on your local machine, no traffic will be sent across the switches (since there are no OpenFlow rules in the switches) and the commands will timeout.! 4

An alternative option to generate traffic is to use the mininet commands pingpair, pingall, and iperf. Using these commands avoids the need to run commands on individual hosts. You can use the mininet help command or consult the Mininet documentation (http://yuba.stanford.edu/foswiki/bin/view/ OpenFlow/MininetWalkthrough) to learn more about these commands. 2.4 Running your controller You will run your SDN controller on your local machine. In your local machine in the folder where POX was installed issue the following command to run a basic hub example (switches will act like hubs): $./pox.py log.level --DEBUG misc.of_tutorial This tells POX to enable verbose logging and to start the of_tutorial component, which you'll be using (which currently acts like a hub). Now in your VM start mininet with the above tree topology of depth 3 with the command: sudo mn --topo tree,3 --mac --arp --switch ovsk --controller remote,ip=<host_ip> The controller should indicate that the switches are connected printing something like this: INFO:openflow.of_01:[Con 1/1] Connected to 00-00-00-00-00-01 DEBUG:samples.of_tutorial:Controlling [Con 1/1] The first line is from the portion of POX that handles OpenFlow connections. The second is from the tutorial component itself (the specific controller that we are using). 2.5 Verify Hub Behaviour with tcpdump Now we verify that hosts can ping each other, and that all hosts see the exact same traffic (the behavior of a hub). To do this, we'll create xterms for each host and view the traffic in each. In the Mininet console, start up 8 xterms: mininet> xterm h1 h2 h3 h4 h5 h6 h7 h8 Arrange each xterm so that they're all on the screen at once. This may require reducing the height of to fit a cramped laptop screen. In the xterms for h2 trough h8, run tcpdump, a utility to print the packets seen by a host: For example for hosts h2 and h3: # tcpdump -XX -n -i h2-eth0 and respectively: # tcpdump -XX -n -i h3-eth0 In the xterm for h1, send a ping: # ping -c1 10.0.0.2 The ping packets are now going up to the controller, which then floods them out all interfaces except the sending one. You should see identical ARP and ICMP packets corresponding to the ping in both xterms! 5

running tcpdump. This is how a hub works; it sends all packets to every port on the network. So the ping packet is seen in all hosts. In mininet (in the VM) run the iperf command: mininet> iperf This Mininet command runs an iperf TCP server on one virtual host, then runs an iperf client on a second virtual host. Once connected, they blast packets between each other and report the results. Remember that every packet goes up the controller and to all switches. 2.6 Changing the controller The next exercise is to edit the controller to act like a learning switch instead of a hub. Edit the file pox/misc/of_tutorial.py in your favorite text editor. The file contains in commented code almost all the needed alterations to change the controller such that it instructs the switches to perform like a learning switch and to install forwarding rules for learnt addresses. To re-run the controller with the new program save the file and then run it again with: $./pox.py log.level --DEBUG misc.of_tutorial The following sections gives some information about Python so that you can better understand the controller code and point to a possible solution. 2.6.1 Learning Python Python: is a dynamic, interpreted language. There is no separate compilation step, just update your code and re-run it. uses indentation rather than curly braces and semicolons to delimit code. Four spaces denote the body of a for loop, for example. is dynamically typed. There is no need to pre-declare variables and types are automatically managed. has built-in hash tables, called dictionaries, and vectors, called lists. is object-oriented and introspective. You can easily print the member variables and methods of an object at runtime. runs slower than native code because it is interpreted. Performance-critical controllers may want to distribute processing to multiple nodes or switch to a more optimised language. Common operations: To initialize a dictionary: mactable = {}! 6

To add an element to a dictionary: mactable[0x123] = 2 To check for dictionary membership: if 0x123 in mactable: print 'element 2 is in mactable' if 0x123 not in mactable: print 'element 2 is not in mactable' To print a debug message in POX: log.debug('saw new MAC!') To print an error message in POX: log.error('unexpected packet causing system meltdown!') To print all member variables and functions of an object: print dir(object) To comment a line of code: # Prepend comments with a #; no // or /**/ In the next lines you can find some information about the code in the of_tutorial.py file and POX classes that are useful for the exercise. 2.6.2 Open flow messages in POX When a connection to a switch starts, a ConnectionUp event is fired by the POX controller s switch listener. The of_tutorial.py code creates a new Tutorial object (Tutorial(event.connection)) (one Tutorial object is created for each switch that connects) that holds a reference to the associated Connection object returned by the Switch listener. This object is a packet listener that is used to receive events from the switches. This object is also used to send commands (OpenFlow messages) to the switch. def launch (): Starts the component def start_switch (event): log.debug("controlling %s" % (event.connection,)) Tutorial(event.connection) core.openflow.addlistenerbyname("connectionup", start_switch)! 7

In the Tutorial class constructor (def init (self, connection) method) the connection object is registered so that the controller can send it messages. def init (self, connection): # Keep track of the connection to the switch so that we can # send it messages! self.connection = connection And the instance of the tutorial class is registered as the event listener for this connection (with this switch): # This binds our PacketIn event listener connection.addlisteners(self) Packet_in events are processed in the _handle_packetin method: def _handle_packetin (self, event): Handles packet in messages from the switch. packet = event.parsed # This is the parsed packet data. if not packet.parsed: log.warning("ignoring incomplete packet") return packet_in = event.ofp # The actual ofp_packet_in message. # Comment out the following line and uncomment the one after # when starting the exercise. self.act_like_hub(packet, packet_in) #self.act_like_switch(packet, packet_in) The above code receives a packet. The POX packet library is used to parse packets and make each protocol field available to Python in a clean Object format. This library can also be used to construct packets for sending. The parsing libraries are in: pox/lib/packet/ Each protocol has a corresponding parsing file. For the exercise, you'll only need to access the Ethernet source and destination fields. To extract the source MAC address of a packet, use the dot notation: packet.src! 8

The Ethernet src and dst fields are stored as pox.lib.addresses.ethaddr objects. These can easily be converted to their common string representation (str(addr) will return something like "01:ea:be: 02:05:01"). To see all members of a parsed packet object: print dir(packet) The event.ofp object contains the packet in the form needed to send it via OpenFlow trough the network. The line: packet_in = event.ofp Stores this object in the packet_in variable. The act_like_hub method calls the resend_packet method to flood the packets: self.resend_packet(packet_in, of.ofpp_all) That is defined as: def resend_packet (self, packet_in, out_port): Instructs the switch to resend a packet that it had sent to us. "packet_in" is the ofp_packet_in object the switch had sent to the controller due to a table-miss. msg = of.ofp_packet_out() #creates a packet out in the msg variable msg.data = packet_in #fills message with the received packet # Add an action to send to the specified port action = of.ofp_action_output(port = out_port) msg.actions.append(action) # Send message to switch self.connection.send(msg) It creates a packet from the of class (imported from pox.openflow.libopenflow_01). And an action is created using the: ofp_action_output class This is an action for use with ofp_packet_out and ofp_flow_mod objects. It specifies a switch port that you wish to send the packet out of. It can also take various "special" port numbers. An example of this would be OFPP_FLOOD, which sends the packet out all ports except the one the packet originally arrived on. In the example code resend_packet is called with out_port = of.ofpp_all (this value has a similar behaviour to the OFPP_FLOOD value. You should now complete the following act_like_switch method:! 9

def act_like_switch (self, packet, packet_in): Implement switch-like behavior. # DELETE THIS LINE TO START WORKING ON THIS (AND THE ONE BELOW!) # # Here's some psuedocode to start you off implementing a learning # switch. You'll need to rewrite it as real Python code. # Learn the port for the source MAC self.mac_to_port... <add or update entry># if the port associated with the destination MAC of the packet is known: # Send packet out the associated port self.resend_packet(packet_in,...) # Once you have the above working, try pushing a flow entry # instead of resending the packet (comment out the above and # uncomment and complete the below.) log.debug("installing flow...") # Maybe the log statement should have source/destination/port? #msg = of.ofp_flow_mod() # ## Set fields to match received packet #msg.match = of.ofp_match.from_packet(packet) # #< Set other fields of flow_mod (timeouts? buffer_id?) > # #< Add an output action, and send -- similar to resend_packet() > else: # Flood the packet out everything but the input port # This part looks familiar, right? self.resend_packet(packet_in, of.ofpp_all) # DELETE THIS LINE TO START WORKING ON THIS # To perform this the following information is useful: After the _handle_packetin method the source address of the Ethernet packet is in packet.src and the port where the message arrived at the switch is in event.port. You may need to find a way to pass this port in to the act_like_switch method since the event object is not known inside this method. You can test if a destination address is stored in the mac_to_port dictionary with: if packet.dst in self.mac_to_port. In the affirmative case you can then call the self.resend_packet method passing the port stored in the dictionary for the destination in the packet: self.mac_to_port[packet.dst]! 10

This will make the switch send the packet through that port. In case the destination address is still not in the dictionary the packet should be flooded you can do that by using: self.resend_packet(packet_in, of.ofpp_all) After you change the code above to store the port for a mac address and to forward known destination addresses via those ports you have a learning switch. Repeat the hub test with the new controller. You should see that after the first packet the following ones are sent only to the destination hosts. However up to this point the switches still send every packet they receive to the controller. You can now try and change the code so that the controller installs a flow entry in the switch instructing that all packets for that destination should be forwarded by the respective port. This will cause the switch to automatically forward packets for destinations addresses that were already learned instead of sending it to the controller. You can create a message variable to store an OpenFlow flow entry object using the method ofp_flow_mod() of the of class pox.openflow.libopenflow_01 (that is imported as of.) : msg = of.ofp_flow_mod() You can then define a match using the of.ofp_match object defining the attributes to match on. For example: msg.match = of.ofp_match(in_port = 5, dl_dst = packet.dst) Creates a match for packets arriving in port 5 with the destination MAC address (dl_dst). That match rule is associated with the flow entry msg that we will send to the switch. Alternately you can define a match from an existing packet (the match will be for all packets that have the same header values of the passed packet) using the from_packet method. For example: of.ofp_match.from_packet(packet) Creates an exact match on the fields of the packet object meaning that packets arriving at any interface with the same headers are matched. This means that all packets with the same source and destination MAC addresses as the first one will be dealt by this flow entry. After defining the match rule of the flow entry we have to define the OpenFlow actions applied to packets that are matched. There are several possible actions, in this example we will use the output action using the class ofp_action_output. This action defines an action to forward out of a port. For example: msg.actions.append(of.ofp_action_output(port = out_port)) Will create an action to forward a packet that matches our flow entry out of the port with port number out_port. Other flow attributes can be set like timer values or matching priority. This can be done via the available fields at the flow object for example msg.priority contains the priority value of the of.ofp_flow_mod() object contained in msg.! 11

Finally we can send the flow entry to the switch, using the instruction: self.connection.send(msg) Upon completion of the code you should repeat the test in mininet. Like in the last case only the destination host should see the ping traffic, the difference to the previous case is that now after the learning stage similar packets are directly forwarded towards the next switch and not to the controller. If you issue the pingall command in mininet and then iperf you will see that the bandwidth is now much higher than in the previous cases. The reason is that there is less delay forwarding traffic since the packets do not have to be sent to the controller.! 12