Fixes 3675
It is possible for ipsec.InitSARemote to be called after ipsec.Destroy.
If an xfrm policy for that source/destination pair exists it will be
updated to the SPI from the Destroyed connection causing IPSEC to stop
working.
from transient errors (heartbeast misses). In case of transient
errors OverlayForwarder is marked to be unhealty. When overlay forwarder
is unhealty its hept on hold so chooseBest() will skip selecting the forwrder
Once OverlayForwarder is considered healthy run chooseBest() again so the
forwarder can be selected if its the best forwarder
Fixes#1737
The change makes "weave expose" to call the "/expose" HTTP
endpoint implemented in router which exposes the bridge.
Such architectural change required as we need to know whether NPC is
enabled when exposing the bridge and weaver knows this fact the best.
Unfortunately, this change makes impossible to "weave expose"
when weaver is not running.
It is possible to receive FastDatapathCryptoInitSARemote control plane
message before Confirm'ing a connection. In such case, resetting
heartbeatTimer leads to null pointer dereference, as the timer is
initialized during Confirm'ation.
In this situation, skipping the reset is non-harmful, because
Confirm'ing will reset it.
NB: the reset to 0 should only happen after establishing the connection
on both ends.
Otherwise, we risk to lose peer list when any failure happens after
the creation but before storing the list and as a consequence,
the weave container gets restarted.
Added log lines for packets that we will broadcast;
Added log lines for flows we don't know how to handle;
Moved the line for when we expect to insert a flow down to the miss-handler;
Packets handled by the bridge already have their own logging via --pktdebug
The tracker's HandleUpdate method is called by the ring update routines.
In addition, we add a dummy overlay for AWSVPC to make `weave (status|
report)` to produce reasonable reports which includes AWS hosts
connection state.
The nil FlowOp check in collectFlowOps was not addressed with the
introduction of DiscardingFlowOp. This meant that DiscardingFlowOps
produced in the router core would get handled by fastdp as if they were
foreign FlowOps, preventing flow creation and so leading to unwarranted
ODP misses.
To fix this, collectFlowOps cannot simply eliminate FlowOps for which
Discards() is true, because it's true for odpFlowKeyFlowOp. So the
Discards() case has to be handled in FastDatapath send().
Reworked interface to router so we split setting up the initial list
from beginning to make connections - we shouldn't do that until
after router.Start().
Bryan Boreham