BGP/OSPF synchronisation

[Ondrej Zajicek]

On Fri, May 02, 2014 at 02:32:12PM +1000, Tom Harbert wrote:
> Hello,
> 
> I am running BIRD 1.4.2 on two Ubuntu Linux 12.04 systems acting as border
> routers.  Two eBGP peers on each with iBGP between them.  OSPF also between
> them and internally.
> 
> I notice that on reboot 10-15 packets both in and out are lost.  This seems
> to happen just as/after the bird process starts.  It appears as if perhaps
> BGP is establishing prior to the OSPF neighbors coming up and as a result
> black-holing traffic.  I am nailing down my public IP prefixes with null
> routes.

You mean that eBGP sessions established first? I guess there is no such
problem with iBGP sessions, as these usually depend on routable IP
addresses of neighbors, so they cannot establish before OSPF converges.
But singe-hop eBGP sessions could be established fast.

> I have attempted to use the 'start delay time x' command under the BGP
> sessions however they still establish immediately.  I believe this is
> because this command delays the outbound attempt to connect yet the remote
> side is initiating it.

Yes, that is true, 'start delay time x' governs just outbound attempts.

> # eBGP session to X
> protocol bgp eBGP_X {
>         description "eBGP - X";
>         local as X;
>         neighbor x.x.x.x as x;
> * start delay time 60;*
> import filter import_eBGP_X;
> export filter export_eBGP_X;
> }
> 
> Has anyone else ran into this problem with a similar design?  Is there a
> different command to prevent BGP peering from establishing or to wait for
> the IGP?

Currently, there is no feature allowing postponed start of some
protocols. I am interested in receiving suggestions or proposals on how
such dependence between protocols should behave or how it behaves in
other implementations.

> I have implemented a workaround/hack by filtering incoming TCP connections
> with destination port 179.  This prevents the peers from being established
> until the *start delay time* is reached.  I will review my routing
> configuration/design however is there another way to accomplish this?

One workaround would be to start BIRD with disabled BGP protocols and then
use 'birdc enable bgpX' to start them, but that would have another
problem - any reconfiguration would disable them back.

Another workaround would be to use another BIRD just to announce your
public IP prefixes to your border routers by iBGP. Therefore a restarted
border router would not announce anything until it connects to this one
using iBGP which naturally depends on convergence of OSPF in internal
network.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140503/b42b5596/attachment-0001.asc>