+
+
+
+
+
+
+
+
diff --git a/site/boot2docker.md b/site/boot2docker.md
new file mode 100644
index 00000000..125ccfa0
--- /dev/null
+++ b/site/boot2docker.md
@@ -0,0 +1,26 @@
+---
+title: Installing Weave with Boot2Docker
+layout: default
+---
+
+## Installation with Boot2Docker
+
+If you are running Docker inside the Boot2Docker VM, e.g. because you
+are on a Mac, then the following changes are required to these
+instructions:
+
+Assuming you have fetched the 'weave' script via curl or similar, and
+it is in the current directory, transfer it to the Boot2Docker VM and
+make it executable like this:
+
+ host1$ boot2docker ssh "cat > weave" < weave
+ host1$ boot2docker ssh "chmod a+x weave"
+
+Then, if we were trying to create the same containers as in the first
+example above, the 'launch' command would be run like this:
+
+ host1$ boot2docker ssh "sudo ./weave launch"
+
+and the 'run' command like this:
+
+ host1# C=$(boot2docker ssh "sudo ./weave run 10.0.1.1/24 -t -i ubuntu")
diff --git a/site/building.md b/site/building.md
new file mode 100644
index 00000000..fe84f79a
--- /dev/null
+++ b/site/building.md
@@ -0,0 +1,92 @@
+---
+title: Building Weave
+layout: default
+---
+
+**NB** This is only necessary if you want to work on the weave code.
+
+## Building directly on Linux
+
+You can work on weave without using a VM if you are running the docker
+daemon outside a VM. (These instructions have only been tested on
+Ubuntu.)
+
+To build weave you need `libpcap-dev` and `docker` installed. And `go`
+(and `git` and `hg` to fetch dependencies).
+
+The package name is `github.com/zettio/weave`, so assuming `$GOPATH`
+is set:
+
+```bash
+$ cd $GOPATH
+$ WEAVE=github.com/zettio/weave
+$ git clone https://$WEAVE src/$WEAVE
+$ cd src/$WEAVE
+```
+
+Then simply run
+
+```bash
+$ make
+```
+
+This will build the weave router, produce a docker image
+`zettio/weave` and export that image to `/var/tmp/weave.tar`.
+
+## Building using Vagrant
+
+If you aren't running Linux, or otherwise don't want to run the docker
+daemon outside a VM, you can use
+[Vagrant](https://www.vagrantup.com/downloads.html) to run a
+development environment. You'll probably need to install
+[VirtualBox](https://www.virtualbox.org/wiki/Downloads) too, for
+Vagrant to run VMs in.
+
+First, check out the code:
+
+```bash
+$ git clone https://github.com/zettio/weave
+$ cd weave
+```
+
+The `Vagrantfile` in the top directory constructs a VM that has
+
+ * docker installed
+ * go tools installed
+ * weave dependencies installed
+ * $GOPATH set to ~
+ * the local working directory mapped as a synced folder into the
+ right place in $GOPATH
+
+Once you are in the working directory you can issue
+
+```bash
+$ vagrant up
+```
+
+and wait for a while (don't worry, the long download and package
+installation is done just once). The working directory is sync'ed with
+`~/src/github.com/zettio/weave` on the VM, so you can edit files and
+use git and so on in the regular filesystem.
+
+To build and run the code, you need to use the VM. To log in and build
+the weave image, do
+
+```bash
+$ vagrant ssh
+vm$ cd src/github.com/zettio/weave
+vm$ make
+```
+
+The docker daemon is also running in this VM, so you can then do
+
+```bash
+vm$ sudo ./weave launch
+vm$ docker ps
+```
+
+and so on.
+
+You can provide extra Vagrant configuration by putting a file
+`Vagrant.local` in the same place as `Vagrantfile`; for instance, to
+forward additional ports.
diff --git a/site/features.md b/site/features.md
new file mode 100644
index 00000000..aa456862
--- /dev/null
+++ b/site/features.md
@@ -0,0 +1,354 @@
+---
+title: Weave features
+layout: default
+---
+
+# Weave features
+
+Weave has a few more features beyond those illustrated by the [basic
+example](https://github.com/zettio/weave#example):
+
+ * [Virtual ethernet switch](#virtual-ethernet-switch)
+ * [Application isolation](#application-isolation)
+ * [Dynamic network attachment](#dynamic-network-attachment)
+ * [Security](#security)
+ * [Host network integration](#host-network-integration)
+ * [Service export](#service-export)
+ * [Service import](#service-import)
+ * [Service binding](#service-binding)
+ * [Service routing](#service-routing)
+ * [Multi-cloud networking](#multi-cloud-networking)
+ * [Multi-hop routing](#multi-hop-routing)
+ * [Dynamic topologies](#dynamic-topologies)
+ * [Container mobility](#container-mobility)
+ * [Fault tolerance](#fault-tolerance)
+ * [DNS](#dns)
+
+### Virtual Ethernet Switch
+
+To application containers, the network established by weave looks
+like a giant Ethernet switch to which all the containers are
+connected.
+
+Containers can easily access services from each other; e.g. in the
+container on $HOST1 we can start a netcat "service" with
+
+ root@28841bd02eff:/# nc -lk -p 4422
+
+and then connect to it from the container on $HOST2 with
+
+ root@f76829496120:/# echo 'Hello, world.' | nc 10.0.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
+
+We can deploy the entire arsenal of standard network tools and
+applications, developed over decades, to configure, secure, monitor,
+and troubleshoot our container network. To put it another way, we can
+now re-use the same tools and techniques when deploying applications
+as containers as we would have done when deploying them 'on metal' in
+our data centre.
+
+### Application isolation
+
+A single weave network can host multiple, isolated applications, with
+each application's containers being able to communicate with each
+other but not containers of other applications.
+
+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)
+
+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 ---
+ 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 ---
+ 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 ---
+ 1 packets transmitted, 0 received, 100% packet loss, time 0ms
+
+This isolation-through-subnets scheme is an example of carrying over a
+well-known technique from the 'on metal' days to containers.
+
+NB: By default docker permits communication between containers on the
+same host, via their docker-assigned IP addresses. For complete
+isolation between application containers, that feature needs to be
+disabled by
+[setting `--icc=false`](https://docs.docker.com/articles/networking/#between-containers)
+in the docker daemon configuration.
+
+### Dynamic network attachment
+
+In some scenarios containers are started independently, e.g. via some
+existing tool chain, or require more complex startup sequences than
+provided by `weave run`. And sometimes the decision which application
+network a container should be part of is made post-startup. For these
+situations, weave allows an existing, running container to be attached
+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
+
+There is a matching `weave detach` command:
+
+ host1# weave detach 10.0.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
+
+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
+
+### Security
+
+In order to connect containers across untrusted networks, weave peers
+can be told to encrypt traffic by supplying a `-password` option when
+launching weave, e.g.
+
+ host1# weave launch -password wEaVe
+
+The same password must be specified for all weave peers; it is a
+component in the creation of ephemeral session keys for connections
+between peers.
+
+### Host network integration
+
+Weave application networks can be integrated with a host's network,
+establishing connectivity between the host and application containers
+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
+
+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
+
+will work. And, more interestingly,
+
+ host2# ping 10.0.1.1
+
+will work too, which is talking to a container that resides on $HOST1.
+
+### Service export
+
+Services running in containers on a weave network can be made
+accessible to the outside world (and, more generally, other networks)
+from any weave host, irrespective of where the service containers are
+located.
+
+Say we want to make our example netcat "service", which is running in
+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
+
+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
+
+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.
+
+With the above in place, we can connect to our 'nc' service from
+anywhere with
+
+ echo 'Hello, world.' | nc $HOST2 2211
+
+(NB: due to the way routing is handled in the Linux kernel, this won't
+work when run *on* $HOST2.)
+
+Similar NAT rules to the above can used to expose services not just to
+the outside world but also other, internal, networks.
+
+### Service import
+
+Applications running in containers on a weave network can be given
+access to services which are only reachable from certain weave hosts,
+irrespective of where the application containers are located.
+
+Say that, as an extension of our example, we have a netcat service
+running on $HOST3, port 2211, and that $HOST3 is not part of the weave
+network and is only reachable from $HOST1, not $HOST2. Nevertheless we
+want to make the service accessible to an application running in a
+container on $HOST2.
+
+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
+
+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 \
+ -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
+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
+
+The same command will work from any application container.
+
+### Service binding
+
+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
+`$HOST3:2211`. We can point application containers at another service
+location by changing the above NAT rule, without having to alter the
+applications themselves.
+
+### Service routing
+
+The [service export](#service-export) and
+[service import](#service-import) features can be combined to
+establish connectivity between applications and services residing on
+disjoint networks, even when those networks are separated by firewalls
+and might have overlapping IP ranges. Each network imports its
+services into weave, and in turn exports from weave services required
+by its applications. There are no application containers in this
+scenario (though of course there could be); weave is acting purely as
+an address translation and routing facility, using the weave
+application network as an intermediary.
+
+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
+
+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
+
+Now any host on the same network as $HOST2 can access the service with
+
+ echo 'Hello, world.' | nc $HOST2 4433
+
+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
+endpoint in the weave network.
+
+### Multi-cloud networking
+
+Weave can network containers hosted in different cloud providers /
+data centres. So, for example, one could run an application consisting
+of containers on GCE, EC2 and in local data centres.
+
+To enable this, the network must be configured to permit TCP and UDP
+connections to port 6783 of the docker hosts.
+
+### 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
+is able to route traffic between containers as long as there is at
+least one *path* of connected hosts between them.
+
+So, for example, if a docker host in a local data centre can connect
+to hosts in GCE and EC2, but the latter two cannot connect to each
+other, containers in the latter two can still communicate; weave will
+route the traffic via the local data centre.
+
+### Dynamic topologies
+
+To add a host to an existing weave network, one simply launches weave
+on the host, supplying the address of at least one existing
+host. Weave will automatically discover the other hosts in the network
+and establish connections to them if it can (in order to avoid
+unnecessary multi-hop routing).
+
+In some situations all existing weave hosts may be unreachable from
+the new host due to firewalls, etc. However, it is still possible to
+add the new host, provided inverse connections, i.e. from existing
+hosts to the new hosts, are possible. To accomplish that, one launches
+weave on the new host without supplying any additional addresses, and
+then on one of the existing hosts runs
+
+ host# weave connect $NEW_HOST
+
+Other hosts in the weave network will automatically attempt to
+establish connections to the new host too.
+
+### Container mobility
+
+Containers can be moved between hosts without requiring any
+reconfiguration or, in many cases, restarts of other containers. All
+that is required is for the migrated container to be started with the
+same IP address as it was given originally.
+
+### Fault tolerance
+
+Weave peers continually exchange topology information, and monitor
+and (re)establish network connections to other peers. So if hosts or
+networks fail, weave can "route around" the problem. This includes
+network partitions; containers on either side of a partition can
+continue to communicate, with full connectivity being restored when
+the partition heals.
+
+The weave container is very light-weight - just over 8MB image size
+and a few 10s of MBs of runtime memory - and disposable. I.e. should
+weave ever run into difficulty, one can simply stop it (with `weave
+stop`) and restart it. Application containers do *not* have to be
+restarted in that event, and indeed may not even experience a
+temporary connectivity failure if the weave container is restarted
+quickly enough.
+
+### DNS
+
+WeaveDNS is a distributed DNS service for weave networks, enabling
+containers to address each other by name rather than IP address. A
+preview release of weaveDNS is described [on our
+blog](http://weaveblog.com/2014/11/04/have-you-met-weavedns/).
diff --git a/site/how-it-works.md b/site/how-it-works.md
new file mode 100644
index 00000000..dceb89d4
--- /dev/null
+++ b/site/how-it-works.md
@@ -0,0 +1,37 @@
+---
+title: How Weave works
+layout: default
+---
+
+## How does it work?
+
+Weave creates a network bridge on the host. Each container is
+connected to that bridge via a veth pair, the container side of which
+is given the IP address & netmask supplied in 'weave run'. Also
+connected to the bridge is the weave router container.
+
+A weave router captures Ethernet packets from its bridge-connected
+interface in promiscuous mode, using 'pcap'. This typically excludes
+traffic between local containers, and between the host and local
+containers, all of which is routed straight over the bridge by the
+kernel. Captured packets are forwarded over UDP to weave router peers
+running on other hosts. On receipt of such a packet, a router injects
+the packet on its bridge interface using 'pcap' and/or forwards the
+packet to peers.
+
+Weave routers learn which peer host a particular MAC address resides
+on. They combine this knowledge with topology information in order to
+make routing decisions and thus avoid forwarding every packet to every
+peer. The topology information captures which peers are connected to
+which other peers; weave can route packets in partially connected
+networks with changing topology.
+
+Weave routers establish TCP connections to each other, over which they
+perform a protocol handshake and subsequently exchange topology
+information. These connections are encrypted if so configured. Peers
+also establish UDP "connections", possibly encrypted, for the
+aforementioned packet forwarding. These "connections" are duplex and
+can traverse firewalls.
+
+More details on the inner workings of weave can be found in the
+[architecture documentation](https://github.com/zettio/weave/blob/master/docs/architecture.txt).
diff --git a/site/images/blacktocat.png b/site/images/blacktocat.png
new file mode 100644
index 00000000..6e264fe5
Binary files /dev/null and b/site/images/blacktocat.png differ
diff --git a/site/index.md b/site/index.md
new file mode 100644
index 00000000..3e10185a
--- /dev/null
+++ b/site/index.md
@@ -0,0 +1,14 @@
+---
+title: weave, the Docker network
+layout: default
+---
+
+# weave documentation
+
+ * [Introduction and example (in README)](https://github.com/zettio/weave#readme)
+ * [Features](features.html)
+ * [Troubleshooting](troubleshooting.html)
+ * [Building](building.html)
+ * [Using with Boot2Docker](boot2docker.html)
+ * [How it works](how-it-works.html)
+ * [Contact information](https://github.com/zettio/weave#contact-us)
diff --git a/site/javascripts/main.js b/site/javascripts/main.js
new file mode 100644
index 00000000..d8135d37
--- /dev/null
+++ b/site/javascripts/main.js
@@ -0,0 +1 @@
+console.log('This would be the main JS file.');
diff --git a/site/params.json b/site/params.json
new file mode 100644
index 00000000..39ea0a13
--- /dev/null
+++ b/site/params.json
@@ -0,0 +1 @@
+{"name":"Weave","tagline":"The Docker Network","body":"","google":"","note":"Don't delete this file! It's used internally to help with page regeneration."}
diff --git a/site/stylesheets/pygment_trac.css b/site/stylesheets/pygment_trac.css
new file mode 100644
index 00000000..e65cedff
--- /dev/null
+++ b/site/stylesheets/pygment_trac.css
@@ -0,0 +1,70 @@
+.highlight .hll { background-color: #ffffcc }
+.highlight { background: #f0f3f3; }
+.highlight .c { color: #0099FF; font-style: italic } /* Comment */
+.highlight .err { color: #AA0000; background-color: #FFAAAA } /* Error */
+.highlight .k { color: #006699; font-weight: bold } /* Keyword */
+.highlight .o { color: #555555 } /* Operator */
+.highlight .cm { color: #0099FF; font-style: italic } /* Comment.Multiline */
+.highlight .cp { color: #009999 } /* Comment.Preproc */
+.highlight .c1 { color: #0099FF; font-style: italic } /* Comment.Single */
+.highlight .cs { color: #0099FF; font-weight: bold; font-style: italic } /* Comment.Special */
+.highlight .gd { background-color: #FFCCCC; border: 1px solid #CC0000 } /* Generic.Deleted */
+.highlight .ge { font-style: italic } /* Generic.Emph */
+.highlight .gr { color: #FF0000 } /* Generic.Error */
+.highlight .gh { color: #003300; font-weight: bold } /* Generic.Heading */
+.highlight .gi { background-color: #CCFFCC; border: 1px solid #00CC00 } /* Generic.Inserted */
+.highlight .go { color: #AAAAAA } /* Generic.Output */
+.highlight .gp { color: #000099; font-weight: bold } /* Generic.Prompt */
+.highlight .gs { font-weight: bold } /* Generic.Strong */
+.highlight .gu { color: #003300; font-weight: bold } /* Generic.Subheading */
+.highlight .gt { color: #99CC66 } /* Generic.Traceback */
+.highlight .kc { color: #006699; font-weight: bold } /* Keyword.Constant */
+.highlight .kd { color: #006699; font-weight: bold } /* Keyword.Declaration */
+.highlight .kn { color: #006699; font-weight: bold } /* Keyword.Namespace */
+.highlight .kp { color: #006699 } /* Keyword.Pseudo */
+.highlight .kr { color: #006699; font-weight: bold } /* Keyword.Reserved */
+.highlight .kt { color: #007788; font-weight: bold } /* Keyword.Type */
+.highlight .m { color: #FF6600 } /* Literal.Number */
+.highlight .s { color: #CC3300 } /* Literal.String */
+.highlight .na { color: #330099 } /* Name.Attribute */
+.highlight .nb { color: #336666 } /* Name.Builtin */
+.highlight .nc { color: #00AA88; font-weight: bold } /* Name.Class */
+.highlight .no { color: #336600 } /* Name.Constant */
+.highlight .nd { color: #9999FF } /* Name.Decorator */
+.highlight .ni { color: #999999; font-weight: bold } /* Name.Entity */
+.highlight .ne { color: #CC0000; font-weight: bold } /* Name.Exception */
+.highlight .nf { color: #CC00FF } /* Name.Function */
+.highlight .nl { color: #9999FF } /* Name.Label */
+.highlight .nn { color: #00CCFF; font-weight: bold } /* Name.Namespace */
+.highlight .nt { color: #330099; font-weight: bold } /* Name.Tag */
+.highlight .nv { color: #003333 } /* Name.Variable */
+.highlight .ow { color: #000000; font-weight: bold } /* Operator.Word */
+.highlight .w { color: #bbbbbb } /* Text.Whitespace */
+.highlight .mf { color: #FF6600 } /* Literal.Number.Float */
+.highlight .mh { color: #FF6600 } /* Literal.Number.Hex */
+.highlight .mi { color: #FF6600 } /* Literal.Number.Integer */
+.highlight .mo { color: #FF6600 } /* Literal.Number.Oct */
+.highlight .sb { color: #CC3300 } /* Literal.String.Backtick */
+.highlight .sc { color: #CC3300 } /* Literal.String.Char */
+.highlight .sd { color: #CC3300; font-style: italic } /* Literal.String.Doc */
+.highlight .s2 { color: #CC3300 } /* Literal.String.Double */
+.highlight .se { color: #CC3300; font-weight: bold } /* Literal.String.Escape */
+.highlight .sh { color: #CC3300 } /* Literal.String.Heredoc */
+.highlight .si { color: #AA0000 } /* Literal.String.Interpol */
+.highlight .sx { color: #CC3300 } /* Literal.String.Other */
+.highlight .sr { color: #33AAAA } /* Literal.String.Regex */
+.highlight .s1 { color: #CC3300 } /* Literal.String.Single */
+.highlight .ss { color: #FFCC33 } /* Literal.String.Symbol */
+.highlight .bp { color: #336666 } /* Name.Builtin.Pseudo */
+.highlight .vc { color: #003333 } /* Name.Variable.Class */
+.highlight .vg { color: #003333 } /* Name.Variable.Global */
+.highlight .vi { color: #003333 } /* Name.Variable.Instance */
+.highlight .il { color: #FF6600 } /* Literal.Number.Integer.Long */
+
+.type-csharp .highlight .k { color: #0000FF }
+.type-csharp .highlight .kt { color: #0000FF }
+.type-csharp .highlight .nf { color: #000000; font-weight: normal }
+.type-csharp .highlight .nc { color: #2B91AF }
+.type-csharp .highlight .nn { color: #000000 }
+.type-csharp .highlight .s { color: #A31515 }
+.type-csharp .highlight .sc { color: #A31515 }
diff --git a/site/stylesheets/stylesheet.css b/site/stylesheets/stylesheet.css
new file mode 100644
index 00000000..2bd468ab
--- /dev/null
+++ b/site/stylesheets/stylesheet.css
@@ -0,0 +1,431 @@
+/*******************************************************************************
+Slate Theme for GitHub Pages
+by Jason Costello, @jsncostello
+*******************************************************************************/
+
+@import url(pygment_trac.css);
+
+/*******************************************************************************
+MeyerWeb Reset
+*******************************************************************************/
+
+html, body, div, span, applet, object, iframe,
+h1, h2, h3, h4, h5, h6, p, blockquote, pre,
+a, abbr, acronym, address, big, cite, code,
+del, dfn, em, img, ins, kbd, q, s, samp,
+small, strike, strong, sub, sup, tt, var,
+b, u, i, center,
+dl, dt, dd, ol, ul, li,
+fieldset, form, label, legend,
+table, caption, tbody, tfoot, thead, tr, th, td,
+article, aside, canvas, details, embed,
+figure, figcaption, footer, header, hgroup,
+menu, nav, output, ruby, section, summary,
+time, mark, audio, video {
+ margin: 0;
+ padding: 0;
+ border: 0;
+ font: inherit;
+ vertical-align: baseline;
+}
+
+/* HTML5 display-role reset for older browsers */
+article, aside, details, figcaption, figure,
+footer, header, hgroup, menu, nav, section {
+ display: block;
+}
+
+ol, ul {
+ list-style: none;
+}
+
+blockquote, q {
+}
+
+table {
+ border-collapse: collapse;
+ border-spacing: 0;
+}
+
+a:focus {
+ outline: none;
+}
+
+/*******************************************************************************
+Theme Styles
+*******************************************************************************/
+
+body {
+ box-sizing: border-box;
+ color:#373737;
+ background: #212121;
+ font-size: 16px;
+ font-family: 'Myriad Pro', Calibri, Helvetica, Arial, sans-serif;
+ line-height: 1.5;
+ -webkit-font-smoothing: antialiased;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ margin: 10px 0;
+ font-weight: 700;
+ color:#222222;
+ font-family: 'Lucida Grande', 'Calibri', Helvetica, Arial, sans-serif;
+ letter-spacing: -1px;
+}
+
+h1 {
+ font-size: 36px;
+ font-weight: 700;
+}
+
+h2 {
+ padding-bottom: 10px;
+ font-size: 32px;
+ background: url('../images/bg_hr.png') repeat-x bottom;
+}
+
+h3 {
+ font-size: 24px;
+}
+
+h4 {
+ font-size: 21px;
+}
+
+h5 {
+ font-size: 18px;
+}
+
+h6 {
+ font-size: 16px;
+}
+
+p {
+ margin: 10px 0 15px 0;
+}
+
+footer p {
+ color: #f2f2f2;
+}
+
+a {
+ text-decoration: none;
+ color: #007edf;
+ text-shadow: none;
+
+ transition: color 0.5s ease;
+ transition: text-shadow 0.5s ease;
+ -webkit-transition: color 0.5s ease;
+ -webkit-transition: text-shadow 0.5s ease;
+ -moz-transition: color 0.5s ease;
+ -moz-transition: text-shadow 0.5s ease;
+ -o-transition: color 0.5s ease;
+ -o-transition: text-shadow 0.5s ease;
+ -ms-transition: color 0.5s ease;
+ -ms-transition: text-shadow 0.5s ease;
+}
+
+#main_content a:hover {
+ color: #0069ba;
+ text-shadow: #0090ff 0px 0px 2px;
+}
+
+footer a:hover {
+ color: #43adff;
+ text-shadow: #0090ff 0px 0px 2px;
+}
+
+em {
+ font-style: italic;
+}
+
+strong {
+ font-weight: bold;
+}
+
+img {
+ position: relative;
+ margin: 0 auto;
+ max-width: 739px;
+ padding: 5px;
+ margin: 10px 0 10px 0;
+ border: 1px solid #ebebeb;
+
+ box-shadow: 0 0 5px #ebebeb;
+ -webkit-box-shadow: 0 0 5px #ebebeb;
+ -moz-box-shadow: 0 0 5px #ebebeb;
+ -o-box-shadow: 0 0 5px #ebebeb;
+ -ms-box-shadow: 0 0 5px #ebebeb;
+}
+
+pre, code {
+ width: 100%;
+ color: #222;
+ background-color: #fff;
+
+ font-family: Monaco, "Bitstream Vera Sans Mono", "Lucida Console", Terminal, monospace;
+ font-size: 14px;
+
+ border-radius: 2px;
+ -moz-border-radius: 2px;
+ -webkit-border-radius: 2px;
+
+
+
+}
+
+pre {
+ width: 100%;
+ padding: 10px;
+ box-shadow: 0 0 10px rgba(0,0,0,.1);
+ overflow: auto;
+}
+
+code {
+ padding: 3px;
+ margin: 0 3px;
+ box-shadow: 0 0 10px rgba(0,0,0,.1);
+}
+
+pre code {
+ display: block;
+ box-shadow: none;
+}
+
+blockquote {
+ color: #666;
+ margin-bottom: 20px;
+ padding: 0 0 0 20px;
+ border-left: 3px solid #bbb;
+}
+
+ul, ol, dl {
+ margin-bottom: 15px
+}
+
+ul li {
+ list-style: inside;
+ padding-left: 20px;
+}
+
+ol li {
+ list-style: decimal inside;
+ padding-left: 20px;
+}
+
+dl dt {
+ font-weight: bold;
+}
+
+dl dd {
+ padding-left: 20px;
+ font-style: italic;
+}
+
+dl p {
+ padding-left: 20px;
+ font-style: italic;
+}
+
+hr {
+ height: 1px;
+ margin-bottom: 5px;
+ border: none;
+ background: url('../images/bg_hr.png') repeat-x center;
+}
+
+table {
+ border: 1px solid #373737;
+ margin-bottom: 20px;
+ text-align: left;
+ }
+
+th {
+ font-family: 'Lucida Grande', 'Helvetica Neue', Helvetica, Arial, sans-serif;
+ padding: 10px;
+ background: #373737;
+ color: #fff;
+ }
+
+td {
+ padding: 10px;
+ border: 1px solid #373737;
+ }
+
+form {
+ background: #f2f2f2;
+ padding: 20px;
+}
+
+img {
+ width: 100%;
+ max-width: 100%;
+}
+
+/*******************************************************************************
+Full-Width Styles
+*******************************************************************************/
+
+.outer {
+ width: 100%;
+}
+
+.inner {
+ position: relative;
+ max-width: 640px;
+ padding: 20px 10px;
+ margin: 0 auto;
+}
+
+#forkme_banner {
+ display: block;
+ position: absolute;
+ top:0;
+ right: 10px;
+ z-index: 10;
+ padding: 10px 50px 10px 10px;
+ color: #fff;
+ background: url('../images/blacktocat.png') #0090ff no-repeat 95% 50%;
+ font-weight: 700;
+ box-shadow: 0 0 10px rgba(0,0,0,.5);
+ border-bottom-left-radius: 2px;
+ border-bottom-right-radius: 2px;
+}
+
+#header_wrap {
+ background: #212121;
+ background: -moz-linear-gradient(top, #373737, #212121);
+ background: -webkit-linear-gradient(top, #373737, #212121);
+ background: -ms-linear-gradient(top, #373737, #212121);
+ background: -o-linear-gradient(top, #373737, #212121);
+ background: linear-gradient(top, #373737, #212121);
+}
+
+#header_wrap .inner {
+ padding: 50px 10px 30px 10px;
+}
+
+#project_title {
+ margin: 0;
+ color: #fff;
+ font-size: 42px;
+ font-weight: 700;
+ text-shadow: #111 0px 0px 10px;
+}
+
+#project_tagline {
+ color: #fff;
+ font-size: 24px;
+ font-weight: 300;
+ background: none;
+ text-shadow: #111 0px 0px 10px;
+}
+
+#downloads {
+ position: absolute;
+ width: 210px;
+ z-index: 10;
+ bottom: -40px;
+ right: 0;
+ height: 70px;
+ background: url('../images/icon_download.png') no-repeat 0% 90%;
+}
+
+.zip_download_link {
+ display: block;
+ float: right;
+ width: 90px;
+ height:70px;
+ text-indent: -5000px;
+ overflow: hidden;
+ background: url(../images/sprite_download.png) no-repeat bottom left;
+}
+
+.tar_download_link {
+ display: block;
+ float: right;
+ width: 90px;
+ height:70px;
+ text-indent: -5000px;
+ overflow: hidden;
+ background: url(../images/sprite_download.png) no-repeat bottom right;
+ margin-left: 10px;
+}
+
+.zip_download_link:hover {
+ background: url(../images/sprite_download.png) no-repeat top left;
+}
+
+.tar_download_link:hover {
+ background: url(../images/sprite_download.png) no-repeat top right;
+}
+
+#main_content_wrap {
+ background: #f2f2f2;
+ border-top: 1px solid #111;
+ border-bottom: 1px solid #111;
+}
+
+#main_content {
+ padding-top: 40px;
+}
+
+#footer_wrap {
+ background: #212121;
+}
+
+
+
+/*******************************************************************************
+Small Device Styles
+*******************************************************************************/
+
+@media screen and (max-width: 480px) {
+ body {
+ font-size:14px;
+ }
+
+ #downloads {
+ display: none;
+ }
+
+ .inner {
+ min-width: 320px;
+ max-width: 480px;
+ }
+
+ #project_title {
+ font-size: 32px;
+ }
+
+ h1 {
+ font-size: 28px;
+ }
+
+ h2 {
+ font-size: 24px;
+ }
+
+ h3 {
+ font-size: 21px;
+ }
+
+ h4 {
+ font-size: 18px;
+ }
+
+ h5 {
+ font-size: 14px;
+ }
+
+ h6 {
+ font-size: 12px;
+ }
+
+ code, pre {
+ min-width: 320px;
+ max-width: 480px;
+ font-size: 11px;
+ }
+
+}
diff --git a/site/troubleshooting.md b/site/troubleshooting.md
new file mode 100644
index 00000000..76652fc8
--- /dev/null
+++ b/site/troubleshooting.md
@@ -0,0 +1,152 @@
+---
+title: Troubleshooting Weave
+layout: default
+---
+
+## Troubleshooting
+
+Make sure you are running the latest version - you can download it
+with
+
+ docker pull zettio/weave:latest
+
+Check the weave container logs with
+
+ docker logs weave
+
+A reasonable amount of information, and all errors, get logged there.
+
+The log verbosity can be increased by supplying the `-debug` flag when
+launching weave. Be warned, this will log information on a per-packet
+basis, so can produce a lot of output.
+
+Another useful debugging technique is to attach standard packet
+capture and analysis tools, such as tcpdump and wireshark, to the
+`weave` network bridge on the host.
+
+One can ask a weave router for a [status report](#status-report) or
+for a [list of attached containers](#list-attached-containers).
+
+To stop weave, run
+
+ weave stop
+
+Note that this leaves the local application container network intact;
+containers on the local host can continue to communicate, whereas
+communication with containers on different hosts, as well as service
+export/import, is disrupted but resumes when weave is relaunched.
+
+To stop weave and completely remove all traces of the weave network on
+the local host, run
+
+ weave reset
+
+Any running application containers will permanently lose connectivity
+with the weave network and have to be restarted in order to
+re-connect.
+
+### Status report
+
+The command
+
+ weave status
+
+reports on the current status of the weave router.
+
+This produces output like:
+
+````
+Our name is 7a:f4:56:87:76:3b
+Sniffing traffic on &{39 65535 ethwe ae:e3:07:9c:8c:d4 up|broadcast|multicast}
+MACs:
+ba:8c:b9:dc:e1:c9 -> 7a:f4:56:87:76:3b (2014-10-23 16:39:19.482338935 +0000 UTC)
+ce:15:34:a9:b5:6d -> 7a:f4:56:87:76:3b (2014-10-23 16:39:28.257103595 +0000 UTC)
+7a:61:a2:49:4b:91 -> 7a:f4:56:87:76:3b (2014-10-23 16:39:27.482970752 +0000 UTC)
+9e:95:0c:54:8e:39 -> 7a:16:dd:5b:83:de (2014-10-23 16:39:28.795601325 +0000 UTC)
+72:5f:a4:60:e5:ce -> 7a:16:dd:5b:83:de (2014-10-23 16:39:29.575995255 +0000 UTC)
+Peers:
+Peer 7a:16:dd:5b:83:de (v31) (UID 13151318985609435078)
+ -> 7a:f4:56:87:76:3b [37.157.33.76:7195]
+Peer 7a:f4:56:87:76:3b (v1) (UID 6913268221365110570)
+ -> 7a:16:dd:5b:83:de [191.235.147.190:6783]
+Topology:
+unicast:
+7a:f4:56:87:76:3b -> 00:00:00:00:00:00
+7a:16:dd:5b:83:de -> 7a:16:dd:5b:83:de
+broadcast:
+7a:f4:56:87:76:3b -> [7a:16:dd:5b:83:de]
+7a:16:dd:5b:83:de -> []
+Reconnects:
+192.168.32.1:6783 (next try at 2014-10-23 16:39:50.585932102 +0000 UTC)
+````
+
+The terms used here are explained further at
+[how it works](how-it-works.html).
+
+A 'peer' on the weave network is a weave router; one per host. Each
+peer has a name, which tends to remain the same over restarts, and a
+unique identifier (UID) which is different each time it is run. These
+are opaque identifiers as far as the router is concerned, although the
+name defaults to a MAC address.
+
+The 'Sniffing traffic' line shows details of the virtual ethernet
+interface that weave is using to receive packets on the local
+machine.
+
+The 'MACs' section lists all MAC addresses known to this router. These
+identify containers in the weave network, as well as points for
+[host network integration](features.html#host-network-integration). For
+each MAC the list shows the peer they reside on, and the time when the
+router last saw some traffic from that MAC. The router forgets
+addresses which are inactive for longer than 10 minutes.
+
+The 'Peers' section lists all peers known to this router, including
+itself. Each peer is shown with its name, version number (incremented
+on each reconnect) and the UID. Then each line beginning `->` shows
+another peer that it is connected to, with the IP address and port
+number of the connection. In the above example, the local router has
+connected to its peer using address 191.235.147.190:6783, and its peer
+sees the same connection as coming from 37.157.33.76:7195.
+
+The 'Topology' section summarised the information for deciding how to
+route packets between peers, which is mostly of interest when the
+weave network is not fully connected. See the
+[architecture documentation](https://raw.githubusercontent.com/zettio/weave/master/docs/architecture.txt)
+for a full explanation.
+
+Finally, 'Reconnects' lists peers that this router is aware of, but is
+not currently connected to. Each line contains some information about
+whether it is attempting to connect or is waiting for a while before
+connecting again.
+
+### List attached containers
+
+ weave ps
+
+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
+
+On each line are the container ID, its MAC address, then the list of
+IP address/routing prefix length ([CIDR
+notation](http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing))
+assigned on the weave network.
+
+### Reboots
+
+When a host reboots, docker's default behaviour is to restart any
+containers that were running. Since weave relies on special network
+configuration outside of the containers, the weave network will not
+function in this state.
+
+To remedy this, stop and re-launch the weave container, and re-attach
+the application containers with `weave attach`.
+
+For a more permanent solution,
+[disable Docker's auto-restart feature](https://docs.docker.com/articles/host_integration/)
+and create appropriate startup scripts to launch weave and run
+application containers from your favourite process manager.