Rediscovering Recurring Routing Results
Xiao Song, John Heidemann
TL;DR
Fenrir addresses the challenge of understanding and comparing Internet routing by representing service reachability as a routing vector $D(t)$ over networks and sites, and by measuring similarity with $ (t,t')$ using $M(t,t',n)$ and Gower distance. It combines data-cleaning, weighting, pairwise similarity, and hierarchical clustering to identify recurring routing modes and quantify changes, with visualizations such as heatmaps and transition matrices $T(t,t',s,s')$ to guide operator decisions. The approach is validated against operator ground truth for B-Root and applied to five years of anycast data, USC traceroutes, and front-end website measurements (Google and Wikipedia), revealing stable modes, large enterprise upstream changes, and rapid front-end evolution by hypergiants. Fenrir thus offers a general, measurement-driven framework for operational routing awareness across multiple classes of Internet services, enabling operators to detect both self-initiated and third-party routing changes and their potential performance implications.
Abstract
Routing is central to networking performance, including: (1) latency in anycast services and websites served from multiple locations,(2) networking expenses and throughput in multi-homed enterprises, (3) the ability to keep traffic domestic when considering data sovereignty. However, understanding and managing how routing affects these services is challenging. Operators use Traffic Engineering (TE) with BGP to optimize network performance, but what they get is the result of all BGP policies throughout the Internet, not just their local choices. Our paper proposes Fenrir, a new system to rediscover recurring routing results. Fenrir can discover changes in network routing, even when it happens multiple hops away from the observer. Fenrir also provides new methods to quantify the degree of routing change, and to identify routing "modes" that may reappear. Second, we show that Fenrir can be applied to many different problems: we use five instances of three different types of systems to illustrate the generalization: anycast catchments showing in a root DNS service, route optimization for two multi-homed enterprises, and website selection for two of the top-10 web services. Each type requires different types of active measurements, data cleaning and weighting. We demonstrate Fenrir's methods of detecting and quantifying change are helpful because they all face similar operational questions: How much effect did traffic engineering have? Did a third-party change alter my routing? In either case, is the current routing new, or is it like a routing mode I saw before?