BGP Fundamentals for Engineers

BGP is the backbone of internet routing. It connects autonomous systems—networks operated by different organisations—into a cohesive, scalable, and resilient global network. This page details the core mechanisms, configuration practices, and operational insights engineers need to understand and manage BGP in real deployments. Whether you're setting up a multi-site data center, integrating with a cloud provider, or troubleshooting a peering session that’s flapping, the fundamentals here apply directly.

Establishing a BGP Session

To establish a BGP session between two routers, both peers must agree on a set of parameters. The most common method is using TCP port 179, with the session initiated via a OPEN message. The first step is to configure the BGP process and peer address.

On a Linux-based router using Quagga (a widely deployed open-source BGP suite), the configuration is defined in /etc/quagga/zebra.conf and /etc/quagga/bgpd.conf. The BGP daemon (bgpd) reads these files and applies them at startup.


router bgp 65001
  bgp router-id 192.0.2.1
  network 198.51.100.0/24
  neighbor 203.0.113.1 remote-as 65002
  neighbor 203.0.113.1 update-source eth0
  neighbor 203.0.113.1 timers 30 90
  neighbor 203.0.113.1 advertisement-interval 30
  neighbor 203.0.113.1 ebgp-multihop 2

This configuration tells the router to:

Use AS number 65001.
Set the router ID to 192.0.2.1.
Advertise the prefix 198.51.100.0/24.
Establish a session with peer 203.0.113.1, which is in AS 65002.
Use eth0 as the source interface for the TCP connection.
Set keepalive interval to 30 seconds and hold time to 90 seconds.
Send updates every 30 seconds (minimum advertisement interval).
Allow EBGP sessions across multiple hops (two hops in this case).

The bgpd daemon logs session establishment in /var/log/quagga/bgpd.log. A successful session appears as:

BGP: 203.0.113.1 FSM: State Change to ESTABLISHED
BGP: 203.0.113.1: Session established

Failure modes are common. A session that stays in Idle state typically indicates a TCP connectivity issue or a misconfigured neighbor address. A session that transitions to Connect then Active usually means the peer is not listening on port 179 or the remote-as is incorrect. If the session flaps every 30 seconds, check the timers configuration and ensure both peers use matching keepalive and holdtime.

Advertising Routes

Once the BGP session is established, the router advertises its IP prefixes. The default behavior is to advertise directly connected routes, but you can also inject static routes or redistribute from other routing protocols.

To advertise a route via BGP, use the network command. The router looks for a route in the routing table that matches the network prefix and mask. If it finds one, it includes it in the BGP UPDATE message.

network 198.51.100.0/24
network 203.0.113.0/24
network 172.16.0.0/16

For routes not in the routing table, use redistribute:

redistribute connected
redistribute static
redistribute ospf 1

This command redistributes routes from the connected table, static routes, and OSPF process 1 into BGP. Each redistributed route is tagged with a MED (Multi-Exit Discriminator) value, defaulting to 0.

A common pitfall: a static route exists but is not being advertised. The cause is often that the route is not in the main routing table. If ip route add 10.0.0.0/24 via 192.0.2.10 dev eth1 is issued, but bgpd is only looking at table main, then the route must be explicitly installed:

ip route add 10.0.0.0/24 via 192.0.2.10 dev eth1 table main

Without this, the route is in table 10, but bgpd doesn't see it. Use show ip bgp summary to verify:

# show ip bgp summary
Neighbor     V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
203.0.113.1  4 65002     143       143       10    0    0 00:15:22    ESTABLISHED      12

If PfxRcd is less than expected, check show ip bgp for detailed route information.

Route Flapping and Convergence

When a route changes—say, a link fails—the router sends an UPDATE message to its BGP peer. The UPDATE contains:

A list of withdrawn prefixes.
A list of new or updated prefixes.
Path attributes such as AS_PATH, NEXT_HOP, LOCAL_PREF, MED, and COMMUNITY.

An UPDATE message for a route might look like:

UPDATE
  Withdrawn Routes: 198.51.100.0/24
  Network: 198.51.100.0/24
  Path Attributes:
    AS_PATH: 65001
    NEXT_HOP: 192.0.2.1
    LOCAL_PREF: 100
    MED: 50

The receiving router applies this update and recomputes its best path. It then propagates changes to its own peers.

When a link fails, the router may send multiple UPDATE messages in quick succession. If the link flaps every 5 seconds, the BGP session may update every 30 seconds, causing suboptimal routing. To reduce convergence time, adjust the advertisement-interval and minimum-route-advertisement-interval:

neighbor 203.0.113.1 advertisement-interval 10
neighbor 203.0.113.1 minimum-route-advertisement-interval 5

The advertisement-interval controls how often updates are sent, even if no routes changed. The minimum-route-advertisement-interval ensures that updates are sent at least every N seconds, regardless of changes.

A silent failure: if advertisement-interval is set to 30, but the minimum-route-advertisement-interval is 10, the router sends updates every 30 seconds even when no routes changed. But if a route changes and the interval is not yet up, the router waits until the next 30-second tick, delaying convergence.

Managing BGP Attributes

BGP uses path attributes to influence route selection. The most important are:

AS_PATH: the sequence of AS numbers traversed to reach the prefix. Used for loop detection and route preference.
NEXT_HOP: the IP address of the router that should be used to reach the advertised prefix.
LOCAL_PREF: a per-AS attribute used to choose the best exit point from the AS.
MED: used to prefer an entry point into an AS when multiple exist.
COMMUNITY: a tag applied to routes for policy-based routing.

To set these attributes, use neighbor commands:

neighbor 203.0.113.1 route-map OUTBOUND out
neighbor 203.0.113.1 route-map INBOUND in
neighbor 203.0.113.1 local-preference 200
neighbor 203.0.113.1 med 150
neighbor 203.0.113.1 send-community

The route-map commands apply policy-based filtering and attribute modification. For example, a route-map OUTBOUND can:

Set the LOCAL_PREF to 200 for all routes to a specific network.
Add a COMMUNITY value 65001:100 to routes from a specific prefix.

# route-map OUTBOUND
route-map OUTBOUND permit 10
  match ip address 100
  set local-preference 200
  set community 65001:100 additive
  set metric 100

ip access-list standard 100
  permit 192.0.2.0 0.0.0.255

This route-map applies to routes sent to the peer 203.0.113.1. The additive keyword ensures that existing communities are preserved when setting new ones.

A common misconfiguration: setting MED on the wrong side of the peering. If an ISP advertises a route with MED 100, but the customer sets MED 200 in its UPDATE, the receiving router uses the customer’s MED only if the MED is set locally. Without send-community, the COMMUNITY attribute is not sent, so the receiving network cannot apply policy.

Troubleshooting BGP Sessions

Use show ip bgp to inspect routing tables:

# show ip bgp 198.51.100.0/24
BGP table version is 10, local router ID is 192.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i IGP, e EGP, ? incomplete
Network          Next Hop            Metric LocPrf Weight Path
* 198.51.100.0/24  203.0.113.1            0    200      0 65002 65001 i

Here, * means the route is valid, > indicates it is the best path, and i marks it as internal (IGP origin).

Use show ip bgp summary to check session status:

# show ip bgp summary
Neighbor     V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
203.0.113.1  4 65002     143       143       10    0    0 00:15:22    ESTABLISHED      12

If InQ or OutQ grow over time, the peer is not processing updates fast enough. If Up/Down time changes rapidly, the session is flapping.

To debug a flapping session, use show ip bgp neighbor 203.0.113.1.

# show ip bgp neighbor 203.0.113.1
BGP neighbor is 203.0.113.1, remote AS 65002, local AS 65001, internal link
  BGP version 4, remote router ID 203.0.113.1
  BGP state: ESTABLISHED, table version: 10
  Last read: 00:00:11, last write: 00:00:11
  Keepalive interval: 30 seconds, hold time: 90 seconds
  Received 143 messages, sent 143 messages
  Update messages: received 10, sent 10
  Keepalive messages: received 123, sent 123
  Route refresh: received 0, sent 0
  Current outbound: 32, in queue: 1
  Current inbound: 24, in queue: 2
  BGP version: 4
  Neighbor capabilities:
    Multiprotocol capability (AFI/SAFI: IPv4/Unicast)
    Route refresh capability
    4-byte AS capability
  Received 12 path attributes
  Sent 12 path attributes

This shows that 10 UPDATE messages have been sent and received. If Update messages: received 10, sent 10, but InQ is 2 and OutQ is 1, the peer is not processing updates quickly.

A silent failure: if the NEXT_HOP in an UPDATE message points to a router that is not reachable, the receiving router cannot forward packets to the advertised prefix. Use show ip route to verify the reachability of the NEXT_HOP.

BGP in Practice: Common Patterns

Multi-homing: connect a site to two or more providers. Use local-preference to prefer one provider for internal traffic, and MED to prefer one provider for incoming traffic.
Route Filtering: use prefix-lists and route-maps to control what routes are advertised and how they are modified.
Route Aggregation: summarize multiple routes into a single, more general one. Use aggregate-address to reduce the size of the BGP routing table.

aggregate-address 198.51.100.0/22 summary-only

This command creates a summary route for the range 198.51.100.0/22, and only advertises it if at least one more specific route exists. The summary-only flag ensures that the specific routes are not advertised individually.

A frequent failure: forgetting to enable summary-only. Without it, both the specific routes and the aggregate are advertised, leading to redundant entries and increased routing table size.

In summary, BGP is not just a protocol—it is a policy engine, a convergence mechanism, and a foundation for scalable network design. Engineers must understand how sessions are established, how routes are advertised, how attributes shape path selection, and how to debug failures that manifest subtly in logs and counters. Mastering these fundamentals ensures stable, predictable, and performant network operations.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.