Gigamon has a web interface called GigaSMART that it uses to configure NetFlow on Gigamon devices. But GigaSMART can be limiting; through working with many Gigamon and Scrutinizer users, I’ve found that most users are far more comfortable configuring NetFlow through the command line. This blog will explain how to configure NetFlow for H Series Gigamon devices through the CLI.Read more
In Part 3 of the NetFlow Overview series, I will be discussing the NetFlow Template Flowset. In Part 1 I covered NetFlow basics, and then Scott addressed NetFlow Packet headers in Part 2 of this series.
The following definitions are taken from Cisco’s NetFlow Version 9 Flow-Record Format whitepaper.
Welcome to the first installment of our NetFlow v9 Overview, beginning (of course!) with NetFlow basics.
What is NetFlow?
A network flow is defined as a unidirectional sequence of packets between given source and destination endpoints. Traditional NetFlow uses a 7-tuple of source and destination IP address, transport layer port numbers, IP Protocol, Type of Service (ToS), and the input interface port to uniquely identify flows. Flexible NetFlow (FNF) is a ground-up rewrite of NetFlow which allows the user to customize the NetFlow tuple to include (or exclude) a nearly infinite amount of different fields.
If you are looking for an agentless performance monitoring solution for Citrix Desktop Virtualization, consider using AppFlow or IPFIX exports from your Citrix NetScaler. AppFlow is the Citrix IPFIX export which is basically the proposed standard for NetFlow v9. Through IPFIX, Citrix is now exporting details on Applications, URLS, browser types, user details and more.
As network administrators are looking to use NetFlow for more visibility on their network, they often have to decide what NetFlow version they need enabled on routers/switches. Several times, these past few weeks, I was asked the difference between NetFlow v5 and v9. That is why in this blog, I intend to give you just enough information to make your choice between the two versions quick and easy, especially if you are using our NetFlow and sFlow Analyzer. Read more
Today I want to talk, in a nutshell, about the advantages of NetFlow. One thing in particular that distinguishes NetFlow based traffic monitoring from the traditional SNMP dependent systems is the ability to characterize traffic applications and patterns. Knowing what the traffic is, who it is from, how and where it flows is critical for network performance and troubleshooting. For instance, it helps Network managers “determine where to apply QoS, optimize resource usage and it plays a vital role in network security to detect Denial-of-Service (DoS) attacks, network-propagated worms, and other undesirable network events.”
In planning, as I previously stated, NetFlow information ensures that resources are used adequately in support of organizational goals. Moreover, it facilitates solutions to many common network issues including: Read more
A customer called the other day regarding NetFlow collection and interface descriptions not matching the correct interface instance numbers. I’d seen this issue before and knew it was not related to the NetFlow configuration, but rather that the device in question was exporting the wrong interface information in the NetFlow packets.
Michael Patterson addressed this issue in his blog, “Messed Up Interface names in Scrutinizer” in February.
To summarize Michael’s blog, the device in question was including interface instance numbers from enterprise mibs in the NetFlow packets, and most NetFlow Traffic Analyzers get the interface descriptions from the standard MIB-2 ifIndex tables.