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:
- Route validation and peer policy determine whether a route is allowed to participate.
- Local preference (
local_pref) applies stable administrative and geographical policy. - AS path length retains its standard BGP priority.
- MED compares the propagated quality of otherwise equivalent paths.
- 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_VALIDandROA_UNKNOWNroutes, filtering out allROA_INVALIDroutes - 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:
- Region Priority: Routes are evaluated based on DN42 region communities
(64511, 41-70) - Country Fallback: When region information is unavailable, country communities
(64511, 1000-1999)are used - 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:
- Higher
bgp_local_pref - Shorter
AS_PATH - Better BGP origin
- Lower
bgp_med - eBGP over iBGP
- Lower internal distance to the border router
- 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 community91..94E: encryption community31..36B: bandwidth community21..29R: latency community1..9T: topology community81..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
Qwins; - 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_STATICcheck 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
Disabled to reduce route updates(4242422189, 255, P)- IEDON-NET IGP cost (whereP= IGP cost, 0 if route doesn't traverse our IGP)(4242422189, 100, Q)- IEDON-NET Node ID (whereQ= IGP Node ID from which route was learned)(4242422189, 101, R)- IEDON-NET Node Region (whereR= IGP Node Region from which route was learned)(4242422189, 102, S)- IEDON-NET Node Country (whereS= IGP Node Country from which route was learned)(4242422189, 10, T)- Peer relationship role (whereT= 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.