How do I reproduce a BGP problem before I open a vendor case?

A vendor case moves faster with a reproduction: the smallest topology that shows the symptom, the configs, and the exact commands whose output is wrong. Build the two or three routers involved on the same OS image, replay the configs, and capture show bgp neighbor, the received and advertised routes and the policy evaluation. The reproduction is what goes into the case, and the same lab is where the fix gets tried first. In ChatGPT, Claude or Meta Muse with NetPilot connected, you describe the symptom and the assistant builds the routers on real images and runs the commands.

The reproduction, in five steps

  1. 1

    Shrink the topology to the symptom

    The peer that misbehaves, the router it peers with, and one router behind it that originates or should receive the prefix. If the symptom still shows with three routers, the case needs three routers, not the whole site.

  2. 2

    Use the same network OS image

    Cisco IOL for IOS, Cisco XRd for IOS XR, Cisco NX-OS for Nexus, Juniper cRPD for Junos, Arista cEOS for EOS, Nokia SR Linux, SONiC or FRR. The assistant deploys the image you name and replays the sanitized configs onto it.

  3. 3

    Capture the session and both route views

    The neighbour detail, the routes received from the peer before policy, the routes advertised to it, the BGP table entry for the prefix, and the route-map or policy that the session applies. One capture per router, timestamps on.

  4. 4

    Package the reproduction

    Topology, the configs, the OS version, the command list and the outputs, and the one line that states what is wrong. That is the case attachment, and the vendor engineer can replay it in their own lab from it.

  5. 5

    Try the fix in the same lab first

    The workaround the vendor suggests runs here with the same commands before anyone types it on a production router. If the after output is right, the same commands verify it in the window.

Say this to the assistant

R1 (AS 65001) peers with R2 (AS 65002) and is not installing 10.50.0.0/24, which R3 behind R2 originates. Build the three routers on Cisco IOL with the configs I pasted, enable soft-reconfiguration inbound on R1 for the R2 session, then run show ip bgp summary, show ip bgp neighbors 10.0.12.2 received-routes, show ip bgp 10.50.0.0/24 and show route-map FROM-AS65002 on R1 and quote the output.

The commands, by network OS

The pair that settles most BGP cases is received-routes against the BGP table: it separates "the peer never sent it" from "we received it and dropped it". On Cisco IOS the received view needs soft-reconfiguration inbound on the neighbour, which the assistant adds in the lab when you ask for it.

Network OSCommands to run before and after
Cisco IOS (IOL)
show ip bgp summaryshow ip bgp neighbors 10.0.12.2show ip bgp neighbors 10.0.12.2 received-routesshow ip bgp neighbors 10.0.12.2 advertised-routesshow ip bgp 10.50.0.0/24show route-map FROM-AS65002
Juniper Junos (cRPD)
show bgp summaryshow bgp neighbor 10.0.12.2show route receive-protocol bgp 10.0.12.2show route advertising-protocol bgp 10.0.12.2show route 10.50.0.0/24 detailtest policy FROM-AS65002 10.50.0.0/24
Arista EOS (cEOS)
show ip bgp summaryshow ip bgp neighbors 10.0.12.2 received-routesshow ip bgp neighbors 10.0.12.2 advertised-routesshow ip bgp 10.50.0.0/24
FRR and SONiC
vtysh -c "show bgp summary"vtysh -c "show bgp ipv4 unicast neighbors 10.0.12.2 received-routes"vtysh -c "show bgp ipv4 unicast neighbors 10.0.12.2 advertised-routes"vtysh -c "show bgp ipv4 unicast 10.50.0.0/24"

What the output looks like

The symptom in the prompt above: R1 does not install 10.50.0.0/24. The reproduction shows the prefix arriving from R2 with the path 65002 65003, the BGP table without it, and the inbound route-map matching an as-path list that permits only paths from AS 65002 itself. The prefix is dropped by local policy, which is the finding, and the case either closes or becomes a question about the policy, with the evidence attached.

R1
R1# show ip bgp neighbors 10.0.12.2 received-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.20.0.0/24     10.0.12.2                0             0 65002 i
 *   10.50.0.0/24     10.0.12.2                0             0 65002 65003 i

Total number of prefixes 2

R1# show ip bgp 10.50.0.0/24
% Network not in table

R1# show route-map FROM-AS65002
route-map FROM-AS65002, permit, sequence 10
  Match clauses:
    as-path (as-path filter): 1
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

R1# show ip as-path-access-list 1
AS path access list 1
    permit ^65002$

Running the commands on both routers at once

The assistant runs the capture on every router in one go and quotes each device's output under its name. Every device is also a normal SSH target, so the vendor's suggested command can be typed by hand on the router, as in this capture from the NetPilot web app.

app.netpilot.io

What you need

  • A NetPilot account on Pro, Max, Team or Signature, including a Team seat or a Signature seat in an organization. On Free or Plus you can connect and sign in, and each tool answers with a note that the feature is included from Pro.
  • NetPilot connected in your assistant: ChatGPT, Claude.ai, Claude Code or Meta Muse. The lab VM is created the first time you ask the assistant to start it.
  • The sanitized configs of the routers involved and the OS image they run. Nokia SR Linux and FRR are built in. Cisco IOL, Cisco XRd, Cisco NX-OS, Juniper cRPD, Arista cEOS and SONiC run as bring-your-own-image (BYOI), added once in the NetPilot app.

Run it from the chat you already have open

  1. 1Connect NetPilot in ChatGPT, Claude or Meta Muse: how to connect, step by step.
  2. 2A NetPilot account on Pro, Max, Team or Signature, including a Team seat or a Signature seat in an organization. On Free or Plus you can connect and sign in, and each tool answers with a note that the feature is included from Pro. Plans and lab credits.

Common questions

Build the smallest topology that shows the symptom, usually the misbehaving peer, the router it peers with and one router behind it, on the same network OS image as production. Replay the sanitized configs, then capture the neighbour detail, the routes received from the peer, the routes advertised to it, the BGP table entry for the prefix and the policy the session applies. Those outputs are the reproduction that goes into the case. With NetPilot connected in ChatGPT, Claude or Meta Muse, you describe the symptom and the assistant builds the routers on real images in your lab VM and runs the commands.
The topology with the AS numbers, the configs of the routers involved, the exact OS version, the commands whose output is wrong and that output, when the problem started and what changed around that time. A reproduction on the same image answers all of it in one attachment and lets the vendor engineer replay the problem in their own lab instead of asking you for the next show command.
Then the trigger is outside the three routers, which is a finding in itself. The usual suspects are timing (the problem needs a flap or a specific order of updates), scale (a full table, many peers), a feature that only exists on the production platform, or an image version that differs from the one in the lab. Say which one you ruled out in the case, and widen the lab one device or one feature at a time until the symptom appears. A good share of cases end here, when the reproduction shows a local policy or a config line doing exactly what it was told.

Reproduce it before you open the case

Create a NetPilot account, pick Pro or above, and connect NetPilot in ChatGPT, Claude or Meta Muse.