Setting Up Topology Discovery

3. Setting Up Topology Discovery

Osprey discovers IGP topology through two methods: GRE tunnels (direct protocol adjacency) and SNMP polling (agentless discovery). Both OSPF (v2/v3) and IS-IS are supported with either method. Layer 2 adjacencies are discovered separately via LLDP/CDP — see L2 Neighbor Discovery below.

Which method gives you what. Both reconstruct the same topology, and either alone is enough to build the model. They differ in two ways worth knowing before you choose:

	GRE tunnel	SNMP polling
Router-side work	A tunnel interface, added to the IGP	None — enable SNMP, be reachable
Freshness	Real time: the routers flood changes to Osprey as they happen	One poll cycle
Live protocol header fields	Yes — LSA age/sequence/checksum (OSPF), LSP sequence/remaining lifetime/overload+attached bits (IS-IS)	Not as live values — the MIBs carry point-in-time copies, which Osprey deliberately leaves out

That last row is the one that surprises people, and the distinction is deliberate rather than technical: the OSPF and IS-IS MIBs do expose header fields, but as snapshots — an LSA age sampled somewhere in the last poll cycle, rendered next to live data, would masquerade as fresh. Osprey takes header fields only from a live protocol adjacency, so the LSDB Browser shows what it can stand behind and states plainly when age, sequence number and checksum are unavailable, rather than rendering polled copies that would look live. Add one GRE recorder to an area and those columns appear for the LSAs it received, alongside the SNMP-reconstructed ones; partial coverage is disclosed as a count rather than implied. The two methods coexist on the same area by design — an SNMP recorder for breadth, a GRE recorder where you want protocol-level fidelity.

Creating the Hierarchy

Before adding collectors, create the network hierarchy in the sidebar.

Step 1 -- Create a Network:

1. Open the sidebar by clicking the toggle tab on the left edge of the screen (or via View > Sidebar).
2. Click the + icon next to the "Networks" heading at the top.
3. Enter a name (e.g., "Production") and an optional description.
4. Click Create.

This automatically creates a hidden Autonomous System (ASN 65000) and a default Routing Domain ("default", type global) behind the scenes. You do not need to create these manually.

Step 2 -- Add a Protocol Instance:

1. Hover over the network name in the sidebar and click the + icon that appears.
2. Select Add Protocol.
3. Choose the protocol (OSPFv2, OSPFv3, IS-IS, or BGP) and enter an identifier:
   • OSPF: Enter a process ID (e.g., 1 for router ospf 1). When OSPFv3 is selected, an address family selector appears (IPv6 default, IPv4 for RFC 5838 AF extensions).
   • IS-IS: Enter an instance tag (e.g., CORE for router isis CORE). Shown in the sidebar as "IS-IS CORE".
   • BGP: Enter the local ASN (e.g., 65000). Only one BGP protocol instance is allowed per routing domain. BGP instances do not have areas -- instead, you add BMP targets under them (see Setting Up BGP Monitoring).
   • Optionally add a description.
4. Click Create.

Step 3 -- Add an Area with a Collector:

Areas (OSPF areas or IS-IS levels) are created together with their first collector through the Tunnel Quick-Add dialog. Hover over the Protocol Instance, click +, and select Add Area. This opens a dialog where you can specify the area ID (or IS-IS level), area type, and collector configuration all at once. See Method 1 or Method 2 below.

Alternatively, if you need additional routing domains (for VRFs or L3VPNs), hover over the network, click +, and select Add Routing Domain.

Tip: You can also add collectors to existing areas. Hover over an area in the sidebar, click the + icon, and choose Add Recorder (for GRE) or Add Recorder (SNMP). An area can have both a GRE collector and an SNMP collector simultaneously.

Method 1: GRE Tunnel Discovery

GRE tunnels form a real IGP adjacency with your network. Osprey receives the full link-state database and tracks changes in real time. OSPFv2, OSPFv3, and IS-IS are all supported -- the Tunnel Quick-Add dialog adapts based on the parent protocol instance.

1. Open the Tunnel Quick-Add dialog by either:
   • Hovering over a Protocol Instance in the sidebar, clicking +, and selecting Add Area (creates both the area and the collector).
   • Hovering over an existing Area in the sidebar, clicking +, and selecting Add Recorder (adds a GRE collector to an existing area).
2. Select GRE as the discovery mode (this is the default).
3. Fill in the required fields:
   • GRE Remote: The router's WAN IP (GRE tunnel destination endpoint).
   • GRE Local: The IP on your Osprey server that faces the remote router.
   • Tunnel IP: The /30 or /31 point-to-point address for the tunnel interface (e.g., 10.254.0.1/30 for OSPFv2, or fe80::1/64 for OSPFv3). For IS-IS this field is called Local Address (CIDR) and lives in the IS-IS Configuration section; the peer address is derived from the subnet.
   • Tunnel Peer: The remote end's tunnel IP (e.g., 10.254.0.2). Not asked for IS-IS (derived).
4. Optionally expand the Advanced section to configure:
   • Router ID: Osprey's OSPF router ID. Router IDs are always 32-bit dotted-decimal, even for OSPFv3. For OSPFv2 it defaults to the tunnel-local IP when left blank; for OSPFv3 there is no IPv4 address to derive it from, so the field is required (it appears in the P2P Addressing section, not under Advanced). For IS-IS, this field is replaced by NET (Network Entity Title, e.g., 49.0001.0192.0168.0001.00).
   • Hello/Dead intervals: Timer values (OSPF defaults: 10s hello, 40s dead; IS-IS defaults: 10s hello, 30s hold).
   • Cost, Priority, MTU, TTL: Fine-tuning parameters. IS-IS uses wide metrics by default (range 1--16777215).
   • Authentication: None, simple password, or MD5/SHA-HMAC with key ID. (OSPFv3 uses IPsec for authentication external to the protocol, so in-protocol authentication is hidden for v3 collectors. IS-IS supports HMAC-MD5 (RFC 5304) and HMAC-SHA-256 (RFC 5310, with key ID), configured directly in the IS-IS Configuration section; the recorder signs its Hellos, SNPs, and its own LSP, and logs — but never drops — incoming PDUs that fail verification.)
5. If creating a new area:
   • OSPF: Enter the Area ID (e.g., 0.0.0.0 for backbone; you can also use integer notation like 0 which auto-converts to dotted-decimal) and Area Type (normal, stub, or NSSA). The recorder uses this type for its OSPF Hello option bits — stub/NSSA neighbors reject Hellos with mismatched options (RFC 2328) — and a recorder added to an existing area inherits that area's type automatically.
   • IS-IS: Select the Level (Level 1, Level 2, or Level 1/2) from the dropdown.
6. Click Create. The collector-manager detects the new config within 10 seconds, creates the GRE tunnel, and starts adjacency formation.

Requirements: The Osprey server needs IP connectivity to the remote router. The collector-manager runs as root (GRE tunnels require NET_ADMIN and NET_RAW capabilities).

On the router side, configure a GRE tunnel back to Osprey and add it to the IGP. The examples below are verified working configs against Cisco IOS (the adjacency reaches FULL with Osprey's defaults).

Example (Cisco IOS, OSPFv2):

interface Tunnel100
 ip address 10.254.0.2 255.255.255.252
 ip ospf 1 area 0
 ip ospf cost 1000
 ip ospf priority 0
 tunnel source <router-wan-ip>
 tunnel destination <osprey-server-ip>
 tunnel mode gre ip

In the Tunnel Quick-Add form, set Tunnel IP = 10.254.0.1/30 (Osprey's end of that /30) and Tunnel Peer = 10.254.0.2.

Example (Cisco IOS, OSPFv3 / IPv6):

interface Tunnel100
 ipv6 enable
 ipv6 address fe80::2 link-local
 ospfv3 1 ipv6 area 0
 ospfv3 cost 1000
 tunnel source <router-wan-ip>
 tunnel destination <osprey-server-ip>
 tunnel mode gre ip

For OSPFv3 the GRE outer transport may be IPv4 or IPv6: carry IPv6 inside an IPv4 underlay (tunnel mode gre ip), or run the tunnel over an IPv6 underlay (ip6gre / Cisco tunnel mode gre ipv6) by entering IPv6 GRE Remote / GRE Local endpoints — both must be the same address family. The inner (OSPFv3) addressing is IPv6 either way: set Tunnel IP = fe80::1/64 and Tunnel Peer = fe80::2 (link-local is sufficient; OSPFv3 runs over link-local). Router IDs are still 32-bit dotted-decimal even for OSPFv3, so set a Router ID (e.g. 10.254.0.1). Tip: an IPv6 underlay for the v3 recorder and an IPv4 underlay for the v2 recorder lets a single router host both (the two tunnels are different families, so they never collide). OSPFv2/IS-IS keep an IPv4 GRE outer.

Example (Cisco IOS, IS-IS):

interface Tunnel100
 ip address 10.254.0.2 255.255.255.252
 ip router isis CORE
 isis circuit-type level-2-only
 isis metric 16777215
 isis authentication mode md5
 isis authentication key-chain OSPREY-ISIS
 tunnel source <router-wan-ip>
 tunnel destination <osprey-server-ip>
 tunnel mode gre ip

(Omit the two isis authentication lines if the recorder uses no authentication. The key chain OSPREY-ISIS / key 1 / key-string <key> must be defined globally, and the key-string must match the recorder's key.)

MTU: GRE overhead depends on the outer family. IPv4 GRE adds 24 bytes → tunnel MTU 1476 (1500 − 24). An IPv6 ip6gre underlay adds 44 bytes plus an 8-byte encap-limit option on Linux → tunnel MTU 1448 (Cisco's ip6gre defaults to 1456, so set ipv6 mtu 1448 on the tunnel to match Osprey). The recorder form auto-fits the MTU to the underlay family as you type the GRE endpoints — 1476 for an IPv4 outer, 1448 for IPv6 — so you normally never touch it; override only if your path MTU is smaller. Both ends must agree: Cisco IOS carries the interface MTU in its OSPF/OSPFv3 DBD packets and will not move past ExStart if the values differ (the classic "stuck in ExStart, repeated DBD with the Init bit" symptom), so a stale 1476 on an ip6gre tunnel silently blocks the OSPFv3 adjacency until both sides read 1448.

Warning: Ensure the hello and dead/hold intervals match on both sides. A mismatch prevents adjacency formation. Osprey defaults to 10s hello / 40s dead for OSPF, and 10s hello / 30s hold for IS-IS. Set the IS-IS metric to the maximum (16777215) to prevent the tunnel from being used for transit traffic. When IS-IS authentication is enabled on the recorder, configure the matching mode and key on the router's tunnel interface (e.g., isis authentication mode md5 with a key chain) — routers drop unauthenticated or mismatched Hellos.

Note (IS-IS over GRE): Cisco IOS carries IS-IS as CLNS directly inside the GRE tunnel (GRE protocol type 0x00FE, no inner IP), and Osprey's IS-IS GRE collector speaks exactly that encapsulation — an IS-IS GRE adjacency forms against IOS out of the box, including HMAC-MD5 authentication (validated end-to-end on Cisco IOS). Configure the tunnel with tunnel mode gre ip and ip router isis <tag> as shown above. Large link-state PDUs that IOS IPv4-fragments are reassembled automatically, so you do not need to lower the router's area-wide lsp-mtu — leave it at its default, since a mismatched lsp-mtu would freeze the area's LSDB. SNMP discovery remains available as an alternative or complement for IS-IS.

Method 2: SNMP Discovery

SNMP discovery polls routers via SNMPv2c or v3 to walk the link-state database MIB. No tunnel configuration needed on the router -- just ensure SNMP is enabled and reachable from the Osprey server. Supported MIBs: OSPFv2 (RFC 1850), OSPFv3 (RFC 5643), and ISIS-MIB (RFC 4444). For IS-IS, Osprey auto-detects Cisco proprietary ISIS-MIB OIDs and falls back to them when the standard MIB is unavailable.

Osprey polls each discovered router at a reachable management address (a probe-confirmed loopback), not at its OSPF router-id — so discovery and the multi-area crawl also work on fabrics whose management plane is IPv6-only, where the IPv4-looking router-id is not routable. When OSPFv2 and OSPFv3 both run on a dual-stack network, you can point an OSPFv2 and an OSPFv3 recorder at the same seed address; they are tracked as distinct recorders and each reuses whichever address family is actually reachable.

EIGRP (passive, Cisco-only): EIGRP has no link-state database to join, so Osprey reads it read-only from the CISCO-EIGRP-MIB. You add an EIGRP recorder the same way as any other: pick EIGRP as the protocol, give it one or more seed devices (one address per line — a single recorder carries the whole list) with SNMP credentials, and choose whether it records one EIGRP AS or every AS it finds. Address families are never a choice: one recorder always records both IPv4 and IPv6 — the MIB tags each row's family and Osprey files every discovered (AS, family) combination as its own instance. On a network with nothing but EIGRP the seeds are also how the devices come to exist: the recorder creates them and files them under its own network. Recording is deliberate — a device is not probed for EIGRP until a recorder covers it — and the recorder also decides where the result lands in your hierarchy. Behind the scenes nothing is tunnelled and no session is formed: the SNMP poller does the reading. Where a device runs EIGRP, its detail drawer gains an EIGRP tab listing the adjacencies (local port, peer address for IPv4 and IPv6, AS, VRF, hold/SRTT/RTO, uptime) and the EIGRP-enabled interfaces (hello, peer count, mean SRTT). Where both ends of an adjacency are known, the link is also drawn on the topology canvas like any other IGP's, and picks up topology diff, history, live updates and the exports along with it. EIGRP links carry no cost — the composite metric describes a whole path, not a single hop — so they are deliberately never used for shortest-path calculation: use the observed path view, which follows the routers' own forwarding decisions. In the RIB view the router's observed EIGRP routes appear alongside everything else — D for internal routes, D EX for redistributed ones — and take part in the same administrative-distance selection (90/170 by default, configurable under Admin › Settings); the metric shown is the feasible distance the router itself computed. Because EIGRP has no areas, the sidebar files an instance under a single row simply named Topology. On link details and hover cards, though, each EIGRP entry identifies itself by what actually distinguishes it: AS number and address family — AS 100 (v4) — so a link carrying several EIGRP autonomous systems dual-stack shows four distinct entries rather than four identical "Topology" rows. And where an EIGRP adjacency shares a wire with an IS-IS or OSPF link, the canvas draws one merged link with a tab per protocol, exactly like the other multi-protocol merges.

1. Open the Tunnel Quick-Add dialog by either:
   • Hovering over a Protocol Instance in the sidebar, clicking +, and selecting Add Area.
   • Hovering over an existing Area, clicking +, and selecting Add Recorder (SNMP) (pre-selects SNMP mode).
2. Select SNMP as the discovery mode.
3. Enter the Target IP (the router's management IP address).
4. Select a Credential Profile (the dropdown appears when profiles exist; the profile dictates both the SNMP version and the credentials), or pick the SNMP version and enter inline credentials:
   • v2c: Community string (e.g., public)
   • v3: Username, auth protocol (MD5/SHA), auth password, privacy protocol (DES/AES), privacy password
5. Optionally configure:
   • Poll Interval: How often to poll (in seconds).
   • Crawl ABRs/L1L2: Enable BFS crawl to automatically discover IGP neighbors and build the full topology from a single seed device. For IS-IS, a single seed discovers every L1 area of the domain — not just the seed's own — by crawling one reachable L1L2 ABR per remaining area.
6. If creating a new area, enter the area ID. (No area type is asked here — SNMP discovery forms no adjacency, so the area type does not affect it.)
7. Click Create.

Tip: Credential Profiles let you save named SNMP credential templates for reuse across multiple collectors and SNMP targets. Create them under Admin > Monitoring > Credential Profiles.

Collector Status

Each collector shows a colored status dot next to its area in the sidebar:

• Green (running): Actively discovering topology and receiving data.
• Blue pulsing (discovering): SNMP collector is actively crawling/discovering neighbors.
• Yellow pulsing (starting): Initializing GRE tunnel or SNMP session.
• Gray pulsing (pending): Configuration saved but not yet picked up by the collector-manager.
• Gray solid (stopped): Disabled by user.
• Red (error): Failed -- hover over the status dot to see the collector name and status. Click the area to expand and view the full error message.

Hover over an area with a collector to reveal action icons:

• Edit (pencil icon): Modify the collector configuration. Changes increment the config version, causing the collector-manager to automatically restart the collector with the new settings.
• Toggle (pause/play icon): Enable or disable the collector. The collector-manager handles start/stop within 10 seconds.

Tip: When multiple collectors exist on the same area (e.g., both GRE and SNMP), each shows its own status dot. Click the area to expand and see details for each collector individually.

SNMP Traffic Monitoring

Separately from topology discovery, Osprey polls device interfaces for traffic statistics (utilization, errors, discards). This is handled by the SNMP Poller service, which is independent of the topology collectors.

Set up SNMP targets under Admin > Monitoring > SNMP Targets:

1. Click Add Target.
2. Enter the device management IP and SNMP credentials (or select a credential profile).
3. The SNMP poller begins collecting interface counters at the configured interval (default 5 minutes, configurable in Admin > System Settings > SNMP).

Targets that fail 10 consecutive polls are automatically disabled to prevent wasted resources. You can re-enable them manually after fixing the underlying issue.

Pausing the SNMP Poller: The SNMP Targets manager has a Stop/Start SNMP Poller button that pauses all regular SNMP polling (discovery + counters) across all targets. When paused, zero SNMP traffic is generated -- useful for maintenance windows or troubleshooting. On-demand boost mode (clicking a link for live traffic) still works while the poller is paused. Click the button again to resume normal polling.

Traffic data enables:

• Utilization coloring on the topology canvas (View > Color > By Utilization)
• Link Detail Panel traffic charts (with automatic 5-second boost polling while the panel is open)
• Congestion alerts (80% warning, 95% critical -- seeded by default)
• Top Utilized Links card on the dashboard
• Congestion Trend diagnostic report (Reports > Diagnostics > Congestion Trend)
• MTU mismatch detection (Reports > Diagnostics > MTU Mismatch) — detects interface MTU mismatches across link endpoints via SNMP IF-MIB

L2 Neighbor Discovery (LLDP/CDP)

Osprey discovers Layer 2 adjacencies via SNMP walks of the LLDP-MIB (IEEE 802.1AB) and CDP-MIB tables. This runs automatically alongside IGP topology discovery (OSPF or IS-IS) when enabled.

How it works:

• The SNMP poller walks LLDP-MIB on each target device. If LLDP data is unavailable (e.g., older IOS devices), it falls back to CDP-MIB per device.
• Discovered L2 neighbors are stored with chassis ID, port ID, system name, management addresses, and platform description.
• LLDP and CDP capability bitmaps are normalized to a unified scheme (bridge=0x04, router=0x10). Only neighbors with bridge and/or router capability are stored; endpoints without these capabilities are excluded.
• Platform-based filtering automatically excludes wireless access points (Cisco AIR-/Aironet/C91xx, Aruba, Meraki, Ubiquiti, Ruckus) and Cisco UCS Fabric Interconnects (identified by "U: Uplink" / "S: Server" port descriptions) even when they advertise bridge capability.
• UTF-8 sanitization strips NUL bytes and invalid sequences from SNMP string values.
• Stale neighbors (not seen within the configured expiry window) are automatically cleaned up.

Configuration:

L2 discovery is configured per network in the network's Enrichment panel (and via the tri-state toggles in the network edit form -- see Per-Network L2 Configuration below):

Setting	Default	Description
L2 Enrichment	off	Master toggle for LLDP/CDP neighbor discovery on monitored routers
Switch Crawling	off	BFS crawl to discover neighboring switches via LLDP/CDP. Phones, APs, and endpoints are excluded.
Crawl Interval (minutes)	360	How often the L2 crawler runs (6 hours)
Max Crawl Depth	3	Maximum BFS hop depth from nearest OSPF router seed
Neighbor Expiry (hours)	72	Hours before unseen neighbors are pruned (3 days)

Operations (admin): the Enrichment panel's Advanced section has an L2 crawler row to run an immediate crawl cycle or reset the network's discovered-neighbor queue.

Device identity resolution:

Osprey automatically resolves L2 neighbors to existing devices in the topology using a 5-tier cascade:

1. Chassis ID -- matches the remote chassis ID against device.chassis_id (collected via lldpLocChassisId)
2. SNMP target management IP -- matches the remote management IP against configured SNMP targets
3. Router ID -- matches the remote management IP against device router IDs
4. Interface IP -- matches the remote management IP against known interface IPs
5. Hostname -- case-insensitive match of the remote system name against device hostnames

Resolution runs at poll time (per-device) and via a background sweep every 5 minutes.

Interpreting L2 links -- physical vs. dot1Q subinterface:

L2 links reflect the LLDP/CDP control plane (which physical ports share a cable), not the forwarding/VLAN plane. When a physical port carries a dot1Q subinterface -- e.g. two OSPF adjacencies over one wire: the backbone on Et0/1 and a VLAN-100 area on Et0/1.100 -- the device advertises LLDP for both the physical port and the subinterface, so LLDP reports two neighbor rows on one cable: physical (Et0/1 -> Et0/1) and subinterface (Et0/1 -> Et0/1.100). This is expected device behavior, not a fault.

Osprey collapses these onto the physical link for display -- on the canvas (an L2 edge that is the same cable as an L3 adjacency is suppressed, subinterface-insensitively) and in the node drawer's L2 Neighbors list (a physical link and its subinterface advertisements show as one row, keeping the richer lldp+cdp row). The raw rows are kept in the database.

An Et0/1 <-> Et0/1.100 entry is not a data-plane cross-connect: the tagged (VLAN) and untagged traffic stay in separate broadcast domains, and the OSPF/IS-IS area view is the source of truth for L3 separation -- the L2 entry is only a control-plane artifact of LLDP being processed per physical port. To remove it at the source, disable LLDP on the subinterface (no lldp transmit / no lldp receive on the dot1Q sub-interface); OSPF/IS-IS on that subinterface is unaffected.

L2 canvas overlay:

When L2 data is available, click the L2 toggle button in the toolbar to display Layer 2 switches and links on the canvas alongside the IGP topology. See L2 Topology Overlay below.

Note: L2 neighbor discovery requires SNMP targets to be configured. It runs during the regular SNMP discovery interval (default 6 hours).

L2 Topology Overlay

The L2 toggle button in the toolbar renders discovered switches and L2 adjacencies on the Cytoscape canvas as an overlay alongside the L3 IGP topology (OSPF or IS-IS).

What it shows:

• L2 switches appear as dashed-border nodes, positioned near their connected L3 routers.
• L2 links appear as dashed gray edges between switches and between switches and routers.
• Router-to-router L2 edges are suppressed -- only edges to L2-only devices are shown (avoids duplicating the existing OSPF links).

Interaction:

• Click an L2 edge to open the L2 Link Detail Panel, showing LLDP/CDP adjacency details, capabilities, and protocol.
• Right-click context menu guards prevent actions that do not apply to L2-only devices (RIB, SSH, SPF tree).
• L2 topology auto-refreshes via WebSocket when changes are detected.

Per-Network L2 Configuration

Each network can override the global L2 discovery settings. This is useful when different networks require different SNMP credentials, or when you want L2 discovery enabled for some networks but not others.

Configuring per-network overrides:

1. In the sidebar, click on a network name to expand it, then click the pencil icon to edit.
2. Below the name and description fields, the L2 Configuration section appears (admin only).
3. Each toggle uses a tri-state cycle: click to cycle through ON, OFF, and Default:
   • ON (green) -- explicitly enabled for this network, regardless of the global setting.
   • OFF (red) -- explicitly disabled for this network, regardless of the global setting.
   • Default (gray) -- inherits from the global system setting. Shows "Default (on)" or "Default (off)" to indicate the effective value.

Available per-network overrides:

Setting	Description
LLDP/CDP Enrichment	Override the global L2 enrichment toggle for this network
Switch Crawling	Override the global switch crawl toggle for this network
Primary Credential	SNMP credential profile for L2 crawling in this network (overrides the global default)
Fallback Credential	Fallback credential profile for this network (overrides the global fallback)

The credential profile selectors appear only when credential profiles have been created (see Admin > SNMP Credential Profiles). When set to "Global default", the network uses whatever profile is configured in the global SNMP settings.

Precedence: Per-network settings always take priority over global system settings. When a per-network toggle is set to Default (null), the SNMP poller falls back to the global l2.enrichment_enabled and l2.crawl_enabled system settings.

L2 data management:

Right-click a network in the sidebar for data management options:

• Reset L2 Data -- deletes all L2 neighbor and discovered neighbor data for the network. Useful after credential changes or when L2 data has become stale.
• Reset Crawler Queue -- clears pending crawl targets for the network without affecting existing L2 neighbor data.

Multi-Protocol Devices

The same physical device can run both OSPF and IS-IS simultaneously. Osprey automatically correlates devices across protocols using TE Router ID (IS-IS TLV 134) and SNMP sysName matching. Each protocol is managed under its own protocol instance in the sidebar.

The canvas currently shows one protocol instance at a time -- select the desired OSPF process or IS-IS instance in the sidebar. Multi-protocol overlay (viewing OSPF and IS-IS topology simultaneously) is planned for a future release.

IS-IS Event Types

IS-IS topology changes generate events similar to OSPF but with IS-IS-specific types:

• LSP Update: An IS-IS Link State PDU was updated (analogous to OSPF LSA Update).
• LSP Purge: An LSP was purged from the LSDB (analogous to LSA MaxAge).
• IS-IS Adjacency Change: An IS-IS adjacency transitioned state (up/down).
• DIS Change: The Designated Intermediate System changed on a broadcast segment (analogous to OSPF DR Change).

These events appear in the Activity Tray, event history, and incident correlation alongside OSPF events.

Setting Up BGP Monitoring (BMP)

Osprey receives BGP routing data via BMP (BGP Monitoring Protocol, RFC 7854). Your routers push BMP messages to Osprey's BMP server -- no polling required. This gives you visibility into BGP peers, the RIB (best-path table), and AS path analysis.

Prerequisites:

• The network hierarchy (Network, AS, Routing Domain) must already exist -- see above.
• Your router must support BMP and be configured to send BMP to Osprey's IP on port 11019 (TCP).

Step 1 -- Configure BMP on the router:

On Cisco IOS-XR:

bmp server 1
 host 198.51.100.10 port 11019
 flapping-delay 60
!
router bgp 65000
 bmp server 1
  route-monitoring policy post inbound

On Arista EOS:

router bgp 65000
 neighbor 10.1.0.1
  bmp activate
!
management api bmp
 host 198.51.100.10 port 11019

Step 2 -- Create a BMP target in Osprey:

First, create a BGP protocol instance in the sidebar:

1. Hover over a network and click + > Add Protocol.
2. Select BGP as the protocol.
3. Click Create.

Then add a BMP target:

1. Expand the BGP protocol instance in the sidebar.
2. Click the + icon and select Add Target.
3. Enter a name, the router's management IP, and select a RIB mode:
   • loc_rib -- Best paths as computed by the router itself (most common)
   • adj_rib_in_post -- All paths received from all peers (post-policy)
   • none -- Accept BMP session but skip RIB processing
4. Click Create.

BMP targets can also be managed via the REST API:

• Create: POST /api/v1/bgp/targets
• List targets: GET /api/v1/bgp/targets?pi_id=...
• Update: PUT /api/v1/bgp/targets/{id}
• Toggle enable/disable: PUT /api/v1/bgp/targets/{id}/toggle
• Delete: DELETE /api/v1/bgp/targets/{id}

Step 3 -- Verify connectivity:

The target's status indicator in the sidebar changes:

• Pending (grey) -- Waiting for the router to connect
• Connected (green) -- BMP session established, receiving data
• Error (red) -- Connection failed (check router config, firewall, port 11019)

Once connected, BGP peers appear within seconds. Routes populate as the initial RIB dump completes (End-of-RIB marker). Right-click a BMP target in the sidebar to view its peers or routes directly.

Step 4 -- View BGP data:

• BGP Peers: Reports > Routing > BGP Peers (or right-click a BMP target > View Peers)
• BGP Routes: Reports > Routing > BGP Routes (or right-click a BMP target > View Routes)
• Live updates: Peer state changes (up/down) and route count changes are pushed to the browser via WebSocket -- no page refresh needed.

Tip: For route reflector deployments, configure BMP on the RR. The RR's Loc-RIB reflects all client routes, giving full AS-wide visibility from a single BMP session.

EVPN Visibility (automatic)

If your fabric runs EVPN (RFC 7432 -- EVPN-VXLAN or MPLS-based E-LAN / EVPN-VPWS), Osprey picks it up from the same BMP feed with no extra Osprey configuration: the moment BMP messages carry the EVPN address family (AFI 25 / SAFI 70), EVPN instances are discovered and a Reports > Routing > EVPN entry appears automatically.

The only requirement is on the router side: the BMP-exporting router must actually carry the EVPN routes. Make sure the EVPN address family is active on the sessions BMP monitors -- typically a route reflector that participates in the EVPN mesh. On a router that should see all EVPN routes regardless of its own route-target imports (a dedicated monitoring peer), disable RT filtering (e.g. no bgp default route-target filter on IOS-XE).

Each BMP target has an EVPN route budget (max_evpn_routes, API-configurable per target). If a target exceeds it, additional routes are dropped (withdrawals still process) and the EVPN panel shows the instance data as truncated -- never silently incomplete.

MPLS Discovery (TE Tunnels, L3VPNs & L2VPN Pseudowires)

Osprey discovers MPLS state from the routers over SNMP, inside the normal poll cycle — no extra service and no router configuration beyond SNMP access:

• MPLS-TE tunnels (RFC 3812, MPLS-TE-STD-MIB): every tunnel with its role (head / transit / tail), admin/oper status, and signalling protocol.
• L3VPNs (RFC 4364 / RFC 4382, MPLS-L3VPN-STD-MIB): per-PE VRFs with their route-targets, rolled up server-side into L3VPNs (a route-target equivalence class), classified full-mesh or hub-and-spoke with per-site hub/spoke roles.
• L2VPN pseudowires (RFC 3985 / RFC 5601, PW-STD-MIB — with automatic fallback to the pre-standard CISCO-IETF-PW-MIB that IOS/IOS-XE actually implement): every pseudowire with its peer, attachment-circuit name, and per-end status, rolled up server-side into VPWS wires (point-to-point, both ends mutually paired) and VPLS instances (multipoint, classified from mesh evidence — never guessed).

Discovery mode — the MPLS Discovery card in the network's Enrichment panel (open it from the network row in the sidebar) controls both:

Mode	Behavior
Auto (default)	A cheap capability probe runs on every SNMP target; only devices that actually answer the MPLS MIBs are walked
On	Every SNMP target is walked, probe result ignored
Off	MPLS discovery disabled for this network

Viewing the results:

• Reports > Routing > MPLS-TE Tunnels — appears only on networks with discovered tunnels. Clicking a tunnel lifts an abstract arc from headend to tailend on the canvas (marching ants when up, broken red dash when down). The arc is an overlay plane above the physical links — it does not claim to trace the hop-by-hop path.
• Reports > Routing > L3VPNs — appears only on networks with discovered VRFs. Clicking an L3VPN highlights its PE sites and draws membership edges (a full interconnect for mesh, a star from the hub for hub-spoke). The edges show control-plane VPN membership (who shares the VPN, from route-targets), not the data path — the traffic rides the core LSPs.
• Reports > Routing > VPWS Wires — appears only on networks with discovered point-to-point pseudowires. Each wire lists its two endpoint PEs, VC ID, per-end status and a signalling chip (LDP / static / EVPN). Clicking a wire draws its endpoint arc on the canvas. A wire whose far end Osprey cannot see (the peer PE is outside SNMP reach) is honestly flagged half-wire with the off-view peer address — it is listed, never drawn as if both ends were known.
• Reports > Routing > VPLS Instances — appears only on networks with discovered multipoint L2VPNs. Each instance lists its member PEs with a mesh-completeness badge (full / partial / membership unknown); clicking draws membership edges between the member PEs, the same visual grammar as L3VPNs.

A tunnel reroute/drop, a VRF going down, or a pseudowire going down feeds incident correlation as a symptom attached to the co-incident link/PE failure — never as a root cause. A pseudowire symptom carries both endpoint routers, so it attaches to an incident at either end of the wire.

Notes: All overlays are live-only (hidden in time travel). Per-VRF route counts require the agent's VRF performance table, which some virtual images (e.g. Cisco IOL) omit — those L3VPNs list their sites without a route total. A pseudowire arc asserts the wire's endpoints and status, nothing about which core links carry it — the PSN path is not traced.