Can AI predict BGP bestpath changes better than a checklist

Introduction to BGP Forecasting

Border Gateway Protocol (BGP) is the de facto standard inter‑domain routing protocol. Each BGP update carries attributes that influence the decision process:

• AS_PATH – list of traversed ASNs (loop detection, path length preference).
• LOCAL_PREF – degree of preference within the local AS (higher wins).
• MED – Multi‑Exit Discriminator (lower is preferred).
• ORIGIN – IGP, EGP, or INCOMPLETE (tie‑breaker).
• COMMUNITY – optional transitive tags for policy signaling.
• WEIGHT (Cisco‑specific) – local router preference (highest wins).

The BGP best‑path algorithm is a deterministic, ordered list of comparison steps (Cisco/Juniper follow RFC 4271 with vendor extensions). Changing any attribute can alter the outcome for one or more prefixes, affecting traffic engineering, load balancing, or causing routing loops if policies are misaligned.

Operators edit BGP attributes to implement traffic engineering, mitigate congestion, or enforce business relationships. Before committing changes to production, it is critical to forecast the resulting best‑path selection and any side‑effects (unintended blackholing, suboptimal paths, protocol oscillations). Accurate forecasting reduces service‑impact risk, shortens maintenance windows, and provides an audit trail for change management.

Three complementary approaches exist for this forecasting task:

1. Manual reasoning – the operator applies the BGP decision algorithm by hand or with simple calculators.
2. Deterministic policy simulation – a software tool replays the BGP decision process on a modeled topology.
3. AI‑assisted operator workflow – a language model (LM) suggests attribute edits, interprets simulation output, and guides the operator, while the final decision remains grounded in deterministic verification.

The remainder of this article examines each approach in depth, compares them against a common set of inputs and success criteria, and discusses operational considerations for deployment.

Approach 1: Manual Reasoning

Methodology and Limitations

Manual reasoning involves the operator:

1. Extracting the relevant BGP attributes for the prefix(es) of interest from the current RIB (Routing Information Base) or from peer advertisements.
2. Applying the vendor‑specific BGP best‑path algorithm step‑by‑step to determine which path would win after a proposed attribute change.
3. Documenting the reasoning (e.g., in a change‑request ticket) for peer review.

Limitations

• Cognitive load – the algorithm contains up to 10+ comparison steps, each with vendor‑specific nuances (e.g., Cisco’s weight, Juniper’s local‑preference handling, multipath considerations).
• Error proneness – mis‑reading an attribute, forgetting a tie‑breaker, or overlooking a community‑based policy leads to incorrect forecasts.
• Scalability – reasoning manually over dozens of prefixes or multiple peers becomes impractical; time grows linearly with the number of paths examined.
• Lack of reproducibility – without an automated record, it is difficult to re‑run the analysis after a topology change.

Despite these drawbacks, manual reasoning remains valuable for quick sanity checks, training junior engineers, and validating the output of automated tools.

Example Use Case: Manual Calculation of BGP Best Path

Consider a simple topology: AS 65001 (our AS) receives two routes to prefix 10.0.0.0/24:

• Path A via AS 65002: AS_PATH: 65002, LOCAL_PREF: 100, MED: 50, ORIGIN: IGP.
• Path B via AS 65003: AS_PATH: 65003 65004, LOCAL_PREF: 120, MED: 100, ORIGIN: IGP.

The operator proposes to raise the LOCAL_PREF of Path A to 150.

Manual steps (Cisco‑style)

1. Highest WEIGHT – not configured, skip.
2. Highest LOCAL_PREF – Path A now 150 > Path B 120 → Path A wins.
   Since LOCAL_PREF is the second step, the algorithm stops here; no further comparison is needed.

If the operator instead attempted to lower the MED of Path B to 20, the reasoning would be:

1. WEIGHT – tie.
2. LOCAL_PREF – Path B 120 > Path A 100 → Path B wins (unless LOCAL_PREF is changed).
   Thus, the MED change would have no effect unless LOCAL_PREF is equalized.

Troubleshooting Common Errors in Manual Reasoning

Corrective action: re‑extract the exact attribute set from the RIB, verify vendor‑specific defaults, and repeat the step‑wise comparison. Using a scratchpad or a simple spreadsheet can reduce transcription errors.

Approach 2: Deterministic Policy Simulation

Overview of Simulation Tools and Techniques

Deterministic simulation replays the BGP decision process on a model of the network topology, policy configuration, and RIB state. Unlike emulation (which runs actual routing daemons), a simulator works purely on data structures, making it fast and suitable for change‑impact analysis.

Common open‑source options:

• Batfish – data‑plane‑aware configuration analyzer; includes a BGP semantics model that can compute the post‑change RIB.
• FRR (Free Range Routing) with bgpd in a container – can be instantiated per‑candidate change and queried via vtysh.
• BGPStream + custom Python script – pulls live updates, applies a user‑defined attribute delta, and runs the decision algorithm via the bgpys library.
• Cisco Modeling Labs (CML) / VIRL – full‑blown emulation, heavier but provides real‑OS behavior.

For forecasting, the simulator must support:

• Import of the current configuration (or a snapshot of the RIB).
• Injection of a policy delta (attribute modification).
• Re‑execution of the BGP best‑path algorithm.
• Export of the resulting paths (e.g., as JSON or CSV).

Configuring and Running Simulations

Batfish Workflow (version 2023.12.0)

Batfish operates purely on configuration snapshots and provides a declarative query language.

1. Snapshot collection

   # On the router or via a management script
   ssh admin@router1 "show running-config" > router1.cfg
   ssh admin@router2 "show running-config" > router2.cfg
   # Repeat for all routers in the AS
   mkdir -p snapshot
   mv *.cfg snapshot/

2. Initialize Batfish service (Docker)

   docker run -d --name bf -p 9996:9996 -v $(pwd)/snapshot:/snapshot batfish/allinone

3. Load the snapshot

   curl -X POST http://localhost:9996/api/v1/snapshots?name=bgp_forecast \
        -F "snapshot=@snapshot/"

4. Define the attribute change – using Batfish’s question framework. Example: raise LOCAL_PREF for paths learned from neighbor 192.0.2.2 on prefix 10.0.0.0/24 to 200.
   Create a file change.policy:

   {
     "questions": [
       {
         "question": "bgpProcessDeltas",
         "parameters": {
           "Nodes": ["/router1/", "/router2/"],
           "Deltas": [
             {
               "Location": {
                 "Node": "/router1/",
                 "Interface": "GigabitEthernet0/0",
                 "AddressFamily": "ipv4",
                 "Protocol": "bgp",
                 "Neighbor": "192.0.2.2"
               },
               "Action": "set",
               "Attribute": "LOCAL_PREF",
               "Value": 200,
               "MatchCriteria": {
                 "DestinationNetwork": "10.0.0.0/24"
               }
             }
           ]
         }
       }
     ]
   }

5. Run the question

   curl -X POST http://localhost:9996/api/v1/questions \
        -H "Content-Type: application/json" \
        -d @change.policy

   The response includes a result field containing the updated BGP RIB for each node.

6. Extract the forecast – e.g., query the best path for the prefix:

   curl -X GET "http://localhost:9996/api/v1/questions/<questionId>/answers?answer=bgpRoutes" \
        -H "Accept: application/json"

   Parse the JSON to see which AS_PATH is selected for 10.0.0.0/24 on each router.

FRR‑Based Workflow (if Batfish is unavailable)

# 1. Build a base FRR image with config volume
docker run -d --name frr_bgp \
   -v $(pwd)/frr_conf:/etc/frr \
   -p 2605:2605 \
   frrouting/frr:8.4

# 2. Copy current configuration into the container
docker cp router1.conf frr_bgp:/etc/frr/frr.conf
docker cp peers.conf frr_bgp:/etc/frr/peers.conf

# 3. Reload FRR to apply config
docker exec frr_bgp vtysh -c "configure terminal" -c "exit" -c "reload"

# 4. Apply attribute change via vtysh (example: set LOCAL_PREF 200 for neighbor 192.0.2.2)
docker exec frr_bgp vtysh <<EOF
configure terminal
router bgp 65001
 neighbor 192.0.2.2 route-map SET_LOCALPREF in
exit
route-map SET_LOCALPREF permit 10
 match ip address prefix-list TARGET_PREFIX
 set local-preference 200
exit
exit
write memory
EOF

# 5. Show the resulting BGP table
docker exec frr_bgp vtysh -c "show bgp ipv4 unicast 10.0.0.0/24"

Interpreting Simulation Results and Success Criteria

The success criteria for a forecast are:

• Correctness – the simulated best path must match the actual post‑change path observed on the router (validated in a lab or via a canary).
• Completeness – all affected prefixes (those whose attribute matches the change criteria) are reported.
• Determinism – given the same input snapshot and delta, the simulator always produces the same output.
• Performance – the time to produce the forecast should be compatible with change‑management windows (typically < 30 s for a medium‑size AS).

Operators examine the simulator output for:

• Path attributes (AS_PATH, LOCAL_PREF, MED) of the selected route.
• Path count (whether multipath is enabled).
• Potential loops (AS_PATH containing the local ASN).
• Policy violations (e.g., a community that should have blocked the prefix is still present).

If any of these checks fail, the change is rejected or revised before production deployment.

Approach 3: AI‑Assisted Operator Workflow

Introduction to AI in Networking and BGP Forecasting

Large language models (LLMs) excel at interpreting natural‑language intent, retrieving relevant documentation, and suggesting configuration snippets. In the context of BGP forecasting, an LLM can:

1. Translate an operator’s high‑level goal (e.g., “I want to prefer traffic from AS 65002 for prefix 10.0.0.0/24”) into a concrete attribute delta (e.g., increase LOCAL_PREF for routes learned from 192.0.2.2).
2. Explain the reasoning behind the suggestion, citing relevant BGP algorithm steps.
3. Invoke external tools (simulators, configuration validators) via tool‑calling APIs to verify the suggestion.
4. Present the verification result in a concise, operator‑friendly format, highlighting any risks.

Crucially, the LLM does not make the final forwarding decision; it acts as an advisory layer whose output must be validated by a deterministic simulator or the actual router.

Architecture of AI‑Assisted BGP Forecasting Systems

A production‑grade workflow consists of the following loosely coupled components:

+-------------------+       +---------------------+       +-------------------+
|   Operator UI     | <---> |   LLM Agent (Tool)  | <---> |  Deterministic    |
|   (Chat/CLI)      |       |   (e.g., LangChain) |       |  Simulator (Batfish|
+-------------------+       +---------------------+       |  / FRR)           |
        ^                           ^                         +-------------------+
        |                           |                             |
        |                           |                           +-------------------+
        |                           |                           |  Policy Store /    |
        |                           |                           |  Config Snapshots  |
        |                           |                           +-------------------+
        |                           |
        |                           +-------------------+
        |                           |  Safety / Approval |
        |                           |  Gate (Human‑in‑the‑loop) |
        |                           +-------------------+
        |
        +---------------------------+-------------------+
                                    |
                            +-------------------+
                            |  Audit & Logging  |
                            +-------------------+

Key interfaces

• LLM ↔ Tool – the LLM emits a structured JSON action (e.g., { "name": "run_simulation", "args": { "snapshot": "...", "delta": {...} } }). The tool executor runs the simulation and returns a result payload.
• Tool ↔ Simulator – a thin wrapper that translates the LLM’s delta into the simulator’s native format (Batfish question, FRR vtysh script, etc.).

The workflow keeps the operator in the loop: the LLM proposes, the simulator verifies, and the operator approves or rejects the change. This combines the speed and natural‑language flexibility of AI with the rigor of deterministic verification.

Operational Considerations

• Trust boundary – never allow the LLM to push configuration directly; always route proposals through a deterministic verification step.
• Model grounding – augment the LLM with up‑to‑date vendor documentation and retrieval‑augmented generation (RAG) to reduce hallucination.
• Auditability – log every LLM suggestion, tool call, and simulation result for compliance and post‑mortem analysis.
• Fallback – if the LLM fails to produce a valid suggestion, fall back to manual reasoning or a preset script library.

By following this hybrid approach, operators gain the productivity benefits of AI