Posts

Routing Policy and Preferences

Introduction

IEDON-NET (AS4242422189) implements an intelligent BGP routing policy that combines route validation, peer-relationship controls, geographical awareness, internal path cost, and end-to-end link-quality information.

The policy is deliberately divided into separate decision layers:

  1. Route validation and peer policy determine whether a route is allowed to participate.
  2. Local preference (local_pref) applies stable administrative and geographical policy.
  3. AS path length retains its standard BGP priority.
  4. MED compares the propagated quality of otherwise equivalent paths.
  5. For iBGP routes, the accumulated internal cost keeps the nearest suitable border router preferred; path quality breaks ties between equal-cost exits.

Dynamic latency and packet-loss measurements do not modify local_pref, so periodic metric updates cannot unexpectedly cross administrative or geographical preference boundaries.

Route Validation

  • ROA Validation: We only accept ROA_VALID and ROA_UNKNOWN routes, filtering out all ROA_INVALID routes
  • ROA Updates: ROA data is refreshed every 30 minutes to ensure up-to-date validation
  • Session Types: By default, all peering sessions are treated as Full Table sessions, meaning we export and import all valid routes unless otherwise specified

Network Security

We restrict WireGuard tunnel traffic to the following IP address ranges:

  • fe80::/10 (IPv6 Link-Local)
  • fd00::/8 (IPv6 Unique Local Addresses)
  • 172.16.0.0/12 (Private IPv4 space)
  • 10.0.0.0/8 (Private IPv4 space)

BGP Local Preference (local_pref)

Local preference implements IEDON-NET's stable administrative and geographical routing policy. A higher value is preferred.

Local Preference Values

Local Pref Route Class Description
3000 Directly Connected Routes Routes originated by a directly connected peer (AS_PATH length = 1)
2000 Same Region/Country Routes Routes matching the local DN42 region or country policy
1000 Default Routes All other valid routes
0 Suppressed Routes Unhealthy or internally suppressed routes

Geographical Routing Logic

Our implementation prioritizes geographical proximity using DN42 community standards:

  1. Region Priority: Routes are evaluated based on DN42 region communities (64511, 41-70)
  2. Country Fallback: When region information is unavailable, country communities (64511, 1000-1999) are used
  3. Cold Potato Strategy: Geographical policy keeps traffic within the preferred region when possible, while the internal cost selects the nearest suitable border router

Route Preference Decision Matrix

Route Has Region Route Has Country Same Region Same Country Local Pref
Yes Yes Yes Yes 2000
Yes Yes Yes No 1000
Yes Yes No - 1000
Yes No Yes - 2000
Yes No No - 1000
No Yes - Yes 2000
No Yes - No 1000
No No - - 1000

Region information takes priority. Country is only used as a fallback when the route does not carry a region community.

Route Selection Order

For BGP routes with the same BIRD route preference, the relevant comparison order is:

  1. Higher bgp_local_pref
  2. Shorter AS_PATH
  3. Better BGP origin
  4. Lower bgp_med
  5. eBGP over iBGP
  6. Lower internal distance to the border router
  7. Router ID and the remaining tie-breakers

Consequently, a lower MED does not override a higher local preference or a shorter AS path.

All generated peer protocols explicitly enable:

med metric on;

This makes the normalized MED comparable across routes received from different neighboring autonomous systems.

BGP Multi-Exit Discriminator (MED)

IEDON-NET encodes propagated path quality into a deterministic quality cost named Q. Lower values represent better paths.

The quality cost includes five dimensions, in strict priority order:

packet loss > encryption > bandwidth > latency > topology

The complete DN42 path is considered. When a route crosses a new link, that link's characteristics are merged with the quality communities already carried by the route before MED is calculated.

Quality Rank Conversion

Let the normalized route communities be:

  • L: packet-loss community 91..94
  • E: encryption community 31..36
  • B: bandwidth community 21..29
  • R: latency community 1..9
  • T: topology community 81..89

Each value is converted to a rank where a lower rank is better:

Dimension Defined Community Rank Rank When Missing
Packet loss L = 91..94 pL = L - 91 pL = 4
Encryption E = 31..36 pE = 36 - E pE = 6
Bandwidth B = 21..29 pB = 29 - B pB = 9
Latency R = 1..9 pR = R - 1 pR = 9
Topology T = 81..89 pT = T - 81 pT = 9

Missing information is deliberately ranked after every defined value. The system does not interpret missing measurements as zero latency, zero packet loss, or maximum bandwidth.

Path Quality Cost

The ranks are encoded using a collision-free mixed-radix formula:

Q = ((((pL * 7 + pE) * 10 + pB) * 10 + pR) * 10 + pT)

Its exact range is:

0 <= Q <= 34999

This encoding guarantees that:

  • any packet-loss rank difference outweighs every lower-priority dimension combined;
  • any encryption rank difference outweighs bandwidth, latency, and topology combined;
  • any bandwidth rank difference outweighs latency and topology combined;
  • any latency rank difference outweighs topology;
  • no two distinct rank combinations produce the same Q.

Topology is intentionally the final dimension. It can distinguish otherwise equal paths, but a physical connection does not automatically override a tunnel with measurably better loss, encryption, bandwidth, or latency.

eBGP MED

For routes received from an external peer:

MED_eBGP = 100000 + Q

The resulting range is:

100000 <= MED_eBGP <= 134999

The local link is merged into the route's existing DN42 quality communities before Q is calculated. MED therefore represents the normalized worst characteristics of the complete path, including the local peering link.

When exporting a route to an external peer, the received MED is cleared. The DN42 quality communities continue to propagate, allowing the next autonomous system to calculate its own local MED without exposing IEDON-NET's internal cost.

iBGP MED and Internal Exit Selection

For routes distributed internally:

MED_iBGP = 200000 + IGPCost * 35000 + Q

IGPCost is the accumulated IEDON-NET internal cost carried by the internal (64498, cost) community.

Because:

Q_max = 34999 < 35000

a one-point difference in IGPCost always outweighs the complete possible quality range.

This gives deterministic cold-potato behavior:

  • when internal costs differ, the closer suitable border router wins;
  • when internal costs are equal, the route with the lower quality cost Q wins;
  • quality measurements cannot unexpectedly move traffic to a more distant exit.

Even at the maximum 16-bit internal cost:

MED_max = 200000 + 65535 * 35000 + 34999
        = 2293959999

the value remains within the unsigned 32-bit BGP MED range.

MED Calculation Example

Suppose a route carries the following normalized communities:

packet loss = 92  -> pL = 1
encryption = 34   -> pE = 2
bandwidth = 24    -> pB = 5
latency = 4       -> pR = 3
topology = 83     -> pT = 2

The quality cost is:

Q = ((((1 * 7 + 2) * 10 + 5) * 10 + 3) * 10 + 2)
  = 9532

For eBGP:

MED_eBGP = 100000 + 9532
         = 109532

For iBGP with an accumulated internal cost of 12:

MED_iBGP = 200000 + 12 * 35000 + 9532
         = 629532

An otherwise perfect route with IGPCost = 13 has:

MED_iBGP = 200000 + 13 * 35000
         = 655000

The first route remains preferred because the lower internal cost takes priority over the complete quality score. If both routes have the same IGPCost, the route with the lower Q wins.

⚠ Warning

DO NOT ADD OR TAG COUNTRY AND REGION COMMUNITIES ON ROUTES THAT DO NOT BELONG TO YOU

Here is how to correctly set the DN42 region community flag, copied from the DN42 Wiki:

  • Unlike the other community values, the DN42_REGION community should only be set on routes originating from your network! This is what the source = RTS_STATIC check enforces.
  • Otherwise, if you export routes across multiple regions within your network, you may send incorrect origin information to other peers.

Incorrect origin communities can also break region-based route optimization.

Link Quality Assessment

IEDON-NET uses the current DN42 standard communities to describe and propagate link characteristics.

When importing an eBGP route, the local link is merged with the route's existing values using the following rules:

latency    = max(route.latency,    link.latency)
bandwidth  = min(route.bandwidth,  link.bandwidth)
encryption = min(route.encryption, link.encryption)
topology   = max(route.topology,   link.topology)
packetloss = max(route.packetloss, link.packetloss)

These rules retain the worst characteristic encountered along the path:

Dimension Better Direction Path Merge
Latency Lower max
Bandwidth Higher min
Encryption Higher min
Topology Lower max
Packet loss Lower max

After merging, old communities from the same category are removed and exactly one normalized value is written back.

Latency Communities (64511, 1-9)

Latency uses the most recent raw RTT measurement. Packet loss is not multiplied into RTT because packet loss now has its own independent community and quality rank.

Community Latency Range Description
(64511, 1) (0, 2.7 ms] ≤ 2.7 ms
(64511, 2) (2.7 ms, 7.3 ms] ≤ 7.3 ms
(64511, 3) (7.3 ms, 20 ms] ≤ 20 ms
(64511, 4) (20 ms, 55 ms] ≤ 55 ms
(64511, 5) (55 ms, 148 ms] ≤ 148 ms
(64511, 6) (148 ms, 403 ms] ≤ 403 ms
(64511, 7) (403 ms, 1097 ms] ≤ 1097 ms
(64511, 8) (1097 ms, 2981 ms] ≤ 2981 ms
(64511, 9) > 2981 ms > 2981 ms

The mathematical definition is:

latency in (exp(x - 1), exp(x)] milliseconds -> community (64511, x)

where x < 10.

No usable local RTT measurement is represented internally as 0. It does not create a DN42 latency community and is treated as a missing, worst-ranked value for local MED calculation.

Packet-Loss Communities (64511, 91-94)

Packet loss is calculated independently from the sliding window of recent RTT samples.

Community Average Packet Loss
(64511, 91) Exactly 0%
(64511, 92) (0%, 1%]
(64511, 93) (1%, 5%]
(64511, 94) (5%, 100%]

An explicit 0% measurement maps to community 91. This is different from having no packet-loss samples.

When local latency or packet-loss measurement is unavailable:

  • community propagation preserves any upstream value because the DN42 standard has no "unknown" community;
  • local eBGP MED calculation still assigns the missing rank to the unavailable local measurement;
  • an upstream good measurement therefore cannot hide an unknown local link.

Latency and packet loss are deliberately independent. The previous calculation:

effective_RTT = average_RTT * (1 + loss_rate * 2)

is no longer used, because it would penalize the same packet loss once through latency and again through the packet-loss community.

Bandwidth Communities (64511, 21-29)

For asymmetric connections, bandwidth is the lower of the upload and download capacity.

Community Bandwidth Range
(64511, 21) [0.1 Mbit/s, 1 Mbit/s)
(64511, 22) [1 Mbit/s, 10 Mbit/s)
(64511, 23) [10 Mbit/s, 100 Mbit/s)
(64511, 24) [100 Mbit/s, 1 Gbit/s)
(64511, 25) [1 Gbit/s, 10 Gbit/s)
(64511, 26) [10 Gbit/s, 100 Gbit/s)
(64511, 27) [100 Gbit/s, 1 Tbit/s)
(64511, 28) [1 Tbit/s, 10 Tbit/s)
(64511, 29) [10 Tbit/s, ∞)

Encryption Communities (64511, 31-36)

Community Encryption Level Example
(64511, 31) Not encrypted GRE, Ethernet cable
(64511, 32) Encrypted using an unsafe VPN solution PPTP
(64511, 33) Safe VPN without Perfect Forward Secrecy OpenVPN PSK
(64511, 34) Safe VPN with Perfect Forward Secrecy WireGuard, OpenVPN PKI, fastd
(64511, 35) Safe VPN with PFS and post-quantum resistance, but without post-quantum forward secrecy WireGuard with PSK
(64511, 36) Safe VPN with PFS and post-quantum forward secrecy WireGuard with Rosenpass

Topology Communities (64511, 81-89)

Community Topology Example
(64511, 81) Physical connection Ethernet cable, direct wireless link
(64511, 82) Connection over an Internet Exchange Point Ethernet connection through a large switch
(64511, 83) Connection over a tunnel WireGuard, fastd, GRE
(64511, 84) Connection over a meshed virtual Internet Exchange Point Tailscale, Tinc, n2n
(64511, 85) Connection over a centralized virtual Internet Exchange Point Tunnel to a server providing a virtual switch
(64511, 89) Unknown or other topology Other connection types

The current DN42 reference assigns explicit meanings to 81-85 and 89. Values 86-88 are within the accepted topology range but are not currently assigned a meaning in that reference.

Quality Refresh

Latency uses the latest raw RTT bucket, while packet loss uses the configured sliding history window. A metric sample does not trigger an immediate BIRD reload by itself.

Peer Relationship Policies

IEDON-NET implements RFC 9234-style routing policies based on peer relationship roles to control route import/export behavior.

Available Peer Roles

Role Value Description
ROLE_FULL 0 Full table and full transit
ROLE_TRANSIT 1 Transit provider (provides connectivity to DN42/upstream)
ROLE_PEER 2 Settlement-free peer (mutual benefit peering)
ROLE_DOWNSTREAM 3 Customer/downstream (we provide transit to them)
ROLE_UPSTREAM 4 Upstream provider (they provide transit to us), admin only

Route Import Policies

  • From PEER/DOWNSTREAM: Only accept their own networks
  • From TRANSIT/UPSTREAM: Accept all valid routes (they provide full transit)
  • From FULL: Accept all valid routes (no filtering restrictions)

Route Export Policies

  • To TRANSIT/PEER: Only export own routes and customer routes
  • To UPSTREAM: Only export own routes and customer routes
  • To DOWNSTREAM: Export all valid routes (provide full transit)
  • To FULL: Export all valid routes (no filtering restrictions)

BGP Communities Reference

Well-Known Communities

  • (65535, 666) - Blackhole community (RFC 7999) - Route will be blackholed
  • (65535, 65281) - NO_EXPORT - Do not advertise outside AS
  • (65535, 65282) - NO_ADVERTISE - Do not advertise to any peer

DN42 Standard Communities

See DN42 BGP Communities for the current definitions and propagation rules.

  • (64511, 1-9) - Path latency classification
  • (64511, 21-29) - Path bandwidth classification
  • (64511, 31-36) - Path encryption level
  • (64511, 41-70) - DN42 origin region
  • (64511, 81-89) - Path topology classification
  • (64511, 91-94) - Path packet-loss classification
  • (64511, 1000-1999) - DN42 origin country

Latency, bandwidth, encryption, topology, and packet-loss communities are processed along the route and normalized to the worst encountered value. Region and country communities describe the origin and must not be changed by transit networks.

IEDON-NET Specific Large Communities

  • (4242422189, 255, P) - IEDON-NET IGP cost (where P = IGP cost, 0 if route doesn't traverse our IGP) Disabled to reduce route updates
  • (4242422189, 100, Q) - IEDON-NET Node ID (where Q = IGP Node ID from which route was learned)
  • (4242422189, 101, R) - IEDON-NET Node Region (where R = IGP Node Region from which route was learned)
  • (4242422189, 102, S) - IEDON-NET Node Country (where S = IGP Node Country from which route was learned)
  • (4242422189, 10, T) - Peer relationship role (where T = role value 0-4)

Internal Tracking Communities

These communities are not exported to external peers.

  • (64496, region) - Previous-hop region tracking
  • (64497, country) - Previous-hop country tracking
  • (64498, cost) - Internal network cost accumulation used by the iBGP MED calculation

This routing policy preserves stable administrative and geographical decisions while using standardized, propagated path-quality information to make deterministic choices between otherwise equivalent routes.