Just like any other client-server operation, in order for NetFlow to function, the client (router) must connect to the server (NTOP) to send the flow information it is gathering. This is done via a network connection using regular IP communication. Such communication must take place from one of the IP addresses of the router. The ip flow-export source FastEthernet 0/0 command on the router will simply tell the device from which port (and IP address) the updates will be sent to the NTOP server. If this command is not used, Netflow will simply choose one of the IP addresses from which the communication will take place.
Next, you must configure on which ports Netflow will âcaptureâ flow data. You can capture flows on any port of the device, and you can configure as many interfaces as you like as well. This information will be captured and sent to the NTOP server.
So, in the first case, you configure the communication with the NTOP server, in the second, you indicate on which ports the flows will be tracked.
Interesting topic but unfortunately this article only skims the surface. Just following the couple of commands provided did not do me much good on 6500. Trying to look around for some bits and pieces revealed there is a whole bunch of other commands, starting with âmls flowâ, etc., to be able to collect some data. So to be able to meaningfully use this feature and indeed understand what and how to collect it would be really be helpful to dedicate couple of articles to it, answering questions like can we collect data on the L2 interfaces (even on L3 switches if the only option is to enable it on SVI routed interfaces it loads obviously a lot of traffic one does not need); what indeed we are configuring with first 'mls⌠â commands and then separately (?) âip flow-exportâ (in my case I did not even see any data till âmlsâŚâ commands were executed); what type of data we can actually see - only âperformanceâ related, like number of packets, of maybe something more useful, like port numbers the flows are using; what is âaggregationâ feature; what are default settings, etc. There is seems to be quite a bit of info needed in order for this feature indeed be useful in real world.
Thanks so much for the feedback! Itâs always useful to hear what our users think about our lessons. As always, you can make suggestions for additions at the Member Ideas page shown below. There you can make your suggestions âofficialâ. You may find that others have expressed similar suggestions as well, so you can add your voice to their recommendations.
Iâm a bit confused about the output of show ip cache flow.
In your example, it looks like only ingress traffic is being recorded on the interface. Is that correct?
The confusion is because your explanation says âYou can also use the ip flow egress or ip flow ingress commands if you only want to enable it on one sub-interface or in one direction.â Which made me think it should be enabled as ingress and egress unless you specify one of those commands.
This is a good point you bring up. At first, I thought that the output shown in the lesson may simply be a partial output, and that is the reason for displaying only ingress traffic. However, looking deeper into the commands involved, I found out that the ip route-cache flow command enables NetFlow only in an ingress direction, according to this Cisco documentation.
The ip route-cache flow command has the same functionality as the ip flow ingress command, which is the preferred command for enabling NetFlow. If either the ip route-cache flow command or the ip flow ingress command is configured, both commands will appear in the output of the show running-config command.
So it seems that indeed, only the ingress traffic is tracked using the ip route-cahe flow command. If you want to capture egress traffic you must use the ip flow egress command.
I will ask @ReneMolenaar to confirm this and have him make the appropriate clarifications in the lesson.
Hi, Rene
Actually i was configuring net-flow on an interface to which already a net-flow monitor map was applied. Unfortunately i encountered an error pasted below. Your usual guidance is requested in this regard. Term duplicate is there (however different flow exporter, sampler and flow monitor was configured) for ipv4 record.
------------------------------------------ERROR-------------------------------------------
flow ipv4 monitor NimbusMonitorV4 sampler NimbusSampler ingress
!!% 'nfma' detected the 'warning' condition 'Attempt to apply a duplicate flow monitor to the interface'
Hi,
If I setup netflow first without sending the data to a netflow monitor and the data is stored locally is there a danger that this can eat up the memory of the router\switch ? and is there anywhere you can set the maximum amount of memory it could use ?
As netflow is per flow is there a way and do I need to pick a different port number when sending the flow to a monitor if I am monitoring several different ports on the same switch ?
Like if I had two separate switches and I was monitoring a port on each obviously I would have to setup a different netflow port number for each port that Iâm monitoring for example I could say Switch 1 Gi0/1 = port 9738 and Switch 2 Gi0/23 = port 9645 so the monitor could tell the difference but is there a way to differentiate like this on a single switch if I wanted to monitor several different ports then is there a way I can set each port up with a different udp port of each flow that I am sending to the monitor so they donât get mixed up together ?
Thanks
Netflow has been designed to capture flow data and send it to an external device for further analysis and visualization. I donât believe that there is any way that you can store the data locally and view it from the CLI in some way. As you mention, devices have a local cache where information is temporarily stored before being sent to the external NetFlow monitor. The size of this cache can be adjusted using cache command. By default, the maximum number of entries is 4096. More info on this command can be found here: https://www.cisco.com/c/en/us/td/docs/ios/fnetflow/command/reference/fnf_book/fnf_01.html#wp1324612
As for your question about ports, there is no mapping of transport layer ports to physical switch ports. You can use the following single command to set up the exporting of data to the external monitor:
The final number of 2055 is the default UDP port that is used by NetFlow. All NetFlow information is sent there. You would use the same port even if you are setting up multiple devices to be monitored by the same server.
In order to track flows on specific interfaces, you simply issue the ip route-cache flow command on the interfaces you want to monitor. NetFlow will keep track of all flows and send them appropriately to the monitor. All tracking of flows is managed internally by NetFlow itself.
Netflow does indeed use up CPU and memory resources. Whether or not you can use it on the main outgoing interface depends on various factors.
The platform you are using. Devices with more memory and CPU will be able to handle larger demands on their resources.
The amount of traffic. The more traffic on the main interface, the greater the load of NetFlow. Obviously, you will have a huge difference in demand if your enterprise consists of 10 hosts or 1000 hosts.
The number of active flows. Remember that Netflow examines flows. The number of flows in a particular network depends more upon the nature of the traffic rather than the number of hosts producing the traffic.
You must take all of these factors into account in order to determine the impact on the resources of your device. However, there is some documentation that is helpful in this process:
The second document is a bit old, but it is very comprehensive. The same principles are valid today.
Hello Laz ,
"For each of the flows, NetFlow will track the number of packets sent, bytes sent, packet sizes and more. "
does Netflow or CPM store in Cach flow and export the whole Packet or only the Metrics related to Flows ? what about EPC ( cisco embedded Packet Capture ) does also export all Data ? what is the difference between EPC and Netflow in Functionality and in purpose ?
Netflow does not export all of the packets of a particular flow to the flow collector. The Flow Exporter configured on the router will only send what are known as flow records. Flow records can contain a wide variety of information about the traffic in a given flow. This information includes:
Input and output interfaces
timestamps for the beginning and ending of a flow
the number of packets and bytes observed in a flow
Layer 3 header information including source and destination IP addresses, IP protocol and ToS values
Source and destination port numbers for TCP, UDP
Layer 3 routing information
and many othersâŚ
Using the show ip cache flow command as shown in the lesson, shows you the list of flows. Within that list, you can see some flows have 1 packet, others have dozens of packets, but even if a flow has dozens of packets, it is only one record that contains all of the info for that flow.
A router that has been configured for NetFlow will have a local cache where these flow records are kept. You can take a look at this NetworkLessons Note about the cache size, its default, and how to change it.
EPC differs from NetFlow in that EPC collects all packets and stores them locally on the router in a capture buffer. EPC is typically used sparing and for very short periods of time for specific troubleshooting scenarios because of the limited storage space on network devices. Once complete, the packet capture is saved as a .pcap file that can be either viewed in a limited fashion on the device itself or exported to be viewed and analyzed on a packet analyzer like Wireshark.
EPC and NetFlow are two very different tools that are used in very different ways. From the EPC you can glean the same kind of information as you do from NetFlow, with the appropriate analysis, but only for small periods of time. NetFlow is designed for 24/7 monitoring and analysis.
Deploying Netflow monitoring on an SVI has several pros and cons compared to a physical interface.
If you deploy it on an SVI, you can monitor and analyze the aggregated traffic from multiple physical interfaces associated with the same VLAN.
NetFlow on an SVI can also monitor and analyze traffic flowing between different VLANs, which is useful for understanding communication patterns between subnets.
By configuring NetFlow on an SVI, you reduce the number of NetFlow instances needed, since you need only one instance per VLAN rather than one instance per interface, thus you use fewer resources.
However, NetFlow on an SVI will only monitor traffic that is destined to or comes from other subnets. You wonât be able to monitor traffic within the VLAN itself, since such traffic would go directly between hosts and would not traverse the SVI.
If you apply NetFlow to physical interfaces, then:
You have more visibility to traffic that goes between hosts on the same VLAN
This becomes more resource intensive and complex since you have more NetFlow configurations to perform and more NetFlow sessions (one per configured physical interface), making it less scalable and more challenging to manage.
I have been studying NetFlow, and applying it on labs, and I have ran into a few questions.
There are two theories, for the goal to capture a hop by hop view in the network.
First of all, I just want to clarify your terminology. Northbound usually refers to traffic going toward the core of the network, while Southbound usually refers to traffic going toward the edge of the network. Your network, however is flat, unless you consider the routers as the core and the switches as the edge. Iâm going to assume that that is the case.
That means that the northbound interfaces are the interfaces of the link between the routers, while the southbound interfaces are those connected to the switches.
This option obviously gives you a more complete picture of the traffic entering and exiting the core of the network and of traffic flow through the central points of the network. Also, the fact that youâre capturing egress traffic helps in understanding the exit path of traffic which can be critical in analyzing traffic patterns and anomalies.
However, this could generate a large amount of data which will require substantial storage and processing power to analyze. It may also impact the performance of your network devices due to the extra processing they will need to do to capture NetFlow data. There may also be considerable duplicate flow records since the ingress flow record on one interface will be the same with an egress flow record on another.
This option will capture less data. Thus you will need less storage and analyzing power, and it will eliminate the duplicate records and will have less of an impact on network device performance. However, you may lose some critical information about traffic exit paths.
I hope that gives you a better understanding of the advantages and disadvantages of each NetFlow design choice.
