Ask Your Question

Problem crossing from config to operational API

asked 2015-07-02 00:39:05 -0700

Edu gravatar image

I have the problem that the when I install a flow in the /restconf/conf API it is installed well, but the controller doesn't translate the flow to the /restconf/operational API so the flow is not visible for my ovs. I have try it with the flow proposed by the end-to-end-flow wiki page and also by flows created by me. I give you some details to see if are you able to help me:


      <hardware>Open vSwitch</hardware>
      <manufacturer>Nicira, Inc.</manufacturer>

I install the next flow: PUT: http://localhost:8181/restconf/operational/opendaylight-inventory:nodes/

  "nodes": {
    "node": [
        "id": "openflow:1",
        "flow-node-inventory:table": [
            "id": 0,
            "flow": [
                "id": "1",
                "instructions": {
                  "instruction": [
                      "order": 0,
                      "apply-actions": {
                        "action": [
                            "order": 0,
                            "output-action": {
                              "output-node-connector": "2"
                "flow-name": "Edu",
                "match": {
                  "in-port": "1"
                "strict": false,
                "table_id": 0,
                "priority": 999

Response Code 200 The flow is in the conf API:



but not in the operational API:

<table><id>0</id><flow-hash-id-map><hash>Match [augmentation=[]]03098476543630901248</hash><flow-id>#UF$TABLE*0-7</flow-id></flow-hash-id-map><flow-hash-id-map><hash>Match [_inPort=Uri [_value=openflow:1:1], augmentation=[]]23098476543630901249</hash><flow-id>#UF$TABLE*0-4</flow-id></flow-hash-id-map><flow-hash-id-map><hash>Match [_ethernetMatch=EthernetMatch [_ethernetType=EthernetType [_type=EtherType [_value=35020], augmentation=[]], augmentation=[]], augmentation=[]]1003098476543630901248</hash><flow-id>#UF$TABLE*0-6</flow-id></flow-hash-id-map><flow-hash-id-map><hash>Match [_inPort=Uri [_value=openflow:1:2], augmentation=[]]23098476543630901248</hash><flow-id>#UF$TABLE*0-5</flow-id></flow-hash-id-map><flow-hash-id-map><hash>Match [_inPort=Uri [_value=openflow:1:3], augmentation=[]]23098476543630901250</hash><flow-id>#UF$TABLE*0-3</flow-id></flow-hash-id-map><aggregate-flow-statistics><flow-count>5</flow-count><byte-count>0</byte-count><packet-count>0</packet-count></aggregate-flow-statistics><flow-table-statistics><packets-looked-up>53</packets-looked-up><active-flows>5</active-flows><packets-matched>24</packets-matched></flow-table-statistics><flow><id>#UF$TABLE*0-5</id><instructions><instruction><order>0</order><apply-actions><action><order>1</order><output-action><output-node-connector>3</output-node-connector><max-length>65535</max-length></output-action></action><action><order>2</order><output-action><output-node-connector>CONTROLLER</output-node-connector><max-length>65535</max-length></output-action></action><action><order>0</order><output-action><output-node-connector>1</output-node-connector><max-length>65535</max-length></output-action></action></apply-actions></instruction></instructions><hard-timeout>0</hard-timeout><match><in-port>openflow:1:2</in-port></match><idle-timeout>0</idle-timeout><table_id>0</table_id><flow-statistics><byte-count>0</byte-count><duration><second>40</second><nanosecond>891000000</nanosecond></duration><packet-count>0</packet-count></flow-statistics><priority>2</priority><cookie>3098476543630901248</cookie><flags/></flow><flow><id>#UF$TABLE*0-6</id><instructions><instruction><order>0</order><apply-actions><action><order>0</order><output-action><output-node-connector>CONTROLLER</output-node-connector><max-length ...
edit retag flag offensive close merge delete


We reached the same conclusion about this issue. As you said programmed flows are not corring from config to operational datastore. I've been with this issue for a week more or less and I still with no solution. May be we're missing something in the configuration of ODL but I don't think so.

Wayko ( 2015-07-02 06:20:50 -0700 )edit

Me too I'm working some days with this issue. Let's share any progress that we make! Edu

Edu ( 2015-07-02 07:20:08 -0700 )edit

Facing same issue from last one week, but no solution found any where... Please share if any one has any solution. Same flow is working without any issue if I use different controller which internally uses Openflow lib extracted from ODL.

Mandeep ( 2015-07-30 01:51:07 -0700 )edit

4 answers

Sort by ยป oldest newest most voted

answered 2015-07-02 10:21:20 -0700

If your flow isn't copied over to operational, then ODL wasn't able to push it to the switch successfully.

edit flag offensive delete publish link more

answered 2015-08-11 22:50:30 -0700

Hongjun_Ni gravatar image

Facing the same issue with you, and have not had any solution yet. But I'll share some points that I have found with you.

  1. The different flows with strange names you saw is the default flows installed in ovs. [root@localhost ovs]# ovs-ofctl dump-flows br0 NXSTFLOW reply (xid=0x4): cookie=0x2b00000000000000, duration=11369.929s, table=0, npackets=0, nbytes=0, idleage=13423, priority=100,dltype=0x88cc actions=CONTROLLER:65535 cookie=0x2b00000000000001, duration=11369.927s, table=0, npackets=0, nbytes=0, idleage=13423, priority=0 actions=drop

  2. I tried to capture flowmod messages between ODL and OVS, but I could not got any flowmod messages. It seems that the ODL did not send flow_mod message to OVS yet.

Thanks, Hongjun

edit flag offensive delete publish link more


Hi Hongjun....As you said I am getting the same default flows with strange names. How could I delete them through REST API ?? And I am using OPenflow13(HELIUM release).When I add switches and hosts from mininet and see ovs-ofctl dump-flows s1,I could see these strange flows. And when I tried pinging h1 and h2 ,it straight away starts pinging. After this dump-flows show h1 and h2 flows too.... Could you help me in removing these flows. Thanks in advance

Sasivenkat ( 2015-08-25 22:32:36 -0700 )edit

answered 2015-08-13 00:31:07 -0700

Mandeep gravatar image

I figured out problem in my case...

As suggested by grmontpetit.

I was not using OVS, instead I was using our real switches and after debugging, found that our switches were not supporting all actions hence ODL request was rejected.

Note: Some switches does not accept empty flow. Our switch rejects empty flow which is considered as default with lowest priority.

edit flag offensive delete publish link more


Do you mean that your switch receives the flowmod message, but rejects it?

Hongjun_Ni ( 2015-08-13 00:38:04 -0700 )edit

Yes... From wireshark I could see flow_mod was sent.. even switch log was clearly receiving and rejecting.

Mandeep ( 2015-08-13 01:39:42 -0700 )edit

Hi Mandeep, Thanks a lot.

Hongjun_Ni ( 2015-08-13 05:06:42 -0700 )edit

answered 2015-08-24 04:32:13 -0700

Michal gravatar image

Same issue here. I'm using OVS-2.3.1, according to logs seems like OVS rejects FLOW_MOD requests being made by ODL. but "ovs-ofctl show br0" returns the following caps -


Meaning that OVS supports actions.

according to OVS logs - 2015-08-24T08:28:13.745Z|02703|connmgr|INFO|br0<->tcp: 2 flowmods 10 s ago (2 adds) 2015-08-24T09:35:13.475Z|02704|pktbuf|WARN|attempt to reuse buffer 00000000 2015-08-24T09:35:13.475Z|02705|connmgr|INFO|br0<->tcp: sending OFPBRCBUFFEREMPTY error reply to OFPTFLOW_MOD message

I think that this is the issue - ODL tries to use buffer 0.

is there anyway to change it? to make ODL use a different buffer?



edit flag offensive delete publish link more
Login/Signup to Answer

Question Tools



Asked: 2015-07-02 00:39:05 -0700

Seen: 722 times

Last updated: Aug 24 '15