[c-nsp] delay eBGP sessions on startup?

[Gert Doering]

Hi,

On Mon, Nov 23, 2009 at 11:31:42AM +0100, Pavel Skovajsa wrote:
> 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.

Indeed.  But actually you don't need millisecond convergence here, if 
you ensure convergence in the right sequence - IGP first (with overload
bit), iBGP next, clear IGP overload bit, eBGP.

The problem is that eBGP routes are announced before iBGP has converged,
and as such, the routers cannot do the right thing here.

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

This would not help at all.  Why?  Because at startup, "ISP Router 1"
only has *one* prefix.  Only after the 200k routes from ISP-R2 and
upstream 1 have been received, ISP-R1 could even begin to announce them.

Not that I would *want* to announce "the full table" to the upstream 
routers.

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

This would improve things slightly, but won't solve the general problem.

>    b. Bind the advertizing of the big  200.1.0.0/16 to RTR tracker
> that tracks the availability of certain route

Won't help.  If ISP-R2 is down, ISP-R1 still has to announce the /16
(there are customers directly connected to ISP-R1 that need the /16 to
be in BGP).

>    c. ....BGP scanner tweaking....

Won't help.  Scanner is not involved yet.

>    d. etc. etc. see Networkers presentations:
>                     BRKIPM-3005 - Advances in BGP
>                     BRKIPM-3004 - IOS-XR IGP, BGP and PIM Convergence

I'll look at these (thanks).

> 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. :))

These two would solve this, but "3." will only help for planned reboots
(we hardly ever do planned reboots, unplanned crashes and/or power problem
are more frequent), and "4." introduces extra complexity that we really
do not want to see there... 

Are EEM applets and startup invocation visible in "show running-config"?
(This is a serious question - of course the router configuration needs
to be backed up, and restored easily.  If extra work besides "copy tftp start"
is needed to get a replacement device in place, this is bad).

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

EEM is a hack that increases complexity in a non-deterministic way, and
should only be used when all the more generic approaches fail.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20091123/5acffce1/attachment-0001.bin>