[88783] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Disaster recovery using as-prepend?

daemon@ATHENA.MIT.EDU (Todd Vierling)
Fri Feb 17 16:58:02 2006

Date: Fri, 17 Feb 2006 16:57:12 -0500 (Eastern Standard Time)
From: Todd Vierling <tv@duh.org>
To: "Christopher L. Morrow" <christopher.morrow@verizonbusiness.com>
Cc: Warren Kumari <warren@kumari.net>,
	"Christopher J. Pilkington" <christopher.j.pilkington@gmail.com>,
	nanog@merit.edu
In-Reply-To: <Pine.GSO.4.58.0602172124250.9741@marvin.argfrp.us.uu.net>
Errors-To: owner-nanog@merit.edu


On Fri, 17 Feb 2006, Christopher L. Morrow wrote:

> > > If your primary is connected to ISP_A and the backup is connected to ISP_B,
> > > customers connected to ISP_B MAY still flow to your backup DC (ISP_B will
> > > probably set local preference on all customer routes - you should be able to
> > > override this behavior with communities but not all providers support this (or
> > > honor it 100% of the time!))
> >
> > And in addition to that, even multihomed customers of ISP_B may choose the
> > prepended route for a number of different reasons; for instance, ISP_B might
> > be a cheaper pipe for them, or there may be a smart-ish routing device or
> > scheme in play that overrides normal BGP decision making.
>
> I might be crazy, but couldn't you just prepend the route enough to
> effectively poison it at ingress to 'backup-isp' ?

Some route decision override schemes don't care what the path length is at
all, or factor it in with such a low weight, such that no reasonable amount
of prepending will change the situation.

With the development of source traffic engineering schemes, prepending is no
longer reliable as a means of affecting routing on the remote side.  That
perception will have to die with it (hopefully sooner rather than later).

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

home help back first fref pref prev next nref lref last post