[52104] in North American Network Operators' Group
RE: BGP Default Route
daemon@ATHENA.MIT.EDU (Martin, Christian)
Sun Sep 15 19:33:17 2002
From: "Martin, Christian" <cmartin@gnilink.net>
To: 'Jesper Skriver' <jesper@skriver.dk>,
"Lupi, Guy" <Guy.Lupi@eurekaggn.com>
Cc: "'nanog@merit.edu'" <nanog@merit.edu>
Date: Sun, 15 Sep 2002 19:32:23 -0400
Errors-To: owner-nanog-outgoing@merit.edu
>
> 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. 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.
What I will say is that a "full-table" peer should not get a default route
at all. Of course, this isn't very enforcable. In any case, providing a
default is not something I would say shouldn't be done, IMHO.
Thanks,
chris
>
> /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.
>
