OpenFlow Flows¶
An OpenFlow forwarding rule, called a flow, is comprised of a match-case (a filter for which the rule applies) and an action (what to do with packets that fit the filter).
In contrast to layer-specific forwarding rules, present in for instance a router or a regular switch, OpenFlow can apply matches on a wide set of fields.
The wide set of matching possibilities allows us to create highly specialized forwarding rules, by creating smart flows.
To successfully create effective flows there are two high-level-approaches one can take.
First, you may ask the question "What should happen if X type of traffic arrives at the forwarding device". This approach enables the construction of highly specific and accurate flow-rules that can take into account protocol specifics and ideal behaviour. As the types of traffic one may expect might be incredibly large, this approach does not scale well and is best used in the case of special traffic types that enable connectivity, such as ARP.
A second approach to designing flows is to be goal oriented. By looking at one's topology and asking the question "What types of traffic should be sent toward device A?" (device A being a device that is connected to the forwarding device we are making flows for). If we are able to create general enough filters based on this question, we can cover a broad amount of traffic types and fulfill the intended behaviour. By asking the counter-question, "What traffic should not be sent toward device A?", we can ensure that our filters do not include unintended traffic-types.
Once we have a high-level understanding of what we want to achieve and include in our flow-rules, we can implement them using OpenFlow's syntax. The general syntax for an openflow-rule is as follows:
comma-seperated-list of match-filters (always including an ethertype match), a priority so that rules are applied with correct precedence, action=comma-seperated-list of actions
Matching¶
The filter always relies on the inclusion of an ethertype match, as depending on which type is specified in the MAC-header, a different layer-3 header in is use and can be matched on. As an example openflow-rule, the following rules combined send IP-traffic with destination addresses in the 192.168.0.0/16 subnet to output port 3, except traffic with destination to 192.168.1.0/24, which goes out to output 2:
"eth_type=0x0800,nw_dst=192.168.0.0/16,priority=50,action=output:3"
"eth_type=0x0800,nw_dst=192.168.1.0/24,priority=100,action=output:2"
ip -> eth_type=0x0800 tcp6 -> eth_type=0x86dd,ip_proto=6
By using the aliases, the example rules above can be written as:
"ip,nw_dst=192.168.0.0/16,priority=50,action=output:3"
"ip,nw_dst=192.168.1.0/24,priority=100,action=output:2"
Actions¶
For some flows, it may be necessary to apply multiple actions, as networking devices commonly modify parts of a packet before forwarding it. One such action, is for instance the decrementation of the TTL-field.
In cases where one wishes to have multiple actions in a flow, the actions are comma-seperated, e.g:
"ip,nw_ttl=0,priority=100,action=drop
"ip,nw_dst=192.168.0.0/16,priority=50,action=dec_ttl,output:3"
Tables¶
As a final note, it is possible to create a hierarchy of tables on an ovs-switch, which allows for iterative flow behaviour, e.g. the matches of the flows in table 1 sends the packet to different tables that are specific to the different traffic-types. One could by the use of tables have a dedicated ARP-table, MPLS-table and so forth, to create a more structure and legible rule-set on the OVS-device. For the labs in TTM4250, table-specification is likely superflouos, but in more complete production set-ups, table organization may be essential to maintain reliable forwarding behaviour.