From BGP Data to Insight: Simplifying Real-Time Routing Analysis

On 18 March 2025, North Korea's routes became unreachable due to a misconfiguration that occurred when they started their journey with RPKI. Quickly reported and documented in a blog post by Doug Madory, this incident drew attention because of the uniqueness of these routes. Such types of incidents can affect any network and highlight the importance of robust monitoring tools that enable rapid inspection and mitigation.

IHR's BGP monitor

We have been developing a simple web-based tool that monitors the reachability of a prefix over time, with the following key features:

• Visualisation of the reachability, number of BGP messages, and AS paths for a prefix
• Real-time monitoring using the RIS Live API
• Historical analysis using the BGPlay API (data available from July 2024)
• Historical RPKI status
• Detailed route information (e.g., BGP communities)
• No installation, no registration, no fees required, and open source code.

Usage is straightforward: go to this website, select the data source (RIS Live for live data or BGPlay for historical data), enter your prefix, and click LOAD. Optionally, you can select specific RIS collectors and define time ranges for historical analysis.

Reviewing the North Korea faulty ROA incident

Let's revisit the North Korean outage from March 2025.

The plots below show the status of one of North Korea’s prefixes (175.45.176.0/24) between 18 March and 20 March. You can also check out the interactive plots in the IHR BGP monitor tool.

Overview

Reachability

The first plot above shows the number of RIS peers (for the selected collectors) that can reach the prefix. In this case, up to 36 peers could reach the prefix during the observation period. The drop from around 10:00 UTC on 18 March until 02:00 UTC on 19 March corresponds to the outage. Also, four peers consistently reported connectivity to the prefix and thus appeared unaffected by the outage.

Number of BGP messages

The second plot shows the number of BGP messages per second reported by RIS peers. It reveals a burst of updates when the prefix went down, followed by another burst when the prefix was globally restored. This view is particularly useful for identifying flapping or noisy routes.

RPKI status

The third plot shows the RPKI validation status for the monitored routes. Each row corresponds to a RIS peer, and the colours indicate the RPKI validation status:

• Orange: not covered by any ROA.
• Red: ROA invalid routes.
• Green: ROA valid routes.

Here we observe that the prefix was not covered by RPKI before the outage (orange bars), it became invalid during the outage (red bars), and was finally marked as valid afterwards (green bars).

Note that the colour transitions are not perfectly aligned with the BGP updates. This is because the RPKI data we use (RPKIviews) has a lower temporal resolution (updated every 20 minutes).

Clicking on the panel below the plot reveals the ROA details. After the outage, two ROAs are visible: one for the monitored prefix (175.45.176.0/24) and one for a covering prefix (175.45.176.0/22). During the outage, only the ROA for the covering prefix existed, which caused the /24 route to be invalid.

AS Paths

Scrolling down, you will find a graph showing AS paths from RIS peers to the AS originating the monitored prefix. Below it, a table provides details about the latest BGP message received by each peer along with check boxes to show specific peers in the graph.

Here the graph shows that the origin AS is AS131279, downstream of AS134544 (Cenbong) and AS4837 (China Unicom). You can click inside the `Reachability plot` above to jump to the outage period and see how the four unaffected RIS peers maintained reachability even when the route was invalid.

Comparing the two graphs reveals that many RIS peers and transit networks lost reachability (e.g., Telia AS1299, which implements route origin validation) while some continued propagating the invalid route (e.g., Hurricane Electric AS6939, KDDI AS2516, Softbank AS17676).

Wrapping up

This example illustrates how past routing incidents can be quickly analyzed using this tool. Although not shown here, selecting the RIS Live data source enables real-time monitoring for operational use (note that live RPKI monitoring is not yet supported).

We hope that this tool proves useful for both researchers and network operators, and we welcome feedback on how to further improve it. The best way to request new features or report problems is to open an issue on GitHub or by commenting below.

Acknowledgements

IHR BGP Monitor was implemented by Arnab Ghosh and supported by the Google Summer of Code program. Many thanks for their help and support!