Mirrors
/
ARDEN-documentation
mirror of https://github.com/aredn/documentation.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update Supernode how-to article (#356) 

* update supernode how-to

* scale new screenshot
This commit is contained in:
Steve 2024-05-25 06:29:43 -07:00 committed by GitHub
parent 12ed3c0276
commit c743aff86d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
arednHow-toGuides/_images/supernode-owners.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 755 KiB

After

Width:  |  Height:  |  Size: 564 KiB

27
arednHow-toGuides/supernodes.rst
View File

@ -2,7 +2,9 @@
Configuring a Supernode
=======================
**Supernodes** are a way to link multiple mesh island networks in a safe and efficient way. A Supernode network is a high-level mesh network --- **super** meaning *"above or higher."* The Supernode network sits above the isolated mesh networks and provides connectivity without increasing the routing load on the local networks. Supernodes do not merge networks into one big mesh but instead isolate connections between discrete meshes. For further information see the *Supernode Architecture* section of the **Network Topologies** topic in the **Network Design Guide**.
*Contributor: Tim Wilkinson KN6PLV*
**Supernodes** are a way to link multiple mesh island networks in a safe and efficient way. A Supernode network is a high-level mesh network --- **super** meaning *"above or higher."* The Supernode network sits above the individual mesh networks and provides connectivity without increasing the routing load on the local networks. Supernodes do not merge networks into one big mesh but instead isolate connections between discrete meshes. For further information see the *Supernode Architecture* section of the **Network Topologies** topic in the **Network Design Guide**.
.. image:: ../_images/supernode-mesh.png
:alt: Supernode mesh diagram
@ -15,19 +17,18 @@ Criteria for Deploying a Supernode
Before you consider deploying a Supernode, make sure you can adequately support the level of uptime that is desired for the Cloud Mesh network.
1. Fast unlimited Internet connection. Fiber is preferable. Low latency between Supernodes is important as is available bandwidth. A Supernode can easily transfer 1 teraByte of data every month, so an unmetered connection is best.
1. **Fast unlimited Internet connection.** Fiber is preferable. Low latency between Supernodes is important as is available bandwidth. A Supernode can easily transfer 1 teraByte of data every month, so an unmetered connection is best.
2. Uptime stability. The Supernode should be up 99.999% of the time. The location should ideally have backup power and network connectivity, both to the Internet and to the local mesh.
3. Solid local mesh connectivity. As this is the path for all traffic between your local mesh and every other mesh, the connection to your mesh should be at a high-bandwidth location. If you are deploying a Supernode with any sort of high-bandwidth backbone, the Supernode should be connected to the backbone.
2. **Uptime stability.** The Supernode should be up 99.999% of the time. The location should ideally have backup power and network connectivity, both to the Internet and to the local mesh.
3. **Solid local mesh connectivity.** As this is the path for all traffic between your local mesh and every other mesh, the connection to your mesh should be at a high-bandwidth location. If you are deploying a Supernode with any sort of high-bandwidth backbone, the Supernode should be connected to the backbone.
Coordinating Supernode Deployments
----------------------------------
Because Supernodes use the `OLSR (Optimized Link State Routing) <https://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol>`_ protocol, multiple Supernodes can be connected to each other, each operating as a peer of the others. A local network can be connected to multiple Supernodes, but a single Supernode should only be connected to a single local network, although it may be connected at multiple points.
By having only a single local network connected to each Supernode, the owners of each local network are responsible for their own Supernodes. This simplifies management and maintenance. There is also some fault isolation as a failed Supernode will only affect the link to one local network.
By having each Supernode connected to only a single local network, the owners of each local network are responsible for their own Supernodes. This simplifies management and maintenance. There is also some fault isolation as a failed Supernode will only impact the one local network to which it is connected.
The number of messages a Supernode receives will scale linearly with the total number of nodes in all connected local networks. A Supernode receives a management message from every node in the network (all nodes in all local networks) every 5 seconds. With a typical message size of 100 bytes, a Supernode receives about 20 bytes per second per node. At the time of initial testing, there were 4,300 AREDN |trade| nodes registered world-wide, so a Supernode for this network would receive ``84 KB/s`` or ``0.7 Mb/s``, which is a manageable bandwidth requirement.
@ -42,7 +43,7 @@ As more Supernodes are deployed linking more local networks, the overall perform
Setting up a Supernode
----------------------
Typically a Supernode is configured on a dedicated *Mikrotik hAP ac2*. Its sole task is to serve as a node on the Supernode network. The local sub-mesh network is linked to the Supernode using a :abbr:`DtD (Device to Device)` link on one of its LAN ports which is configured for *dtdlink* on the *Advanced Network* display (Port 5 by default).
Typically a Supernode is configured on a dedicated *Mikrotik hAP ac2*. Its sole task is to serve as a node on the Supernode network. The local network is linked to the Supernode using a :abbr:`DtD (Device to Device)` link on one of its LAN ports which is configured for *dtdlink* on the *Advanced Network* display (Port 5 by default).
.. image:: _images/supernode-localDTD.png
:alt: DtD Link Example
@ -52,7 +53,7 @@ Typically a Supernode is configured on a dedicated *Mikrotik hAP ac2*. Its sole
The following steps are required to configure a Supernode.
#. Start with a **Mikrotik hAP ac2** device that is newly flashed with the latest Nightly Build (≥ 20230930). If the node has been previously configured or used beforehand, please reflash and start fresh in order to avoid problems later in the setup process.
#. Start with a **Mikrotik hAP ac2** device that is newly flashed with the latest Nightly Build. If the node has been previously configured or used beforehand, please reflash and start fresh in order to avoid problems later in the setup process.
#. Configure the Supernode with a nodename prefixed with your callsign followed by a location identifier as well as the word "SUPERNODE." For example you could use ``AB2CD-NYC-SUPERNODE`` or ``AB6CD-LAX-SUPERNODE``
@ -87,13 +88,13 @@ Your node should now be functioning as a Supernode. To validate this you can do
config supernode
option enable '1'
If somehow you do not see these lines, please start this process again from the beginning and make sure to follow every step in the sequence.
If you do not see these lines, please start this process again from the beginning and make sure to follow every step in the sequence.
Things to Avoid
Here are several things **NOT** to do when configuring your Supernode.
- Your Supernode must **not** use any Cross-links (Xlinks) to other nodes
- Your Supernode must **not** have tunnel links to any non-Supernode devices
- Your Supernode must **not** have its *Mesh RF* interface ``enabled`` -- *Mesh RF* must be ``disabled`` as noted above
- Your Supernode must **not** use any Cross-links (Xlinks) to other nodes.
- Your Supernode must **not** have tunnel links to any non-Supernode devices.
- Your Supernode must **not** have its *Mesh RF* interface ``enabled`.` *Mesh RF* must be ``disabled`` as noted above.
Before proceeding, make sure all the previous steps have been completed successfully. Now you should be able to connect to another Supernode using a tunnel. The easiest way to do this is to ask another Supernode owner for a set of tunnel client credentials. Your node can use either a client or server tunnel link. Supernode tunnels use port ``5526`` rather than the usual tunnel port of ``5525``. Supernode owners can be identified from the `Supernode Network Map <https://arednmap.xojs.org>`_
Before proceeding, make sure all the previous steps have been completed successfully. Now you should be able to connect to another Supernode using a tunnel. The easiest way to do this is to ask another Supernode owner for a set of tunnel client credentials. Your node can use either a client or server tunnel link. Supernode owners can be identified from the `Supernode Network Map <https://worldmap.arednmesh.org/>`_