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

[Jeff Bacon]

> On Sun, Aug 28, 2011 at 11:12:44AM -0500, Tony Varriale
> wrote:
> > Then hire someone that knows what they are doing.
> 
> Am I the only one to find that sort of remark a bit nasty?
>
> While not sporting any nice certificates, I consider myself to be
> somewhat experienced with Cisco platforms, and Cisco architecture - and
> if a prospective customer would have asked me "will NAT and netflow
> work together?" I would have checked the documentation, would not have
> found anything about that conflict either, and would have said "no
> problem there".
> 
> After all, on other Cisco platforms netflow is used as well to help
> NAT (netflow feature-acceleration), and of course, the corresponding
> flow records get exported properly afterwards.
> 
> gert

It's un-called-for, certainly. 

It's the problem of some smaller firms, especially in this business niche. We can't afford to do RFPs for everything, and while we have talented staff, sometimes we're just stuck doing a "attempt to do it and hope it works" because that's the speed the business is moving at, and since your guess is right 80% of the time, you take that bet because better that than slow down the entire process 100% of the time. You stick a finger in the air, measure the wind, dial in a bit of Kentucky windage, and fire, because it's better to have something that sorta works _now_ than something that works perfectly _later_. 

Is this ideal? No. It sucks, frankly. It's just life. 

On the other hand, if you've been using the platform for about so long, it should be fairly obvious at this point that not everything works as described and just because it's documented - or not-documented - doesn't mean it will work. (Remember, negative proofs are the hardest to deal with.) It's frustrating, and worth a good vent, but that too is just life. 

The reality, as I can determine, is that not even Cisco really knows what does and does not work when it comes to the 6500. As I had it explained to me, there are so many possible combinations and permutations of "features" (defined as anything managed by the feature manager) that, when combined with the fact that it _isn't_ a nice clear software path but a muddle of paths being pushed down into the ASICs, that there isn't enough manpower to even attempt to test it all in order to document it. (And if you did, imagine the size of the documentation necessary - and the manpower required to manage _that_.) TAC sort of knows, as a sort of collective "hive mind" of stored emails and internal docs and experiences, but even that's imperfect. I've been told more than once that pretty much you end up having to have your SE go ask TAC and dev "can it do X and Y" and half the time (for various random combinations of X and Y feature) it'll come back "maybe". 

Another example of this is that you can't run NAT on an interface with MPLS. It works - except when it doesn't. "The results are unpredictable." Or NAT with VRF - look how specific the documented case is. It works, if you do exactly that, and if you are absolutely sure that no addresses overlap. It actually works in a much broader general case - it works with dynamic NAT and overlapping addresses and all sorts of cases - except the occasional connection will get dropped during a TCAM refresh, randomly, sorta kinda, unpredictably. But they also apparently never had anyone TRY it until I did. Customers will do the damndest things, after all... 


-bacon