Every time I explain the Forward platform and what a Snapshot is, I know the next question I will be asked. I would start with something like "A Snapshot is a collection of the network devices’ running configuration and state at a specific point in time. The Forward Platform uses all the data gathered to run its mathematical model and calculate every possible traffic path in the network.” And here it comes the same question, every, single, time: “How long does it take?” I smile and I say “Well, it depends :)"
It’s not that I want to hide bad news or that I’m afraid the answer could close any further conversation, but it really depends on different factors, and most of them actually are not related to the Forward platform but to the managed networks instead, like the number of devices, the size of the forwarding tables, the ability of authentication servers to keep up with the parallel collections Forward instantiates just to name a few. Some of these factors can impact one or more stages that go into building the mathematical model of the network. At the end of the day, what customers care about is the total time between when a new collection starts and when all the data has been processed and available on the Forward User Interface (or the Forward APIs). In large network environments, where thousands of devices are contained in a single view, this time can be significant.
To simplify the concept, the total time to build the mathematical model of the network can be divided into two main components:
- Collection Time: the time it takes to connect to all the devices, gather the configuration and state, parse and normalize all the data;
- Processing Time: the time it takes to process all the normalized data
We spend a lot of time and effort to constantly improve the Forward Platform to support bigger networks and at the same time to reduce the time needed to build the model. Many of these improvements are driven by our customer’s use cases. For instance, some customers are using the Forward platforms in change management windows where it’s critical to verify that the network is behaving as expected as quickly as possible after a change has been made. Often only a small subset of devices is affected by the change, the collection time is usually way longer than the processing time and, last but not least, the biggest bottleneck is the authentication server's scalability and response time.
Today I’m happy to announce the release of Partial Collection, a new feature designed with the change management windows use case in mind.
Partial Collection allows users to dramatically reduce the collection time by restricting and triggering a new collection from a subset of devices and then merging the new data with the most recent Snapshot.
The merged data is then fully processed again by the Forward platform.
Some customers have already reported huge improvements by leveraging Partial Collection. For instance, a customer with 5000 devices, very large routing tables and, more importantly, a TACACS server that can support only 16 parallel connections has been able to reduce the collection time by 10 times, allowing them to verify the network in very short change management windows!
We have also added new useful information to the snapshot menu, the collection Span. It's the period of time between the oldest and newest device collection times in the Snapshot. In this way, customers can understand how old the oldest collection is, as well as how far apart the collection stretched for the given network.
For more information on Partial Collection check the Snapshot documentation page in the Getting Started section.
Stay tuned for more enhancement on Collection and Processing Time!
