fix/add links to examples when referring to them

site/ipam/stop-remove-peers-ipam.md

@@ -22,8 +22,9 @@ peers but this is not known to the whole network, or if some of them
 later rejoin the Weave network, the same IP address may be allocated
 twice.
 
-Assume you had started the three peers in the example earlier, and
-then host3 caught fire, you can go to one of the other hosts and run:
+Assume you had started the three peers in the
+[overview example](/site/ipam/overview-init-ipam.md), and then host3
+caught fire, you can go to one of the other hosts and run:
 
     host1$ weave rmpeer host3
     524288 IPs taken over from host3

site/using-weave/host-network-integration.md

@@ -5,7 +5,7 @@ layout: default
 
 Weave application networks can be integrated with an external host network, establishing connectivity between the host and with application containers running anywhere.
 
-For example, returning to the [netcat example](/site/using-weave/intro-example.md), you’ve now decided that you need to have the application containers that are running on `$HOST2` accessible by other hosts and containers. 
+For example, returning to the [netcat example](/site/using-weave/deploying-applications.md), you’ve now decided that you need to have the application containers that are running on `$HOST2` accessible by other hosts and containers. 
 
 On `$HOST2` run:
 

site/using-weave/service-management.md

@@ -17,7 +17,7 @@ This section contains the following topics:
 
 Services running in containers on a Weave network can be made accessible to the outside world (and, more generally, to other networks) from any Weave host, regardless of where the service containers are located.
 
-Turning back to the netcat example, your netcat service, which is running in a container on `$HOST1`, needs to be accessible to the outside world via `$HOST2`.
+Turning back to the [netcat example](/site/using-weave/deploying-applications.md), say you want the netcat service, which is running in a container on `$HOST1`, to be accessible to the outside world via `$HOST2`.
 
 To do this, expose the application network to `$HOST2`, as explained in [Host Network Integration](/site/using-weave/host-network-integration.md) by running:
 
@@ -74,7 +74,7 @@ Note that you should be able to run this command 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. 
 
-Referring back to the netcat services example that is running on three hosts (as explained in Importing Services above), the application containers are completely unaware that the service they are accessing at `10.2.1.3:3322` actually resides on `$HOST3:2211`. 
+Referring back to the [netcat services example that is running on three hosts](#importing), the application containers are completely unaware that the service they are accessing at `10.2.1.3:3322` actually resides on `$HOST3:2211`. 
 
 You can point application containers to another service location by changing the above NAT rule, without altering the applications.
 

site/weavedns/load-balance-fault-weavedns.md

@@ -9,8 +9,10 @@ It is permissible to register multiple containers with the same name:
 weavedns returns all addresses, in a random order, for each request.
 This provides a basic load balancing capability.
 
-Returning to the earlier example, let us start an additional `pingme`
-container, this time on the 2nd host, and then run some ping tests...
+Expanding the
+[overview example](/site/weavedns/overview-using-weavedns.md), let us
+start an additional `pingme` container on a 2nd host, and then run
+some ping tests...
 
 ```bash
 host2$ weave launch $HOST1