Operating System: All
Platform: All

Flow with arbitrary mask works in stable/beryllium but not master

Input in config -> http://pastebin.com/Tq6finM5

Output in operational -> http://pastebin.com/vqpnea8v

mininet output

mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=321.38s, table=0, n_packets=0, n_bytes=0, priority=40,ip,nw_src=40.40.40.0,nw_dst=40.0.40.0/255.0.255.0 actions=dec_ttl

All the above mentioned flows works in stable/beryllium as expected

I just tested it now with the current code on master branch.

Hi Andrej,

I've tested this with master branch builds as early as distribution-karaf-0.5.0-20160727.205650-3885.tar.gz

I noticed that the flows in the config datastore that Sai provided resulted in OFPBMC_BAD_WILDCARDS errors on a version 2.5.0 OVS Switch. After modifying the flow (see below*), I was able to get the flow installed on the switch and confirm that the operational flow ID indeed matched the config datastore flow ID. So, I could not reproduce this bug as Sai was seeing. Were you able to reproduce it?

• this would be a successful arbitrary bitmask config:
  <ipv4-source-address-no-mask>40.40.40.0</ipv4-source-address-no-mask>
  <ipv4-destination-address-no-mask>40.0.40.0</ipv4-destination-address-no-mask>
  <ipv4-destination-arbitrary-bitmask>255.0.255.0</ipv4-destination-arbitrary-bitmask>
  <ipv4-source-arbitrary-bitmask>255.255.255.255</ipv4-source-arbitrary-bitmask>

Hi Andrej / Bertrand,

I re-tested with latest master (which includes Anil's Patch)

Seems Ipv4 arbitrary bit mask is ok, but some cases of Ipv6 arbitrary bit mask doesn't work.

Please check the flow Id s 440,441,447 in config, there are not correctly reflected in operational.
Where as Flow Id 473 is correctly represented.
In case of stable/beryllium these work as expected. i.e., they show up in operational.

config :- http://pastebin.com/raw/DaKk89H7

operational :- http://pastebin.com/raw/UXZC0iMp

Hence the bug still exists. Please let me know any clarification.

Following flow in Ipv4 doesn't work

Config :-http://pastebin.com/6xce2rgU

operational :- http://pastebin.com/uXCYB8BE

Hi guys,
(didn't send details yesterday)
The issue with incorrect flow id (i.e. alien id) is similar to OPNFLWPLUG-722 and there are some improvements after https://git.opendaylight.org/gerrit/#/c/42510/.

I also tested it with your first configuration Sai and for OVS 2.3.0 all flows are pushed to device and they show up in operational with correct flow id. (However if you would like to setup these flows in OVS 2.4.0 or 2.5.0 - as Bertrand mentioned, device will return error cause of incorrect masks. Newer versions are more clever.)

But it seems that problem is if *address-no-mask + *arbitrary-bitmask fileds are used. Will try to check it.

The problem was really with *address-no-mask + *arbitrary-bitmask fields not comparing properly with ipv4/6-source from device. I created patch that will fix this problem here: https://git.opendaylight.org/gerrit/#/c/43233/

Sai, could you please test it, it should work now.
(if u r using OVS 2.4.0+ you need to edit address or mask in the last config u sent again, otherwise device will probably reject the flow)

Hi Andrej / Tomas,

With ovs version 2.3 following flows fail to show up in operational.

http://pastebin.com/8CYJt4Vx

This was not issue related to alien id actually, but fixed here:

master: https://git.opendaylight.org/gerrit/#/c/43641/
boron: https://git.opendaylight.org/gerrit/#/c/43643/
beryllium: https://git.opendaylight.org/gerrit/#/c/43647/

Thank you Andrej.
Once the above three patches are merged, this bug can be closed.

Guys, everything is fine and I am going to merge it. Just wonder why this errors weren't catch by JUNIT test. Please add/upgrade test to prevent further mistakes.

With Andrej, we additionally replaced regexp, that was converting IPv6 adress to its short notation to proper byte array related method, because that regex was not shortening the longest groups of zeros, as it should.

Also, Andrej tested it on OVS 2.3 and 2.4, and everything was working as it was supposed to (on 2.3, everything passed, and on 2.4, when there was bad wildcard, it was properly rejected).

Patches are merged already, if its ok please close this bug.

Jozef