[ovs-discuss] OpenVSwitch looped topology without bonds/STP

[Raymond Burkholder]

On 2019-03-27 1:48 p.m., Colton Powell wrote:
> The difficult part for us, however, is actually finding the paths to redirect on. Because we are currently using STP in our looped topology, OpenDaylight cannot find all links/paths in the network. Only links on the Spanning Tree are found (similarly, any link that would create a cycle/loop is not found).

Well actually, that is the way things are supposed to work.  I think 
that even if you could 'know about the link' and you could write a rule 
to redirect the flow, with STP enabled, the packets would get dropped 
anyway, which is the hard-wired nature of switches and spanning tree.

> So, from the controller-side of things, we do not have visibility of all links in the network. As a result, we cannot optimally distribute traffic throughout the network, due to the fact that we do not have a complete view of all links in the network.

I would suggest thought that is only half correct.  I'd say that you do 
indeed have visibility to all 'forwarding links' on the network.

> Therefore, we were either hoping to a) find a solution without STP or b) Use STP, but modify our OVS configuration, with the ultimate goal of achieving visibility of all links in the network.

If you want this to work, you would have to disable STP, and remove, by 
default, all forwarding and generation rules in OVS.  By removing STP, 
the switch will bring up all ports.  By removing all rules, including 
default rules, you prevent packet storms.

You'd have to somehow enable LLDP neighbor detection or similar.  LLDP, 
by nature, is not forwarded.

There is a bunch of IPv6 ND issues for which you'd have to manually 
insert rules.

In short, after disabling traffic, you then have to start adding rules 
to get the various non-transport protocols operating properly.

Then you can start inserting/removing your transport oriented rules.

Are you running OVS-only switches, or do you also have non-OVS switches 
with which to contend?

Is your control channel in-band or out-of-band?  If in-band, you 
probably will have even more problems with which to contend.

> I hope that clarifies my intent a bit. Please let me know if I can provide any other information, and thanks again for your help.

Are you sure you want to design a network this way?  I think I see where 
you are going with this, but I think that road is littered with dead 
bodies.  That is, if your intention is to rely on a single instance of 
OpenDayLight to control all your switches, then you will have 
resiliency/redundancy/reliability issues.

There are a few hybrid solutions which make use of this style of 
mechanism (making the assumption that ALL switches are OVS controlled).

One style which comes to mind is the distributed controller style, which 
allows resiliency in the scenario of a central controller failure.  This 
scenario makes use of a two tier controller solution:  a) a controller 
on each switch maintaining local topology, link, and bandwidth state, 
with b) a central controller which has a global map of the network which 
the two tiers communicate iteratively for tuning traffic patterns.