Frequently Asked Questions

GRE tunnel discovery forms a real IGP adjacency (OSPF or IS-IS) — Osprey receives the full LSDB or LSP database and sees changes in real time as they happen. SNMP discovery polls routers at intervals to walk the OSPF-MIB, OSPFv3-MIB, or ISIS-MIB tables. GRE gives instant updates; SNMP requires no tunnel configuration on the router side.

No. Osprey is strictly passive. Even with GRE tunnels, OSPF cost is set high (default 1000) and priority is set to zero, so Osprey never becomes a designated router. IS-IS GRE tunnels use the maximum wide metric (16777215) to prevent transit use. BGP visibility is purely receive-only via BMP (RFC 7854).

Yes. An area can have both a GRE collector and an SNMP collector running simultaneously. This is useful for combining real-time GRE updates with SNMP-based traffic statistics.

With SNMP discovery, yes — tick "Crawl multi-area (BFS through ABR neighbors)" on a seed device and Osprey walks outward through the ABRs to discover the whole OSPF domain. IS-IS gets the equivalent "Crawl multi-level (BFS through L1L2 neighbors)". With GRE, you need one tunnel per area.

OSPFv2 (IPv4), OSPFv3 (IPv6, including RFC 5838 IPv4 address family extensions), IS-IS (ISO 10589, both L1 and L2, with CLNS, IPv4, and IPv6 address families), EIGRP (passively over SNMP, IPv4 and IPv6), and BGP (via BMP, RFC 7854). On top of the routed topology, Osprey discovers MPLS services (TE tunnels, L3VPNs, and L2VPN pseudowires) via SNMP and EVPN instances via BMP. A device running more than one of these is automatically correlated across protocols. When multiple protocols share a physical link, edges merge on the canvas with a per-protocol tab view.

Yes, read-only. EIGRP has no synchronized link-state database to form an adjacency into, so Osprey reads it entirely passively from the CISCO-EIGRP-MIB over the existing SNMP poller — which also means EIGRP discovery is limited to Cisco platforms. You get neighbours and interface state for IPv4 and IPv6, classic and named mode, per VRF and per AS. Because there is no shared database, the topology is reconstructed from neighbour tables the same way Layer 2 is, stitched onto the LLDP/CDP fabric. Paths follow each router's installed successor and report the real composite metric (FD) rather than a borrowed IGP cost, with equal-cost brothers shown as variants. Administrative distance, neighbour-down alerting, and an EIGRP recorder you add and switch on like any other protocol are all included, and an EIGRP domain takes part in cross-AS path analysis in both directions.

Yes. IS-IS discovery works via GRE (real adjacency using NET addressing) or SNMP (ISIS-MIB, RFC 4444, with Cisco ISIS-MIB fallback for older IOS). Level 1, Level 2, and L1/L2 routers are fully supported, with wide metrics (up to 16,777,215) by default. SR-MPLS label stack extraction is available for IS-IS IPv4/IPv6 paths via TLV 242.

Yes, passively via BMP (BGP Monitoring Protocol, RFC 7854). Your routers push peer state and RIB updates to Osprey's BMP server on TCP port 11019 — no polling. Osprey supports loc_rib (router's best paths), adj_rib_in_post (all received routes post-policy), and peer-monitoring-only modes. BGP routes can be searched with exact, longest-match, or covered prefix modes, and ECMP analysis is built in. The BGP AS-Flow view animates how routes shift between autonomous systems over a timeline, with a movers diff and per-AS drill-down, and any single prefix's best-path history can be replayed step by step. With history recording enabled, time travel shows real as-of-that-moment best-paths and peer sessions. Routers that can't export BMP get their BGP sessions discovered via SNMP.

Yes. MPLS-TE tunnels (RFC 3812), L3VPNs (RFC 4364/4382), and L2VPN pseudowires (RFC 5601, including the pre-standard Cisco dialect) are discovered via SNMP inside the normal poll cycle — no configuration beyond SNMP access. Per-PE VRFs are rolled up into L3VPNs by route-target with full-mesh vs hub-and-spoke classification, and pseudowires roll up into VPWS wires and VPLS instances. Selecting a service highlights its members on the canvas. Discovery is controlled per network with an auto / on / off toggle; tunnel reroutes, VRF-down, and pseudowire-down events feed incident correlation.

Yes. If your fabric runs EVPN, Osprey picks it up from the same BMP feed with no extra configuration: E-LAN and EVPN-VPWS instances (RFC 7432), VXLAN or MPLS encapsulation, per-PE MAC/IP counts, and Ethernet Segments. MAC mobility (a host moving between PEs) and a PE dropping out of an instance surface as correlated incident symptoms — storm-guarded so a broadcast storm never becomes an event flood.

Yes. When source and destination live in different ASes or tenant networks, the path tool stitches the IGP segments together along the BGP AS chain — each segment labelled with its own cost and a confidence level (resolved, inferred, or opaque), with the eBGP transitions drawn on the canvas. Administrative distance is honored across protocols exactly as your routers honor it. Within a domain, the path is a hop-by-hop forwarding chain: every hop is that router's own routing-table decision rather than a source-rooted shortest path, carrying its metric, route type, and full installed equal-cost set — plus per-hop route explanations, CLNS traceroute for IS-IS, and SR-MPLS label stacks. Ask an IPv6 question and you get an IPv6 answer, or an explanation of why no IPv6 path exists — never an IPv4 path presented as the IPv6 one.

Yes. LLDP and CDP neighbors are auto-discovered via SNMP walks. Osprey correlates L2 neighbors against the L3 topology using a 5-tier identity cascade (chassis ID, mgmt IP, router ID, interface IP, hostname). A toggleable L2 overlay shows switches and Layer 2 links on the canvas alongside the IGP topology. Switch crawling uses BFS with platform-based filtering to exclude APs, phones, and fabric interconnects.

SNMPv2c and SNMPv3. For v3, all security levels are supported: noAuthNoPriv, authNoPriv, and authPriv. Authentication covers MD5 and the full SHA-2 family (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512); privacy covers DES and AES-128, AES-192, and AES-256 — so you are not forced back onto deprecated algorithms.

Yes — three ways. OpenID Connect (Entra ID, Okta, Keycloak, or any OIDC-compliant provider) uses a server-side Authorization Code flow with mandatory PKCE. SAML 2.0 is supported as a service provider, with SP-initiated sign-on, a signed request, and full assertion validation — signature, audience, expiry, and a check that the response answers the request Osprey actually issued, so unsolicited and replayed assertions are rejected. LDAP and Active Directory accounts sign in through the normal username/password form with no separate button: LDAPS or StartTLS, group membership via memberOf, a group-search filter for directories without the overlay, and AD nested groups. In all three cases users are provisioned on first sign-in and their role follows your group mapping.

Yes, TOTP for local accounts, with any standard authenticator app. Enrollment is self-service with a server-rendered QR code — the secret never crosses an external service — and one-time recovery codes are shown once at setup. It is included at no extra cost, on every licence including the free evaluation.

Yes, via SCIM 2.0 (RFC 7644). Your identity provider can create, update, and deactivate Osprey accounts as staff join, change role, or leave. SCIM authenticates with a dedicated bearer token — separate from session cookies and API keys — that carries both an expiry and a revoke flag.

Local accounts keep working alongside any configured provider, and Osprey ships a recovery command line for exactly this case — so an IdP outage, a misconfigured provider, or a lost admin account never locks you out of your own monitoring.

Yes. Sign-in, failed sign-in (with the reason), sign-out, password change, and refresh-token replay attempts all land in the audit log, which is filterable by user, action, entity, and time range, and exportable to CSV. Active sessions are visible under Administration with their IP and user agent, and can be force-logged-out individually or per user.

Five systemd services: the engine (topology processing, SPF, event correlation), the API server (REST API, WebSocket, SSH proxy), the collector manager (GRE tunnels and IGP adjacencies), the SNMP poller (discovery, traffic counters, L2 crawling, MPLS and EIGRP), and the BMP server (BGP peers and RIBs on TCP 11019). Inter-service messaging is via NATS. All services are managed as a single group via osprey.target.

All data is stored in PostgreSQL on your server. Osprey is entirely self-hosted — no data leaves your infrastructure.

Osprey provides a full database backup and restore feature under Administration. You can also export a portable configuration backup that includes all hierarchy definitions, users, and settings.

Yes. Osprey is vendor-agnostic — it works with any device that speaks OSPF, IS-IS, BGP (BMP), LLDP, or CDP. This includes Cisco, Juniper, Arista, Nokia, Mikrotik, and effectively any modern networking platform. The one exception is EIGRP, which is a Cisco protocol and is read from the Cisco EIGRP MIB, so EIGRP discovery covers Cisco platforms only.

If installed via APT, simply run sudo apt update && sudo apt upgrade osprey. The package handles database migrations and service restarts automatically.