That's great. I'll extend it by adding two custom TLVs for send/receive
timestamps (or IDs).
Each outgoing LLDP will carry the current timestamp of the sender and the
timestamp in the last received LLDP. So that each Valve can independently
detect if a remote end and connectivity to it are working.
On Thu, Mar 8, 2018 at 5:37 PM Josh Bailey <joshb(a)google.com> wrote:
Following this up, I went and implemented my LLDP
protocol format proposal.
You can now enable LLDP reception selectively on ports, and FAUCET can
send its DPID as a LLDP org-specific TLV (see below for output from one of
the stacking tests). The code runs as part of the standard stacking
The LLDP probe packets are safe - they won't be forwarded by compliant
non-SDN elements and use the standard protocol format (they have also been
tested a handful of Juniper and Cisco switches) - and they are extensible -
we can add other org TLVs as needed without needing a custom protocol. For
example, we can add an authenticator TLV so that connectivity probes can't
At the moment, the probes are sent and received but no action is taken
(ie. we do not look for a cabling mismatch, and we do not consider missing
LLDP as a sign of anything like unidirectional link failure). However now
that the data are there we can have the control plane take any appropriate
Mar 08 17:04:15 faucet.valve INFO DPID 249473827 (0xedeab23) LLDP
len=2568), PortDescription(len=18,tlv_info=b'to faucet-1 port
On Tue, Jan 30, 2018 at 1:36 PM Josh Bailey <joshb(a)google.com> wrote:
It will be extremely valuable to have an active verification scheme, this
will be the foundation of all kinds of useful things.
I am against a custom ethertype/reserved IP addresses, because there may
be unforeseen forwarding behavior from non-SDN elements.
I suggest extending an existing protocol, such as LLDP. This has
predictable and well understood behavior (including switches and routers
will explicitly discard packets and not flood them which is extremely
desirable behavior to leverage). LLDP is extensible in that we can add TLVs
at any time, without breaking non-SDN devices, and allows to add features
like authentication later in a backward compatible way.
It would be good also to explicitly separate your design of algorithm,
from implementation of the algorithm.
I suggest as a next step, developing your algorithm a bit further in how
it would behave in various loss/loop scenarios, and what each node in the
network should do when it locally, etc.
On Tue, Jan 30, 2018 at 1:19 PM, Jonathan Miller <millerjona1(a)myvuw.ac.nz
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
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
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
Define a new ethernet type for our protocol, and use FAUCET_MAC for
What does everyone think about this?
Faucet-dev mailing list
Faucet-dev mailing list