...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 <[email protected]> wrote: > From: Frank Bulk <[email protected]> > Subject: RE: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not > supported on 76xx/65xx on the same interface > To: "'Randy'" <[email protected]> > Cc: [email protected] > 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: [email protected] > [mailto:[email protected]] > On Behalf Of Randy > Sent: Sunday, August 28, 2011 9:15 PM > To: Gert Doering; Brett Frankenberger > Cc: [email protected] > 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 <[email protected]> > wrote: > > > From: Brett Frankenberger <[email protected]> > > Subject: Re: [c-nsp] WARNING: Netflow Data Export > & Hardware assisted NAT > not supported on 76xx/65xx on the same interface > > To: "Gert Doering" <[email protected]> > > Cc: [email protected] > > 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 [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
