It worked Monday. By lunch it did not.
CrossConnect keeps your design and the live network as two separate records. When something breaks, it replays the network and names the change that did it, with the configuration before and after.
Every day, on your Linux host
It runs on a Linux host you already own and re-reads the network on a schedule.
Read-only accounts, and whatever configuration backups you already keep.
It only reads. Configurations stay as they are, and it sits outside the traffic path.
It names the hop where the proof ran out.
The record is right the day it is written and wrong by Thursday.
Somebody made a change at half past eight. It was approved and in a window. It looked unrelated. Three devices moved together and one audio path stopped existing.
Without a record of what the network looked like before, the next four hours go on rebuilding that record from memory and from people who were not there.
With intent and reality kept apart, the morning question becomes what moved since yesterday?
Healthy at 06:31. Broken at 08:31. Here is the change.
- 1The change it found
- 2Worked, then broken
It keeps a copy of yesterday, so today has something to be different from.
The whole network, on a schedule, over read-only access. It keeps what it found.
Today against yesterday, and both against what you said you meant to build.
When something stops working it finds the last moment it worked and the first moment it did not, then names what changed between them.
When it cannot prove a path, it says so.
A reachability answer that is confident about a hop it never saw is worse than no answer. Here is what to do with each kind of gap.
- 1Take the named hop first
When it reports no path it names the device where the chain stopped. Usually one of two things is wrong: nobody can reach or back up that device, or nobody has its credential. Fix that one and a whole region of the map fills in.
- 2Then the devices with no configuration
It can see a device on the wire and still have no configuration for it. Those are listed separately, because a path through a device you cannot read is a guess.
- 3Then set what "meant to build" is
Until intent is written down, everything is a change and nothing is a drift. Declare the intent once and the daily report shrinks to the changes that matter.
Does it push configuration?
Does it push configuration?
No. Configurations are read and left as they were, and every build ships with a test that fails if a write path appears.
What does it need from us?
Read-only access to the devices, and whatever configuration backups you already keep. If you keep none, it can hold its own copies.
How is it different from CrossScan?
CrossScan makes one pass and leaves you a file. CrossConnect stays on and keeps yesterday, which is how it can tell you what changed. Most people run CrossScan first.
Will it tell us who made the change?
It tells you what changed and on which devices, down to the two minutes it happened between. Who did it comes from your change record, and the report is laid out to be pasted into one.
What about devices it cannot reach?
They are named and they lower the coverage figure. An unreachable device stays in the denominator.
See it work
There is an all-hands at nine. Is the room going to work?
Nobody asks that question until nine o’clock, when it is already being answered badly. CrossConnect asks it the night before, on a schedule, and writes down what it found.
Start here. The whole application on a demo estate of 241 devices across four sites: the map, the inventory, what changed overnight, the room that will fail at nine, and the change that broke it. About a minute for the tour, as long as you like after it.
It found the room before the room found you.
It read the estate off the wire and kept reading. It checked the room on a schedule, failed it, and showed the evidence behind every finding. Then it named the change that broke it, and it never touched a device.
Sample data. This demo does not connect to any network, and nothing you click changes anything.
Before the next change goes in
If you also run CrossCheck, it can take its inventory from CrossConnect and rehearse the next firmware change against it.
CrossConnect next to the other sevenCrossConnect hands you the gap between the plan and the network, which is where CrossCheck picks up: “Will this change break the room?”
Bring one outage nobody explained.
Bring read-only access to the devices around an outage nobody could explain. In thirty minutes we show you how CrossConnect reads that part of the network, and what it would keep for the next morning.