I got you.
Btw, what I propose is a generalization of the case where stack has only
In that topology, it will work with two controllers, but it doesn't with
more than two controllers.
On Mon, Jul 2, 2018 at 8:27 AM Josh Bailey <joshb(a)google.com> wrote:
We have deployed stacking at WAND and it already
responds to link failures
by reprogramming flows so the network still works (where link status can be
used), and it does support multiple controllers. There is also automated
testing in place to demonstrate this.
Responding to probe status would be a positive change, but it must be
accompanied by tests per our usual convention.
On Mon, Jul 2, 2018, 05:09 Truong Huu Trung <trungdtbk(a)gmail.com> wrote:
Currently, broacast (and unicast) rules are built
statically based on the
configured stack graph.
I'm implement some incremental changes to make it resilient and updated
based on the actual network state.
I just launched a PR#2125 <https://github.com/faucetsdn/faucet/pull/2125>
that updates the graph based on the link probe.
I suggest the following changes to the stack broadcast algorithm:
*1. A DP floods to local ports (none stack ports) only if it can't reach
to the root DP.*
2. Stack should use only links that have been probed to be working (not
the configured links).
3. Each time when the stack graph changes, a DP rebuilds flood rules (and
unicast rules if any).
I've already implemented this (it does not change the code much). There
is no automated test yet.
If you're ok, I'll proceed to the tests and make a PR for it.
That changes make the stack to react stack events. There are limitations
- There are a lot of more rules sent to switches during start up (many
stack links are up during this time)
- It works only if all DPs are controlled by the same Faucet. It's
because there is no mechanism to propagate events between Faucet yet.
- It does not deal with root failure.
Faucet-dev mailing list