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 any existing code in the _base class for listening to a
broadcast? Something parallel to "verify_tp_dst_notblocked" and
"verify_tp_dst_notblocked" -- but what I want to do is verify if broadcast
is blocked/notblocked. The only reference I found was to using broadcast
ping for switch learning, but nothing about listening for it.
The other broadcast-oriented tests I see are flow-matching tests, but that
is not really what I want because I want to know if broadcast gets through
somehow, not if there's a specific flow that's matched.
Just wanted to make sure I wasn't missing anything obvious before going off
and inventing something. Seems like I'd need to write something that
listens for a broadcast, pretty much the same way that tp_dst listens on a
server... correct me if there's an easier way!
A couple of things with the RabbitMQ adapter:
A) Should there be a Pi version of the rabbitmq adapter?
B) In ../rabbitmq/rabbit.py the environment variable 'FAUCET_EVENT_SOCK'
is a boolean value, while in Faucet it is the path to the UNIX socket. I
think rabbit should use the same path style.
If they are wanted i can push the changes I'm using locally.
I'm trying to build & run from HEAD and when I run the docker tests, I get
the error below. What I'm mainly trying to understand is why my docker
tests are failing while the Travis-CI build is (I assume) passing. For now,
I'm working around it with the -n option, but I was hoping to get to the
bottom of the discrepancy...
============ Running pytype analyzer ============
File "dp.py", line 260, in set_defaults: Access of attribute '__add__' on a
type that might be None [none-attr]
Do you need a type comment?