reweave/weave
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move detailed warning about rmpeer from FAQ to docs

Browse Source
This commit is contained in:
Bryan Boreham committed 2017-02-23 13:22:28 +00:00
1 parent 6ac1fef01d
commit f7ce16cba8
2 files changed
+22 -10
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

site/faq.md
+2 -8
View File
@@ -42,15 +42,9 @@ Yet another option is to expose a port from the container on host B and then con
<a name="duplicate-ip"></a>
**Q: Why am I seeing the same IP address assigned to two different containers on different hosts?**
Under normal circumstances, this should never happen, but it can occur if `weave forget` and `weave rmpeer` was run on more than one host.
Under normal circumstances, this should never happen, but it can occur if `weave rmpeer` was run on more than one host.
You cannot call `weave rmpeer` on more than one host. The address space, which was owned by the stale peer cannot be left dangling, and as a result it gets reassigned. In this instance, the address is reassigned to the peer on which `weave rmpeer` was run. Therefore, if you run `weave forget` and then `weave rmpeer` on more than one host at a time, it results in duplicate IPs on more than one host.
Once the peers detect the inconsistency, they log the error and drop the connection that supplied the inconsistent data. The rest of the peers will carry on with their view of the world, but the network will not function correctly.
Some peers may be able to communicate their claim to the others before they run `rmpeer` (i.e. it's a race), so what you can expect is a few cliques of peers that are still talking to each other, but repeatedly dropping attempted connections with peers in other cliques.
For more information on see [Allocating IP Addresses](/site/ipam.md) and also, [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md).
For more information see [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md).
<a name="dead-node"></a>
site/ipam/stop-remove-peers-ipam.md
+20 -2
View File
@@ -32,8 +32,26 @@ caught fire, you can go to one of the other hosts and run:
Weave Net takes all the IP address ranges owned by host3 and transfers
them to be owned by host1. The name "host3" is resolved via the
'nickname' feature of Weave Net, which defaults to the local host
name. Alternatively, you can supply a peer name as shown in `weave
status`.
name. Alternatively, you can supply a peer name as shown in `weave status`.
###<a name="caution-rmpeer"></a>Caution###
You cannot call `weave rmpeer` on more than one host. The address
space, which was owned by the stale peer cannot be left dangling, and
as a result it gets reassigned. In this instance, the address is
reassigned to the peer on which `weave rmpeer` was run. Therefore, if
you run `weave forget` and then `weave rmpeer` on more than one host
at a time, it results in duplicate IPs on more than one host.
Once the peers detect the inconsistency, they log the error and drop
the connection that supplied the inconsistent data. The rest of the
peers will carry on with their view of the world, but the network will
not function correctly.
Some peers may be able to communicate their claim to the others before
they run `rmpeer` (i.e. it's a race), so what you can expect is a few
cliques of peers that are still talking to each other, but repeatedly
dropping attempted connections with peers in other cliques.
**See Also**