Introduction
I spent some time ago comparing packet traces to Cisco NetFlow using our network bandwidth monitoring tool ‘Scrutinizer’. I setup 3 scenarios where I captured the actual packets with Wireshark and captured the NetFlow datagrams with our NetFlow collector. In this 3 part series, the details from these three labs will be explained:
Hi there guys! Its Thursday afternoon and the snow is beginning to fall here in New England. I’ve heard talk about 1-2 ft worth of snow, but you know those weathermen…
But before we close shop here for the holiday weekend, I wanted to be sure and announce the release of a small patch that provides a few small fixes that we wanted to squeak in before the next big release.
To find the latest update for your favorite NetFlow traffic analysis tool, just clicky clicky on the link below:
And we at Plixer all hope you have safe and restful New Years!
-Nate
As much as I would like to see more companies switch over to IPv6 it isn’t going to happen overnight. Like anything involving an expensive migration process, you should ask yourself some questions.
When do businesses need to move to the new system and what are the advantages of switching over to IPv6? Why make the move? I don’t think you have to but, be aware that IPv6 use has grown by 300% over the past 2 years. Read more »
Many NetFlow Reporting applications claim to tell you who the top 10 bandwidth hogs are by displaying the top 10 or so hosts for a time period based on total amount of traffic sent or received. Yes, this is helpful but it can paint a distorted picture when it comes to network traffic analysis. What about Flow Volume? Read more »
Michael PattersonVirtual routing and forwarding (VRF) is a technology included in IP (Internet Protocol) network routers that allows multiple instances of a routing table to exist in a router and work simultaneously. This increases functionality by allowing network paths to be segmented without using multiple devices. Because traffic is automatically segregated, VRF also increases network security and can eliminate the need for encryption and authentication. Internet service providers (ISPs) often take advantage of VRF to create separate virtual private networks (VPNs) for customers; thus the technology is also referred to as VPN routing and forwarding. Read more »
Michael PattersonI decided at the last minute to go to Cisco Live. The long flight to San Francisco won’t be so bad on Virgin America as they provide Internet access the whole way. Nice!
If you happen to be meandering around the Moscone Convention Center, please stop by booth #1412 to see our live demonstration of Scrutinizer v7 for NetFlow Traffic Analysis. Have a great weekend.
I’m going strawberry picking with my girls. 
I’m doing some more work lately with Wireshark and Scrutinizer v7. I thought that the topic of egress vs. ingress might be interesting to some readers. NOTE: Egress is only available in Cisco NetFlow v9 and not NetFlow v5.
IPFIX or NetFlow v9?
In theory, ingress and egress should work the same in IPFIX, which is based on NetFlow v9, but they are certainly different. Although they are very similar, don’t let any company tell you they are exactly the same. Many collectors that work with NetFlow v9 will puke when they receive IPFIX. Scrutinizer handles both with ease. Nortel supports IPFIX, as does/did Avici, which is now Soapstone Networks, Inc. Other vendors, such as Adtran and Enterasys, support NetFlow v9.
One annoying area where IPFIX and NetFlow v9 differ is in the labeling of fields: NetFlow v9 has ‘IN_BYTES’ and IPFIX labels the same field ‘octetDeltaCount’. IPFIX probably renamed it because when talking about egress flows, IN_BYTES is sort of misleading.
Ingress vs. egress differences
NetFlow v9 Ingress is collected on traffic going into (i.e. inBound) an interface. This is how NetFlow v5 collects data. To figure out outBound traffic volume, ingress must be collected on all interfaces and the reporting software then displays outbound traffic. What goes in must go out, right? Ya, usually.
NetFlow v9 Egress is collected on traffic going out (i.e. outBound) of an interface. Generally, it is used in combination with Ingress, but it doesn’t have to be. I’ll dive into this a bit more.
Why collect with egress?
Why collect with egress, if ingress worked so well with NetFlow v5? Because hardware such as WAN optimizers compress data. Traffic compression with Cisco NetFlow means that what comes in 100 bytes might go out as 50 bytes. If only using ingress flows, the NetFlow reporting software will show 100 bytes outbound, even if it was compressed to 50 bytes. GASP!!! This is because it was calculated using ingress flows.
Tell me the truth!
If the router is exporting both ingress and egress and the NetFlow monitor can report on both without overstating utilization, you can see how much of each flow is being compressed. It’s pretty slick, but it requires that the NetFlow collector understand what is known as the flow “Direction”. If the field in the NetFlow v9 packet is a 0, then it is an ingress collected flow. If the field is a 1, then it is an egress collected flow.
Ingress Flow with IPv6 (the same with IPv4)
Egress Flow with IPv6 (the same with IPv4)
The network traffic reports produced by the NetFlow analyzer need to be intelligent when dealing with ingress and egress flows. I feel that dynamically figuring out flow direction in mixed NetFlow v9 ingress egress environments is crucial, especially if the customer has hundreds of routers. If you are just setting up ingress, I would keep this blog in mind: “ip route-cache flow or ip flow ingress… Which do I use?”
Something else to think about
NetFlow traffic analysis is going to be taken to another level as Flexible NetFlow matures. Perhaps we’ll see it take advantage of what NetFlow v9 calls ‘OUT_BYTES’. (IPFIX, needing to be different, calls this same field ‘postOctetDeltaCount’.)
Now you might ask: how is it related to ingress or egress? Stay tuned…
Michael Patterson
