EnsureBridge used to skip creation and initialization of the weave
bridge and friends if such existed. This caused problems when
EnsureBridge failed before completing all init steps and so, subsequent
weaver could not work without "weave reset".
This change makes EnsureBridge idempotent.
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(https://github.com/moby/moby/pull/28257) which makes containers
inaccessible from a remote host when the bridge is exposed.
The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.
The chain is a target of the rule "-t filter -A FORWARD -o weave".
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's sad because this changes a regular pattern into an irregular one,
which will create spurious diffs if more work is added at the end of
the function. Still, this is easier than fixing the lint runner to
ignore the report.
The fix ensures that if odp is not supported (usually due to
missing openvswitch, vxlan or vport-vxlan kernel modules),
weaver will create the pcap based bridge instead of crashing.
We don't get a very useful error object back from go-iptables and I
didn't feel like parsing the message, so just ignore all errors.
It would be racy to try to check if WEAVE-NPC existed before calling
NewChain.
Enabled hairpin mode on vethwe-bridge was one of the root causes
for installing looping flows in the fastdp mode.
Also, it confused the weave custom L2 bridge, as the bridge treats
a bounced back packet, e.g. ARP brodcast request, as a local one
(the case for "Captured a packet associated with remote host").
Martynas Pumputis