About Blog Documentation FAQ GitHub

Advanced Peerings

This document contains information on more advanced peering setups.

Multi-homed outbound peerings

On a machine that has multiple network interfaces, where more than one interface can be used to reach a given peer (or the Internet), the InterfacePeers option can be used instead of the Peers option to create peerings over specific interfaces.

It is possible to connect to the same peer multiple times using different interfaces, creating a highly-available peering configuration:

InterfacePeers: {
  "eth0": [
    tls://a.b.c.d:e
  ]
  "eth1": [
    tls://a.b.c.d:e
  ]
}

Prioritised listeners

Like in the above multi-homed example, the machine may have two or more network interfaces. An example may be a Wi-Fi interface and a wired ethernet interface. If you want to accept incoming peering connections on both, but to specifically prefer sending traffic over one or other link whenever possible, you can use the priority field in the peering URI.

Lower numbers are better. In this example, the a.b.c.d IP address belongs to the wired ethernet adapter and the f.g.h.i IP address belongs to the Wi-Fi adapter. Peerings to the priority 1 peering port will be used whenever possible, therefore if another node peers to both interfaces, the wired peering will be preferred over wireless one:

tls://a.b.c.d:e?priority=1
tls://f.g.h.i:e?priority=2

Note that the priority field only influences traffic between two peerings to the same node. It does not affect routing decisions across different nodes and cannot be used, for example, to avoid sending traffic to one remote peer over another.

Prioritised multicast interfaces

If like above you have multiple network interfaces but are using multicast peers, but want to prefer one network interface over the other, you can specify the Priority for a given multicast interface.

Lower numbers are better. In this example, peerings that are automatically discovered and established over eth0 will be preferred over peerings to the same node made over eth1:

MulticastInterfaces: [
  {
    Regex: eth0
    Beacon: true
    Listen: true
    Priority: 1
  }, 
  {
    Regex: eth1
    Beacon: true
    Listen: true
    Priority: 2
  }
]

Note that the priority field only influences traffic between two peerings to the same node. It does not affect routing decisions across different nodes and cannot be used, for example, to avoid sending traffic to one remote peer over another.

Multiple outbound Tor circuits

Peering over Tor is possible using the SOCKS proxy support, although it is typically discouraged as Tor peerings are often slow and fragile. Most notably, Tor circuits can be broken at any time, taking down your Yggdrasil peering connection with it.

To mitigate this, enable the IsolateSOCKSAuth option in Tor and then establish multiple connections to the same peer using different SOCKS usernames and passwords. The usernames and passwords can be anything, but these unique pairs will force Tor to use a separate circuit for each peering connection, providing redundancy against one of those circuits breaking:

Peers: [
  socks://one:one@localhost:9050/a.b.c.d:e
  socks://two:two@localhost:9050/a.b.c.d:e
  socks://three:three@localhost:9050/a.b.c.d:e
]

For more information, see the Tor manual for IsolateSOCKSAuth.

Multicast peerings in combination with a host firewall

If your device has a firewall enabled, multicast discovery of peers through MulticastInterfaces may not work by default. To get this to work, perform the following three steps:

1. Under MulticastInterfaces, set Port to a fixed TCP port number;
2. Allow inbound TCP connectivity to this chosen port number through your firewall — this allows inbound peering connections from other devices;
3. Allow inbound UDP connectivity on port 9001 (optionally with a destination address of ff02::114) through your firewall — this enables your device to hear multicast beacons from other devices.