Summary

  • A LACNIC 46 keynote used 37.148.92.0/24 to show why BGP UPDATE volume is a poor summary of a route event: the origin and first transit hop changed little while AS49666 replaced upstream AS6762 with AS198150 at 15:26 UTC.
  • The talk’s method follows route state over time and across multiple views, then asks how far a change spread, how long it lasted and which networks were involved. The slide deck does not give the example year or its complete vantage list.

The counter had four digits. The path had one change worth tracing.

A count of 1,025 BGP UPDATE messages sounds like a finding. By itself, it is a pile of messages with no answer to the question an operator actually asks: what changed in the route?

Doug Madory’s LACNIC 46 keynote puts that difference on one prefix, 37.148.92.0/24. In the presentation, the route’s origin view and the first transit hop show little movement. Farther along, the picture changes. AS49666 normally used two upstreams. Beginning at 15:26 UTC, AS6762 drops out of the displayed path and AS198150 takes its place. The slide notes 1,025 processed updates, then moves on. The count did not describe the change; the route state did.

That is the useful point of the example. BGP produces messages. Operators need to know which path each network had, when it changed and how much of the system saw the change. Counting announcements without reconstructing state can put a harmless burst and a consequential path shift in the same bucket.

Messages are the evidence. State is the question.

BGP’s UPDATE message carries reachability information: it can announce reachable destinations and withdraw routes that are no longer available. The protocol’s route-selection process then uses the information and local policy to choose a path. A counter records message volume. It does not show the path a particular network selected or how that path changed over time. RFC 4271 defines the protocol messages and route-selection process.

The keynote’s framework asks three more useful questions about an event: scope, duration and context. Scope asks how far a change propagated. Duration asks when it began and whether it ended. Context identifies the autonomous systems in the path and the role each played. Madory’s slides describe announcements as the observable messages around a less visible object: the routing state each AS maintained over time.

That shift changes the analyst’s unit of work. Instead of plotting every announcement as if each were a separate incident, the analyst compares route states at meaningful times. Which path was present before? Which one replaced it? Did the origin change, or only a transit relationship farther away? Did other views see the same transition? These questions turn a packet of updates into a sequence that an operator can inspect.

The presentation also makes a practical concession: drawing every AS-to-AS edge can make the graph unreadable. Reducing the number of sources makes the picture simpler but throws away viewpoints. The slides demonstrate a visibility threshold of roughly one per cent of BGP sources to prune the graph. The threshold has direct costs: lower it and more edges survive, along with clutter; raise it and a narrow but real path may vanish from the picture.

The threshold is therefore part of the result. A reader needs to know which sources were included, how a route qualified for display and how the system handled a change visible from only a small share of collectors. Without those details, a clean graph can look more complete than the evidence behind it.

One route can change where the origin looks steady

The 37.148.92.0/24 example is useful because it resists the easiest reading. The origin appears broadly stable. The first transit view changes little. A search farther along the path reveals the upstream swap. An analyst who stopped at the origin or first hop would have missed the change that the speaker chose to examine.

The slides show control-plane route views; traffic, packet delivery and application telemetry do not appear in the source package. A route transition is a fact about routing state; its service effect needs a different observation. Keeping those records separate makes the finding more precise and more useful.

For a network operator, the same distinction matters during a busy event. A large update count can consume attention because it looks urgent. A smaller number of state changes can matter more if they alter the path used by a customer network, a transit provider or a service prefix. Analysts should rank events by the route transitions they can explain, not by the loudness of the message stream.

The slides identify the example as 14:00–16:00 UTC on “Sep-8,” but omit the year and complete collector list; a dated export with that source list would make the 15:26 swap independently reproducible and let readers measure its full duration. The published LACNIC agenda and original keynote deck preserve the talk’s record.

The distinction is small enough to fit in one slide and large enough to change an investigation. “1,025 updates” tells the reader how busy the feed was. “AS6762 disappeared from AS49666’s upstream view at 15:26” tells the reader what to check next.