[c-nsp] Feature request
christopher.a.kane at jpmchase.com
christopher.a.kane at jpmchase.com
Fri Nov 10 13:39:05 EST 2006
>So if I understand correctly, you want to route all traffic away from a
>switch while you change the duplex on a port and then route traffic
>back through that switch, to mitigate against the risk of unexpected
>consequences from the duplex change.
>
>For this to make sense, the mechanism/process for rerouting the traffic
>would have to be less risky than the mechanism/process for changing a
>duplex setting. It seems to me that the likelyhood of that being the
>case is essentially zero.
>
>Put another way: it sounds like you are asking for a fix that is almost
>certain to be worse than the problem.
>
> -- Brett
Thanks for the feedback. I referenced the speed/duplex as an example of
the caution some of our customers exhibit. And I referenced the insertion
of the flash card spiking CPU greater than 95% and dropping packets as an
example of situations that have occurred that make it a challenge to
squelch our customer's nervousness.
You are absolutely right...in that it often does seem for every knob we
have available and use, other portions of the configurations can be
impacted and have to be accounted for.
I appreciate all of the replies so far. Several folks have mentioned that
flow analysis is not something modern routers are expected to take action
on. Is that completely true? Doesn't OER play into that? The necessary
information is there if you've enabled Netflow. OER (Optimized Edge
Routing) appears to monitor flow and respond, which may be where the tweak
I'm looking for could exist. I haven't had a chance to play with OER to
see what we could get out of it.
In regards to references about OC-192...I'm talking about maintenance out
near our customer edge connections and Access layer infrastructure, not
the backbone. I appreciate the challenges you face trying to switch at
wire speed and the caution to ask for more packet examination while still
trying to maintain those standards. I'm not asking for the feature's
availability in this part of a large transport backbone. SSO and NSF
aren't always applicable because of the device types. The application of
my request is intended for an often seen 4 box setup. I'm only looking to
effect first hop ingress and first hop egress and then the immediately
attached uplinks. Propagation of this change throughout a larger portion
of the network is not necessary with proper summarization.
Some folks have mentioned OSPF and IS-IS use's of Stub and Overload. These
options help and I'll consider them in the future, but not always
applicable in every situation such as BGP peering via Aggregation routers
(think ISP gateway type topology). Those options would only apply for the
first egress hop in my scenario. They don't help in a graceful Default
Gateway change via HSRP or VRRP. Rather, I was hoping for a more protocol
independent/collaboration feature along the lines of OER.
I particularly like the working IETF doc that Oli provided. Thanks, I'll
be sure to keep an eye on that effort. And Dale is correct, I am basing
this both on the TDM reference you mention as well as some past
experiences I had with a company that wrote X.25 software.
Thanks,
-chris
-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
More information about the cisco-nsp
mailing list