For network engineers with a BGP neighbor down, flapping or empty
BGP DeskRead the evidence before you touch the router. Every peer's state and first checks, the broken references, the numbers - then a read-only diagnosis and a change-window plan.
Paste what one router printed: show bgp summary, show bgp neighbors and the router bgp section - prompts, command echoes and route-maps included. Your browser parses it for IOS, NX-OS, IOS-XR or EOS, masks every password first, and applies the skill's state table to every peer: Active, Connect, OpenSent, Idle with their first checks, Established with zero prefixes, eBGP from a loopback with no multihop, route-maps and prefix-lists referenced but not defined, max-prefix as a percentage, flapping, and AS-path regex without token boundaries. It fills in the read-only checklist per peer. Then the diagnosis, and the change plan.
The evidence free
The parse free
Every peer
What the parse found
Policy references
The skill's read-only checklist, per peer
Your checklist and exports free
The checklist holds every read-only command in the skill's order, with this router's peers, VRFs and sources filled in - show, ping and traceroute only; nothing in it changes the configuration. The CSVs carry every peer and every finding for the ticket.
The diagnosis metered
Pricing as soon as the session is ready...
Sign inThe reply could not be read. Here it is as it came back:
Caveats
Caveats
The page's check of this reply
Saved routers
How it works - and what it cannot see
The parse reads the paste as a terminal prints it: prompts and command echoes set the context (the VRF and address family a summary belongs to), passwords, keys and communities are masked before anything else, and each block is recognised by its own header - the summary table of IOS, NX-OS, IOS-XR or EOS, the BGP neighbor detail, the router bgp section (flat or hierarchical, with peer-groups, templates and neighbor-groups resolved), route-maps, prefix-lists, AS-path lists and route-policies, and BGP log lines. A finding is raised only when the paste proves it: a reference is called missing only when that kind of definition was pasted unfiltered, and a healthy peer raises nothing.
It cannot see the peer's side of the session, an ACL or a firewall on the path, received routes the router does not store, or anything you did not paste - that is the diagnosis. Every command it suggests is read-only; clears and policy changes belong in a reviewed change window, and the page re-reads a change plan against the paste (a static re-parse - it runs nothing on any router), so a fix that does not land is flagged rather than trusted.
Configuration changes can take sessions down. A change plan is a draft from the evidence you pasted, not an operational guarantee: have it reviewed, apply it in an approved maintenance window with a rollback ready, and stage it the way your platform allows - commit confirmed on IOS-XR, a configuration session with a commit timer on EOS, a checkpoint on NX-OS, a revert timer on IOS / IOS-XE. The plan carries those lines for the detected platform.