This is everything CrossConnect does, grouped the same way as the menu inside the product. Each item is described for someone seeing it for the first time, so you can find a screen in the app and read what it is for here.
Home is the landing page you see when you first open CrossConnect, and you can return to it any time by clicking the logo. It gives a short plain summary of what the product is and what it does, then points you toward common first tasks. A set of quick start cards links you straight into the main areas, so you do not have to hunt through the menu to get going.
For example · A welcome banner with start cards for the walkthrough, hotspots, devices, discovery, AV equipment, and compliance.
Hotspots is a single ranked list that answers the question of what you should deal with first. It pulls together every risk the platform has spotted across your network, such as hardware or software that is reaching end of life, settings that have drifted from what was intended, known security vulnerabilities, address space or capacity getting close to full, devices that are down, and changes made without a ticket. Each item is sorted by how serious it is, so the most urgent problems sit at the top. When you open a hotspot, a panel called What changed traces the affected device through the recorded history and tells you whether the issue likely came from a recent change or from an environmental cause, and it flags when a change was made without an approving ticket.
For example · The list opens with a critical row reading 'Device down: acc-stuA-12' above a medium row reading 'IP space 10.10.0.0/24 at 78 percent'.
Health shows whether each device can be reached on the network and reports readings from its built-in environmental sensors, such as temperature, fan status, and power supply status. Devices that are having a problem are brought to the top so you do not have to scan a long list to find them. You use this page for a quick daily check on whether anything is overheating, has lost power, or has dropped off the network.
For example · Highlights one switch running hot at 68 degrees Celsius and one device that is not responding.
Changes is a running feed of recent edits made to your records, so you can see what was touched and when across your equipment. It helps you catch up after time away, confirm an update went in, or trace back when something started behaving differently. Each entry notes what kind of record was changed and the time it happened.
For example · Lists the last 50 record edits, each showing what was changed and when.
Network map plots your physical sites on a geographic map, with each location showing how many devices it holds. You can click a site to drill into the equipment at that location. It gives you an at-a-glance picture of where your gear is in the world and how it is distributed across offices and buildings.
For example · Pins three sites: headquarters in Boston, Studio A in New York, and Studio B in Los Angeles.
Topology draws an interactive diagram of how your devices physically connect to each other, built automatically from the neighbor information the devices share with one another (using common protocols called LLDP and CDP). It lays out the network by layer, from access switches that connect end devices up to the core, so you can see the path traffic takes and where backup links exist. You use it to understand how the network fits together and to spot single points of failure.
For example · Shows access switches connecting up to distribution and core, with a redundant backup ring highlighted.
AV overview is the front door for your media network. It gives one readiness score for the AV protocols you run, Dante, AES67, SMPTE ST 2110, NDI and Q-SYS, and shows what is strong, what is weak, and what to fix first. It surfaces the clock, the recent changes that can move that readiness, and a flow map of every stream.
For example · A readiness score with a split-clock warning and a count of switches missing IGMP snooping.
AV devices gives a health card for every audio and video endpoint: the firmware it runs, its clock role, how much flow headroom it has left, and any known security holes, sickest first.
For example · A Q-SYS core shown with its clock role and a flow-budget chip, flagged because it is near its limit.
AV assurance checks the things that take rooms down and proves the things you promised. It confirms whether the audio, video and control lanes are really kept separate, whether each stream is reaching a listener instead of flooding, and whether the clock is healthy.
For example · A segmentation check that compares how a VLAN was set up against what its traffic is actually doing.
QoS reads what your switches' configs actually say about protecting time-sensitive traffic, and tells you whether the AV, voice and PTP that depend on it are safe: priority queues bounded, a trust boundary set, the AV-bearing devices actually policed. Every failing finding carries the fix in that device's own syntax.
For example · 'One device has no QoS policy', opening to the exact switch and the command for its platform.
Multicast is one place to see whether the multicast your AV rides on is healthy: the groups and who sends and listens, IGMP snooping and a querier on each VLAN, routing for cross-subnet, and which streams are flooding because nobody joined. When something is off it names the exact switches and gives the fix.
For example · '47 of 65 switches pass IGMP snooping', with the 18 that fail listed by name.
The camera view surveys your security and AV camera fleet over open standards and watches for trouble: cameras that have gone dark, lost their stream, or been quietly swapped for unknown hardware. It identifies each one and never stores a single frame.
For example · A fleet list flagging a PTZ with no stream for six minutes and a dock camera whose hardware was swapped.
Space occupancy turns the Wi-Fi you already run into a live read on how full a room or area actually is, by counting the devices associated to its access points. No new sensors to install.
For example · 'Studio A, 18 of 40 seats in use', read from Wi-Fi association counts.
This is the home page for your equipment inventory. It lists every device you manage, such as switches, routers, and wireless access points, and shows each one's vendor, hardware model, location, software version, role, and current status. You can filter the list to narrow it down to exactly the devices you care about. Most day to day work starts here.
For example · Filter the list to show only the active Cisco access switches in Studio A.
This is a view of just your audio and video gear, pulled out automatically from the full device list based on the maker of each device, such as Crestron, Q-SYS, Extron, Biamp, or Shure. You do not enter any extra information to get it. It includes summary cards (total units, number of vendors, number of sites, how many have a known security issue, and how many are down) along with charts that break the gear down by vendor and by site, plus a grid you can browse.
For example · See 12 AV devices spread across 4 vendors and 3 sites, with charts showing how many sit at each site and 2 flagged as having a known security issue.
This is a timeline for a single device that shows everything that has happened to it over time. It draws from the change record, so you can see what changed, when it changed, and who made the change. It also shows where the device is now and the full trail of any location and rack moves it has been through.
For example · For one access switch you can see it was moved from the Studio A site to the HQ site, reclassified as a core device, and had a note added.
This page tracks your virtual machines and the physical host servers they run on, grouped into clusters. A cluster is a pool of host servers, and each virtual machine is treated as a full host with its own processor count, memory, disk, main IP address, and network connections. If you delete a cluster, its virtual machines are detached rather than deleted, so you do not lose their records.
For example · A VMware cluster running 18 virtual machines, where vm-app-01 has 4 virtual processors, 8 GB of memory, a 120 GB disk, and an address of 10.0.5.20 on VLAN 50.
This page records the software services running on your devices and virtual machines, including each service's name, the protocol it uses, and the network ports it listens on. It gives you a clear answer to the question of what is open on a given host. That information feeds into your security picture alongside known vulnerabilities and hardening checks.
For example · For a Q-SYS core, a 'web admin' service on TCP ports 443 and 8443, and a 'Dante control' service on UDP ports 4440 through 4455.
This is your list of hardware makers, each with its logo. Vendors are the companies that build your equipment, and every device model in the catalog is tied back to one of them. It gives you a single place to manage the brands you buy from.
For example · Vendors such as Cisco, Meraki, Extreme, and Netgear.
This is the catalog of specific hardware models you use. Each model records how many rack units of height it takes up, where it sits in its product life cycle, and can include optional front and rear photos. When you add a real device, you pick its model from this list so its details are filled in consistently.
For example · A Catalyst 9300-48P model, 1 rack unit tall, listed as a PoE+ access switch.
This page lets you define device roles and software platforms and assign them to your equipment. A role describes the job a device does, such as core switch, access switch, or wireless access point, and a platform is the operating system it runs. Once assigned, you can filter and group your devices by either one.
For example · Tag the device cor-hq-01 with the role 'core' and the platform 'cisco-ios-xe'.
This is the catalog of the kinds of plug-in parts a chassis device can hold. A module is a removable component such as a line card (a card that adds more ports) or an SFP (a small plug-in transceiver for fiber or copper links). You define the types here before installing actual modules into devices.
For example · A 48-port line card type and a 10G SFP+ transceiver type.
This page manages the plug-in parts of your devices. It covers the bays (slots) on each device, the modules installed in them, storage media in the device, and a spares shelf for modules you own but have not installed yet. You can move a module from the shelf into a bay, or pull one out of a device back to spares, and it keeps its serial number throughout. Related views on the same route track spare modules and the passive parts inside a device such as power supplies and optics.
For example · Install a line card in bay 1, add a 16 GB boot drive, and keep a cold spare transceiver on the shelf.
This page lets you model a chassis that holds smaller whole devices, often called blades. You set up the chassis as a parent device, add its bays (slots), and place a child device into each bay. This is different from module bays, which hold cards rather than complete devices.
For example · The chassis blade-chassis-1 has its bay 3 holding the server blade-srv-07.
This page holds the physical layout that everything else attaches to, arranged as a hierarchy of sites, buildings, rooms, and rows. You set up where your places are so each device, rack, and circuit can be tied to a real spot. It is the backbone for knowing where things physically live.
For example · A path of HQ, then Studio A, then Row A.
This page shows rack elevations, meaning a front and rear picture of each equipment rack and which slots are filled. You can drag devices into place, see how full each rack is, and mount two half width devices side by side so they share a single rack unit. It gives you an accurate picture of what is mounted where.
For example · Place a 2 rack unit core switch at slot 40 on the front face, and pair two media converters left and right at slot 12.
This page tracks the electrical circuits that supply your racks, coming from a power strip or building panel. For each feed it records voltage, amperage, phase, whether it is AC or DC, its rated wattage, and a safe maximum load level, and it shows how much of that feed is currently in use. It works together with the rack power view so you can confirm that a rack has two independent feeds and would keep running on either one alone.
For example · Feed A is 208 volts at 30 amps three phase, set to an 80% safe limit and currently 62% loaded, and Rack 4 would keep running on either feed by itself.
This page maps how power flows from a device all the way back to its supply circuit. It records each device's power inputs and, for a power strip, its outlets, then connects them so you can trace draw from the device to the outlet to the feed. The total load on a feed is the sum of every connected device that traces back to it.
For example · Power supply 1 on vm-host-01 draws 450 watts, plugs into outlet 3 on a power strip, which connects through that strip's inlet to Feed A.
This page lists the carriers and internet service providers that deliver your network circuits. For each one you can record its network identifier (its ASN) and links to its customer portal. It gives you a tidy reference for who supplies your outside connections.
For example · Providers such as Lumen, Comcast, and Zayo.
Interfaces is the list of every network port across all your devices in one place. You can split a single physical port into several smaller virtual ports, and you can bond two or more ports together into one logical link (called a LAG or port-channel) for more bandwidth or backup, with each member port shown grouped under the bundle it belongs to. Customers use this to see and organize ports without logging into each device by hand.
For example · Split a 100G port into four 25G lanes, or bond ports Gi1/0/1 and Gi1/0/2 into a single Port-channel1.
Cables records the physical wires and fibers that connect your equipment, including the connector type at each end, the color, the length, and any label printed on the cable. The discovery feature can suggest most of these connections automatically so you do not have to enter them by hand. Customers use this to keep an accurate map of what is plugged into what.
For example · Record an LC to LC fiber cable running from a patch panel to a switch port.
Patch panels lets you document the passive panels used in structured cabling, the kind of panel that has ports on the front and matching ports on the rear but no electronics of its own. You record the front and rear ports so cabling that runs through the panel can be traced end to end. Customers use this to model the in-wall and in-rack cabling that ties rooms and racks together.
For example · Add a 24-port LC fiber panel located in Studio A.
Wireless is where you document the parts of your network that have no cable to record, namely Wi-Fi networks (the named SSIDs that devices join) and fixed point-to-point wireless links between locations. These links act like a cable through the air, so the regular cable model cannot hold them. Customers use this to keep wireless connections in the same inventory as everything else.
For example · Document a 5 GHz wireless bridge linking Studio A to Studio B.
Console access documents the out-of-band way to reach a device, meaning the back-door connection you use when the normal network is down. It records each device's console port and the console server port it connects to, linked together so you can trace exactly how to get to a device in an emergency. Customers use this to know how to log in and recover a switch even when it is unreachable over the network.
For example · The console port on switch acc-stuA-12 connects to terminal server termserv-1 on port 7.
Locate a device lets you type in a hardware address (MAC) or an IP and instantly see exactly which switch and port that device is plugged into, based on records the switches themselves report. It also pulls together a full profile in one view: what the device is doing on the network, whether it has recently moved ports, whether it is named in any security alert, and how to reach its switch out-of-band if the network is down. Customers use this when they need to physically find or troubleshoot a device without checking several different screens.
For example · Search a MAC address and see it is on switch acc-sw-1 port Gi1/0/3, VLAN 10, carrying audio traffic, stable on one port, with no threats.
Endpoint history is a record of every hardware address (MAC) the network has ever seen, including which switch and port it is on now, when it was first and last seen, and whether it has moved between ports. It also tells you whether each device is still connected or has gone away. Customers use this to track when a device appeared, where it has been, and whether it is still present.
For example · One MAC address has been seen on two different ports, while another went offline about 30 minutes ago.
Circuits documents the wide-area links you buy from carriers to connect sites, including the provider, the type of service, the committed speed, and the two endpoints (the A and Z ends). Each end can land on a physical location or on a point-to-point wireless link, so a wireless last mile or a building-to-building bridge can carry a circuit too. Customers use this to keep track of the connections between buildings and to the internet and what each one costs and delivers.
For example · A Lumen 1G internet circuit from HQ to Studio A, plus a backup circuit whose far end lands on a rooftop microwave link.
Trace follows a physical path one connection at a time, starting from a chosen port and walking through every cable and patch panel until it reaches the far end. It shows each hop along the way so you can see the full route a cable run takes. Customers use this to confirm where a cable actually goes without crawling under floors or behind racks.
For example · Trace from port Gi0/0 on core switch cor-hq-01 to find where the other end terminates.
VLAN trace follows a single VLAN, which is a logical network segment, across your equipment to show everywhere it is carried. It maps out which switches and links pass that VLAN along. Customers use this to confirm a given network segment reaches the rooms and devices it is supposed to.
For example · Check where VLAN 20, the audio network, actually reaches across the fabric.
IP path works out the route traffic would take between two IP addresses across your documented network, following the routing layer that moves data between segments. It shows the hops between the two addresses. Customers use this to understand how two systems talk to each other and where the traffic flows.
For example · Compute the path from 10.10.0.5 to 10.20.0.7.
Relationships shows a visual graph of how your records connect to one another, linking devices to their cables, circuits, and VLANs. You can pick an object and explore everything attached to it. Customers use this to understand the full set of connections around a device before they change or remove it.
For example · Pick core switch cor-hq-01 and explore everything attached to it.
Spanning-tree loops finds places in your discovered network where the cabling forms a circle, a loop that the spanning-tree protocol must block one link to prevent traffic from going round and round. It shows the switches involved and how to confirm the loop protection is working as intended. Customers use this to check that redundant rings are safe and not causing problems.
For example · Detects a redundant ring formed by switches acc-hq-01, acc-hq-05, and acc-hq-06.
Forwarding health reads your device configurations and flags routing problems that cause outages, such as loops where traffic circles endlessly, uneven load sharing across equal paths, and routing partnerships between devices that have failed to come up. It surfaces these on its own with no input needed from you. Customers use this to catch the kinds of routing faults that quietly break connectivity.
For example · Finds 1 forwarding loop on dist-sw2 and 1 OSPF routing session that is down on core-1.
Failure impact answers the question of what breaks if a given device fails. You pick a device, and the platform removes it from a copy of your network and reports exactly what would lose connectivity, with no risk to the live network. An empty result means you have proven backup paths exist, while a list shows your real exposure. Customers use this to find single points of failure before they cause an outage.
For example · If switch dist-hq-01 fails, 14 traffic flows lose connectivity because they have no second path.
Config topology builds a map of the network connections implied by your device configurations, giving a third view to compare against the cables you documented and the neighbors that discovery found. By cross-checking the three, you can spot a connection the configs create that nobody drew, or an expected connection the configs are missing. Customers use this to catch mismatches between how the network is wired, how it was recorded, and how it is configured.
For example · The configs form 38 routed links, including one to a device that is not in the documented cabling.
The Overview is the starting page for everything to do with IP addressing in CrossConnect. It pulls together the parts that follow, your address blocks, prefixes, individual host addresses, and ranges, so you can see how the address space is laid out and how much of it is in use at a glance. Customers use it as a home base before drilling into a specific block or fixing a problem.
For example · Open the Addressing overview to see total address space and how much is allocated across the network.
Aggregates are the large top-level address blocks that all your smaller prefixes are carved out of, along with a note of who handed each block to you, such as a regional internet registry like ARIN or RIPE, or your own private internal authority. They sit one level above prefixes and define the overall pools you are allowed to allocate from. Customers use this page to keep track of which big blocks they own and where they came from.
For example · Record the block 203.0.113.0/24 issued by ARIN and the private block 10.0.0.0/8.
IP spaces are the top-level containers that prefixes and individual host addresses live inside. They let you keep separate sets of addressing apart from each other, for example keeping a management network in its own space. Customers use them to organise their addressing into clear, non-overlapping areas.
For example · Create a separate 'mgmt' space to hold all management addresses.
Prefixes are subnets written in CIDR form, such as 10.10.0.0/24, each shown with its status, where it sits, and how full it is. The page can warn you when two prefixes overlap and can suggest the next free subnet to hand out. Customers use it to plan and track how their address space is divided and how much room is left.
For example · View 10.10.0.0/24 and see it is 47 percent used.
This page lists individual host addresses you have documented, each with a status showing whether it is in use or available. It can also allocate the next free address in a chosen subnet for you, so you do not have to scan a list by hand. Customers use it to assign and keep a record of the specific addresses devices are using.
For example · Ask for the next free address in 10.10.0.0/24 and assign it to a new device.
IP ranges are bands of addresses defined by a start and an end, used for things like DHCP pools that hand out addresses automatically or blocks set aside as reservations. Each range shows how full it is and can tell you the next free address in a read-only way. Customers use ranges to manage pools of addresses that are given out in bulk rather than one at a time.
For example · Define a DHCP pool from 10.10.0.150 to 10.10.0.200.
Duplicate IPs finds addresses that more than one device is claiming at the same time by reading through every device configuration. These clashes are a common cause of intermittent outages that are hard to spot in a spreadsheet. The page lists each conflicting address together with the devices that claim it, so customers can track down and fix the overlap.
For example · See that 10.20.0.1 is claimed by both dist-hq-01 and dist-hq-02 on their Vlan20 interfaces.
VLANs are separate logical networks that run over the same physical switches, each identified by a number called a VID. This page lists your VLANs with their number, status, the group they belong to, and which devices carry them. Customers use it to see how their network is split into segments, for example keeping audio traffic apart from guest traffic.
For example · Track VLAN 20 used for audio and VLAN 30 used for guest access.
VLAN groups are named scopes that a VLAN belongs to, which lets the same VLAN number be reused in different parts of the network without clashing. A given number has to be unique within its group, so VLAN 10 in one studio is treated as a different VLAN from VLAN 10 in another. Customers use groups to organise VLANs cleanly across multiple sites or rooms.
For example · Keep a 'Studio A' group and a 'Studio B' group, each with its own separate VLAN 10.
IPAM roles are purpose labels such as audio, video, control, voice, guest, or management that you attach to both prefixes and VLANs, so the network can be read by what each part is for. You assign them from the Prefixes and VLANs pages. Customers use roles to group network elements by intent rather than just by number, making it easier to see what each segment does.
For example · Tag both VLAN 20 and the subnet 10.20.0.0/24 with the role 'audio'.
Network zones group your whole estate into trust planes such as audio, video, control, management, data, and guest, worked out from your VLANs. The page includes a segmentation matrix that shows where two planes share the same switch and are therefore bridged together. Customers use it to confirm that sensitive planes stay separated from each other.
For example · Confirm that the guest plane is kept isolated from the audio plane.
This page shows every MAC address, the hardware identifier built into each network device, that CrossConnect has seen, and resolves each one to its manufacturer based on the address. They are grouped by maker, and each entry shows the device and interface it sits on. Customers use it to find a piece of equipment by its hardware address.
For example · Group addresses by maker, then click 'Unknown OUI' to find unexpected gear on the network.
VRFs, short for virtual routing and forwarding instances, let one physical router hold several separate routing tables so different sets of traffic stay isolated from each other. Each one is recorded with a route distinguisher, an identifier that keeps its routes unique. Customers use VRFs to keep traffic such as management separate from the rest of the network on shared hardware.
For example · Record a management VRF with route distinguisher 65000:1.
FHRP groups cover first-hop redundancy protocols such as HSRP, VRRP, and GLBP, where two or more routers share a single virtual gateway address so the default gateway keeps working even if one router fails. Each group records the protocol, the group number, the shared virtual IP, and the member routers with their priorities. Customers use this page to confirm their gateways are backed up and to see which router is meant to take over.
For example · VRRP group 1 with virtual IP 10.0.0.1, backed by cor-hq-01 at priority 110 and cor-hq-02 at priority 100.
Tunnels are overlay links that wrap one network's traffic inside another to carry it across the wider network, using methods such as GRE, IPSec, WireGuard, VXLAN, or IP-in-IP. Each tunnel records the method used, its status, its numeric identifier, and the interface, outside address, and role at each end. Customers use this page to document point-to-point or hub-and-spoke links between sites.
For example · An IPSec tunnel connecting HQ and Studio B, or a VXLAN tunnel with id 5010 across three hub-and-spoke endpoints.
L2VPNs are Layer 2 VPNs, using methods such as VPWS, VPLS, VXLAN-EVPN, or MPLS-EVPN, that join VLANs or interfaces together across different sites as if they were on the same local network. Each one lists the VLAN or interface endpoints that connect into it. Customers use this page to track networks that span multiple locations but behave as a single segment.
For example · A VXLAN-EVPN with id 5010 stitching VLAN 50 across HQ and Studio B.
DNS here covers the forward DNS zones and records for your equipment, the entries that map a device name to its IP address. It gives you a place to keep track of those name-to-address mappings across the fleet. Customers use it to see and manage how their devices are named on the network.
For example · In the av.local zone, the name cor-hq-01 points to 10.10.0.11.
This view shows which of your network devices are exposed to known security flaws, called CVEs, broken down by how serious each one is. CrossConnect matches published security advisories to the exact software version each device is running, so you can see at a glance how many devices are affected and how urgent the problem is. A customer uses it to decide which devices need a software update first and to show, with evidence, where the real risk sits.
For example · A critical flaw from 2025 affects every Cisco device running a software version older than 17.9.4.
Threat detection looks for signs that someone or something on the network is misbehaving, such as one IP address being claimed by two different devices, a hardware address showing up on more than one switch port, or an unexpected device appearing. It builds this from the address tables the switches already keep, so no extra equipment is needed. Each finding comes with a suggested fix, so a customer can spot likely spoofing or address conflicts and act on them.
For example · Flags that the address 10.99.1.50 is being claimed by two different devices at once, a sign of address spoofing.
Vendor analysis reads the gear the formal engine cannot model on its own. It uses CrossConnect's own parsers for Netgear, Ubiquiti EdgeSwitch and EdgeRouter, Aruba and Extreme, and pulls config straight from the cloud for Cisco Meraki and Ubiquiti UniFi. For each device it shows the VLANs and segmentation, the IGMP snooping and querier state that AV multicast depends on, the ACL and firewall intent, and PoE. It is honest that this is a careful read of the settings, not a formal proof of every path.
For example · A Netgear M4250 shows its VLANs and an IGMP-querier check; connect the Meraki Dashboard and the org's VLANs and firewall rules appear.
This view checks each device's configuration against common security best practices, such as using time syncing, allowing only secure remote logins, using the secure version of the device monitoring protocol, and requiring proper login controls. It reports, per device, which of these checks pass and which fail. A customer uses it to find devices set up in a less secure way and to know exactly what to tighten up.
For example · Twelve devices fail the check that says device monitoring should use the secure version 3 of the protocol.
Config grade gives each device's configuration a simple letter grade from A to F along with a numeric score, so you can rank devices by how well they are set up. For every recommended change it explains three things in plain terms: what to change, what that change does, and why it matters. A customer uses it to see at a glance which devices need attention and to understand the reasoning behind each suggestion rather than just being handed a list.
For example · The device acc-stuA-rack gets a grade of C, with a recommendation to allow only secure remote logins and an explanation of why.
An ACL is a rule list on a device that decides which network traffic is allowed through and which is blocked. This tool tests a specific kind of traffic against every such rule list across all your devices and tells you whether it would be permitted or denied, including the exact rule line that made the decision. It includes ready-made presets for common audio and video traffic types, and it does this by analysing the configurations rather than sending any real traffic, so it is safe to run anytime. A customer uses it to confirm that the right traffic is allowed and the wrong traffic is blocked, and to spot rule lines that can never take effect because an earlier rule already covers them.
For example · Audio traffic on UDP port 4440 to the 10.20.0.0/24 range is permitted by the Dante rule on six switches and denied by a guest rule on one.
This check answers whether traffic from one place can actually reach another, taking into account the routing and every rule list along the way, and then tells you whether that matches what you intended. You state whether two areas should be able to reach each other or should be kept apart, and it returns a clear pass or fail along with the path the traffic would take. A customer uses it to confirm, from the live configurations, that systems that should be isolated really are and that systems that should talk to each other can.
For example · Traffic from the guest range 10.99.0.0/24 to the audio range 10.20.0.0/24 on UDP 4440 returns PASS because the two are correctly isolated.
Segmentation compares which parts of the network are supposed to be kept separate against the traffic that is actually moving between them. It groups devices into trust zones such as audio, video, control, and guest, then checks the real traffic flows to see whether anything is crossing a boundary that should be closed. A customer uses it to catch the dangerous case where two zones are meant to be isolated but traffic is still passing between them, and to collect proof that zones which should be separate genuinely are, which is exactly the evidence an audit asks for. It is read-only and changes nothing.
For example · Warns that two flows totalling 1.1 GB were seen between the guest and audio zones that must stay isolated, while confirming the control and guest zones are verified separate.
The network black box answers the question every operator dreads at 2am: something that used to work stopped, and you need to know what changed. CrossConnect keeps every device's running config over time, like a flight recorder, then binary-searches that history against a formal model of your network to find the exact revision where a flow flipped from healthy to broken. You give it a flow, for example Dante audio from the control room to a 10.10.20.5 endpoint on UDP 4440, and it returns the interval where it broke and the precise config line behind it, healthy on one side and broken on the other. It is read-only: it names the cause and shows the proof, it never applies a change to your gear.
For example · A flow healthy on 7 June and broken on 8 June, traced in two probes to a single added ACL line on cor-bb-01 (deny udp any 10.10.20.0 0.0.0.255 eq 4440) that silently drops Dante audio, shown as a before and after diff with the breaking line highlighted.
Compliance scores your network against well-known security frameworks such as CIS, NIST-CSF, and SOC2, using the data CrossConnect has already gathered as the evidence. Instead of filling out a checklist by hand, you see how many of each framework's controls are passing and which are not. A customer uses it to gauge their security posture against a recognised standard and to produce audit-ready results without a separate manual review.
For example · CIS posture shows 18 of 24 controls passing.
Controls let you define your own compliance rules on top of the data CrossConnect collects, rather than relying only on the built-in frameworks. You write a rule that states a requirement, and the system checks every device against it and reports which ones meet it. A customer uses this to enforce their own internal standards, for example a policy that all devices must do something specific.
For example · Create a rule that requires remote logging to be turned on for every device.
Change control keeps a record of every significant change to the network, such as moving, deleting, or upgrading a device or altering a rack, and links each one to the ticket that authorised it. When a change has no ticket attached, it flags that gap so it is easy to spot. A customer uses it to prove that changes were approved and to find any that slipped through without the proper paperwork.
For example · Eighteen changes are listed with a warning that no ticket is attached, prompting you to link ticket OPS-1234.
Change preview lets you test a proposed configuration before you apply it to a real device. It loads the proposed configuration into a copy of your live network and compares what traffic could flow before and after, so you can see which connections a change would open or close. A customer uses it to catch unintended effects ahead of time, and because it works on a copy, no real device is touched.
For example · A proposed configuration for acc-sw1 would newly allow one flow from guest to printers, so it is flagged for review.
A golden config is the configuration you have decided a device should have. This view compares each device's current live configuration against that intended version and highlights any differences, called drift, line by line. A customer uses it to confirm that devices still match their approved settings and to see exactly what has changed when they do not.
For example · Device cor-hq-02 has drifted from its intended settings, with 6 lines that differ.
Config contexts let you define settings in reusable pieces that automatically apply to devices based on things like location, status, or device type. The pieces merge together, and you can preview the combined result for any single device before it takes effect. A customer uses this to apply shared standards broadly while still allowing local exceptions where needed.
For example · Apply a global time-sync setting everywhere while adding a logging override just for Studio A.
Data sources are outside locations that feed configuration data into CrossConnect, such as a folder of files or a code repository synced through an agent. The data they supply flows into the config contexts so your standards can live where your team already keeps them. A customer uses this to keep their settings in a central place and have CrossConnect pick up changes automatically.
For example · Sync a folder of standards files so its contents flow into your configuration.
Data quality gives you a single score based on a set of checks that look for missing or incomplete information in your records, such as devices with no location, no model, or interfaces missing a hardware address. It points out exactly which records have gaps. A customer uses it to keep their inventory accurate and complete, which makes every other report more trustworthy.
For example · Twelve devices are missing a location.
Config check reads every device configuration with a vendor-neutral parser and reports real correctness problems that a simple text search would miss. It flags configurations that failed to parse, references to things like rule lists, route policies, or interfaces that do not actually exist, and items that are defined but never used. A customer uses it to find genuine configuration mistakes across the whole fleet rather than just surface-level typos.
For example · On switch sw2, a rule list named ACL_X is referenced on a port but is never actually defined.
Lifecycle tracks when the hardware and software in your network reach their end-of-sale or end-of-support dates, the point past which the vendor no longer sells or maintains them. It rolls this up into a summary of which devices are at risk and suggests what to move them to. A customer uses it to plan replacements and upgrades before equipment falls out of support.
For example · Eight devices are running on hardware that is past its end-of-support date.
Fix plan combines five separate risk lists, security flaw exposure, software lifecycle, hardware lifecycle, and configuration hardening, into one ranked to-do list organised by device. Each at-risk device gets a single blended risk score and one recommended action: replace it, upgrade it to a named supported version, or harden its configuration, with the worst offenders first. A customer uses it to make one decision per device instead of cross-checking several dashboards, and it only reads data, never changing anything.
For example · Device cor-hq-02 is marked Upgrade to version 17.9.4 to clear a critical flaw, while acc-stuA-12 is marked Replace because it has a critical flaw and end-of-support hardware.
Performance shows how busy each network link is and how cleanly it is running, based on regular measurement samples taken from your devices. You can see how much of each port's capacity is in use, how much traffic is passing through, and which ports are reporting errors, which are signs of a bad cable or a struggling connection. Customers use this to spot the most congested links and to catch ports that are quietly dropping data before users complain.
For example · See your busiest links ranked by how full they are, and notice two ports reporting cabling errors.
Traffic flows shows the actual conversations happening on your network and who the heaviest users are, presented next to your equipment inventory. You get the top talkers ranked by how much data they moved, a breakdown by protocol or application, and the device that observed each conversation. There are two ways to feed it data: point your routers at the built-in collector that listens for standard flow records (NetFlow and sFlow), or send summaries to the flows endpoint yourself. Customers use this to understand what is really using their bandwidth and where it is going.
For example · The top talker is 9.8 GB of Dante audio going from 10.21.10.51 to 10.20.0.9, seen by the boston-core-01 switch.
Capacity planning shows how full your shared resources are today and projects when they will run out, covering switch power for devices (PoE), physical rack space, network bandwidth, and available IP addresses. You can set an expected growth rate and try what-if scenarios to see how the timeline changes. Customers use this to plan purchases and changes ahead of time instead of being surprised by a resource filling up.
For example · At 5 percent growth per month, the audio VLAN runs out of addresses in about 120 days.
Storage shows how full the onboard storage and memory are on each device across your fleet, covering bootflash, disk, and memory, gathered automatically over SNMP, a standard protocol for reading device health. Areas that are nearly full are listed first. Customers use this to catch a switch that is low on space before that shortage causes a backup or a software upgrade to fail partway through.
For example · The acc-stuA-rack switch shows its flash storage at 92 percent full, flagged as near full.
Rack power checks that racks fed by two independent power sources (an A feed and a B feed) can survive losing one of them. The rule is that neither feed should carry more than a threshold you set, commonly 50 percent, so that if one feed fails the remaining feed can take on the full load. You enter the voltage, amperage, and threshold, and it flags any rack that breaks the rule. Customers use this to confirm their redundant power is truly redundant and not quietly over capacity.
For example · At 120V, 20A, with a 50 percent threshold, one rack is running at 62 percent on each feed, which breaks the rule.
Automation lets the system watch for conditions and react on its own when a measured signal crosses a limit you set. When a threshold is passed it can take an action such as writing a log entry, calling an outside system through a webhook (a message sent to another tool), or opening a tracked issue. Customers use this to turn routine watching into hands-off responses so problems get recorded or escalated without someone staring at a screen.
For example · Automatically open a tracked issue when switch power usage for devices goes above 90 percent.
Event rules is where you write and manage the individual rules that the automation engine checks. Each rule pairs a condition to watch for with the action to take when it happens. Customers use this to tailor exactly what the system reacts to and how, building up the set of rules over time.
For example · If a configuration change is detected on a device, send a webhook to another tool.
Jobs shows the background tasks the system runs, both the ones happening right now and a history of past runs, with their live output as they go. This lets you follow long-running work and confirm it finished. Customers use this to keep an eye on tasks like a scan of the network and to check what happened if one did not complete cleanly.
For example · Watch a network discovery scan run to completion and read its output as it progresses.
Upgrades helps you plan software updates for your devices, including the windows when notifications go out, and it generates infrastructure-as-code files, which are scripts that tools like Terraform or Ansible use to apply changes in a repeatable way. Customers use this to organize a rollout in advance rather than upgrading devices one at a time by hand.
For example · Plan a rollout of IOS-XE version 17.9.5 across the affected switches.
Change safety is a pre-flight check you run before touching a device. You pick the device, and optionally paste the configuration you plan to apply, and it returns a single verdict of GO, CAUTION, or HOLD. That verdict combines four things: whether the change would break reachability, how wide the damage would be if it failed, what live traffic the device is carrying at that moment, and whether you are inside an approved maintenance window. No single one of those tells you it is safe, but together they do. It only reads and never makes changes, and it still works if some inputs are unavailable.
For example · For cor-hq-02 the verdict is HOLD because it has only one path, is exposing 14 traffic flows, is carrying 9.8 GB of live Dante audio, and is not in a maintenance window.
Maintenance windows let you schedule planned change or blackout periods covering a single device, a whole site, or your entire account. During a window, the system gives a live read of whether it is active right now, so work done and alerts raised in that time are understood as planned rather than as a surprise outage. Customers use this to keep their team from chasing alarms that are really just expected maintenance.
For example · Schedule a Studio A blackout for Saturday 22:00 to 02:00, and the dashboard marks it active while it is running.
Reports is a catalog of ready-made reports you can run, plus the option to have them emailed to you on a schedule. Customers use this to answer recurring questions about their network without rebuilding the query each time, and to have those answers arrive automatically.
For example · Run the report that lists devices reaching their end-of-support date.
Export templates let you save a named set of columns for exporting your devices, VLANs (logical network groupings), or circuits to a CSV or JSON file. You choose the columns once, then re-run the same download whenever you need that report again. Customers use this to produce consistent exports for audits or handoffs without picking the fields every time.
For example · Build an audit template that exports each device's short name, full name, status, and software version as a CSV file.
Saved filters let you store a search you use often on a given list view and give it a name, then recall it later from that view's saved filter picker. This saves retyping the same search again and again. Customers use this to jump straight to a common view of their data in one click.
For example · Save a down access switches filter on the Devices list and apply it in one click.
Runbooks let you write or import step-by-step operational procedures that apply to many targets at once, including categories of trouble spots in the network. Each runbook fills in the specifics of the item it is attached to using templates, so the same procedure reads correctly for each device, and the whole library can be exported to a grouped PDF. Customers use this to keep consistent instructions for handling common situations and to attach the right steps automatically wherever they apply.
For example · A Device down runbook attaches to every device-down alert and fills in the name of the specific switch involved.
Journal is a running operational log you can add notes to on any device, where each entry is stamped with the time and the person who wrote it. Customers use this to keep a record of what was done to a device and when, so the history stays with the equipment for the next person who works on it.
For example · Add the note Replaced fan tray under RMA to the acc-stuA-rack switch.
The Assistant is a chat box where you ask questions about your network in plain English and get answers back. It pulls from your own records, so every answer comes with citations that point to the exact devices or data it used, and it tells you when it does not know rather than guessing. You can also ask it to make changes, but it will never change anything on its own. It shows you the proposed change first and waits for you to confirm before it commits.
For example · Ask 'Which devices are down right now and who owns them?' and get a list with links to each one.
AI setup is where you connect CrossConnect to the AI model you want to use, a setup often called bring-your-own model. You choose the provider, pick the specific model, and paste in your own access key, which is stored encrypted and kept separate for each tenant (each customer account). A test-connection button lets you confirm the key and model work before you rely on them.
For example · Choose Anthropic, pick the claude-sonnet-4-6 model, paste your key, and run the connection test.
AI quality is where you review how well the Assistant has been answering and improve it over time. It shows a quality score along with a list of answers that did not go well, such as ones that lacked supporting records, were held back, or got a thumbs-down from a user. Working through that list tells you what to fix, whether that means adding a capability the Assistant was missing, documenting a feature, or correcting a record so future answers are better.
For example · Look at the questions that missed last week and mark past answers as good or bad.
Write intents is the queue of changes the AI has proposed but not yet made. Because the Assistant never changes your data on its own, anything it wants to do waits here for a person to review and approve it. You can look at each proposed change, then approve it to apply it or reject it to discard it.
For example · Review a proposed rename of a VLAN and approve it to apply the change.
Encryption keys is where you manage the master key that protects every stored secret, such as device passwords and API tokens. Those secrets are encrypted at rest behind this key, which never leaves your server. You can rotate the key with no downtime and see when it was last rotated, and a startup check refuses to run on a weak or default key, so a misconfigured install fails safe instead of running exposed.
For example · Rotate the master key and every stored secret is re-wrapped under the new one, with the old key retired on a schedule.
This is where you manage the people who can sign in to CrossConnect for your account, and what each one is allowed to do. Every user is given a role, such as a read-only viewer or an editor who can make changes, and you can grant finer permissions on top of that role for specific actions. Use it to add a new team member, change someone's access level, or remove access when a person leaves.
For example · Give a teammate an editor role plus permission to run device upgrades.
API tokens are keys that let your own scripts and other software talk to CrossConnect through its programming interface instead of through the web pages. You create a token here, hand it to a script, and that script can then read or update your data on your behalf. This is useful for automating tasks or pulling data into another system, and you can issue a read-only token when the script only needs to look at data.
For example · Create a read-only token so a nightly script can pull the device list.
Secrets is an encrypted vault for the sensitive login details CrossConnect needs to reach your network gear, such as device passwords and access tokens. Storing them here keeps them protected rather than sitting in plain text, and the rest of the product can use them when it needs to connect to a device. Use it to save credentials like a switch's privileged-mode password in one safe place.
For example · Save the privileged-mode password for the main core switch.
Discovery is the part of CrossConnect that automatically finds and reads your network equipment, and this page controls how it works. Here you turn scanning on or off, store the read-only login details it uses to query devices, and define which parts of your network it should scan, including ranges of addresses to probe for gear it does not yet know about. The product only re-checks devices it already knows by default, so adding a management range tells it to walk every address in that block and report whatever answers, which is how new equipment on a fresh subnet gets found without you typing each device in by hand.
For example · Add the read-only credentials for the demo network so the scan can read its switches.
Integrations lists every connection CrossConnect can make to outside systems, both data coming in and data going out. Each connection is turned off by default and is switched on through configuration, and the page shows its current status, what it does, and how to enable it. Use it to start pulling in data such as system log messages, or to send your activity out to a security monitoring tool.
For example · Turn on incoming system-log collection, or send activity out to a security monitoring tool.
Inbound review is the checkpoint for information arriving from outside systems before it is treated as fact. Each incoming claim shows up as a proposal that is matched to a known item and given a confidence rating based on how many sources agree, and you confirm or dismiss it. This means nothing from an outside feed quietly changes your records without a person looking at it first.
For example · Two sources agreeing a port is down get a high confidence rating, while a claim about an unknown host gets a low one.
Webhooks let CrossConnect automatically notify another system the moment something happens, by sending it a message over the web. You choose which events should trigger a message from more than fifty event types, and CrossConnect signs each message and retries if delivery fails. Use it to push alerts into another tool, optionally including related details, so that system reacts without anyone watching CrossConnect.
For example · Send a message to your security monitoring tool whenever configuration drift is detected.
SMTP setup is where you tell CrossConnect how to send email for your account. Once configured, it can deliver scheduled reports and notifications to your inbox. You point it at your organization's mail server so outgoing messages go through your normal email path.
For example · Point report emails at your company's mail server.
Custom fields let you add your own pieces of information to records when the built-in fields do not cover something you track. Each field has a type, such as text, a number, a yes/no value, a date, a web link, or a pick-list of set choices, and entries are checked as you type. The fields can also be searched by the assistant, so use it to capture details specific to your environment.
For example · Add a criticality pick-list with low, medium, and high choices to your devices.
Custom links let you place buttons on a record that jump straight to the matching item in another system, such as a ticketing tool, a dashboard, or a wiki. You write a web address template that includes placeholders like the item's short name, and CrossConnect fills those in and shows the link on every matching record's detail page. Use it so anyone can go from a device in CrossConnect to that device's page in another tool in one click.
For example · Add a dashboard link that appears on every device and opens that device's chart.
Tags are colored labels you can stick on any record to group and find things your own way. You create the labels here and then attach them to devices, racks, or anything else, and you can filter lists down to just the items carrying a given tag. Use it to mark a set of items that belong together, like everything tied to your audio-visual systems.
For example · Create an AV-critical tag and attach it to the devices that run your audio and video.
Contacts is a directory of people and teams that you can attach to records along with the part they play, such as technical, administrative, or billing. Linking a contact to a device or rack records who to reach about it. Use it so anyone looking at a piece of equipment can see who is responsible for it.
For example · Assign the AV Ops team as the technical contact on a rack switch.
Customers lets you record which department or client owns each part of the network, and you can group them. You assign devices, address blocks, circuits, and network segments to an owner so it is clear who a given piece of the network belongs to. This is helpful when one CrossConnect account serves several teams or clients and you need to see who has what.
For example · Show that the Acme Studios department owns fourteen devices and a block of addresses.
Plugins is a list of the optional add-on components running inside CrossConnect, such as the audit log and webhook features. The page shows which ones are currently started. Use it to check that the pieces you rely on are active.
For example · Check that the audit-log and webhook plugins are running.
A tenant is a separate, walled-off account whose data does not mix with any other, and this page is the directory of them. It is the boundary that keeps one organization's network records fully isolated from another's. Use it to create a new tenant when you need a fresh, separate space, for example for a new client.
For example · Create a separate American Sound tenant for that client's network.
The audit log is a filterable record of every change made in CrossConnect, drawn from the protected history trail. You can narrow it down by the type of change and by time to find exactly what you are looking for. Use it to answer questions like who moved a device or what was edited during a given week.
For example · Filter to just the device-move events from this week.
Recent events is the running feed of every change, kept in a tamper-evident way so each entry is chained to the one before it and any alteration would be detectable. You can confirm that this chain is intact and download the records as a spreadsheet file. Use it as a trustworthy history for audits, where it matters that no entry was quietly changed or removed.
For example · Confirm the change history is intact and has not been tampered with.
The sitemap is a single page that lists every screen in CrossConnect with a short description of what each one does. You can export the whole map as a PDF. Use it to get an overview of everything the product offers or to share a reference of the pages with your team.
For example · Export the full list of pages and what they do as a PDF.
Admin config holds account-wide settings and on/off switches for your tenant. It is where you adjust the defaults and options that apply across the whole account rather than to a single record. Use it to fine-tune how CrossConnect behaves for everyone in your account.
For example · Adjust the default settings that apply across your whole account.
Workflows is a searchable library of step-by-step guides for the common jobs you will do in CrossConnect. You can tell it what you want to accomplish or pick a guide from the list, and each one walks you through where to go in the app, what to do, why you are doing it, what you need to have ready, and what the result will be. It is meant to get you to a finished task without having to already know your way around the product.
For example · Search for isolate guest to open the step-by-step guide for separating guest traffic onto its own segment.
Articles is the in-product help center, with how-to guides, explanations, a glossary of terms, and the full list of features. It is where you go to learn how CrossConnect works and how to do something, all without leaving the application. New users often start here to get oriented before diving into the rest of the product.
For example · Open the How do I start? article for a walkthrough of first-time setup.
API and Webhooks is the reference for connecting CrossConnect to your own scripts and other systems. It is laid out as a two-pane browser: one side lists every REST endpoint (a web address your code can call) with what it does, the parameters it takes, what it returns, and copy-and-paste request, response, and curl examples; the other lists every webhook event, which is a message CrossConnect sends out automatically when something changes. It also covers the basics of sign-in, the tenant header that identifies your account, message signing, and retries.
For example · Look up the endpoint that creates a device, or find the webhook event that fires whenever a circuit changes.
Glossary is a plain-language dictionary of the networking and CrossConnect terms you will run into while using the product. Each entry gives a short, everyday definition so you can look up a word like VLAN, LLDP, or circuit without leaving the app or searching the web. It is helpful if you are newer to networking and want a quick refresher on what a term means.
For example · Look up LLDP to read a short explanation that it is the protocol switches use to announce which neighbors they are connected to.
Everything about your network in one place, checked against what is really connected, with a black box that finds what broke a connection and an assistant that answers in plain English. CrossConnect is in active operator preview.
