Your CMDB is a hypothesis. The diagram is a year stale, the spreadsheet disagrees with it before lunch, and a change nobody logged is in production right now. CrossConnect reads the gear read-only and keeps a live source of truth in Postgres, current with what is actually on the wire. Engineer to engineer: here is exactly how it collects, tracks what changes, and proves what it shows you.
flowchart LR NET["Your network
switches, routers, firewalls"] -->|reads it, changes nothing| CC["CrossConnect"] CC --> MAP["A live map you can trust
kept current on its own"] MAP --> ASK["You ask, in plain English"] ASK --> ANS["A clear answer
with the record to prove it"] classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff; classDef good fill:#1797b3,stroke:#0d7d90,color:#ffffff; classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b; class CC app; class MAP good; class NET,ASK,ANS ext;
The Visio is two years stale, the spreadsheet was wrong before lunch, and an out-of-band change is sitting in production right now with no ticket behind it. When something breaks you burn an afternoon guessing, and when an auditor asks what is connected to what, you sweat. CrossConnect keeps a live model of the real network by reading the gear itself, on the schedule you set, so the answer is already there, current, with the record behind it.
No agents on your devices and no config changes. CrossConnect reads the gear the same way you would from a jump box, on the protocols the gear already speaks, with short timeouts so a slow or dead host never stalls a run. Point it at a seed range or a list, give it read-only credentials, and it walks the network from neighbor to neighbor.
Want the full per-protocol breakdown of every OID and field? It is in the Data Collection Reference.
From what the switches report, CrossConnect assembles the full Layer 2 and Layer 3 topology and refreshes it on every run. No Visio to maintain, no diagram going stale the week you saved it. Follow any connection from a port through the cabling, and find any device by address in a single lookup.
L2 adjacencies from LLDP, CDP, and FDP, L3 from the routing it reads, redrawn on every run. The map is never the stale one from last quarter.
L2 + L3, currentTrace a connection the whole way: from a switch port, through the cabling, out to the carrier handoff. The path is read from the gear, not redrawn by hand.
port to carrierType a MAC or an IP and land on the exact switch and port it plugs into, learned from the switches themselves, with what it is and whether it quietly moved ports.
MAC / IP → portDefine a golden config for a role, an NTP block, an SNMP ACL, an AAA stanza, and CrossConnect diffs every device against it on each run. Drift surfaces the moment it appears: a missing time-sync line, a relabeled interface, a new local account, a config that changed since yesterday with no ticket behind it. You get the line, the device, and the minute it landed.
CrossConnect snapshots config and reachability over time. When a path breaks, instead of guessing from symptoms it computes reachability formally across the relevant config snapshots, isolates the exact stanza whose change altered the forwarding outcome, and shows you the before and after as the proof. This is config-delta analysis on a forwarding model, not a ping in a loop.
AV-EGRESS now drops the flow.ip access-list extended AV-EGRESS
permit ip any any
!
interface Gi0/1
ip access-group AV-EGRESS out
ip access-list extended AV-EGRESS
deny udp any 10.10.20.0 0.0.0.255 eq 4440
permit ip any any
!
interface Gi0/1
ip access-group AV-EGRESS out
Formal reachability covers the vendors with full config models; everything else falls back to config-level and cloud analysis. The exact maturity per vendor is in the Vendor Support Reference.
The conversational layer queries the same live source of truth you do. Every answer cites the records behind it. If the data cannot support a claim, it says so instead of inventing a device, an address, or an adjacency. It honors the asker's role, logs every prompt and retrieved record, and it advises only: it will point at the offending stanza and hand you the command, but it never touches a device.
One Java service and a PostgreSQL system of record, on-prem or in your own cloud account. Scale out to multiple replicas behind a load balancer when you need availability. Nothing leaves your network except the egress paths you switch on yourself.
Spring Boot service plus PostgreSQL as the system of record. Docker for a single-node install, multi-replica for HA. Your data stays in your account.
on-prem · your cloudEach network listener, its bind, and its default is documented, alongside the full runtime service surface. No mystery ports. Read the Services & Listeners Reference.
no mystery portsCapacity and throughput numbers for a planned deployment, with the measured methodology behind them. See Performance & Capacity Planning.
measured, not modeledPush the facts it finds, drift, and alerts to your ticketing and ops tooling, each payload HMAC-signed so the receiver can verify it.
signed payloadsEvery claim on this page has a document behind it, written in protocol and port. Lift the answers straight into your evaluation.
Bring the network that keeps you guessing. We will run CrossConnect against one like it, read-only, and show you the live map, the drift, and the change nobody logged. Walk out with a source of truth that matches the wire, so the next time someone asks what is really connected to what, the answer is already on your screen with the record behind it. It is in operator preview: young, but everything here is built and running against a real network today.