> 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
>
> > 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