Verification of aggregated flows in OpenFlow networks Sachin Sharma, Wouter Tavernier, Didier Colle, Mario Pickavet, and Piet Demeester Department of Information Technology (INTEC), Ghent University - iMinds, Email: {sachin.sharma, wouter.tavernier, didier.colle, mario.pickavet, piet.demeester}@intec.ugent.be Abstract—Recently, the automatic test packet generation (ATPG) tool is proposed to verify a network for error conditions (e.g., incorrect firewall rules, software, hardware, and perfor- mance errors). However, this tool is not able to verify aggregated flows (i.e., flows having wildcards in some of their fields) for matching issues. In this paper, we propose a mechanism to verify aggregated flows in OpenFlow networks. In the demonstration, we verify aggregated flows installed in an emulated pan-European topology using our proposed mechanism. I. I NTRODUCTION In OpenFlow [1], the control plane is decoupled from switches or routers, and is embedded into one or more external servers called controllers. However, like traditional networks, debugging for errors (e.g., software, hardware, and firewall rules errors) is one of the time consuming and complex tasks in OpenFlow networks. One of the reasons of this complexity is the presence of aggregated flows, which contain several individual flows by having wildcards in some of their fields. As aggregated flows can match many different flows, it is difficult to find which flow is having an issue (such as matching issue). The issue could be caused by misconfiguration (e.g., firewall rules), software issues, hardware issues, or malicious attacks. Debugging all these errors is difficult by just analyzing the configuration of networks. Therefore, network operators have to debug manually by sending test packets in the network. Manual debugging takes significant time in finding the issues. Therefore, the ATPG tool [2] is proposed recently for automatic verification of all flows by transmitting test packets in networks. However, this tool does not verify the matching header part of aggregated flows for software or hardware matching issues. In this paper, we propose a mechanism to verify all the aggregated flows for these issues. The aim of our mechanism is : (1) to perform automatic discovery of matching errors, (2) to minimize the time required to find errors, (3) to minimize the bandwidth required for verification. The mechanism is implemented in the part of a verification activity [3] in the UNIFY project (www.fp7-unify.eu). For the demo, we first generate the matching errors for aggregated flows and then find these errors using our mecha- nism. Executing the mechanism, generating errors, and finding the errors are performed by different GUIs (Graphical User Interface) placed in the controller and in an emulated switch topology (pan-European topology). In addition, during the demo, we transmit data traffic containing faulty and non-faulty flows, and show that the errors found through our mechanism are actually present in the network, as traffic containing faulty flows are not received by the destinations. II. VERIFICATION MECHANISM In our mechanism, for verification, two steps – (1) flow- entry transformation and (2) test packet generation – are performed. The flow-entry transformation step transforms an aggregated flow-entry into three entries and can be performed at the time of flow addition. The test packet generation step verifies these three entries for matching issues and can be performed at any time when the verification of the aggregated flow is required. In the mechanism, a field (such as EtherType or VLAN) of a flow is used to distinguish data and test packets. It is assumed that this field is always wildcarded for data flows. This assumption allows the mechanism to add the same matching-header for two of the entries (flow-entry 1 and 2 in Fig. 1) in the flow-entry transformation step. As the matching- header part of these entries is same, the assumption is that if a matching error is present in one entry, it is also present in the other entry. P, matching-header: actions (P, EtherType, IP): actions (P, *, 10.1.*.*/16): Table:2 FlowTABLE 1 FlowTABLE 2 1 P, matching-header: actions (P, EtherType, IP): actions (P, *, 10.1.*.*/16): Port:3 (P+, E,10.1.*.*/16):Drop 2 3 P, matching-header: actions (P, EtherType, IP): actions (P, *, 10.1.*.*/16): Port:3 Aggregated Flow Transformed Aggregated Flow * = wildcard and E is EtherType of test packets FlowTABLE 1 Fig. 1. Flow-Entry Transformation step. P+ is a priority no. higher than P The flow-entry transformation step is shown in Fig .1. In this step, an aggregated flow is transformed into three flow- entries. The first entry is present in the same FlowTable as the original flow, and the other two entries are present in another FlowTable i.e., FlowTable 2 in Fig .1. The first flow-entry, which has the same matching header as the original flow, redi- rects all the matched packets to another table (i.e., FlowTable 2). The second flow-entry, which has same matching-header as the first entry and a lower priority number than the third entry, redirects all the matched data packets to the output action (Port:3) of the original flow. The third flow-entry, which contains EtherType (E) of test packets in its matching header part, drops all the matched test packets. After establishing these entries, the controller can now perform verification using test packet generation step. In the test packet generation step, the controller finds the matching errors in the aggregated flow by transmitting test packets. For finding errors in a switch, the controller in our mechanism sends first all the test packets (which can be matched through an aggregated flow). It then finds the number of errors by subtracting the number of sent packets from the increase in the counters (statistics) of the third flow entry (the third entry) in FlowTable 2. It also finds that if there is an increase in counters of another test packet flow-entry containing unmatched flow (due to incorrect matching). At this time, the controller knows the number of flow matching errors. However, it does not know that which flows have a