Introduction
IEDON-NET (AS4242422189) implements an intelligent BGP routing policy designed to optimize traffic flow through geographical awareness, link quality assessment, and comprehensive route validation. This document describes our routing implementation and peering policies.
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 determines route preference within IEDON-NET and implements our cold potato routing strategy to keep traffic within the same geographical region when possible.
Local Preference Values
| Local Pref | Route Class | Description |
|---|---|---|
| 3000 | Directly Connected Routes | Routes from directly connected peers (AS path length = 1) |
| 2000 | Same Region/Country Routes | Routes originating from the same DN42 region or country |
| 1000 | Default Routes | All other valid 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: Traffic is routed via IGP to the nearest region or country, keeping it within our network longer
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 |
BGP Multi-Exit Discriminator (MED)
The MED attribute implements a comprehensive cost metric that considers link quality, latency, bandwidth, and encryption level. We update link latency values every hour based on average RTT with penalties for packet loss.
MED Calculation
For iBGP Routes (Internal)
bgp_med = 200000 + igp_cost
- Base value: 200000 (identifies internal routes)
- IGP cost: Accumulated internal network cost
For eBGP Routes (External)
bgp_med = 100000 + crypto_penalty + bandwidth_penalty + latency_penalty
Where:
- Base value: 100000 (identifies external routes)
- Crypto penalty:
(40000 - (dn42_crypto_level - 30) * 10000) - Bandwidth penalty:
(9000 - (dn42_bandwidth_level - 20) * 1000) - Latency penalty:
dn42_latency_level(calculated by effective RTT described in section "Link Quality Assessment") * 100
⚠ Warning
DO NOT ADD/TAG COUNTRY AND REGION COMMUNITIES ON ROUTES THAT NOT BELONG TO YOU
Here is how to correctly set DN42 region community flag, copied from 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 does). - Otherwise, if you export routes across multiple regions within your network, you may be sending incorrect origin information to other peers.
Beyond that, you may also be breaking region optimization for route decision.
Link Quality Assessment
We use DN42 standard communities to assess and control traffic routing based on link characteristics:
Latency Communities (64511, 1-9)
| Community | Latency Range | Description |
|---|---|---|
| (64511, 1) | 0 - 2.7ms | Excellent (local/metro) |
| (64511, 2) | 2.7ms - 7.3ms | Very good (regional) |
| (64511, 3) | 7.3ms - 20ms | Good (national) |
| (64511, 4) | 20ms - 55ms | Acceptable (continental) |
| (64511, 5) | 55ms - 148ms | Poor (intercontinental) |
| (64511, 6) | 148ms - 403ms | Very poor |
| (64511, 7) | 403ms - 1097ms | Satellite-like |
| (64511, 8) | 1097ms - 2981ms | Extremely poor |
| (64511, 9) | > 2981ms | Unusable |
However, to calculate final latency level, we will apply another loss penalty to the raw average latency used:
effective_RTT = average_RTT * (1 + loss_rate * penalty_factor), where penalty_factor is 2.0 .
Bandwidth Communities (64511, 21-29)
| Community | Bandwidth | Description |
|---|---|---|
| (64511, 21) | ≥ 0.1 Mbps | Very low bandwidth |
| (64511, 22) | ≥ 1 Mbps | Low bandwidth |
| (64511, 23) | ≥ 10 Mbps | Medium bandwidth |
| (64511, 24) | ≥ 100 Mbps | High bandwidth |
| (64511, 25) | ≥ 1000 Mbps | Very high bandwidth |
Encryption Communities (64511, 31-34)
| Community | Encryption Level | Description |
|---|---|---|
| (64511, 31) | Not encrypted | Plain text connection |
| (64511, 32) | Unsafe VPN | Basic encryption without security |
| (64511, 33) | Safe VPN (no PFS) | Secure VPN without Perfect Forward Secrecy |
| (64511, 34) | Safe VPN with PFS | Secure VPN with Perfect Forward Secrecy |
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 the DN42 Wiki: BGP Communities for complete details.
(64511, link_latency)- Link latency classification (1-9)(64511, link_bandwidth)- Link bandwidth classification (21-29)(64511, link_crypto)- Link encryption level (31-34)(64511, region_code)- DN42 region code (41-70)(64511, country_code)- DN42 country code (1000-1999)
IEDON-NET Specific Large Communities
(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
(64496, region)- Previous hop region tracking(64497, country)- Previous hop country tracking(64498, cost)- Internal network cost accumulation
This routing policy ensures optimal performance while maintaining security and providing predictable traffic engineering capabilities for IEDON-NET and our peers.