SD-WAN

Hi,

I'm currently experimenting with SDN. In particular, I'm running the latest HP VAN SDN controller (192.168.0.102) with Mininet. Pings for mininet hosts seem to work only when I specify the 'protocols=OpenFlow10'. Leaving default or using 'protocols=OpenFlow13', the pings fail.

sdn@mininet:~$ sudo mn --controller=remote,ip=192.168.0.102 --switch ovs,protocols=OpenFlow10
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Starting CLI:
mininet> h1 ping -c 2 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.266 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.025 ms

--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.025/0.145/0.266/0.121 ms
mininet>

mininet> exit
*** Stopping 1 controllers
c0
*** Stopping 2 links
..
*** Stopping 1 switches
s1
*** Stopping 2 hosts
h1 h2
*** Done
completed in 60.429 seconds

## I did issue sudo mn -c to cleanup before moving on to next ....
sdn@mininet:~$ sudo mn --controller=remote,ip=192.168.0.102 --switch ovs,protocols=OpenFlow13
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Starting CLI:
mininet> h1 ping -c 2 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.

--- 10.0.0.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

mininet> dump
<Host h1: h1-eth0:10.0.0.1 pid=7303>
<Host h2: h2-eth0:10.0.0.2 pid=7306>
<OVSSwitch{'protocols': 'OpenFlow13'} s1: lo:127.0.0.1,s1-eth1:None,s1-eth2:None pid=7312>
<RemoteController{'ip': '192.168.0.102'} c0: 192.168.0.102:6633 pid=7297>
mininet> net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s1-eth2
s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0
c0
mininet> links
h1-eth0<->s1-eth1 (OK OK)
h2-eth0<->s1-eth2 (OK OK)

mininet> exit

sdn@mininet:~$ sudo ovs-vsctl show
bbdf5572-1f93-4982-aae4-e5a9e608d0b5

Bridge "s1"

 Controller "tcp:192.168.0.102:6633"

is_connected: true

Controller "ptcp:6634"

..
ovs_version: "2.5.2"

I have tried with the ODL controller (192.168.0.101) and the ping works in Mininet for both OF1.0 and OF1.3.

sdn@mininet:~$ sudo mn --controller=remote,ip=192.168.0.101 --switch ovs,protocols=OpenFlow13
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Starting CLI:
mininet> h1 ping -c 2 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=998 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.134 ms

--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.134/499.367/998.600/499.233 ms

Just wondering why pings are failing with the HP VAN SDN when specifying OF1.3 in Mininet. Any help much appreciated.

Hi ZzyzxRoad,

We may need a little more information about your setup. I tried close to the same sequence of commands and I saw ping working for both OpenFlow10 and OpenFlow13:

sdn@mininet:~$ sudo mn --controller=remote,ip=10.0.14.11 --switch ovsk,protocols=OpenFlow13
*** 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> h1 ping -c 2 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.348 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.066 ms

--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.066/0.207/0.348/0.141 ms
mininet> exit
*** Stopping 1 switches
s1 ..
*** Stopping 2 hosts
h1 h2
*** Stopping 1 controllers
c0
*** Done
completed in 60.241 seconds

One thing I noticed was that mininet did not allow me to use 'ovs', it forced me to use one of ovsk/user/ovs1/ivs:

sdn@mininet:~$ sudo mn --controller=remote,ip=10.0.14.11 --switch ovs,protocols=OpenFlow10
--------------------------------------------------------------------------------
Caught exception. Cleaning up...

Exception: error: ovs is unknown - please specify one of ['ovsk', 'user', 'ovsl', 'ivs']
--------------------------------------------------------------------------------
*** Removing excess controllers/ofprotocols/ofdatapaths/pings/noxes
...

This leads me to think that you're using a different version of mininet than I am. I am using mininet 2.1.0. Could you post your version of mininet (mn --version)?

Also, it may help to diagnose the issue if you upload your VAN SDN controller logs. They can be obtained through the GUI by clicking General > Support Logs > Export.

Shaun

Hi Shaun,

Thanks for your reply. The version I'm running is:

root@mininet:/home/sdn# dpkg -l | grep mininet
ii mininet 2.2.1-2 amd64 process-based network emulator

Please refer to the attached SDN controller log.

For 17:53 entries it's when I've started mininet (and closed) specifying 1.3 . Mininet host pings fail.

For 17:54 entries it's when I've started (and closed) mininet specifying 1.0. Mininet host pings successful.

Please note the IP's have changed due to a change in location (i.e. moved the VMs to another environment).

Controller IP - 192.168.2.205/24

Mininet VM - 192.168.2.206/24

Let me know if you need any further information.

Thanks

John

Hi John,

It looks like you've hit an incompatibility. The VAN SDN controller support matrix (link below) indicates that the VAN SDN controller supports OVS 2.3.2 (see pages 13 and 16):

http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c05040231

When I upgraded to Ubuntu 16.04 to get the mininet version you're using, I also saw the same failing behavior for OF 1.3. I noticed that the OVS version is 2.5.2 in Ubuntu 16.04:

sdn@mininet:~$ dpkg -l | grep mininet
ii  mininet                               2.2.1-2                     ...
sdn@mininet:~$ dpkg -l | grep openvswitch
ii  openvswitch-common                    2.5.2-0ubuntu0.16.04.1      ...
ii  openvswitch-datapath-source           2.3.1-1                     ...
ii  openvswitch-dbg                       2.5.2-0ubuntu0.16.04.1      ...
ii  openvswitch-ipsec                     2.5.2-0ubuntu0.16.04.1      ...
rc  openvswitch-pki                       2.3.1-1                     ...
ii  openvswitch-switch                    2.5.2-0ubuntu0.16.04.1      ...
ii  openvswitch-test                      2.5.2-0ubuntu0.16.04.1      ...
ii  openvswitch-vtep                      2.5.2-0ubuntu0.16.04.1      ...
ii  python-openvswitch                    2.5.2-0ubuntu0.16.04.1      ...

Mainly the VAN SDN controller just needs to be tested against this newest version of mininet/OVS to be considered compatible. In your case, I'd recommend using the approved and tested version which ships with Ubuntu 14.04:

sdn@scw-mininet:~$ sudo dpkg -l | grep mininet
ii  mininet                               2.1.0-0ubuntu1              ...
sdn@scw-mininet:~$ sudo dpkg -l | grep openvswitch
ii  openvswitch-common                    2.3.1-1                     ...
ii  openvswitch-datapath-source           2.3.1-1                     ...
ii  openvswitch-dbg                       2.3.1-1                     ...
ii  openvswitch-ipsec                     2.3.1-1                     ...
rc  openvswitch-pki                       2.3.1-1                     ...
ii  openvswitch-switch                    2.3.1-1                     ...
ii  openvswitch-test                      2.3.1-1                     ...
ii  openvswitch-vtep                      2.3.1-1                     ...
ii  python-openvswitch                    2.3.1-1                     ...

For what it's worth, I dug into the reason why this setup fails with OpenFlow 1.3 and it looks like a bug in OVS' multi-table support. OpenFlow 1.0 uses only a single table, but OpenFlow 1.3 uses multiple tables. By default the VAN SDN controller will concatenate tables together by putting "goto NEXT" at the end of each table in the pipeline until it has reached the last table in the pipeline. I uploaded a screenshot to show the flow tables in the GUI. This means each packet not hitting the default VAN rules in table 0 will flow through table 1,2,3,... until it reaches the final table 253.

The bug in OVS 2.5.2 looks like it's dropping packets between table 65 and 66 (see "screenshot_counters.png"). I can't explain why ONOS would work, except if they initialize tables differently. That would need more digging, but it is fairly apparent that this is a bug in the newer version of OVS. For more detail, you'll likely need to file a defect with the team that supports mininet/OVS.

Shaun