Stack flood rules are built based on the stack topo stated in the config
If the actual topo differs from the configured one, the flood rules
possibly won't work.
For example, Valve can't select a backup root if the primary one fails or
the selected root port hasn't run.
In order to support dynamic flood rules, I propose to (1) dynamically
update the stack topo,
and (2) support backup root DP and recalculate flood/unicast rules upon
This PR https://github.com/faucetsdn/faucet/pull/2055 is supposed to
The current flood algorithm may be used, but it will take into account the
actual topo when building rules.
Unicast rules may be updated upon topo change as well, or we could simply
delete them to re-learning hosts
(if we accept a temporarily unicast flooding).
We’re proposing a protocol whereby controllers actively detect connectivity to adjacent members of a stack.
This means they are either down, mis-cabled, or the adjacent switch has no active controller.
In this way we improve the resiliency of the stacking functionality in FAUCET.
Valves will send messages to adjacent members of the stack by sending packets out each port configured for stacking.
The neighbouring valve will respond if able. If no response is heard in time, we treat this as a failure, and record this in the log (for now).
Both request and reply messages contain a payload with the source and destination Valve (DPID, PortID).
If they don’t match, then we’ve detected a mis-cabled link.
E.g. A sends [PING A:1 -> B:1 SEQ=X] on port 1.
B(and only B) replies [PONG A:1 -> B:1 SEQ=X+1], if it receives this on port 1, otherwise it discards the message.
Additionally, if the adjacent controller has failed, we detect that as a failed link.
We don’t want our probing packets to be processed by the pipeline so we need to be able to distinguish them from ordinary traffic. Possible options:
* Use a specific port for our protocol, a reserved IP and FAUCET_MAC for destination
* Define a new ethernet type for our protocol, and use FAUCET_MAC for destination
What does everyone think about this?
Is there an easy/recommended way of turning off port randomization for
integration tests? Trying to do some differential debugging and it would be
a bit easier if the port #s were stable and consistent for comparison
I'm working through some flow optimizations and tests, and I'm still
getting confused as to the expected/desired behavior of a Faucet stack when
loop_protect_external is set.
I put together this simple stack diagram
with a few options for desired output behavior, just wondering which one is
correct... or, if none of them is correct, what is the correct answer?
A few bug fixes in there this week. Hopefully the final release before
faucetcon, looking forward to seeing everyone there!
As always, to install faucet review the installation documentation here:
Highlights for this release include:
- Allow tuning of TFM autosizer (port_table_scale_factor), fix override
of table sizes.
- Handle a non-reflected stack degraded to a string
- Fix test for LACP passthrough
- Relax timers for DPs that do not support idle/hard timers < 10s