Call Us:1.800.561.4019
In part 1 of this blog, I mentioned that our customers often ask the question “What can really be done to improve network visibility?” I answered the question with regards to data and packet conditioning. In the 2nd part of this discussion, I’ll continue to answer the question with a second set of features that will deliver even more verifiable benefits to improve network visibility.
I’ll provide you an in-depth view of features that will deliver true benefits. There are 5 fundamental feature sets that we’ll cover:
When combined, these capabilities can “supercharge” your network. This is because the five categories of monitoring functionality work together to create a coherent group of features that can – and will – lift the veil of complexity. These feature sets need to be integrated, yet modular, so you can deploy them to attack the complexity. This will allow you to deliver the right data to your monitoring and security tools and ultimately solve your business problems.
Advanced packet filtering is one of the primary components (i.e., part of the secret sauce) which demonstrably improves visibility within the data network. While many monitoring switch vendors have filtering, very few can perform the advanced filtering that adds real value for businesses.
But what do we mean by “advanced filtering?” Advanced filtering includes the ability to filter packets across the anywhere it’s needed, using very granular criteria. Most monitoring switches just filter on the ingress and egress data streams. Only a few, like the Ixia Anue Net Tool Optimizer (NTO), can filter in between those two points as well. Filtering rules can be simple when you only have one or two monitor tools you need to send data to. But once the number of ports you need starts to increase, the number of filters increase and the potential for filters to overlap and prevent critical data from reaching the right tools. It takes time and money for the IT staff to write and maintain filter rules as the network changes. With the NTO filtering rule engine, all the filtering complexity is taken care for the NTO administrator and the IT department can focus on their value-add tasks such as resolving network problems and adding new capabilities to the network requested by the business.
Advanced packet filtering will usually incorporate the following components:
Let’s take a deeper look into each one of these components of filtering to see what it really does.
Basic packet filtering consists of either filtering the packets as they enter or leave the monitoring switch. Filtering at the ingress will restrict the flow of data (and information) from that point on. This is most often the worse place to filter, as tools and functionality downstream from this point will never have access to that deleted data. However, ingress filtering is commonly used to limit the amount of data on the network that is passed on to your tool farm and/or for very security sensitive applications that wish to filter non-trusted information as early as possible.
Egress filters are primarily meant for fine tuning of data packets sent to the tool farm. If IT tries to use these for the primary filtering functionality, they can easily run into an overload situation where the egress port is overloaded and packets are dropped.
Filtering can happen at three different points within a monitoring switch. Filtering at the ingress is called the 1st stage. Filtering at the egress is the 2nd stage. Filtering in between the ingress and egress would be called a 3rd stage of filtering. This 3-stage filtering capability, also called “dynamic filtering,” is a key aspect of advanced filtering. This type of filtering allows IT the capability to really take advantage of data flowing in from SPAN and TAP ports. The data can be segmented at a very granular level and then parsed out to individual or groups of monitoring and security tools across the LAN.
Dynamic filters are similar to that of ingress and egress filters except that the dynamic filter is located (and processed) in the middle, between the ingress and egress port filters. If dynamic filtering is used, the ingress filter can be left wide open so that the dynamic filters can segment and then aggregate packets from multiple ports and then send those packets on to the appropriate tool.
Any decent monitoring switch will allow users to save the filters they have created to a filter library so that they can be reused in the future. The filter library can also be pre-built by the IT organization for access whenever necessary without requiring knowledge of detailed filter criteria, addressing, or specifics surrounding a scenario. This library is perfect for a junior engineer or third-shift staff because they don’t need detailed knowledge of how to program a filter within a monitoring switch. The engineer can simply pull up a filter from the library and apply it with the graphical user interface to ingress and/or egress ports. This makes implanting filters quick and easy for the IT staff.
As simple as it is to create filters on-the-fly or from a filter library, pre-staged “floating” filters are another nifty tool. This ability allows users to create a dynamic filter, or filters, ahead of time and then pre-connect them to a tool port for on-demand analysis. The filters are typically pre-configured for a specific purpose, common condition, or some vulnerability – allowing Network Operations personnel super-fast troubleshooting capabilities.
Floating filters allows an administrator that is more experienced with the monitoring switch to pre-stage diagnostic filters, regulatory or industry compliance (such as PCI DSS verification) filters, or other filter types. An authorized user, maybe an IT person responsible for network security or some other aspect, can then access the Control Panel and easily connect an ingress port to the floating filter and begin the data stream flow to a SIEM or other tool as needed.
This primarily includes automation of functions to provide near instantaneous alerting and response when incidents arise and the ability for the system to automatically respond to those incidents with actions in real-time. Faster responses to problems result in a shorter mean time to diagnosis and a corresponding faster mean time to repair (MTTR).
A good monitoring switch will have an API capability built into it. When this is combined with scripting capability, the monitoring switch can react to network changes to deliver real-time responses to those network changes. For instance, automation scripts can be triggered in response to internal events (based upon some filter parameter or event monitoring parameter) or external events (such as SNMP traps, SNMP polls, Syslog, NMS events, SIEM events, or other software tool that supports TCL scripting).
More information on the Ixia Anue Net Tool Optimizer monitoring switch and advanced packet filtering within the Network Visibility Operating System (NVOS) 3.8 is available on the Ixia website and the Simple Is website.
Additional Resources:
Thanks to Ixia for the article.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
Comments