Final Laboratory Configuration and Management of Networks The final Lab consists in configuring a series of case study routing topologies to configure without instructions. Each scenario has a small description and a high level list of tasks to perform. Upon completion of the lab the students should deliver for each topology the following items: Configuration files of the equipment (.cfg files) (for all network elements) Text file containing the issued commands. This should be delivered by email to : pfa@fct.unl.pt by midnight of the 8 Th of December 2013. A second part of the laboratory involves a tutorial exercise about software-defined networks and the use of a Software controller to configure the switches of a network via the OpenFlow protocol. This exercise comes with detailed instructions on how to install the mininet simulator to simulate a network of OpenFlow enabled switches and how to install POX (a Python based controller development environment) the exercise is to simply run one of the example controllers in POX that configures switches to act like a HUB and then change the code so that the switches act like learning switches. For the Labs discussion you should bring your one laptop with the GNS3 projects of the three routing case studies and the mininet installation so that you can demonstrate the connection with the POX controller and run a simulation. Grading The grade will be attributed according to the three routing exercises. The OpenFlow exercise will have an impact of 1 point in the final grade. Therefore: If the OpenFlow exercise is not completed there will be a penalty of -1 point in the routing exercises grade. If the OpenFlow basic exercise is completed (installation of the simulator and the POX environment and running of a simulation using the sample controller) there is no impact on the grade. If the full OpenFlow exercise is completed (including the change in the code of the sample controller to change it to a learning switch with installed forwarding rules) there is an increase of +1 point in the grade.
Part one Routing case studies Scenario 1 EIGRP case study Topology Objectives! Implement a topology and EIGRP routing. Configure all interfaces in the topology diagram with the IP addresses shown. Configure a bandwidth of 64 in all the serial interfaces. Configure EIGRP AS 10 to route all networks in the diagram. Disable auto-summarization. Configure R4 and R2 to summarize their loopback interfaces to the most specific summary possible. Verify connectivity between all routers.
Scenario 2 OSPF challenge Configuration and Management of Networks Topology Objectives! Implement the topology diagram following the instructions in the Configuration Requirements section. Configuration Requirements Configure the interfaces in the diagram with the IP addresses shown. Configure OSPF with the interfaces in the areas shown in the diagram. Configure R1 to summarize area 20 with the most specific mask possible. Make the link between R1 and R2 have the OSPF network type of broadcast, with R1 as the DR. Configure R3 to always originate a default route. Configure area 43 to be a stub area. Figure out the hidden issue in the topology that you need to address to have full connectivity. Verify connectivity between all addresses in the topology.
Scenario 3 BGP case study Topology Objectives Plan, design, and implement the Supermarket core Network. Plan, design and implement the Supermarket Provider s Network. Allow the networks to communicate via BGP. Verify that all implementations are operational and functional according to the requirements Configuration Requirements Use the addressing scheme shown in the diagram Configure the Supermarket Network to be in EIGRP AS 64600. Configure the Supermarket provider network to be in EIGRP AS 64602. Disable EIGRP auto summarization in both EIGRP domains Configure the Supermarket network to be in BGP AS 64600 and the provider network in BGP AS 64602.
Advertise the 192.168.14.0/30 and the 192.168.34.0/30 networks in both EIGRP Autonomous Systems. Configure the interfaces on the border routers between the two EIGRP autonomous systems, so they do not send EIGRP packets. All routers will be participating in BGP. Configure all routers for a full mesh of IBGP peers in each system. Advertise all loopback interfaces into the BGP process, except on R2 where the only advertised should be loopback 0. In R2 for the rest of the loopback interfaces create a summary and advertise this static route into BGP. R4 should send a summary route to the supermarket network representing all R4 loopback interfaces. R4 should prefer the path to the supermarket network via the Ethernet link R1-R4. Routers in the supermarket network should prefer the Ethernet link R1-R4 to reach provider networks.
Part 2 Configuring a network using OpenFlow Objective Configuration and Management of Networks 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 analyze that code and understand the OpenFlow messages exchanged between the controller and the switches. The basic exercise consists in setting up the mininet/openflow VM and setting up the POX controller development environment. You should then run an example controller and connect it to a mininet network as it is described in the instructions. You will be asked to perform this during the project discussion. Failing to do this will decrease the grading of the routing configuration exercises in 1 point. The full 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. Successful completion of this will increase the grading of the routing configuration exercises in 1 point. Notation 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. 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. 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 in: http://tele1.dee.fct.unl.pt/cgr/secure/vmopen.zip 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: 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 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. 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. 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. 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. 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).
Verify Hub Behavior 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 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. ------------------------------------------ END OF THE BASIC EXERCISE ------------------------------------------- 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.
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 functions 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 optimized language. Common operations: To initialize a dictionary: mactable = {} 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.
Open flow messages in POX When a connection to a switch starts, a ConnectionUp event is fired. The of_tutorial.py code creates a new Tutorial object that holds a reference to the associated Connection object. This can later be 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) In the Tutorial class the connection to the switch 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: # This binds our PacketIn event listener connection.addlisteners(self) Events are then 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. 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 of a packet, use the dot notation: packet.src 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 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 msg 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). An then 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 behavior to the OFPP_FLOOD value. You should now complete the following act_like_switch method: 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 that you can access using:
self.mac_to_port[packet.dst] This will make the switch send the packet thought 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 receive the other packets. 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 to send to a switch 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 at the object creation. 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. 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.