4
votes

Summary: I am unable to ping between hosts using Opendaylight and Mininet, and would appreciate some guidance as to what may be the problem.

Setup and what I've done so far: I've been stuck on this for two days now and can't seem to find anything about it. I've got a Win7 laptop running VMware Workstation 10.0.3. I've installed Ubuntu 12.04 with Opendaylight, and I've got Mininet 2.0 running. All NICs are bridged. I can ping between all of them. Running Firefox, Putty and Xming on the Win7. I can log into the Opendaylight.

Opening up Putty and starting Mininet with: sudo mn --mac --controller=remote,ip=192.168.0.118,port=6633 I get the normal response of creating network etc. Ping fails. In Wireshark I see ARP requests but no answers. The controller now shows the switch. Adding the gateway 10.0.0.254/8 makes the controller see the hosts, but still no ping. I still see ARP requests, but no answers. I removed the gateway and installed the flows as per the instructions. No ping.

I've tried doing all this from the VMs themselves, skipping Putty and the laptop, with the same result. I've also tried using Ubuntu 14.04 and Mininet 2.10. Same result. I've been reading the Opendaylight wiki and apparently nobody else have this problem. Which means I must be missing something basic. I just can't figure out what it is.

EDIT, MININET OUTPUT: (As asked for below)

mininet> s1 ovs-ofctl dump-flows s1
ovs-ofctl: 127.0.0.1 is not a bridge or a socket
mininet> s1 ovs-ofctl dump-flows "s1"
NXST_FLOW reply (xid=0x4):
mininet>

So the flows created on the controller hasn't made it over to Mininet?

Hi again, and thanks for your input. I've tried to follow your example to the letter and below is what I get:

Last login: Thu Jul 10 13:56:17 2014

mininet@mininet-vm:~$ sudo mn --mac --controller=remote,ip=192.168.0.115,port=6633
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
*** Starting 1 switches
s1
*** Starting CLI:
mininet> pingall
*** Ping: testing ping reachability
h1 -> X
h2 -> X
*** Results: 100% dropped (0/2 received)

mininet> s1 ovs-ofctl show "s1"
OFPT_FEATURES_REPLY (xid=0x1): dpid:0000000000000001
n_tables:255, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 1(s1-eth1): addr:a6:fc:ac:e6:ab:2a
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 100 Mbps max
 2(s1-eth2): addr:2e:8a:70:b0:48:82
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 100 Mbps max
 LOCAL(s1): addr:1a:74:aa:bb:5a:49
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 100 Mbps now, 100 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
mininet>
mininet>
mininet> s1 ovs-ofctl add-flow "s1" priority=1,ip,nw_dst=10.0.0.2,actions=mod_dl_dst:00:00:00:00:00:02,output=2
mininet> s1 ovs-ofctl add-flow "s1" priority=1,ip,nw_dst=10.0.0.1,actions=mod_dl_dst:00:00:00:00:00:01,output=1
mininet>
mininet>
mininet> s1 ovs-ofctl dump-flows "s1"
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=44.765s, table=0, n_packets=0, n_bytes=0, idle_age=44, priority=1,ip,nw_dst=10.0.0.1 actions=mod_dl_dst:00:00:00:00:00:01,output:1
 cookie=0x0, duration=71.05s, table=0, n_packets=0, n_bytes=0, idle_age=71, priority=1,ip,nw_dst=10.0.0.2 actions=mod_dl_dst:00:00:00:00:00:02,output:2
mininet>
mininet>
mininet> pingall
*** Ping: testing ping reachability
h1 -> X
h2 -> X
*** Results: 100% dropped (0/2 received)
mininet> h1 ping -c2 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
From 10.0.0.1 icmp_seq=2 Destination Host Unreachable

--- 10.0.0.2 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms
pipe 2
mininet>

I ran the same command as in the listing above, I got the same result. I then ran the command you suggested as listed below and here's the output. I didn't know there were two controllers as listed in the output, but the connected one is the correct one with the correct IP address.

mininet>
mininet> s1 ovs-vsctl list controller
_uuid               : 5c50bc34-725b-497c-86f2-e0b8eafc34f9
connection_mode     : []
controller_burst_limit: []
controller_rate_limit: []
enable_async_messages: []
external_ids        : {}
inactivity_probe    : []
is_connected        : true
local_gateway       : []
local_ip            : []
local_netmask       : []
max_backoff         : 1000
other_config        : {}
role                : other
status              : {sec_since_connect="395", state=ACTIVE}
target              : "tcp:192.168.0.115:6633"

_uuid               : e5ba6cf2-dd48-4c2b-88b7-4546e90f98d0
connection_mode     : []
controller_burst_limit: []
controller_rate_limit: []
enable_async_messages: []
external_ids        : {}
inactivity_probe    : []
is_connected        : false
local_gateway       : []
local_ip            : []
local_netmask       : []
max_backoff         : 1000
other_config        : {}
role                : []
status              : {}
target              : "ptcp:6634"
mininet>

And I did run the ss command on the controller and everything showed either "Active" or "Resolved".

4
Its a little unclear exactly what you're asking. I suggest you edit and just add a short summarized version of your question.Aelphaeis
Did you add flow rules for bridges?user3771522
I added the flows (one each way) to the the controller under the "Flows" tab by clicking on the "Add Flow" button. Are there any other place I need to add them? I guess I'm a little confused by the term "bridges", I thought they were called Switches. I'll go through the documentation again to make sure we're talking about the same thing.OldePhart
We are talking about the same thing because "bridge" is used everywhere in the documentation of OvS even if it's a switch (see the FAQ). «Q: I thought Open vSwitch was a virtual Ethernet switch, but the documentation keeps talking about bridges. What's a bridge? A: In networking, the terms "bridge" and "switch" are synonyms. Open vSwitch implements an Ethernet switch, which means that it is also an Ethernet bridge.»user3771522
Can you edit your post and add the result of the «ovs-ofctl dump-flows s1» in xterm or in mininet CLI «s1 ovs-ofctl dump-flows "s1"»? (i think s1 is the name of the bridge (switch) if you use the default mininet network).user3771522

4 Answers

4
votes

I still don't know what the problem was, but the resolution was to go back to square one, and do everything over again. This time I didn't download the pre-built Opendaylight application, I built it myself. I'm not a Linux expert in any way, which is why I was reluctant to do this before. However, building from sources apparently made a difference. Got everything installed and configured and now I have a working controller.

Many thanks for all the help and hints as to where to look, and what to look for. Much appreciated.

2
votes

It seems the switch doesn't have any flow rules. You must add them manually.

If you have more than 1 host in your network (and no tunnel between the pinging hosts), a "pingall" in mininet CLI should work because it automatically add flow rules to switches

I use the same configuration

mn --mac --controller=remote,ip=192.168.2.4,port=6633

I can ping hosts but let's consider it didn't work and delete the existing rules.

The network I use is the default one i.e. 2 hosts connected to the same switch

mininet> net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s1-eth2
s1 lo:  s1-eth1:h1-eth0 s1-eth2:h2-eth0
c0

Since the flow table is empty, we need to add flows to the switch. So we have to know the ports it used.

mininet> s1 ovs-ofctl show "s1"
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 1(s1-eth1): addr:6e:ab:c5:6d:e5:ad
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 2(s1-eth2): addr:da:64:44:ec:d9:66
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 LOCAL(s1): addr:c2:53:40:c8:d9:4b
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

we know now that «h1 is connected to s1-eth1 that is the port 1» and «h2 is connected to s1-eth2 that is the port 2»

To ping from h1 to h2, add those rules changing host_ip and host_mac (an eventually adapt to your own network topology)

mininet> s1 ovs-ofctl add-flow "s1" priority=1,ip,nw_dst=<host2_ip>,actions=mod_dl_dst:<host2_mac>,output=2
mininet> s1 ovs-ofctl add-flow "s1" priority=1,ip,nw_dst=<host1_ip>,actions=mod_dl_dst:<host1_mac>,output=1

Let's verify the flow table

mininet> s1 ovs-ofctl dump-flows "s1"
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=14.02s, table=0, n_packets=0, n_bytes=0, idle_age=14, priority=1,ip,nw_dst=10.0.0.2 actions=mod_dl_dst:00:00:00:00:00:02,output:2
 cookie=0x0, duration=7.692s, table=0, n_packets=0, n_bytes=0, idle_age=7, priority=1,ip,nw_dst=10.0.0.1 actions=mod_dl_dst:00:00:00:00:00:01,output:1

And now hosts can ping each over!

mininet> h1 ping -c2 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=43.9 ms
64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=0.100 ms

If your network is different you can adapt the rules but the steps will be the same

0
votes

I had the same situation as above. This command worked for me :

 sudo mn --mac --arp --controller=remote,ip=192.168.1.33,port=6633
0
votes

I think you should add another flow allowing the ARP request as follows:

mininet> sh ovs-ofctl add-flow s1 dl_type=0x806,nw_proto=1,actions=flood