BGP Best Practices: Complete Configuration Guide

Border Gateway Protocol is the glue of the internet—and the most dangerous tool in your network arsenal. A single misconfiguration can take down continents. This guide provides comprehensive best practices for hybrid cloud connectivity.

1. ASN (Autonomous System Number) Strategy

Public vs Private ASNs

ASNs identify your network to the global routing system. Choosing the right type is critical:

Private ASNs (64512–65534, 4200000000–4294967294)

• Use for: Internal networks, connections to cloud providers via Direct Connect/ExpressRoute
• Advantage: No registration required, immediate availability
• Requirement: Must be stripped (or replaced) before routes reach the public internet

# AWS Direct Connect uses private ASN by default
# Your on-premise router config (example):
router bgp 65001
  neighbor 169.254.x.x remote-as 64512  # Amazon's private ASN
  neighbor 169.254.x.x local-as 65001   # Your private ASN

Public ASNs

• Use for: Internet peering, IXP participation, multi-homing with ISPs
• Obtaining: Apply through your Regional Internet Registry (ARIN, RIPE, APNIC)
• Cost: Varies by region; annual fees apply

ASN Planning Recommendations

• Use a single private ASN range across your organization for consistency
• Document all ASN assignments in a central registry
• Reserve ASN ranges for different purposes (e.g., 65001-65100 for data centers, 65101-65200 for cloud connections)

2. Prefix Management and Advertisement

Prefix Sizing Rules

• Never advertise smaller than /24: Most ISPs filter /25 and smaller prefixes to limit routing table size
• IPv6 minimum: /48 is the typical minimum accepted
• Aggregate when possible: Prefer advertising one /16 over sixteen /20s

Address Planning for Multi-Homing

If you multi-home (connect to multiple ISPs), you need Provider Independent (PI) address space:

• Apply for PI space from your RIR
• Minimum allocation varies (typically /24 for IPv4, /48 for IPv6)
• You control advertisements to all upstream providers

Route Summarization

# Bad: Leaking individual routes
network 10.0.1.0/24
network 10.0.2.0/24
network 10.0.3.0/24
...
network 10.0.254.0/24

# Good: Advertising summary
network 10.0.0.0/16

Summarization reduces routing table size, improves convergence time, and hides internal topology changes from external peers.

3. Route Manipulation and Traffic Engineering

With redundant connections, you must control which path traffic takes. BGP offers several attributes for traffic engineering:

Path Selection Order (Simplified)

1. Highest Weight (Cisco-specific, local to router)
2. Highest Local Preference (iBGP, used for outbound traffic)
3. Locally originated route preferred
4. Shortest AS-Path
5. Lowest Origin type (IGP < EGP < Incomplete)
6. Lowest MED (when received from same AS)
7. eBGP over iBGP
8. Lowest IGP metric to next hop
9. Oldest route
10. Lowest router ID

Traffic Engineering Techniques

Example: Prefer Primary Link for Outbound

# Set higher local-pref on routes from primary upstream
route-map PRIMARY-IN permit 10
  set local-preference 200

route-map BACKUP-IN permit 10
  set local-preference 100

router bgp 65001
  neighbor 203.0.113.1 route-map PRIMARY-IN in
  neighbor 198.51.100.1 route-map BACKUP-IN in

Example: Deprioritize Inbound via Backup

# Prepend AS-path on backup advertisements
route-map BACKUP-OUT permit 10
  set as-path prepend 65001 65001 65001

router bgp 65001
  neighbor 198.51.100.1 route-map BACKUP-OUT out

4. BGP Communities

Communities are powerful tags that control route handling across networks. They enable complex policies without manual coordination.

Standard Community Format

Communities are 32-bit values written as ASN:VALUE (e.g., 65001:100).

Well-Known Communities

• NO_EXPORT — Don't advertise outside the AS
• NO_ADVERTISE — Don't advertise to any peer
• LOCAL_AS — Don't advertise outside the local AS (confederation sub-AS)

ISP Action Communities (Examples)

Most ISPs publish communities you can attach to routes for special handling:

• ISP:0 — Blackhole (drop traffic to this prefix)
• ISP:100 — Set local-pref to 100
• ISP:80 — Prepend 3x before advertising to peers

Always check your ISP's documentation for supported communities.

Large Communities (RFC 8092)

For 32-bit ASNs or more expressive policies, use large communities: ASN:FUNCTION:VALUE.

5. Security: RPKI and Route Filtering

Route hijacking—whether accidental or malicious—is a real threat. Implement these security measures:

RPKI (Resource Public Key Infrastructure)

RPKI enables cryptographic verification of route origins:

ROA (Route Origin Authorization)

• Create ROAs for your prefixes so others can validate you're authorized to advertise them
• Validate received routes against ROAs and reject invalid origins

# Create ROA (via your RIR portal):
Prefix: 203.0.113.0/24
Origin AS: 65001
Max Length: /24  # Don't allow more-specifics

# Router validation policy:
router bgp 65001
  bgp rpki server tcp 10.0.0.1 port 8282
  
  route-map RPKI-FILTER permit 10
    match rpki valid
    set local-preference 200
  route-map RPKI-FILTER permit 20
    match rpki not-found
    set local-preference 100
  route-map RPKI-FILTER deny 30
    match rpki invalid

Prefix Filtering

Always filter routes from peers—trust no one by default:

Inbound Filtering

• Only accept prefixes the peer is authorized to advertise
• Reject bogons (private addresses, test ranges, reserved space)
• Reject your own prefixes (prevent loops/hijacks)
• Consider max-prefix limits to prevent route leaks

Outbound Filtering

• Only advertise routes you're authorized to originate
• Tag routes with appropriate communities
• Never leak customer routes to other customers (unless transit)

# Prefix-list for inbound filtering
ip prefix-list CUSTOMER-PREFIXES seq 10 permit 192.0.2.0/24
ip prefix-list CUSTOMER-PREFIXES seq 100 deny 0.0.0.0/0 le 32

# Apply to neighbor
router bgp 65001
  neighbor 198.51.100.1 prefix-list CUSTOMER-PREFIXES in
  neighbor 198.51.100.1 maximum-prefix 100 warning-only

6. High Availability and Failover

BFD (Bidirectional Forwarding Detection)

BGP's default keepalive (60s) and hold timer (180s) are too slow for production. BFD provides sub-second failure detection:

# Enable BFD on BGP neighbor
router bgp 65001
  neighbor 203.0.113.1 fall-over bfd

# BFD timers (platform-specific)
bfd
  interval 300 min_rx 300 multiplier 3  # 900ms detection

Graceful Restart

When a router restarts (software upgrade, control plane failure), graceful restart preserves forwarding while BGP reconverges:

router bgp 65001
  bgp graceful-restart
  bgp graceful-restart restart-time 120

7. Cloud-Specific BGP Considerations

AWS Direct Connect

• BGP session over private VIF uses private ASN by default
• Advertise on-premise routes to AWS
• Receive VPC CIDR blocks from AWS
• Use AS-path prepending to prefer one Direct Connect over another

Azure ExpressRoute

• Microsoft uses ASN 12076
• Supports both private peering (VNets) and Microsoft peering (M365, Azure public services)
• Local preference and AS-path prepending work as expected

Google Cloud Interconnect

• Cloud Router handles BGP sessions
• Supports custom route advertisements (learned routes or static)
• MED is used for path preference within Google's network

Learn more in our AWS, Azure, and Google Cloud provider guides.

8. Troubleshooting BGP

Common Issues

• Session stuck in Active/Connect: Check IP reachability, ASN configuration, TTL (eBGP needs TTL>1 for loopback peering)
• Routes not received: Check prefix filters, max-prefix limits, RPKI validation
• Routes not sent: Check outbound route-maps, network statements, redistribution
• Traffic asymmetry: Analyze local-pref and AS-path in both directions

Essential Commands

# Check neighbor status
show bgp summary
show bgp neighbors 203.0.113.1

# View routes
show bgp ipv4 unicast
show bgp ipv4 unicast 192.0.2.0/24
show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes
show bgp ipv4 unicast neighbors 203.0.113.1 received-routes

# Debug (use carefully in production)
debug bgp updates

Key Takeaways

• Use private ASNs for cloud connections, public ASNs for internet peering
• Never advertise prefixes smaller than /24
• Use local-pref for outbound control, AS-path prepending for inbound
• Implement RPKI and prefix filtering for security
• Enable BFD for fast failure detection
• Document everything—BGP doesn't forgive unknown configurations