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?
We're slowly getting into the swing of things for 2019, and starting the
year off with some minor fixes and dependency upgrades. Hoping to have more
for you in the next few weeks!
Please review the faucet installation documentation for a list of the
different methods of installing faucet here:
Highlights for this release include:
- Fix newly added ports not working after config reload
- Document running hardware tests from VMware controller host not
- Tests should fail faster if hardware test environment is not correct
- Upgrade Sphinx to 1.8.3.
- Upgrade pytype to 2018.12.21.