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".
David Wragg