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