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.