I am trying to use ODL Beryllium with an HP Procurve 6600 24 GL switch.

Configuration:

My ODL is the tarball available for downloading from ODL website.

Currently I have my HP switch divided into 2 OF-related VLANs, one is used for interfacing with the controller and the other is incorporated with an OpenFlow instance.

The VLAN with ODL instance consists of 3 hosts connected to it. The hosts are pinging each other before switching on the OpenFlow setup.

I am trying to run OpenFlow version 1.3 and therefore I have also launched my ODL karaf with the option -of13. I have configured my OF instance on the switch with the version 1.3 as well.

In my ODL, I have installed only two features, odl-l2switch-all and odl-dlux-all.

Result:

As a result, three flows are added, one is default in table 0 which just forwards everything to table 100, and then there is one in table 100 that drops everything and then there is one in table 200 that does the same. And therefore ping does not work.

Remedy:

So, I changed the files that say that ODL should add everything to table 0 in the folder <distribution>/etc/opendaylight/karaf/ and instructed it to add whatever flows it wants to to the table 100. These files are 52-loopremover, 54-arphandler and 58-l2switchmain. But still the response is same.

Detailed Analysis:

By checking the packets in wireshark, it turns out that the FLOWMOD packet is getting back an ERROR packet, which means the controller is failing to push the configuration to the switch. The error type is OFPETBADMATCH (4) and its code is OFPBMCBAD_FIELD (6). The log file for ODL also logs some warnings, as shown in the log at the end.

Anyone has any idea how to get about it. I have used a lot of time to try different things, search the web and so on but to no avail. Some help will be appreciated.

PS;
Using OpenFlow 1.0 instead:

Worth mentioning is that by using OpenFlow 1.0, although the flows are added successfully and link can be seen in Dlux web interface as well, it still does not allow the hosts to ping each other. When checked the switch, there are 17 flows out of which one looks like this:

2 answers

As you mentioned that the 3 flows that are added in the switch might be default flows, I agree with this idea. Because looking at the wireshark dumps, it shows that no FLOW_MOD message went through to the forwarding tables, all of them triggered error. So this is established.

Digging a bit into the error message that I receive, this is what OF 1.3 specs have to say about it,

If the match in a flow mod message specifies a field that is unsupported in the table, the switch must return an ofperrormsg with OFPETBADMATCH type and OFPBMCBADFIELD code.

Searching a bit more in the HP documentation, it shows that for OF1.3, the field ETH_TYPE must be wildcarded for HP Procurve switches to add it as a hardware flow.

This lead to the second solution, I changed the table-id in the above-mentioned configuration files to table 200 in order to make the controller to send all the FLOW_MOD messages to a software table. But then there is no way the flow in table 100 is forwarding the packets to tale 200. Still, there are flows added to table 200 by odl controller and there is no error message. Life looks okay.

The last part of the solution, therefore, is to add a manual flow in table 100. Which I have done and it sends all the packets to table 200. By doing so, I managed to get the links among all of my switches. One problem solved.

But now, all the hosts that are connected to these switches are not pinging each other if they belong to different subnets. Then I changed all the hosts to the same subnet and now they are pinging each other as well.

So, adding a hard flow in table 100 to direct everything to table 200, changing the config files in /distribution/etc/opendaylight/karaf to add all flows in table 200, and making sure that all hosts are in the same subnet solves this issue.

Thanx for all the supervision Jamo, now the issue is solved, I had one wandering packet that actually chocked everything, so I removed it by physically disconnecting the cables. Also, I was trying to have a network with diff subnets, maybe l2switch feature doesn't do that.

I don't know the final solution here, but some comments anyway in case they help.

In your Result section above you mentioned the three flows table 0 -> table 100 (drop); table 200 (drop). I think those
might be default from your procurve switch, and not coming from ODL. Either way, telling l2switch to use table 100
seems like the right thing to do.

There may be some bug though, if the switch is rejecting the flow mod with "OFPETBADMATCH (4) and its code is OFPBMCBAD_FIELD (6)." Can you dig a little more on that issue and see if you can determine what the bad
match or bad field is? You can also send that kind of question (with details) to the openflowplugin-dev@lists.opendaylight... mailing list.

when using OF1.0, that first rule you see with ethertype 0x88cc is the rule that tells the switches to send all LLDP
(link discovery) packets to ODL. that's how it learns the links and is able to paint them in the GUI/DLUX. Unfortunately
I cannot see the other rules you pasted. There is a link to see (more), but it's not showing me anything.