[c-nsp] WARNING: Netflow & Hardware assisted NAT not supported on 65xx on the same interface even with Sup2T

oldnick oldnick.nsp at gmail.com
Fri Oct 11 02:45:36 EDT 2013

Hi all,

I leave it here JFTR, to prevent someone else to make the same error as I did with NAT, Netflow and 
Sup2T (just as Matthew Huff did before me with Sup720).

According to Cisco because of CSCud36118, enabling NAT (ip nat outside) and Flexible NetFlow (ip 
flow monitor MonitorFlow input) on the same interface force NAT traffic to be software switched even 
with Sup2T.

Although TAC states that this is software limitation, I've been told that there it no plan to 
support this feature combination in hardware.


-----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 

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

More information about the cisco-nsp mailing list