R&E Global LPP Report
Sort family:
The global R&E network consists of roughly 2,700 separate networks (autonomous systems). A significant percentage of these networks have connections to both an upstream R&E provider and one or more commodity ISPs. Each network independently makes routing decisions about which path to prefer when reaching various destinations.
Campuses typically connect to a regional R&E network (e.g., MERIT, LEARN, CENIC, NYSERNet), which in turn connects to Internet2. The R&E route between two campuses is often at least 4 AS hops. If both campuses use the same commodity ISP—which happens frequently—the commodity route might only be 2 hops. Without an explicit routing policy, BGP selects the shortest AS path, and the two campuses will route via the commodity ISP instead of the R&E network.
The recommended best practice is to use BGP Local Preference to prefer routes learned from R&E networks over routes learned from commodity ISPs. When this is done, campuses route via the R&E path regardless of AS-path length.
The Local Preference Probe (LPP) is a server connected to both the Internet2 R&E network and a commodity ISP. It sends probes from two source addresses to hosts across the 2,700 R&E networks and observes how each network routes its response back—does it arrive via the R&E path or the commodity path?
| Source | Address | Route design |
|---|---|---|
| Source A | 163.253.64.1 |
R&E route is prepended towards commodity |
| Source B | 163.253.63.63 |
R&E route is prepended towards R&E |
Both sources share the same commodity route. The difference is which direction the R&E route is prepended, so the two probes test whether the remote network chooses based on Local Preference or AS-path length.
| Color | Source A | Source B | Meaning |
|---|---|---|---|
| RE | R&E | R&E | The network is following the best practice of preferring R&E routes over commodity. BGP Local Preference favors R&E. |
| Path | R&E | Commodity | The network is using AS-path length to choose, so some destinations use R&E while others route via commodity. R&E and commodity have equal Local Preference. |
| Comm | Commodity | Commodity | The network appears to always prefer commodity, even when an R&E route exists. |
| Inconclusive | Missing / unexpected | Excluded from percentages. | |
Orange and red networks are connected to the global R&E network infrastructure, but are not effectively using it.
The stacked bar for each AS represents the ratio of probe response classifications across its entire customer cone—the AS itself plus every AS downstream of it in the R&E tree.
Multiple IP addresses are probed within each prefix, not just one per prefix. The percentages reflect the classification of every individual probe response across all prefixes in the cone. For example, if an AS and its downstream networks have 1,000 total probed IPs and 800 are classified as RE, 150 as Path, and 50 as Comm, the bar shows 80% / 15% / 5%. Inconclusive responses are excluded from both the count and the total.
A leaf AS shows only its own probe results. A transit AS near the root aggregates results across hundreds of downstream networks, giving a high-level view of routing policy in that part of the R&E topology.
The pfx link next to each AS shows the total number of prefixes across the AS and its entire customer cone. Clicking it opens a hierarchical prefix view that mirrors the AS relationship tree.
Each AS in the hierarchy is shown as a highlighted header with its AS number, name, and prefix count. Below each header are the prefixes originated by that AS, with:
Child ASes appear nested below their parent, matching the R&E routing hierarchy. All levels start expanded so the full cone is visible at a glance. Click any AS header to collapse or expand its children.
For a leaf AS with no downstream networks, clicking pfx shows a simple flat list of its originated prefixes without the hierarchy wrapper.
An AS can appear as a child of multiple parents in the tree. This happens when a network is multi-homed to more than one R&E upstream—for example, a campus connected to both a regional network (like MERIT or CENIC) and directly to Internet2, or reachable through multiple regional peers. RouteViews sees AS paths through each upstream, creating multiple parent–child edges for the same AS.
Multi-parent ASes are identified by a badge next to the AS number (e.g., “3 parents”). Clicking the badge opens a diagram showing the AS and all its parents as connected boxes.
Each parent box in the diagram shows:
The target box at the bottom shows the child AS itself with its overall cone bar chart and all of its originated prefixes.
The Highlight multi-homed button adds a blue left border to every row where the AS has more than one parent, making them easy to spot while scrolling. The header displays a count of how many ASes in the tree have multiple parents.
The dashboard at the top of the report provides an at-a-glance overview:
Each AS row shows n=XXX next to its stacked bar, indicating the total number of probe destinations in the customer cone. ASes with fewer than 10 probes have their bars dimmed to signal low confidence — their percentages may not be representative of the network’s actual routing policy.
The More specific routes in DFZ button toggles the bar chart to a different view: instead of showing probe-based routing policy, it shows the percentage of each AS’s R&E address space that has more-specific routes in the Default-Free Zone (DFZ) that are not part of the R&E infrastructure.
When a more-specific prefix exists in the DFZ but not in R&E, longest-prefix-match
routing forces traffic to those addresses off the R&E path — regardless of the
network’s BGP Local Preference setting. This is a structural issue that no amount
of correct policy configuration can overcome. For example, if a campus announces
10.0.0.0/16 via R&E but also announces 10.0.1.0/24 only
to a commodity provider, all traffic destined for 10.0.1.0/24 will follow
the more-specific route and bypass R&E.
In DFZ more-specific mode the bar splits into two rows: the top row shows IPv6, the bottom row shows IPv4. Each row is colored independently:
If an AS’s cone has prefixes in only one family, the other row is shown as a muted “no v4” / “no v6” placeholder.
When viewing prefixes (via the pfx link), each R&E prefix that has DFZ more-specifics shows them in a highlighted box with a red border. This lists every more-specific prefix found in the global routing table that is not tagged with an R&E community, making it easy to identify exactly which more-specific announcements are diverting traffic away from R&E.
The analysis compares the R&E IPv4 and IPv6 prefixes against the full global routing table from CAIDA RouteViews prefix-to-AS data (both v4 and v6 trees, updated hourly). A prefix in the global table counts as a DFZ more-specific if it is contained within an R&E prefix and is not itself tagged with any R&E BGP community (11537:950, 11537:2501, 11537:3000). Maximum prefix length considered is /24 for IPv4 and /48 for IPv6. The bar percentages are based on IP address count within each family, so v4 and v6 are not directly comparable across the split.
The RPKI ROV status button toggles the bar chart to show RPKI coverage across each AS’s customer cone. Like the DFZ view, the bar is split into two halves: top is IPv6, bottom is IPv4. Each family is percentaged independently against its own address space.
Each prefix in the prefix view (pfx) also shows an RPKI badge: ROA ✓, ROA ✗, or No ROA.
RPKI data is sourced from Cloudflare’s RPKI validator, refreshed every 24 hours. Validation uses the origin AS from the RouteViews R&E route for each prefix.
The ASPA button shows what percentage of the ASes in each AS’s customer cone (the AS itself plus all descendants) have published an ASPA (Autonomous System Provider Authorization) object in the RPKI. Each AS is counted once, regardless of how much address space it originates.
Each prefix in the prefix view also shows a blue ASPA badge if its origin AS has a published ASPA.
ASPA data is sourced from Cloudflare’s RPKI validator, refreshed every 24 hours.
The «⚠ DFZ more-specifics only» checkbox in the filter bar restricts the tree to only ASes whose customer cone contains at least one prefix with more-specific routes in the DFZ. All other ASes are hidden, making it easy to focus on the networks affected by route leakage. The filter composes with the community filter—both must pass for a prefix to be visible.
Clicking a prefix name opens a detail popup showing the prefix’s holder, origin AS, RPKI status, ASPA status, LPP probe breakdown, and any DFZ more-specific routes. At the top of the popup, a tree-style AS path shows the route from the Internet2 root down to the origin AS, with the prefix as the leaf node. Each ancestor AS in the path is clickable—clicking one closes the popup and scrolls to that AS in the main tree. Clicking a bar chart opens a similar detail popup showing the aggregate statistics for that AS’s customer cone in the current bar mode.
The browser URL automatically updates as you interact with the report. Every aspect of your current view is captured: bar chart mode, search query, sort order, which tree nodes are expanded, community and DFZ filters, open prefix lists, and any open detail popup. Copy the URL from the address bar to share your exact view with someone else—when they open the link, the report restores to the same state.
You can also link directly to a specific AS by adding ?asn=12345 to the
URL. The tree will auto-expand and scroll to that AS on load.
The probe targets responsive IP addresses discovered by the USC/ISI Internet address survey. These addresses may include router interfaces, management planes, or other infrastructure devices whose return path may differ from the network’s general routing policy. For example, a router interface on a transit link may respond over that transit link regardless of the BGP Local Preference configured for the campus’s production traffic. As a result, individual probe results should be interpreted with caution—the aggregate percentages across many probed IPs within a prefix provide a more reliable picture than any single probe.
RouteViews (BGP paths & origins), RIPE Stat (AS names), CAIDA (fallback names), lpp-store (probe results). Report rebuilds daily at UTC midnight.
Part of the CICI-ROOTBEER project.
This material is based on research sponsored by the National Science Foundation (NSF) grant OAC-2530871. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of NSF.