Infrastructure · Networking

How to Configure BGP: Sessions, Filtering, RPKI, and Traffic Engineering

BGP is the protocol that stitches the internet’s networks together, and configuring it gives you control over how your traffic enters and leaves your network — multihoming across providers, optimising paths, and keeping consistent addressing. It’s also unforgiving: a misconfiguration can leak routes, blackhole traffic, or take you offline. This guide walks the configuration carefully, from the prerequisites through session setup, filtering, RPKI, and traffic engineering, with the safety habits that keep a BGP change from becoming an outage.

What do you need before configuring BGP?

BGP isn’t something you can simply switch on — it requires resources and registrations that have to be in place first. You need your own public Autonomous System Number, registered with a Regional Internet Registry, which uniquely identifies your network to the rest of the internet. You also need provider-independent IP address space that you control: at minimum a /24 of IPv4 or a /48 of IPv6, because peers reject anything longer as too specific to carry in the global table. Your WHOIS records should be accurate, reflecting your real contacts and the intended use of the space.

The security prerequisite that’s now effectively mandatory is RPKI. You create a Route Origin Authorization — a signed statement pairing your prefixes with the ASN authorised to originate them — which lets other networks verify that your announcements are legitimate and protects against route hijacks. With those in hand, you give your upstream the practical details to set up peering: your ASN, the exact prefixes you’ll announce, the peering interface IPs (often loopback addresses), and any routing-policy preferences. Only once these are settled does the router configuration begin, much as bringing your own IP space requires, which our BYOIP guide covers.

eBGP versus iBGP

The first conceptual split to understand is between the two kinds of BGP session, because they behave differently and trip people up in different ways. External BGP, or eBGP, runs between routers in different autonomous systems — you and your upstream provider, for instance — and it’s the kind most people mean by “configuring BGP.” By default an eBGP session expects the neighbour to be directly connected (a TTL of one), so if there’s a router in between you enable multihop. Internal BGP, or iBGP, runs between routers within your own AS to distribute externally learned routes inside your network.

iBGP has one notorious quirk worth flagging early: by default it doesn’t change the next-hop address of routes it passes along, so an internal router can learn a route whose next-hop it can’t actually reach. The fix is to configure next-hop-self on your border routers, telling them to set themselves as the next-hop for routes they inject into iBGP, and to ensure those loopbacks are reachable through your internal routing protocol. In fact, most “session is up but no traffic flows” problems on iBGP trace back to exactly this unresolved next-hop, which makes it the first thing to check.

How do you establish a session?

Bringing up a session is a matter of telling each router about the other and watching the state machine progress. The session walks through a defined sequence of states — Idle, Connect, Active, OpenSent, OpenConfirm, and finally Established — and only at Established does it exchange routes. The diagram shows that progression.

To reach Established, a handful of things must line up: TCP port 179 has to be reachable between the neighbours, the configured AS numbers must match what each side expects, the update-source and any TTL or multihop settings must be correct, and an MD5 key if used must agree. You also activate the address families you intend to carry — IPv4 and IPv6 separately — under the neighbour. A session stuck at Active or Connect almost always means a transport problem (can you reach port 179?) or an ASN mismatch, which makes those the first two things to verify when a session won’t come up.

Announcing prefixes and filtering routes

With the session up, you announce your address space and, just as importantly, filter what flows in both directions. Announcing is straightforward — a network statement for each aggregate you own — but the discipline is to advertise only your aggregates and deliberately chosen more-specifics, never your full table or a default route to a peer who shouldn’t receive it. On the inbound side, filtering is what protects you from the rest of the internet’s mistakes, and it has several layers that work together.

The essential inbound filters are a prefix-list that accepts only what you expect, a bogon filter that drops private and special-use ranges that should never appear in the global table, and — critically — a maximum-prefix limit that caps how many routes a neighbour can send you. That last one is your safety net: most sudden BGP outages happen when a route leak elsewhere on the internet floods a neighbour’s table, and a maximum-prefix limit with a sensible threshold and an alarm lets you react before your router is overwhelmed. You should also reject private ASNs on eBGP and enforce a maximum AS-path length, the kind of layered defence our DDoS protection guide applies at other layers.

Securing announcements with RPKI

RPKI origin validation is the modern baseline for BGP security, and configuring it is no longer optional for a responsible operator. The mechanism works by having your router connect to an RPKI validator — a cache server that holds the published Route Origin Authorizations — which gives the router a validated database of which ASNs are authorised to originate which prefixes. Every route the router learns is then checked against this database and assigned a state: Valid, when the prefix and origin AS match an authorization; Invalid, when an authorization exists but the origin AS or prefix length doesn’t match; or Not Found, when no authorization covers the prefix at all.

The recommended policy is clear and widely adopted: reject Invalid routes outright, since they’re likely hijacks or serious misconfigurations; accept Not Found routes but monitor them, since much of the internet isn’t yet covered by ROAs; and prefer Valid routes. The honest limitation to understand is that RPKI validates only the origin of a route — that the right AS announced it — not the entire path it travelled, so it doesn’t stop an attacker who spoofs a valid origin AS within a forged path. Path validation requires BGPsec, which remains rare in practice, so RPKI origin validation is the strong, practical protection you deploy today.

How does BGP choose the best path?

Before you can steer traffic, it helps to understand how BGP decides between competing routes to the same destination, because traffic engineering is really just nudging this decision process. When a router knows several paths to one prefix, it walks an ordered list of tie-breakers and stops at the first one that produces a winner. On Cisco-style routers the order begins with Weight — a purely local value, never advertised, that overrides everything else on that one router — followed by local-preference, then whether the route was locally originated, then the shortest AS-path.

If those still tie, it continues down the list: lowest origin type (a route learned via IGP beats one that was redistributed), then lowest MED, then a preference for eBGP routes over iBGP, then the lowest internal routing cost to the next-hop, and finally tie-breakers like the oldest route and the lowest router ID. The two steps that matter most for engineering are near the top — local-preference and AS-path length — which is exactly why those are the levers you reach for. Knowing the order also makes troubleshooting tractable: when a route installs that you didn’t expect, you walk the list and find which attribute decided it.

How do you steer traffic with BGP?

Once routing works, traffic engineering lets you control which paths your traffic takes, and the two main levers pull in opposite directions. For outbound traffic — how you leave your network — the primary tool is local-preference: you raise the local-pref on routes learned from your preferred upstream, and because higher local-pref wins early in the best-path selection, your traffic exits through that provider while the other stays up as failover. The table summarises the key attributes BGP weighs when choosing a path.

For inbound traffic — how the internet reaches you — your main lever is AS-path prepending: you advertise a route to a backup provider with your own ASN added several times, making that path look longer and therefore less attractive, so remote networks prefer your primary. It’s the classic way to keep a backup ISP on standby. MED is a weaker inbound hint that only applies between paths from the same neighbouring AS and is often ignored, while communities let you tag routes to trigger policies like no-export or provider-defined local-pref changes at scale. The key caution is to keep policy simple and explainable, since aggressive prepending can create asymmetric return paths that break stateful firewalls.

Using BGP communities

Communities are the mechanism that makes BGP policy manageable at scale, and they’re worth configuring deliberately rather than treating as an afterthought. A community is simply a tag — a 32-bit value, or a larger “large community” — that you attach to a route, which other routers can then match on to make policy decisions. Rather than maintaining sprawling per-prefix rules, you tag a group of routes once and write policy against the tag, so adding a new prefix to that group automatically inherits the right treatment.

Two kinds of community do most of the work. The well-known ones have fixed meanings everywhere: no-export tells a neighbour not to advertise the route beyond its own AS, and no-advertise says don’t pass it on at all — both useful for keeping traffic-engineering specifics contained. The more powerful kind are provider-defined communities, where your upstream publishes a list of tags that trigger actions on their side: “set local-pref to 120,” “prepend twice toward peer A,” or “blackhole this /32.” Large communities are increasingly preferred because their extra structure avoids the ASN collisions that plagued the original 32-bit format when operators run multiple ASNs. The discipline that makes communities safe is documentation — publish what each tag means so both sides, and your own on-call engineers under pressure, can reason about the policy.

Verifying and operating safely

The last step is confirming everything works and operating it without causing outages. The terminal shows the core verification and a minimal session config.

# Minimal eBGP session + announcement (FRR/Cisco-style)
router bgp 65001
 neighbor 192.0.2.1 remote-as 200
 neighbor 192.0.2.1 description UPSTREAM-A
 neighbor 192.0.2.1 prefix-list BOGONS in
 neighbor 192.0.2.1 maximum-prefix 1000000 restart 15
 network 203.0.113.0/24
# Verify
$ show ip bgp summary        # neighbor State = Established
$ show ip bgp neighbors 192.0.2.1 advertised-routes
$ show ip bgp 203.0.113.0/24  # confirm path + RPKI valid
# Then check public looking glasses for your prefix.

Verification has two halves: locally, you confirm the neighbour reached Established and that your prefixes are advertised and received as intended; externally, you check public looking glasses and route servers to see that your prefix appears across the internet with the path and communities you intended. Operationally, a few habits prevent disasters: comment every route-map with who made it and why, automate your prefix-lists from IRR and RPKI data rather than maintaining them by hand, use soft reconfiguration and route refresh instead of hard session resets, and stage every policy change in a lab before applying it to one edge router, observing for a full timer cycle before touching the second. For teams that want resilient, multihomed connectivity as the foundation for this kind of control, our dedicated servers in Toronto sit on a well-peered network — while disciplined filtering, RPKI, and staged changes are what keep BGP an asset rather than an outage waiting to happen.