[52105] in North American Network Operators' Group
Re: BGP Default Route
daemon@ATHENA.MIT.EDU (Jesper Skriver)
Mon Sep 16 03:22:47 2002
Date: Mon, 16 Sep 2002 09:21:52 +0200
From: Jesper Skriver <jesper@skriver.dk>
To: "Martin, Christian" <cmartin@gnilink.net>
Cc: "Lupi, Guy" <Guy.Lupi@eurekaggn.com>,
"'nanog@merit.edu'" <nanog@merit.edu>
Mail-Followup-To: Jesper Skriver <jesper@skriver.dk>,
"Martin, Christian" <cmartin@gnilink.net>,
"Lupi, Guy" <Guy.Lupi@eurekaggn.com>,
"'nanog@merit.edu'" <nanog@merit.edu>
In-Reply-To: <94B9091E1149D411A45C00508BACEB35015F3293@entmail.gnilink.com>
Errors-To: owner-nanog-outgoing@merit.edu
On Sun, Sep 15, 2002 at 07:32:23PM -0400, Martin, Christian wrote:
> > On Sat, Sep 14, 2002 at 02:18:15PM -0400, Lupi, Guy wrote:
> >
> > > I was wondering how people tend to generate default routes to
> > > customers running bgp.
> >
> > Short answer: don't
> >
> > Longer answer: To solve the exact problems you mention below, only
> > advertise a aggregate block of your own to this customer, say
> > x.x.0.0/16, then the customer will configure his device something
> > like
> >
> > ip route 0.0.0.0 0.0.0.0 x.x.0.0
> >
> > or
> >
> > set routing-options static route 0.0.0.0/0 next-hop x.x.0.0 resolve
> >
> > This will ensure that if the border router get's isolated, it will
> > no longer advertise x.x.0.0/16 to the customer, and the customer
> > router can choose a backup path.
>
> What if the aggregate is local to the border router? If you want to
> avoid this problem, you will have to use a route that originates from
> somewhere away from the border.
Yes, I guess that is the most normal senario, the aggregate routes are
sourced at a set of routers at different pop's, but not all border
routers.
> This is more work than is necessary, IMO. If your border router is
> isolated, you have a design problem or a failure state that is just as
> likely to occur(if not moreso) than the border router failing.
That is no argument, there is a probability that a border router get's
isolated, and the above solution will handle that problem too, how
likely or unlikely that failure might be, which highly depends on the
design.
> What I will say is that a "full-table" peer should not get a default
> route at all.
Agree
> Of course, this isn't very enforcable. In any case, providing a
> default is not something I would say shouldn't be done, IMHO.
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Senior network engineer @ AS3292, TDC Tele Danmark
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.