Custom OpenFlow via OpenDaylight has no effect - opendaylight

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.

Answer 1

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.