Merge pull request #2889 from weaveworks/consistent-spacing-in-markdown-headings

Consisten spacing in Markdown headings
2017-04-10 13:35:37 +01:00
commit 1b7c386351
@@ -15,7 +15,7 @@ application containers.  CNI is supported by
 and 
 [others](https://github.com/containernetworking/cni#who-is-using-cni).

-###Installing the Weave Net CNI plugin
+### Installing the Weave Net CNI plugin

 If your machine has the directories normally used to host CNI plugins, 
 then the Weave Net CNI plugin is installed when you run `weave setup`.
@@ -29,7 +29,7 @@ Then run:

    weave setup

-####Launching Weave Net
+#### Launching Weave Net

 To create a network that spans multiple hosts, the Weave peers must be connected to each other.  
 This is accomplished by specifying the other hosts during `weave launch` or via
@@ -40,7 +40,7 @@ for a discussion on peer connections.

    weave launch <peer hosts>

-####Using the CNI network configuration file
+#### Using the CNI network configuration file

 All CNI plugins are configured by a JSON file in the directory
 `/etc/cni/net.d/`.  `weave setup` installs a minimal configuration
@@ -64,9 +64,9 @@ The following other fields in the spec are supported:
 - `ipam / subnet` - default is to use Weave's IPAM default subnet
 - `ipam / gateway` - default is to use the Weave bridge IP address (allocated by `weave expose`)

-###Using the Weave Net CNI plugin
+### Using the Weave Net CNI plugin

-####Configuring Kubernetes to use the CNI Plugin
+#### Configuring Kubernetes to use the CNI Plugin

 After you've launched Weave and peered your hosts, you can configure
 Kubernetes to use Weave, by adding the following options to the
@@ -79,7 +79,7 @@ for more details.

 Now, whenever Kubernetes starts a pod, it will be attached to the Weave network.

-####Configuring Mesos to use the CNI plugin
+#### Configuring Mesos to use the CNI plugin

 To use the CNI plugin, the Mesos Agent must be started with reference
 to the CNI configuration and binary directories:
@@ -105,7 +105,7 @@ connected to the weave network)"
 For more information, see the 
 [Mesos documentation](http://mesos.apache.org/documentation/cni/).

-###Caveats
+### Caveats

 - The Weave Net router container must be running for CNI to allocate addresses
 - The CNI plugin does not add entries to weaveDNS.
@@ -27,7 +27,7 @@ menu_order: 20

 For step-by-step instructions on how to use Weave Net, see [Using Weave Net](/site/using-weave.md).

-###<a name="virtual-ethernet-switch"></a>Virtual Ethernet Switch
+### <a name="virtual-ethernet-switch"></a>Virtual Ethernet Switch

 Weave Net creates a virtual network that connects Docker containers
 deployed across multiple hosts.
@@ -46,7 +46,7 @@ over Weave Net.
 To start using Weave Net, see [Installing Weave Net](/site/installing-weave.md) 
 and [Using Weave Net](/site/using-weave.md).

-###<a name="fast-data-path"></a>Fast Datapath
+### <a name="fast-data-path"></a>Fast Datapath

 Weave Net automatically chooses the fastest available method to 
 transport data between peers. The best performing of these 
@@ -55,7 +55,7 @@ transport data between peers. The best performing of these
 See [Using Fast Datapath](/site/using-weave/fastdp.md) and
 [How Fast Datapath Works](/site/how-it-works/fastdp-how-it-works.md).

-###<a name="docker"></a>Seamless Docker Integration (Weave Docker API Proxy)
+### <a name="docker"></a>Seamless Docker Integration (Weave Docker API Proxy)

 Weave Net includes a [Docker API Proxy](/site/weave-docker-api.md), which can be 
 used to start containers using the Docker [command-line interface](https://docs.docker.com/reference/commandline/cli/) or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/), and attach them to the Weave network before they begin execution.
@@ -73,7 +73,7 @@ policy, are re-attached to the Weave network by the `Weave Docker API Proxy`.
 See [Integrating Docker via the API Proxy](/site/weave-docker-api.md).


-###<a name="plugin"></a>Weave Network Docker Plugin
+### <a name="plugin"></a>Weave Network Docker Plugin

 Weave Net can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
 named `weave` is created by `weave launch`, which is used as follows:
@@ -88,14 +88,14 @@ when there are network connectivity problems.
 See [Integrating Docker via the Network Plugin](/site/plugin.md) for more details.


-###<a name="cniplugin"></a>Weave Network CNI Plugin
+### <a name="cniplugin"></a>Weave Network CNI Plugin

 Weave can be used as a plugin to systems that support the [Container Network Interface](https://github.com/appc/cni), such as Kubernetes and Mesosphere.

 See [Integrating Kubernetes and Mesos via the CNI Plugin](/site/cni-plugin.md) for more details.


-###<a name="addressing"></a>IP Address Management (IPAM)
+### <a name="addressing"></a>IP Address Management (IPAM)
 
 Containers are automatically allocated a unique IP address. To view the addresses allocated by Weave, run `weave ps`.

@@ -106,7 +106,7 @@ For a discussion on how Weave Net uses IPAM, see [Automatic IP Address Managemen
 [the basics of IP addressing](/site/how-it-works/ip-addresses.md) for an explanation of addressing and private networks. 


-###<a name="naming-and-discovery"></a>Naming and Discovery
+### <a name="naming-and-discovery"></a>Naming and Discovery
 
 Named containers are automatically registered in [weaveDNS](/site/weavedns.md), 
 and are discoverable by using standard, simple name lookups:
@@ -119,7 +119,7 @@ WeaveDNS also supports [load balancing](/site/weavedns/load-balance-fault-weaved

 See [Discovering Containers with WeaveDNS](/site/weavedns.md).
 
-###<a name="application-isolation"></a>Application Isolation
+### <a name="application-isolation"></a>Application Isolation

 A single Weave network can host multiple, isolated 
 applications, with each application's containers being able 
@@ -136,13 +136,13 @@ See [Isolating Applications](/site/using-weave/application-isolation.md)
 for information on how to use the isolation-through-subnets 
 technique with Weave Net.

-###<a name="network-policy"></a>Network Policy
+### <a name="network-policy"></a>Network Policy

 The Weave [Kubernetes Addon](/site/kube-addon.md) includes a network
 policy controller that implements [Kubernetes Network
 Policies](http://kubernetes.io/docs/user-guide/networkpolicies/).

-###<a name="dynamic-network-attachment"></a>Dynamic Network Attachment
+### <a name="dynamic-network-attachment"></a>Dynamic Network Attachment

 At times, you may not know the application network for a 
 given container in advance. In these cases, you can take 
@@ -153,7 +153,7 @@ See [Dynamically Attaching and Detaching Containers](/site/using-weave/dynamical
 for details. 


-###<a name="security"></a>Security
+### <a name="security"></a>Security

 In keeping with our ease-of-use philosophy, the cryptography 
 in Weave Net is intended to satisfy a particular user requirement: 
@@ -179,14 +179,14 @@ and, additionally in the case of encrypted fast datapath using [the cryptography
 For information on how to secure your Docker network connections, see [Securing Connections Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md) and for a more technical discussion on how Weave implements encryption see, [Weave Encryption](/site/how-it-works/encryption.md) and [How Weave Implements Encryption](/site/how-it-works/encryption-implementation.md).


-###<a name="host-network-integration"></a>Host Network Integration
+### <a name="host-network-integration"></a>Host Network Integration

 Weave Net application networks can be integrated with a host's network, and establish connectivity between the host and 
 application containers anywhere.

 See [Integrating with the Host Network](/site/using-weave/host-network-integration.md).

-###<a name="services"></a>Managing Services: Exporting, Importing, Binding and Routing
+### <a name="services"></a>Managing Services: Exporting, Importing, Binding and Routing
 
 * **Exporting Services** - Services running in containers on a Weave network can be made accessible to the outside world or to other networks.
 * **Importing Services** - Applications can run anywhere, and yet still be made accessible by specific application containers or services.
@@ -195,7 +195,7 @@ See [Integrating with the Host Network](/site/using-weave/host-network-integrati

 See [Managing Services - Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md) for instructions on how to manage services on a Weave container network. 

-###<a name="multi-cloud-networking"></a>Multi-Cloud Networking
+### <a name="multi-cloud-networking"></a>Multi-Cloud Networking

 Weave can network containers hosted in different cloud providers 
 or data centers. For example, you can run an application consisting 
@@ -206,7 +206,7 @@ of containers that run on [Google Compute Engine](https://cloud.google.com/compu
 See [Enabling Multi-Cloud networking and Muti-hop Routing](/site/using-weave/multi-cloud-multi-hop.md).


-###<a name="multi-hop-routing"></a>Multi-Hop Routing
+### <a name="multi-hop-routing"></a>Multi-Hop Routing

 A network of containers across more than two hosts can be established 
 even when there is only partial connectivity between the hosts. Weave Net
@@ -216,14 +216,14 @@ of connected hosts between them.
 See [Enabling Multi-Cloud networking and Multi-hop Routing](/site/using-weave/multi-cloud-multi-hop.md).


-###<a name="dynamic-topologies"></a>Dynamic Topologies
+### <a name="dynamic-topologies"></a>Dynamic Topologies

 Hosts can be added to or removed from a Weave network without stopping
 or reconfiguring the remaining hosts. See [Adding and Removing Hosts
 Dynamically.](/site/using-weave/finding-adding-hosts-dynamically.md)


-###<a name="container-mobility"></a>Container Mobility
+### <a name="container-mobility"></a>Container Mobility

 Containers can be moved between hosts without requiring any 
 reconfiguration or, in many cases, restarts of other containers. 
@@ -233,7 +233,7 @@ with the same IP address as it was given originally.
 See [Managing Services - Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md), in particular, Routing Services for more information on container mobility. 


-###<a name="fault-tolerance"></a>Fault Tolerance
+### <a name="fault-tolerance"></a>Fault Tolerance

 Weave Net peers continually exchange topology information, and 
 monitor and (re)establish network connections to other peers. 
@@ -13,7 +13,7 @@ This section describes some details of Weave Net's built-in



-####<a name="ephemeral-key"></a>Establishing the Ephemeral Session Key
+#### <a name="ephemeral-key"></a>Establishing the Ephemeral Session Key

 For every connection between peers, a fresh public/private key pair is
 created at both ends, using NaCl's `GenerateKey` function. The public
@@ -48,7 +48,7 @@ not be able to form valid ephemeral session keys.
 The same ephemeral session key is used for both TCP and UDP traffic
 between two peers.

-###<a name="csprng"></a> Key Generation and The Linux CSPRNG
+### <a name="csprng"></a> Key Generation and The Linux CSPRNG

 Generating fresh keys for every connection
 provides forward secrecy at the cost of placing a demand on the Linux
@@ -84,7 +84,7 @@ Weave Net's demand on `/dev/urandom` is causing you problems with blocking
 `/dev/random` reads, please get in touch with us - we'd love to hear
 about your use case.

-####<a name="tcp"></a>Encypting and Decrypting TCP Messages
+#### <a name="tcp"></a>Encypting and Decrypting TCP Messages

 TCP connection are only used to exchange topology information between
 peers, via a message-based protocol. Encryption of each message is
@@ -105,9 +105,9 @@ polarity. As a result the receiver will only be able to decrypt a
 message if it has the expected sequence number. This prevents replay
 attacks.

-####<a name="udp"></a>Encrypting and Decrypting UDP Packets
+#### <a name="udp"></a>Encrypting and Decrypting UDP Packets

-#####Sleeve
+##### Sleeve

 UDP connections carry captured traffic between peers. For a UDP packet
 sent between peers that are using crypto, the encapsulation looks as
@@ -181,7 +181,7 @@ contained in the set. The window spans at least 2^20 message sequence
 numbers, and hence any re-ordering between the most recent ~1 million
 messages is handled without dropping messages.

-#####Fast Datapath
+##### Fast Datapath

 Encryption in fastdp uses [the ESP protocol of IPsec](https://tools.ietf.org/html/rfc2406)
 in the transport mode. Each VXLAN packet is encrypted with
@@ -11,7 +11,7 @@ This section contains the following topics:
 * [What Happens When The Topology is Out of Date?](#out-of-date-topology)


-###<a name="topology"></a>Communicating Topology Among Peers
+### <a name="topology"></a>Communicating Topology Among Peers

 Topology messages capture which peers are connected to other peers. 
 Weave peers communicate their knowledge of the topology
@@ -49,7 +49,7 @@ improved update containing them is gossiped.
 If the update mentions a peer that the receiver does not know, then
 the entire update is ignored.

-####<a name="messages"></a>How Messages Are Formed
+#### <a name="messages"></a>How Messages Are Formed

 Every gossip message is structured as follows:

@@ -120,14 +120,14 @@ which the structure is:
    | Connection N: Established         |
    +-----------------------------------+

-####<a name="removing-peers"></a>Removing Peers
+#### <a name="removing-peers"></a>Removing Peers

 If a peer, after receiving a topology update, sees that another peer
 no longer has any connections within the network, it drops all
 knowledge of that second peer.


-####<a name="out-of-date-topology"></a>What Happens When The Topology is Out of Date?
+#### <a name="out-of-date-topology"></a>What Happens When The Topology is Out of Date?

 The propagation of topology changes to all peers is not instantaneous.
 Therefore, it is very possible for a node elsewhere in the network to have an
@@ -20,13 +20,13 @@ After your VM is setup with Docker Machine, Weave Net can be launched directly f

 With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Using Weave Net](/site/using-weave.md).

-###Quick Start Screencast
+### Quick Start Screencast

 <a href="https://youtu.be/kihQCCT1ykE" target="_blank">
  <img src="hello-screencast.png" alt="Click to watch the screencast" />
 </a>

-###Checkpoint
+### Checkpoint

 Weave Net [periodically contacts Weaveworks servers for available
 versions](https://github.com/weaveworks/go-checkpoint).  New versions
@@ -45,7 +45,7 @@ To disable this check, run the following before launching Weave Net:

    export CHECKPOINT_DISABLE=1

-###Guides for Specific Platforms
+### Guides for Specific Platforms

 CoreOS users see [here](/guides/networking-docker-containers-with-weave-on-coreos/) for an example of installing Weave using cloud-config.

@@ -9,52 +9,52 @@ Weave Net creates a virtual network that connects Docker containers across multi
 Services provided by application containers on the weave network can be exposed to the outside world, regardless of where they are running. Similarly, existing internal systems can be opened to accept connections from application containers irrespective of their location.


-##Why Weave?
+## Why Weave?

-###Hassle Free Configuration
+### Hassle Free Configuration

 Weave Net simplifies setting up a container network. Because containers on a Weave network use standard port numbers, (for example MySQL’s default is port 3306), managing microservices is straightforward. Every container can find the IP of any other container using a simple DNS query on the container's name, and it can also communicate directly without NAT, without using port mappings or complicated ambassador linking.  And best of all deploying a Weave container network requires zero changes to your application’s code. 

 ![Weave Net Encapsulation](weave-net-overview.png)

-###Service Discovery
+### Service Discovery

 Weave Net implements service discovery by providing a fast "micro DNS" server at each node. You simply name containers and everything 'just works', including load balancing across multiple containers with the same name.  

-###No External Cluster Store Required
+### No External Cluster Store Required

 All other Docker networking plugins, including Docker's own "Overlay" driver, require that you set up Docker with a cluster store – a central database like Consul or Zookeeper – before you can even use them. Besides being difficult to set up, maintain and manage, every Docker host must also be in constant contact with the cluster store: if you lose the connection, even temporarily, then you cannot start or stop any containers.

 Weave Net is bundled with a Docker Network plugin that doesn't require an external cluster store. You can get started right away and you can start and stop containers even when there are network connectivity problems.  
 For information about the Weave Docker Plugin, see [How The Weave Network Plugin Works](/site/plugin/plugin-how-it-works.md).

-###Operates in Partially Connected Networks
+### Operates in Partially Connected Networks

 Weave Net can forward traffic between nodes, and it works even if the mesh network is only partially connected.  This means that you can have a mix of legacy systems and containerized apps and still use Weave Net to keep everything in communication. 

-###Weave Net is Fast
+### Weave Net is Fast

 Weave Net automatically chooses the fastest path between two hosts, offering near native throughput and latency, all without your intervention.  

 See [How Fast Datapath Works](/site/using-weave/fastdp.md) for more information.

-###Network Operations Friendly
+### Network Operations Friendly

 Weave uses industry-standard VXLAN encapsulation between hosts. This means you can continue using your favorite packet analyzing tools, such as ‘Wireshark’ to inspect and troubleshoot protocols.

-###Weave Net is Secure
+### Weave Net is Secure

 Weave Net traverses firewalls without requiring a TCP add-on. You can encrypt your traffic, which allows you to connect to apps on hosts even across an untrusted network.  

-###Multicast Support
+### Multicast Support

 Multicast addressing and routing is fully supported in Weave Net. Data can be sent to one multicast address and it will be automatically broadcast to all of its recipients. 

-###NAT Traversal
+### NAT Traversal

 With Weave Net, deploy your applications - whether peer-to-peer file sharing, voice over IP or anything else - and take advantage of built-in NAT traversal. With Weave your app is portable, containerized and with its standardized approach to networking it gives you one less thing to worry about.

-###Run with Anything: Kubernetes, Mesos, Amazon ECS, ...
+### Run with Anything: Kubernetes, Mesos, Amazon ECS, ...

 Weave Net is a good choice if you want one tool for everything.  For example: In addition to Docker plugins, you can also use Weave as a Kubernetes plugin.  You can also use Weave with Amazon ECS or with Mesos and Marathon.  
 Refer to our Getting Started and Integration Guides for more information.
@@ -112,7 +112,7 @@ peers. This can be useful to add peers to an existing fixed cluster
 (for example in response to a scale-out event) without worrying about
 adjusting initial peer counts accordingly.

-####<a name="quorum"></a> `--ipalloc-init consensus=` and How Quorum is Achieved
+#### <a name="quorum"></a> `--ipalloc-init consensus=` and How Quorum is Achieved

 Normally it isn't a problem to over-estimate the value supplied to
 `--ipalloc-init consensus=`, but if you supply a number that is too
@@ -34,7 +34,7 @@ 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`.

-###<a name="caution-rmpeer"></a>Caution###
+### <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
@@ -13,7 +13,7 @@ The following topics are discussed:
 * [Changing Configuration Options](#configuration-options)


-##<a name="install"></a> Installation
+## <a name="install"></a> Installation

 Weave Net can be installed onto your CNI-enabled Kubernetes cluster
 with a single command:
@@ -64,7 +64,7 @@ to the YAML file for the [latest release](https://github.com/weaveworks/weave/re
 Historic versions are archived on our [GitHub release
 page](https://github.com/weaveworks/weave/releases).

-##<a name="kube-1.6-upgrade"></a> Upgrading Kubernetes to version 1.6
+## <a name="kube-1.6-upgrade"></a> Upgrading Kubernetes to version 1.6

 In version 1.6, Kubernetes has increased security, so we need to
 create a special service account to run Weave Net. This is done in
@@ -79,7 +79,7 @@ annotation to a field on the DaemonSet spec object.
 If you have edited the Weave Net DaemonSet from a previous release,
 you will need to re-make your changes against the new version.

-###<a name="daemon-sets"></a> Upgrading the Daemon Sets
+### <a name="daemon-sets"></a> Upgrading the Daemon Sets

 Kubernetes does not currently support rolling upgrades of daemon sets,
 and so you will need to perform the procedure manually:
@@ -91,7 +91,7 @@ and so you will need to perform the procedure manually:
  lose track of IP address range ownership, possibly leading to
  duplicate IP addresses if you then start a new copy of Weave Net.

-##<a name="npc"></a>Network Policy Controller
+## <a name="npc"></a>Network Policy Controller

 The addon also supports the [Kubernetes policy
 API](http://kubernetes.io/docs/user-guide/networkpolicies/) so that
@@ -109,7 +109,7 @@ definition](http://kubernetes.io/docs/api-reference/extensions/v1beta1/definitio
  all multicast traffic) by adding `--allow-mcast` as an argument to
  `weave-npc` in the YAML configuration.

-###<a name="blocked-connections"></a> Troubleshooting Blocked Connections
+### <a name="blocked-connections"></a> Troubleshooting Blocked Connections

 If you suspect that legitimate traffic is being blocked by the Weave Network Policy Controller, the first thing to do is check the `weave-npc` container's logs.

@@ -141,7 +141,7 @@ TCP connection from 10.32.0.7:56648 to 10.32.0.11:80 blocked by Weave NPC.
 UDP connection from 10.32.0.7:56648 to 10.32.0.11:80 blocked by Weave NPC.
 ```

-###<a name="configuration-options"></a> Changing Configuration Options
+### <a name="configuration-options"></a> Changing Configuration Options

 The default configuration settings can be changed by saving and editing the
 addon YAML before running `kubectl apply`. Additional arguments may be
@@ -18,18 +18,18 @@ The following concepts are described:
    * [Observers](#observers)
 * [Persistence](#persistence)

-##<a name="host"></a>Host
+## <a name="host"></a>Host

 For the purposes of this documentation a host is an
 installation of the Linux operating system that is running an
 instance of the Docker Engine. The host may be executing directly on bare
 hardware or inside a virtual machine.

-##<a name="peer"></a>Peer
+## <a name="peer"></a>Peer

 A peer is a running instance of Weave Net, typically one per host.

-##<a name="peer-name"></a>Peer Name
+## <a name="peer-name"></a>Peer Name

 Weave Net peers are identified by a 48-bit value formatted like an
 ethernet MAC address, for example, `01:23:45:67:89:ab`. The 'peer
@@ -66,14 +66,14 @@ The appropriate strategy for assigning peer names depends on the type
 and method of your particular deployment and is discussed in more
 detail below.

-##<a name="peer-discovery"></a>Peer Discovery
+## <a name="peer-discovery"></a>Peer Discovery

 Peer discovery is a mechanism that allows peers to learn about new
 Weave Net hosts from existing peers without being explicitly told. Peer
 discovery is
 [enabled by default](/site/using-weave/finding-adding-hosts-dynamically.md).

-##<a name="network-partition"></a>Network Partition
+## <a name="network-partition"></a>Network Partition

 A network partition is a transient condition whereby some arbitrary
 subsets of peers are unable to communicate with each other for the
@@ -82,7 +82,7 @@ optic line severed. Weave Net is designed to allow peers and their
 containers to make maximum safe progress under conditions of
 partition, healing automatically once the partition is over.

-##<a name="ip-address-manager"></a>IP Address Manager (IPAM)
+## <a name="ip-address-manager"></a>IP Address Manager (IPAM)

 [IPAM](/site/ipam.md) is the subsystem responsible for dividing up a
 large contiguous block of IP addresses (known as the IP allocation
@@ -116,7 +116,7 @@ scenarios:

 * [Uniform Dynamic Cluster](/site/operational-guide/uniform-dynamic-cluster.md)

-###<a name="consensus"></a>Consensus
+### <a name="consensus"></a>Consensus

 Alternatively, when a new network is formed for the first time, peers
 can be configured to co-ordinate amongst themselves to automatically
@@ -132,7 +132,7 @@ scenarios:
 * [Interactive Deployment](/site/operational-guide/interactive.md)
 * [Uniform Fixed Cluster](/site/operational-guide/uniform-fixed-cluster.md)

-###<a name="observers"></a>Observers
+### <a name="observers"></a>Observers

 Finally, an option is provided to start a peer as an _observer_. Such
 peers do not require a seed peer name list or an initial peer
@@ -146,7 +146,7 @@ scenarios:

 * [Autoscaling](/site/operational-guide/autoscaling.md)

-##<a name="persistence"></a>Persistence
+## <a name="persistence"></a>Persistence

 Certain information is remembered between launches of Weave Net (for
 example across reboots):
@@ -12,7 +12,7 @@ The following administrative tasks are discussed:
 * [Resetting Persisted Data](#reset)


-##<a name="start-on-boot"></a>Configuring Weave Net to Start Automatically on Boot
+## <a name="start-on-boot"></a>Configuring Weave Net to Start Automatically on Boot

 `weave launch` runs all of Weave Net's containers with a Docker restart
 policy set to `always`.  If you have launched Weave Net manually at least
@@ -23,7 +23,7 @@ If you are aiming for a non-interactive installation, use
 [systemd](/site/installing-weave/systemd.md) or a similar init system to
 launch Weave using the `--no-restart` flag after Docker has been started.

-##<a name="detect-reclaim-ipam"></a>Detecting and Reclaiming Lost IP Address Space
+## <a name="detect-reclaim-ipam"></a>Detecting and Reclaiming Lost IP Address Space

 The recommended method of removing a peer is to run `weave reset` on that
 peer before the underlying host is decommissioned or repurposed. This
@@ -56,7 +56,7 @@ range managed by peer and also identifies the names of unreachable peers. If you
 that the peer is truly gone, rather than temporarily unreachable due to a
 partition, you can reclaim their space manually.

-###<a name="manually-reclaim-address-space"></a>Manually Reclaiming Address Space
+### <a name="manually-reclaim-address-space"></a>Manually Reclaiming Address Space

 When a peer dies unexpectedly the remaining peers will consider its
 address space to be unavailable even after it has remained unreachable
@@ -70,7 +70,7 @@ command is provided to perform this task, and must
 be executed on _one_ of the remaining peers. That peer will then take
 ownership of the freed address space.

-##<a name="cluster-upgrade"></a>Upgrading a Cluster
+## <a name="cluster-upgrade"></a>Upgrading a Cluster

 Protocol versioning and feature negotiation are employed in Weave Net
 to enable incremental rolling upgrades. Each major maintains
@@ -102,7 +102,7 @@ To minimize downtime while the new script is pulling the new container images:
 there are any special caveats or deviations from the standard
 procedure.

-##<a name="reset"></a>Resetting Persisted Data
+## <a name="reset"></a>Resetting Persisted Data

 Weave Net persists information in a data volume container named
 `weavedb`. If you wish to start from a completely clean slate (for
@@ -34,7 +34,7 @@ which a helper is provided in the Weave script:
    # ping foo


-###<a name="launching"></a>Launching Weave Net and Running Containers Using the Plugin
+### <a name="launching"></a>Launching Weave Net and Running Containers Using the Plugin

 Just launch the Weave Net router onto each host and make a peer connection with the other hosts:

@@ -55,7 +55,7 @@ then run your containers using the Docker command-line:
    64 bytes from 10.32.0.2: icmp_seq=2 ttl=64 time=0.052 ms


-###<a name="multi"></a>Creating multiple Docker Networks
+### <a name="multi"></a>Creating multiple Docker Networks

 Docker enables you to create multiple independent networks and attach
 different sets of containers to each network. However, coordinating
@@ -79,7 +79,7 @@ Containers attached to different Docker Networks are
 [isolated through subnets](https://www.weave.works/docs/net/latest/using-weave/application-isolation/).


-###<a name="restarting"></a>Restarting the Plugin
+### <a name="restarting"></a>Restarting the Plugin

 The plugin, like all Weave Net components, is started with a policy of `--restart=always`, so that it is always there after a restart or reboot. If you remove this container (for example, when using `weave reset`) before removing all endpoints created using `--net=weave`, Docker may hang for a long time when it subsequently tries to re-establish communications to the plugin.

@@ -90,7 +90,7 @@ If you are using `systemd` with Docker 1.9, it is advised that you modify the Do
    TimeoutStartSec=0


-###<a name="configuring"></a>Configuring the Plugin
+### <a name="configuring"></a>Configuring the Plugin

 The plugin accepts a number of configuration parameters. To supply
 these, instead of running `weave launch`, start the router and plugin
@@ -13,7 +13,7 @@ This section contains the following topics:
 * [Starting the Netcat Service](#start-netcat)


-###<a name="launching"></a>Launching Weave Net
+### <a name="launching"></a>Launching Weave Net

 Before launching Weave Net and deploying your apps, ensure that Docker is [installed](https://docs.docker.com/engine/installation/) on both hosts. 

@@ -57,7 +57,7 @@ You can also preload the images by running `weave setup`. Preloaded images are u
 If you are deploying an application that consists of more than one container to the same host, launch them one after another using `docker run`, as appropriate.  


-###<a name="peer-connections"></a>Creating Peer Connections Between Hosts
+### <a name="peer-connections"></a>Creating Peer Connections Between Hosts

 To launch Weave Net on an additional host and create a peer connection, run the following:

@@ -73,7 +73,7 @@ You can also peer with other hosts by specifying the IP address, and a `:port` b

 There are a number of different ways that you can specify peers on a Weave network. You can launch Weave Net on `$HOST1` and then peer with `$HOST2`, or you can launch on `$HOST2` and peer with `$HOST1` or you can tell both hosts about each other at launch. The order in which peers are specified is not important. Weave Net automatically (re)connects to peers when they become available. 

-####Specifying Multiple Peers at Launch
+#### Specifying Multiple Peers at Launch

 To specify multiple peers, supply a list of addresses to which you want to connect, all separated by spaces. 

@@ -83,7 +83,7 @@ For example:

 Peers can also be dynamically added. See [Adding Hosts Dynamically](/site/using-weave/finding-adding-hosts-dynamically.md) for more information.

-####Restricting Access
+#### Restricting Access

 By default Weave Net listens on all host IPs (i.e. 0.0.0.0). This
 can be altered with the `--host` parameter to `weave launch`, for example, 
@@ -95,7 +95,7 @@ Weave Net control and data ports.
 For communication across untrusted networks, connections can be
 [encrypted](/site/using-weave/security-untrusted-networks.md).

-###<a name="testing"></a>Testing Container Communications
+### <a name="testing"></a>Testing Container Communications

 With two containers running on separate hosts, test that both containers are able to find and communicate with one another using ping. 

@@ -116,7 +116,7 @@ Similarly, in the container started on `$HOST2`...
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.366/0.366/0.366/0.000 ms

-###<a name="start-netcat"></a>Starting the Netcat Service
+### <a name="start-netcat"></a>Starting the Netcat Service

 The `netcat` service can be started using the following commands:  

@@ -16,7 +16,7 @@ on which they live.

 ![Weave Net AWS-VPC Mode](weave-net-awsvpc-1007x438.png)

-###Configuring EC2 Instances to use Weave AWS-VPC Mode
+### Configuring EC2 Instances to use Weave AWS-VPC Mode

 First, your AWS instances need to be given write access to the route
 table via its
@@ -59,7 +59,7 @@ addresses will flow over the AWS network unmodified.
 Finally, since Weave will be operating with IP addresses outside of the 
 range allocated by Amazon, you must disable "Source/Destination check" on each machine.

-###Using AWS-VPC Mode
+### Using AWS-VPC Mode

 Launch Weave Net with the `--awsvpc` flag:

@@ -68,7 +68,7 @@ Launch Weave Net with the `--awsvpc` flag:
 >>**Note:** You will still need to supply the names or IP addresses of other hosts in
 your cluster.

-###Present Limitations
+### Present Limitations

 - AWS-VPC mode does not inter-operate with other Weave Net modes; it
  is all or nothing.  In this mode, all hosts in a cluster must be AWS
@@ -85,7 +85,7 @@ your cluster.
 - All of your containers must be on the same network, with no subnet
  isolation. (We hope to ease this limitation in future.)

-###Packet size (MTU)
+### Packet size (MTU)

 The Maximum Transmission Unit, or MTU, is the technical term for the
 limit on how big a single packet can be on the network. Weave Net
@@ -20,7 +20,7 @@ where,

 >Note If you are using the Weave Docker API proxy, it will have modified `DOCKER_HOST` to point to the proxy and therefore you will have to pass `-e WEAVE_CIDR=none` to start a container that _doesn't_ get automatically attached to the weave network for the purposes of this example.

-###Dynamically Detaching Containers
+### Dynamically Detaching Containers

 A container can be detached from a subnet, by using the `weave detach` command:

@@ -10,13 +10,13 @@ When Weave Net cannot use the fast data path between two hosts, it falls back to

 See [How Fastdp Works](/site/how-it-works/fastdp-how-it-works.md) for a more in-depth discussion of this feature. 

-###Disabling Fast Datapath
+### Disabling Fast Datapath

 You can disable fastdp by enabling the `WEAVE_NO_FASTDP` environment variable at `weave launch`:

    $ WEAVE_NO_FASTDP=true weave launch

-###Fast Datapath and Encryption
+### Fast Datapath and Encryption

 Fast datapath implements encryption using IPsec which is configured with IP
 transformation framework (XFRM) provided by the Linux kernel.
@@ -28,7 +28,7 @@ Cloud Platform denies ESP packets by default.
 See [How Weave Implements Encryption](/site/how-it-works/encryption-implementation.md)
 for more details for the fastdp encryption.

-###Viewing Connection Mode Fastdp or Sleeve
+### Viewing Connection Mode Fastdp or Sleeve

 Weave Net automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave Net can use the fast datapath:

@@ -48,7 +48,7 @@ Where fastdp indicates that fast datapath is being used on a connection. If fast
    $ weave status connections
    <- 192.168.122.25:54782  established sleeve 8a:50:4c:23:11:ae(ubuntu1204)

-###<a name="mtu"></a>Packet size (MTU)
+### <a name="mtu"></a>Packet size (MTU)

 The Maximum Transmission Unit, or MTU, is the technical term for the
 limit on how big a single packet can be on the network. Weave Net
@@ -23,7 +23,7 @@ hosts run:
 Any other existing hosts on the Weave network will attempt to
 establish connections to the new host as well.

-###Instructing Peers to Forget a Host
+### Instructing Peers to Forget a Host

 To instruct a peer to forget a particular host specified to it via
 `weave launch` or `weave connect` run:
@@ -34,14 +34,14 @@ This prevents the peer from reconnecting to that host once
 connectivity to it is lost, and can be used to administratively remove
 any decommissioned peers from the network.

-###Bulk Replacing Hosts
+### Bulk Replacing Hosts

 Hosts can also be bulk-replaced. All existing hosts will be forgotten,
 and the new hosts added:

    host# weave connect --replace $NEW_HOST1 $NEW_HOST2

-###Restarting Docker and Weave Net
+### Restarting Docker and Weave Net

 If Weave Net is restarted by Docker it automatically remembers any
 previous connect and forget operations, however if you stop it
@@ -22,7 +22,7 @@ And you can also ping the `a1` netcat application container residing on `$HOST1`

    host2$ ping $(weave dns-lookup a1)

-###Exposing Multiple Subnets
+### Exposing Multiple Subnets

 Multiple subnet addresses can be exposed or hidden using a single command:

@@ -31,14 +31,14 @@ Multiple subnet addresses can be exposed or hidden using a single command:
    host2$ weave hide   net:default net:10.2.2.0/24
    10.2.1.132 10.2.2.130

-###Adding Exposed Addresses to weaveDNS
+### Adding Exposed Addresses to weaveDNS

 Exposed addresses can also be added to weaveDNS by supplying fully qualified domain names:

    host2$ weave expose -h exposed.weave.local
    10.2.1.132

-###<a name="routing"></a>Routing from Another Host
+### <a name="routing"></a>Routing from Another Host

 After running `weave expose`, you can use Linux routing to provide
 access to the Weave network from hosts that are not running Weave Net:
@@ -4,7 +4,7 @@ menu_order: 100
 ---


-###Enabling Multi-Cloud Networking
+### Enabling Multi-Cloud Networking

 Before multi-cloud networking can be enabled, you must configure the network to allow 
 connections through Weave Net's control and data ports on the Docker hosts. By default, the 
@@ -20,7 +20,7 @@ port and UDP 9000/9001 for its data port.
 the same setting.


-###Multi-hop routing
+### Multi-hop routing

 A network of containers across more than two hosts can be 
 established even when there is only partial connectivity 
@@ -13,7 +13,7 @@ This section contains the following topics:



-###<a name="exporting"></a>Exporting Services
+### <a name="exporting"></a>Exporting Services

 Services running in containers on a Weave network can be made
 accessible to the outside world (and, more generally, to other networks)
@@ -43,7 +43,7 @@ With the above in place, you can connect to the 'nc' service from anywhere using

 Similar NAT rules to the above can be used to expose services not just to the outside world but also to other, internal, networks.

-###<a name="importing"></a>Importing Services
+### <a name="importing"></a>Importing Services

 Applications running in containers on a Weave network can be given access to services, which are only reachable from certain 
 Weave hosts, regardless of where the actual application containers are located.
@@ -73,7 +73,7 @@ You can now connect to it from the application container running on `$HOST2` usi

 Note that you should be able to run this command from any application container.

-###<a name="binding"></a>Binding Services
+### <a name="binding"></a>Binding Services

 Importing a service provides a degree of indirection that allows late and dynamic binding, similar to what can be achieved with a proxy. 

@@ -81,7 +81,7 @@ Referring back to the [netcat services example that is running on three hosts](#

 You can point application containers to another service location by changing the above NAT rule, without altering the applications.

-###<a name="routing"></a>Routing Services
+### <a name="routing"></a>Routing Services

 You can combine the service export and service import features to establish connectivity between applications and services residing on disjointed networks, even if those networks are separated by firewalls and have overlapping IP ranges. 

@@ -103,7 +103,7 @@ Now any host on the same network as `$HOST2` is able to access the service:

    echo 'Hello, world.' | nc $HOST2 4433

-###<a name="change-location"></a>Dynamically Changing Service Locations
+### <a name="change-location"></a>Dynamically Changing Service Locations

 Furthermore, as explained in Binding Services, service locations can be dynamically altered without having to change any of the applications that access them.  

@@ -9,7 +9,7 @@ network when they are started using the ordinary Docker
 or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/),
 instead of `weave run`.

-###<a name="attaching-containers"></a>Attaching Containers to a Weave Network
+### <a name="attaching-containers"></a>Attaching Containers to a Weave Network

 There are three ways to attach containers to a Weave network (which method to use is 
 entirely up to you):
@@ -34,7 +34,7 @@ See [Integrating Docker via the Network Plugin](/site/plugin.md).
 does not use the Weave Docker API Proxy. 
 See [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md). 

-###<a name="weave-api-proxy"></a>Setting Up The Weave Net Docker API Proxy
+### <a name="weave-api-proxy"></a>Setting Up The Weave Net Docker API Proxy

 The proxy sits between the Docker client (command line or API) and the
 Docker daemon, and intercepts the communication between the two. You can
@@ -19,7 +19,7 @@ To start a container without connecting it to the Weave network, pass

    host1$ docker run -ti -e WEAVE_CIDR=none weaveworks/ubuntu

-###Disabling Automatic IP Address Allocation
+### Disabling Automatic IP Address Allocation

 If you do not want an IP to be assigned by default, the proxy needs to
 be passed the `--no-default-ipalloc` flag, for example:
@@ -12,7 +12,7 @@ When they are started via the Weave Net proxy, containers are
 [automatically assigned IP addresses](/site/ipam.md) and connected to the
 Weave network.  

-###Creating and Starting Containers with the Weave Net Proxy
+### Creating and Starting Containers with the Weave Net Proxy

 To create and start a container via the Weave Net proxy run:

@@ -33,7 +33,7 @@ variable by space-separating them, as in
 `WEAVE_CIDR="10.2.1.1/24 10.2.2.1/24"`.


-###Returning Weave Network Settings Instead of Docker Network Settings
+### Returning Weave Network Settings Instead of Docker Network Settings

 The Docker NetworkSettings (including IP address, MacAddress, and
 IPPrefixLen), are still returned when `docker inspect` is run. If you want
@@ -46,13 +46,13 @@ only includes one of them.

    host1$ weave launch-router && weave launch-proxy --rewrite-inspect

-###Multicast Traffic and Launching the Weave Proxy
+### Multicast Traffic and Launching the Weave Proxy

 By default, multicast traffic is routed over the Weave network.
 To turn this off, for example, because you want to configure your own multicast
 route, add the `--no-multicast-route` flag to `weave launch-proxy`.

-###Other Weave Proxy options
+### Other Weave Proxy options

 * `--without-dns` -- stop telling containers to use [WeaveDNS](/site/weavedns.md)
 * `--log-level=debug|info|warning|error` -- controls how much
@@ -21,7 +21,7 @@ When weaveDNS is queried for a name in a domain other than
 `.weave.local`, it queries the host's configured nameserver, which is
 the standard behaviour for Docker containers.

-###Specifying a Different Docker Bridge Device
+### Specifying a Different Docker Bridge Device

 So that containers can connect to a stable and always routable IP
 address, weaveDNS listens on port 53 to the Docker bridge device, which