From my point of view most of reported problems of Openflowplugin was fixed by
https://git.opendaylight.org/gerrit/#/c/7127/
Which fixed loss of initial features and ports reply messages lost in some scenarious.
Tony
From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...]
On Behalf Of Brent Salisbury
Sent: Tuesday, May 20, 2014 8:38 PM
To: Brent Salisbury; openflowplugin-dev@...; openflowjava-dev
Subject: Re: [openflowplugin-dev] [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL
Looks like SetFields are working again as of today. The branch pulled about 18 hours ago and for the couple of weeks prior didn’t. Can someone point to the patch
that resolved this or maybe even the project / ballpark? It would help unravel how to contribute.
Hey guys, TunnelID matches are failing in OpenflowpluginTestCommandProvider. I narrowed this one down to the mask causing issues. I can help debugging the root
this week if it isn't obvious to you guys. I need to go through all of the flowmods as this was the first one I started with.
I opened a bug with the specific details and logs.
Folks,
In the OF Plugin meeting (Monday morning Pacific / evening for India/Slovakia), Brent is going to go thru his slides confirming his understanding of the openflowplugin,
library, MD-SAL interactions - as well as the issues that he is facing.
Tony, it will be good if you are also present (for some of the MD-SAL interactions). Also of course both the Michals as well as the usual suspects (Prasanna,
Anil, Kamal, etc.).
Abhijit
---------- Forwarded message ----------
From: Brent Salisbury <brent.salisbury@...>
Date: Fri, May 16, 2014 at 11:32 AM
Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL
To: Abhijit Kumbhare <abhijitkoss@...>, "controller-dev@..." <controller-dev@...>,
"openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev
<openflowjava-dev@...>
Thanks Abhijit, I will get the details teased out and make sure we aren’t creating any issues with:
1.
Bad header length on the controller punt that bombs the OF channel with the deserialization issues (#4)
2.
Controller channel resets after bad length.
3.
The channel re-initialization prevents the table-miss drop from being instantiated.
4.
without a table miss drop policy at the end of table=10, OVS punts IPv6 from OpenStack Vms to the controller.
5.
Triggering OXM_OF_IPV6_ND_TARGET TLV deserialization errors with the length - byte SIZE_OF_IPV6_ADDRESS_IN_BYTES = (8 * Short.SIZE) / Byte.SIZE;
Michal: Here is what the basic overlay pipeline looks like for OF13. The extensions will likely wedge into the classifier for now. I added the OVS client commands.
We can also get you setup with the latest OpenStack image from Mestery if it helps next week and get your OpenStack environment up if there was any interest. I can catch up with you on CET if interested.
ovs-vsctl add-port br-int vxlan -- set Interface vxlan type=vxlan options:key=flow options:local_ip=172.16.86.180 options:remote_ip=172.16.86.182 ofport_request=10
ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,tun_id=0x5,in_port=10 actions=goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,in_port=1,dl_src=00:00:00:00:00:01 actions=set_field:5->tun_id,goto_table=10"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,priority=16384,in_port=1 actions=drop"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,tun_id=0x5,dl_dst=00:00:00:00:00:08 actions=output:10,goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,priority=16384,tun_id=0x5,dl_dst=ff:ff:ff:ff:ff:ff actions=output:10,goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,priority=8192,tun_id=0x5 actions=goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,tun_id=0x5,dl_dst=00:00:00:00:00:01 actions=output:1"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,priority=16384,tun_id=0x5,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,priority=8192,tun_id=0x5 actions=drop"
Thanks guys, will get the details in this evening.
Brent will be investigating a bit more & file a bug regarding this reconnection/renegotiation issue & assigning to Michal Rehak.
toggle quoted messageShow quoted text
On Fri, May 16, 2014 at 6:22 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Changing to the mailing lists.
On Fri, May 16, 2014 at 5:22 AM, Michal Polkoráb <michal.polkorab@...> wrote:
Unfortunately I don't know what causes the renegotiation. It is also weird that the switch renegotiates after each flowmod ... there should be no messages
send when no connection is available. The connection loss is the reason for the renegotiation.
Maybe it also depends on the flowmods being installed, because if they are not installed into table 20, there is no table 20 on the device. It might help
to see the desired flowmods.
Regards
Michal
From: Ed Warnicke (eaw) <eaw@...>
Sent: 16 May 2014 14:06
To: Michal Polkoráb; Brent Salisbury; Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Anilkumar
Vishnoi; Prasanna Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios
Cc: Madhu Venugopal; Jan Medved (jmedved); Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker
Subject: RE: OVSDB having many issues over OF Plugin/MD-SAL
Michal,
Could you address the "What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:"
part?
Do you have any good ideas on how to handle the OF13 issue where OVS is out of spec on table miss? I think we all agree that OVS support
is critical, and so this is not a
"Not our problem because the switch is out of spec" thing... its more of a "OK... so what do we do now to cope with OVS being out of spec
there" thing :)
Also... did you get your questions answered here? Do you have other questions or issues we need to dig into to get resolved?
From: Michal Polkoráb [michal.polkorab@...]
Sent: Friday, May 16, 2014 6:04 AM
To: Brent Salisbury; Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Anilkumar Vishnoi; Prasanna
Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios
Cc: Madhu Venugopal; Jan Medved (jmedved); Ed Warnicke (eaw); Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker
Subject: RE: OVSDB having many issues over OF Plugin/MD-SAL
Hi Brent,
a couple of observations:
"The latest issue in the past few days (nothing changed
in the OVSDB project) are the OXM v6 constants. The only thing I can guess as to why these are winding up at the controller is because the pipeline isn’t getting run out to a drop in table20 because the table 20 flowmods are never being instantiated.
Since it is OF13 in the DP the implicit table miss should be dropping rather then punting.
What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:"
- Yes, the specification says that the table miss should be dropped if there is no table miss flow entry installed / pushed. But the OVS switch behaves
differently - it sends the table miss up to the controller even when there was no table miss flow entry installed. Cpqd behaves according to specification.
"The OXMs deserialization errors threw me off because the constant is also an NXM constant I have locally for some NXM matches that
I’ve been beating on which is why it took so long this evening to reply to the thread. I didn’t correlate msgType: 1 equating to OPENFLOW_BASIC 0x8000 and I am assuming NXM0 0x0000 and NXM1 0x0001 are msgType 2 & 3 respectively.
java.lang.NullPointerException: Deserializer for key: msgVersion: 4 class: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev130731.oxm.fields.grouping.MatchEntries
msgType: 1 msgType2: 31 was not found"
You should register your deserializer as: .registerDeserializer(new EnhancedMessageCodeKey(4, 1 (${oxm_class}), 31 (${oxm_field}),
MatchEntries.class), your_deserializer)
From: Brent Salisbury <brent.salisbury@...>
Sent: 16 May 2014 11:00
To: Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Michal Polkoráb; Tony; Robert Varga; Anilkumar Vishnoi; Prasanna Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios
Cc: Madhu Venugopal; Jan Medved; Ed Warnicke; Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker
Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL
Thanks Abhijit, we have seeing an inordinate amount of deserialization errors in the past week with the latest ODL plugin image coupled
with the latest virtualization build. It finally dawned on me maybe why.
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=465.972s, table=0, n_packets=0, n_bytes=0, send_flow_rem tun_id=0x582,in_port=1 actions=goto_table:20
cookie=0x0, duration=605.715s, table=0, n_packets=93, n_bytes=8463, send_flow_rem dl_type=0x88cc actions=CONTROLLER:56
cookie=0x0, duration=465.945s, table=10, n_packets=0, n_bytes=0, send_flow_rem priority=16384,tun_id=0x582,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
actions=output:1,goto_table:20
cookie=0x0, duration=465.972s, table=10, n_packets=0, n_bytes=0, send_flow_rem tun_id=0x582,dl_dst=fa:16:3e:2d:6d:00 actions=output:1,goto_table:20
<Table 20 never gets instantiated>
There is a set of flows that are not called but I haven’t stepped through that yet. We haven’t changed anything in OF13 class we build
the flowmods in since Hydrogen but nothing on the flowmods.
The latest issue in the past few days (nothing changed in the OVSDB project) are the OXM v6 constants. The only thing I can guess as
to why these are winding up at the controller is because the pipeline isn’t getting run out to a drop in table20 because the table 20 flowmods are never being instantiated. Since it is OF13 in the DP the implicit table miss should be dropping rather then punting.
What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:
negotiated OpenFlow version 0x04 (we support version 0x04, peer supports version 0x04)
It appears the LLDP punt length is off, so it may be that we are breaking it with that. I think I remember a patch last week that may
have modified that but need to check.
2014-05-11T05:51:58.087Z|34102|vconn|DBG|tcp:192.168.1.47:6633: sent (Success):
OFPT_PACKET_IN (OF1.3) (xid=0x0): total_len=91 in_port=1 tun_src=192.168.1.49 tun_dst=192.168.1.50 (via action) data_len=56 (unbuffered) (***total_len != data_len***)
metadata=0,in_port=0,vlan_tci=0x0000,dl_src=c2:fb:c5:86:bd:64,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
2014-05-11T05:51:58.087Z|34103|vconn|DBG|tcp:192.168.1.47:6633: sent (Connection
reset by peer): OFPT_PACKET_IN (OF1.3) (xid=0x0): total_len=91 in_port=1 tun_src=192.168.1.49 tun_dst=192.168.1.50 (via action) data_len=56 (unbuffered) (***total_len != data_len***)
metadata=0,in_port=0,vlan_tci=0x0000,dl_src=c2:fb:c5:86:bd:64,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
2014-05-11T05:51:58.087Z|34104|rconn|WARN|br-int<->tcp:192.168.1.47:6633: connection
dropped (Connection reset by peer)
2014-05-11T05:51:58.087Z|34105|rconn|DBG|br-int<->tcp:192.168.1.47:6633: entering
BACKOFF
The OXMs deserialization errors threw me off because the constant is also an NXM constant I have locally for some NXM matches that I’ve
been beating on which is why it took so long this evening to reply to the thread. I didn’t correlate msgType: 1 equating to OPENFLOW_BASIC 0x8000 and I am assuming NXM0 0x0000 and NXM1 0x0001 are msgType 2 & 3 respectively.
java.lang.NullPointerException: Deserializer for key: msgVersion: 4 class: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev130731.oxm.fields.grouping.MatchEntries
msgType: 1 msgType2: 31 was not found
In the file "OVS-Debug-Search-for-OFPT_FLOW_MOD.txt" if you search for "OFPT_FLOW_MOD" it shows the flowmods for table0-10. Table20
never arrives. The sun is coming up here and I have calls in a couple of hours. I just didn’t want to leave the thread dangling. Michal P has already looked at the bug Hsin-Yi and Madhu opened earlier which is much appreciated. If this wasn’t our OpenStack
integration I would be less panicky about it. It works fine on builds from a couple of weeks ago on the image that Mestery did recently (unless it pulls from the latest virtualization build which now I realize Im not sure).
Just wanted to brain dump before I took a break for a couple hours sleep. If any of this rings a bell please let us know. It may be
as simple as the controller punt length being wrong but I gotta call it for now. We have some good stuff to contribute back to ofplugin soon, we just still need to understand how ofplugin ties into MD_SAL first. One of the team will update the thread and thanks
again for being responsive on this.
From:
Abhijit Kumbhare <abhijitkoss@...>
Date: Friday, May 16, 2014 at 12:07 AM
To: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>, "michal.polkorab" <michal.polkorab@...>,
Tony <ttkacik@...>, Robert Varga <rovarga@...>, Anilkumar Vishnoi <avishnoi@...>,
Prasanna Huddar <prasanna.huddar@...>, "Kamal Rameshan (kramesha)" <kramesha@...>, Luis Gomez Palacios <ecelgp@...>
Cc: Madhu Venugopal <mavenugo@...>, Jan Medved <jmedved@...>, Brent Salisbury <brent.salisbury@...>,
Ed Warnicke <eaw@...>
Subject: OVSDB having many issues over OF Plugin/MD-SAL
Hi Michal & Michal, Tony,
It seems that Hsin-Yi/Brent/Madhu/OVSDB folks many issues in the last few days for consuming MD-SAL/OF-plugin. Has there been any major changes in the
last week or so? Can you guys help?
Apparently they are having OSGI console blows up w/ deserialization errors (x: DOM-1454 Did not pass canCommit phase.).
Brent will add more details.
I don't recall many changes in the OF plugin.
Of course - there is the following bug that Kamal is working on:
Kamal was also saying he is seeing issues with OF 1.3 (in addition to the above bug with OF 1.0 mininet).
MichalPolkoráb
Software Developer
Mlynské Nivy 56
/ 821 05 Bratislava
/ Slovakia
+421 918 378 907 /
michal.polkorab@...
reception: +421 2 206 65 111
/ www.pantheon.sk
_______________________________________________ openflowjava-dev mailing list
openflowjava-dev@...https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
|
|
Brent,
Are there any outstanding issues that you think the OVSDB project needs fixed? We (openflow plugin) will be meeting at 10 pm Pacific tonight (we will be concentrating on issues relevant to stable release) - if you have any issues you would like to discuss you are welcome.
Thanks, Abhijit
toggle quoted messageShow quoted text
From my point of view most of reported problems of Openflowplugin was fixed by
https://git.opendaylight.org/gerrit/#/c/7127/
Which fixed loss of initial features and ports reply messages lost in some scenarious.
Tony
Looks like SetFields are working again as of today. The branch pulled about 18 hours ago and for the couple of weeks prior didn’t. Can someone point to the patch
that resolved this or maybe even the project / ballpark? It would help unravel how to contribute.
Hey guys, TunnelID matches are failing in OpenflowpluginTestCommandProvider. I narrowed this one down to the mask causing issues. I can help debugging the root
this week if it isn't obvious to you guys. I need to go through all of the flowmods as this was the first one I started with.
I opened a bug with the specific details and logs.
Folks,
In the OF Plugin meeting (Monday morning Pacific / evening for India/Slovakia), Brent is going to go thru his slides confirming his understanding of the openflowplugin,
library, MD-SAL interactions - as well as the issues that he is facing.
Tony, it will be good if you are also present (for some of the MD-SAL interactions). Also of course both the Michals as well as the usual suspects (Prasanna,
Anil, Kamal, etc.).
Abhijit
Thanks Abhijit, I will get the details teased out and make sure we aren’t creating any issues with:
1.
Bad header length on the controller punt that bombs the OF channel with the deserialization issues (#4)
2.
Controller channel resets after bad length.
3.
The channel re-initialization prevents the table-miss drop from being instantiated.
4.
without a table miss drop policy at the end of table=10, OVS punts IPv6 from OpenStack Vms to the controller.
5.
Triggering OXM_OF_IPV6_ND_TARGET TLV deserialization errors with the length - byte SIZE_OF_IPV6_ADDRESS_IN_BYTES = (8 * Short.SIZE) / Byte.SIZE;
Michal: Here is what the basic overlay pipeline looks like for OF13. The extensions will likely wedge into the classifier for now. I added the OVS client commands.
We can also get you setup with the latest OpenStack image from Mestery if it helps next week and get your OpenStack environment up if there was any interest. I can catch up with you on CET if interested.
ovs-vsctl add-port br-int vxlan -- set Interface vxlan type=vxlan options:key=flow options:local_ip=172.16.86.180 options:remote_ip=172.16.86.182 ofport_request=10
ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,tun_id=0x5,in_port=10 actions=goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,in_port=1,dl_src=00:00:00:00:00:01 actions=set_field:5->tun_id,goto_table=10"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,priority=16384,in_port=1 actions=drop"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,tun_id=0x5,dl_dst=00:00:00:00:00:08 actions=output:10,goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,priority=16384,tun_id=0x5,dl_dst=ff:ff:ff:ff:ff:ff actions=output:10,goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,priority=8192,tun_id=0x5 actions=goto_table:20"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,tun_id=0x5,dl_dst=00:00:00:00:00:01 actions=output:1"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,priority=16384,tun_id=0x5,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1"
ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,priority=8192,tun_id=0x5 actions=drop"
Thanks guys, will get the details in this evening.
Brent will be investigating a bit more & file a bug regarding this reconnection/renegotiation issue & assigning to Michal Rehak.
On Fri, May 16, 2014 at 6:22 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Changing to the mailing lists.
On Fri, May 16, 2014 at 5:22 AM, Michal Polkoráb <michal.polkorab@...> wrote:
Unfortunately I don't know what causes the renegotiation. It is also weird that the switch renegotiates after each flowmod ... there should be no messages
send when no connection is available. The connection loss is the reason for the renegotiation.
Maybe it also depends on the flowmods being installed, because if they are not installed into table 20, there is no table 20 on the device. It might help
to see the desired flowmods.
Regards
Michal
From: Ed Warnicke (eaw) <eaw@...>
Sent: 16 May 2014 14:06
To: Michal Polkoráb; Brent Salisbury; Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Anilkumar
Vishnoi; Prasanna Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios
Cc: Madhu Venugopal; Jan Medved (jmedved); Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker
Subject: RE: OVSDB having many issues over OF Plugin/MD-SAL
Michal,
Could you address the "What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:"
part?
Do you have any good ideas on how to handle the OF13 issue where OVS is out of spec on table miss? I think we all agree that OVS support
is critical, and so this is not a
"Not our problem because the switch is out of spec" thing... its more of a "OK... so what do we do now to cope with OVS being out of spec
there" thing :)
Also... did you get your questions answered here? Do you have other questions or issues we need to dig into to get resolved?
From: Michal Polkoráb [michal.polkorab@...]
Sent: Friday, May 16, 2014 6:04 AM
To: Brent Salisbury; Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Anilkumar Vishnoi; Prasanna
Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios
Cc: Madhu Venugopal; Jan Medved (jmedved); Ed Warnicke (eaw); Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker
Subject: RE: OVSDB having many issues over OF Plugin/MD-SAL
Hi Brent,
a couple of observations:
"The latest issue in the past few days (nothing changed
in the OVSDB project) are the OXM v6 constants. The only thing I can guess as to why these are winding up at the controller is because the pipeline isn’t getting run out to a drop in table20 because the table 20 flowmods are never being instantiated.
Since it is OF13 in the DP the implicit table miss should be dropping rather then punting.
What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:"
- Yes, the specification says that the table miss should be dropped if there is no table miss flow entry installed / pushed. But the OVS switch behaves
differently - it sends the table miss up to the controller even when there was no table miss flow entry installed. Cpqd behaves according to specification.
"The OXMs deserialization errors threw me off because the constant is also an NXM constant I have locally for some NXM matches that
I’ve been beating on which is why it took so long this evening to reply to the thread. I didn’t correlate msgType: 1 equating to OPENFLOW_BASIC 0x8000 and I am assuming NXM0 0x0000 and NXM1 0x0001 are msgType 2 & 3 respectively.
java.lang.NullPointerException: Deserializer for key: msgVersion: 4 class: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev130731.oxm.fields.grouping.MatchEntries
msgType: 1 msgType2: 31 was not found"
You should register your deserializer as: .registerDeserializer(new EnhancedMessageCodeKey(4, 1 (${oxm_class}), 31 (${oxm_field}),
MatchEntries.class), your_deserializer)
From: Brent Salisbury <brent.salisbury@...>
Sent: 16 May 2014 11:00
To: Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Michal Polkoráb; Tony; Robert Varga; Anilkumar Vishnoi; Prasanna Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios
Cc: Madhu Venugopal; Jan Medved; Ed Warnicke; Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker
Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL
Thanks Abhijit, we have seeing an inordinate amount of deserialization errors in the past week with the latest ODL plugin image coupled
with the latest virtualization build. It finally dawned on me maybe why.
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=465.972s, table=0, n_packets=0, n_bytes=0, send_flow_rem tun_id=0x582,in_port=1 actions=goto_table:20
cookie=0x0, duration=605.715s, table=0, n_packets=93, n_bytes=8463, send_flow_rem dl_type=0x88cc actions=CONTROLLER:56
cookie=0x0, duration=465.945s, table=10, n_packets=0, n_bytes=0, send_flow_rem priority=16384,tun_id=0x582,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
actions=output:1,goto_table:20
cookie=0x0, duration=465.972s, table=10, n_packets=0, n_bytes=0, send_flow_rem tun_id=0x582,dl_dst=fa:16:3e:2d:6d:00 actions=output:1,goto_table:20
<Table 20 never gets instantiated>
There is a set of flows that are not called but I haven’t stepped through that yet. We haven’t changed anything in OF13 class we build
the flowmods in since Hydrogen but nothing on the flowmods.
The latest issue in the past few days (nothing changed in the OVSDB project) are the OXM v6 constants. The only thing I can guess as
to why these are winding up at the controller is because the pipeline isn’t getting run out to a drop in table20 because the table 20 flowmods are never being instantiated. Since it is OF13 in the DP the implicit table miss should be dropping rather then punting.
What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:
negotiated OpenFlow version 0x04 (we support version 0x04, peer supports version 0x04)
It appears the LLDP punt length is off, so it may be that we are breaking it with that. I think I remember a patch last week that may
have modified that but need to check.
2014-05-11T05:51:58.087Z|34102|vconn|DBG|tcp:192.168.1.47:6633: sent (Success):
OFPT_PACKET_IN (OF1.3) (xid=0x0): total_len=91 in_port=1 tun_src=192.168.1.49 tun_dst=192.168.1.50 (via action) data_len=56 (unbuffered) (***total_len != data_len***)
metadata=0,in_port=0,vlan_tci=0x0000,dl_src=c2:fb:c5:86:bd:64,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
2014-05-11T05:51:58.087Z|34103|vconn|DBG|tcp:192.168.1.47:6633: sent (Connection
reset by peer): OFPT_PACKET_IN (OF1.3) (xid=0x0): total_len=91 in_port=1 tun_src=192.168.1.49 tun_dst=192.168.1.50 (via action) data_len=56 (unbuffered) (***total_len != data_len***)
metadata=0,in_port=0,vlan_tci=0x0000,dl_src=c2:fb:c5:86:bd:64,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
2014-05-11T05:51:58.087Z|34104|rconn|WARN|br-int<->tcp:192.168.1.47:6633: connection
dropped (Connection reset by peer)
2014-05-11T05:51:58.087Z|34105|rconn|DBG|br-int<->tcp:192.168.1.47:6633: entering
BACKOFF
The OXMs deserialization errors threw me off because the constant is also an NXM constant I have locally for some NXM matches that I’ve
been beating on which is why it took so long this evening to reply to the thread. I didn’t correlate msgType: 1 equating to OPENFLOW_BASIC 0x8000 and I am assuming NXM0 0x0000 and NXM1 0x0001 are msgType 2 & 3 respectively.
java.lang.NullPointerException: Deserializer for key: msgVersion: 4 class: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev130731.oxm.fields.grouping.MatchEntries
msgType: 1 msgType2: 31 was not found
In the file "OVS-Debug-Search-for-OFPT_FLOW_MOD.txt" if you search for "OFPT_FLOW_MOD" it shows the flowmods for table0-10. Table20
never arrives. The sun is coming up here and I have calls in a couple of hours. I just didn’t want to leave the thread dangling. Michal P has already looked at the bug Hsin-Yi and Madhu opened earlier which is much appreciated. If this wasn’t our OpenStack
integration I would be less panicky about it. It works fine on builds from a couple of weeks ago on the image that Mestery did recently (unless it pulls from the latest virtualization build which now I realize Im not sure).
Just wanted to brain dump before I took a break for a couple hours sleep. If any of this rings a bell please let us know. It may be
as simple as the controller punt length being wrong but I gotta call it for now. We have some good stuff to contribute back to ofplugin soon, we just still need to understand how ofplugin ties into MD_SAL first. One of the team will update the thread and thanks
again for being responsive on this.
From:
Abhijit Kumbhare <abhijitkoss@...>
Date: Friday, May 16, 2014 at 12:07 AM
To: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>, "michal.polkorab" <michal.polkorab@...>,
Tony <ttkacik@...>, Robert Varga <rovarga@...>, Anilkumar Vishnoi <avishnoi@...>,
Prasanna Huddar <prasanna.huddar@...>, "Kamal Rameshan (kramesha)" <kramesha@...>, Luis Gomez Palacios <ecelgp@...>
Cc: Madhu Venugopal <mavenugo@...>, Jan Medved <jmedved@...>, Brent Salisbury <brent.salisbury@...>,
Ed Warnicke <eaw@...>
Subject: OVSDB having many issues over OF Plugin/MD-SAL
Hi Michal & Michal, Tony,
It seems that Hsin-Yi/Brent/Madhu/OVSDB folks many issues in the last few days for consuming MD-SAL/OF-plugin. Has there been any major changes in the
last week or so? Can you guys help?
Apparently they are having OSGI console blows up w/ deserialization errors (x: DOM-1454 Did not pass canCommit phase.).
Brent will add more details.
I don't recall many changes in the OF plugin.
Of course - there is the following bug that Kamal is working on:
Kamal was also saying he is seeing issues with OF 1.3 (in addition to the above bug with OF 1.0 mininet).
MichalPolkoráb
Software Developer
Mlynské Nivy 56
/ 821 05 Bratislava
/ Slovakia
+421 918 378 907 /
michal.polkorab@...
reception: +421 2 206 65 111
/ www.pantheon.sk
_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
|
|
Hi guys, apologies for the delayed response today, I was needing to catch up on other other projects. I think things look good to go like Tony said. We are working on getting integration testing implemented ASAP. Would like to pick your guys brains next Monday if you guys wouldn’t mind on a reasonable way to test the Java APIs into an OVS datapath end to end.
I will shoot to get a proof over the weekend. Not sure if Pax Exam is the only path there or if the team had some other ideas. Would be a great place to collaborate on. Certainly appreciated the teams attention and responsiveness on these issues.
Thanks! -Brent
Brent,
Are there any outstanding issues that you think the OVSDB project needs fixed? We (openflow plugin) will be meeting at 10 pm Pacific tonight (we will be concentrating on issues relevant to stable release) - if you have any issues you would like to discuss you are welcome.
Thanks, Abhijit
toggle quoted messageShow quoted text
From my point of view most of reported problems of Openflowplugin was fixed by
https://git.opendaylight.org/gerrit/#/c/7127/ Which fixed loss of initial features and ports reply messages lost in some scenarious. Tony Looks like SetFields are working again as of today. The branch pulled about 18 hours ago and for the couple of weeks prior didn’t. Can someone point to the patch
that resolved this or maybe even the project / ballpark? It would help unravel how to contribute. Hey guys, TunnelID matches are failing in OpenflowpluginTestCommandProvider. I narrowed this one down to the mask causing issues. I can help debugging the root
this week if it isn't obvious to you guys. I need to go through all of the flowmods as this was the first one I started with. I opened a bug with the specific details and logs. Folks, In the OF Plugin meeting (Monday morning Pacific / evening for India/Slovakia), Brent is going to go thru his slides confirming his understanding of the openflowplugin,
library, MD-SAL interactions - as well as the issues that he is facing. Tony, it will be good if you are also present (for some of the MD-SAL interactions). Also of course both the Michals as well as the usual suspects (Prasanna,
Anil, Kamal, etc.). Abhijit Thanks Abhijit, I will get the details teased out and make sure we aren’t creating any issues with: 1.
Bad header length on the controller punt that bombs the OF channel with the deserialization issues (#4) 2.
Controller channel resets after bad length. 3.
The channel re-initialization prevents the table-miss drop from being instantiated. 4.
without a table miss drop policy at the end of table=10, OVS punts IPv6 from OpenStack Vms to the controller. 5.
Triggering OXM_OF_IPV6_ND_TARGET TLV deserialization errors with the length - byte SIZE_OF_IPV6_ADDRESS_IN_BYTES = (8 * Short.SIZE) / Byte.SIZE; Michal: Here is what the basic overlay pipeline looks like for OF13. The extensions will likely wedge into the classifier for now. I added the OVS client commands.
We can also get you setup with the latest OpenStack image from Mestery if it helps next week and get your OpenStack environment up if there was any interest. I can catch up with you on CET if interested. ovs-vsctl add-port br-int vxlan -- set Interface vxlan type=vxlan options:key=flow options:local_ip=172.16.86.180 options:remote_ip=172.16.86.182 ofport_request=10 ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,tun_id=0x5,in_port=10 actions=goto_table:20" ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,in_port=1,dl_src=00:00:00:00:00:01 actions=set_field:5->tun_id,goto_table=10" ovs-ofctl add-flow -O OpenFlow13 br-int "table=0,priority=16384,in_port=1 actions=drop" ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,tun_id=0x5,dl_dst=00:00:00:00:00:08 actions=output:10,goto_table:20" ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,priority=16384,tun_id=0x5,dl_dst=ff:ff:ff:ff:ff:ff actions=output:10,goto_table:20" ovs-ofctl add-flow -O OpenFlow13 br-int "table=10,priority=8192,tun_id=0x5 actions=goto_table:20" ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,tun_id=0x5,dl_dst=00:00:00:00:00:01 actions=output:1" ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,priority=16384,tun_id=0x5,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1" ovs-ofctl add-flow -O OpenFlow13 br-int "table=20,priority=8192,tun_id=0x5 actions=drop" Thanks guys, will get the details in this evening. Brent will be investigating a bit more & file a bug regarding this reconnection/renegotiation issue & assigning to Michal Rehak. On Fri, May 16, 2014 at 6:22 AM, Abhijit Kumbhare <abhijitkoss@...> wrote: Changing to the mailing lists. On Fri, May 16, 2014 at 5:22 AM, Michal Polkoráb <michal.polkorab@...> wrote: Unfortunately I don't know what causes the renegotiation. It is also weird that the switch renegotiates after each flowmod ... there should be no messages
send when no connection is available. The connection loss is the reason for the renegotiation. Maybe it also depends on the flowmods being installed, because if they are not installed into table 20, there is no table 20 on the device. It might help
to see the desired flowmods. Regards Michal
From: Ed Warnicke (eaw) <eaw@...> Sent: 16 May 2014 14:06 To: Michal Polkoráb; Brent Salisbury; Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Anilkumar
Vishnoi; Prasanna Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios Cc: Madhu Venugopal; Jan Medved (jmedved); Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker Subject: RE: OVSDB having many issues over OF Plugin/MD-SAL
Michal,
Could you address the "What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:"
part? Do you have any good ideas on how to handle the OF13 issue where OVS is out of spec on table miss? I think we all agree that OVS support
is critical, and so this is not a "Not our problem because the switch is out of spec" thing... its more of a "OK... so what do we do now to cope with OVS being out of spec
there" thing :) Also... did you get your questions answered here? Do you have other questions or issues we need to dig into to get resolved?
From: Michal Polkoráb [michal.polkorab@...] Sent: Friday, May 16, 2014 6:04 AM To: Brent Salisbury; Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Anilkumar Vishnoi; Prasanna
Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios Cc: Madhu Venugopal; Jan Medved (jmedved); Ed Warnicke (eaw); Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker Subject: RE: OVSDB having many issues over OF Plugin/MD-SAL Hi Brent, a couple of observations: "The latest issue in the past few days (nothing changed
in the OVSDB project) are the OXM v6 constants. The only thing I can guess as to why these are winding up at the controller is because the pipeline isn’t getting run out to a drop in table20 because the table 20 flowmods are never being instantiated.
Since it is OF13 in the DP the implicit table miss should be dropping rather then punting.
What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller:" - Yes, the specification says that the table miss should be dropped if there is no table miss flow entry installed / pushed. But the OVS switch behaves
differently - it sends the table miss up to the controller even when there was no table miss flow entry installed. Cpqd behaves according to specification. "The OXMs deserialization errors threw me off because the constant is also an NXM constant I have locally for some NXM matches that
I’ve been beating on which is why it took so long this evening to reply to the thread. I didn’t correlate msgType: 1 equating to OPENFLOW_BASIC 0x8000 and I am assuming NXM0 0x0000 and NXM1 0x0001 are msgType 2 & 3 respectively. java.lang.NullPointerException: Deserializer for key: msgVersion: 4 class: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev130731.oxm.fields.grouping.MatchEntries
msgType: 1 msgType2: 31 was not found" You should register your deserializer as: .registerDeserializer(new EnhancedMessageCodeKey(4, 1 (${oxm_class}), 31 (${oxm_field}),
MatchEntries.class), your_deserializer)
From: Brent Salisbury <brent.salisbury@...> Sent: 16 May 2014 11:00 To: Abhijit Kumbhare; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); Michal Polkoráb; Tony; Robert Varga; Anilkumar Vishnoi; Prasanna Huddar; Kamal Rameshan (kramesha); Luis Gomez Palacios Cc: Madhu Venugopal; Jan Medved; Ed Warnicke; Chris Wright; Kyle Mestery; Hsin-Yi Shen; Sam Hague; Dave Tucker Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL Thanks Abhijit, we have seeing an inordinate amount of deserialization errors in the past week with the latest ODL plugin image coupled
with the latest virtualization build. It finally dawned on me maybe why. OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=465.972s, table=0, n_packets=0, n_bytes=0, send_flow_rem tun_id=0x582,in_port=1 actions=goto_table:20 cookie=0x0, duration=605.715s, table=0, n_packets=93, n_bytes=8463, send_flow_rem dl_type=0x88cc actions=CONTROLLER:56 cookie=0x0, duration=465.945s, table=10, n_packets=0, n_bytes=0, send_flow_rem priority=16384,tun_id=0x582,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
actions=output:1,goto_table:20 cookie=0x0, duration=465.972s, table=10, n_packets=0, n_bytes=0, send_flow_rem tun_id=0x582,dl_dst=fa:16:3e:2d:6d:00 actions=output:1,goto_table:20 <Table 20 never gets instantiated> There is a set of flows that are not called but I haven’t stepped through that yet. We haven’t changed anything in OF13 class we build
the flowmods in since Hydrogen but nothing on the flowmods. The latest issue in the past few days (nothing changed in the OVSDB project) are the OXM v6 constants. The only thing I can guess as
to why these are winding up at the controller is because the pipeline isn’t getting run out to a drop in table20 because the table 20 flowmods are never being instantiated. Since it is OF13 in the DP the implicit table miss should be dropping rather then punting.
What I am seeing however is the OF channel to OVS getting re-negotiated with each flowmod from the controller: negotiated OpenFlow version 0x04 (we support version 0x04, peer supports version 0x04) It appears the LLDP punt length is off, so it may be that we are breaking it with that. I think I remember a patch last week that may
have modified that but need to check. 2014-05-11T05:51:58.087Z|34102|vconn|DBG|tcp:192.168.1.47:6633: sent (Success):
OFPT_PACKET_IN (OF1.3) (xid=0x0): total_len=91 in_port=1 tun_src=192.168.1.49 tun_dst=192.168.1.50 (via action) data_len=56 (unbuffered) (***total_len != data_len***) metadata=0,in_port=0,vlan_tci=0x0000,dl_src=c2:fb:c5:86:bd:64,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc 2014-05-11T05:51:58.087Z|34103|vconn|DBG|tcp:192.168.1.47:6633: sent (Connection
reset by peer): OFPT_PACKET_IN (OF1.3) (xid=0x0): total_len=91 in_port=1 tun_src=192.168.1.49 tun_dst=192.168.1.50 (via action) data_len=56 (unbuffered) (***total_len != data_len***) metadata=0,in_port=0,vlan_tci=0x0000,dl_src=c2:fb:c5:86:bd:64,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc 2014-05-11T05:51:58.087Z|34104|rconn|WARN|br-int<->tcp:192.168.1.47:6633: connection
dropped (Connection reset by peer) 2014-05-11T05:51:58.087Z|34105|rconn|DBG|br-int<->tcp:192.168.1.47:6633: entering
BACKOFF The OXMs deserialization errors threw me off because the constant is also an NXM constant I have locally for some NXM matches that I’ve
been beating on which is why it took so long this evening to reply to the thread. I didn’t correlate msgType: 1 equating to OPENFLOW_BASIC 0x8000 and I am assuming NXM0 0x0000 and NXM1 0x0001 are msgType 2 & 3 respectively. java.lang.NullPointerException: Deserializer for key: msgVersion: 4 class: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev130731.oxm.fields.grouping.MatchEntries
msgType: 1 msgType2: 31 was not found In the file "OVS-Debug-Search-for-OFPT_FLOW_MOD.txt" if you search for "OFPT_FLOW_MOD" it shows the flowmods for table0-10. Table20
never arrives. The sun is coming up here and I have calls in a couple of hours. I just didn’t want to leave the thread dangling. Michal P has already looked at the bug Hsin-Yi and Madhu opened earlier which is much appreciated. If this wasn’t our OpenStack
integration I would be less panicky about it. It works fine on builds from a couple of weeks ago on the image that Mestery did recently (unless it pulls from the latest virtualization build which now I realize Im not sure). Just wanted to brain dump before I took a break for a couple hours sleep. If any of this rings a bell please let us know. It may be
as simple as the controller punt length being wrong but I gotta call it for now. We have some good stuff to contribute back to ofplugin soon, we just still need to understand how ofplugin ties into MD_SAL first. One of the team will update the thread and thanks
again for being responsive on this. From:
Abhijit Kumbhare <abhijitkoss@...> Date: Friday, May 16, 2014 at 12:07 AM To: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>, "michal.polkorab" <michal.polkorab@...>,
Tony <ttkacik@...>, Robert Varga <rovarga@...>, Anilkumar Vishnoi <avishnoi@...>,
Prasanna Huddar <prasanna.huddar@...>, "Kamal Rameshan (kramesha)" <kramesha@...>, Luis Gomez Palacios <ecelgp@...> Cc: Madhu Venugopal <mavenugo@...>, Jan Medved <jmedved@...>, Brent Salisbury <brent.salisbury@...>,
Ed Warnicke <eaw@...> Subject: OVSDB having many issues over OF Plugin/MD-SAL Hi Michal & Michal, Tony,
It seems that Hsin-Yi/Brent/Madhu/OVSDB folks many issues in the last few days for consuming MD-SAL/OF-plugin. Has there been any major changes in the
last week or so? Can you guys help? Apparently they are having OSGI console blows up w/ deserialization errors (x: DOM-1454 Did not pass canCommit phase.). Brent will add more details. I don't recall many changes in the OF plugin. Of course - there is the following bug that Kamal is working on: Kamal was also saying he is seeing issues with OF 1.3 (in addition to the above bug with OF 1.0 mininet). MichalPolkoráb Software Developer Mlynské Nivy 56
/ 821 05 Bratislava
/ Slovakia +421 918 378 907 /
michal.polkorab@...
reception: +421 2 206 65 111/ www.pantheon.sk
_______________________________________________
openflowplugin-dev mailing list openflowplugin-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
|
|