Weave sends all gossip down new connections. We do this so that new
peers learn about all gossip'ed information quickly, thus enabling
them to process subsequent incremental updates. In particular, for
topology gossip it ensures that the remote peer learns about all other
peers. This ensures that the incremental update, which is sent as a
result of the new connection getting established and which may
reference a number of other peers, can be processed.
So the intent really is to send all gossip to new peers. But what we
actually do is send it down every new connection. Not every new
connection is from a new peer. In fact most connections aren't. Hence
the current approach is wasteful.
To fix this we need a conservative detection of new peers, i.e. it is
preferable to have false positives. This contrasts with existing logic
in the handshake code. The criteria we use is whether our peer has a
unicast route to the other peer. That is only the case when there is a
continuos chain of symmetric, established connections. The
establishment of these connections should have triggered the sending
of all gossip to the other peer. So we don't need to send it ourself.
Fixes#454.
The most likely cause of failure is the container going away, in which.
case we don't need to clean up. And there are other points of possible
failure in the same category in attach(), so making sure we clean up the
container interface under all conditions is a broader issue.
When an IP address was reused by a new container, other containers
could experience delays of many seconds the first time they tried to
talk to that new container before successful communication would
occur. This delay came from three sources related to ARP cache
behaviour:
- The kernel would take a while to decide that an ARP mapping was
stale due to lack of positive evidence (due to the
base_reachable_time default of 30s)
- Even once an ARP mapping was considered stale, the kernel would wait
a few seconds before sending an ARP request, in the hope that a
higher layer (e.g. TCP) would confirm the ARP entry (due to the
delay_first_probe default of 5s)
- When the kernel sent out an ARP request to update a stale entry,
initial attempts would unicast the request to the old MAC address
before resorting to broadcast (due to the ucast_solicit default of
3)
This change reduces all these values, so that any delays
are a few seconds.
For most workloads, this should not greatly increase the amount
of ARP traffic, because communication via TCP is often sufficient
to confirm ARP entries. And one unicast ARP request is still sent
just in case.
Unfortunately, there's a fixed-but-only-recently bug in the kernel
that means that changing base_reachable_time can take a while to take
effect:
<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4bf6980dd0328530783fd657c776e3719b421d30>.
This means that a container will continue to use a long reachable_time
delay for the first few minutes of its life.
There were situations, such as deleting another connection as result
of it losing a tie-break, where lifecycle events of connections on the
local peer weren't logged.
Fixing that entails moving the logging closer to (i.e. right after)
the state change action. This in turn requires promotion of logging to
the Connection interface instead of it LocalConnection. Which in turn
requires a change from 'log' to 'Log', for consistency with other
interface methods.
Fixes#449.
Do not inject ICMP "fragmentation needed" for broadcast packets.
It's a contravention of RFC1122 and also breaks weave routing due to producing packets with broadcast addresses as the source.
Fixes#419.
* disable the default Vagrant shared folder, which we don't need
* install `bc` on the dev VM, since it's needed by the smoke tests
* expose the dev VM docker on TCP, for convenience
If forwarding of a broadcast frame resulted in a FrameTooBigError, we
would generate an ICMP "fragmentation needed" packet that contravened
RFC1122 on two counts: First, we should not produce a ICMP error
message in response to a broadcast/multicast packet. Secondly, we
should not produce an IP packet with a broadcast/multicast source IP
address. (It also gave an ethernet frame with a broadcast source MAC,
which probably contravenes some IEEE spec.)
So when RelayBroadcast gets a FrameTooBigError, it should just drop
the packet.
Futhermore, if we fail to relay a broadcast on one connection, that's
not a good reason to give up entirely - we can proceed to attempt to
relay on the other next hop connections. Errors other than
FrameTooBigError that propagated upwards were simply logged, so that
logging is moved down into RelayBroadcast.
- extract helper function
- use "lots and lots of MX records" instead of "lots of TXT records"
for testing large response
- calculate on the fly the number of records we need to generate a
large response
- don't hardcode "weave.works"
Improve the DNS server configuration mechanism. The new configuration
system includes the ability to specify a different domain name other
than ".weave.local".
Adam Harrison