How to set up a BGP session

Setting up a BGP session means establishing a TCP connection on port 179 between two edge routers and exchanging routes according to an agreed policy. A safe eBGP session, however, requires much more than just setting the neighbor address and AS number. Without prefix filters, a max-prefix limit and RPKI validation, a single mistake on the peer's side can inject hundreds of thousands of bad routes into your routing table or reroute traffic. This guide explains how to configure an eBGP session that resists common mistakes and attacks.

Basics: addressing, ASN and authentication

An eBGP session runs between two autonomous systems with different AS numbers. On both sides you define the neighbor (peer) IP address, its AS number and the local AS number. By default eBGP uses a TTL of 1, so the peer must be directly connected. For remote peering you use ttl-security or ebgp-multihop. It is worth enabling session authentication and mechanisms that improve stability.

• Authentication: a TCP-MD5 password or the more modern TCP-AO (RFC 5925) protects the session against TCP hijacking.
• GTSM (RFC 5082): checking for TTL=255 makes it harder to inject BGP packets from outside the directly connected segment.
• BFD: detects link failure in milliseconds, far faster than BGP timers (the default hold-time is 90 s).
• The peer AS and address must match the configuration on the other side and the data in PeeringDB.

Prefix filters and the max-prefix limit

The most important part of a safe session is filtering routes in both directions. Never accept or announce routes without an explicit policy. Prefix filters are built from IRR objects (the peer's AS-SET), generating a list of allowed prefixes with tools such as bgpq4. For peers and customers you apply strict IRR-based filters, while from a transit provider you typically accept the full table. Every session should also have a max-prefix limit, which tears down the session when the peer announces more routes than agreed. This protects against route leaks.

In the outbound direction, announce only your own prefixes and the prefixes of customers you are authorized to route, ideally based on the same IRR data. This prevents you from accidentally becoming a transit for someone else's traffic, which is the classic route leak.

RPKI and bogon filtering

RPKI validation (Route Origin Validation) lets you reject routes marked invalid, meaning routes where the origin AS or prefix length does not match a signed ROA object. This requires running a validator (such as Routinator, FORT or rpki-client) and connecting it to the router via the RTR protocol. Valid and unknown (notfound) states are accepted, while invalid is rejected. Independently of RPKI you should filter bogons, addresses that should never appear in the global routing table.

• Reject prefixes from private and reserved space (RFC 1918, RFC 6890, RFC 6598).
• Reject private AS numbers in the path (64512-65534 and 4200000000-4294967294).
• Filter prefixes longer than /24 for IPv4 and /48 for IPv6, the typical acceptance threshold.
• Drop routes marked invalid by RPKI (drop invalids), as recommended by MANRS.
• Apply BCP 38 and uRPF at the edge to block traffic with spoofed source addresses.

BGP sessions with AS202520 SkyPass

AS202520 SkyPass runs BGP sessions according to the principles described here across both PoPs, in Warsaw and Wrocław, and at the Polish internet exchanges THINX, TPIX, WRIX and 1-IX. We filter routes from IRR data, validate origin with RPKI under a drop-invalids policy, and apply max-prefix limits and bogon filtering on every session. If you need peering, IP transit with the full table, or remote IXP access, we will help agree on the policy and AS numbers and bring the session up safely for both sides.