Ask Your Question
0

Using ODL Beryllium with HP Procurve 6600 switch

asked 2016-09-05 08:40:18 -0700

chilwan gravatar image

Hei ODL community,

Objective:

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

Configuration:

  1. My ODL is the tarball available for downloading from ODL website.
  2. 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.
  3. The VLAN with ODL instance consists of 3 hosts connected to it. The hosts are pinging each other before switching on the OpenFlow setup.
  4. 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.
  5. 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:

Flow 2 Match Incoming Port : Any Ethernet Type : 0x88cc Source MAC : Any Destination MAC : Any Destination MAC Mask : 000000-000000 VLAN ID : Any VLAN Priority : Any Source IP Address : Any Destination IP Address : Any IP Protocol : Any IP ToS Bits : Any Source Port : Any Destination Port : Any Attributes Priority : 100 Duration : 60 seconds Hard Timeout : 0 seconds Idle Timeout : 0 seconds Byte Count : 683095 Packet Count : 5839 Controller ID : 1 Cookie : 0x2b00000000000000 Flow Location : Software Hardware Index: NA Reason Code : 3 Reason Description : The rule has a match criterion for non-IP Ether type Actions
Controller Port

and all the other look like this:

Flow 3 Match Incoming Port ... (more)

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted
0

answered 2016-09-13 08:14:48 -0700

chilwan gravatar image

updated 2016-10-04 01:32:17 -0700

Hei Jamo,

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.

edit flag offensive delete publish link more

Comments

great debugging, btw. I wonder if you might not have all the right knobs turned to table 200 for the l2switch app. here is their Be user guide: https://wiki.opendaylight.org/view/L2_Switch:Beryllium:User_Guide you can do a pkt cap on your hosts. I bet they are sending arp packets but no response

jamoluhrsen ( 2016-09-13 14:09:58 -0700 )edit

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.

chilwan ( 2016-10-04 01:34:17 -0700 )edit

glad it worked out for you. sounds like you had a packet storm of some sort. I think the l2switch project is not totally reliable so take care when using it. BTW, Boron is out now. give it a try :)

jamoluhrsen ( 2016-10-07 21:25:33 -0700 )edit

have downloaded it already, lets see how does it play out.

chilwan ( 2016-10-11 00:44:11 -0700 )edit
0

answered 2016-09-07 15:43:27 -0700

jamoluhrsen gravatar image

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.

edit flag offensive delete publish link more

Comments

Thanks Jamo for your input. Please read my answer below for details on the ideas that you have given. We might find a way out here. :)

chilwan ( 2016-09-13 06:35:59 -0700 )edit

Managed somehow to let controller add flows to the switches, but now the controller is not adding flows required for pinging a host from another host. Any solution?

chilwan ( 2016-09-13 08:15:46 -0700 )edit
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2016-09-05 08:40:18 -0700

Seen: 186 times

Last updated: Oct 04 '16