通过OpenDaylight配置的自定义OpenFlow规则未生效问题咨询

Let's work through the problems you're hitting with your OpenDaylight flow rule step by step—there are a few key issues that are preventing your block from working:

1. Your flow rule is matching a DSCP value that your nc traffic doesn't use #

You added an <ip-dscp>28</ip-dscp> condition to your match, but the UDP packets sent by nc -u don't have this DSCP marking by default. That means your drop rule will never trigger for the traffic you care about.

Fix: Remove the entire <ip-match> block from your flow XML. If you want to make the rule even more precise (only blocking the specific nc UDP port), add a UDP match too. Here's the corrected match section:

<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>
  <!-- Optional: Block only the specific nc UDP port -->
  <udp-match>
    <destination-port>7865</destination-port>
  </udp-match>
</match>

2. You're targeting the wrong table in your REST command #

Your flow XML specifies <table_id>0</table_id>, but your curl command is sending it to table/234. This mismatch means OpenDaylight either rejects the rule or puts it in a table that doesn't handle your VM traffic.

Fix: Update your curl command to use table 0 (the main forwarding table in OpenStack+ODL setups):

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/0/flow/10

Keep the <table_id>0</table_id> line in your XML unchanged.

3. Your rule's priority is too low to override default rules #

You set <priority>1</priority>, but most default rules from OpenStack and ODL use higher priorities (usually starting at 100 or more). That means the default allow rules will catch your traffic before your drop rule does.

Fix: Boost the priority to something higher than the defaults, like <priority>1000</priority>.

4. Your ovs-ofctl commands are using the wrong OpenFlow version #

The error from ovs-ofctl snoop is because you're using OpenFlow 1.0 by default, but your switch is running OpenFlow 1.3 (0x04 is the code for OF1.3).

Fix: Specify the protocol version when running ovs-ofctl commands:

• To check for your flow rule:

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

• To snoop traffic properly:

  ovs-ofctl snoop br-int --protocols=OpenFlow13
  

5. Final steps to test #

After fixing all the above, re-send your corrected flow rule with the updated curl command. Then use the corrected dump-flows command to confirm the rule is present on br-int.

Once that's done, test your nc traffic again:

• On 10.0.0.7: nc -u -l -p 7865
• On 10.0.0.10: nc -u 10.0.0.7 7865

The client (10.0.0.10) should no longer be able to send data to the server, but the server should still be able to send data back to the client (since you didn't block reverse traffic).

内容的提问来源于stack exchange，提问作者Nakrule