First day at Tech Field Day NFD16 , I’m quite excited to be here among fellow network engineers to share our views on products and technologies.

I’m planning to post my takeaways for each vendor with variable lengths based on my knowledge and interest of the specific product.

Today’s first presenter is Veriflow . Let’s see what Continuous Network Verification is and how it can help to make networks more robust and secure.

Veriflow

What Veriflow does is to collect data plane L1 to L4 information about the network, create a model of the whole network and then predict the impact of changes and outages.

The collected information used to create the model include running configurations, L2 and L3 tables, CDP/ LLDP neighbors, VRRP/HSRP status, routing tables etc. The product does not collect actual data or flow information but uses only control plane information (more on that later).

All the collection is agentless and works with multiple vendors. what you put in your network in a collection machine that grabs all the information and sends that to a verification engine.

The verification engine performs data normalization and creates the predictive model.

The product focus right now is mostly on L3 Access-List changes. With Veriflow it is possible to verify if a traffic is allowed on all the access-lists on the path of it is blocked somewhere. The search engine clearly shows which ACL dropped the traffic with a detail up to the exact line on the ACL.

If we compare this to the manual process involved to get the some result it is easy to understand how much time it saves.

It is also possible to predict if a change in an access list would impact some network communication allowing unwanted traffic or blocking business traffic.

The Intent

The intent feature in Veryflow is not the same intent based you find in other automation products but is still quite useful indeed. We can define how the network should behave and verify the model supports that intent.

In my opinion the best part is many intents are automagically created when the model is built. It is possible to create new intents with the GUI or API.

What is an intent for Veriflow? It could be the reachability status of a particular network from a specified source, the presence of a prefix on the RIB or a specific devise, the presence of an ACL that permits or allows specific traffic.

What happens for example if we filter a prefix somewhere on the network? Or we create and access list that filters traffic that should be allowed?

Veriflow collects the information, verifies if the updated model satisfies the intent and generates an alarm when it doesn’t. The alarm includes a very detailed information of the configuration that generates the unintended model so it’s possible to go back and fix it.

It is also possible to investigate the status of the network in different times to compare the differences. That’s a great whay to get an answer of the most important question when something goes wrong: what’s changed?.

What I’d like to see in the roadmap

The model of the network can be very good and accurate but over the years in IT I learned to trust&verify. I feel like the verify part can be stronger here.

The question is: what happens if the model is wrong?

What I’d really like to see is an integration with Netflow/IPFIX to validate the model with actual data traffic. It may happen that the model misses something and the data takes an unpredicted path. Veriflow right now wouldn’t be able to verify that, there’s no model validation in the workflow. It may be a corner case but we now that sometimes Network Engineers can be very creative in their solutions and a model can’t predict every single case.

I don’t think Veriflow should replace a Netflow/IPFIX collector but limited collection to validate the model would close the loop.

Another feature where I can see improvement is about prediction, or Pre-flight as they call this feature. It is possible to read the BGP table and OSPF database from the devices. It would be very useful to evaluate the second-best path, not installed in RIB, to verify there is a valid backup path in case of problems. What happens if one interface or routing peer goes down? Right now we need an actual problem to happen to collect all the information during the fault from the devices and verify the second path.

See the session recording for more on this. .

I understand Veriflow does not focus on this feature right now. Read “A General Approach to Network Configuration Verification " for more on this topic.

Last feature I’d like to see is the integration of Security Intelligence feeds to create Security Intents. Security intents could be used to verify if traffic that may lead to and attack is allowed on the network. Something as simple as port 445 should not be open to the WAN could be a good start.

Wrap up Veriflow

I think Veriflow is a great product, the GUI is very nice&clear and very fast. It is possible to filter the prefixes using a tcpdump-like syntax. The model generated is very accurate and it’s possible to extend it, sky’s the limit.

Veriflow can be used both as a preventive tool to spot outages before they occur or as troubleshooting tool when things are bad, every Network Engineer would love to have it in the toolbox.

You can see the full recordings of this and previous events on youtube . Go to TechFieldDay.com for more videos and great articles on IT.

DISCLAIMER

Tech Field Day (TFD) is a commercial activity for TFD and the presenting companies. When I attend TFD events my travel and accommodation expenses are usually paid for by TFD. At the events, most of my meals are provided by TFD. In addition, the companies that present at TFD usually give the delegates gifts. At TFD the presenting companies engage with delegates to educate us about their products and services. The smart companies also want to learn from delegates (a few are very smart about this). The aim of the event is to help the presenting companies connect with delegates. Ultimately get the company’s message spread by delegates. Usually, delegates will write about some or all of the presenting companies.

Neither the TFD staff nor the presenting companies get to review what the delegates write. There is no obligation on delegates to write about any or all presenters. Nor is there an obligation to write nice things about presenters. In fact, the greatest expectation is that delegates will be honest in any writing that they do.

This (ifconfig.it) is my personal blog. Everything I write here is my thoughts and opinions. None of it is reviewed by the organizations I write about before publication. I could get corrections from the companies I write about and may incorporate the parts I agree with into my posts here.