Routing Policy

AS47778 is designed as a backbone with explicit route tagging and conservative export rules. The policy prefers predictable behavior over automatic propagation.

This page describes the public behavior of the backbone routing design. Internal exceptions and site-specific tuning are intentionally not listed here, but the general model follows the BIRD filters used on the network.

Session roles

External BGP sessions are handled by role:

• Upstream routes are accepted with a lower local preference and are mainly used for Internet reachability.
• Peer routes are preferred over upstream routes when they pass validation.
• Downstream and locally originated routes receive the highest preference when they are within the expected routing scope.
• Internal sessions carry routes across AS47778 nodes with source and node metadata preserved.

Each accepted route is tagged with its source role. These tags are later used by export filters, so a route learned from one role is only announced to another role when the policy allows it.

Backbone preference

AS47778 uses cold-potato routing. When multiple usable exits exist, the network generally prefers to keep traffic on the backbone until a better exit point is available, instead of handing traffic off at the first possible upstream.

Internal route selection considers:

• The route source type: downstream and originated routes are preferred over peer routes, and peer routes are preferred over upstream routes.
• AS path length of the public path view.
• The node path carried in large communities.
• MED values carried across internal sessions, which represent the relative latency across the backbone.
• Regional distance between where a route entered the backbone and where it is being used. Cross region routes are generally less preferred than IP transit routes due to penalty when it happens.

The result is a route selection model that favors local or regional exits when appropriate, while still avoiding unnecessarily weak or indirect paths.

Node and region metadata

Routes are tagged with large communities that record where they were learned and which nodes they traversed. The public BGP communities document lists these tags as:

• 47778:200:nnn for the node where a route was learned.
• 47778:201:nnn for the node where a route was exported.
• 47778:210:nnn for nodes used by a route inside AS47778.
• 47778:0:nnn for MED carried through the backbone.

These tags make routing behavior easier to inspect and help keep internal policy consistent across nodes.

Export policy

Export is explicit. AS47778 does not simply re-announce every accepted route to every neighbor.

Export filters use the route source tags and documented BGP communities to decide whether a route may be announced to upstreams, peers, downstreams, or other backbone nodes.

For example:

• Downstream and locally originated routes may be exported to upstreams and peers when the route is valid.
• Peer and upstream routes are not treated as downstream customer routes.
• Communities can suppress export to a session type or request AS-path prepending.
• Blackhole routes are handled through the documented blackhole community.
• Cross region routes will be penalized by path prepending when exported to upstreams and peers.

The public controls are listed in AS47778 BGP communities.

Filtering boundary

Routing policy starts with route security. Before a route can participate in backbone selection or export policy, it must pass validation for prefix length, bogon space, reserved ASNs, RPKI invalid status, and session role.

Details are documented in Route Security.

Operator expectations

Peers and downstreams should expect stable, documented behavior:

• Keep route-set or AS-SET data current.
• Keep RPKI ROAs accurate.
• Use documented communities for export control and prepending.
• Contact the NOC before relying on undocumented routing behavior.

For new peering or transit sessions, start with the peering policy and contact page.