This page describes the Routing Policy for AS4242421080.
This is a rough overview, when in doubt you can check my actual filter code: custom_filters.conf.j2
- Prefer the shortest AS path.
- For routes containing the dn42 region communities, prefer routes originating in the same super-region (see below) as an edge node. This is effectively cold potato routing:
- Routes with matching dn42 region to an edge node or no dn42 region community at all are assigned
bgp_med = 50. Other routes are assignedbgp_med = 100.
- Prefer routes received via eBGP over iBGP.
- Prefer routes from edge routers closest to the current node (lowest internal distance). Internal costs are periodically recalculated from inter-node latency.
- When latency is tied, prefer the first received route (RFC 5004).
Routes with unusually large path lengths (> 12) are rejected as they usually signal ghost routes.
Some exceptions apply (see in handle_special_cases).
These are defined in get_region_tag of custom_filters.conf.j2:
- 1: North America (West) - dn42 community
(64511, 44) - 2: North America (East) - dn42 community
(64511, 42..43) - 3: Europe - dn42 community
(64511, 41) - 4: Asia-Pacific - dn42 community
(64511, 51..53) - 0: Everything else (no presence in my AS)
The standard dn42 BGP Communities for max. inter-AS link latency, bandwidth, and encryption are supported. All of my nodes so far are marked as >= 10 Mbps bandwidth, as capacity varies and I cannot guarantee anything higher.
I currently export some informational large communities:
- (4242421080, 101, X) - Route learned in this dn42 region
- (4242421080, 103, Y) - Route learned on this node, where Y is the last octet of the node's dn42 IPv4 address.
- e.g. (4242421080, 103, 117) for de-nbg01
Strict ROA checking is enabled - routes must be ROA_VALID in order to be accepted.