From 25c70cfad6f2380106232283c1a84ab0dbd200e3 Mon Sep 17 00:00:00 2001 From: Bryan Boreham Date: Mon, 18 May 2015 17:26:24 +0100 Subject: [PATCH] Illustrate the usage of 'weave rmpeer' --- site/ipam.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/site/ipam.md b/site/ipam.md index 43693237..ba8a4cb4 100644 --- a/site/ipam.md +++ b/site/ipam.md @@ -94,3 +94,24 @@ peer, and as such should be used with extreme caution - if the rm'd peer had transferred some range of IP addresses to another peer but this is not known to the whole network, or if it later rejoins the Weave network, the same IP address may be allocated twice. + +Assuming we had started the three peers in the example earlier, and +host3 has caught fire, we can go to one of the other hosts and run: + + host1$ weave rmpeer host3 + +Weave will take all the IP address ranges owned by host3 and transfer +them to be owned by host1. The name "host3" is resolved via the +'nickname' feature of weave, which defaults to the local host +name. You can see the full set of range assignments in the output from +`weave status`, which will show the internal hex ID and nickname in +brackets, like this: + + Ring [10.2.1.1, 10.2.1.255) + 10.2.1.1 -> 96:e9:e2:2e:2d:bc (host1) (version: 3, free: 126) + 10.2.1.128 -> ea:84:25:9b:31:2e (host2) (version: 2, free: 64) + 10.2.1.192 -> ea:6c:21:09:cf:f0 (host3) (version: 1, free: 62) + +So, in our example, we could equivalently do: + + host1$ weave rmpeer ea:6c:21:09:cf:f0