[c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Mack McBride]

NAT on the 6500/7600 doesn't work well and uses substantial software resources.
NDE on the 6500/7600 has a large number of limitations.
Netflow itself is done in hardware but the export is done in software.
I have used both on the 6500 platform with no issues so it may be software dependent.
I migrated off of netflow to the SPAN setup you describe with specialized software versus
attempting to generate netflow data. 

SPAN as you describe works well but you are limited by the replication on the PFC/DFC.
If you are only interested in 'interesting' tcp traffic (ignore packets with ACK only) you
can sample very large quantities of data on the linux box.  This can be done with VACL functions.
If your data is mostly UDP it may be more difficult to determine what is interesting.

Mack

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Matthew Huff
Sent: Friday, August 26, 2011 10:26 AM
To: 'cisco-nsp at puck.nether.net'
Subject: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

Last winter we purchased a pair of 7606 routers to use out at the NYSE colo facility. We connect via a 1gb fiber to the SFTI LCN for market data and FIX traffic. We fully expected to be able to use hardware assisted NAT and NDE to monitor the traffic. The netflow output we get is random, sporadic and very incomplete. After dealing with our Sales team and TAC, we have finally got them to admit that it doesn't work when NAT and NDE are configured on the same interface.

Nowhere in the Cisco marketing literature, Cisco Documentation, or even Cisco bug lists does it mention this. There are some caveats listed regarding NDE and NAT (flow mask conflicts, and fragments), but even given that, the caveats imply that it will work if the caveats don't apply or the flowmask conflicts are resolved. Also, there are no warnings when configuring it. The feature manager shows no errors or conflicts, etc...

At every step, in my opinion, cisco has been reluctant to admit that it doesn't work. Only when confronted with the evidence, they did finally admit it. Had we known of this limitation, we would have purchased different hardware including possibly another vendor's solution.

I'm looking at using SPAN to replicate the data and send it to a linux box to then create netflow data exports, however, given the nature of the data (high bandwidth and microburst), I'm not sure that the Linux box will work accurately. I assumed the PFC would be doing the exports in hardware giving us the most accurate realtime look at the market data. Evidently I was wrong.

I'm sending this so that no one else will make the same mistake we did as well as being in the nsp archives.

----
Matthew Huff             | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff        | Fax:   914-460-4139



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/