Unified communications means more NetFlow, sFlow

Posted in NetFlow on August 6th, 2009 by mike@plixer.com
unified-communications-means-more-netflow-sflow

SYDNEY, AUSTRALIA: Nortel has saved around $12 million in the last one year as a result of implementing unified communications (UC) in the organization. This often means voice, video and data all done remotely using a typical laptop.

My experience with UC
Two weekends ago I was up at Lake Winnipesaukee in New Hampshire and my cell phone reception was horrible. I needed to call the office and I didn’t want to use the phone in the hotel room to run up my personal charges and go through the hassle of submitting a reimbursement at the office. I experienced UC by launching my soft phone on my PC and making a phone call after checking my email. Read more »

Michael Patterson
Scrutinizer Product Manager
Tags: , , , , , , , , , , , , , , , ,

Nortel switches and IPFIX – A mixed message?

Posted in NetFlow, NetFlow Analyzer on June 22nd, 2009 by jimmyd
nortel-switches-and-ipfix-a-mixed-message

I was looking at a WireShark packet capture of some IPFIX traffic coming from a Nortel switch and quickly saw a few things that puzzled me.  At first, I started splitting hairs because I was thinking that if Nortel is going to market IPFIX support, it should adhere to the standard (RFC 5101).

Then again, it might have better luck working with the various NetFlow traffic analyzer solutions on the market if it makes the exported data look like Cisco NetFlow v9.

Read more »

____________________________________
Jim Dougherty aka "Jimmy D"
International Sales Channel Manager and
Netflow Evangelist for Plixer International!

Follow me on Twitter
http://twitter.com/jimmydnet
____________________________________
Tags: , , , , , , ,

NetFlow version 9: egress vs. ingress

Posted in NetFlow, NetFlow Analyzer, Network Traffic Analysis, Scrutinizer on June 4th, 2009 by mike@plixer.com
netflow-version-9-egress-vs-ingress

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)

nfv9ingress

Egress Flow with IPv6 (the same with IPv4)

nfv9egress

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
Scrutinizer Product Manager
Tags: , , , , , , , , , , , , , , , , , , , , , , ,

Nortel pushing forward with IPFIX Support

Posted in NetFlow, Scrutinizer, sFlow on May 2nd, 2009 by Jon Mills
nortel-pushing-forward-with-ipfix-support

IPFIX is the same as NetFlow v9?
We have several dozen customers collecting IPFIX from their Nortel hardware. Mostly they have 5500 and 8600 series switches and routers. The biggest issue we find is that somehow customers are getting the impression that it is almost exactly the same thing as Cisco NetFlow v9 – and this is true… well sort of.

Nortel supports flow sampling with IPFIX
IPFIX is basically NetFlow v9. However, Nortel is only sampling packets on most of their switches (e.g. 5500, 5600 and 8300 series). The sampling is done in a round robin fashion, similar to sFlow technology. Nortel claims that the 8600 series can sample 100%, but our customers that I’ve spoken with are still seeing sampling and not 100%. Perhaps someone from Nortel could comment on this? Then there is the hash overflow [pdf] issue. You can find information on configuring IPFIX on Nortel switches on our web site.

Nortel gives away IPFIX in base code
In the past, IPFIX support required a purchase of the advanced routing software on top of the 5500 switch. Recently, I heard that they are putting IPFIX support in the base code of the new 5600 series. I would contact your local Nortel team for an update on where the company is going with their products. Sometimes you can find out a whole lot after signing an NDA.

Nortel is still restructuring
Nortel isn’t out of their financial woes yet. However, certain divisions are seeing success in sales.


Jon Mills
Marketing & Public Relations Manager
Follow Me On Twitter
Tags: , , , , , ,

Utilization Understated on Nortel IPFIX capable equipment

Posted in General, Network Health Report, Network Problem Resolution, Scrutinizer on January 13th, 2009 by Jo-G
utilization-understated-on-nortel-ipfix-capable-equipment

This may be caused by an internal Hash overflow issue with the Nortel hardware.

1. Connect Scrutinizer directly to the ERS node.
2. DO NOT directly connect Scrutinizer to that PR card and use a VLAN IP as the exporter IP. This will likely cause accuracy problems.
3. DO NOT use an out of band connection.
4. If you are not using many of the ports on the card, try spreading the links in 3 lanes, because each lane has a hash table and spreading the links may be helpful for reducing the hash overflow.

The issue may be due to a hash overflow. To check if you do have a hash overflow, do the following:
Read more »

Tags: , ,