Reporting on traffic impacted by Cisco WAAS using NetFlow requires the use of egress flow in NetFlow v9. Consider the diagram below where the traffic going in on interface 1 should be compressed by WAAS before it leaves on Interface 3:
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
In a bold and very aggressive move, Cisco this week announced its new line of commercial servers that specialize in virtualization.
I don’t know about you all, but I find this interesting, yet puzzling.
First off, this will be Cisco’s debut into an already competitive market. You wouldn’t imagine there would be much of a customer pool left when competing with giants such as Dell, HP and IBM, but Cisco seems to think so.
Of course, Cisco is no small player either boasting annual revenue $40 billion and 65% gross profits in the networking market.
However, the puzzling part is why it would want to start fresh in this fierce market where vendors generally only make a 25% profit margin anyway? Also, what kind of impact will this have on Cisco’s relationships/partnerships with companies like IBM, Dell and HP? I wouldn’t imagine there are a lot of fuzzy, good feelings about this.
I found a New York Times blog dedicated to Cisco’s announcement and it has a nice quote from James Staten, an analyst at Forrester Research who attended Cisco’s launch.
He said, “This is war and a direct frontal assault on IBM and HP.”
On top of that comment, HP also had some strong statements of its own regarding this launch: “It’s appropriate that Cisco launched their server in a museum.” taking jabs at the concept design of these servers.
Going in for the kill, HP added: “Would you let a plumber build your house?”
Ouch.
Personally, I don’t care about Cisco making servers. However, this manuever could have a significant impact on the networking market as we know it.
HP has already responded to Cisco’s announcement by increasing its investment in networking equipment. I don’t know what HP has planned, but I bet “hell hath no fury like a vendor scorned!”
But it does makes me wonder what HP has planned for its already affordable ProCurve line.
But what about vendors like Dell and IBM that have only a small presence in the networking field? I wonder if they will be so quick to advertise Cisco routers/switches along with their products?
I speculate that we may start seeing increased sales from networking companies like Juniper, Enterasys and Riverbed.
But I guess only time with tell.
What do you all think? Feel free to post a comment to this blog.
Related read: How open is Cisco Unified Computer System?
-Nate
