« Previous 1 2 3 Next »
OpenFlow-capable Zodiac WX access point
Controlled Landing
Unintentionally Dynamic
The port problem of wireless clients adds an involuntary dynamic to OpenFlow application development. Generating a dynamic flow that sends packets to port 5 and the connected wireless client can cause complications: If a wireless client then switches to power-saving mode, it might reappear as the sixth client when it logs back in and be connected to WX port 6 in the OpenFlow logic. Developers for the WX have to pay special attention to this possibility.
The administrator of the Zodiac WX cannot manage the flow rules locally but relies on an OpenFlow controller. In the test, I used Floodlight [6] and OpenDaylight [7]. In its early versions, the WX did not work with OpenDaylight, but Northbound fixed that.
The SDN controller configuration is managed in the web interface under Control | Settings (Figure 4). The Auth Bypass setting ensures that the access point excludes packets that are only used to log on wirelessly (they form their own EtherType) from further flow processing. Alternatively, you need to set up a flow manually that passes these packages through.
Do It Yourself
As usual with OpenFlow-controlled devices, the admin of the device is also its programmer and has to take care of everything personally. To operate a wireless client with activated Auth Bypass , you need to set up flows for ARP and DHCP. The OpenDaylight version of the flow description is shown in Listing 1.
Listing 1
Flow Definitions for Wireless Clients
001 [ 002 { 003 "flow" : [ 004 { 005 "instructions" : { 006 "instruction" : [ 007 { 008 "apply-actions" : { 009 "action" : [ 010 { 011 "output-action" : { 012 "output-node-connector" : "FLOOD" 013 }, 014 "order" : 0 015 } 016 ] 017 }, 018 "order" : 0 019 } 020 ] 021 }, 022 "priority" : "5", 023 "match" : { 024 "ethernet-match" : { 025 "ethernet-type" : { 026 "type" : "0x806" 027 } 028 } 029 }, 030 "table_id" : 0, 031 "id" : "f1" 032 } 033 ] 034 }, 035 { 036 "flow" : [ 037 { 038 "match" : { 039 "ip-match" : { 040 "ip-protocol" : "17" 041 }, 042 "ethernet-match" : { 043 "ethernet-type" : { 044 "type" : "0x800" 045 } 046 }, 047 "udp-destination-port" : "67" 048 }, 049 "table_id" : 0, 050 "id" : "DHCP1", 051 "instructions" : { 052 "instruction" : [ 053 { 054 "order" : 0, 055 "apply-actions" : { 056 "action" : [ 057 { 058 "order" : 0, 059 "output-action" : { 060 "output-node-connector" : "FLOOD" 061 } 062 } 063 ] 064 } 065 } 066 ] 067 }, 068 "priority" : "10" 069 } 070 ] 071 }, 072 { 073 "flow" : [ 074 { 075 "match" : { 076 "ip-match" : { 077 "ip-protocol" : "17" 078 }, 079 "ethernet-match" : { 080 "ethernet-type" : { 081 "type" : "0x800" 082 } 083 }, 084 "in-port" : "65", 085 "udp-destination-port" : "68" 086 }, 087 "table_id" : 0, 088 "id" : "DHCP2", 089 "priority" : "10", 090 "instructions" : { 091 "instruction" : [ 092 { 093 "order" : 0, 094 "apply-actions" : { 095 "action" : [ 096 { 097 "order" : 0, 098 "output-action" : { 099 "output-node-connector" : "NORMAL" 100 } 101 } 102 ] 103 } 104 } 105 ] 106 } 107 } 108 ] 109 } 110 ]
The output port used here is FLOOD
, the OpenFlow counterpart to a broadcast. Once the controller has learned which client belongs to which port, it can cause higher priority flows to output the ARP or DHCP packets for a particular client only on its port.
The Zodiac WX is a hybrid OpenFlow switch, which means it supports the NORMAL
output action. This follows the saying: Send the package where it belongs according to the forwarding table. For switches, this would be the destination MAC address and applies here.
Because the wireless clients do not use physical ports, another special feature appears that is not seen with other OpenFlow devices: The MAC destination address and the port must match or be made to match.
The assignment follows the order when logging in, as described above. OpenFlow assigns port 1 to the 5GHz client that is logged on first. It also remembers the MAC address of the client. This means that the OpenFlow action output:1
must overwrite the target MAC address for the packet to arrive on the appropriate radio channel.
The already mentioned nnofagent
program lists the flows installed by the controller with the -f
option and corresponds to the output in the web interface. The access point also supports the OpenFlow Group
and Meter
properties, with the first action summarizing and the second contributing to throughput control. To list these parameters, use -g
(for groups) and -m
(for meters).
REST API
The configuration of each network device also includes the configuration of IP addresses and, if applicable, virtual LANs (VLANs), which, however, are not supported by the OpenFlow protocol. Instead, the latest firmware release (1.10 at the time of the test) provides a REST API that allows you to perform these basic configurations.
Therefore, you can develop an SDN controller with the appropriate driver to control the entire configuration of the device, which means that an application on this controller can span entire networks and not just control traffic flows.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.