Making ACI Configurations Consistent
Forward Networks came out of stealth with a great presentation at Networking Field Day 13. The company was founded by four Stanford PhDs and is funded by some of the top Silicon Valley venture capital firms.
Forward has a very innovative product that is being marketed as a Network Assurance platform, capable of verifying that your network behaves as intended. I and all the #NFD13 delegates were very intrigued by the product, and found that it demos well.
Of course, the proof is in the user experience, so I’d certainly recommend trying the offering on your own network, after reading this blog and watching the NFD13 streaming videos.
Forward Networks recognizes the complexity of modern networks: complex routing and other configuration elements’ rules, multiple vendors, bugs — many things can affect a network. They want to help their customers ensure things work properly.
Forward Networks determines single network device behaviors at the network flow level. They apparently do this by varying device configurations and sending probe traffic through each device.
From their web pages:
“… the Forward Platform computes a model of all current and potential behaviors of the network devices. What this delivers to users is a mathematically accurate copy of a running network, all in software.”
Forward Networks combine that device- and OS-specific behavioral model with a collection of your device configurations and network topology to build a model of your network. They can then probe the model network with packet flows, follow the path(s) taken, and determine where packets get blocked.
This allows Forward Networks to build a database of paths and ports (flows) that is rapidly searchable, just like Google does for words. That, in turn, allows checking whether any given flow is permitted through the network, and what path(s) it might take.
There’s got to be some deep proprietary (Stanford thesis-based) magic there. It sounds like limited reverse engineering of a network environment via observing inputs and outputs and describing it as a OpenFlow-like black box.
All that prep work is done behind the scenes, and stored/accessed in the cloud — or on your premises.
The second portion of the product leverages this database. If you specify your intentions or policy, in the form of permitted or denied packets, Forward Networks can then verify whether your intentions (aka “connectivity and security rules”) are met.
Forward Networks keeps tabs on current configurations, so once you have your policy built, it can let you know if configuration changes broke something. It can also pinpoint which configuration element blocked traffic that should be permitted. It also tracks configuration changes, so it can tell you when a problem first occurred. And you can do “what if” predictive modeling in a “sandbox.”
Here are the key use cases:
The product does not yet address automated remediation. It does have a REST API, which might allow you some interesting automation of workflows.
Have you noticed there’s a severe shortage of skilled network engineers at CCNP level and above?
I’ve worked with some complex networks. It can take a CCNP or CCIE hours to figure out where a given flow is blocked and why. Make it multi-vendor and it gets even more challenging.
As far as value, here are the big ones from my perspective:
I’m a big fan of not spreading your senior talent too thin. Anything that keeps them out of day-to-day problem solving has got to be a big win!
That does assume you know the flows in your network, and I have yet to consult at a site that can tell me all the flows and server endpoints for their most critical applications.
Thought: Combining Cisco Tetration with Forward Networks might be a very interesting play. Tetration to identify the flows; Forward Networks to check that what was working still works. However, there’d need to be some API glue in between.
The potential of the product is amazing. I do have two concerns that were not addressed within the limited realm of the NFD13 presentation:
The second of these reflects my years of network (and other) management and consulting experience. I always look for the labor-intensive pain points.
My prior reference point for tools like this is the Netsys network modeling product, acquired by Cisco in the late 90s. I taught classes on the product and was amazed at the amount of human effort it might have taken Netsys to accurately predict the effects of various configuration commands. OPNET also used to model networks, using standards-based state models — which did not necessarily quite match up with vendors’ implementation quirks.
NetBrain does this sort of thing on the fly, on a path basis, for both forward and return flows, one at a time. It is not clear whether this is based solely on modeling, or to some extent on extracted routing tables plus modeling.
Another way to tackle this problem: NetCraftsmen has been using VIRL to pre-model and test changes and configurations, even when the customer has a physical lab. It is much more productive to be able to work in spare hours — labs tend to require being physically present or non-available remote access.
I’m impressed — the product looked quite useful. I can’t rave further without exploring the questions above, or getting hands-on with the product. I will go as far as to say that if the above stimulates your interest, watch the NFD13 videos, read David Varnum’s blog (link below), check out the Forward Networks website, and get a demo.
If you want to learn more or see the demos (NFD is big on demos), be sure to check out the streaming videos of Forward Networks presentations and related blogs.
For more information on Forward Networks, read the following blogs:
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
Making ACI Configurations Consistent
Six Tips to Help with Your Next Configuration Audit
Does Security Belong Near Endpoints?
Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.