FreeTransit Learning Centre

A production checklist for filtering, activation, monitoring, rollback and incident handling.

Safe BGP operations

A BGP session should exchange no routes until deliberate policy permits them. Production safety comes from multiple independent controls, careful activation and external monitoring.

Baseline policy

Default reject

Use explicit import and export policy. A new neighbour should not receive or advertise useful routes merely because the TCP session established.

Read RFC 8212 — Default External BGP Route Propagation Behavior Without Policies.

Exact outbound announcements

Permit only prefixes that:

belong to your organisation or are explicitly delegated to you;
are intended to be originated by your ASN;
have matching IRR and RPKI data;
use an approved prefix length;
are present in the routing table through an intentional origination method.

End the export policy with a deny. Avoid broad redistribution from connected, static, OSPF or another BGP session.

Relationship-based inbound policy

A customer, peer and provider should not have the same policy.

From a customer, accept only the customer's authorised prefixes and customer cone.
From a peer, accept only the peer's authorised prefixes and customer cone.
From a provider, accept the agreed default route, partial routes or full table.
Never accept your own prefixes back from another network as usable routes.

Prefix limits

Set a limit based on the expected route count with enough headroom for planned growth. Alert before the hard limit. Understand whether exceeding the limit closes the session, discards routes or requires manual recovery on your platform.

Bogon and special-purpose filtering

Filter prefixes and ASNs that should not appear in the public Default-Free Zone. Keep lists updated from an authoritative source rather than pasting a static list permanently.

Useful references:

RPKI origin validation

Monitor validation state, correct legitimate Invalids and then reject RPKI Invalid routes through controlled rollout. Maintain validator redundancy and monitor data freshness.

Session protection

Where both sides support it and the relationship requires it, consider:

TCP authentication;
Generalized TTL Security Mechanism or equivalent TTL protection;
access-control rules limiting TCP/179 to the neighbour;
BFD only after understanding its failure sensitivity;
BGP Roles and OTC.

These protect the session or improve signalling. They do not replace route filters.

Recommended best-practice material

FreeTransit pre-activation checklist

Registry and authorisation

RIPE Database maintainer and contact objects are accessible.
aut-num data is correct.
route and route6 objects exist for all intended announcements.
ROAs authorise the correct origin and only required prefix lengths.
ASPA contains the correct provider ASNs shown by the actual routing design.
PeeringDB and operational contacts are accurate where applicable.

Router policy

IPv4 and IPv6 have separate, reviewed policy.
Import and export default to deny.
Export permits only the approved prefix list originated directly by the applicant ASN.
The AS path received by FreeTransit has a maximum depth of 1; downstream ASNs and customer cones are not permitted.
No AS-SET is supplied or used to expand the accepted prefix list.
No routes learned from any downstream, peer, upstream or other tunnel can be exported to FreeTransit.
Prefix limits are configured.
Own prefixes, bogons and invalid path patterns are handled deliberately.
The FreeTransit community policy is documented before communities are sent.
The configuration has been tested in a lab using the same routing software and major version where possible.

Change control

The activation window is documented.
Out-of-band management works.
A known-good configuration is saved.
Rollback commands are prepared.
Monitoring is open before the session is enabled.
A second reviewer has checked the export policy where possible.
Contact details for both sides are available outside the affected network.

Verification after activation

Confirm session state for IPv4 and IPv6.
Check received and advertised route counts.
Inspect advertised routes per neighbour, not only the local RIB.
Verify your origin and AS path through RIPEstat, a looking glass or another collector.
Confirm RPKI state.
Check that no unexpected more-specific is visible.
Test reachability from multiple external networks.
Watch logs and route counts through at least one full keepalive and monitoring interval.

Monitoring tools

Incident response basics

When a route leak or incorrect announcement is suspected:

Stop the bad export at the source. Shut the affected address family or session if that is the fastest safe action.
Do not make multiple unrelated changes while the incident is active.
Verify withdrawal through external collectors.
Contact affected upstreams and peers with the ASN, prefixes, start time and corrective action.
Preserve router logs, configuration differences and timestamps.
Correct IRR, ROA or ASPA data if the incident exposed stale authorisation.
Write a short incident report explaining cause, impact and preventive action.
Add a lab test or automated policy check that reproduces the failure.

Learn before you apply