[openflowplugin-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL


Tony Tkacik
 

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. 

 

As an FYI, I opened an LLDP bug: https://bugs.opendaylight.org/show_bug.cgi?id=1055

 

Thanks,

-Brent

 

From: Brent Salisbury <brent.salisbury@...>
Date: Tuesday, May 20, 2014 at 2:31 AM
To: "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>
Subject: Re: [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

 

 

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.

 

Thanks,

-Brent

 

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Monday, May 19, 2014 at 12:40 AM
To: "openflowplugin-dev@..." <openflowplugin-dev@...>, Tony <ttkacik@...>
Cc: openflowjava-dev <openflowjava-dev@...>
Subject: [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

 

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.).

 

Thanks,

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.

 

// OVSDB TEP init

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

 

// Classifier table 0

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"

 

// Egress table 10

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"

 

// Ingress 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

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Friday, May 16, 2014 at 1:16 PM
To: "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>, Brent Salisbury <brent.salisbury@...>


Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL

 

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?

 

Brent,

 

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?

 

Ed


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) 

 

Regards

Michal Polkorab

 


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

 

Zip with logs.

 

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. 

 

Cheers,

-Brent

 

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).

 

Thanks,

Abhijit

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

logo 

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

logo

 

 

 

_______________________________________________ openflowjava-dev mailing list openflowjava-dev@...https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev


Abhijit Kumbhare
 

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  


On Wed, May 21, 2014 at 1:08 AM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:

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. 

 

As an FYI, I opened an LLDP bug: https://bugs.opendaylight.org/show_bug.cgi?id=1055

 

Thanks,

-Brent

 

From: Brent Salisbury <brent.salisbury@...>
Date: Tuesday, May 20, 2014 at 2:31 AM
To: "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>
Subject: Re: [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

 

 

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.

 

Thanks,

-Brent

 

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Monday, May 19, 2014 at 12:40 AM
To: "openflowplugin-dev@..." <openflowplugin-dev@...>, Tony <ttkacik@...>
Cc: openflowjava-dev <openflowjava-dev@...>
Subject: [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

 

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.).

 

Thanks,

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.

 

// OVSDB TEP init

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

 

// Classifier table 0

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"

 

// Egress table 10

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"

 

// Ingress 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

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Friday, May 16, 2014 at 1:16 PM
To: "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>, Brent Salisbury <brent.salisbury@...>


Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL

 

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?

 

Brent,

 

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?

 

Ed


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) 

 

Regards

Michal Polkorab

 


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

 

Zip with logs.

 

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. 

 

Cheers,

-Brent

 

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).

 

Thanks,

Abhijit

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

logo 

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

logo

 

 

 

_______________________________________________ openflowjava-dev mailing list openflowjava-dev@...https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev


_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev



Brent Salisbury
 

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

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Wednesday, May 21, 2014 at 8:54 PM
To: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Cc: Brent Salisbury <brent.salisbury@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>
Subject: Re: [openflowplugin-dev] [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

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  


On Wed, May 21, 2014 at 1:08 AM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:

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. 

 

As an FYI, I opened an LLDP bug: https://bugs.opendaylight.org/show_bug.cgi?id=1055

 

Thanks,

-Brent

 

From: Brent Salisbury <brent.salisbury@...>
Date: Tuesday, May 20, 2014 at 2:31 AM
To: "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>
Subject: Re: [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

 

 

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.

 

Thanks,

-Brent

 

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Monday, May 19, 2014 at 12:40 AM
To: "openflowplugin-dev@..." <openflowplugin-dev@...>, Tony <ttkacik@...>
Cc: openflowjava-dev <openflowjava-dev@...>
Subject: [openflowjava-dev] Fwd: OVSDB having many issues over OF Plugin/MD-SAL

 

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.).

 

Thanks,

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.

 

// OVSDB TEP init

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

 

// Classifier table 0

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"

 

// Egress table 10

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"

 

// Ingress 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

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Friday, May 16, 2014 at 1:16 PM
To: "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, openflowjava-dev <openflowjava-dev@...>, Brent Salisbury <brent.salisbury@...>


Subject: Re: OVSDB having many issues over OF Plugin/MD-SAL

 

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?

 

Brent,

 

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?

 

Ed


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) 

 

Regards

Michal Polkorab

 


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

 

Zip with logs.

 

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. 

 

Cheers,

-Brent

 

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).

 

Thanks,

Abhijit

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

logo 

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

logo

 

 

 

_______________________________________________ openflowjava-dev mailing list openflowjava-dev@...https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev


_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev