Verify Intended Network Functionality Using Veriflow
What kinds of problems would you be able to avoid by managing your network according to your intent?
Here's the problem: You're responsible for a network and would like an automatic way to verify that it's functioning correctly. Validation is important for business applications as well as for voice and collaboration, especially with regard to security and redundancy.
Traditional network management systems rarely contain the types of checks needed to discern correct operation. Sure, they check interface up/down, memory/CPU utilization, interface utilization/congestion. But these are device-centric checks, not system-level checks. Some advanced management systems check multi-device functions like Hot Standby Routing Protocol (HSRP) or Spanning Tree Protocol (STP), but that doesn't necessarily mean that they also check that the network is performing correctly or that redundant paths are operational.
When I say "performing correctly," I mean that business applications are able to communicate with one another to implement business processes and to provide desired resiliency for various failures. Preventing and restricting communications is just as important, but network management systems rarely provide such functionality. Should the air conditioning system really be communicating with the voice and collaboration systems? That's not something most network management systems would be capable of detecting -- or taking action on to remediate.
You may have recently read about intent-based networking (IBN) here on No Jitter or elsewhere (see my post, "Intent-Based Networking: Buzzword or Real?). IBN systems verify that the network is correctly implementing its design intent, including connectivity, link operation, security policies, routing policies, and redundancy. Managing by intent is a good way to find hidden problems, as well as to verify functionality after changes.
In a Veriflow-commissioned survey, Dimensional Research found organizations that run validation checks (some don't) primarily used several mechanisms to verify their networks (multiple responses allowed):
- Manual process (69%)
- Network management system (57%)
- Scripts (47%)
- Commercial products (12%)
Validating network functionality requires:
- Data from the network about how the network is functioning
- Rules and policy definitions that check the data against the desired functionality
Veriflow automates the collection of network data with minimal configuration required. On the other hand, functional validation requires entering rules that define the checks to be performed. Veriflow's application programming interfaces (APIs) allow network managers to automate any aspect of the system as applicable to their needs or to extend the system's analysis with external data processing.
Veriflow includes a topology mapping function with basic Layer 2 and Layer 3 layout. As with any topology mapping tool, you'll have to manually edit the diagrams to make them look good or to match them up with your concept of the topology. The network discovery mechanism also works in Amazon Web Services (with support planned for Microsoft Azure and Google Cloud Platform).
Join Terry at Enterprise Connect 2018, where he'll be presenting:
Basic analysis rules provide information on devices that are added and removed from the network, something that most network management systems can perform. It can also do firewall rule analysis by looking at the forwarding plane state information and tracking flows across the network. So, it can validate whether two endpoints or subnets can communicate with one another.
In the NFD demonstration, Veriflow showed an example of an incorrectly configured firewall -- it was supposed to have redundant paths to two core routers, but in fact had only one active connection. As such, when the operational path went down, an outage would have resulted. The topology map showed the existing connectivity, making the absence of a redundant path obvious. Think about how useful that would be for checking the resiliency of a voice/video system or critical business application.
A recent addition to the product uses configuration data it pulls from network devices to perform "pre-flight" analysis of connectivity based on proposed configuration changes. Being able to verify proposed configurations before deploying them in a live, production network will help reduce configuration errors.
The data collection system is separate from the analysis and rules engine. Data collection agents run either on or near the network devices, while the analysis engine sits in the cloud or, for organizations that can't export data to a cloud analysis system, it runs on on-premises servers.
With APIs, Veriflow offers the ability to extend the product's functionality.
How would I apply Veriflow in a real network? I would start with the network discovery and topology mapping. Having accurate topology maps is always a good thing -- a good topology map will tell you whether the network is actually connected the way you think it is, but never had the time to verify.
I would then review my network documentation and enter simple rules that verify the infrastructure links. For example, Switch A, Gig0/1 should connect to Switch B, Gig0/48. Veriflow can then generate alerts whenever there is a problem with a connection, including basic cabling errors. This is where a separate source of truth database (i.e., NSoT or NetBox) can be handy as a repository for connectivity and addressing information. While I would start with the infrastructure links (router and switch interconnects), I would quickly add critical server interfaces for business application servers and UC infrastructure.
Next I would start adding connectivity rules for business applications, voice, video, and collaboration. A quick review of IT trouble tickets should provide enough information to identify rules to add. Examining security policies and application connectivity requirements would be the next step.
Veriflow looks to be a quick install with relatively easy configuration and rapid results. A proof-of-concept test should be easy to perform. The greater challenge for most organizations will be to identify the network design intent and create the corresponding Veriflow connectivity rules.
I'm starting to see several networking tools that provide system-level functionality. Veriflow is one that can be applied to a variety of network topologies, such as leaf-spine and three-tier (core, distribution, access) models. I'm looking forward to more of these tools and exploring how to integrate them with one another.
Disclosure and caveat: While the NFD presenters indirectly paid for my travel and lodging to attend NFD16, I didn't receive any compensation nor have the vendors been promised any favored treatment in articles or reviews. I've not yet had an opportunity to drive Veriflow in a real network, so the above information is from the NFD16 presentation and a follow-up presentation at NetCraftsmen.
Learn more about Systems Management & Network Design at Enterprise Connect 2018, March 12 to 15, in Orlando, Fla. Register now using the code NOJITTER to save an additional $200 off the Advance Rate or get a free Expo Plus pass.
- Is the Data-Driven Network Next Step in Networking?
- Intent-Based Networking: Buzzword or Real?
- Setting the Foundation for Network Automation