iBGP migration to 1.3.0 [Was: Re: Patch to fix BGP ghost routes resulting from loops]

Ondrej Zajicek santiago at crfreenet.org
Sat Apr 2 12:16:38 CEST 2011


On Sat, Apr 02, 2011 at 07:53:35AM +0200, Adrian Czapek wrote:
> Oh, thanks for refreshing this thread, it gives some light on my  
> mysterious problem I encountered yesterday while trying to upgrade from  
> 1.2.5>1.3.0 on one of my route reflector client.
> I just switched binaries and left the same config, and when I started  
> new bird, all my iBGP routes became unreachable. I didn't had time to  
> debug it so I quickly turned back to 1.2.5 and left the problem for next  
> week.

> Did I miss something? Shall I change something in configuration to have  
> route reflector client working properly?

So i understand that routes appear in the routing table but with
unreachable destination? This is related not to mentioned patch, but to
main changes in iBGP that triggered this major release, and it is
probably unrelated to route reflector setting. Essentially, the next hop
from NEXT_HOP attribute have to be resolvable through the routing table.
See option 'gateway direct|recursive' in the documentation.

Essentially, you have have three possibilities:

 - Just switch to the old behavior using 'gateway direct'.

 - If you have flat topology (one L2 network with attached border BGP
routers) and do not use OSPF, you may add device routes using direct
protocol, in that case you also have to add 'next hop self' to iBGP
protocol on BGP border routers (not to the route server), because
without that NEXT_HOP contains IP address of the border router of
neighbor AS, which is usually one hop away.

 - If you use OSPF for the internal network, it should work just fine,
but note that you should have in IGP table not only internal networks,
but also the border networks connecting local and neighbor's border
routers.

-- 
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/20110402/d7833711/attachment-0001.asc>


More information about the Bird-users mailing list