[c-nsp] Feature request

Thu Nov 9 15:50:27 EST 2006

On Thu, Nov 09, 2006 at 12:44:34PM -0800, Ian Cox wrote:
> 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

is you are running IS-IS, check out the overload bit...

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

-b

> 
> 
> 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/
> _______________________________________________
> 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20061109/97541cd8/attachment.bin 