Skip to content

PATTERN Cited by 1 source

Controlled BGP experiment

A controlled BGP experiment is a measurement methodology where a network operator with global anycast presence announces test prefixes with precisely known attributes โ€” then observes what other ASes do to those attributes via public BGP collectors.

Structure

  1. Controlled origination: announce distinct prefixes with each possible value of the attribute under test (e.g., one prefix per ORIGIN value: IGP, EGP, INCOMPLETE) from all peering locations via anycast.
  2. Confirm global propagation: validate all test prefixes are visible across public collectors before measuring.
  3. Path hunting via withdrawal: withdraw prefixes to trigger the BGP path-hunting process, revealing additional paths (and opportunities to spot attribute changes) that wouldn't be visible during steady-state routing.
  4. Collector analysis: parse BGP Update messages from MRT dumps (RIPE RIS + RouteViews) and local BMP data to extract all observed attribute values for test prefixes.
  5. Attribution: for two-hop AS_PATHs, attribute modification is certain (the neighbor must have done it). For longer paths, iterative seed-and-propagate algorithms expand the trusted set.

When to use

  • Investigating whether an attribute is respected or rewritten in transit
  • Quantifying the prevalence of a BGP behavior across the Internet
  • Validating RFC compliance across peer networks
  • Measuring the impact of routing policy on path selection

Trade-offs

  • Requires global presence: the originator must announce from many locations via anycast to get broad collector visibility.
  • Partial visibility: public BGP collectors see only a subset of the Internet's routing topology; the flattening of the Internet (hyperscaler direct peering) widens this gap.
  • Updates over RIBs: parsing Updates rather than RIB snapshots captures more transient paths (especially during path hunting), but at higher data volume.
  • Iterative attribution is approximate: the seed-and-propagate algorithm assumes transitivity in the "trusted" set, which may not hold for all ASes in all configurations.

Seen in

Last updated ยท 595 distilled / 1,807 read