SD-WAN

I can't seem to get my OVS version 2.2 to forward flows I am using the following script

 

payload05='{ "flow": { "priority": 30000,
                                            "idle_timeout":120,
                                            "table_id":202,
                                            "match": [{"eth_type":"ipv4"},
                                                                {"ipv4_src":"10.0.0.1"},
                                                                {"ipv4_dst":"10.0.0.15"},
                                                                {"ip_proto":"tcp"},
                                                                {"tcp_dst": "80"}],
                                            "instructions":[{"apply_actions":[{"output":3}]}]
}}'

 

The flows show up on the controller when I go to openflow monitor, but when I use the follow flow in the topology section, on the switch details the outport does not display and the flow stops at this switch and does not continue. Why is this? Am I doing something wrong? Any help on this?

Thanks

 

#Openflow1.3
#HPVANSDNcontroller
#Mininet
#restapi

Hello,

 

Do you have a host with IP 10.0.0.15 actually connected to port 3 of your switch?

 

 

Regards,

 

Antonio

SDN Team

 

No it's connected to a switch. This is the network topology as seen on the controller. This is using OF 1.0.

This is switch 5 using OF 1.3 and the flow in the table. No OF seems to be running through the switch at all when it is enbaled to OF1.3. I don't know if it is the switch's fault or the controller that is not compatible.  Also I have tried table 200. I am new so openflow and as far as I know from table 200 up is software based tables.

Hello,

 

are you using Mininet, right?

Which topology are you building?

 

 

are other DPIDs showing same flow?

 

Regards,

 

Antonio

SDN Team

 

Hello,

 

which version of the controller are you running?

 

Regards,

 

Antoino

SDN Team

Version 2.0 of controller, version 2.2 of ovs

I am building a custom topology using python. I can send you the script if you like.

hello,

 

Yes, please.

I would suggest you to test the same script against version 2.4.6 of the controller.

This the latest public version available and the one I'm going to test your script.

If you prefer ,you can send me the script as a privat message.

 

Regards,

 

Antonio

I tried the 2.4.6 version of the controller and the links are going crazy, even with openflow 1.0. Links are going up and down, connecting to the wrong switchs. Version 2.0 of the controller seems to be the only version that works

I have sent my python config for mininet. I used  "sudo ovs-vsctl set bridge s5 protocols=OpenFlow10,OpenFlow13" to change the OVS 2.2 to OF 1.3

It seems Hp don't help Students!

Hello Spankalish,

 

We do help students and we're happy to do it.

Unfortunately I was not able to reply to you before or to run your script as per yet.

 

Considering that your goal seems to be showing the controller capabilities and the differencies between OF version 1.0 and OF version 1.3 I do think you should use Mininet and the VAV SDN controller together.

if you configure a simple topology with mininet providing the setting :

 

--controller=remote,ip=<IP ADDRESS OF YOUR CONTROLLER>

 

e.g:

 

sudo mn --controller=remote,ip=192.168.80.133 --topo linear,4

 

you should be able to see the topology on the Controller's Topology page (if the device running mininet and the device running on the controller can reach each other).

 

You can run mininet on version 1.0 or version 1.3 and this will allow you to show the differencies between the 2 versions of the OpenFlow protocol.

 

I hope this helps you and please inform me if it does not,

 

Regards,

 

Antonio

On using the above Mininet topology the host do show up on the topology this time as well as the switchs, but now using the bash script for OpenFlow, I get an error that says no such device 00:00:00:00:00:00:00:01, even though the data path ID on switch 1 is the same. 

Hi,

 

On a fresh VM, I downloaded Mininet 2.1, OVS version is 2.0.2.

I modified your script to use my controller 2.4.6 running on a different VM.

When I run the script I can see the topology, 2 switch connected and 5 hosts each(hosts can be seen after generating traffic).

 

Negotiated OpenFlow version is 1.0.

When I run the command :

 

sudo s1 protocols=OpenFlow10,OpenFlow13

 

Switch 1 (dpid 00:00:00:00:00:00:00:01) negotiates version 1.3 with the controller..

The monitor Tab shows the difference and the FLOWS tab shows "Table 0" rather than "N/A", that can be seen on switch 2 running on Openflow version.

Hosts can be seen after generating traffic (I just pressed the reload button on the Topology tab).

 

If I then modify the flow according to the controller schema I can add it to my datapath without issues (using the REST interface).

Format I used:

 

{

"flow":{

"priority":30000,

"table_id":202,

"idle_timeout":60,

"match":[

{

"ipv4_src":"10.0.0.1"

},

{

"ipv4_dst":"10.0.0.15"

},

{

"ip_proto":"tcp"

},

{

"eth_type":"ipv4"

},

{

"tcp_dst":"80"

}

],

"instructions":[

{

"apply_actions":[

{

"output":3

}

]

}

]

}

}

 

 

You can access the json schema at the url https://<controller_IP>:8443/sdn/v2.0/models

 

I attached to my message screenshots gathered.

Prior to execute the script make sure to clean mininet (mn -c).

 

Let me know how what you did differs from what I tried to describe above.

 

Regards,

 

Antonio

SDN Team

 

 

 

This still does not work. As I stated above with the switch 5 flow topology .docx file,  the flow goes to the switch fine, and all looks good in the OpenFlow Monitor for that switchs flows, as you have shown in the docx file, the exit int should be 6 in the Flow Table on S1 in my document seen below, the field is empty.  Everything but the exit interface goes in here. This means the flow goes no where. It may as well be dropped. Also when logging into the controller the ssl certificates are giving problem to the browser logging in, saying they are not secure. Newer browsers will not give an option to bypass this and you can't login.

Hi,

 

Concerning the ssl certificates issue ,please follow the instructions you will find on last entry of this other post:

 

http://h30499.www3.hp.com/t5/SDN-Development/Issue-installing-latest-VAN-possible-postgreSQL-error/m-p/6733459#M611

 

 

In both files you provided there is no match on the flow you added (0 packets and 0 bytes matching the flow).

Since no packet is matching the flow you added, the traffic will be forwarded by the standart routing and switching rule.

This means that it will reach port 80 og 10.0.0.6.

 

I added a flow matching ICMP between the 2 same hosts and I can see counter increasing (add the flow to table 0 in order to have matching packets).

 

Also my action is "output controller" and I can see packets sent from 10.0.0.1 to 10.0.0.6 being received by the controller (using tshark).Thus the defined action is applied to matching packets.

 

If the above does not solve please let me know what are you expecting to see and why what you see seems wrong.

 

Regards,

 

Antonio

 

 

 

 

 

#ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Ok. I don't mean to be annoying you with this. I am still learning, but I ran the bash script for switch 1. The same script as my very first message, except the exit interface is output 6. This would output http traffic to switch 5 eth1. So I ran Wireshark on Switch 5 eth1 looking for traffic from port 80 and created a server, client connection from h1 to host 15 using iperf, then I sent traffic using port 80 from h1 to h15. The testing I did worked as suspected with OF 1.0, but not with OF 1.3. The attached file shows my results. I would have suspected that no http packets should be going through Switch 6 only acknowledgements, like what happened with Openflow 1.0 with the same scenario. 

Hi,
Can you please send a screenshot of the flow table of the switch?
if you see packets on port 6, it means that the flow is not matching packets.checking the flow table will help.
if in the details of the datapath the matching packets number does not increase, most likely the issue is concerning the table You are adding the flow to
e.g.
if the table is 202 (as from previous examples) you should have on table 0 or on table 100 a flow with instruction "go to" table 202. Without this flow no packet will ever reach table 202
I suspect that adding your flow on table 0 is the solution to this issue.

Regards,
Antonio

That seems to have worked. Thank you for your help. Just one more question. With OpenFlow 1.3, multiple tables can be used on the same switch. To do this do I just add another table number 1 to the list or does the new flow go on table 0 as well? I had read that table 200 were software and table 100 is hardware. Why does this flow go in at table 0?