As a network administrator, it’s vital that you have complete visibility of your network in order to ensure it is secure and operating smoothly.
To achieve complete visibility, you need to ensure that the right traffic reaches the right tool, which is the main objective of the visibility layer. However, manually configuring your visibility layer to ensure you don’t have any blind spots can be an incredibly difficult task. Traditionally, these mapping configurations are semi-fixed and static. But what if there was an alternative to this process? What if you could make mapping configurations, regardless of complexity, dynamic and responsive?
Let’s take a quick look at the visibility layer, how it is structured and why mapping configurations can be complicated to implement.
The visibility layer is made up of a number of building blocks, including Network Packet Brokers, Bypass switches and Network taps. To ensure that the right traffic is sent to the right tool, we connect network traffic from routers and switches to the visibility layer, and designate them as ‘Source’; and connect the various Security, Performance Management and Monitoring tools to the visibility layer — and designate them as ‘Destination’. We then configure and map ‘sources’ to ‘destinations’, ensuring that each tool gets the traffic that it needs.
The mapping may involve complex traffic filtering and forwarding rules, in addition to ‘actions’ such as traffic VLAN tagging, MPLS stripping and load balancing — to name just a few. Even from a high level perspective, we can already get a glimpse into the complicated nature of the visibility layer with hundreds of network traffic links as ‘sources’ and dozens of tools as ‘destinations’.
Traditionally, these mapping configurations are semi-fixed and static. Changes to these mapping configurations only occur when they are updated or modified because network expansions were conducted, a new tool is added, or during maintenance periods.
The below figure depicts connected network packet brokers and bypass switches that form a single virtual visibility layer.
A network engineer can seamlessly configure a forwarding rule from a network data traffic source connected to one packet broker, through multiple "intermediate" connected packet brokers to a destination monitoring tool connected to a different packet broker.
This forwarding rule with its filtering and actions is termed as a FabricFlow.
But what if there was an alternative to this process? What if you could make mapping configurations, regardless of complexity, dynamic and responsive? This is a paradigm shift from a static to a dynamic visibility layer. Let’s deep-dive and explore some use cases and typical scenarios.
Your network security tool detects unusual traffic, which turns out to be a DDOS attack. The DDoS attack is identified by the security appliance, whether it’s a firewall or an intrusion detection system, and it is able to automatically notify, out-of-band, the Network Packet Broker (NPB) of the attack and the source of the attack. The NPB is then able to block this IP address while the traffic is active.
In this scenario, the you are effectively changing the mapping configuration so that the suspicious traffic flows are dynamically blocked until their flows terminate. They are then released once a new flow is re-initiated. The NPB will continue to perform deep packet inspection and block the attack traffic until a traffic analysis has been completed that confirms the DDoS attack is over. This entire process will all occur automatically, without the need for an administrator to identify the problem and trigger any rules.
Another possible scenario is dynamically forwarding traffic to different tools to perform traffic analysis. When a specific traffic event occurs, for example, Netflix traffic is identified, the traffic is redirected to a different ad-hoc specific tool for in-line traffic analysis processing. Such a scenario would simply not be possible without a dynamic and responsive visibility layer.
Lastly, let’s look at the modern visibility layer deployment that includes multiple connected packet brokers and bypass switch across multiple sites — forming a single virtual visibility layer. In this case the mapping configuration between a ‘source’ and a ‘destination’ tool also includes the need to configure intermediary connected NPB’s.
If one of the connected Packet Brokers goes down or if the connection is lost, in a static system, the mapping configuration would fail, taking the service down with it. It would also require a manual user intervention to reconfigure the fabric flows. However, with a dynamic and responsive virtual visibility layer, the system detects the failure and dynamically modifies the mapping configuration so that the service is always maintained.
In each of these use cases, dynamic fabric and open system visibility presents a paradigm shift in improved network security, easier configuration of fabric flows for traffic management, and better redundancy in the event of a link failure.
Now that we understand the future that a dynamic and responsive visibility layer can bring - how do you achieve a dynamic visibility layer?
Niagara Networks corms dynamic visibility layers by integrating SDN architecture directly into the visibility nodes, and combining it with a robust RESTful API so that external tools can integrate with the visibility nodes to provide timely, automated, “expert” inputs. This allows different devices from different manufacturers to communicate with the NPB (and with other visibility nodes), improved orchestration, and gives you the option of implementing advanced services through combined fabric mapping and applications.
Knowing the benefits that Dynamic Fabric and Open System Visibility can offer you, why remain static? Learn more what a dynamic responsive visibility can do for your services and network, and set up a consultation with a Niagara Networks visibility expert today.