Pith. sign in

REVIEW 5 major objections 5 minor 49 references

BEAR: BGP Event Analysis and Reporting

T0 review · 5 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read BEAR is an LLM-based system that writes accurate, plain-English reports explaining BGP hijacks and route leaks, and the paper reports 100% accuracy on 54 test events.

desk verdict Genuinely new task formulation for BGP anomaly explanation with a plausible LLM pipeline, but the 100% accuracy claim rests on a small, partly circular evaluation and should be taken as provisional. read the letter →

arxiv 2506.04514 v1 pith:BQ2STHTO submitted 2025-06-04 cs.NI cs.AI

Hanqing Li , Melania Fedeli , Vinay Kolar , Diego Klabjan This is my paper · ORCID
classification cs.NIcs.AI
keywords BGPanomalyexplanationlargelanguagemodelsrouteleakhijackmulti-stepreasoningself-consistencysyntheticdatagenerationnetworkoperations
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

BEAR is an automated system that writes plain-English reports explaining BGP routing anomalies (hijacks and route leaks) after they are detected. The paper's claim is that by first translating large tables of BGP routing data into structured textual descriptions, then repeatedly asking a large language model to classify the change and reconcile the answers through self-consistency, BEAR explains all 54 test events correctly: 10 real incidents, 10 anonymized versions, and 34 synthetically generated ones. The authors argue this matters because today interpreting a BGP event requires specialists who understand AS relationships and historical incidents, which delays mitigation; an automatic, accurate report could let network operators act sooner. The paper also introduces an LLM-based synthetic data generator to overcome the scarcity of documented BGP anomalies, and shows BEAR keeps working when many route collectors are unavailable, recommending additional data collection when the event is not visible.

What carries the argument

The load-bearing mechanism is a multi-step reasoning pipeline that converts structured BGP data into text before asking the LLM to reason. The raw material is the AS path — the list of autonomous system numbers a route traverses — observed historically, immediately before the event, and immediately after it. BEAR prompts the LLM to answer targeted questions about path changes (did the destination AS change, was a new sub-prefix announced, how does the new path differ), transforms those answers into a narrative, runs the classification N times, and uses a self-consistency step where the LLM picks the majority classification and synthesizes one coherent change report. A second mechanism is the synthetic data generator: an LLM invents a hypothetical event's details, then the system retrieves real historical and pre-event routes for a random prefix and edits them to mimic the invented hijack or leak, producing a realistic after-event dataset. A hierarchical summarization routine is used for exceptionally large events that exceed the LLM's token window.

What would settle it

Take 20 BGP hijacks and route leaks documented after the backbone LLM's training cutoff, run BEAR on them, and have independent BGP experts (not involved in the paper) judge the reports; if any report misidentifies the event type, the affected ASes, or the involved sub-prefix, the claimed 100% accuracy does not generalize beyond the tested set.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that BGP anomaly event explanation can be automated with an LLM. Given an IP prefix and start time, BEAR pulls the historical routing state, the state just before the event, and the state just after it from public BGP collectors; it then has the LLM answer a fixed set of questions about how AS paths changed, repeat the analysis and classification N times, select the classification by majority vote, and finally generate a report identifying event type, affected ASes, hijacker or leaker, and remediation advice. The evaluation is a claim of 100% accuracy: BGP experts judged every one of the 54 generated reports correct, including the anonymized events whose AS numbers and timestamps were randomized so the LLM could not retrieve memorized incident write-ups. The same method outperforms chain-of-thought, in-context learning, and their combination, and it retains full accuracy when only a fraction of route collectors are online, producing an explicitly inconclusive report instead of a wrong one when the event is absent from the collected data.

Load-bearing premise

The result assumes that synthetic BGP events created by an LLM from the same model family as BEAR's backbone resemble real-world anomalies closely enough that scoring 100% on them predicts real-world performance.

Editorial extensions

If this is right

  • If BEAR's accuracy holds in practice, network operators can get an expert-level written explanation of a BGP hijack or route leak within minutes of detection, shortening the time to remediation.
  • Because BEAR keeps 100% accuracy with only one or two route collectors online and flags missing data rather than guessing, it is usable during collector outages or maintenance.
  • The synthetic event generator can be reused to create labeled BGP anomaly datasets for training detection models and for testing explanation systems when real documented incidents are scarce.
  • The framework is not tied to one LLM: strong reasoners such as the models tested reach 100%, while a weaker open model reaches 80%, still above the baselines.
  • The method's scope is intentionally limited to direct intended and unintended anomalies (hijacks and route leaks); extending to indirect anomalies and link failures is left as future work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the paper's synthetic events are generated by the same LLM family that BEAR uses, so the 34-event synthetic half of the headline result is best read as a stress test of the pipeline's internal consistency rather than independent evidence about real-world generalization.
  • Editorial inference: the tabular-to-text translation is a transferable trick; any high-cardinality structured data that LLMs handle poorly — router configurations, firewall logs, financial transaction graphs — could be pre-processed into targeted textual questions before LLM reasoning.
  • Editorial inference: the accuracy metric depends on expert labeling; a stronger evaluation would have multiple experts independently label the same events and measure inter-rater agreement, since '100% correct' against one reviewer's judgment may not be stable.
  • Editorial inference: end-to-end security still hinges on detection, not explanation; even a perfect explainer cannot compensate for real-time collector coverage that misses about a quarter of simulated hijacks, so deployment should pair BEAR with detection systems that integrate additional vantage points.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The manuscript proposes BEAR, an LLM-based framework that retrieves BGP path data from RIPE RIS around a detected anomaly, converts it into textual descriptions, and uses multi-step prompting with self-consistency to produce natural-language reports explaining the event type and affected ASes. It also introduces an LLM-driven synthetic data generator that modifies retrieved BGP data to create labeled hijack and route-leak events. The paper reports 100% accuracy on a mix of 10 real events, 10 anonymized versions, and 34 synthetic events, outperforming CoT and in-context baselines, and further evaluates robustness under reduced collector availability and a hierarchical summarization strategy for a very large event.

Significance. If the evaluation were externally grounded, the framework would be a useful step toward automated, interpretable BGP incident reporting, and the paper’s problem formulation, code release, and token-cost measurements are strengths. However, the headline claim rests on a benchmark that is substantially self-referential: 34 of 54 test events are generated by an LLM of the same family used as BEAR’s backbone, with injected path signatures that the prompts are explicitly designed to detect; the 10 anonymized real events preserve the structure of publicly documented incidents rather than providing independent labels; and the largest real event is excluded from the headline accuracy. These issues are load-bearing for the central claim, so the significance is real but currently unsubstantiated at the claimed level.

major comments (5)
  1. [Section IV-A and Section V] The synthetic evaluation is circular. Section IV-A uses an LLM to generate the event type, the hijacker or leaker, sub-prefix, affected AS paths, and detection rate, and then deterministically rewrites D_after by replacing the last AS (for hijacks) or the path suffix (for leaks) and duplicating paths for sub-prefixes. Section III-C then explicitly prompts BEAR to look for changed destination AS, new sub-prefix, and path-suffix differences. Because the same GPT-4o family is used to invent the ground truth and to classify it, the 34 synthetic events mainly measure whether the model can recover templates it generated, not whether BEAR explains real-world anomalies. The paper should either obtain independent ground truth for synthetic events (e.g., by checking against real incidents not used in prompt design), or clearly reframe the synthetic results as an internal consistency check rather than evidence for real-world accuracy.
  2. [Section IV (real-event anonymization)] The 10 anonymized real events are not independent test samples. Replacing AS numbers with random values and shifting timestamps preserves the exact structural signature of each published incident, so the LLM’s success on these samples may reflect memorized or template-like event structure rather than transferable reasoning. The paper should report a per-event breakdown of the 20 real/anonymized samples and, ideally, validate on recent real events that postdate the LLM training corpus or use held-out incidents with labels obtained independently of the model.
  3. [Section V (exclusion of Ee)] The headline 100% accuracy excludes event Ee, the Angola Cables route leak with 697 IP prefixes and 771,654 AS paths, because it exceeds the LLM token limit. This is the largest real event in the dataset, and the hierarchical summarization strategy that handles it is tested only on Ee and its anonymized counterpart, with no comparison against baselines or a clear accuracy metric. The paper should either include Ee in the main accuracy computation through the summarization path, or explicitly report the accuracy both with and without Ee and justify why exclusion does not bias the headline claim.
  4. [Section V (expert evaluation)] The evaluation protocol for the 100% claim is underspecified. The paper states that all reports are reviewed by BGP experts but does not report the number of experts, the scoring rubric, inter-rater agreement, or any confidence interval. With 54 correct out of 54, the Wilson lower bound is approximately 93.4%, so the point estimate of 100% overstates the precision of the result. The authors should provide a detailed evaluation protocol and confidence intervals for the reported accuracies.
  5. [Section V and Figure 10] The limited-collector robustness experiment conflates two different outcomes. BEAR is credited for either producing an accurate report when the anomaly is present in D'_before and D'_after or producing an inconclusive report when it is absent; these are very different behaviors, and counting both as success obscures the failure mode where the anomaly is present but BEAR misses it. The accuracy should be reported separately for the two cases, and the current metric should be labeled accordingly.
minor comments (5)
  1. [Section II-B / References] Reference [16] is cited as the source of the Zhao et al. BGP anomaly taxonomy, but the reference list entry is a survey of large language models; the taxonomy citation appears to be incorrect or missing.
  2. [Section III-B] There are typographical issues such as 'annoucement' and 'withdrawl'; a careful proofread is needed.
  3. [Section III-A and Figure 5] The definitions of D_before and D_after use inconsistent typography, and Figure 5 does not explain its axes or the meaning of the two histograms in the caption.
  4. [Section V] The notation BEAR0 is introduced without a subscript or consistent formatting, and the baselines CoT, In-Context, and CoT+In-Context are not described sufficiently in terms of prompt contents and number of trials.
  5. [Section V and Figure 12] The token-cost claim that total tokens increase 'sublinearly' would benefit from a table with standard deviations, since Figure 12 reports only averages.

Circularity Check

1 steps flagged · score 6.0 of 10

Synthetic half of the 100% accuracy claim is circular: the LLM-generated event templates are exactly the AS-path signatures BEAR's prompt is designed to detect.

  1. other [Section IV-A (Synthetic BGP Event) vs. Section III-C (Data Analysis and Report Generation) and Section V (Experiments)]
    "Using the generated event description, we extract the key information and modify D_before to create D_after. ... in BGP hijack events, the first AS is set as the peer, the last AS is the hijacker ... In BGP route leak events, the suffix of the AS path is replaced with the sample AS path provided by the LLM, starting with the leaker and ending with the correct destination AS. (Prompt in Sec. III-C: 'Does the last AS (destination) change or not? Is there any new AS path to a new sub-prefix introduced?')"

    In the synthetic pipeline the ground-truth event type is defined by the edit rule applied to D_before: a hijack is 'last AS is the hijacker', a leak is 'suffix starts with the leaker', and sub-prefix cases duplicate paths. Section III-C prompts BEAR to detect exactly these markers ('Does the last AS (destination) change or not? Is there any new AS path to a new sub-prefix introduced?'). So the 34 synthetic events test whether GPT-4o can recover a template that the same GPT-4o family generated and deterministically encoded. The synthetic half of the 100% accuracy claim reduces to re-detecting the generator's own construction; expert review merely checks reports against these self-generated labels.

full rationale

BEAR's core report-generation pipeline is not circular in itself: it retrieves real BGP data, compares D_before and D_after, applies explicit classification rules, and uses self-consistency; there are no fitted parameters and no load-bearing self-citations. The circularity is in the evaluation benchmark. Section IV-A builds synthetic events by having an LLM select the event type, then deterministically editing D_before into D_after using exactly the signatures that Section III-C's prompt instructs BEAR to detect: changed last/destination AS, new sub-prefix, and suffix replacement starting from the leaker. Because GPT-4o is used both to generate the majority of the evaluation events and as BEAR's backbone, the 34 synthetic events (63% of the 54-event testbed) are a re-detection of the generator's own template rather than an external test. The real and anonymized real events are more independent, but anonymization preserves published event structure, and the largest real event Ee is excluded from the headline number. Since the paper claims 100% accuracy on both real and synthetic datasets and the synthetic half is constructed from the same template that the method is prompted to find, the central claim is partially circular; however, the real-event evaluation and the framework itself retain independent content, so the score is 6 rather than higher.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The paper's central claim rests on the validity of the synthetic data benchmark, which is generated by the same LLM family being evaluated. This is the main circularity burden. The other assumptions are standard data-source and evaluation assumptions, though the lack of inter-rater reliability weakens the expert-review grounding.

free parameters (3)
  • N (self-consistency iterations) = 5
    Number of repeated data-analysis and classification passes; chosen by hand with no sensitivity analysis. Referenced in Section V.
  • x (summarization batch size) = 5
    Batch size for hierarchical summarization of very large events; set to 5 without sensitivity analysis. Section V.
  • k (summarization iterations) = 4
    Number of summarization rounds for event Ee; chosen so that a final report remains within token limits. Section V.
assumptions (5)
  • domain assumption RIPE RIS collector data is a sufficient and representative observation of real BGP routing for the studied events.
    Used throughout data retrieval in Section III-B. If collectors miss the anomaly, BEAR changes behavior, which the paper handles, but the ground truth of 'event captured' depends on this.
  • domain assumption The 10 real-world events documented online are accurately described and correctly labeled.
    Used as ground truth in Section IV; if the online reports are wrong, expert judgments of BEAR's reports may be wrong.
  • ad hoc to paper LLM-generated synthetic BGP events are statistically similar to real anomalies.
    Central to the synthetic evaluation in Sections IV-A and V; the same GPT-4o model both generates and evaluates these events, creating a circular benchmark.
  • domain assumption Manual expert review of generated reports is a valid and reliable measure of accuracy.
    Evaluation in Section V relies on expert assessment with no inter-rater reliability or rubric reported.
  • domain assumption BGPStream correctly parses and retrieves data from MRT and RIB records.
    The data retrieval pipeline in Section III-B relies on the correctness of the open-source tool.

how reviews work

0 comments
Cite this review

Pith. "Pith review of BEAR: BGP Event Analysis and Reporting." pith.science (2026). https://pith.science/paper/BQ2STHTO

@misc{pith2026250604514,
  author       = {Pith},
  title        = {Pith review of: BEAR: BGP Event Analysis and Reporting},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BQ2STHTO}},
  note         = {Machine review of arXiv:2506.04514}
}
read the original abstract

The Internet comprises of interconnected, independently managed Autonomous Systems (AS) that rely on the Border Gateway Protocol (BGP) for inter-domain routing. BGP anomalies--such as route leaks and hijacks--can divert traffic through unauthorized or inefficient paths, jeopardizing network reliability and security. Although existing rule-based and machine learning methods can detect these anomalies using structured metrics, they still require experts with in-depth BGP knowledge of, for example, AS relationships and historical incidents, to interpret events and propose remediation. In this paper, we introduce BEAR (BGP Event Analysis and Reporting), a novel framework that leverages large language models (LLMs) to automatically generate comprehensive reports explaining detected BGP anomaly events. BEAR employs a multi-step reasoning process that translates tabular BGP data into detailed textual narratives, enhancing interpretability and analytical precision. To address the limited availability of publicly documented BGP anomalies, we also present a synthetic data generation framework powered by LLMs. Evaluations on both real and synthetic datasets demonstrate that BEAR achieves 100% accuracy, outperforming Chain-of-Thought and in-context learning baselines. This work pioneers an automated approach for explaining BGP anomaly events, offering valuable operational insights for network management.

Figures

Figures reproduced from arXiv: 2506.04514 by the authors.

Figure 1
Figure 1. BGP hijack example [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. BGP route leak example. forming large-scale tabular BGP data into textual de￾scriptions for enhanced interpretability and performing data analysis and reasoning on the text description in￾stead of the tabular data for high reasoning accuracy. By leveraging prompt augmentation and self-consistency mechanisms, the approach achieves 100% accuracy and generates detailed BGP anomaly event reports, effectively identifying… view at source ↗
Figure 3
Figure 3. Overview of how BGP messages and routing information are collected. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (8 more)
Figure 5
Figure 5. Figure 5: Number of AS path per IP prefix [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Overview of the framework that generates report for BGP anomaly [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 8
Figure 8. Figure 8: Number of correct reports generated by BEAR and other naive [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: An example report for a BGP hijack event. In this report, BEAR not [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 11
Figure 11. Figure 11: Example report when D′ before and D′ after does not contain the anomaly event. maintenance. For instance, on January 16, 2025, several route collectors experienced connectivity problems that prevented data transmission [47]. Similarly, on February 10, 2025, the rrc19 …
Figure 13
Figure 13. Figure 13: An example report of a BGP anomaly event with an extensive volume [PITH_FULL_IMAGE:figures/full_fig_p008_13.png]
Figure 15
Figure 15. Figure 15: A diagram to the network operations pipeline. [PITH_FULL_IMAGE:figures/full_fig_p009_15.png]
Figure 14
Figure 14. Figure 14: Performance of BEAR using different LLM as backbone model. [PITH_FULL_IMAGE:figures/full_fig_p009_14.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 46 canonical work pages

  1. [1]

    A border gateway protocol 4 (BGP-4),

    Y . Rekhter, T. Li, and S. Hares, “A border gateway protocol 4 (BGP-4),” No. rfc4271, 2006

    work page 2006

  2. [2]

    Internet routing instability,

    C. Labovitz, G. R. Malan, and F. Jahanian, “Internet routing instability,” IEEE/ACM Transactions on Networking , vol. 6, no. 5, pp. 515–528, 1998

    work page 1998

  3. [3]

    Detecting BGP instability using recurrence quantification analysis (RQA),

    B. Al-Musawi, P. Branch, and G. Armitage, “Detecting BGP instability using recurrence quantification analysis (RQA),” 2015 IEEE 34th Inter- national Performance Computing and Communications Conference , pp. 1–8, 2015

    work page 2015

  4. [4]

    BGP anomaly detection techniques: A survey,

    B. Al-Musawi, P. Branch, and G. Armitage, “BGP anomaly detection techniques: A survey,” IEEE Communications Surveys & Tutorials , vol. 19, no. 1, pp. 377–396, 2016

    work page 2016

  5. [5]

    BGP anomaly detection as a group dynamics problem,

    B. A. Scott, M. N. Johnstone, P. Szewczyk, and S. Richardson, “BGP anomaly detection as a group dynamics problem,” Computer Networks, vol. 257, p. 110926, 2025

    work page 2025

  6. [6]

    Matrix profile data mining for BGP anomaly detection,

    B. A. Scott, M. N. Johnstone, P. Szewczyk, and S. Richardson, “Matrix profile data mining for BGP anomaly detection,” Computer Networks , vol. 242, p. 110257, 2024

    work page 2024

  7. [7]

    BGP anomaly detection based on automatic feature extraction by neural network,

    M. Xu and X. Li, “BGP anomaly detection based on automatic feature extraction by neural network,” 2020 IEEE 5th Information Technology and Mechatronics Engineering Conference , pp. 46–50, 2020

    work page 2020

  8. [8]

    Suitability of graph representation for BGP anomaly detection,

    K. Hoarau, P. U. Tournoux, and T. Razafindralambo, “Suitability of graph representation for BGP anomaly detection,” 2021 IEEE 46th Conference on Local Computer Networks , pp. 305–310, 2021

    work page 2021

Show all 49 references
  1. [9]

    Optimal detection of border gateway protocol anomalies with extensive feature set,

    M. Sunita and S. V . Mallapur, “Optimal detection of border gateway protocol anomalies with extensive feature set,” Multimedia Tools and Applications, vol. 83, no. 17, pp. 50 893–50 919, 2024

    2024

  2. [10]

    ISP self-operated BGP anomaly detection based on weakly supervised learning,

    Y . Dong, Q. Li, R. O. Sinnott, Y . Jiang, and S. Xia, “ISP self-operated BGP anomaly detection based on weakly supervised learning,” 2021 IEEE 29th International Conference on Network Protocols , pp. 1–11, 2021

    2021

  3. [11]

    Using bursty announcements for detecting BGP routing anomalies,

    P. Moriano, R. Hill, and L. J. Camp, “Using bursty announcements for detecting BGP routing anomalies,” Computer Networks, vol. 188, p. 107835, 2021

    2021

  4. [12]

    Unveiling the potential of graph neural networks for BGP anomaly detection,

    H. Latif, J. Pailliss ´e, J. Yang, A. Cabellos-Aparicio, and P. Barlet-Ros, “Unveiling the potential of graph neural networks for BGP anomaly detection,” Proceedings of the 1st International Workshop on Graph Neural Networking, pp. 7–12, 2022

    2022

  5. [13]

    A multi-view framework for BGP anomaly detection via graph attention network,

    S. Peng, J. Nie, X. Shu, Z. Ruan, L. Wang, Y . Sheng, and Q. Xuan, “A multi-view framework for BGP anomaly detection via graph attention network,” Computer Networks, vol. 214, 2022

    2022

  6. [14]

    Anomalous model-driven-telemetry network-stream BGP detection,

    R. A. Fezeu and Z.-L. Zhang, “Anomalous model-driven-telemetry network-stream BGP detection,” 2020 IEEE 28th International Confer- ence on Network Protocols , pp. 1–6, 2020

    2020

  7. [15]

    Realtime BGP anomaly detection using graph centrality features,

    J. Huang, M. Odiathevar, A. Valera, J. Sahni, M. Frean, and W. K. Seah, “Realtime BGP anomaly detection using graph centrality features,” International Conference on Advanced Information Networking and Applications, pp. 222–233, 2024

    2024

  8. [16]

    A survey of large language models,

    W. X. Zhao, K. Zhou, J. Li, T. Tang, X. Wang, Y . Hou, Y . Min, B. Zhang, J. Zhang, Z. Dong et al. , “A survey of large language models,” arXiv preprint arXiv:2303.18223, 2023

    2023 arXiv

  9. [17]

    Can LLMs understand time series anomalies?

    Z. Zhou and R. Yu, “Can LLMs understand time series anomalies?” The Thirteenth International Conference on Learning Representations , 2025

    2025

  10. [18]

    Cair: Using formal languages to study routing, leaking, and interception in BGP,

    J. Schlamp, M. W ¨ahlisch, T. C. Schmidt, G. Carle, and E. W. Biersack, “Cair: Using formal languages to study routing, leaking, and interception in BGP,” arXiv preprint arXiv:1605.00618 , 2016

    2016 arXiv

  11. [19]

    Oscilloscope: Detecting BGP hijacks in the data plane,

    T. B ¨uhler, A. Milolidakis, R. Jacob, M. Chiesa, S. Vissicchio, and L. Vanbever, “Oscilloscope: Detecting BGP hijacks in the data plane,” arXiv preprint arXiv:2301.12843 , 2023

    2023 arXiv

  12. [20]

    (2013) University of oregon routeviews project

    RouteViews. (2013) University of oregon routeviews project. [Online]. Available: https://routeviews.org

    2013

  13. [21]

    (2025) RIPE: Routing information service (RIS)

    RIPE. (2025) RIPE: Routing information service (RIS). [On- line]. Available: https://www.ripe.net/analyse/internet-measurements/ routing-information-service-ris/

    2025

  14. [22]

    Detecting BGP anomalies with wavelet,

    J. Mai, L. Yuan, and C.-N. Chuah, “Detecting BGP anomalies with wavelet,” NOMS 2008-2008 IEEE Network Operations and Management Symposium, pp. 465–472, 2008

    2008

  15. [23]

    BGP-lens: Patterns and anomalies in internet routing updates,

    B. A. Prakash, N. Valler, D. Andersen, M. Faloutsos, and C. Faloutsos, “BGP-lens: Patterns and anomalies in internet routing updates,”Proceed- ings of the 15th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , pp. 1315–1324, 2009

    2009

  16. [24]

    An internet routing forensics framework for discovering rules of abnormal BGP events,

    J. Li, D. Dou, Z. Wu, S. Kim, and V . Agarwal, “An internet routing forensics framework for discovering rules of abnormal BGP events,” ACM SIGCOMM Computer Communication Review , vol. 35, no. 5, pp. 55–66, 2005

    2005

  17. [25]

    An anomaly detection framework for BGP,

    I. O. de Urbina Cazenave, E. K ¨os ¸l¨uk, and M. C. Ganiz, “An anomaly detection framework for BGP,” 2011 International Symposium on Inno- vations in Intelligent Systems and Applications , pp. 107–111, 2011

    2011

  18. [26]

    Machine learning models for clas- sification of BGP anomalies,

    N. M. Al-Rousan and L. Trajkovi ´c, “Machine learning models for clas- sification of BGP anomalies,” 2012 IEEE 13th International Conference on High Performance Switching and Routing , pp. 103–108, 2012

    2012

  19. [27]

    Separating wheat from chaff: Winnowing unintended prefixes using machine learning,

    A. Lutu, M. Bagnulo, J. Cid-Sueiro, and O. Maennel, “Separating wheat from chaff: Winnowing unintended prefixes using machine learning,” IEEE INFOCOM 2014-IEEE Conference on Computer Communications, pp. 943–951, 2014

    2014

  20. [28]

    Diagnosing network dis- ruptions with network-wide analysis,

    Y . Huang, N. Feamster, A. Lakhina, and J. Xu, “Diagnosing network dis- ruptions with network-wide analysis,” ACM SIGMETRICS Performance Evaluation Review, vol. 35, no. 1, pp. 61–72, 2007

    2007

  21. [29]

    An online mecha- nism for BGP instability detection and analysis,

    S. Deshpande, M. Thottan, T. K. Ho, and B. Sikdar, “An online mecha- nism for BGP instability detection and analysis,” IEEE Transactions on Computers, vol. 58, no. 11, pp. 1470–1484, 2009

    2009

  22. [30]

    Detection of interdomain routing anomalies based on higher-order path analysis,

    M. C. Ganiz, S. Kanitkar, M. C. Chuah, and W. M. Pottenger, “Detection of interdomain routing anomalies based on higher-order path analysis,” Sixth International Conference on Data Mining , pp. 874–879, 2006

    2006

  23. [31]

    A novel unsupervised method for securing BGP against routing hijacks,

    G. Theodoridis, O. Tsigkas, and D. Tzovaras, “A novel unsupervised method for securing BGP against routing hijacks,” Computer and Information Sciences III: 27th International Symposium on Computer and Information Sciences , pp. 21–29, 2012

    2012

  24. [32]

    Pretty good BGP: Improving BGP by cautiously adopting routes,

    J. Karlin, S. Forrest, and J. Rexford, “Pretty good BGP: Improving BGP by cautiously adopting routes,” Proceedings of the 2006 IEEE International Conference on Network Protocols , pp. 290–299, 2006

    2006

  25. [33]

    PHAS: A prefix hijack alert system

    M. Lad, D. Massey, D. Pei, Y . Wu, B. Zhang, and L. Zhang, “PHAS: A prefix hijack alert system.” USENIX Security Symposium , vol. 1, no. 2, p. 3, 2006

    2006

  26. [34]

    Ne- tReview: Detecting when interdomain routing goes wrong

    A. Haeberlen, I. C. Avramopoulos, J. Rexford, and P. Druschel, “Ne- tReview: Detecting when interdomain routing goes wrong.” USENIX Symposium on Networked Systems Design and Implementation , vol. 2009, pp. 437–452, 2009

    2009

  27. [35]

    Detecting prefix hijackings in the internet with argus,

    X. Shi, Y . Xiang, Z. Wang, X. Yin, and J. Wu, “Detecting prefix hijackings in the internet with argus,” Proceedings of the 2012 Internet Measurement Conference, pp. 15–28, 2012

    2012

  28. [36]

    A light-weight distributed scheme for detecting IP prefix hijacks in real-time,

    C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis, “A light-weight distributed scheme for detecting IP prefix hijacks in real-time,” ACM SIGCOMM Computer Communication Review , vol. 37, no. 4, pp. 277– 288, 2007

    2007

  29. [37]

    Accurate real-time identification of ip prefix hijacking,

    X. Hu and Z. M. Mao, “Accurate real-time identification of ip prefix hijacking,” 2007 IEEE Symposium on Security and Privacy , pp. 3–17, 2007

    2007

  30. [38]

    A method to detect prefix hijacking by using ping tests,

    M. Tahara, N. Tateishi, T. Oimatsu, and S. Majima, “A method to detect prefix hijacking by using ping tests,” Proceedings of the 11th Asia-Pacific Symposium on Network Operations and Management: Chal- lenges for Next Generation Network Operations and Service Manage- ment, pp. ...

    2008

  31. [39]

    ispy: Detecting ip prefix hijacking on my own,

    Z. Zhang, Y . Zhang, Y . C. Hu, Z. M. Mao, and R. Bush, “ispy: Detecting ip prefix hijacking on my own,” Proceedings of the ACM SIGCOMM 2008 Conference on Data Communication , pp. 327–338, 2008

    2008

  32. [40]

    What do LLMs need to synthesize correct router configurations?

    R. Mondal, A. Tang, R. Beckett, T. Millstein, and G. Varghese, “What do LLMs need to synthesize correct router configurations?” Proceedings of the 22nd ACM Workshop on Hot Topics in Networks , pp. 189–195, 2023

    2023

  33. [41]

    Mobile-llama: Instruction fine-tuning open-source llm for network analysis in 5g networks,

    K. B. Kan, H. Mun, G. Cao, and Y . Lee, “Mobile-llama: Instruction fine-tuning open-source llm for network analysis in 5g networks,” IEEE Network, 2024

    2024

  34. [42]

    Providing an ai-enabled network assistant for command line interface environments,

    M. Palmero, K. P. Annamalai, H. Singaravelan, D. Zacks, and J. W. Capobianco, “Providing an ai-enabled network assistant for command line interface environments,” Technical Disclosure Commons, 2024

    2024

  35. [43]

    BGP- Stream: A software framework for live and historical BGP data analysis,

    C. Orsini, A. King, D. Giordano, V . Giotsas, and A. Dainotti, “BGP- Stream: A software framework for live and historical BGP data analysis,” Proceedings of the 2016 Internet Measurement Conference , p. 429–444, 2016

    2016

  36. [44]

    Chain-of-thought prompting elicits reasoning in large language models,

    J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V . Le, D. Zhou et al. , “Chain-of-thought prompting elicits reasoning in large language models,” Advances in Neural Information Processing Systems , vol. 35, pp. 24 824–24 837, 2022

    2022

  37. [45]

    A survey on in-context learning,

    Q. Dong, L. Li, D. Dai, C. Zheng, J. Ma, R. Li, H. Xia, J. Xu, Z. Wu, B. Chang et al., “A survey on in-context learning,” Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, pp. 1107–1128, 2024

    2024

  38. [46]

    The next generation of BGP data collection platforms,

    T. Alfroy, T. Holterbach, T. Krenc, K. Claffy, and C. Pelsser, “The next generation of BGP data collection platforms,” Proceedings of the ACM SIGCOMM 2024 Conference , pp. 794–812, 2024

    2024

  39. [47]

    (2025) Delayed RIS dumps for some route collectors incident report for RIPE NCC

    RIPE. (2025) Delayed RIS dumps for some route collectors incident report for RIPE NCC. [Online]. Available: https://status.ripe.net/ incidents/w76jvvvpkqts

    2025

  40. [48]

    (2025) Planned maintenance: RRC19 NAP Africa Johannesburg hardware migration

    RIPE. (2025) Planned maintenance: RRC19 NAP Africa Johannesburg hardware migration. [Online]. Available: https://status.ripe.net/incidents/ w76jvvvpkqts

    2025

  41. [49]

    Siddiqui

    A. Siddiqui. (2023) BGP route leak at Angola Cables slows connectivity for many Australians. [Online]. Available: https://manrs.org/2023/05/ bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/

    2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.