Thanks. For 1, the current code already sends DP ID/port ID in the probe. Do you propose to use this to implement down-after-count? If so I imagine this should be a relatively small change - keen to see that.

For 2 - I don't follow how the mapping works. Would you be able to summarize how the mapping is used with a simple topology (say, one root switch and one non-root switch)? ie. packet comes in on edge, packet is compared with something, etc.

QinQ would be very convenient, unfortunately there is not widespread support for it. In the case where you replace the destination address, how do you account for different kinds of broadcasts/multicasts/a flooded unicast?

On Mon, May 21, 2018 at 8:05 AM Truong Huu Trung <> wrote:
Two protocols being proposed as ways towards making the stack failure tolerance. Currently, the root switch or a link down can break broadcast and unicast in the stack.

1. probing to discover a physical link or a valve failure:
by periodically sending probe packets via all physical stack links. Missing e.g. 3 consecutive packets implies link or peer down. With multiple stack links between switches, all links down means peer down.
This can be implemented by extending the current LLDP beacon. By including dp_id, port_id to the probe, one can compare the received info with the config file to determine if miscabling has happened.

2. state propagation.
Two states that are important for broadcast and unicast calculation after a failure: mapping between a MAC and a switch, and link state.
When calculating unicast rules, we need mappings host-to-switch. Two possible ways for that: tagging (QinQ) or overloading dest MAC (actually replace broadcast MAC with unique MAC of the origin sw; switches will have rules to match and broadcast the packets to non-stack ports as normal).
For link state, some kind of gossip can be used.

I've have implemented some part of this. but really want to hear your comments to make it usable.

Faucet-dev mailing list