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

Matthew Huff mhuff at ox.com
Fri Oct 11 09:11:23 EDT 2013


At least cisco went back end and added caveats to the documentation about this limitation. Since I had combed through all the documentation beforehand, had the caveat been there, it would have been likely we would have purchased a different set of hardware. 

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

> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of oldnick
> Sent: Friday, October 11, 2013 2:46 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] WARNING: Netflow & Hardware assisted NAT not supported on 65xx on the
> same interface even with Sup2T
> 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
> 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/

More information about the cisco-nsp mailing list