Hi, at BCIX we still use OpenBGPd as transparent route server. With about 120 (IPv4 + IPv6) peering sessions it's still stable. We have multiple RIBS per peer but we don't have IRRDB prefix filtering per peer applied, as we know this brings issues regarding performance and convergence times.
When you have peers like AS6939 / he.net with lots of prefixes, you also see higher convergence times even without IRRDB based prefix filtering. But a CPU with high single thread performance helps for this. Most other IXPs switched to bird as of good performance and scalability even with IRRDB prefix filtering per peer activated. Thorleif -- Thorleif Wiik, CTO [email protected] http://www.bcix.de/ https://twitter.com/bcix <http://twitter.com/bcix> https://www.facebook.com/BCIX.Internet.Exchange On Thu, Apr 16, 2015 at 10:40 PM, Stuart Henderson <[email protected]> wrote: > On 2015-04-16, Mike Hammett <[email protected]> wrote: > > I had seen some complaints about OpenBGPd for IX RS usage, but they were > all 2009 - 2011 area. I had assumed the most egregious of them had been > fixed by now. > > I think most of the medium/larger ones have simply stopped using it > unfortunately. > > I think most of the other bugs that would affect IXPs have been squashed > now, the main remaining bgpd bug that I'm aware of won't affect this > use. (filtering is just slow rather than buggy afaik; but then AIUI this > wasn't supposed to be the final implementation of filters ;) > > > Over time I expect I'll implement increasingly advanced configurations, > such as separate RIBs per peer. > > If you allow peers fine-grained control over where their routes are > announced, you need this, otherwise if they are happy for an announcement > ro be sent to all MLP members then it's not necessary. > > > At the suggestion of separate instances of OpenBGPd for v4 and v6, one > could very well do a different VM for v4 and v6. > > Yes that would have a similar effect too. Though it does mean doing OS > updates twice. > > > I did know to get a 16 bit ASN. Is the 32 bit communities issue an > OpenBGPd development issue or a lack of standards\precedent issue? Or, > well, I guess something else. > > Standards. The "32 bit" alternative to communities is "extended > communities" and has support by most software that can use 32-bit ASNs, > but because it's 32+16 bit, you can't use the common "yourasn:otherasn" > syntax if both are 32-bit ASNs. (you can still use yourasn:[arbitrary > 16-bit number] but that makes the common "don't announce to AS XYZ" require > a lookup table to handle AS >= 65536). > > I still don't understand why a similar method as used for AS_PATH/AS4_PATH > wasn't also used for communities.
