Ask is moving to Stack Overflow and! Please use the "opendaylight" tag on either of these sites. This site is now in Read-Only mode

mario's profile - activity

2015-04-08 06:30:35 -0700 received badge  Famous Question (source)
2014-10-26 17:12:44 -0700 received badge  Famous Question (source)
2014-10-02 03:55:27 -0700 received badge  Notable Question (source)
2014-10-02 03:55:27 -0700 received badge  Famous Question (source)
2014-09-22 21:45:09 -0700 received badge  Popular Question (source)
2014-09-18 09:13:21 -0700 asked a question Forwarding Rules Manager (FRM) does not create a FLOW-MOD message. [Update]

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SAL_App_Tutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has anybody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

+++ UPDATE: +++

I found out that the flow-mod messages will be sent successfully under certain circumstances:

If the switch gets disconnected from the controller after a flow should have been installed and reconnected again, then Opendaylight actually pushes the flow to the switch.

This means that the entry in the data store is perfectly fine, but the creation of the flow-mod message is just not triggered.

Can anyone confirm this issue?

Whom should I address in a bug report, MD-SAL, the Forwarding Rules Manager or maybe the Openflow plugin? I'm just not sure which component misses/looses the initial flow-establishment event.



2014-09-16 04:49:29 -0700 received badge  Enthusiast
2014-09-12 04:11:16 -0700 received badge  Notable Question (source)
2014-09-10 00:24:48 -0700 answered a question OpenFlow 1.3 support in Open Daylight
2014-09-07 21:12:49 -0700 received badge  Notable Question (source)
2014-08-28 00:22:40 -0700 answered a question I am unable to see all the devices i added. how to see them?

Have you already tried to ping the hosts from each other, so that ODL can see there is traffic going on?

2014-08-27 01:05:44 -0700 received badge  Popular Question (source)
2014-08-27 00:27:01 -0700 commented answer Installation of flows fails on HP Switch with OF1.3

Well, I'm not sure whose fault it is if ODL always tries to install rules in table 0 and HP expects the rules to be written into table 100. Does the Openflow specification says anything about that? EDIT: Oh, you meant the packet-out message! Sorry. I will have a look about that.

2014-08-26 06:22:03 -0700 commented answer Installation of flows fails on HP Switch with OF1.3

Thank you for your help. Please see the update I appended to my question. However, this makes me uncertain whether to file the bug against openflowjava or the web interface..

2014-08-26 06:20:20 -0700 received badge  Editor (source)
2014-08-25 08:45:21 -0700 asked a question Installation of flows fails on HP Switch with OF1.3

Hi there,

I'm having some trouble using Opendaylight with an HP 8206zl switch over Openflow version 1.3.

I've configured the switch to use OF1.3 and started Opendaylight with "opendaylight-base-0.1.1$ ./ -of13"

The switch is detected as "MD_SAL|openflow:774679839286528" but it won't accept any flows. With both, the simpleforwarder and the Web-UI (Flows > Add flow entry) it's not possible to install any flows.

The corresponding error message of the switch for "Add flow entry" (with the Web-UI) should be:

0040:23:23:01.92 OPFL eOFNetTask:RX from tcp: 0: OFPT_FLOW_MOD
   (OF 0x04) (xid=0x4db):

0040:23:23:01.92 OPFL eOFNetTask:TX to tcp: 0 : OFPT_ERROR (OF
   0x04) (xid=0x4db): OFPFMFC_EPERM
(***truncated to 64 bytes from
00000000  04 0e 00 58 00 00 04 db-00 00 00 00 00 00 00 00

Also, the switch shows periodic error messages like this:

0040:23:30:08.26 OPFL eOFNetTask:Instance:TestInstance, Failed to send Packet_Out:LOCAL
0040:23:30:13.26 OPFL eOFNetTask:RX from tcp: 0: OFPT_PACKET_OUT
   (OF 0x04) (xid=0x720): ***decode error: OFPBRC_BAD_LEN***

Any ideas what's wrong? Is is the switch or Opendaylight that's causing trouble; or is it just me, using it wrong? ;-)

Has somebody been able to use Opendaylight with an HP switch over Openflow version 1.3?

Thanks for any help. Mario

p.s. With Openflow version 1.0, Opendaylight and the switch play well together.


I've done some experimenting and, at least for flow programming, I narrowed down the problem:

The HP switch expects flow rules to be put in table 100. But the web interface seems to be limited to table 0. Using the REST interface I was able to create some flows manually.

However, this does not explain the periodic OFPT-PACKET-OUT errors.

2014-08-19 00:31:07 -0700 received badge  Popular Question (source)
2014-07-30 05:10:51 -0700 received badge  Scholar (source)
2014-07-30 05:10:36 -0700 commented answer Should I develop an "app" as OSGi-plugin or use the REST-API?

Thank you very much, that helped a lot. :-)

2014-07-30 01:15:55 -0700 asked a question Should I develop an "app" as OSGi-plugin or use the REST-API?


I'm trying to get started with "app"-development for Opendaylight, but I have some trouble figuring out whether/in which cases to develop the app as an OSGi-plugin or to use the REST-API. I assume there definitely is an performance impact related to the REST-API.

In addition, I got the impression that MD-SAL is only available with the REST-API, is that correct?

Speaking of which, I'm confused with AD-SAL and MD-SAL.. Since MD-SAL is newer, I wonder if AD-SAL is deprecated. Or are these just two complementary concepts, with different pros and cons? In the latter case, what are the pros and cons, from an app-developer point of view?

As a last question I would like to clarify terminology. As an app-developer, in the context of Opendaylight, am I a "user", a "developer", something in between? Since there are resources for users and developers in the Opdendaylight wiki, but neither seems to really fit for app-developers.

Best regards, Mario