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

[Randy]

...nothing wrong with using-consultants.
Once-again, consultants can only offer-advice based on what-is-known/un-known based on vendor-doc.( unless ofcourse, said-consultant also writes the applicable-code within Cisco!)
..that is the whole point!
./Randy

--- On Sun, 8/28/11, Frank Bulk <frnkblk at iname.com> wrote:

> From: Frank Bulk <frnkblk at iname.com>
> Subject: RE: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface
> To: "'Randy'" <randy_94108 at yahoo.com>
> Cc: cisco-nsp at puck.nether.net
> Date: Sunday, August 28, 2011, 7:45 PM
> 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/
> 
>