BGP Architecture: Autonomous System Peering, MED & Route Flap Damping

1. Autonomous System Peering & eBGP Multihoming Topologies

An Autonomous System (AS) represents a connected group of IP routing prefixes operated by one or more network operators under a single, clearly defined administrative routing policy. Enterprise organizations requiring deterministic external connectivity deploy multihomed external BGP (eBGP) connections across two or more Tier-1 or Tier-2 internet service providers (ISPs) using a globally assigned Public ASN (from ARIN, RIPE, or APNIC) or private ASNs (64512–65534, 4200000000–4294967294) across dedicated cloud interconnects.

When engineering an active-active eBGP multihoming topology across redundant edge routers, network architects must account for two distinct traffic vectors: outbound egress path selection and inbound ingress path determination. Outbound traffic is entirely within the enterprise's administrative control through internal BGP (iBGP) signaling, Local Preference manipulation, and next-hop reachability. Conversely, inbound traffic is governed by autonomous external networks whose routing engines evaluate AS-Path length, origin codes, and peering relationships. Establishing deterministic symmetry demands coordinated prefix segmentation, strategic AS-Path prepending, and granular BGP Community tagging accepted by upstream transit providers.

Without coordinated policy, enterprise networks suffer from asymmetric routing—where egress packets traverse ISP A while ingress packets return via ISP B. While stateless routing accommodates asymmetry without operational penalty, stateful security appliances (such as next-generation edge firewalls, NAT gateways, and intrusion prevention engines) immediately drop out-of-order or one-way TCP sequences when return packets fail to cross the identical stateful firewall inspection table. Therefore, active-active edge architectures require synchronized flow tracking or deterministic per-prefix symmetry.

2. The BGP Best Path Selection Hierarchy & Attribute Mechanics

When an edge router receives multiple candidate paths toward the identical destination prefix, the BGP decision engine executes a strict, non-compensatory 13-step evaluation sequence. Mastering the precise hierarchy of BGP path attributes is essential for tuning traffic flow without destabilizing adjacent routing tables:

• Weight (Cisco/Proprietary): Highest local value (0 to 65,535). Evaluated first, purely local to the router, and never propagated in BGP updates to any neighbor. Ideal for per-router traffic pinning.
• Local Preference (RFC 4271): Highest value preferred (default 100). Propagated throughout the entire local AS via iBGP, but stripped at eBGP egress boundaries. This is the primary lever for engineering enterprise outbound egress routing.
• Locally Originated Routes: Routes generated via local network commands or redistribution into BGP take precedence over routes learned from neighboring peers.
• AS-Path Length: Shortest discrete AS count preferred. Widely manipulated by injecting redundant local AS numbers (AS-Path Prepending) to deter external inbound traffic from selecting a backup transit pipe.
• Origin Code: IGP (i) preferred over EGP (e), which is preferred over Incomplete (?). Modern networks rarely encounter legacy EGP.
• Multi-Exit Discriminator (MED / Metric): Lowest value preferred. Conveyed across eBGP boundaries between adjacent autonomous systems to indicate preference among multiple entry points into the advertising AS. By default, routers only compare MED among paths received from the exact same neighboring AS.
• eBGP over iBGP: External eBGP paths take precedence over internal iBGP paths to clear egress traffic from the internal backbone as swiftly as possible (hot-potato routing).
• IGP Metric to Next Hop: Lowest IGP metric (cost) to the BGP next-hop address. Enables tie-breaking based on internal link speeds.

3. Multi-Exit Discriminator (MED) vs. Local Preference in Enterprise Fabrics

Enterprise network engineers frequently conflate Local Preference and Multi-Exit Discriminator (MED) when designing multi-region cloud and data center interconnects. Local Preference dictates outbound flow choices made by internal systems, broadcasting throughout the entire internal AS. In contrast, MED is a suggestion passed to an external neighbor regarding how that neighbor should route traffic into your AS.

Because MED is an optional non-transitive attribute, upstream providers frequently strip or overwrite incoming MED attributes unless an explicit peering agreement or business contract mandates adherence. Furthermore, non-deterministic MED evaluation can induce routing loops and non-transitive BGP oscillations if bgp always-compare-med and deterministic MED algorithms are disabled on Cisco IOS-XE and Arista EOS platforms. When communicating with tier-1 transit providers, utilizing RFC 1997 Well-Known BGP Communities or ISP-specific communities (e.g., AS_TRANSIT:70 for low preference, AS_TRANSIT:90 for high preference) yields far more deterministic inbound traffic engineering than raw MED injection.

4. Route Flap Damping (RFC 2439) & Path Convergence Penalties

Route flap occurs when an unstable network link or misconfigured BGP peer rapidly oscillates between available and withdrawn states. Each oscillation floods the global routing system with BGP Update and Withdraw messages, consuming CPU cycles on core Internet routers and degrading routing table convergence. Route Flap Damping (RFD, RFC 2439) introduces a decaying mathematical penalty to suppress unstable prefixes until their operational stability is proven over a continuous duration:

While RFD successfully protects transit cores from route storms, overly aggressive flap damping parameters historically resulted in prolonged blackholing of legitimate enterprise routes during routine hardware maintenance. Modern RIPE and IETF recommendations (RFC 7454) mandate conservative damping thresholds, dampening only persistent, high-frequency flappers while exempting well-behaved prefixes experiencing isolated maintenance disconnects.

5. Cryptographic Route Origin Validation (RPKI ROV)

Historically, BGP relied on implicit trust, leaving the global routing table vulnerable to accidental route leaks and malicious BGP hijacking (such as cryptocurrency theft and state-sponsored traffic diversion). Resource Public Key Infrastructure (RPKI) provides an authoritative, cryptographically signed public-key infrastructure linking IP prefix allocations to designated Autonomous System Numbers through Route Origin Authorizations (ROAs).

Enterprise edge routers connect to internal RPKI validators (such as Routinator, StayRTR, or OctoRPKI) via the RTR (RPKI-to-Router) protocol. The router evaluates each received eBGP prefix against the validated ROA cache, assigning an evaluation status:

• Valid: The announced prefix and ASN match an authoritative ROA with a prefix length less than or equal to the registered maxLength.
• Invalid: An active ROA exists for the prefix, but either the advertising ASN does not match the ROA, or the prefix length exceeds the specified maxLength. Modern best practices dictate immediate rejection (drop) of Invalid routes at the edge.
• NotFound (Unknown): No signed ROA exists for the prefix. The route is processed normally through standard BGP path selection.

6. Technical Comparison: BGP Routing Mechanisms & Traffic Levers

7. Production Hardened Configuration: Arista EOS & Cisco IOS-XE

Below is a production-grade enterprise edge configuration demonstrating eBGP multihoming with BFD sub-second failure detection, deterministic route dampening, and standardized community tagging for egress preference:

! ==============================================================================
! Cisco IOS-XE Enterprise Dual-Homed eBGP Edge Configuration
! ==============================================================================
router bgp 65001
 bgp router-id 198.51.100.1
 bgp log-neighbor-changes
 bgp deterministic-med
 no bgp default ipv4-unicast
 neighbor 203.0.113.1 remote-as 7018
 neighbor 203.0.113.1 description PRIMARY_TRANSIT_ISP_A
 neighbor 203.0.113.1 fall-over bfd
 neighbor 203.0.113.5 remote-as 3356
 neighbor 203.0.113.5 description BACKUP_TRANSIT_ISP_B
 neighbor 203.0.113.5 fall-over bfd
 !
 address-family ipv4 unicast
  network 198.51.100.0 mask 255.255.255.0 route-map RM_ORIGINATE_PREFIX
  bgp dampening 15 750 2000 60
  neighbor 203.0.113.1 activate
  neighbor 203.0.113.1 route-map RM_ISP_A_IN in
  neighbor 203.0.113.1 route-map RM_ISP_A_OUT out
  neighbor 203.0.113.5 activate
  neighbor 203.0.113.5 route-map RM_ISP_B_IN in
  neighbor 203.0.113.5 route-map RM_ISP_B_OUT out
 exit-address-family
!
route-map RM_ISP_A_IN permit 10
 set local-preference 200
!
route-map RM_ISP_B_IN permit 10
 set local-preference 100
!
route-map RM_ISP_B_OUT permit 10
 set as-path prepend 65001 65001 65001
!