Changes between Version 4 and Version 5 of GENIEducation/SampleAssignments/CCNAssignment/ExerciseLayout/Execute

05/29/13 16:17:48 (6 years ago)



  • GENIEducation/SampleAssignments/CCNAssignment/ExerciseLayout/Execute

    v4 v5  
    6262  - '''Question 1.1 B:''' [[BR]]
    6363  Browse the content caches and interests seen on various hosts in the network by loading their ccnd status page on TCP port 9695 in your browser (see Section 5, Hints, below). Which hosts have seen interests and have content cached, and why?
     64  - '''Task 1.2: Intent Propagation''' [[BR]]
     65  ''This task will demonstrate the behavior of Intent filtering during propagation. ''[[BR]]
     66  Log into the machine ''datasource1'' and run the command ''tail -f /tmp/atmos-server.log''. Next, run ''/opt/ccnx-atmos/'' on both of the hosts researcher1 and researcher2. Enter 1902/01/15 as both start and end date on both hosts, and press <ENTER> on both hosts as close to the same time as possible.
     67  - '''Question 1.2 A:''' [[BR]]
     68  What intents show up at datasource1 for this request? (Use the timestamps in the server log to correlate requests with specific intents.) Will you observe unique or duplicate intents when both researcher1 and researcher2 fetch the same data at precisely the same time? Why? [[BR]]
     69  - '''Task 1.3: Explore traffic patterns''' [[BR]]
     70  ''For this task, you will start network monitoring services on your slice and observe the data traffic passing between hosts as you fetch various content.'' [[BR]]
     71  Load your sliver in [ Flack] (if you used your GENI Portal credential to create the topology, then launch Flack from GENI Portal web page) if you have not already done so by refreshing your slices (if necessary) and clicking the slice name in the left pane. Go to the Plugins tab (depicted as a puzzle piece) and click the Instrumentize button. This will take some time, as it adds and configures measurement and monitoring software to your sliver. When it completes, open the INSTOOLS portal in your web browser (Flack will prompt you) and look at the bandwidth usage between the various hosts over time in the INSTOOLS plots. [[BR]]
     72  Log into the host collaborator1 and use the Atmos client to fetch data from 1902/01/28 to 1902/02/03. Look at the INSTOOLS data usage, and observe that data is pulled from both datasource1 and datasource2, through router to researcher1 and ultimately to collaborator1. Record or remember the data rates and volumes from this transaction.
    79   '''Network Setup''' [[BR]]
    80   [[Image(OpenFlowAssignment1.png, 50%, nolink)]] [[BR]]
    81   Follow instructions in the [ DesignSetup] step to build a firewall experiment topology. The specific host names allocated for your experiment will be different, but the topology will be isomorphic. The host labeled ''left'' in the figure is “behind” the firewall, implemented by the Open vSwitch host labeled ''switch''. The host labeled ''router'' handles IP routing for the firewalled network, and every host on the other side of this router (the host labeled ''right'' being the only example on this topology; you may wish to add others for your testing and experimentation) are “outside” of the firewall. [[BR]]
    82   The provided RSpec and the files it installs on the hosts it allocates will configure a complete, working network with an Open vSwitch running on the host labeled ''switch''. The Open vSwitch switch is configured to connect to a controller on localhost (that is, the switch host), but no controller is started; until a controller is started on localhost, the Open vSwitch will act like a normal learning switch, forwarding all packets to the appropriate interface based on MAC address. ''Trema'' is installed in ''/opt/trema-trema-8e97343.'' Once you have implemented your switch, you can simply use this ''Trema'' install to run it and the Open vSwitch will obey its configuration. [[BR]]
    83   You can test that the network configured correctly by waiting a few moments after Flack or Omni (or whatever GENI tool you are using) suggests that the sliver is ready, and running ping right from the host allocated for left or vice-versa. Since the fallback switch configuration will act like a normal learning switch, the ping packets should go through. [[BR]]
    85   '''Firewall Configuration''' [[BR]]
    86   The firewall configuration language is very simple. All flows not specified in the configuration are assumed to be forbidden, and the default packet processing policy on the OpenFlow device you are managing should be to drop packets. The configuration language will specify, one flow to a line, the TCP flows that should be permitted to pass the firewall. The syntax is:
    87   {{{
    88   <ip>[/<netmask>] <port> <ip>[/<netmask>] <port>
    89   }}}
    90   Items in angle brackets (<>) represent variable values, items in square brackets ([]) represent optional syntax, and unquoted characters (e.g., the slash characters) represent themselves. The first subnet (IP address plus mask length) and port number are the subnet and port number of the host initiating the connection (that is, sending the first bare SYN), and the second subnet and port number are those of the host accepting the connection. IP addresses are specified as dotted quads (e.g., and netmasks as bit lengths (e.g., 24). If a netmask is missing (the IP address for a given subnet is not followed by a slash and an integer), it is equivalent to /32. Port numbers are integers. Either or both of the IP address or port numbers may be replaced by the word any, equivalent to in the case of IP address, or to any port number, in the case of port numbers. [[BR]]
    91   A sample configuration that implements a firewall permitting inbound connections to a web server at IP address on port 80, and any outbound connections initiated by hosts inside the firewall (protecting is as follows:
    92   {{{
    93   any any 80
    94 any any any
    95   }}}
    96   All whitespace will be a single ASCII space character, all newlines will be a single ASCII newline character (0x0a) Empty lines (two newlines back-to-back) are permitted. [[BR]]
    97   A connection is allowable if it matches any rule. A connection matches a rule if all four elements of the four-tuple match. Subnet matching uses standard rules, expressed in this pseudocode:
    98 {{{
    99 boolean subnet_match(IP subnet, int bits, IP addr) {
    100     int32 bitmask =  ̃((1 << 32 - bits) - 1);
    101     IP addrnet = addr & bitmask;
    102     return addrnet ˆ subnet == 0;
    103 }
    104 }}}
    105   Note that rules are not bidirectional; the presence of the first rule in this set does not imply the second:
    106 {{{
    107 any any any
    108 any any any
    109 }}}
    110   This means that the first packet the controller sees that matches a flow causes the flow to be allowed. Packets that would trigger a reply that would be allowed are not necessarily allowed.
    111   The name of a firewall configuration file will be provided on the controller command line. To provide an argument to your controller application, it must be included with the controller file name. For example, to configure your firewall found in ''firewall.rb'' to load ''fw.conf'', you would invoke:
    112 {{{
    113 trema run ’firewall.rb fw.conf’
    114 }}}
    115   You will then find [’firewall.rb’, ’fw.conf’] in ARGV when your controller’s start method is invoked. [[BR]]
    117   '''Firewall Semantics''' [[BR]]
    118   When an OpenFlow device connects to your controller (that is, you receive a switch_ready controller event), your controller should send it instructions to:
    119   - 
    120    - Pass all packets matching allowed connections to your controller
    121    * Drop all other packets [[BR]]
    122   Priorities are going to be critical to the correct operation of your controller, so set them carefully. Higher priority rules match before lower priority rules, and the first matching rule is followed. See Section 3.4 of the [ OpenFlow specification] for more details on flow matching. [[BR]]
    123   Upon receiving a packet from the OpenFlow device (via a ''OFPT_PACKET_IN'' message), your controller should:
    124   -
    125    - Ensure that the packet matches a rule in the configuration
    126    - Insert a flow match in the OpenFlow device for the complete four-tuple matching the incoming packet
    127    - Insert a flow match in the OpenFlow device for the complete four-tuple matching the opposite direction of the same connection
    128    - Instruct the OpenFlow device to forward the incoming packet normally (using ''OFPP_NORMAL'')
    129   Packets which do not match a rule on the controller should be denied. Because your initial device configuration eliminates most of these packets outright, your controller should not see a large number of these packets. [[BR]]
    130   Because this firewall implementation cannot track the actual state of the TCP connections it is managing, removing accepted connections from the forwarding tables on the OpenFlow device must be handled by timers. OpenFlow rules can be removed by an idle timer as well as expired a fixed period after insertion. For this firewall, use an idle timer of 300 seconds. [[BR]]
    132   '''Limitations of this Approach''' [[BR]]
    133   Note that this approach to implementing a firewall has drawbacks. Because the OpenFlow controller does not, and can not efficiently, track the precise state of the TCP flow it is forwarding, the rules are a little bit sloppy. In particular, connections “in progress” when the firewall comes online are not differentiated from new connections created after the firewall is initialized, and connection closings can not be detected by the controller. The former can be managed by inspecting the packet headers included in the ''OFPT_PACKET_IN'' message when a connection is opened, but the latter cannot easily be mitigated. This means that connections with long idle times (and 300 s is not particularly unusual, in the long tail of TCP connection statistics!) will be disconnected unnecessarily, and new connections reusing recent four-tuples may be passed through the firewall without examination by the controller. [[BR]]
    135   '''To get you started, you can download an incomplete version of `firewall.rb` from [ Here], as well as a sample fw.conf [ Here] ''' [[BR]]
    136   '''Question 1. fill up the blanks in function `switch_ready` to insert rules into the openflow switch that allow ICMP and ARP packets to go through''' [[BR]]
    137   '''Question 2. fill up the blanks in function `packet_in` to insert a flow match in the OpenFlow device that allows the packets (as well as those in the reverse path) that match rules in the fw.conf to pass''' [[BR]]
    138   '''Question 3. fill up the blanks in function `packet_in` to insert rules that drops all other packets that does not match the rules specified in fw.conf''' [[BR]]
    139   To verify your implementation, run the following on the switch:
    140 {{{
    141 /opt/trema-trema-8e97343/trema run 'firewall.rb fw.conf'
    142 }}}
    143   Then try to ping from left to right. Ping should go through since you allowed ICMP packets and ARP packets to pass. [[BR]]
    144   If you are using the fw.conf we provided, try to run a TCP session from left to right using iperf using port 5001, 5002, 5003.
    145   Since in the fw.conf file we provided, we specifically allow TCP to go through port 5001 and 5002, but not port 5003, you should be able to see that iperf gives back throughput results for port 5001 and 5002 but not 5003.
    147   Try play with the code as well as the fw.conf file to setup more rules, then verify your setting via iperf or telnet. [[BR]]
    148   You can check the flow table on the OpenFlow Switch via:
    149 {{{
    150 sudo /opt/openvswitch-1.6.1-F15/bin/ovs-ofctl dump-flows tcp:
    151 }}}
    152   A sample output should be something like the following:
    153 {{{
    154 NXST_FLOW reply (xid=0x4):
    155  cookie=0x1, duration=165.561s, table=0, n_packets=6, n_bytes=360, idle_age=17,priority=65535,arp actions=NORMAL
    156  cookie=0xa, duration=43.24s, table=0, n_packets=3, n_bytes=222, idle_timeout=300,idle_age=22,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=46361,tp_dst=5003 actions=drop
    157  cookie=0x5, duration=147.156s, table=0, n_packets=18289, n_bytes=27682198, idle_timeout=300,idle_age=137,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=33385,tp_dst=5001 actions=NORMAL
    158  cookie=0x9, duration=105.294s, table=0, n_packets=4, n_bytes=296, idle_timeout=300,idle_age=60,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=46360,tp_dst=5003 actions=drop
    159  cookie=0x7, duration=124.764s, table=0, n_packets=17902, n_bytes=27095256, idle_timeout=300,idle_age=114,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=57908,tp_dst=5002 actions=NORMAL
    160  cookie=0x3, duration=165.561s, table=0, n_packets=1, n_bytes=74, idle_timeout=300,idle_age=124,priority=65535,tcp,nw_src=,nw_dst=,tp_dst=5002 actions=CONTROLLER:65535
    161  cookie=0x4, duration=165.561s, table=0, n_packets=1, n_bytes=74, idle_timeout=300,idle_age=147,priority=65535,tcp,nw_src=,nw_dst=,tp_dst=5001 actions=CONTROLLER:65535
    162  cookie=0x2, duration=165.561s, table=0, n_packets=0, n_bytes=0, idle_age=165,priority=65535,icmp actions=NORMAL
    163  cookie=0x6, duration=147.156s, table=0, n_packets=9387, n_bytes=624254, idle_timeout=300,idle_age=137,priority=65535,tcp,nw_src=,nw_dst=,tp_src=5001,tp_dst=33385 actions=NORMAL
    164  cookie=0x8, duration=124.764s, table=0, n_packets=9257, n_bytes=617666, idle_timeout=300,idle_age=114,priority=65535,tcp,nw_src=,nw_dst=,tp_src=5002,tp_dst=57908 actions=NORMAL
    165 }}}
    168   '''Hints - Want to get the complete firewall.rb? ask your instructor or visit here (you need a password to get it), or send an email  (the solution code may be full of bugs, feel free to tweak it and report bugs/ask questions)''' [[BR]]
    169   The following list of hints may help you design and debug your implementation more rapidly.
    170   -
    171    - Remember that OpenFlow switches are an Ethernet switch first and foremost, and that not all packets on an Ethernet are IP. In particular, your hosts will require ARP in order to pass IP traffic through the switch!
    172    - You may pass ICMP packets without limitation, to make debugging easier.
    173    - The Trema ''Match'' class has a ''compare()'' method that accepts a ''Match'' argument and may be useful to you — consider the ''!ExactMatch#from()'' method in conjunction.
    175   '''Extra Credit''' [[BR]]
    176   For extra credit (if permitted by your instructor), generate TCP reset segment at the firewall to reset rejected connections.
    178  - '''3.2 Extending the Firewall''' [[BR]]
    179  OpenFlow controllers can also make complex flow decisions based on arbitrary state. This is one benefit to removing the controller from the network device — the controller is free to perform any computation required over whatever data is available when making decisions, rather than being constrained to the limited computing power and storage of the network device. For this exercise, you will extend the firewall described in Section 3.1 to include rudimentary denial of service prevention using this capability. [[BR]]
    181   '''Extended Firewall Configuration'''[[BR]]
    182   You will extend the firewall configuration language to accept an additional final parameter, an integer representing the number of allowable connections matching a given rule at any point in time. As before, the keyword any will be used to indicate that no limiting is to be performed on the rule. The new firewall configuration syntax is:
    183 {{{
    184 <ip>/<netmask> <port> <ip>/<netmask> <port> <limit>
    185 }}}
    187   '''Connection Limiting Semantics''' [[BR]]
    188   The extended firewall will perform flow matching as before, with one added check: if the number of existing flows allowed by a given rule exceeds the limit specified in the configuration, a new flow matching that rule will be denied. The number of existing flows matching a given rule is computed as the number of currently active flow matches in the OpenFlow device for that rule. You may wish to look into the ''OFPT_FLOW_REMOVED'' message for help in implementing this. If a connection rule specifies any as the flow limit, no limiting will be performed by the controller. [[BR]]
    189   Note that the timeout-based nature of flow removal dictates that small connection limits will be quite limiting. Keep this in mind when testing your firewall!
    191   '''Question: extend the firewall.rb to take the new firewall configuration file and accept the additional parameter'''
    192   '''Hints: Want to get the complete firewall.rb? ask your instructor or visit here (you need a password to get it), or send an email (the solution code may be full of bugs, feel free to tweak it and report bugs/ask questions)''' [[BR]]
    193   You probably want to change the `rule` structure defined in function `add_rule` to add two members: `limit` and `count` to store the maximum number of active flows allowed and the current number of active flows. [[BR]]
    194   You should also over-ride the function `flow_removed` to subtract `count` when-ever a flow rule expired. [[BR]]
    195   You might also set the idle_timeout to a smaller number (e.g., 30) so that you do not need to wait for too long before they get removed :-) [[BR]]
    196   To verify your implementation, use `-P` option in iperf to add TCP flows.
    199  - '''3.3 Load Balancing''' -- Files to download: [ lb.rspec], [ load-balancer.rb], [] [[BR]]
    200  Load balancing in computer networking is the division of network traffic between two or more network devices or paths, typically for the purpose of achieving higher total throughput than either one path, ensuring a specific maximum latency or minimum bandwidth to some or all flows, or similar purposes. For this exercise, you will design a load-balancing OpenFlow controller capable of collecting external data and using it to divide traffic between dissimilar network paths so as to achieve full bandwidth utilization with minimal queuing delays. [[BR]]
    201  An interesting property of removing the controller from an OpenFlow device and placing it in an external system of arbitrary computing power and storage capability is that decision-making for network flows based on external state becomes reasonable. Traditional routing and switching devices make flow decisions based largely on local data (or perhaps data from adjacent network devices), but an OpenFlow controller can collect data from servers, network devices, or any other convenient source, and use this data to direct incoming flows. [[BR]]
    202  For the purpose of this exercise, data collection will be limited to the bandwidth and queue occupancy of two emulated network links.
    204   '''Experimental Setup [[BR]]'''
    205   [[Image(OpenFlowAssignment2.png, 50%, nolink)]] [[BR]]
    206   Follow instructions in the [ DesignSetup] step to build a load balancing experiment topology. Your GENI resources will be configured in a manner similar to the above figure. The various parts of the diagram are as follows:
    207   -
    208     - '''Inside and Outside Nodes''': These nodes can be any exclusive ProtoGENI PCs.
    209     - '''Switch:''' The role of the Open vSwitch node may be played either by a software Open vSwitch installation on a ProtoGENI node, or by the OpenFlow switches available in GENI — consult your instructor.
    210     - '''Traffic Shaping Nodes (Left and Right)''': These are Linux hosts with two network interfaces. You can configure netem on the two traffic shaping nodes to have differing characteristics; the specific values don’t matter, as long as they are reasonable. (No slower than a few hundred kbps, no faster than a few tens of Mbps with 0-100 ms of delay would be a good guideline.) Use several different bandwidth combinations as you test your load balancer.
    211     - '''Aggregator''': This node is a Linux host running Open vSwitch with a switch controller that will cause TCP connections to “follow” the decisions made by your OpenFlow controller on the Switch node.
    213   '''Linux netem'''[[BR]]
    214   Use the ''tc'' command to enable and configure delay and bandwidth constraints on the outgoing interfaces for traffic traveling from the OpenFlow switch to the Aggregator node. To configure a path with 20 Mbps bandwidth and a 20 ms delay on eth2, you would issue the command:
    215 {{{
    216 sudo tc qdisc add dev eth2 root handle 1:0 netem delay 20ms
    217 sudo tc qdisc add dev eth2 parent 1:0 tbf rate 20mbit buffer 20000 limit 16000
    218 }}}
    219   See the ''tc'' and ''tc-tbf'' manual pages for more information on configuring tc token bucket filters as in the second command line. Use the ''tc qdisc change'' command to reconfigure existing links,instead of ''tc qdisc add''. [[BR]]
    220   The outgoing links in the provided lb.rspec are numbered and for left and right, respectively.
    222   '''Balancing the Load''' [[BR]]
    223   An example openflow controller that arbitrarily assigns incoming TCP connections to alternating paths can be found at [ load-balancer.rb] (If you have already downloaded it, ignore this). [[BR]]
    224   The goal of your OpenFlow controller will be to achieve full bandwidth utilization with minimal queuing delays of the two links between the OpenFlow switch and the Aggregator host. In order to accomplish this, your OpenFlow switch will intelligently divide TCP flows between the two paths. The intelligence for this decision will come from bandwidth and queuing status reports from the two traffic shaping nodes representing the alternate paths. [[BR]]
    225   When the network is lightly loaded, flows may be directed toward either path, as neither path exhibits queuing delays and both paths are largely unloaded. As network load increases, however, your controller should direct flows toward the least loaded fork in the path, as defined by occupied bandwidth for links that are not yet near capacity and queue depth for links that are near capacity. [[BR]]
    226   Because TCP traffic is bursty and unpredictable, your controller will not be able to perfectly balance the flows between these links. However, as more TCP flows are combined on the links, their combined congestion control behaviors will allow you to utilize the links to near capacity, with queuing delays that are roughly balanced. Your controller need not re-balance flows that have previously been assigned, but you may do so if you like. [[BR]]
    227   The binding of OpenFlow port numbers to logical topology links can be found in the file /tmp/portmap on the switch node when the provided RSpec boots. It consists of three lines, each containing one logical link name (left, right, and outside) and an integer indicating the port on which the corresponding link is connected. You may use this information in your controller configuration if it is helpful. [[BR]]
    228   You will find an example OpenFlow controller that arbitrarily assigns incoming TCP connections to alternating paths in the file [ load-balancer.rb]. This simple controller can be used as a starting point for your controller if you desire. Examining its behavior may also prove instructive; you should see that its effectiveness at achieving the assignment goals falls off as the imbalance between balanced link capacities or delays grows.
    230   '''Gathering Information''' [[BR]]
    231   The information you will use to inform your OpenFlow controller about the state of the two load-balanced paths will be gathered from the traffic shaping hosts. This information can be parsed out of the file /proc/net/dev, which contains a line for each interface on the machine, as well as the tc -p qdisc show command, which displays the number of packets in the token bucket queue. As TCP connections take some time to converge on a stable bandwidth utilization, you may want to collect these statistics once every few seconds, and smooth the values you receive over the intervening time periods. [[BR]]
    232   You may find the file /tmp/ifmap on the traffic shaping nodes useful. It is created at system startup, and identifies the inside- and outside-facing interfaces with lines such as:
    233 {{{
    234 inside eth2
    235 outside eth1
    236 }}}
    237   The first word on the line is the “direction” of the interface — toward the inside or outside of the network diagram. The second is the interface name as found in ''/proc/net/dev''. [[BR]]
    238   You are free to communicate these network statistics from the traffic shaping nodes to your OpenFlow controller in any fashion you like. You may want to use a web service, or transfer the data via an external daemon and query a statistics file from the controller. Keep in mind that flow creation decisions need to be made rather quickly, to prevent retransmissions on the connecting host. [[BR]]
    240   '''Questions'''[[BR]]
    241   To help user to fetch the information about the amount of traffic as well as the queue depth (measured in number of packets) on both left and right node, we provide a script that the user can download and run on both left and right node [[BR]]
    242   You can download the script from [] (If you have already downloaded it, ignore this). Then do the following to start monitoring network usage: [[BR]]
    243  -
    244   - 1. install Twisted Web package for Python on both left and right node:
    245 {{{
    246 sudo yum install python-twisted-web
    247 }}}
    248   - 2. upload onto left and right node, then change the listening IP address in to the public IP address of left and right node respectively. i.e., replacing the following in your file to the public IP address of the left/right node.
    249 {{{
    250 reactor.listenTCP(8000, factory, interface = '')
    251 }}}
    252   - 3. apply qdisc on interface eth1 of both left and right node by executing (you may further change the parameters by using ''tc qdisc change''):
    253 {{{
    254 sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem delay 20ms
    255 sudo /sbin/tc qdisc add dev eth1 parent 1:0 tbf rate 20mbit buffer 20000 limit 16000
    256 }}}
    257   - 4. run the script by:
    258 {{{
    259 python
    260 }}}
    261   - 5. verify it is working by opening a web browser and typing the following URL ('''replacing with your left or right node's public IP address'''):
    262 {{{
    264 }}}
    265   For more information about, please look at the comments in the file. [[BR]]
    267   To help you get started, the following is the ruby class that helps collecting the monitoring results:
    268 {{{
    269 class DataCollector
    270     @@Weight = 0.2
    272     attr_reader :port
    274     def initialize(host, port)
    275         @host = host
    276         @uri = 'http://' + host + ':8000/qinfo/'
    277         @last = 0
    278         @ewmabytes = 0
    279         @ewmapkts = 0
    280         @lock =
    281         @port = port
    282     end
    284     def run
    285         starttime =
    286         while true
    287             data = Net::HTTP.get(URI(@uri + @last.to_s))
    288             data.each do |line|
    289                 ts, bytes, qlen = line.chomp.split(' ').map { |x| x.to_i }
    290                 @lock.synchronize do
    291                     if ts <= @last
    292                         next
    293                     elsif @last == 0
    294                         @ewmabytes = bytes
    295                         @ewmapkts = qlen
    296                     else
    297                         # Just assume we haven't missed too many entries
    298                         @ewmabytes = bytes * @@Weight + @ewmabytes * (1 - @@Weight)
    299                         @ewmapkts = qlen * @@Weight + @ewmapkts * (1 - @@Weight)
    300                     end
    301                     @last = ts
    302                 end
    303             end
    304             sleep 5
    305         end
    306     end
    308     def averages
    309         a = nil
    310         @lock.synchronize do
    311             a = [@ewmabytes, @ewmapkts]
    312         end
    313         return a
    314     end
    315 end
    316 }}}
    317   In the above code, function ''averages'' will return the weighted average number of bytes seen in the corresponding node, as well as the weighted average queue depth in terms of number of packets seen in the corresponding node. [[BR]]
    318   Here is some example code that makes use of this class:
    319 {{{
    320         @collectors = [$leftip, @leftport),
    321              $rightip, @rightport)]
    322         @collectors.each do |collector|
    323    do |c|
    325             end
    326         end
    328         left_monitor_value = @collectors[0].averages
    329         right_monitor_value = @collectors[1].averages
    330         #left_monitor_value[0] shows the average number of bytes seen on the left node
    331         #left_monitor_value[1] shows the average number of queued packets on the left node
    332 }}}
    334   '''Question: Implement your load-balancer.rb, run it on ''switch'', and display the number of bytes and queue length on both left and right node when a new TCP flow comes and path decision is made'''[[BR]]
    335   '''A sample output should be as follows: [[BR]]'''
    336 {{{
    337 left:  5302.5338056252 bytes, Q Depth: 20.5240502532964 packets
    338 right: 14193.5212452065 bytes, Q Depth: 27.3912943665466 packets
    339 so this new flow goes left. Total number of flows on left: 1
    340 }}}
    341   You can use iperf to generate TCP flows from ''outside'' node to ''inside'' node:
    342  -
    343   - On ''inside'', run:
    344 {{{
    345 /usr/local/etc/emulab/emulab-iperf -s
    346 }}}
    347   - On ''outside'' run the following multiple times, with about 6 seconds interval between each run:
    348 {{{
    349 /usr/local/etc/emulab/emulab-iperf -c -t 100 &
    350 }}}
    351     This will give the '''' enough time to collect network usage statistics from both left and right node so that the load-balancer can make the right decision.
    353   '''If you really do not know where to start, you can find a semi-complete load-balancer.rb [ HERE], you only need to complete the ''next_path'' function that prints out the statistics of each path and returns the path choice''' [[BR]]
    354   '''Hints: Want to get the complete load-balancer.rb? ask your instructor or visit here (you need a password to get it), or send an email (the solution code may be full of bugs, feel free to tweak it and report bugs/ask questions)''' [[BR]]
    355   -
    356     - Remember that the TCP control loop is rathers low — on the order of several round trip times for the TCP connection. This means your load balancing control loop should be slow.
    357     - You may wish to review control theory, as well as TCP congestion control and avoidance principles.
    358     - Without rebalancing, “correcting” a severe imbalance may be difficult or impossible. For testing purposes, add flows to the path slowly and wait for things to stabilize.
    359     - Some thoughts on reducing the flow count when load balancing via Open- Flow can be found in [ Wang et al.]  You are not required to implement these techniques, but may find them helpful.
    360     - Remember that the default OpenFlow policy for your switch or Open vSwitch instance will likely be to send any packets that do not match a flow spec to the controller, so you will have to handle or discard these packets.
    361     - You will want your load balancer to communicate with the traffic shaping nodes via their administrative IP address, available in the slice manifest.
    362     - If packet processing on the OpenFlow controller blocks for communication with the traffic shaping nodes, TCP performance may suffer. Use require ’threads’, Thread, and Mutex to fetch load information in a separate thread.
    363     - The OpenFlow debugging hints from Section 3.1 remain relevant for this exercise.
    365 = [wiki:GENIEducation/SampleAssignments/OpenFlowAssignment/ExerciseLayout/Finish Next: Teardown Experiment] =
     82= [wiki:GENIEducation/SampleAssignments/CCNAssignment/ExerciseLayout/Finish Next: Teardown Experiment] =