Get started with Cisco ASDM 6.2
To setup the NetFlow export from your ASA which must be running version 8.2.1 or newer, bring up the Cisco ASDM (Adaptive Security Device Manager) and setup the NetFlow exporters:
Hey guys! I hope everyone is enjoying what they are seeing so far in our Scrutinizer v7 NetFlow collector release. I’m hearing a lot of good things from our existing customers, so I’m glad the hard work has paid off.
I’m sure you all noticed the huge changes that have occurred, whether it be IPv6, Flexible NetFlow or ASA NSEL support. With all of these new features, I wanted to remind you to watch the recently posted video tutorials to get comfortable with navigating the new product and finding the features you were looking for.
Here’s a great video that shows you how to create specific filters for your traffic. This new filter function has replaced the CUSTOM REPORTS option in v6. You’ll love it. Go ahead and take a look: Read more »
Scrutinizer v7 for NetFlow and sFlow analysis has been released. This new version of our network traffic analysis solution is 100% free. Plixer’s new model is to build a business around the modules:
This is part 3 of a series on the ToS field (i.e. Differentiated Services Field) of IP frames. I’m getting closer to how it relates to NetFlow and sFlow. Make sure you have already read Part 1 and Part 2 of this blog.
ToS part 3
In this blog I copy largely from RFC 2474, which was written in 1998. I discuss how 6 bits of the 8-bit ToS is now the Differentiated Services Code Point. See the screen capture below from my first blog. This is where we are today however, many of us still refer to this field as ToS (i.e. type of service). Sometimes it is called the Differentiated Services Field (DSF) but, not as often. Read more »
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 PattersonAre you struggling to setup NetFlow on your Cisco router or other vendor gear? We have a Web page dedicated to helping people find the commands to set up NetFlow, sFlow, IPFIX, JFlow, Netstream, etc. It is all ‘flow’ technology and we have run into all of them on most hardware. If you are interested, our software provides a NetFlow Configuration Wizard that I demonstrate here in this video:
Some of you may be interested in setting up Cisco NetFlow v9 with support for IPv6. Although Scrutinizer v6 does not support it, we are exploring it for our v7 release. Below I share a few commands for setting IPv6 up on our Cisco router. Please forgive me for replacing portions of the IP addresses with X.X.
NetFlow and IPv6 setup commands on a Cisco Router:
!
!
interface FastEthernet0/0
ip address 172.X.X.1 255.255.0.0
duplex auto
speed auto
ipv6 address 2001:DB8:BEAC:1::10/64
ipv6 enable
ipv6 flow ingress
ipv6 flow egress
!
interface FastEthernet0/1
ip address 192.168.X.X 255.255.0.0
duplex auto
speed auto
ipv6 address 2001:DB8:DEAD:BEAC:2::10/64
ipv6 enable
ipv6 flow ingress
ipv6 flow egress
!
ip default-gateway 172.16.X.X
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 172.16.X.X
ip route X.X.0.0 255.255.0.0 FastEthernet0/0
ip route X.X.0.0 255.255.0.0 FastEthernet0/1
!
ip flow-export destination 172.16.X.X 2055
!
ip http server
no ip http secure-server
!
snmp-server community XXXXXXX RO
snmp-server community XXXXXXX RW
ipv6 route 2001:DB8:BEAC::/64 FastEthernet0/0
ipv6 route 2001:DB8:DEAD:BEAC::/64 FastEthernet0/0
!
ipv6 flow-export template options export-stats
ipv6 flow-export template timeout-rate 2
ipv6 flow-export template refresh-rate 10
ipv6 flow-export destination 10.1.X.X 2055
ipv6 flow-aggregation cache protocol-port
cache timeout active 1
export version 9
export destination 172.16.X.X 2056
export destination 172.16.X.X 2056
enabled
!
ipv6 flow-aggregation cache source-prefix
export version 9
export destination 172.16.X.X 2057
mask source minimum 64
!
!
Turn on Wireshark and watch the NetFlow packets come in. I’ll have more updates for you on NetFlow and IPv6 as I receive them. 
If you’re a regular follower of this blog, you’ll know that Plixer is working on adding IPv6 support to Scrutinizer v7.0, but where is IPv6 on your radar?
We’ve all read articles about the growing shortage of IPv4 addresses and that’s why we need to move to IPv6, but when will that be and when should we start worrying?
If you do work for the federal government you’ll know that, according to the government’s 2005 mandate, everything on its network was required to be IPv6-ready by June 2008.
The government’s mandate helped to remind other organizations that they too needed to start thinking about moving to IPv6, but unless you do work for the government, the urgency to move isn’t so great.
Right now, large service providers are working on (or are begining to think about) transitioning their networks to IPv6. As their customers add cool devices such as smart phones and gaming devices onto the network, each of these need a new IP address. Experts say IPv4 address will be depleted by 2012. The world won’t stop when that happens but unless they have support in place, service providers won’t be able to add new devices to their networks.
As a stopgap, some organizations are using network address translation (NAT), which puts private network addresses behind a single IP address. Some carriers are investigating carrier-grade NAT. NAT could be the reason why the move to IPv6 has been slow for organizations other than government agencies.
One recent survey of companies including service providers, network equipment vendors and enterprises suggest that there is no business case for IPv6. Customer demand is the biggest driving force for those that are implementing IPv6. These folks are using a dual-stack approach, which allows IPv4 and IPv6 to run side-by-side.
The report also suggests that the biggest challenge for organizations is the lack of IPv6 technical expertise on staff. If you’re looking to find your next career move, this could be it. A quick hit of the Indeed job listings aggregator site netted 297 IPv6 jobs. Not a huge number, but if the survey results are to be believed, there would be less competition for jobs.
How far along is your company in transitioning to IPv6?
I did some investigation on IPv6 the other day. Luckily Wireshark has the decodes necessary to look inside the Cisco NetFlow v9 / IPFIX packets.
The flow shown below is one of the Egress flows and I highlighted the IPv6 Address. Take a look:
What is your company doing to prepare for IPv6? You can start by asking “why IPv6”.
This is article 2 of a 3 part series on the differences between NetFlow version 5 and v9. Read Cisco NetFlow v5 vs. NetFlow v9: Part 1.
The Big Mac
You expected it but Cisco NetFlow v9 is really more than a Big Mac®. To hold to the analogy, the Big Mac brings cheese, lettuce and a sesame seed bun to the traditional McDonald’s burger. It brings more substance, more meat! It brings the coveted “special sauce”.
If you haven’t already, take a look at the format of Cisco NetFlow v9. At first you might think “wow, too much information”. Let’s keep it all in perspective. You can get tons of information using SNMP and most people only scratch the surface.
Hey, I need a template
With NetFlow v5, the collection software is usually hard coded with the decode information necessary to digest the incoming flows. It is predetermined and never changes. It is always the same old fields in the same order. Some call it deterministic, and therefore, collection can be fast.
With NetFlow v9, templates are periodically sent out (e.g. every minute) on how to decode the packets. The collector often must hold off on decoding datagrams until a template is received. This template architecture makes v9 very dynamic with what it can send. Some of the new features in v9 that some customers might be looking for include:
• Source and Destination MAC addresses
• IPv6 support
• Improved details on VLANs and MPLS connections
• Flow sampling, which is kind of like sFlow. See NetFlow vs. sFlow
• Interface Name and Description (usually requires SNMP)
• Egress Flows which I’ll digress on in another blog (Important)
• Many more capabilities. I’ll talk about Flexible NetFlow later.
NetFlow v9 downfalls
Version 9 is not without its weaknesses. First of all, most people turning it on are using it to collect the same data you can get with version 5. How come? Most NetFlow collection packages don’t provide a reporting interface to view the additional information provided by v9. What’s more, the advanced exports are more complicated to configure, and without a reporting package, it is more work to figure out if it is exporting correctly.
Like SNMPv2, NetFlow v9 will take time to roll out. Customers need to ask for the additional features. Where’s the ‘demand’? Too bad I wasn’t drawing comparisons to Wendy’s Hamburgers. Anyway, we need to hear from you! Vendors need to hear from more than one customer that a feature is needed and why. A business case can then be justified and software development can begin.
What is Cisco up to?
NetFlow v9 is Cisco’s attempt to let the Network Administrator export nearly any information he/she wants from the router. It is my guess that someone at Cisco took a class on Microeconomics and is trying to encourage the IOS software developers to write more features into NetFlow in hopes that the consumer will strive for more ‘utility’ and ultimately ‘Demand’ will follow. We’ll discuss flexible NetFlow in my 3rd and final blog in this series.
Update: All the parts to this series have been published. See Part 1 here, Part 2 here, and Part 3 here.
Michael Patterson
