Matthias Radestock
b9be18c386
set up masquerading as part of 'weave launch'
...
thus simplifying external access
2014-08-30 14:25:00 +01:00
Matthias Radestock
038d5c4f80
cosmetic
2014-08-30 11:46:03 +01:00
Matthias Radestock
86f993a1e8
cosmetic
2014-08-30 11:45:29 +01:00
Matthias Radestock
53f06c07a5
document external service access
2014-08-30 11:44:03 +01:00
Matthias Radestock
2e73fbb797
link to architecture documentation
2014-08-30 10:06:12 +01:00
Matthias Radestock
98257d0df6
switch to ubuntu image for examples
...
It comes with more stuff pre-installed, such as 'nc', so makes
experimentation just a little more convenient.
2014-08-30 09:59:13 +01:00
Matthias Radestock
5b6dc2d762
(slightly) faster pmtu discovery
...
Issues with the previous scheme...
When we have just encountered an EMSGSIZE, the odds of encountering
another one straight away, when attemtping to send a verification
packet with the lower mtu, are slim, since for a new, lower mtu to be
set some packet must have made it further then the one that triggered
the icmp3.4 that gave rise to the EMSGSIZE, and we must have received
the resulting icmp3.4. All of which takes time.
Also, sending a bunch of udp packets in rapid succession is not a
great way to improve their chances of making it through to the other
peer, since they could easily all get dropped by a single congestion
event or other network glitch.
Now we send a single verification packet, wait for a short while, and
if we don't get a response then we send another one, wait for longer
period (2x), etc, until some upper bound is reached, at which point we
lower the pmtu and start the verification process again (same as
currently happens).
We are now also calling flush() to send the verification packet, just
as we do for ordinary packets. This makes for shorter code, consistent
error handling, and introduces a nice little recursion :)
2014-08-29 19:15:18 +01:00
Matthias Radestock
3107aba53f
unbreak script
...
I have no idea why this matters
2014-08-29 17:40:38 +01:00
Matthias Radestock
d0d8949f72
make 'weave <unknown_command>' a no-op
2014-08-29 16:20:41 +01:00
Matthias Radestock
51a33929ea
remove unused var
2014-08-29 16:17:10 +01:00
Matthias Radestock
2c88710d62
we only need the bridge address when launching weave
2014-08-29 16:16:16 +01:00
Matthias Radestock
180c142964
move the most important check first
2014-08-29 16:12:44 +01:00
Matthias Radestock
d8cc45c650
fix weave arg count check
2014-08-29 16:10:29 +01:00
Matthias Radestock
ef9dbcb854
oops, make weave usage output match the command
2014-08-29 15:22:19 +01:00
Matthias Radestock
02f39f17f9
grrr
2014-08-29 14:27:19 +01:00
Matthias Radestock
81e8a9b987
cosmetic
2014-08-29 11:07:45 +01:00
rade
b3807b7c41
Merge pull request #16 from bboreham/14_run_in_boot2docker
...
make weave work with boot2docker
2014-08-29 10:57:32 +01:00
Bryan Boreham
4008c26351
Merge branch 'master' into 14_run_in_boot2docker
...
Removed small change from README.md
2014-08-29 09:53:47 +01:00
Matthias Radestock
c299cda859
remove more shades of security daftness
2014-08-28 22:09:13 +01:00
Matthias Radestock
e93dbde9e0
note that building weave requires go
2014-08-28 21:47:36 +01:00
Matthias Radestock
5d59f69228
explain that weave security isn't as daft as it may first appear
2014-08-28 21:30:02 +01:00
Matthias Radestock
f185c3ebb2
explain different roles of weave and docker port mapping
2014-08-28 19:45:11 +01:00
Bryan Boreham
ef80218629
Mention that we need Go dev tools to build weave
2014-08-28 17:45:10 +01:00
Bryan Boreham
5908df4f17
added Boot2Docker instructions, and simplified the message when ethtool is missing
2014-08-28 17:41:22 +01:00
Bryan Boreham
dced4e3d6f
add a test to see whether ethtool is available before trying to run it
2014-08-28 17:20:17 +01:00
Matthias Radestock
9924f420e5
banish bashism
2014-08-28 16:18:30 +01:00
Matthias Radestock
753af453ef
fix off-by-14 error in fragmentation
...
This was harmless since it simply meant our fragments were not as long
as they could be.
2014-08-28 14:17:00 +01:00
Matthias Radestock
0059f0cb49
cosmetic
2014-08-28 12:14:08 +01:00
Matthias Radestock
1a51ee8807
explain rationale for accounting for EthernetOverhead
2014-08-28 11:49:00 +01:00
Matthias Radestock
dbf19b6910
tiny refactor for consistency
2014-08-28 07:53:05 +01:00
Matthias Radestock
59eab28982
tyop
2014-08-28 07:51:56 +01:00
Matthias Radestock
bbfbc55078
cosmetic
2014-08-28 07:19:12 +01:00
Matthias Radestock
eb5d6f0d89
refactor: extract Forwarder
2014-08-27 23:31:37 +01:00
Matthias Radestock
4710a59ac8
calculate an initial effectivePMTU
...
That way as soon as the forwarder is live we have a sensible value
2014-08-27 21:40:16 +01:00
Matthias Radestock
41d3a6dc7c
log the *effective* pmtu when dropping frames
...
since that is more relevant
2014-08-27 21:38:18 +01:00
Matthias Radestock
7ccb361873
cosmetic
2014-08-27 21:37:46 +01:00
Matthias Radestock
6cec7a036c
refactor: yet more clarity on naming around pmtu
2014-08-27 17:55:43 +01:00
Matthias Radestock
f5e3450f0c
refactor: clear distinction between actual and effective pmtu
2014-08-27 17:27:14 +01:00
Matthias Radestock
b350924a63
refactor: remove unused field
2014-08-27 16:33:21 +01:00
Matthias Radestock
a6eea3405a
comment
2014-08-27 15:24:10 +01:00
Matthias Radestock
2a3256805f
tiny refactor: rename, move
2014-08-26 21:28:40 +01:00
Matthias Radestock
6f30cf2daf
8 is better than 10
...
It's quite common for the real pmtu to be 8 less than what was
advertised.
2014-08-26 21:11:24 +01:00
Matthias Radestock
c5d39fd5bf
drop maxpayload in conjunction with clientPMTU
...
Seems odd to do the latter w/o the former. And wrong.
2014-08-26 21:09:23 +01:00
Matthias Radestock
c6a796675d
pay attention to EMSGSIZE errors when sending pmtu verification packets
...
and drop the pmtu accordingly
This way, when we actually *do* get pmtu info from the network/kernel
we can discover the correct pmtu much more quickly. Especially in the
absence of other traffic, forwarding of which was previously the only
place where we'd check for EMSGSIZE.
Fixes #12
2014-08-26 21:05:13 +01:00
Matthias Radestock
fa5a5f46b4
usability: check that script is being run as root
...
so we can display a nicer error if not
2014-08-26 13:40:09 +01:00
Matthias Radestock
9c5603ebe7
add Troubleshooting section
2014-08-26 12:55:13 +01:00
Matthias Radestock
7e90c73d97
cosmetic: break overlong line
2014-08-26 11:57:01 +01:00
Matthias Radestock
e057799e0c
add some basic error handling to 'weave' script
2014-08-26 11:54:01 +01:00
Matthias Radestock
b35f83f132
explain that we need docker (yes, really)
...
and switch from 'curl' to 'wget' for installing weave, since the
latter is more widely installed. Also, make root use during that more
explicit.
2014-08-26 11:24:47 +01:00
Matthias Radestock
565856eaba
run weave in privileged container
...
...since on selinux (and possibly others) we encounter a "bind:
permission denied" error instead, most likely because weave is
attempting to bind a raw ip socket, which is a restricted operation on
those systems.
Fixes #7
2014-08-26 10:27:47 +01:00
Matthias Radestock