burble.dn42 / Network / Peering with burble.dn42

Peering with burble.dn42

This page provides the information to get started on peering with the burble.dn42 network

burble.dn42 is a set of global POPs integrated to the dn42 network, and new peering requests are welcome. Some details of the network are available in the Design page.

burble.dn42 is a large network and there are some restrictions in place to protect the network and the rest of the DN42.
Please ensure you read the information below before requesting to peer.

Peering Requests

Please mail [email protected] if you’d like to peer with me.

Peering Requirements

To peer with burble.dn42, you must meet the following requirements:

  • You must support IPv6

  • You must implement ROA checks

  • Contact information in the registry must always be up to date and admins must respond when contacted

    Contacts must also be reachable in case of problems. In addition, the network is ever evolving and failure to respond to change notices may result in your peering being suspended.

  • Latency to your node must be reasonable, typically this means a latency less than 40ms.

At a minimum, I’ll need to know the following in order to establish a peering:

  • The burble.dn42 node you would like to peer with
  • Your ASN
  • The public address of your host
  • The tunnel and BGP parameters, e.g.
  • IP addresses of your end of the tunnel
    • Typically these will be a single IPv4/32 and Link-Local IPv6 address

All peerings will be configured as a full transit session.

Residential ISPs and Dynamic IP Addresses

A 24/7 connection, with static IP addresses are the norm for DN42. If you are connecting from a residential ISP or otherwise have a dynamic IP please let me know so that I can configure my side appropriately. If you don’t do tell me, the peering may stop working when your IP address changes.

Peering in Multiple Locations

If you have multiple nodes, you are welcome to peer in several locations to provide additional redundancy and route choice. Routes exported from the network include a latency based MED attribute to help peers optimise their routing (See the Routing Policy)

It’s highly recommended to peer with multiple DN42 users though, it’s lots of fun and you should never rely on just one user for your connectivity.

Supported Tunnel Types

I prefer to use wireguard, it’s simple to set up and just works. I also support OpenVPN tunnels.

Wireguard

  • The port number will be 2xxxx where xxxx is the last four digits of your ASN.
  • Each peer is assigned a unique encryption key, pre-shared keys are also supported (but not enabled by default).
  • Endpoint names and IP addresses are detailed in the nodes page.

My wireguard AllowedIPs are:

AllowedIPs=fe80::/64
AllowedIPs=fd00::/8
AllowedIPs=0.0.0.0/0

Use of wg-quick

Using wg-quick is not recommended as it does not support adding a peer address. If you want to use wg-quick you will need to delete and re-add the wireguard interface IP address and configure it as a point to point address or you will run in to next-hop problems when using BGP. You must read the DN42 Wiki on how to set up wg-quick for use within DN42.

OpenVPN

  • The port number will be 2xxxx where xxxx is the last four digits of your ASN.

By default I will configure the following OpenVPN parameters:

comp-lzo
cipher aes-256-cbc
auth sha256

Tunnel Configuration

Allowed Traffic

Only the following network ranges will be forwarded through the DN42 network, all other traffic will be dropped.

IPv4

172.16.0.0/12
10.0.0.0/8

IPv6

fd00::/8
BGP peer addresses are more permissive to allow for link local or non-DN42 IP addresses within the tunnel, but these will not be forwarded through the DN42 network.

Flow Control and BGP Rate Limiting

A typical BGP session in DN42 will use a trivial amount of traffic. However, for large networks like burble.dn42 some transient events, such as BGP flapping, can generate multi MB/sec traffic flows that damage the network and create instability across DN42.

To protect the network from misconfigurations and prevent excessive updates from propagating to the rest of DN42, the burble.dn42 network implements rate limiting on BGP sessions. The rate limiting activates when a large amount of BGP traffic is seen (typically 10’s or 100’s of thousands of updates a second) over a sustained period and will typically reset automatically within an hour.

There are no other controls applied to transit or non-BGP traffic.

BGP Configuration
Network Name BURBLE
BURBLE-MNT [email protected]
ASN AS4242422601

BGP Feature Support

The burble.dn42 network uses a custom build of bird 2, and the following features are supported:

The source code for the custom bird used on the network is available on git.burble.dn42

Default Extensions

Multiprotocol BGP is preferred, however it is not enabled by default as not all peers can support it. Please let me know when peering if you can support a multiprotocol BGP session.

Extended next hop and extended message support are both enabled by default.

Route Filtering

The network applies strict Route Origin Authorisation (ROA) filtering to all received and exported routes. This means any advertised route that does not have a corresponding route{,6} object in the DN42 registry will be dropped.

ROA is implemented with updates through RPKI, using dn42regsrv and gortr.

The DN42 ROA data is provided as a public service, see the Services page.

Generic Allowed Prefixes:

IPv4

172.20.0.0/14+
10.0.0.0/8+

IPv6

fd00::/8{44,64}

Testing

Connectivity Testing

Within the tunnel, hosts respond to ping and traceroute, but also have the echo (port 7) and daytime (port 13) services enabled. These can be used to check the tunnel is up and configured correctly.

$ ping fe80::42:2601:32:1%wg0
PING fe80::42:2601:32:1%wg0(fe80::42:2601:32:1%wg0) 56 data bytes
64 bytes from fe80::42:2601:32:1%wg0: icmp_seq=1 ttl=64 time=4.44 ms
64 bytes from fe80::42:2601:32:1%wg0: icmp_seq=2 ttl=64 time=4.52 ms
64 bytes from fe80::42:2601:32:1%wg0: icmp_seq=3 ttl=64 time=4.96 ms
^C
--- fe80::42:2601:32:1%wg0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.445/4.643/4.961/0.233 ms
$ netcat fe80::42:2601:32:1%wg0 13
Sun Sep 23 09:57:26 2018
^C
$

Reachability Testing

Once peering is established I have a BGP looking glass (public internet link) and global route collector which can be used to check routing configuration. Looking glasses are a key, self-service resource for you to use when understanding how your routes are propagating around the DN42 network, please take the time to learn how to use them.

Speed Test

burble.dn42 operates a speed test service at speedtest.burble.dn42, see the services pages for more info.

Automated Tests

pingable.burble.dn42 (172.20.129.5 / fd42:4242:2601:ac05::1) is a dedicated address that responds to ping and traceroute and may be used for automated reachability or link quality testing.

Please be considerate when configuring automated tests and set a reasonable test frequency.

In all cases, the frequency must not be more than once a second.
Please consider this if your router automatically pings its tunnel endpoint for stats purposes.