Forward Networks’ flagship product, Forward Enterprise, delivers a vendor-agnostic “digital twin” of the network, designed for both cloud and on-prem networks
We have broken all previous records on the number of visitors to our booth (409) with lines of people longer than we’ve ever experienced. Staffed with some of our best technical team members on-site in the booth, we're educating discerning attendees on our revolutionary technology. We’re available (in English, French, and Italian!) to drill down on details and explain what’s happening ‘under the hood’ inside our network verification and network assurance technology
People from all over the world are excited to understand how Forward Enterprise can not only help manage their Citrix devices but also get a holistic view of their entire network across vendors. It has been so exciting to share it with attendees for the first time and see their eyes light up!
We love talking to the technical gurus and NetScaler admins that can appreciate the insight of our product, many of which have begun pilot evaluations to learn more in their own environment.
After a quick demo, visitors want to understand on a deeper level what powers Forward Enterprise so we’ve been launching into a 20-30 minute product overviews throughout the day.
Remember, we still have 2 days of Synergy left-- any attendee that visits our booth can take not only the information gathered back to work with them, but a full-featured 90-day version of our enterprise software!
Last month we introduced our Network Query Engine (NQE) at Cisco Live Europe and to a very impressive technical audience as part of Tech Field Day 2019. If you didn’t have the chance to read through our introduction blog, NQE leverages the internal network data model that Forward Networks builds and manages to allow users to query their network infrastructure details like a database. These queries can be quickly built to confirm network health, proper configurations, effects of a change, device or interface status, etc. A few representative queries that customers have described to us and that are now possible include:
Do all distribution layer access links in my network have redundant paths?
Are all BGP sessions currently established with configured peers?
What are the nearest neighbors of a down device?
Are any device interfaces intended to be operational currently down anywhere in my network?
By viewing all network details as a data source, users are able to query on issues globally across their entire network, looking for any anomalies, in one quick sweep. This has rarely been possible before, without an enormous amount of usually custom effort. The alternative is to check for conditions at each device, one at time, across a large network. Scripts that automated these kinds of custom checks across network devices are very tedious to develop and maintain, especially across different vendors and device types. Forward Networks now makes it easy to build queries in only a few minutes, based on the normalized, vendor-neutral data model in our platform, with a very flexible new query language, GraphQL.
GraphQL was developed by Facebook and turned into an open source project in 2015. It offers enormous flexibility in defining what information is returned, independent of the data model, making it much more efficient for almost every use case than typical interface APIs. GraphQL query statements are natural to embed in programming or scripting languages, like Python, to further compare or analyze the extracted data, or format the results.
Now See the Demos
But, the best way to get a handle on how NQE works is to see a quick video we built that explains how it can be used inside our Forward Enterprise platform, how a sample query is built and how the information can be leveraged. Check out the short demo below:
A lengthier and more technically advanced use case was presented as part of Tech Field Day. Our lead NQE engineer, Andreas Voellmy, shows how we can compare BGP routes in downstream and upstream routers to confirm they were all exported correctly as advertised. This situation actually caused a severe outage at one of our service provider customers, so they wanted to be able to continually check for this scenario. To be able to programmatically verify this across an entire SP network, with many vendors, on a daily basis is a huge time saver and eliminates future errors for them now. Check out Andreas’ demo that replicates their use case here:
The feedback we’ve gotten since we introduced NQE has been universally positive, and not only from the Tech Field Day audience, like this comment from Bob Laliberte, Sr Analyst at ESG:
“For years organizations have been trying to extract value from the data available to them in large complex network environments. Unfortunately, manual efforts and inefficient collection and normalization procedures have held them back. Fortunately, Forward Networks has unlocked the ability to quickly, easily and programmatically convert network data into knowledge and actionable information leveraging its Network Query Engine feature.” - Bob Laliberte, ESG
Network IT engineers realize that NQE gives them a really accelerated approach to automate almost any of their network analysis and health status checks. Our platform provides many useful ways to analyze the network end-to-end, but NQE allows customers to query the collected and normalized data in thousands of ways and use cases that we didn’t design for.
A few final quick points to know:
We provide a lot more information and example code on our github repository, where we invite customers to share their code samples and feature requests.
NQE is currently part of our Forward Enterprise product and available now.
Our NQE data model takes inspiration from OpenConfig, and we have aligned with that data model where possible, although there is not a strict syntactical mapping. More details on our github repository.
Want to learn more or get a live demo? We’ll show you how NQE can help accelerate your networking tasks and processes in minutes.
What’s been the biggest change to networking in the past decade? While there have been tremendous improvements in automation, capacity and mobility, nothing has had a greater impact on IT organizations than cloud migration. We all know the business drivers behind this evolution, from cost efficiency and resource elasticity, to backup and disaster recovery. But there are still concerns and hurdles in migrating a vast majority of mission critical workloads and traffic to the cloud.
The biggest challenges have to do with loss of control and visibility; of data, network policies and security. Cloud platforms are easy to spin up and are architected to be pretty generic in nature for simplicity and flexibility. But to network engineers, they tend to look like black boxes, where the activity and outputs are clear, but you don’t have the same visibility to network policy details as on-prem infrastructure. Ultimately, this can lead to potential security breaches and data loss, or resistance to migrate to the public cloud.
Simplicity as a Trade-off for Visibility and Control
The Console Wizard for AWS Virtual Private Cloud (VPC), for example, is a very straightforward, streamlined tool for setting up a sophisticated hosted private network. It allows IT teams to design dedicated subnets with security policies, load balancers and routing protocols to front-end application workloads. But, it does not provide the visibility and control of end-to-end paths or the ability to analyze and verify traffic patterns and security controls that network and compliance teams require. Even basic tools, like traceroute, through an AWS VPC, is not available. Not to mention more stringent tests for network isolation, sophisticated access controls, NAT rules, routing behavior, or VPN policies. Trying to determine actual network and security policies from the AWS console is frequently an exercise in futility.
This contrast between on-premises networks and cloud is even more acute in hybrid cloud deployments. For application networks and traffic that span on-prem and cloud infrastructure, why do we have to lose visibility to our infrastructure at the gateway to our provider? This is where Forward Networks comes in.
Forward Networks for Hybrid Cloud
Forward Networks has pioneered the ability to verify the end-to-end behavior of networks and then compare that behavior to defined intent, security policies and compliance requirements. We can quickly verify all possible paths through a network that comply with a policy or network intent, or we can confirm the proper isolation (lack of access) between subnets and devices. We shift focus from individual box-by-box testing to analyzing paths through the network end-to-end and the policy behaviors they allow. This moves network troubleshooting from a reactive (after the fact) activity, to a proactive, error isolation and removal (before an incident) methodology for the first time.
The path-oriented focus that Forward Networks provides is only natural to now extend to hybrid cloud environments. Having the same visibility and policy verification for the cloud component of your infrastructure will greatly accelerate adoption of hybrid and public cloud deployments and simplify network operations. We are starting with AWS VPC support, which is now available in our latest Forward Enterprise release.
Amazon Virtual Private Clouds are implemented as subnets within AWS with virtual network devices such as load balancers, routing tables, security policy groups, access control lists, NAT gateways, VPN gateways and access layer switches that interface to each EC2 virtual workload. Imagine if instead of a “black box” subnet view, each of these virtual devices could be represented as an extension of your physical infrastructure on an always up-to-date topology diagram. And not only having easy access to individual device configurations and state details, but to analyze and verify the end-to-end path behaviors flowing from any on-premises device all the way through to any cloud edge switch and application workload.
Forward Enterprise supports connectivity to AWS through VPN connections (AWS Virtual Private Gateway – VPG), direct connect through VLAN encapsulation or through public internet. Ensuring proper VPN security posture and connectivity is critical for security conscious organizations that are hesitant to migrate. And that’s just one of many security and policy checks that we can enable for the first time.
Now the Cloud Includes Industry-Leading Verification and Compliance
What kind of policy checks and behaviors are we talking about for a hybrid cloud? Forward Enterprise can verify that only a specific port from on-premises devices can reach the public cloud. Or verify that there is complete network isolation from the public cloud to any on-premises subnet or device. If you are familiar with Forward Enterprise search and verify capabilities, you know that the policy checks are almost limitless when you take into account all the IP networking attributes and parameters that can be designed into search queries.
Moving this level of visibility to individual public cloud virtual devices and subnets promises to alleviate many of the compliance concerns for public cloud adoption. A primary use case for AWS VPC visibility, in fact, is to verify the accurate implementation of business and security policies pre- and post-migration when migrating services to the cloud. Forward Enterprise can verify policy requirements are met consistently in the cloud as when completely on-premises. With no guessing, risk or roll-back.
The end result will be a dramatically new method for viewing, analyzing and controlling AWS-deployed services, consistent with the superior path-based analysis Forward Networks has already achieved with on-premises networks. IT organizations will finally be able to combine elasticity and efficiency of the public cloud with complete confidence and control.
Want to learn more? Reach out to us or watch our video demo:
On October 31, 2018, Cisco released a security advisory for its ASA and Firepower threat defense software regarding a Denial of Service (DoS) vulnerability. The full security advisory can be foundhere. The summary (below) notes that the Session Initiation Protocol (SIP) inspection engine could allow a remote attacker to trigger high CPU usage resulting in a DoS condition.
A bug with no fix?
Even more unsettling, the advisory notes that there is no software update available for this vulnerability, nor are mitigation options available. That’s basically technical jargon for, “if you have Cisco firewalls, you could be screwed, and we can’t help you”.
Are you impacted? Are you particularly vulnerable to external traffic from potential attackers? How extensive is your vulnerability? How can you quickly identify all the affected devices and prioritize remediation based on where traffic could be coming from? How quickly can you test a possible fix and verify that it will work?
In this blog post, we’ll show a new way to answer all these questions and identify all points of vulnerability - in only minutes. We’ll employ Forward Enterprise, an intent-based verification platform that can quickly identify all paths through your enterprise network that conform to certain high-level criteria. It can also verify if proposed changes affect desired policies or address known issues (like outside traffic reaching Cisco firewalls using SIP protocol).
Where can the traffic go?
Let’s take a look at how you can check a network in Forward Enterprise. First, you might want to quickly query your network design to see which sections of the network are affected by Cisco ASA traffic. In our system, and as shown below, we would build a modular query that asks where any traffic using SIP protocol enters an ASA device:
The results of this query show the portion of the network where traffic can flow through a pair of Cisco ASA appliances, along with all edge destinations that can be reached. The unaffected portion of the network is shown in lighter gray. From this result, we know that the immediate problem is restricted to one data center only, and such traffic can’t reach the MPLS backbone or other sites. Reasonably good news at first glance.
Unfortunately, this portion of the network is behind an internet gateway. Our next issue is to determine if external traffic can reach our suspect devices and if so, how to design a fix. A slightly more specific query will ask if traffic from the internet gateway can reach any of our ASA appliances. Notice that we have essentially changed “from anywhere” in our query to “from atl-internet”, which is the name of our gateway.
The result now shows that, indeed, external traffic can reach one of the two ASA edge firewalls, and also reveals that external SIP protocol traffic will be dropped at that point. We know this because no paths are shown southbound from this device, as well as the dashboard showing that all paths result in drops. But knowing that all SIP traffic is dropped at the ASA device does not necessarily solve our problem. This is a DoS attack, which could take down the device and affect legitimate traffic from reaching destination servers.
Determining a fix...
Fortunately, we see an excellent solution from our Forward Enterprise analysis. We can reconfigure the atl-isp-edge01 router to block SIP traffic, since that is the only viable route to our vulnerable device. The firewall edge-fw02 is a back-up, currently unaffected for external traffic. Dropping SIP traffic at edge01 would be a priority to circumvent the DoS attack immediately, but the back-up firewall should be addressed as well for when it came online.
But, it gets better still. We could actually evaluate a potential configuration change in our system and verify that: 1) it prevents SIP traffic reaching the ASA appliances, and 2) no other policies would be violated as a result of this quick change. In fact, we can even ensure that if any future change breaks this policy, we’ll be notified immediately.
Forward Networks provides an ideal platform to quickly query and search large enterprise networks to view possible paths that conform to certain criteria or policies, such as in this scenario, going through any vulnerable Cisco ASA appliance. We provide a way to refine queries around specific policies or scenarios, such as isolating traffic from a particular source, like the external gateway. Or we can identify which applications and subnets could be subsequently affected. Finally, we have a way to quickly determine and prioritize points of remediation and verify how those changes would affect overall network policies.
Want to learn more?Contact us for a quick demo and we can show you how we can quickly determine your level of vulnerability to this new security advisory and a whole lot more! Or, check out some of our latest demo videos on our YouTube channel:
In tech terms, a diff is a listing of changes or differences between documents, files, source code, etc. As a Unix command, it became a common method of distributing patches and source updates, or just comparing versions of text files. Diffs became so easy to do and use, and common to so many use cases, it’s always fun to imagine how you could apply them to more than just text files and documents.
What if you could diff yourself now to five years ago? Probably the changes would be too numerous and impractical to list (and, hopefully, most would be for the better!). Well, we probably don’t have the tools to fully diff a person quite yet. But, what if we could diff your entire network! Sure, diffs can compare two device config files side-by-side. But I’m talking about the entire network! Between any two points in time. As if you had running side-by-side two different versions of your network that you could watch end-to-end, analyzing all behaviors and activity, and could quickly note any differences in one intuitive dashboard. Yes, I’m saying let’s clone that enterprise data center from 6-months ago and run it side-by-side to today’s and see all the behaviors and policy changes in our network. Would that be helpful?
Imagine the possibilities! You think you could address some of the compliance team’s concerns a little quicker? What if rogue IT had installed a few extra devices or access points in the last few months and they stuck out like sore thumbs in the diffs dashboard? What if you started having intermittent network performance issues that you first noticed three weeks ago, and you wanted to roll-back or study all changes and their potential impact on network capabilities over the last, say, six weeks.
And I’m not just talking about diffing the text of the configuration files or packet captures. I’m talking about diffing the behavior of the network. Like if we diffed the behavior of my teenagers today and three years ago: they eat more, spend more money, and clean their room less. The network behavior diffs could be a very long list like: 1) these two subnets that were isolated are now reachable through a firewall, 2) there is now only one active path between a particular source and destination address where before there were redundant paths, 3) traffic that could be delivered from the internet to the web application server is now delivered via HTTPS and SSH, where only HTTPS was available before.
This is exactly what Forward Networks is able to achieve in our latest Forward Enterprise feature we call Behavior Diffs. Behavior Diffs provides network engineers with a powerful tool to compare network behavior and designs between any two points in time. Users can now compare network policies, behaviors and security posture to a prior state before any issues occurred to quickly determine where errors could have been introduced and how to remove them. This takes diagnostics and troubleshooting to a new level since users now have virtually unlimited documentation of prior network changes and their impact on network behavior to guide analysis and problem resolution, or just to prove historical compliance to key policy requirements.
As most followers of Forward Networks know, Forward Networks has developed a next-generation platform for analyzing network behavior and verifying network implementations. It is the first highly scalable, multi-vendor, layer 2-4 verification solution based on a behaviorally-accurate software model of the network. By analyzing the configurations and state information of the network’s devices, rather than real-time packet analysis, Forward Enterprise can identify if policy violations could occur under any scenario or set of conditions, what would trigger them, and how to proactively fix them before they happen.
And that’s exactly what we are doing with Behavior Diffs: comparing snapshots of two network points in time in our software model, running side-by-side, and highlighting the behavior and policy differences. We can resurrect that 6-month old data center snapshot and run it in all of its behavioral glory, long after you’ve been pulling cables and adding new devices. Want some examples? Let’s look at a screen shot of our behavior checks and see some policy changes we should probably know about.
In the above screen capture, we see a list of network behaviors or policy requirements that we are checking for and their passing/failing status in two different snapshots (“Before” and “After”). While we see two policies that are now passing in today’s model, our maintenance update has apparently broken one policy that was passing before. That policy essentially requires that all traffic from the Internet to our app servers only use HTTPS, and some other protocols are apparently now allowed through. In our analysis and remediation platform we can quickly drill down and analyze the source of that behavior to guide the repair.
Across the top of the above screenshot you can get a flavor for what other network attributes we get in our diff analysis. Such as changes in topology, devices additions, routing paths, VLANs, ACLs, and, yes, text of configuration files on all changed devices. We have some more good examples and screen shots on our Behavior Diff web page, and we have a brief demo overview video available here and on our YouTube channel.
Behavior Diffs is now available in our latest 2.18 release of Forward Enterprise. It is such a novel and powerful capability that we are excited to see the many different use cases and workflows that our customers will use it for. How do you think it could make your IT life a bit easier and more productive?
The great panacea for network IT the last several years has been more and more automation. Automation through orchestration. Simplifying and accelerating network administration tasks at the scale of large enterprise and cloud networks. Automation to keep up with the accelerated deployment of virtual applications, workload mobility and virtual networks. But if everything is happening so fast, and change is constant, can we keep the same degree of accuracy and assurance in our network and security deployments?
Automating complex network configuration processes is a great way to propagate errors at warp speed to all corners of your data center. Orchestration platforms can be great tools in the right hands, but small errors have a way of doing greater damage in profound ways. Like a power chain saw can do more damage with the slightest miscalculation. What's needed is to couple orchestration platforms with rapidly emerging network verification technology. Network verification can now be completely automated, so you aren't introducing additional manual processes to slow down your orchestration. But you can verify that everything is accurate and deployed correctly at light speed.
But what is network verification? If you've been following Forward Networks to get this far, you probably know already. Verification is much closer to an automated audit process than traditional tests that look at live traffic, log files, sniffers or port analyzers. It is a much more thorough analysis of the entire network end-to-end based on identifying theoretical sets of packets that could potentially breach stated policies. The analysis is based on a behaviorally-accurate mathematical model of your large network that can be queried for policy compliance and end-to-end behavior. You define the policy checks you need to have in place, and the platform verifies whether the current network configurations deviate from any of the policies. In minutes or less.
How would this work in practice? We just recorded a great 30-minute webinar and demo that gives a great example of this scenario in action. In the following presentation, we show how Forward Enterprise, our verification and network assurance platform, can be integrated with Cisco Network Services Orchestrator (NSO, formerly Tail-f), a leading automation platform. In this short video, you can see how Forward Networks:
can seamlessly verify correctness of changes after an NSO update to firewalls and network devices,
can verify both automated and manual changes,
hallows you to build a repository of policy requirements to automate future verifications, and
allows admins to compare behavioral differences across snapshots in time to isolate configuration errors.
A new feature in Forward Enterprise now allows customers to simplify the analysis of network access issues between the network and security teams. We call this feature ACL-less analysis, or permit-all mode. First some context why multiple customers asked us to develop this feature, and the use case benefits they are seeing.
Forward Enterprise allows customers to quickly drill down into network and security configuration issues to isolate and expose the root cause of policy violations and deviations from intended network behavior. For example, why is this destination unreachable? Why is server access from the WAN impeded? What is blocking traffic between two sites or subnets? Forward Enterprise allows you to compare end-to-end path behavior with desired policies rather than focusing on individual device configurations and box-by-box analysis the old-fashioned way. Overall, this greatly accelerates Mean-Time-To-Repair (MTTR) and increases operational efficiency for IT teams.
When dealing with uncertain root-cause across large networks, many organizations are challenged to bridge the silos between network and security teams. It’s only natural. Visibility to both policies and implementations between two large technical organizations is rarely complete. It’s easy to start with a reasonable amount of finger-pointing. And when dealing with a connectivity or accessibility issues, sometimes it’s the network devices and topology, and sometimes it’s an unintended consequence of a security policy or access control issue.
When Forward Networks started putting our next-generation analytical tools and troubleshooting insights into the hands of large enterprise organizations, we uncovered some of these Layer 8 (political) problems ourselves. Several of our customers that have distinct network and security policy teams subsequently asked us to provide capability in our system to separate root-cause analysis between networking configuration and Access Control List (ACL) rules.
The motivation was at least two-fold: 1) It provides an immediate way of isolating any access or connectivity issues to network devices or security rules, and 2) It clearly indicates which team should be addressing the problem and further refines where remediation should best be applied. This usually decreases the MTTI (Mean Time to Innocence) for the networking team as well as avoiding tedious work and delays trying to definitively prove the lack of existence of some uncertain error.
How does this work in practice? Starting with the Verify view in Forward Enterprise, where a user has defined a set of policies to validate, we see a single failed policy check for the existence of at least one path between two IP addresses in different data centers, through a specific firewall, with traffic delivered between the sites via an MPLS backbone.
Clicking on the “failed” link allows the user to explore the configuration issues associated with this policy failure. This brings up a new view as depicted in Figure 2. The failing policy statement is displayed in the top search bar, which we can refine or broaden to help analyze the situation further.
The result of a Forward Enterprise query statement is always the full set of network paths that meet the requirements of the query or search. In this case, as expected, we see “No results found”, because no such path exists. All traffic is being dropped in this scenario between the two IP addresses 10.117.170.01 and 10.110.57.34. And no paths are highlighted in our topology diagram, only the individual devices included in the query.
At this point we don’t know if this is a network connectivity error, or security policy issue. The new permit-all mode in Forward Enterprise allows users to determine this immediately. By clicking on “permit-all mode”, the platform runs the same analytical query bypassing all the ACL rules, to see if there is network reachability and if traffic would flow in the absence of any security enforcement.
For those not familiar with Forward Enterprise, our platform is based on a behaviorally-accurate software model of your live network. These types of hypothetical analysis are very easy in our system, and never impact the live network where you can’t turn-off security enforcement just for the sake of analysis and testing. Checking the expected behavior of future traffic under any hypothetical change or scenario is one of many ways we aid in the analysis and troubleshooting of network and security issues.
In Figure 3, we see the top search updated with permit all, and now we are seeing that, indeed that are many (128) possible paths between these systems, due to the several pairs of redundant devices at most hops in the network. We are highlighting one path through the network, and focusing on an initial access layer switch that enforces ACLs.
We have highlighted in the hop details how the deny here, which is being applied to all packets, is being ignored, and the policy violation is not a network connectivity configuration issue after all. At this point, we can refer the ticket to the security team or administrator responsible for this particular device for further analysis or remediation. A key policy alert was detected, isolated and handed off to the responsible team in only a few clicks.
Another ACL-less scenario would be an application team wanting to know if the current network configuration supported access to a requested server. The current security policy would likely not support this policy a priori, but a key first step would be to know what network connectivity would allow in the absence of security rules. ACL-less analysis ignores the firewalls and ACL rules and can either confirm or deny network support for the application team request. This scenario is detailed in the YouTube video below.
This new capability, referred to as ACL-less or permit all mode, is having increasing interest across our entire user base that have separate security and network teams. We are interested to learn how it might help your organization and your IT processes in dealing with trouble tickets and how it may help overcome any Layer 8 problems you may have.
For more information, check out our YouTube video or get a live demo of ACL-less mode and the rest of the features in Forward Enterprise.
In agile network operations, network configurations need to be updated to reflect new application or policy requirements, or to implement a change in network behavior. As business and application requirements change, we have to translate new policies into specific network configuration changes in one or more devices.
In Figure 1, we describe the workflow of rolling out a network update. From the current operational state of the network, we have to respond to a new intent or policy requirement with proposed configuration changes. The development of the change candidate by network engineers is reviewed by various teams and architects, including security. These design reviews can be tedious and manual, and may highlight additional changes or corrections to minimize the impact on existing infrastructure.
Once the candidate change has been approved, it moves into the network lab for testing. But this step can usually only provide cursory testing because the lab network is not running at the scale of the production network, nor can the proposed change be evaluated under all scenarios and conditions that will actually arise over time. In order to improve network agility, testing has to be short and efficient, but this also increases risk and potential for issues post-deployment. After the proposed update has completed the test scenarios, it is pushed to a configuration repository and scheduled for deployment.
Accelerating Change Windows and NetOps with Forward Networks
How can we accelerate the above workflow to increase network agility and reliability, and better align network teams with DevOps processes? Forward Networks has developed the industry-leading solution for analyzing network behavior and verifying configurations in a software model of the network. This allows for rapid evaluation and verification of proposed changes outside the live network, and can automate many of the lengthy review and testing processes.
Automating the Verification Process
Network verification provides assurance that proposed changes accurately implement all of the defined network policies. Rather than looking at live traffic and reporting on current activity, verification proactively analyzes the network configuration files to build a behaviorally accurate software model, and then identifies scenarios under which the current implementation could fail to meet policy objectives. In Figure 2, we see how various features of the Forward Enterprise solution, our flagship product, can automate and improve our earlier workflow.
For example, the initial change of policy or intent can be defined in Forward Enterprise as a policy rule or check. That policy rule would be verified against future network implementations and any configurations that would violate that rule would be immediately flagged (as in Figure 4). The new intent rule would be added to the overall rule repository and verified along with all other rules as part of the pre- and post-change verification.
Network Analysis with Forward Search and API queries
Forward Enterprise is a large database of network configurations, state and behavior information from a series of individual snapshots in time. The software model of networking behavior simulates traffic behavior accurately and predicts which vulnerabilities or scenarios will cause policy violations. Like any database, the Forward Platform can be queried, with the behavior and policy results being displayed in an intuitive and interactive network map (see “API access” block in Figure 2 and Figure 3 below).
Similarly, candidate changes can be quickly peer reviewed automatically in Forward Enterprise (see “Acceptance Test” block in Figure 2). After an initial policy query, it becomes clear how network traffic paths will be affected by the new change (as shown in Figure 3). With the automated and more detailed review available from Forward Networks, networking teams can proceed towards deployment with greater confidence and less manually-intensive test scenarios.
Summary
In recent years, there has been a great deal of focus on network automation in order to increase IT agility and to better align network operations (NetOps) with accelerated DevOps processes. That focus has been mainly on accelerating network deployments and automating virtual network configurations to support new application requirements.
Forward Networks has now delivered a new platform that focuses on the automation of network design verification, network analysis and change processes. Network verification, a new methodology to analyze network designs and configuration changes, can both provide greater confidence by reducing network risk and preventing outages, as well as accelerating once-manual design, review and testing processes that slowed network agility and resulted in lengthy change windows.
Yesterday, Brandon Heller and I recorded a podcast with Ethan Banks and Greg Ferro of Packet Pushers fame. If you are not a fan of Packet Pusher Podcasts, you should be. They have a large following of highly technical network nerds and their podcasts are always engaging and educational. When they finish production on the podcast, I'll post a link here.
During the discussion, we talked about how Forward Networks can be a "single source of truth" for all things networking. Network admins are always looking for a single source of truth for the topology and implementation of the network in a digestible documentation source rather than trying to cobble it together when needed from individual devices. For many years Microsoft Visio has been the most frequently used tool to document network topology and connectivity, including IP addresses, etc. But the problem has always been that complex diagrams are hard to maintain and keep current, and there's no guarantee they reflect reality.
Ethan had a great line, that Visio is the "single source of the way the network looked at some point in time". Which was humorous and insightful enough that he tweeted it out. Then all sorts of hilarity ensued.
So, Visio may represent a somewhat archaic view of the network, maybe? Or maybe Visio as a topology mapping tool is somewhat of a relic? Finally, someone asks:
A Better Way
Well, as fans of Forward Networks know, that answer is a resounding "Yes!". In fact, if your primary interest is automatically maintaining an always-up-to-date topology diagram, with a centralized repository of configuration files and network state, then you only need our Free solution, Forward Essentials. It can collect all of your network data in minutes, builds a diagram, and you are ready to dive in and drill down on all your current network details, protocols, ports and plumbing.
Essentials can collect a new snapshot every day, or more frequently if desired, so you are automatically up to date. And Essentials doesn't merely generate a diagram. It's a very interactive, intuitive user interface that allows you to search, explore and drill down into the network to help research and document devices from every angle. A perfect training tool or a repository for compliance and audit data.
If you're interested in seeing a quick demo video, learning more, or a trial the free product, it all happens here.
In Part 1 of this blog, I discussed the power of network verification compared to traditional network testing. Verification is the mathematical and logical analysis of your current network configurations and state to detect and highlight violations of your policies and intent. Verification can take you from being "Pretty Sure" your network is configured correctly, to being "Absolutely Sure" your intent is represented in the network. This capability is delivered in Forward Enterprise, our full-featured platform designed for large enterprise and provider networks, including multi-site data centers, private clouds, corporate backbones and telco-class infrastructure.
It is important to note that Forward Enterprise is not a monitoring or performance management tool. In fact, it doesn’t look at live traffic. Forward Networks creates a software model based on a snapshot of the network, and can perform end-to-end analysis of the range of possible behaviors under all scenarios and conditions. It doesn’t test a packet going over the link, it will find the boundary conditions that you haven't thought to test for. That will allow you to head off problems before they occur. And help you avoid tedious weeks of box-by-box analysis and root cause research.
It all starts with collection and search...
Forward Enterprise builds a software model of your network after collecting all configuration and state information from each device. Much like Google crawls the Internet for new content and links between web sites, Forward crawls devices and organizes a snapshot of all network links and information. We even understand subtle behavior differences between specific networking or firewall vendors to ensure accurate analysis of traffic behavior in the live network. From the collection, Forward builds a complete inventory and topology diagram.
Most of our customers find this initial inventory and topology display immensely useful because it can identify devices you may have forgotten about, or are obviously not performing any productive function. For example, a device may be physically connected in the network, but misconfigured to not support any real traffic flows. Since all possible routes into and from each device are analyzed and displayed, it becomes immediately apparent where links are up, down, or have no potential traffic flows. But it gets much better when you can create sophisticated queries into the network model.
From search to verification
Forward Search is one of the three key functional pillars of Forward Enterprise, along with Verify and Predict. But each of the three capabilities allow you to develop extremely interesting behavioral queries about the intent and performance of the network. A simple search query could be structured such as "show all the inbound internet traffic paths reaching a rack of servers, or a particularly virtual switch, that don't use destination port 443". This might show vulnerabilities on non-SSL ports that your network might be allowing through. If that's possible, it's easy to trace flows through each device in the path that are misconfigured and how to remediate. Virtually any network attribute, protocol or device state can be queried to quickly isolate inconsistencies or violations of your network intent.
When you define your network intent as a series of network policy requirements, each requirement becomes essentially a search query and a check is performed. Again, any deviations from the pre-defined network intent are quickly identified and isolated. Forward Enterprise comes with several pre-defined policy checks, as shown below, including checking for forwarding loops, IP address uniqueness, consistency across all links for VLANs, MTU, speed, duplex-type, etc.
Forward also allows you to define your own policy requirements for your own network intent very easily. User-defined checks provide the ultimate flexibility to incorporate specifics of your network design and application requirements. In the example scenario below, we see the failure of the user-defined check for only SSL traffic being allowed to reach a set of web servers.
Whenever one of your intents fail, it’s not only easy to quickly drill down to the explicit scenario that violated the policy, but to analyze the individual device(s) that are misconfigured and to see the specific device configurations and states that generated the policy violations. As you make network changes and update potential errors, you can also immediately see on the dashboard if any new violations have been introduced and what overall impact any changes will have.
Forward Networks has introduced a powerful new weapon to be able to mathematically model and analyze the network in aggregate. Against live scenarios, as well as ones that are coming in the future. The ones you don’t know about. The ones you didn’t plan for. The ones you couldn’t test. That's the power of network verification. And understanding your network intent today is the first step towards intent-based networking.
Forward Enterprise can help reveal your network intent today, on any existing network, and to identify where configuration errors could be causing your problems now or in the future. It's non-intrusive, installs in minutes, and doesn't disrupt current operations. For a live demo and to see how it could model and analyze your network environment, sign up here.
Learn the modern way that companies stay off the front page
