FreeTransit Learning Centre

Filtering, activation, monitoring, rollback and incident handling for a production BGP session, with the FreeTransit pre-activation checklist.

Safe BGP operations

A new BGP session should exchange nothing until your policy says otherwise. Filters, a careful activation and outside monitoring each catch different mistakes, so use all three.

Baseline policy

Reject by default

Write explicit import and export policy. A session that comes up should not exchange routes just because TCP connected.

RFC 8212 requires this behaviour for eBGP. Many current daemons follow it; check what yours does.

Announce exactly what you mean

Export only prefixes that:

belong to you or were explicitly delegated to you
are meant to be originated by your ASN
have matching IRR objects and ROAs
have an agreed prefix length
are in your routing table because you put them there on purpose, for example as a static blackhole or a network statement

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

Different policy per relationship

Customers, peers and providers each get their own policy.

From a customer: accept only their registered prefixes and those of their customers.
From a peer: the same, for the peer.
From a provider: accept what you agreed on, whether a default route, partial routes or a full table.
From anyone: never accept your own prefixes back as usable routes.

Prefix limits

Set a limit at your expected route count plus room for planned growth, and alert before you hit it. Find out what your platform does when the limit is exceeded: tear down the session, drop the extra routes, or wait for you to reset it.

FreeTransit accepts at most 30 prefixes per customer session and restarts the session if you send more.

Bogons and special-purpose addresses

Filter prefixes and ASNs that have no business in the global routing table. Take the lists from a maintained source and update them; don't paste a list once and forget it.

NLNOG BGP Filter Guide
DENOG Routing Guide, community best practices with examples for several platforms. Some topics are more complete than others.
NLNOG bogon ASN guide
Team Cymru bogon lists

RPKI origin validation

Watch the validation states, fix your own legitimate Invalids, then reject Invalid routes as a planned change. Run more than one validator and alert when its data goes stale.

Session protection

Where both sides support it, consider:

TCP authentication (MD5 or TCP-AO)
GTSM or another TTL check
access lists that allow TCP port 179 only from the neighbour
BFD, once you understand how quickly it reacts to packet loss
BGP Roles and OTC

These protect the session itself. None of them filters routes.

Best-practice material

FreeTransit pre-activation checklist

Registry and authorisation

You can log in to your RIPE Database maintainer and your contact objects are current.
Your aut-num has direct import and export lines for AS41051.
Every prefix you will announce has a route or route6 object with your ASN as origin.
ROAs allow your ASN and only the prefix lengths you need.
Your ASPA lists AS41051 and all your other real providers.
In PeeringDB, your contacts are current and Never via route servers is off.

Router policy

IPv4 and IPv6 each have their own reviewed policy.
Import and export reject by default.
Export towards FreeTransit allows only your approved prefixes, originated by your ASN.
Paths you send us contain only your ASN, prepended if you like. No downstream ASNs or customer cones.
You don't rely on an AS-SET for FreeTransit filtering.
Routes learned from a downstream, peer, upstream or another tunnel can't reach the FreeTransit session.
You have a prefix limit on routes received from us, and you announce well under our limit of 30.
Your own prefixes and bogons are handled on purpose.
You know what each community you send means. Our action communities (do not announce, prepend, per-node and IXP-only or upstream-only) are listed on the features page and documented in the portal manual after sign-in.
You tested the configuration in a lab with the same routing software and major version.

Change control

The activation time is written down.
Out-of-band access works.
A known-good configuration is saved.
Rollback commands are ready.
Monitoring is running before the session is enabled.
Someone else has read the export policy, if you have someone.
Both sides have contact details that don't depend on the network you are changing.

After activation

Check the session state for IPv4 and IPv6.
Check received and advertised route counts.
Look at what you advertise to each neighbour, not only at your own routing table.
Check your origin and AS path from outside, using RIPEstat, a looking glass or bgp.tools.
Check the RPKI state of your prefixes. The session page in the portal shows which of your routes we accepted and which we filtered.
Make sure no unexpected more-specifics are visible.
Test reachability from several outside networks.
Watch logs and route counts for a while, at least a few monitoring intervals.

Keep a second upstream

FreeTransit is a best-effort service. If public routing data shows us as your only upstream, we will remind you every few days to add another one.

Monitoring tools

When something goes wrong

If you suspect a leak or a wrong announcement:

Stop the bad export where it starts. If shutting the session or address family is the quickest safe fix, do that.
Change one thing at a time while the incident is running.
Confirm the withdrawal in public route collectors.
Tell affected upstreams and peers, FreeTransit included: your ASN, the prefixes, when it started and what you did.
Keep router logs, configuration diffs and timestamps.
If stale IRR, ROA or ASPA data played a part, fix it.
Write a short report: cause, impact and what will stop it happening again.
Add a lab test or an automated check that would have caught it.

Learn before you apply