On 8/29/2011 8:58 AM, Jeff Bacon wrote:
It's un-called-for, certainly.
Unfortunate to hear that. It was brief and to the point. If a 6500 NAT
knowledgeable person would have been hired, they would have steered
clear of it. Design around it.
It's the problem of some smaller firms,
On 8/29/2011 12:05 PM, Matthew Huff wrote:
It took 3 weeks with TAC including a network sniffer trace file to prove to the
tech it didn't work. When he escalated it to backline BU engineering, he found
out it wasn't supported. It isn't even well known within Cisco.
A lot of these things
Hi Mark,
Don't speak too soon - we've come across a couple of cases in IOS
XR where a configuration will be committed with references made to
other bits of configurations that don't yet exist.
This is so by design not by mistake or bug. This is called forward
referencing.
Example quote from
On Tuesday, August 30, 2011 04:12:01 PM Robert Raszuk wrote:
This is so by design not by mistake or bug. This is
called forward referencing.
Example quote from some doc:
You can specify a forward reference to a neighbor that
you have not yet configured
Sorry if I wasn't clear - I'm
The issue I spoke about with IOS XR was application of an
ACL filter name and a successful commit before the actual
ACL had been created. This can't be a feature.
Perhaps they intentionally carried over the fun of vanilla IOS where you can
quite legitimately reference ACLs that don't exist,
On Tuesday, August 30, 2011 05:22:41 PM Tim Franklin wrote:
Perhaps they intentionally carried over the fun of
vanilla IOS where you can quite legitimately reference
ACLs that don't exist, and *then* try to remember
whether a non-existant ACL is permit all or deny all
in this particular
My advice as an ex-cisco guy to you all would be to forget about
documentation, marketing, TMEs or consultants.
Instead get the router/switch and test it with the release you plan to use.
Each BU have bunch of routers/switches which they do ship left and right
to customers to try before you
I would instead consider moving the NAT somewhere else, and leaving the
Netflow on the box. The hardware-assisted NAT feature in the 6500/7600
has the feel of an abandoned feature; one that Cisco would rather you
didn't use, and are sorry they ever implemented.
I would say that's not all
On 26/08/2011, at 6:25 PM, Matthew Huff wrote:
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
Another problem with a SPAN is that you can get two gigs of data heading to a
gig port if the port you are mirroring is (full duplex - as it should be
and)running wide open.
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
Matthew Huff writes:
I would understand the limitation if I was using some unusual feature
or using them in some unusual way. However, the marketing literature
for the RSP720 mentions supporting hardware-assisted NAT, and netflow
collection.
Right. Your mistake, and it's an easy one to make,
I agree. This is an undocumented feature.
I am fairly experienced and some would even say knowledgable.
I would not have recommended NAT on the box based on my experience with
poor NAT response rather than the specific bug.
So I don't think this is a valid response to the problem.
Cisco should
On Mon, 29 Aug 2011, Simon Leinen wrote:
In short: Never assume that two features work together until you tried
it in the lab or got credible evidence from somewhere that they do.
I'll add here that just because you configured it in the lab (and didn't
get any errors from the CLI), don't
On Monday, August 29, 2011 12:35:20 AM Pete Lumbis wrote:
This is something I've pushed for in the past and is
incredibly difficult to do. I agree 100% that the CLI
should be the first line of defense against
misconfiguration. One of the first challenges with this
kind if check is the need
On Monday, August 29, 2011 10:15:06 AM Randy wrote:
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 -
On Monday, August 29, 2011 03:22:13 PM Robert Raszuk wrote:
Seeing is believing especially in cisco ;-)
Seeing is believing, with any vendor.
We run PoC's all the time, either on-site with loan
equipment or at the vendor's labs. It's time consuming,
especially when done on-site, but is worth
On 08/27/2011 10:31 PM, Matthew Huff wrote:
As far as speaking to a TME, I work in small trading firm. 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
We don't have fragmented packets. I checked all the caveats. You missed my
point. I'm very aware of the restrictions with conflicting flowmasks, etc.
The problem is that the hardware assisted NAT uses netflow to insert a custom
tcam entry that doesn't get aged out. In other words, NDE will
Netflow *collection* of flows traversing the NAT-ed interface. Sorry, I can see
why that would be confusing.
-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de]
Sent: Sunday, August 28, 2011 5:14 AM
To: Matthew Huff
Cc: 'Dale W. Carder'; 'cisco-nsp@puck.nether.net'
Bottom line: you *should* be able to trust vendor marketing, but you
*can't*, and I strongly advise you don't, for Cisco or any other vendor
- they simply don't convey accurate information reliably enough :o(
I agree. Caveat Emptor.
I would understand the limitation if I was using some
likely we will either replace the entire hardware or leave it the way it is.
Having to increase latency to add monitoring is the tail wagging the dog.
Do you have the tools in place to comment on the latency it will
generate and the impact and loss of revenue to your customers?
As far as
On 8/27/2011 4:31 PM, Matthew Huff wrote:
If it was made apparent, could you point to any public documentation that
states that? I've scoured Cisco's site, google, and mail archives, and can't
find any mention (other than specific caveats) that state that NDE and hardware
assisted nat are not
Hi,
On Sun, Aug 28, 2011 at 10:23:57AM -0400, Matthew Huff wrote:
Netflow *collection* of flows traversing the NAT-ed interface.
Thanks for clarification. Yes, indeed, that makes more sense (in a way)
and is not that easy to work around.
One could try some VRF tricks (NAT in one VRF, netflow
Hi,
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
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
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-knowssnip
What *^% diligence are
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:
...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
On 08/26/2011 05:25 PM, Matthew Huff wrote:
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
I would instead consider moving the NAT somewhere else, and leaving the
Netflow on the box. The hardware-assisted NAT
I would instead consider moving the NAT somewhere else, and leaving the
Netflow on the box. The hardware-assisted NAT feature in the 6500/7600
has the feel of an abandoned feature; one that Cisco would rather you
didn't use, and are sorry they ever implemented.
Yes, I get that feeling
On Aug 26, 2011, at 11:25 AM, Matthew Huff wrote:
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
If it was made apparent, could you point to any public documentation that
states that? I've scoured Cisco's site, google, and mail archives, and can't
find any mention (other than specific caveats) that state that NDE and hardware
assisted nat are not supported on the same interface. In fact,
Hi Dale,
In the right vendor shop no matter how many networkers sessions you
attend there should be no need to make any thing apparent from the
power-point slides.
If CLI/parser allows to co-exist any feature combination - they are
expected to work. I am with Matthew here.
If they do not work
Matthew said:
If it was made apparent, could you point to any public documentation that
states that? I've scoured Cisco's site, google, and mail archives, and can't
find any mention (other than specific caveats) that state that NDE and
hardware assisted nat are not supported on the same
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,
NAT on the 6500/7600 doesn't work well and uses substantial software resources.
NDE on the 6500/7600 has a large number of limitations.
Netflow itself is done in hardware but the export is done in software.
I have used both on the 6500 platform with no issues so it may be software
dependent.
I
On 8/26/2011 11:25 AM, Matthew Huff wrote:
We fully expected to be able to use hardware assisted NAT and NDE to monitor
the traffic.
Why?
The netflow output we get is random, sporadic and very incomplete.
This is a very well known limitation.
After dealing with our Sales team and TAC, we
37 matches
Mail list logo
