IT has two principal functions: create a network that satisfies the business needs of the company and then optimize that network. Unfortunately, the modern enterprise is buried under a myriad of network improvement projects that often do not get deployed.
NetFlow provides summarized network data that provides many benefits, like:
■ The ability to see network bottlenecks
■ Observe denial of service (DOS) attacks
■ Determine where to deploy quality of service (QOS) improvements
■ Manage resource utilization of network components
Flow data can be sent to performance monitoring and SIEM tools to help better manage the network. Some solutions use NetFlow data to optimize network QoS and user experience. Performance trending data can also be created to improve network management and monitoring functions.
While this technology has been available for years, many enterprises are reluctant to fully deploy it. This is for good reason. Turning on the NetFlow feature can increase CPU load by 10% or more. In addition, NetFlow must be programmed manually using a command line interface (CLI). NetFlow also has to be enabled across all of the network switches to get the full benefit. Therefore, the performance degradation and risk associated with this technology has been a barrier to deployment.
To activate NetFlow, each Layer 2 and Layer 3 network routing switch needs to have it turned on or proper statistics will not be captured. Each switch then acts as an event generator and sends data to a NetFlow collector for event correlation and interpretation. When activated, full NetFlow generation creates a significant load on the routing switches. One way around this is to deploy sampling, where the data flow is sampled only at certain intervals instead of sending a complete stream.
To create this network requires significant effort. In addition to programming each switch initially, there is more effort to update the switch programming on an ongoing basis as the network and NetFlow requirements change. This is especially bothersome if you have more than twenty switches in your network. Since each switch is an active component of the network, these programming changes are normally done during the maintenance window and typically require Change Board approval (which may only convene once per month). The reason for Change Board approval is because a mistake during the CLI programming process could inadvertently take the switch out of service, causing service disruption.
To eliminate service disruption risk, taps and a network packet broker (NPB) can be installed into the network. The use of taps are a one-time disruption to the network and are very safe, as they are passive devices. Once a tap is installed, an NPB can be connected to it without causing any service disruption.
A good NPB has built-in software that can be set up to generate NetFlow data from the network switches without sampling (i.e. at full line rate) and pass that data on to a collector, which is typically a performance monitoring tool. The NPB should also have the ability to deduplicate multiple versions of the same data. This will decrease the volume NetFlow generation, thereby decreasing the amount of NetFlow data generated and passed across the network.
In addition, some NPB vendors support add-on NetFlow data features such as: application type(s) in use identification (FTP, HTTP, HTTPS, Netflix, Hulu, etc.), geolocation of flow data, device type, browser type, and autonomous system information. This type of meta data gives you actionable information that allows you to optimize your network.
The following diagram illustrates an NPB serving as a NetFlow generator.
While NetFlow is a free feature on Cisco Layer 2 and 3 routing switches, use of the feature can create significant costs. When programming NetFlow directly on network switches, numerous parameters must be set up including: NetFlow feature enablement, the creation of each specific flow needed, the direction of flow capture, and where the data will be exported to. This all requires CLI for the programming interface.
A good NPB will use a graphical user interface (GUI) instead of CLI. The GUI is simple and intuitive to use. No heavy programming is needed, it is all drag and drop. In addition, no maintenance windows or Change Board approvals are needed, so changes can be made whenever needed and implemented immediately. This can dramatically reduce troubleshooting times and maintain a higher level of network performance. It is also especially important if changes are required for security related issues and data collection of suspicious network activity.
Without maintenance window slowdowns and the addition of a significantly faster programming interface, costs can be reduced. This is especially true when the CPU impacts to NetFlow programming on the Layer 2 and 3 routing switches are considered. Offloading the 10 to 20% performance hit to the NPB (which can process NetFlow at line rate without slowdowns) will also reduce cost and increase switch utilization for processing network traffic.
In the end, NetFlow is a great network switch feature to help with optimization. However, the feature must be turned on to be of benefit and the ongoing cost and effort to use it must also be addressed.
As enterprises work to implement or improve their observability practices, tool sprawl is a very real phenomenon ... Tool sprawl can and does happen all across the organization. In this post, though, we'll focus specifically on how and why observability efforts often result in tool sprawl, some of the possible negative consequences of that sprawl, and we'll offer some advice on how to reduce or even avoid sprawl ...
As companies generate more data across their network footprints, they need network observability tools to help find meaning in that data for better decision-making and problem solving. It seems many companies believe that adding more tools leads to better and faster insights ... And yet, observability tools aren't meeting many companies' needs. In fact, adding more tools introduces new challenges ...
Driven by the need to create scalable, faster, and more agile systems, businesses are adopting cloud native approaches. But cloud native environments also come with an explosion of data and complexity that makes it harder for businesses to detect and remediate issues before everything comes to a screeching halt. Observability, if done right, can make it easier to mitigate these challenges and remediate incidents before they become major customer-impacting problems ...
The spiraling cost of energy is forcing public cloud providers to raise their prices significantly. A recent report by Canalys predicted that public cloud prices will jump by around 20% in the US and more than 30% in Europe in 2023. These steep price increases will test the conventional wisdom that moving to the cloud is a cheap computing alternative ...
Despite strong interest over the past decade, the actual investment in DX has been recent. While 100% of enterprises are now engaged with DX in some way, most (77%) have begun their DX journey within the past two years. And most are early stage, with a fourth (24%) at the discussion stage and half (49%) currently transforming. Only 27% say they have finished their DX efforts ...