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