Vendor Support Reference

0 How to read this document

CrossConnect treats a device by what it can actually do with that device’s configuration, not by brand loyalty. Three things decide the treatment: how we get the configuration (SSH, a cloud API, or SNMP), what can parse it (a formal model, our own parser, or none), and therefore what analysis we can offer. Every vendor below is labelled with its maturity so nothing is oversold.

The single source of truth for a vendor’s treatment is the VendorSupport capability matrix in the code: for each vendor it records how config is captured (SSH, CLOUD_API, or UNSUPPORTED), whether the formal engine can model it (SUPPORTED / UNSUPPORTED), and an operator-facing note when support is limited. This document spells that matrix out.

1 The four ways we treat a vendor

A vendor falls into one of four tiers. The tier sets what analysis is possible, and the code decides it, not a sales sheet.

Two cross-cutting layers sit alongside these tiers and apply to every vendor: SNMP (§7) gives interfaces, VLANs, neighbors, multicast, timing, and sensors regardless of brand, and the AV endpoint layer (§8) types audio-visual gear that often speaks neither SSH nor SNMP.

flowchart LR
  DEV["A device
(vendor identified)"] --> ACQ{"How is its
config reachable?"}
  ACQ -- "SSH running-config" --> FORMAL{"Can the formal
model parse it?"}
  ACQ -- "cloud API" --> CLOUD["Cloud-managed
REST pull · own parser"]
  ACQ -- "SSH, no parser" --> CAP["Capture-only
store · search · diff · drift"]
  FORMAL -- "yes" --> BF["Formally analyzed
Batfish: reachability · ACL · Black Box"]
  FORMAL -- "no" --> CFG["Config-level
our parser + SNMP facts"]
  SNMP["SNMP, every vendor
interfaces · VLANs · LLDP · multicast · sensors"] -.-> DEV
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef gate fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  class BF,CFG,CLOUD,CAP app;
  class ACQ,FORMAL gate;
  class SNMP store;
  class DEV ext;
  

2 How we acquire configuration

Every acquisition path is read-only. We never push configuration to a device. There are four ways data comes in.

The SSH path is the one that varies by vendor: each vendor needs a different paging-disable and a different show command, and the captured text needs to be tagged with its format so the right parser is selected. That per-vendor profile is the VendorCliProfile, listed in full in Appendix A.

3 Formally analyzed vendors Production

For six vendor families we capture the running-config over SSH and parse it with the Batfish formal model. Batfish turns each vendor’s configuration into one vendor-independent model of how the network forwards and filters traffic. From that model we can prove a path, validate an access rule across vendors, and trace the exact change that broke something. Each config is tagged with its vendor format before it enters the model so the correct grammar is used.

4 Config-level vendors (our own parsers) Built, wiring expanding

Some vendors the formal model does not parse, but their configuration is still worth reading. Rather than wait for a formal grammar (which can take many months), we wrote small, focused parsers that pull the facts that matter for segmentation, multicast, and hardening. These devices are modeled as Layer-2 bridges or opaque Layer-3 hops inside the topology; cross-device reachability proofs still run on the formally analyzed core.

The VendorSupport matrix ships and classifies these vendors today, and the parsers above are written and unit-tested. What remains is surfacing each parser’s output into every analyzer view, which is why this section is marked built, wiring expanding rather than fully production.

5 Cloud-managed vendors

Cloud-managed gear keeps its configuration in a vendor cloud, so there is no SSH running-config to capture. CrossConnect pulls the configuration over the vendor’s REST API instead, with an encrypted API key, and analyzes it at the config level (the same segmentation and access-rule intent checks, no formal reachability).

Both follow the same shape. The API client and the JSON parser are built for each: MerakiJson for the Meraki Dashboard, and UniFiJson for the UniFi controller (it parses the controller’s networks and firewall rules into the same fact types). For both, the configuration gate and the wiring of those facts into the analyzer views are being completed.

6 Capture-only & unrecognized vendors Production

Anything we can reach over SSH but cannot parse is still useful as text. We capture the running-config, store it, let you search and diff it, and check it for drift against an approved baseline. We just do not claim a model-based analysis we cannot back up.

• Extreme (EXOS) is the named capture-only vendor: config is captured, stored, searched, diffed, and drift-checked, with no formal or config-level parsing.
• Any unrecognized vendor is treated as SSH best-effort: we attempt a capture, but we do not assert formal analysis, config grading, or hardening until that vendor is properly supported. The operator-facing note says so plainly.

7 SNMP, across every vendor Production

SNMP is the one path that works the same way on every brand, and it runs by default. It reads standard MIBs (the structured data tables a device exposes) for the facts that do not need a config parser, plus a few vendor-specific tables where the standard ones fall short.

Where a standard MIB is not enough, we read a vendor-specific one: for example the Cisco PTP extensions when a device does not populate the standard PTP table, and a Netgear-private power table for PoE budget on FASTPATH switches. The enterprise number in a device’s system identity is also how we recognize cloud-managed gear (for example Meraki) before any API is connected.

8 AV endpoint vendors

Audio-visual gear, codecs, displays, cameras, microphones, signal processors, often speaks neither SSH nor SNMP. CrossConnect types it from the signals it does give off, and for some roles can poll the device’s own management port to confirm it is live. The vendor matters here in two ways: the MAC-address vendor (OUI) is a strong hint at what a device is, and the management protocol is vendor-family specific.

Vendor identity to role

AvOuiProfile maps a MAC-address vendor to a likely AV role. AV-only vendors (Audinate/Dante, Shure, Crestron, AMX, Poly, Biamp, QSC, Barco, NEC, Axis, and others) are a strong vote on their own. Multi-market vendors (Cisco, Sony, Panasonic, Apple, Microsoft) only count as a vote when a second signal agrees, so an Apple device is not called a display until something like an AirPlay announcement corroborates it.

Live management-port probes

Where a role has a standard management protocol, a probe confirms the device is real and reports its state, live first, falling back to the classified record when a probe is not available or not enabled.

The classifier also fuses passive signals: mDNS service types (_dante, _qsys, _airplay), LLDP model strings, DHCP fingerprints, and observed media flows (Dante, AES67, NDI, Q-SYS). The camera probe is part of the experimental Peek-a-Boo preview and is off by default (crossconnect.peekaboo.probe-enabled=false) until camera credentials are supplied; the display and DSP probes are part of the shipped AV endpoint modules. Full detail is in the AV sections of the Capability Guide and the Experimental Features explainer.

flowchart LR
  subgraph SIG["Signals (passive)"]
    direction TB
    OUI["MAC vendor (OUI)"]
    MDNS["mDNS service type"]
    LLDP["LLDP model string"]
    FLOW["AV media flow"]
  end
  CLS{"AV classifier
role + confidence"}
  SIG --> CLS
  CLS --> DISP(["Display, PJLink probe"])
  CLS --> DSP(["DSP, Q-SYS probe"])
  CLS --> COD(["Codec, SIP probe"])
  CLS --> CAM(["Camera, ONVIF probe
experimental, dormant"])
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  classDef gate fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  class OUI,MDNS,LLDP,FLOW store;
  class CLS gate;
  class DISP,DSP app;
  class COD,CAM ext;
  

9 Occupancy & wireless vendors Production

For room occupancy and wireless health, CrossConnect integrates with the wireless vendor’s cloud, with an encrypted API token, and reads placement and client-count telemetry. This feeds occupancy analytics, not network-core modeling.

10 What ships today vs what is expanding

Because customers ask exactly this, here is the honest split. Nothing below is a future promise dressed as a present feature.

A Appendix, SSH command profile per vendor

The per-vendor SSH profile (VendorCliProfile) sets the paging-disable command and the read-only show command CrossConnect runs to capture a running-config. All commands are read-only; no configuration command is ever issued.

Vendors without a dedicated profile (for example Netgear, Ubiquiti EdgeSwitch, Extreme) are captured with a best-effort show command and routed to the parser or capture-only handling described above.

B Appendix, vendor capability matrix

The shipping VendorSupport catalog, ordered most-capable first. Capture is how config is obtained; Formal is whether the Batfish model can parse it.