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

[Frank Bulk]

I agree with you: what ought to be, isn't.  

I don't make buying decisions based on what I would like vendors to do or
what they should do, but what is.  Until documentation matches reality, I
will use consultants to help us with our due-diligence.

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Randy
Sent: Sunday, August 28, 2011 9:15 PM
To: Gert Doering; Brett Frankenberger
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT
not supported on 76xx/65xx on the same interface

....I have been following this thread and it is upto the *vendor* to
*Clearly-Document* what-combinations work and what doesn't!
It has nothing to do with what you or other OP have said wrt regard to
due-diligence or for that matter - ...hiring-someone-who-knows....<snip>
What &*^% diligence are you talking about? When, what works/doesn't is not
documented!!

As applicable to me(as an example)

I am still waiting for a clear-answer from TAC(as applicable to sxi4a & a
DFC environment) *IF* routed-mac-entries still-get-aged-out regardless of
whether-or-not-there is traffic!

..all boiles-down-to vendor-doc!

Given the times; it may be of interest to you and op:

Unlike the 90's there is very-little-to-none by the way of
resources(man-hours/lab) that $Employers can spare.
./Randy





--- On Sun, 8/28/11, Brett Frankenberger <rbf+cisco-nsp at panix.com> wrote:

> From: Brett Frankenberger <rbf+cisco-nsp at panix.com>
> Subject: Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT
not supported on 76xx/65xx on the same interface
> To: "Gert Doering" <gert at greenie.muc.de>
> Cc: cisco-nsp at puck.nether.net
> Date: Sunday, August 28, 2011, 5:33 PM
> On Sun, Aug 28, 2011 at 08:04:00PM
> +0200, Gert Doering wrote:
> > 
> > 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".
> 
> But now much money would you commit to that position? 
> You've been
> doing this a while ... presumably you're well aware that
> not everything
> always works togethor on platforms that do most of their
> switching in
> ASICs.  (I do a lot of GRE tunnelling and have for a
> long time.  The
> first thing I thought when I learned that Sup720s would
> support GRE
> tunnels in hardware was "I wonder what the limitations
> are".  There are
> many, and only some of them are documented.)
> 
> The comment you reference above was in respose to this:
>    We don't have the luxury of long,
> involved RFP with detailed
>    descriptions or time to work with a TME
> to discuss every detail of
>    every configuration we use. We expect if
> a vendor advertise features,
>    that they should work, except when they
> are documented (like caveats).
> 
> While you might not personally know off hand if NAT and
> netflow work
> togethor, if you had a requirement for that functionality
> and were
> considering the 65xx/76xx for it, would you read the
> documentation, not
> find anything saying they won't work togethor, and then buy
> it?  Or
> would you do a detailed RFP or talk to a TME about that
> functionality
> before buying it?  Or if you didn't have the time or
> talent to do one
> of those things yourself, would you hire someone who did?
> 
> The comment was rather blunt, but in terms of content, it
> was dead on. 
> Buyers need to do their due diligence.  Some are large
> and/or
> sophisticated enough to do it with in house employees,
> others need to
> hire outside talent.  But if you do neither, you run
> the risk of being
> disappointed. 
> 
> (In response to the comment about "I can't hire anyone who
> knows about
> limitations on future unreleased products".  Of course
> you can't.  But
> you can hire someone who knows how to do the necessary due
> diligence
> before purchasing a product.)
> 
>      -- Brett
> _______________________________________________
> 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/
> 

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