Custom OpenFlow via OpenDaylight has no effect

Question

I have two VM in an OpenStack cloud. Using the following command, I can send data between them:

# On the server (IP 10.0.0.7)    
nc -u -l -p 7865

# On the client (10.0.0.10)
nc -u 10.0.0.7 7865

Now, I would like to block the communication from 10.0.0.10 to 10.0.0.7 (but still allow it in the other direction). So I create this flow:

root@ubuntu:/opt/stack/opendaylight# cat my_custom_flow.xml 
<?xml version="1.0"?>
<flow xmlns="urn:opendaylight:flow:inventory">
  <priority>1</priority>
  <flow-name>nakrule-custom-flow</flow-name>
  <idle-timeout>12000</idle-timeout>
  <match>
    <ethernet-match>
      <ethernet-type>
        <type>2048</type>
      </ethernet-type>
    </ethernet-match>
    <ipv4-source>10.0.0.10/32</ipv4-source>
    <ipv4-destination>10.0.0.7/32</ipv4-destination>
    <ip-match>
      <ip-dscp>28</ip-dscp>
    </ip-match>
  </match>
  <id>10</id>
  <table_id>0</table_id>
  <instructions>
    <instruction>
      <order>6555</order>
    </instruction>
    <instruction>
      <order>0</order>
      <apply-actions>
        <action>
          <order>0</order>
          <drop-action/>
        </action>
      </apply-actions>
    </instruction>
  </instructions>
</flow>

Then, I send the flow to my switch. I use OpenDaylight as my SDN controller to manage my OpenStack cloud. I have two switchs, br-int and br-ex. A port for each VM in OpenStack is created on br-int. I can get the switchs ID with the following command:

curl -u admin:admin http://192.168.100.100:8181/restconf/config/opendaylight-inventory:nodes | python -m json.tool | grep '"id": "openflow:'[0-9]*'"' 

"id": "openflow:2025202531975591"
"id": "openflow:202520253197559"

The switch with the ID 202520253197559 has a lot of flows in his table, while the other has like 2-3. So I guess 202520253197559 is br-int and therefore add my new flow to it with the following command:

curl -u admin:admin -H 'Content-Type: application/yang.data+xml' -X PUT -d @my_custom_flow.xml http://192.168.100.100:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:202520253197559/table/234/flow/10

Now, I can see my flow with another REST request:

curl -u admin:admin http://192.168.100.100:8181/restconf/config/opendaylight-inventory:nodes | python -m json.tool

{
    "flow-name": "nakrule-custom-flow",
    "id": "10",
    "idle-timeout": 12000,
    "instructions": {
        "instruction": [
            {
                "order": 6555
            },
            {
                "apply-actions": {
                    "action": [
                        {
                            "drop-action": {},
                            "order": 0
                        }
                    ]
                },
                "order": 0
            }
        ]
    },
    "match": {
        "ethernet-match": {
            "ethernet-type": {
                "type": 2048
            }
        },
        "ip-match": {
            "ip-dscp": 28
        },
        "ipv4-destination": "10.0.0.7/32",
        "ipv4-source": "10.0.0.10/32"
    },
    "priority": 1,
    "table_id": 0
},

However, then I go back to my two VM, they still can send data successfully to each other. Moreover, using the following command return nothing:

ovs-ofctl dump-flows br-int --protocols=OpenFlow13 | grep nakrule

I should see my new flow, does that mean OpenDaylight does not add it to my switch ?

root@ubuntu:/opt/stack# ovs-ofctl snoop br-int
2018-05-11T09:15:27Z|00001|vconn|ERR|unix:/var/run/openvswitch/br-int.snoop: received OpenFlow version 0x04 != expected 01
2018-05-11T09:15:27Z|00002|vconn|ERR|unix:/var/run/openvswitch/br-int.snoop: received OpenFlow version 0x04 != expected 01

Thank you in advance.

jamo jamo · Accepted Answer · 2018-05-11T17:26:32

are you sure openflow:1 is the node id of the switch (br-int) that you want to program. I am doubting that. Usually openflow:1 is something we see from a mininet deployment.

do a GET on the topology API via RESTCONF and figure out the node id of your switch(es). Or you can probably guess it by finding the mac address of the br-int you are using and converting the HEX to decimal.

For example, mininet actually makes their mac addresses simple, like 00:00:00:00:00:01, so that's why it ends up openflow:1

another problem I notice in your updated question is that you are sending the flow for table 234 in the URL, but specifying table 0 in the flow data.

Also, you can check the config/ store in restconf for those nodes to see if ODL is even accepting the flow. If it's in the config store and that switch is connected to the openflow plugin, then the flow should be pushed down to the switch.

another place to look for clues, is the karaf.log.

finally, if you think everything is right and the flow should be getting sent down to the switch, but the switch is not showing the flow, then try doing a packet capture. It's possible that your switch is rejecting the flow for some reason. That might also be shown in the ovs logs, if that's the case. I doubt this is what the problem is, but just adding it in case.

Custom OpenFlow via OpenDaylight has no effect

1 Answers