Routing Policy

With a global network and multiple peers, the burble.dn42 network typically has many alternative route paths for reaching a particular destination. The routing policy aims to keep route selection sane, and avoid sending traffic outside of a region where possible.

1. Direct routes for prefixes belonging to a peer should be given the highest priority.
   • So that traffic to peer networks is routed over the burble.dn42 network directly to the peer and not via an external 3rd party
2. Where prefixes are tagged with a DN42 region, they should be routed locally or within the burble.dn42 network.
   • To avoid sending traffic across regions when this could have been avoided.
   • The AS path length is also increased between regions to pursuade external routers to also prefer local hosts.
3. Prioritise by shortest path, then lowest latency

The local_pref for routes is set on entry, and then propogated across the whole network. This forces the network to prefer routes that, where possible, send traffic through the burble.dn42 network to a local peer, rather than sending cross regional traffic through external peers (aka Cold Potato Routing).

The med attribute is used to implement a latency based metric across the network. Scripts are used to gather the latency between nodes (using ping) and this is then incorporated in to the ansible scripting that generates the peer configuration for the internal mesh. The peer configuration sets the med to be the latency in ms between nodes (in milliseconds * 10). A penalty of 500 is added for each hop to encourange direct routing between nodes.

med = (latency between nodes in ms * 10) + (500 per hop)

The med metric is exported to external peers to help them decide how to route traffic to the burble.dn42 network.

The global route collector is treated as a special case and does not follow the normal routing policy. The objective of the collector policy is to steer traffic directly to fr-par1 and reduce transit of GRC traffic over the burble.dn42 network. This is aggressively implemented for certain low bandwidth nodes to prevent any GRC traffic going through these nodes.

To accomplish this, each node announces the GRC prefix in to DN42 with different levels of path prepending depending on the available bandwidth of that node. Some nodes with low bandwidth allocations do not announce the GRC prefix at all.

As well as the external traffic engineering, the internal mesh policy also prevents transit of GRC traffic via low bandwidth nodes.