[c-nsp] delay eBGP sessions on startup?

[Pavel Skovajsa]

Hi all,

The situation is due to the fact that the upstream solution
architecture is not symetric + the fact that BGP is not designed for
milisecond convergence.

Hence are my "silly" ideas in the order they appear in "memory":

1. One of the solutions would be to make the architecture symetric -
make Upstream 1 <---> ISP-Router 1 send 200k routes between
themselves.

2. Try to get the situation symetric as much as possible with
"Advanced Complicated BGP" tweaking
   a. As default MTU for BGP session is 536, use "ip tcp
path-mtu-discovery" on neighboars or "neighbor x.x.x.x transport
path-mtu-discovery". This should get the 200k on the other side
faster.
   b. Bind the advertizing of the big  200.1.0.0/16 to RTR tracker
that tracks the availability of certain route
   c. ....BGP scanner tweaking....
   d. etc. etc. see Networkers presentations:
                    BRKIPM-3005 - Advances in BGP
                    BRKIPM-3004 - IOS-XR IGP, BGP and PIM Convergence

3. Shutdown the BGP with Upstream_1 in startup, and unshut it manually. :))
4. Shutdown the BGP with Upstream_1 in startup, and unshut it
automatically with clever EEM. :))

I my opinion asking Cisco for a knob is a last resort, should be used
only when all the ideas fail.

-pavel skovajsa

On Mon, Nov 23, 2009 at 10:30 AM,  <masood at nexlinx.net.pk> wrote:
> probably Cisco needs a knob very similar to vendor Juniper out-delay. you
> can delay the time between when BGP and the routing table exchange route
> information.
>
> http://www.juniper.net/techpubs/software/junos/junos73/swconfig73-routing/html/bgp-config58.html#1016387
>
> Regards,
> Masood
>
>> On Mon, Nov 23, 2009 at 09:10:25AM +0100, Gert Doering wrote:
>>>   "bgp update-delay <n>"
>>>
>>> "the bgp update-delay command is used to tune the maximum time the
>>> software will wait after the first neighbor is established until it
>>> starts calculating best paths and sending out advertisements".
>>>
>>> Now, what does "maximum time" mean?  Will it wait, or will it not?
>>>
>>> The documentation that I found claims that the default value is "120",
>>> which would certainly not agree with the observed behaviour.  OTOH,
>>> Marco claims that he has seen "0" as a default...
>>
>> The docs make it look like more of a graceful-restart specific timer,
>> not like advertisement-interval (intentionally delaying the propagation
>> of new updates to try and consolidate them) or the "on-startup" delay
>> behaviors available in the IGPs.
>>
>> http://www.cisco.com/en/US/products/ps6550/products_white_paper09186a008016317c.shtml
>>
>> The "bgp update-delay n" command may be entered on the Cisco NSF-capable
>> router. The update-delay specifies the time interval- after the first
>> peer has reconnected during which the restarting router expects to
>> receive all BGP updates and the EOR marker from all of its configured
>> peers. The default value of n is 120 seconds, and n is always measured
>> in seconds. If the restarting router has a large number of peers, each
>> with a large number of updates to be sent, this value may need to be
>> increased from its default value.
>>
>> --
>> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
>> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>