Turn OSPF and BGP captures into routing evidence.
PacketSense reconstructs observed control-plane behavior directly from PCAP and PCAPNG evidence — mapping OSPF adjacencies, BGP sessions, topology, prefixes, policy drift and application impact back to the exact packets that support each conclusion.
A forensic routing workspace — not another packet dump.
Instead of leaving engineers to inspect individual routing packets, PacketSense organizes captured OSPF and BGP traffic into routing-health summaries, interactive topology, adjacency and session analysis, prefix and path evidence, policy validation and packet-backed findings.
Native and local-first — no tshark, Wireshark, dumpcap or cloud service required to analyze a routing capture. Every conclusion stays connected to the underlying packets via Filter and Jump to packet.
OSPFv2 and OSPFv3, reconstructed from the capture.
Router and area discovery, evidence-based adjacency analysis, authentication and timer profiles, and observed LSA/LSDB evidence — all presented as observations, not unobserved device configuration.
Router & area discovery
- Router IDs and source addresses
- OSPF areas and multi-area participation
- Observed neighbors and relationships
- Packet counts per router
Adjacency analysis
- Hello, DBD, LSR/LSU/LSAck activity
- Adjacency direction and inferred state
- One-way Hello & missing reciprocal neighbor
- Confidence level for each inference
Auth & timer profiles
- OSPF version and authentication evidence
- Hello and dead intervals
- Area-specific timer profiles
- Inconsistent values across routers
LSA & LSDB evidence
- Router, Network and OSPFv3 LSAs
- LSA age, sequence and advertising router
- First-version observed route reconstruction
- Packet references for each LSA class
Inferred from captured traffic — observations, not device configuration.
Sessions, prefixes, paths and policy — from captured exchanges.
PacketSense turns captured BGP into session, prefix, path and policy evidence, including IPv4 and IPv6 MP-BGP — with confidence levels and honest handling of partial captures.
42 prefixes · OPEN→KEEPALIVE→UPDATE
OPEN observed; no later evidence (capture limit)
NOTIFICATION: Hold Timer Expired
Open-only means the capture lacks later session evidence — a lead, not proof the peer failed.
Session discovery
- BGP speakers, peers and AS numbers
- BGP identifiers and address families
- Negotiated capabilities and hold timers
- Packets belonging to each session
Session stability
- OPEN / KEEPALIVE / UPDATE / NOTIFICATION
- Established, open-only and reset evidence
- Repeated session transitions (flap)
- Confidence in the inferred condition
Prefix & path analysis
- Announced and withdrawn prefixes
- IPv4 and IPv6 MP-BGP NLRI
- Next hop, AS path, communities, MED, LOCAL_PREF
- Packet evidence for each announcement
Policy & stability findings
- Private ASNs and suspected AS-path loops
- Route-flap and unexpected communities
- Structured NOTIFICATION reset reasons
- Prefix or session drift from a baseline
Interactive evidence topology
A relationship graph built from the capture — OSPF areas and routers, BGP speakers and sessions, ASNs and announced prefixes. Pan, zoom, fit-to-view, OSPF-only and BGP-only modes, node and link selection, and jump straight to the supporting packets. It visualizes what the capture proves, not a claimed complete production network.
Application impact
Where the capture contains matching data-plane traffic, PacketSense connects a routing change to the applications and flows that used the affected prefix — endpoints, packet counts, and direct links to the packets. It moves an investigation from “a route changed” to “this route changed, these observed flows used the prefix, and here is the supporting evidence.” An empty result means no matching data-plane evidence was found — not that no dependency exists.
Repeatable, expected-state investigations.
Validate a capture against what you expect, or compare it to a known-good capture — all locally.
Policy templates
Define expectations for OSPF neighbors, authentication, timers, BGP peer ASNs, expected sessions, required and allowed prefixes, and capabilities — then validate a capture against them to produce packet-backed policy findings.
Known-good baselines
Save a trusted capture as a baseline and compare later captures across routers, areas, neighbors, timer and auth profiles, BGP sessions, ASNs, address families, capabilities and announced prefixes.
Portable policy packages
Export and import templates and baselines as policy packages for analyst workstations and MSP handoffs, with local SHA-256 integrity checking. Organization-signed cloud policy distribution is planned for a future enterprise release.
Findings you can act on — and defend.
Each routing finding carries severity, protocol, what happened, why it matters, confidence, the packet numbers, a generated filter, potential impact, and a recommended next action — with a direct jump to the strongest supporting packet.
Reports include a Routing RCA section: what happened, the evidence, the potential operational or application impact, and the recommended engineering action. The on-device Local Analyst Assistant can summarize routing KPIs, explain the leading control-plane concern, and suggest follow-up investigations.
What happened: One-way Hello from 10.0.0.1 to 10.0.0.3 with no reciprocal neighbor.
Why it matters: The adjacency likely never reached Full, so routes via this link may not install.
Next action: Check 10.0.0.3 interface, subnet mask and auth against 10.0.0.1.
Native routing analysis, on your machine.
Routing analysis runs on PacketSense's own native parsing and local analysis engine.
Evidence stays local
Packet evidence remains on the workstation by default — no mandatory cloud upload.
No external dependencies
No tshark runtime and no Wireshark installation required to analyze a capture.
Built for isolation
Suitable for isolated or air-gapped investigations, with consistent packaged desktop behavior.
PacketSense complements Wireshark by accelerating routing triage while preserving links back to packet-level evidence — it does not replace Wireshark's complete dissector ecosystem.
Beyond static protocol summaries.
PacketSense is designed to go beyond packet counts and manual decoding — positioned as an investigation accelerator, not a universal replacement.
vs. Wireshark
Wireshark stays stronger for exhaustive manual decoding. PacketSense adds structured OSPF/BGP workspaces, adjacency and session summaries, topology, policy workflows and guided RCA — an accelerator that works alongside it.
vs. static PCAP summaries
Goes beyond packet counts by connecting protocol events, topology, state transitions, prefix evidence, application impact, policy expectations and findings — each tied to exact packets.
vs. NMS / routing telemetry
Works from portable capture evidence — useful when monitoring was unavailable, the incident fell outside retention, only a PCAP was supplied, or evidence must be examined offline. It is not a continuous monitoring platform.
Routing analysis — common questions.
Can PacketSense analyze OSPF and BGP packet captures?
Yes. PacketSense reconstructs observed OSPF and BGP control-plane behavior directly from PCAP and PCAPNG evidence — OSPF adjacencies and areas, BGP sessions, prefixes and paths, an interactive topology, and policy findings — and links every conclusion back to the exact packets that support it. It analyzes OSPFv2, OSPFv3 and BGP (including IPv6 MP-BGP) observed in the capture.
Does PacketSense need tshark or Wireshark to analyze routing captures?
No. Routing analysis runs on PacketSense's own native, local-first parsing engine — it does not require tshark, Wireshark, dumpcap, editcap or a cloud service. That makes it suitable for isolated or air-gapped investigations, and it can still complement Wireshark by accelerating routing triage.
What does an "open-only" BGP result mean?
It means the capture contains BGP OPEN evidence but no later session activity. PacketSense treats this as a capture limitation or an investigation lead — not proof that the peer failed. Findings are always framed as what the packets show, with a stated confidence level.
Does PacketSense build the real routing table (RIB/FIB)?
No. PacketSense reconstructs observed route and topology evidence from captured LSDB and BGP data where sufficient fields exist. It does not present an authoritative router RIB or FIB, run a full OSPF SPF calculation, or simulate every BGP route-selection decision — it shows what the capture proves, clearly marked as observations.
How does PacketSense connect a routing change to application impact?
Where the capture contains matching data-plane traffic, PacketSense correlates a routing change with the applications and flows that used the affected prefix, showing endpoints, packet counts and direct links to the supporting packets. An empty impact result means no matching data-plane evidence was found in the capture — not that no dependency exists.
Analyze your routing capture.
Bring an OSPF or BGP PCAP and see the adjacencies, sessions, topology and findings — all local, all packet-backed. Request pilot access to get started.