73
edits
Difference between revisions of "Mesh/Network topology"
Jump to navigation
Jump to search
Drop images depicting relay nodes in network topology
(Drop images depicting relay nodes in network topology) |
|||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
[[ | [[Category:Stale]] | ||
= | '''This page has been marked as [[:Category:Stale|stale]], as it is outdated to the point of providing significant misinformation. Please update it before linking other pages here.''' | ||
= Peoplesopen.net Topology = | |||
For information about the people's open network topology, refer to this [[Mesh/Diagrams#Network Topology Diagram|network topology diagram]]. | For information about the people's open network topology, refer to this [[Mesh/Diagrams#Network Topology Diagram|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 | 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 [[Mesh/Home and extender nodes|Home and extender nodes]] for more info about how these are setup. | |||
All of the outdoor gear | 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. | 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. | ||
| Line 19: | Line 21: | ||
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. | 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: | There are four primary types of devices in the mesh: | ||
| Line 35: | Line 37: | ||
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. | 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. | :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. | :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 = | |||
== Desired == | |||
* 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 [https://goo.gl/maps/TzMBTsadiCL2 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 [http://www.laney.edu/wp/ Laney College] in Oakland. | |||