Mesh/Network topology

From Sudo Room
Revision as of 18:03, 16 June 2018 by Eenblam (talk | contribs) (Drop images depicting relay nodes in network topology)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page has been marked as stale, as it is outdated to the point of providing significant misinformation. Please update it before linking other pages here. Topology

For information about the people's open network topology, refer to this network topology diagram.

WiFi Topology

We use 2.4 GHz 802.11g or 802.11n WiFi gear with omni or semi-directional antennas to provide connectivity to devices such as laptops and smartphones at street level and within buildings. We are currently using a variety of gear including Ubiquiti Picostation M2 HP and Ubiquiti Bullet M2 HP routers for outdoor APs.

We're currently deploying a wireless backbone of point-to-point and point-to-multipoint links. These devices are mounted in high places such as on rooftops, flagpoles, or antenna towers. We currently have firmware support for a variety of Ubiquiti M5 (802.11n) routers, such as NanoBridges, NanoStations, and Rockets. As of June 2018, we're currently working to establish gigabit links with 5GHz and 24GHz Ubiquiti airFiber routers, as well as 60GHz Microtik wireless wires.

See the Home and extender nodes for more info about how these are setup.

All of the outdoor gear is Power over Ethernet (PoE), requiring only a single cable for network and power connectivity.

Mesh Topology

All routers run the Babel mesh routing protocol. The street-level 2.4 ghz routers should ideally be able to function in the event that e.g. an earthquake takes out all of the point to point and point to multipoint rooftop nodes (more alignment sensitive) and the mesh should remain functional, though it could become segmented.

The relays / VPuN servers (see the internet connectivity section) also run Babel, so mesh traffic can flow from one part of the mesh, through the internet, through a relay, and into another part of the mesh if some of the mesh nodes are connected to the internet.

Internet Connectivity

There are four primary types of devices in the mesh:

  • Clients: E.g. smart phones or laptops connected to the mesh.
These do not run the meshing protocol.
  • Mesh nodes: Wifi routers running OpenWRT.
This includes home nodes and their extender nodes
  • Relays / VPuN servers: Professionally hosted servers that relay mesh traffic over the internet.
These run the meshing protocol. Mesh nodes are connected to them with L2TP tunnels.
  • Exit nodes: Co-located servers that appear as the source IP for packets from mesh to internet.
Both relays and exit nodes serve as a layer of protection between people sharing their internet connections with the mesh. A relay can also be an exit server and this may in fact end up being the case in most instances.

Some mesh routers will be hosted in homes that already have internet connections. If an internet connection is available, a mesh router will open an L2TP tunnel (using the tunneldigger software) to several relay nodes over the internet connection. A relay could be e.g. a VPS without a bandwidth cap. The relays all run Babel and function as part of the mesh through the L2TP tunnels to the mesh nodes. Each relay will have a connection to an exit nodes. The relays allow segments of the mesh that are not connected with wifi to be connected over the internet.

Each relay is connected to one exit node (tunnel type not yet decided). It does NAT (IP Masquerading) on traffic coming from the mesh and headed for the internet. All traffic coming from the mesh and going to the wider internet goes through an exit node. The source IP of data coming from the mesh thus appears as the IP of one of the exit nodes. This provides a layer of protection such that e.g. abuse complaints will be sent to the mesh organization instead of the individuals who donate some of their internet bandwidth to the mesh.

Until network has an AS, only one exit node should be made and multiple relay nodes should connect to that exit node (Tunneldigger software can be reused for that). Otherwise clients can have issues when routing protocol decides to move from one exit node to another.
It is important that nodes are connecting to relays and relays to exit nodes and that no IPs of those connecting to relays and exit nodes is stored.

Backbone Connections


  • We have the opportunity to establish a Gigabit link between Oakland and San Francisco, with a connection in San Francisco near the Western most part of 24th street in the Noe Valley neighborhood. This location has great line of sight with many locations in the East Bay. We would like to establish a relationship with anyone that can grant permission to mount equipment on Laney Tower at Laney College in Oakland.