I am using the prepackaged mininet on Oracle VM Virtual Box VM (Ubuntu
13.04, mininet 2.1.0) running in a Windows 8 (HP Pavilion AMD A8). The
version of OpenVSwitch is 1.9.0.
I configured simple reactive hub which installs a temporary FLOOD flow when
a PacketIn event is received by the controller. I expected it to behave just
like the proactive hub example included with POX that uses instead the
ConnectionUp event to install a permanent flow. I want the controller to
install a new flood each time a new series of packets arrive (and that is
working!). But what is also happening is that only the first ping after
about one minute of the network being idle --when both the switch flow and
the hosts ARP entries have timeout-- is successful.
The ARP packets generated by the first ping --with destination broadcast MAC
address ffff ffff ffff-- is flooded as expected to all hosts as well as the
subsequent ARP reply and the ICMP echo request/reply packets.
However if I send another ping after the flow has expired but before the
host ARP entries become stale (so, no broadcast address is sent), the ping
fails. The ICMP REQUEST does not appear to be flooded to any port (at least
according to tcpdump) by the switch/hub even though it gets a new FLOOD flow
and receives & replies to the ARP requests from the initiating host h1. So
at least the flow is working for the ARP packets but is not flooding the
ICMP packets.
I do not get any errors from python, mininet or pox.
Here is the complete code that I am having this issue with:
Hub-reactive.py
from pox.core import core
import pox.openflow.libopenflow_01 as of
from pox.lib.util import dpid_to_str
class hub_reactive (object):
def __init__ (self, connection):
self.connection = connection
# We want to hear PacketIn messages
connection.addListeners(self)
def _handle_PacketIn (self, event):
packet = event.parsed
print event.ofp.buffer_id, packet.type, packet.src, packet.dst,
dpid_to_str(event.dpid), event.port
msg = of.ofp_flow_mod()
msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))
msg.idle_timeout = 10
msg.hard_timeout = 30
self.connection.send(msg)
class myHub (object):
"""
Waits for OpenFlow switches to connect and makes them reactive hubs.
"""
def __init__ (self):
core.openflow.addListeners(self)
def _handle_ConnectionUp (self, event):
hub_reactive(event.connection)
def launch ():
core.registerNew(myHub)
SETUP
I start mininet with 3 hosts, one ovsk switch and the POX controller
sudo mn --topo single,3 --mac --switch ovsk --controller remote
Start pox controller
mininet@mininet-vm:~/pox$ ./pox.py log --file=pox.log log.level --DEBUG
misc.hub-reactive
POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.
DEBUG:core:POX 0.2.0 (carp) going up...
DEBUG:core:Running on CPython (2.7.4/Apr 19 2013 18:28:01)
DEBUG:core:Platform is
Linux-3.8.0-19-generic-x86_64-with-Ubuntu-13.04-raring
INFO:core:POX 0.2.0 (carp) is up.
DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
INFO:openflow.of_01:[00-00-00-00-00-01 1] connected
RESULTS
With the first ping, the host h1 sends an ARP broadcast message and the
controller correctly installs a FLOOD flow on the switch. All the packets
are forwarded both ways and the ping is successful:
h1 ping -c 1 h2 (succesfull ping as expected)
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=998 ms
--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 998.928/998.928/998.928/0.000 ms
A flow has been successfully installed:
dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x7603b3fe): flags=none type=1(flow)
cookie=0, duration_sec=5s, duration_nsec=519000000s, table_id=0,
priority=32768, n_packets=4, n_bytes=280,
idle_timeout=10,hard_timeout=30,actions=FLOOD
tcpdump -XX -n -i h1-eth0
10:30:20.251210 ARP, Request who-has 10.0.0.2 tell 10.0.0.1, length 28
0x0000: ffff ffff ffff 0000 0000 0001 0806 0001 ................
0x0010: 0800 0604 0001 0000 0000 0001 0a00 0001 ................
0x0020: 0000 0000 0000 0a00 0002 ..........
10:30:20.251546 ARP, Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 46
0x0000: 0000 0000 0001 0000 0000 0002 0806 0001 ................
0x0010: 0800 0604 0002 0000 0000 0002 0a00 0002 ................
0x0020: 0000 0000 0001 0a00 0001 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 ............
10:30:20.251550 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 13694, seq 1,
length 64
0x0000: 0000 0000 0002 0000 0000 0001 0800 4500 ..............E.
0x0010: 0054 0000 4000 4001 26a7 0a00 0001 0a00 .T..@.@.&.......
0x0020: 0002 0800 17f3 357e 0001 ab8b 2d54 0000 ......5~....-T..
0x0030: 0000 0fdb 0300 0000 0000 1011 1213 1415 ................
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 67
10:30:20.251615 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 13694, seq 1,
length 64
0x0000: 0000 0000 0001 0000 0000 0002 0800 4500 ..............E.
0x0010: 0054 8b44 0000 4001 db62 0a00 0002 0a00 [email protected]......
0x0020: 0001 0000 1ff3 357e 0001 ab8b 2d54 0000 ......5~....-T..
0x0030: 0000 0fdb 0300 0000 0000 1011 1213 1415 ................
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 67
10:30:25.254489 ARP, Request who-has 10.0.0.1 tell 10.0.0.2, length 46
0x0000: 0000 0000 0001 0000 0000 0002 0806 0001 ................
0x0010: 0800 0604 0001 0000 0000 0002 0a00 0002 ................
0x0020: 0000 0000 0000 0a00 0001 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 ............
10:30:25.254498 ARP, Reply 10.0.0.1 is-at 00:00:00:00:00:01, length 28
0x0000: 0000 0000 0002 0000 0000 0001 0806 0001 ................
0x0010: 0800 0604 0002 0000 0000 0001 0a00 0001 ................
0x0020: 0000 0000 0002 0a00 0002 ..........
(As a side question, I don't understand why there are ARP requests AFTER the
ICMP echo reply has already been received!)
The controller printed the packetIn event:
buffer_id, packet.type, packet.src, packet.dst, event.dpid, event.port
258 2054 00:00:00:00:00:01 ff:ff:ff:ff:ff:ff 00-00-00-00-00-01 1
However, if I wait to send another ping until after the idle timeout expires
and the flow is removed but before the ARP entries in the hosts expire, the
ICMP echo request is still sent from h1 but never received by neither h2 nor
h3 (as if it is not matching the FLOOD flow on the hub s1:
dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0xf1b5c2b9): flags=none type=1(flow)
mininet@mininet-vm:~/pox/pox$ à (Flow expired)
ARP Addresses Catched
mininet> h2 arp
Address HWtype HWaddress Flags Mask
Iface
10.0.0.1 ether 00:00:00:00:00:01 C
h2-eth0
mininet> h1 arp
Address HWtype HWaddress Flags Mask
Iface
10.0.0.2 ether 00:00:00:00:00:02 C
h1-eth0
h1 ping -c 1 h2 (Ping unexpectedly fails!)
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
--- 10.0.0.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
As recorded by initiating host 1:
10:30:49.831398 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 13703, seq 1,
length 64
0x0000: 0000 0000 0002 0000 0000 0001 0800 4500 ..............E.
0x0010: 0054 0000 4000 4001 26a7 0a00 0001 0a00 .T..@.@.&.......
0x0020: 0002 0800 6c15 3587 0001 c98b 2d54 0000 ....l.5.....-T..
0x0030: 0000 94af 0c00 0000 0000 1011 1213 1415 ................
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 67
10:30:54.838934 ARP, Request who-has 10.0.0.2 tell 10.0.0.1, length 28
0x0000: 0000 0000 0002 0000 0000 0001 0806 0001 ................
0x0010: 0800 0604 0001 0000 0000 0001 0a00 0001 ................
0x0020: 0000 0000 0000 0a00 0002 ..........
10:30:54.839247 ARP, Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 46
0x0000: 0000 0000 0001 0000 0000 0002 0806 0001 ................
0x0010: 0800 0604 0002 0000 0000 0002 0a00 0002 ................
0x0020: 0000 0000 0001 0a00 0001 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 ............
No ICMP reply from h2!
As recorded by both hosts 2 and 3:
10:30:54.839220 ARP, Request who-has 10.0.0.2 tell 10.0.0.1, length 46
0x0000: 0000 0000 0002 0000 0000 0001 0806 0001 ................
0x0010: 0800 0604 0001 0000 0000 0001 0a00 0001 ................
0x0020: 0000 0000 0000 0a00 0002 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 ............
10:30:54.839230 ARP, Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 28
0x0000: 0000 0000 0001 0000 0000 0002 0806 0001 ................
0x0010: 0800 0604 0002 0000 0000 0002 0a00 0002 ................
0x0020: 0000 0000 0001 0a00 0001 ..........
No ICMP request or reply to/from h2 but a new flow correctly installed (I
assume because of the ARP packet were received?):
dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0xf61351da): flags=none type=1(flow)
cookie=0, duration_sec=6s, duration_nsec=796000000s, table_id=1,
priority=32768, n_packets=2, n_bytes=120,
idle_timeout=10,hard_timeout=30,actions=FLOOD
The controller printed the packetIn event:
buffer_id, packet.type, packet.src, packet.dst, event.dpid, event.port
260 2048 00:00:00:00:00:01 00:00:00:00:00:02 00-00-00-00-00-01 1
If I wait a minute or so, until the arp entries become stale, the first ping
after that is again successful (although with 1000ms delay!?
On the other hand if I change the PacketIn event handler to send out the
messages received using packet_out instead of flow_mod, then all packets
are flooded correctly to all hosts. Here is the modified PacketIn handler
that works as expected:
def _handle_PacketIn (self, event):
packet = event.parsed
msg = of.ofp_packet_out()
msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))
msg.data = event.ofp
msg.in_port = event.port
self.connection.send(msg)
I did upgrade POX from betta to carp and I also tried using a different
switch with the option --switch user, after stopping ovs with the same
results:
sudo /etc/init.d/openvswitch-controller stop
sudo/etc/init.d/openvswitch-switch stop
Id appreciate any help to understand why installing a flow to flood all
packets do not work as expected (at least by me) in this simple hub
configuration.
Thanks,
David Martin
_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
