Network Management

Summer 2016, Corboy 201, TTh 5:30-8:45 pm

Class 9: August 2


OpenFlow example
What if the controller does this (tutorial2.py)
    if (srcaddr is NOT in the forwarding table)
        add flow rule: reach srcaddr via srcport

Demo: with 5 linear switches and a pingall:
h1 sends ping: s1-s5 learn where h1 is
hi sends response: s1-s5 KNOW where h1 is, so the controller is NOT contacted, so the controller does not learn where h2-h5 are
h2 sends ping to h1: s2 knows where h1 is; no controller involvement
h1 responds: packet gets flooded but there's no new source for controller to learn, so no new flows
h2 sends ping to h3/h4/h5: packet gets flooded, s1 (and s2-s5) learns where h2 is
...
h3 sends ping to h1 or h2: s1 and s2 know where h1,h2 are: no flooding, no new flows
h1/h2 respond to h3: packet is flooded; no new source so no new flows
h3 sends ping to h4/h5: packet gets flooded and all switches learn where h3 is
...

In the end, all switches know where h1-h4 are, but not h5:

for i in 1 2 3 4 5
do
    ovs-ofctl dump-flows s$i |egrep -i '00:0[1-5]'
    echo; echo
done

Now for tutorial3.py, using the following strategy:
    put srcaddr into the controller-side per-switch table when an unknown dest packet is reported
    if destaddr is in the controller-side per-switch table, insert both flows, for both src and dest

    This doesn't really work any better. In the following, cs1-cs5 are the controller-side tables

h1 sends ping: cs1-cs5 learn where h1 is, but s1-s5 just flood.
h2 sends response: s2 doesn't know anything, so controller is notified, and controller knows where h1 and h2 are, so s1 and s2 get told where h1 and h2 are.
h3 sends response: s3 doesn't know anything, so

so the controller is NOT contacted, so the controller does not learn where h2-h5 are
h2 sends ping to h1: s2 knows where h1 is; no controller involvement
h1 responds: packet gets flooded but there's no new source for controller to learn, so no new flows
h2 sends ping to h3/h4/h5: packet gets flooded, s1 (and s2-s5) learns where h2 is
...
h3 sends ping to h1 or h2: s1 and s2 know where h1,h2 are: no flooding, no new flows
h1/h2 respond to h3: packet is flooded; no new source so no new flows
h3 sends ping to h4/h5: packet gets flooded and all switches learn where h3 is
...

See also the Pox output file tutorial3_line4.out.

The core problem is that it's new source addresses that switches must inform the controller about, but the flows above match only on the destination address. So, if a packet arrives at a switch S with a destination known to S, then S will not contact the controller even if the source is new.

The fix is to identify flows by a pair (destaddr,srcaddr). Doing this means that a new srcaddr cannot -- because it is new -- be part of an existing flow, and so will always be reported to the controller. The controller would typically install a bidirectional flow for that (destaddr,srcaddr) pair if it knows the port it should use to reach destaddr. If it does not, it will record the port used to reach srcaddr (that is, the port by which this packet arrived), flood the packet, and wait for the destaddr node to reply.

This is done in the pox example forwarding/l2_pairs.py.




BGP

    MED and traffic engineering


SNMPv3