[c-nsp] Feature request

[Ian Cox]

As Rodney said you don't do things by flows on any modern router or 
switch. Everything is FIB/CEF switched. What you do is increase 
routing metrics such that the box in question is least desirable path 
for traffic in the topology. Once that occurs, and a period of time 
has elapsed so all neighbors are no longer forwarding through this 
node, make the change. Take a look at:

http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800ade18.shtml


Ian


At 01:38 PM 11/9/2006 -0500, Rodney Dunn wrote:
>Disruptive means different things to different people.
>If you define disruptive as losing a single packet it can't
>be done today.
>
>If you define disruptive as something that is "significantly
>noticeable" to the user. ie: phone call drops, TCP session hangs
>for an extensive amount of time then things are in the works and
>some available to proactively reroute traffic (ie: NSF/SSO, signalling
>a node going down proactively to the routing protocols, etc..)
>
>Routers don't keep track of flows in the forwarding path and they
>would have to somehow inform upstream routers to route on a flow
>basis. I can't see any scalable solution to that.
>
>rodney
>
>
>On Thu, Nov 09, 2006 at 12:48:48PM -0500, 
>christopher.a.kane at jpmchase.com wrote:
> > Since dependency upon network availability, IRT revenue, never
> > decreases....it seems more and more often people like to schedule complete
> > downtime maintenance windows to perform seemingly benign tasks. We often
> > have folks requesting we route traffic away from a device that we intend
> > to perform maintenance on even if it's as simple as plugging in a new,
> > non-production T1 or changing the speed/duplex settings on a port that
> > resides on a different module and has nothing to do with their production
> > route. Erring this much on the side of caution seems like a sledgehammer
> > approach. I'd much rather be able to reassure folks that certain tasks can
> > be performed without impact to traffic flow. But over the years...too many
> > bugs or mishaps such as configuration errors or a field engineer sneezing
> > on a router causes said router to reload. You want a true example? How
> > about inserting a flash card into a box that shot CPU utilization up to
> > >95% and caused packet loss.
> >
> > I have a feature request and was hoping Rodney or one of the other Cisco
> > employed lurkers could point me in the right direction. My request is for
> > a 'Detour' feature. What I'm looking for is the ability to route any new
> > traffic flows in a different direction and allow existing traffic flows to
> > bleed off. Once all the traffic has detoured to my alternate connection, I
> > could perform maintenance and then remove the detour and allow the traffic
> > to return to the primary path. The catch is that I don't want this to be
> > disruptive. The programming language would read something like: for all
> > existing flows across interface A/B, permit them to continue. But for any
> > new data flows, detour them to interface X/Y. It seems that we could use
> > data like Netflow and we'd probably have to alter CEF entries to make it
> > happen. Maybe even allow the feature to be shared with a peering router so
> > that we could not only alter the path through various interfaces on one
> > router but ship them to the peering detour router such as would be
> > available in an HSRP/VRRP configuration. As far as I know, up to now, all
> > intentions to route traffic across other available paths is disruptive to
> > existing source/destination flows. I'm not aware of a feature that gently
> > moves traffic another direction without causing some interruption to
> > existing flows. A feature like a detour could be leveraged to stage a
> > device to be ready for maintenance. If we could configure the router to
> > start detouring traffic to an alternate route at a particular time (either
> > immediately or in a set future day/minute/second) we could gently direct
> > traffic away from our maintenance domain without customers having to be
> > engaged and prepared to possibly reset applications because their TCP
> > sessions were hung by the change in flow.
> >
> > Make sense?
> >
> > -chris
> >
> > Chris Kane
> > CCIE #14430
> > Network Engineering - Business Partner connectivity
> > JPMorgan Chase
> > w (614) 213-2923
> > c (614) 329-1906
> >
> > -----------------------------------------
> > 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.
> >
> > _______________________________________________
> > 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/