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.