XML for flow to PUT:
<flow xmlns="urn:opendaylight:flow:inventory"><instructions><instruction><order>0</order><apply-actions><action><order>0</order><output-action><output-node-connector>FLOOD</output-node-connector></output-action></action></apply-actions></instruction></instructions><match><ethernet-match><ethernet-type><type>0x800</type></ethernet-type><ethernet-source><address>00:ab:cd:ef:01:23</address></ethernet-source><ethernet-destination><address>ff:ff:ff:ff:ff:ff</address></ethernet-destination></ethernet-match><ipv4-source>11.3.0.0/16</ipv4-source><ipv4-destination>99.0.0.0/8</ipv4-destination></match><table_id>200</table_id><id>1</id></flow>
This is the ONE TC failure we see in the OpenFlow system test.
I am not able to reproduce this bug. First I tried to install the flow with dst_ip 99.0.0.0/8 then with 98.0.0.0/8 and the flow ID does not change.
Please let me know if I am missing ant step for reproducing the bug.
Hi Subhash, a few checkings here:
1) Are you using helium plugin (odl-openflowplugin-flow-services-* feature) for this test?
2) Are you adding the 2nd flow without deleting the 1st?
I am sking because this issue is still very apparent in the test automation.
BR/Luis
Hi Luis,
1) Are you using helium plugin (odl-openflowplugin-flow-services-* feature) for this test?
I used the feature odl-openflowplugin-flow-services (version: 0.1.0-SNAPSHOT repo: openflowplugin-0.1.0-SNAPSHOT). Should I use odl-openflowpluging-li ?
2) Are you adding the 2nd flow without deleting the 1st?
Yes, I am adding the 2nd flow without deleting the 1st.
I was checking in on this bug and am using this build:
distribution-karaf-0.3.0-20150526.214206-1847.zip
I tried with both plugin codebases' features:
odl-openflowplugin-flow-services-ui
odl-openflowplugin-flow-services-ui-li
At this point I was seeing this unknown value in the flow id inside operational
on the first push. did not require me to modify the flow.
I already answered in the list, this issue is bigger than we thought as flow ID is always unknown in Lithium distribution.
I tested in Lithium and found out (thank to Michal Rehak), that if input contains MAC addresses in upper case. Then it is all right.
The mail was sent to Anton Tkacik (should be able to fix it - probably wrong equals method implemenation in lazy generated code).
If I remember correctly the flows we push in integration are L3, they only match IP address.
Response from Anton Tkacik regarding suspicion on problem in equal() method
===================
https://bugs.opendaylight.org/show_bug.cgi?id=2825
will not be fixed in Lithium – since YANG does not provide information that mac-addresses should
Be stored in lower-case and should be compared camel-case agnostic.
That was hugelly discussed few weeks ago with OF community.
Will be probably fixed in Berrylium.
===================
Elevated to blocker in OpenFlow plugin meeting. Anil will look into this for the old design. On the new design this still needs to be looked at by Jozef 
.
My conclusion:
in both plugins it is currently necessary to record flows with MAC address uppercased. As Anton Tkacik responded this comparison problem (lower vs. upper case) would be probably fixed in Berrylium
- in Li plugin - there shouldn't be any other problem
- in He plugin - there was also other problem which should be solved with patch - https://git.opendaylight.org/gerrit/#/c/21624/
It looks like in Li plugin is problem with aliens still present. Investigating.
I do not see this issue with Lithium redesign code.
ok, so if you are using upper case for MAC address it works fine (Li plugin)
Just to be clear this issue is nothing to do with data format. This issue is ANY flow pushed using Helium code generates alien flow-ID. This behavior is only observed with Helium code.
just to be more concrete, I have tested this with a single flow config (not an update to an
existing flow) flow XML is below and it does not have any MAC address in there to confuse
the upper vs lower case issue.
for helium SR3 the flow id is fine. For both helium codebase and lithium redesign codebase,
I get alien ids. I'm installing odl-openflowplugin-flow-services-ui for helium codebase
and odl-openflowplugin-flow-services-ui-li for lithium code base.
using mininet with a single switch topo.
here is the flow xml:
<flow xmlns="urn:opendaylight:flow:inventory">
<instructions><instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<output-action>
<output-node-connector>FLOOD</output-node-connector>
</output-action>
</action>
</apply-actions>
</instruction>
</instructions>
<match>
<ethernet-match>
<ethernet-type>
<type>0x800</type>
</ethernet-type>
</ethernet-match>
<ipv4-source>11.3.0.0/16</ipv4-source>
<ipv4-destination>99.0.0.0/8</ipv4-destination>
</match>
<table_id>0</table_id>
<id>1</id>
</flow>
Ok, this is new to me because with the flows we push in CI, the Li redesign is doing good.
With input from Jamo I was able to find that problem is in missing priority element.
This patch should solve it in Li OF plugin
https://git.opendaylight.org/gerrit/#/c/21851/
Quotation from commit message:
-------------
Problem was:
- flow was sent to device
- attempt to write flow registry - fails (NPE) because missing priority
- flow was written to device
- statistics bring info about flow
- flow isn't found in flow registry therefore alien ID is generated for it.
Solution:
- sending of flow to device is executed only after storing flow to flow
registry. If it is unsuccessful then nothing is sent to device. Flow is thus
stored only in config DS.
-------------
We use priority in the flows we are pushing in CI and still fail, so I am not sure the root cause is missing priority.
another update.
The flow I'm using is in a previous comment (no priority and no MAC addresses).
there are several combinations here:
A)
He plugin:
flow without priority
- operational store shows alien id
flow with priority
- operational store shows alien id
B)
Li plugin after[1] Jozef's patch[2]
flow without priority
- NO flow in operational. expecting flow and default priority (32768) to be there.
flow with priority
- operational store is OK
C)
Li plugin before[3] Jozef's patch[2]
flow without priority
- operational store shows alien id
flow with priority
- operational store is OK
I'm not sure if the patch [2] is the difference between A) and B), but I came to learn
from Michal that if we don't specify a priority, then the defaut 0x8000 == 32768 is to be
used in the flow pushed to the switch.
[1] distribution-karaf-0.3.0-20150604.163741-2284.zip
[2] https://git.opendaylight.org/gerrit/#/c/21851/1
[3] distribution-karaf-0.3.0-20150602.171547-2182.zip
Looks like this issue happen when user don't specify the cookie value while flow installation, which is perfectly alright. Following patch fixes the issue in Helium code base of stable/lithium branch.
stable/lithium : https://git.opendaylight.org/gerrit/#/c/21981/
Jamo, Above patch should fix (A). Can you please verify the above patch.
Thanks
Anil
Since this is now fixed for Helium portion of stable/lithium - can you (Jozef/Michal) check if the issue is still present Lithium design?
CI is now passing:
https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-cds-flow-services-all-stable-lithium/
I've also verified my previous comments steps (A, B, C). There is still a problem where Li-plugin is not allowing a flow if it doesn't have the
priority explicitly set. A new bug will be opened for that.