Cloud Readiness, Part 1: Connectivity and Interdependencies
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!
Cloud Readiness, Part 1: Connectivity and Interdependencies
NFD13: SolarWinds Presents Its New NetPath Tool
Improve Your IT Infrastructure Without Remodeling or Rebuilding