[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