diff --git a/README.md b/README.md index 1d067f5a..89e51691 100644 --- a/README.md +++ b/README.md @@ -51,7 +51,7 @@ two containers, one on each host. On `$HOST1` run (as root) host1# weave launch - host1# C=$(weave run 10.0.1.1/24 -t -i ubuntu) + host1# C=$(weave run 10.2.1.1/24 -t -i ubuntu) The first line starts the weave router, in a container. This needs to be done once on each host. The required docker image for the weave @@ -83,7 +83,7 @@ addresses must, of course, be unique. We repeat similar steps on `$HOST2`... host2# weave launch $HOST1 - host2# C=$(weave run 10.0.1.2/24 -t -i ubuntu) + host2# C=$(weave run 10.2.1.2/24 -t -i ubuntu) The only difference, apart from the choice of IP address for the application container, is that we tell our weave that it should peer @@ -105,18 +105,18 @@ can talk to each other... On `$HOST1`... host1# docker attach $C - root@28841bd02eff:/# ping -c 1 -q 10.0.1.2 - PING 10.0.1.2 (10.0.1.2): 48 data bytes - --- 10.0.1.2 ping statistics --- + root@28841bd02eff:/# ping -c 1 -q 10.2.1.2 + PING 10.2.1.2 (10.2.1.2): 48 data bytes + --- 10.2.1.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.048/1.048/1.048/0.000 ms Similarly, on `$HOST2`... host2# docker attach $C - root@f76829496120:/# ping -c 1 -q 10.0.1.1 - PING 10.0.1.1 (10.0.1.1): 48 data bytes - --- 10.0.1.1 ping statistics --- + root@f76829496120:/# ping -c 1 -q 10.2.1.1 + PING 10.2.1.1 (10.2.1.1): 48 data bytes + --- 10.2.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms diff --git a/nameserver/http_test.go b/nameserver/http_test.go index 44f3ba8f..fd613861 100644 --- a/nameserver/http_test.go +++ b/nameserver/http_test.go @@ -23,7 +23,7 @@ func TestHttp(t *testing.T) { containerID = "deadbeef" testDomain = "weave.local." successTestName = "test1." + testDomain - testAddr1 = "10.0.2.1/24" + testAddr1 = "10.2.2.1/24" dockerIP = "9.8.7.6" ) diff --git a/nameserver/mdns_server_test.go b/nameserver/mdns_server_test.go index bd7da6dc..bd096e24 100644 --- a/nameserver/mdns_server_test.go +++ b/nameserver/mdns_server_test.go @@ -13,8 +13,8 @@ import ( var ( containerID = "deadbeef" testName = "test.weave.local." - testAddr1 = "10.0.2.1/24" - testInAddr1 = "1.2.0.10.in-addr.arpa." + testAddr1 = "10.2.2.1/24" + testInAddr1 = "1.2.2.10.in-addr.arpa." ) func sendQuery(name string, querytype uint16) error { diff --git a/nameserver/server_test.go b/nameserver/server_test.go index 9fa9d302..10c4445c 100644 --- a/nameserver/server_test.go +++ b/nameserver/server_test.go @@ -12,7 +12,7 @@ import ( ) const ( - testRDNSsuccess = "1.2.0.10.in-addr.arpa." + testRDNSsuccess = "1.2.2.10.in-addr.arpa." testRDNSfail = "4.3.2.1.in-addr.arpa." testRDNSnonlocal = "8.8.8.8.in-addr.arpa." testPort = 17625 @@ -23,7 +23,7 @@ func TestUDPDNSServer(t *testing.T) { successTestName = "test1.weave.local." failTestName = "test2.weave.local." nonLocalName = "weave.works." - testAddr1 = "10.0.2.1" + testAddr1 = "10.2.2.1" ) testCIDR1 := testAddr1 + "/24" diff --git a/nameserver/zone_test.go b/nameserver/zone_test.go index ef242ddb..c3d03f2f 100644 --- a/nameserver/zone_test.go +++ b/nameserver/zone_test.go @@ -11,7 +11,7 @@ func TestZone(t *testing.T) { containerID = "deadbeef" otherContainerID = "cowjuice" successTestName = "test1.weave." - testAddr1 = "10.0.2.1/24" + testAddr1 = "10.2.2.1/24" ) var zone = new(ZoneDb) @@ -21,9 +21,9 @@ func TestZone(t *testing.T) { wt.AssertNoErr(t, err) // Add a few more records to make the job harder - err = zone.AddRecord("abcdef0123", "adummy.weave.", net.ParseIP("10.0.0.1")) + err = zone.AddRecord("abcdef0123", "adummy.weave.", net.ParseIP("10.2.0.1")) wt.AssertNoErr(t, err) - err = zone.AddRecord("0123abcdef", "zdummy.weave.", net.ParseIP("10.0.0.2")) + err = zone.AddRecord("0123abcdef", "zdummy.weave.", net.ParseIP("10.2.0.2")) wt.AssertNoErr(t, err) // Check that the address is now there. @@ -35,7 +35,7 @@ func TestZone(t *testing.T) { } // See if we can find the address by IP. - foundName, err := zone.LookupInaddr("1.2.0.10.in-addr.arpa.") + foundName, err := zone.LookupInaddr("1.2.2.10.in-addr.arpa.") wt.AssertNoErr(t, err) if foundName != successTestName { @@ -69,7 +69,7 @@ func TestDeleteFor(t *testing.T) { var ( id = "foobar" name = "foo.weave." - addr1 = "10.1.2.3/24" + addr1 = "10.2.2.3/24" addr2 = "10.2.7.8/24" ) zone := new(ZoneDb) diff --git a/site/boot2docker.md b/site/boot2docker.md index 6e7eeca2..afb93f31 100644 --- a/site/boot2docker.md +++ b/site/boot2docker.md @@ -23,7 +23,7 @@ example above, the 'launch' command would be run like this: and the 'run' command like this: - host1# C=$(boot2docker ssh "sudo ./weave run 10.0.1.1/24 -t -i ubuntu") + host1# C=$(boot2docker ssh "sudo ./weave run 10.2.1.1/24 -t -i ubuntu") For more information about how to access services running in Boot2Docker from the host or other machines (i.e. outside of the weave diff --git a/site/features.md b/site/features.md index b818e732..cd62ba75 100644 --- a/site/features.md +++ b/site/features.md @@ -37,14 +37,14 @@ container on `$HOST1` we can start a netcat "service" with and then connect to it from the container on `$HOST2` with - root@f76829496120:/# echo 'Hello, world.' | nc 10.0.1.1 4422 + root@f76829496120:/# echo 'Hello, world.' | nc 10.2.1.1 4422 Note that *any* protocol is supported. Doesn't even have to be over TCP/IP, e.g. a netcat UDP service would be run with root@28841bd02eff:/# nc -lu -p 5533 - root@f76829496120:/# echo 'Hello, world.' | nc -u 10.0.1.1 5533 + root@f76829496120:/# echo 'Hello, world.' | nc -u 10.2.1.1 5533 We can deploy the entire arsenal of standard network tools and applications, developed over decades, to configure, secure, monitor, @@ -63,28 +63,28 @@ To accomplish that, we assign each application a different subnet. So, in the above example, if we wanted to add another application similar to, but isolated from, our first, we'd launch the containers with... - host1# D=$(weave run 10.0.2.1/24 -t -i ubuntu) - host2# D=$(weave run 10.0.2.2/24 -t -i ubuntu) + host1# D=$(weave run 10.2.2.1/24 -t -i ubuntu) + host2# D=$(weave run 10.2.2.2/24 -t -i ubuntu) A quick 'ping' test in the containers confirms that they can talk to each other but not the containers of our first application... host1# docker attach $D - root@da50502598d5:/# ping -c 1 -q 10.0.2.2 - PING 10.0.2.2 (10.0.2.2): 48 data bytes - --- 10.0.2.2 ping statistics --- + root@da50502598d5:/# ping -c 1 -q 10.2.2.2 + PING 10.2.2.2 (10.2.2.2): 48 data bytes + --- 10.2.2.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.562/0.562/0.562/0.000 ms - root@da50502598d5:/# ping -c 1 -q 10.0.1.1 - PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data. - --- 10.0.1.1 ping statistics --- + root@da50502598d5:/# ping -c 1 -q 10.2.1.1 + PING 10.2.1.1 (10.2.1.1) 56(84) bytes of data. + --- 10.2.1.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms - root@da50502598d5:/# ping -c 1 -q 10.0.1.2 - PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data. - --- 10.0.1.2 ping statistics --- + root@da50502598d5:/# ping -c 1 -q 10.2.1.2 + PING 10.2.1.2 (10.2.1.2) 56(84) bytes of data. + --- 10.2.1.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms This isolation-through-subnets scheme is an example of carrying over a @@ -110,23 +110,23 @@ to the weave network. To illustrate, we can achieve the same effect as the first example with host1# C=$(docker run -d -t -i ubuntu) - host1# weave attach 10.0.1.1/24 $C + host1# weave attach 10.2.1.1/24 $C There is a matching `weave detach` command: - host1# weave detach 10.0.1.1/24 $C + host1# weave detach 10.2.1.1/24 $C You can detach a container from one application network and attach it to another: - host1# weave detach 10.0.1.1/24 $C - host1# weave attach 10.0.2.1/24 $C + host1# weave detach 10.2.1.1/24 $C + host1# weave attach 10.2.2.1/24 $C or attach a container to multiple application networks, effectively sharing it between applications: - host1# weave attach 10.0.1.1/24 $C - host1# weave attach 10.0.2.1/24 $C + host1# weave attach 10.2.1.1/24 $C + host1# weave attach 10.2.2.1/24 $C ### Security @@ -158,18 +158,18 @@ anywhere. Let's say that in our example we want `$HOST2` to have access to the application containers. On `$HOST2` we run - host2# weave expose 10.0.1.102/24 + host2# weave expose 10.2.1.102/24 choosing an unused IP address in the application subnet. (There is a corresponding 'hide' command to revert this step.) Now - host2# ping 10.0.1.2 + host2# ping 10.2.1.2 will work. And, more interestingly, - host2# ping 10.0.1.1 + host2# ping 10.2.1.1 will work too, which is talking to a container that resides on `$HOST1`. @@ -186,18 +186,18 @@ a container on `$HOST1`, accessible to the outside world via `$HOST2`. First we need to expose the application network to `$HOST2`, as explained [above](#host-network-integration), i.e. - host2# weave expose 10.0.1.102/24 + host2# weave expose 10.2.1.102/24 Then we add a NAT rule to route from the outside world to the destination container service. host2# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \ - -j DNAT --to-destination 10.0.1.1:4422 + -j DNAT --to-destination 10.2.1.1:4422 Here we are assuming that the "outside world" is connecting to `$HOST2` via 'eth0'. We want TCP traffic to port 2211 on the external IPs to be routed to our 'nc' service, which is running on port 4422 in the -container with IP 10.0.1.1. +container with IP 10.2.1.1. With the above in place, we can connect to our 'nc' service from anywhere with @@ -226,23 +226,23 @@ First we need to expose the application network to the host, as explained [above](#host-network-integration), this time on `$HOST1`, i.e. - host1# weave expose 10.0.1.101/24 + host1# weave expose 10.2.1.101/24 Then we add a NAT rule to route from the above IP to the destination service. - host1# iptables -t nat -A PREROUTING -p tcp -d 10.0.1.101 --dport 3322 \ + host1# iptables -t nat -A PREROUTING -p tcp -d 10.2.1.101 --dport 3322 \ -j DNAT --to-destination $HOST3:2211 This allows any application container to reach the service by -connecting to 10.0.1.101:3322. So if `$HOST3` is indeed running a netcat +connecting to 10.2.1.101:3322. So if `$HOST3` is indeed running a netcat service on port 2211, e.g. host3# nc -lk -p 2211 then we can connect to it from our application container on `$HOST2` with - root@f76829496120:/# echo 'Hello, world.' | nc 10.0.1.101 3322 + root@f76829496120:/# echo 'Hello, world.' | nc 10.2.1.101 3322 The same command will work from any application container. @@ -251,7 +251,7 @@ The same command will work from any application container. Importing a service provides a degree of indirection that allows late and dynamic binding, similar to what can be achieved with a proxy. In our example, application containers are unaware that the service they -are accessing at `10.0.1.101:3322` is in fact residing on +are accessing at `10.2.1.101:3322` is in fact residing on `$HOST3:2211`. We can point application containers at another service location by changing the above NAT rule, without having to alter the applications themselves. @@ -273,14 +273,14 @@ In our example above, the netcat service on `$HOST3` is imported into weave via `$HOST1`. We can export it on `$HOST2` by first exposing the application network with - host2# weave expose 10.0.1.102/24 + host2# weave expose 10.2.1.102/24 and then adding a NAT rule which routes traffic from the `$HOST2` network (i.e. anything which can connect to `$HOST2`) to the service endpoint in the weave network host2# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \ - -j DNAT --to-destination 10.0.1.101:3322 + -j DNAT --to-destination 10.2.1.101:3322 Now any host on the same network as `$HOST2` can access the service with @@ -289,7 +289,7 @@ Now any host on the same network as `$HOST2` can access the service with Furthermore, as explained in [service-binding](#service-binding), we can dynamically alter the service locations without having to touch the applications that access them, e.g. we could move the example -netcat service to `$HOST4:2211` while retaining its 10.0.1.101:3322 +netcat service to `$HOST4:2211` while retaining its 10.2.1.101:3322 endpoint in the weave network. ### Multi-cloud networking diff --git a/site/troubleshooting.md b/site/troubleshooting.md index 616bd197..ef6f07af 100644 --- a/site/troubleshooting.md +++ b/site/troubleshooting.md @@ -130,9 +130,9 @@ Produces a list of all the containers running on this host that are connected to the weave network, like this: b07565b06c53 ae:e3:07:9c:8c:d4 - 5245643870f1 ce:15:34:a9:b5:6d 10.0.5.1/24 - e32a7d37a93a 7a:61:a2:49:4b:91 10.0.8.3/24 - caa1d4ee2570 ba:8c:b9:dc:e1:c9 10.0.1.1/24 10.0.2.1/24 + 5245643870f1 ce:15:34:a9:b5:6d 10.2.5.1/24 + e32a7d37a93a 7a:61:a2:49:4b:91 10.2.8.3/24 + caa1d4ee2570 ba:8c:b9:dc:e1:c9 10.2.1.1/24 10.2.2.1/24 On each line are the container ID, its MAC address, then the list of IP address/routing prefix length ([CIDR diff --git a/test/100_cross_hosts_test.sh b/test/100_cross_hosts_test.sh index c1ab6366..6073b581 100755 --- a/test/100_cross_hosts_test.sh +++ b/test/100_cross_hosts_test.sh @@ -2,8 +2,8 @@ . ./config.sh -C1=10.1.1.4 -C2=10.1.1.7 +C1=10.2.1.4 +C2=10.2.1.7 start_suite "Ping over cross-host weave network" diff --git a/test/110_encryption_test.sh b/test/110_encryption_test.sh index 84d339d7..9ac8a903 100755 --- a/test/110_encryption_test.sh +++ b/test/110_encryption_test.sh @@ -2,8 +2,8 @@ . ./config.sh -C1=10.1.1.4 -C2=10.1.1.7 +C1=10.2.1.4 +C2=10.2.1.7 start_suite "Ping over encrypted cross-host weave network" diff --git a/test/200_dns_test.sh b/test/200_dns_test.sh index 402bbc73..a918f699 100755 --- a/test/200_dns_test.sh +++ b/test/200_dns_test.sh @@ -9,7 +9,7 @@ start_suite "Resolve names on a single host" run_on $HOST1 sudo $WEAVE stop || true run_on $HOST1 sudo $WEAVE stop-dns || true -run_on $HOST1 sudo $WEAVE launch-dns 10.0.0.2/8 +run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 docker_on $HOST1 rm -f c1 c2 || true diff --git a/test/210_dns_multicast_test.sh b/test/210_dns_multicast_test.sh index 8afedfb3..2474c109 100755 --- a/test/210_dns_multicast_test.sh +++ b/test/210_dns_multicast_test.sh @@ -16,8 +16,8 @@ done run_on $HOST1 sudo $WEAVE launch run_on $HOST2 sudo $WEAVE launch $HOST1 -run_on $HOST1 sudo $WEAVE launch-dns 10.3.3.2/24 -debug -run_on $HOST2 sudo $WEAVE launch-dns 10.3.3.3/24 -debug +run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 -debug +run_on $HOST2 sudo $WEAVE launch-dns 10.2.254.2/24 -debug run_on $HOST2 sudo $WEAVE run $C2/24 -t --name=c2 -h seetwo.weave.local ubuntu run_on $HOST1 sudo $WEAVE run --with-dns $C1/24 --name=c1 -t aanand/docker-dnsutils /bin/sh diff --git a/test/220_dns_custom_test.sh b/test/220_dns_custom_test.sh index 29f27dfd..73c9d07e 100755 --- a/test/220_dns_custom_test.sh +++ b/test/220_dns_custom_test.sh @@ -9,7 +9,7 @@ start_suite "Resolve names in custom domain" run_on $HOST1 sudo $WEAVE stop || true run_on $HOST1 sudo $WEAVE stop-dns || true -run_on $HOST1 sudo $WEAVE launch-dns 10.0.0.2/8 --localDomain foo.bar. +run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 --localDomain foo.bar. docker_on $HOST1 rm -f c1 c2 || true diff --git a/test/300_fallback_dns_test.sh b/test/300_fallback_dns_test.sh index 808bc6e3..5a2ba74f 100755 --- a/test/300_fallback_dns_test.sh +++ b/test/300_fallback_dns_test.sh @@ -5,10 +5,10 @@ start_suite "Resolve a non-weave address" run_on $HOST1 sudo $WEAVE stop-dns || true -run_on $HOST1 sudo $WEAVE launch-dns 10.2.6.2 -debug +run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 -debug docker_on $HOST1 rm -f c1 || true -run_on $HOST1 sudo $WEAVE run --with-dns 10.1.1.5/24 --name=c1 -t aanand/docker-dnsutils /bin/sh +run_on $HOST1 sudo $WEAVE run --with-dns 10.2.1.5/24 --name=c1 -t aanand/docker-dnsutils /bin/sh ok=$(docker -H tcp://$HOST1:2375 exec -i c1 dig +short -t MX weave.works) assert "test -n \"$ok\" && echo pass" "pass" diff --git a/weave b/weave index 6f605380..af0763c9 100755 --- a/weave +++ b/weave @@ -84,7 +84,7 @@ is_cidr() { validate_cidr() { if ! is_cidr "$1" ; then echo "Invalid CIDR: $1" >&2 - echo "CIDR must of be of form /, e.g. 10.0.1.1/24" >&2 + echo "CIDR must of be of form /, e.g. 10.2.1.1/24" >&2 exit 1 fi } diff --git a/weavedns/README.md b/weavedns/README.md index 1c1874f5..e27f3b23 100644 --- a/weavedns/README.md +++ b/weavedns/README.md @@ -18,9 +18,9 @@ domain registers it in weaveDNS. For example: ```bash $ weave launch -$ weave launch-dns 10.1.254.1/24 -$ weave run 10.1.1.25/24 -ti -h pingme.weave.local ubuntu -$ shell1=$(weave run --with-dns 10.1.1.26/24 -ti -h ubuntu.weave.local ubuntu) +$ weave launch-dns 10.2.254.1/24 +$ weave run 10.2.1.25/24 -ti -h pingme.weave.local ubuntu +$ shell1=$(weave run --with-dns 10.2.1.26/24 -ti -h ubuntu.weave.local ubuntu) $ docker attach $shell1 # ping pingme @@ -31,8 +31,8 @@ Each weaveDNS container started with `launch-dns` needs to be given its own, unique, IP address, in a subnet that is a) common to all weaveDNS containers, b) disjoint from the application subnets, and c) not in use on any of the hosts. In our example the weaveDNS address is -in subnet 10.1.254.0/24 and the application containers are in -subnet 10.1.1.0/24. +in subnet 10.2.254.0/24 and the application containers are in +subnet 10.2.1.0/24. WeaveDNS containers can be stopped with `stop-dns`. @@ -67,7 +67,7 @@ hostnames across all sub-domains plus some external domains, you need behaviour. ```bash -weave run --with-dns 10.1.1.4/24 -ti \ +weave run --with-dns 10.2.1.4/24 -ti \ --dns-search=zone1.weave.local --dns-search=zone2.weave.local \ --dns-search=corp1.com --dns-search=corp2.com \ --dns-search=weave.local ubuntu @@ -95,7 +95,7 @@ supply a different bridge device, use the environment variable `DOCKER_BRIDGE`, e.g., ```bash -$ sudo DOCKER_BRIDGE=someother weave launch-dns 10.1.254.1/24 +$ sudo DOCKER_BRIDGE=someother weave launch-dns 10.2.254.1/24 ``` ### Supplying the DNS server @@ -107,7 +107,7 @@ make it use weaveDNS: ```bash $ docker_ip=$(docker inspect --format='{{ .NetworkSettings.Gateway }}' weavedns) $ shell2=$(docker run --dns=$docker_ip -ti ubuntu) -$ weave attach 10.1.1.27/24 $shell2 +$ weave attach 10.2.1.27/24 $shell2 ``` This isn't very useful unless the container is also attached to the @@ -142,7 +142,7 @@ its hostname, you can register it using the HTTP API: ```bash $ docker start $shell2 -$ curl -X PUT "http://$dns_ip:6785/name/$shell2/10.1.1.27" -d fqdn=shell2.weave.local +$ curl -X PUT "http://$dns_ip:6785/name/$shell2/10.2.1.27" -d fqdn=shell2.weave.local ``` ### Registering multiple containers with the same name @@ -163,7 +163,7 @@ containers that die. You can tell it not to, by adding `--watch=false` to the container args: ```bash -$ weave launch-dns 10.1.254.1/24 --watch=false +$ weave launch-dns 10.2.254.1/24 --watch=false ``` ### Unregistering @@ -174,7 +174,7 @@ API with e.g., `curl`: ```bash $ docker stop $shell2 $ dns_ip=$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' weavedns) -$ curl -X DELETE "http://$dns_ip:6785/name/$shell2/10.1.1.27" +$ curl -X DELETE "http://$dns_ip:6785/name/$shell2/10.2.1.27" ``` ## Present limitations