[OPNFLWPLUG-478] with switch-features-mandatory set to true, switch without required features should not be allowed to connect Created: 02/Jun/15  Updated: 27/Sep/21  Resolved: 26/Jun/17

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Jamo Luhrsen Assignee: Jamo Luhrsen
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 3549

 Description   

In the Lithium plugin redesign we now have a configuration to make switch features required:

~$ egrep features distribution-2182/etc/opendaylight/karaf/42-openflowplugin-Li.xml
<switch-features-mandatory>true</switch-features-mandatory>

By default it is false and allows switches (e.g. OVS 2.0.2) that do not support all the
features to still operate as they have in the past with ODL.

If that config is set to true, we are currently still holding a connection with an
unsupported switch. The switch will be shown in operational store as connected and
thus will even show up in the GUI. However, we cannot interact with the switch as
we'd expect (e.g.pushing flows, reading tables). A REST call to config store to get flows
for this connected device will hang for a while and finally give a 500 internal error.

If there is a good reason to retain the connection of this switch without the mandatory
features, then we need to make it clear to the user and be able to handle REST interactions
without hanging. I don't know of a good reason, so my current opinion is that we can
just reject the connection up front.

 Comments   
Comment by Anton Ivanov [ 09/Sep/15 ]

There is a corresponding FIXME on line 290 in openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/device/DeviceManagerImpl.java

The session is indeed not removed - that is the present code behavior.

Comment by Anton Ivanov [ 11/Sep/15 ]

That whole section of the code needs fixing:

It does not have a FSM for the connected switch. As a result it is likely to show other undefined or erroneous behaviour when a "switch" drops or stalls a connection mid-negotiation.

This needs a rewrite + a corresponding torture test (unit test or test using a 3rd party openflow library).

Please do not mark as resolved until there is a matching test.

Comment by Tomas Slusny [ 07/Apr/17 ]

Right now when this happens, entire connection is closed on both carbon and boron in Lithium design, so this should be fixed now, so this one can probably be closed.

Comment by Jamo Luhrsen [ 07/Apr/17 ]

(In reply to Tomas Slusny from comment #3)
> Right now when this happens, entire connection is closed on both carbon and
> boron in Lithium design, so this should be fixed now, so this one can
> probably be closed.

This is an old bug, but I just tried with ovs 2.0.2 (what I noted originally)
and the switch connects and seems to function as you'd expect with a
connected switch (can push flows, view in config/operational, etc)

the question is then, should this old ovs 2.0.2 be rejected if mandatory
switch features are configured as true?

Comment by Jozef Bacigal [ 05/Jun/17 ]

https://git.opendaylight.org/gerrit/#/c/58179/

Generated at Wed Feb 07 20:32:36 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.