OpenFlow/OpenFlow Tutorial 2

labs.beatcraft.com
OpenFlow

OpenFlow/OpenFlow Tutorial 2 †

To use Wireshark, compare the performance of types of the switches by contents of OpenFlow packets. This resembles a part of OpenFlow Tutorials. Its details are listed at the URL below.

http://www.openflow.org/wk/index.php/OpenFlow_Tutorial

Displaying OpenFlow Pcket †

To use Wireshark, which includes OpenFlow analytical plugins, observe the flow of packets on the virtual network that is created at OpenFlow/OpenFlow Tutorial 1.

$ sudo wireshark

To boot Wireshark, capture the packets at loopback interface.
To imput “of” a string at Filter, it recognizes only OpenFlow related packets (Protocol OFP).

While Wireshark monitors the packets, boot the controller, which implements OpenFlow reference, as the learning switch.

$ controller ptcp:

To look at the capture window of Wireshark, see how the controller and switch communicate each other.

The messages and their details are shown below.

Hello	switch → controller	Show the version of OpenFlow
Hello	controller → switch	Show the version of OpenFlow
Feature Request	controller → switch	Request feature
Set Config	controller → switch	Controller shows how to handle IP fragments and the maximum bytes of a new flow
Features Reply	switch → controller	Switch replies a list of features

In mininet environment, all packets are handled via localhost, so their original sender's IP address are not specified. The controller uses the OpenFlow standard port 6630, and the switch occupies any available port. (for this example, the port number is 54129.)

While learning switch is effective, send a ping, and check what will happen on OpenFlow. Then, to pture the interface of loopback by Wireshark again, echo Request/Reply, which maintains the connection between the controller and switch, is needed to work as a filter, input string at the entry field, and apply it. As this is completed, the capturing process will start.

of && (of.type != 3) && (of.type != 2)

At this moment, table flow is empty.
Try to check it in shell, in stead of mininet command.

$ dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x7a3fc29b): flags=none type=1(flow)

Send a ping by mininet prompt.

mininet> h1 ping -c1 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=4.43 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.431/4.431/4.431/0.000 ms

In the capture window of Wireshark show new messages. (See the image below.)

The contents of the messages are shown below.

Packet In	Switch → Controller	Receiving packets (Since there are no matches on the flow table at the switch, switch sends packets to the controller.)
Packet Out	Controller → Switch	Sending packets
Flow Mod	Controller → Switch	Add a flow to the flow table

To check the flow table, the entries shown below are added by the controller.

$ dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x342f8af7): flags=none type=1(flow)
  cookie=0, duration_sec=18s, duration_nsec=654000000s, table_id=0, priority=65535, n_packets=1, n_bytes=98, idle_timeout=60,hard_timeout=0,icmp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,nw_src=10.0.0.2,nw_dst=10.0.0.1,nw_tos=0x00,icmp_type=0,icmp_code=0,actions=output:1
  cookie=0, duration_sec=18s, duration_nsec=655000000s, table_id=0, priority=65535, n_packets=1, n_bytes=98, idle_timeout=60,hard_timeout=0,icmp,in_port=1,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_tos=0x00,icmp_type=8,icmp_code=0,actions=output:2
  cookie=0, duration_sec=13s, duration_nsec=650000000s, table_id=0, priority=65535, n_packets=1, n_bytes=42, idle_timeout=60,hard_timeout=0,arp,in_port=1,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_proto=2,actions=output:2
  cookie=0, duration_sec=18s, duration_nsec=656000000s, table_id=0, priority=65535, n_packets=1, n_bytes=42, idle_timeout=60,hard_timeout=0,arp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,nw_src=10.0.0.2,nw_dst=10.0.0.1,nw_proto=2,actions=output:1
  cookie=0, duration_sec=13s, duration_nsec=653000000s, table_id=0, priority=65535, n_packets=1, n_bytes=42, idle_timeout=60,hard_timeout=0,arp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,nw_src=10.0.0.2,nw_dst=10.0.0.1,nw_proto=1,actions=output:1

This is a case that OpenFlow is set and used in Passive mode.
In Passive modem, a flow interacts with each packet.

Deferences in the performance of types of switches †

To boot the mininet environment with mn commands, the switch option is specified by --switch. This option make difference in throughputs.

The switch of the mininet environment, which has been used here, is Open vSwitch

$ sudo mn --topo single,3 --mac --switch ovsk --controller remote
mininet> iperf
*** Iperf: testing TCP bandwidth between h1 and h3
*** Results: ['514 Mbits/sec', '517 Mbits/sec']

In average, it reaches 300 ~ 500 Mbps throughputs.

This time, the mininet boots with a switch, which works in the user-land applied by the reference implementation of OpenFlow.

$ sudo mn --topo single,3 --mac --switch user --controller remote
mininet> iperf
*** Iperf: testing TCP bandwidth between h1 and h3
*** Results: ['88.9 Mbits/sec', '89.2 Mbits/sec']

In this implementation, packets need to move from user-space to kernel space several times. This is the reason why its throughputs are lower than the previous setting. With this switch, it is not complicated to improve the throughputs.

Revision History †

• 2013/08/28 This article is initially uploaded.