Peering

Introduction

Once all the necessary resources have been accepted into the DN42 Registry, you can begin to peer with neighbors. The process for this varies by peer, for example Kioubit provides an automated peering system, while Lantian communicates via email but uses the 1xRTT method to do so without extra delay. Other peers can be found on the IRC or via the Pingfinder. However, the technical aspects are likely to share some similarities.

Wireguard

Usually, you will need to at least send a Wireguard public key, Wireguard endpoint including port, tunnel IPv4 address and optionally IPv6 ULA or link-local address, which server of theirs you would like to peer with, and your ASN. You can then set up your end of the tunnel, even if the peer has not responded, since both Wireguard and BGP will just keep trying to connect to the peer until it comes up. The below is an example VyOS configuration for the Kioubit VPN connection.

 address 192.168.219.205/32
 address fe80::ade1/128
 description "Kioubit Network (AS4242423914)"
 peer us2 {
     address 192.210.174.198
     allowed-ips 0.0.0.0/0
     allowed-ips ::/0
     port 21878
     public-key 6Cylr9h1xFduAO+5nyXhFI1XJ0+Sw9jCpCDvcqErF1s=
 }
 port 23914
 private-key <redacted>

Sometimes, this process requires also requires setting up static tunnel routes. For example, to peer with Kioubit, it was necessary to set up a static route to 172.20.53.98/32, which was the BGP router on the other end, and to set up the IP 192.168.219.205/32 on my local interface as above, which they would have a static route to. These IPs were used for BGP sessions and next-hops. Combined with the below route, this made the BGP router reachable over IPv4.

 route 172.20.53.98/32 {
     interface wg3914 {
     }
 }

Then, the below BGP configuration was able to communicate using multiprotocol BGP (since both ipv4-unicast and ipv6-unicast were added) over the tunnel. Note that while the static IPv4 route is not used here, it will be included as the next-hop for all routes. ebgp-multihop is not required to bring up the BGP session, but all IPv4 routes will be marked inactive if it is left out, since there are multiple hops to reach the peer over IPv4, unlike the link-local connection with IPv6.

 neighbor fe80::ade0 {
     address-family {
         ipv4-unicast {
         }
         ipv6-unicast {
         }
     }
     ebgp-multihop 10
     interface {
         source-interface wg3914
     }
     remote-as 4242423914
 }