[c-nsp] delay eBGP sessions on startup?

[Bill Desjardins]

On Tue, Nov 24, 2009 at 2:25 AM, Gert Doering <gert at greenie.muc.de> wrote:
> Hi,
>
> On Mon, Nov 23, 2009 at 07:03:07PM -0500, Bill Desjardins wrote:
>> the idea is that the border routers peer with the ibgp RR's and use a
>> bgp conditional statement to advertise your aggregate upstream only
>> upon matching a 'trigger route' received from the ibgp RR. I am no bgp
>
> This would work, but won't do the job in our network - this network is
> really, really small (but has BIG requirements, as always :-) ) - so there
> are no other BGP routers.
>
> Given that there are only these two boxes, and neither can rely on the
> other one (it could be down...), waiting for a certain route to show
> up might be fatal - depending on what else is available, the route might
> just not show up ever.
>
> (I'm not sure that I would be able to convince the customer that adding
> two more BGP boxes and increasing the complexity of the overall
> configuration is a good thing...)
>
>
> What I'm currently leaning toward is "put all internal routes into OSPF
> and to hell with best practices"...  much less complexity, problem
> still solved. The estimate is that we'll see something like 50-100
> internal routes at maximum, and OSPF will quite happily handle this.

if the only ibgp is between these 2 borders, than best ibgp practice
would seem to be a bit far off anyway.

ospf and be done with it. if IGP routes grow to an uncomfortable
level, then you can revisit the design then. simplicity and
reliability would be my first choice.

> gert

Bill