Skip to main content

BGP Operations

Authoritative Resources​

Protocol Specification:

Operator Guides:

Configuration Examples:

Quick Reference​

BGP Session States​

Idle → Connect → Active → OpenSent → OpenConfirm → Established

Idle: BGP refuses all incoming connections, waiting for a start event. Connect: BGP is waiting for TCP three-way handshake to complete. Active: TCP session failed, BGP attempts another connection. OpenSent: TCP established, BGP OPEN message sent, waiting for peer's OPEN. OpenConfirm: OPEN received and accepted, waiting for KEEPALIVE or NOTIFICATION. Established: Session up, exchanging UPDATE, KEEPALIVE, and NOTIFICATION messages.

Path Selection Algorithm​

BGP selects best path using these criteria in order:

  1. Weight (Cisco-specific, highest preferred)
  2. Local Preference (highest preferred)
  3. Locally originated (prefer local over received)
  4. AS Path length (shortest preferred)
  5. Origin (IGP > EGP > Incomplete)
  6. MED (lowest preferred, compared only if same neighboring AS)
  7. Path type (eBGP > iBGP)
  8. IGP metric to BGP next hop (lowest preferred)
  9. Oldest route (for eBGP paths)
  10. Router ID (lowest preferred)
  11. Peer IP address (lowest preferred)

Common Attributes​

NEXT_HOP: IP address of next-hop router for this path AS_PATH: List of ASes the route has traversed LOCAL_PREF: Preference for outbound traffic (higher = more preferred) MED (Multi-Exit Discriminator): Suggest to neighbors which entry point to prefer COMMUNITIES: Tags for route marking and policy application ATOMIC_AGGREGATE: Route is result of aggregation, some path info lost AGGREGATOR: AS and router that performed aggregation

Session Configuration Basics​

eBGP (External BGP):

  • Between different ASes
  • TTL typically 1 (directly connected)
  • AS_PATH incremented
  • NEXT_HOP changed to local router
  • MED, LOCAL_PREF, COMMUNITY can be set/modified

iBGP (Internal BGP):

  • Within same AS
  • TTL typically 255 (loopback peering)
  • Requires full mesh or route reflectors
  • NEXT_HOP preserved (unless next-hop-self)
  • Routes not re-advertised to other iBGP peers

Essential Timers​

Keepalive: 60 seconds (default) Hold timer: 180 seconds (default, 3x keepalive) ConnectRetry: 120 seconds (default) MinASOriginationInterval: 15 seconds (minimum time between UPDATE messages advertising same route) MinRouteAdvertisementInterval: 30 seconds for eBGP, 5 seconds for iBGP

Key Operational Concerns​

Session Flapping​

Causes:

  • Interface instability
  • Hold timer expiration (keepalives not received)
  • Configuration errors
  • Resource exhaustion (CPU, memory)

Mitigation:

  • BFD (Bidirectional Forwarding Detection) for fast failure detection
  • Adjust timers appropriately for link characteristics
  • Monitor BGP session state changes

Prefix Limits​

Always configure maximum prefix limits per session:

# Cisco IOS XR example
neighbor 192.0.2.1
 address-family ipv4 unicast
  maximum-prefix 1000 75 warning-only

Protects against:

  • Route leaks
  • Misconfigurations
  • Memory exhaustion

Route Reflectors​

Alternative to full iBGP mesh. Reduces iBGP sessions from n(n-1)/2 to n.

Rules:

  • Routes from eBGP peers → reflected to all clients and non-clients
  • Routes from RR clients → reflected to all clients (except originator) and non-clients
  • Routes from non-clients → reflected to clients only

Caveats:

  • Creates hidden dependencies
  • ORIGINATOR_ID and CLUSTER_LIST prevent loops
  • Placement affects path selection
  • Consider redundant route reflectors

iBGP Scaling​

Full mesh: n(n-1)/2 sessions. Doesn't scale beyond ~50 routers.

Route Reflectors: Hierarchical design possible. Reduces sessions significantly.

Confederations: Divide AS into sub-AS. Rarely used in practice.

Current practice: Route reflectors with BGP ADD-PATH (RFC 7911) to preserve path diversity.

Integration Points​

With IGP:

  • BGP NEXT_HOP must be reachable via IGP
  • Synchronization (deprecated) required iBGP route in IGP
  • IGP metric used in path selection (criterion 8)

With Routing Security: See Routing Security Best Practices for RPKI, filtering, and anti-spoofing.

With Traffic Engineering: See Traffic Engineering for using BGP attributes to steer traffic.

Common Configurations​

Basic eBGP Peering​

# Minimalist eBGP session (vendor-agnostic concepts)
# Configure on both sides with appropriate values

neighbor <peer-ip>
  remote-as <peer-asn>
  description "Peer Name - PeeringDB ID"
  password <md5-password>

  address-family ipv4 unicast
    maximum-prefix <limit> <threshold> warning-only
    # Apply import/export policies

  address-family ipv6 unicast
    maximum-prefix <limit> <threshold> warning-only
    # Apply import/export policies

Basic iBGP Peering (Route Reflector)​

# On route reflector
neighbor <client-ip>
  remote-as <local-asn>
  description "RR Client - <router-name>"
  update-source Loopback0

  address-family ipv4 unicast
    route-reflector-client
    next-hop-self

Refer to vendor documentation and the authoritative guides above for complete configurations.

Troubleshooting​

Session won't establish:

  1. Check TCP connectivity (port 179)
  2. Verify ASN configuration matches
  3. Check MD5 passwords match
  4. Review ACLs blocking BGP
  5. Verify TTL (especially eBGP multihop)

Routes not being received:

  1. Check neighbor is advertising (show bgp neighbor <ip> advertised-routes)
  2. Verify inbound policy not filtering
  3. Check route is actually in peer's table
  4. Confirm address-family is activated

Routes received but not used:

  1. Run through path selection algorithm
  2. Check if better path exists from another peer
  3. Verify NEXT_HOP is reachable
  4. Check for route policy modifying attributes

Further reading: Philip Smith's BGP troubleshooting presentations (NANOG archive)

Sources: