I would love to have the problem of having so many customers, prefixes and filters that the route server becomes a performance issue. That means the IX has become successful. I know AMS-IX was one that switched from OpenBGPd. They've got somewhere between 600 and 800 networks on the IX. Currently, one building we're in only has 22 networks present. I'm not sure I'll ever hit the issues AMS-IX had.
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. Over time I expect I'll implement increasingly advanced configurations, such as separate RIBs per peer. At the suggestion of separate instances of OpenBGPd for v4 and v6, one could very well do a different VM for v4 and v6. 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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Stuart Henderson" <s...@spacehopper.org> To: misc@openbsd.org Sent: Thursday, April 16, 2015 1:48:29 AM Subject: Re: OpenBGPd Route Server On 2015-04-15, Mike Hammett <openbsd-m...@ics-il.net> wrote: > With the decline of OpenBGPd's popularity among IXPs, it's difficult > to track down examples of how IXPs are configuring their servers. I saw > a couple presentations in the 2010 - 2011 timeframe with new things that > were coming for 32 bit communities among other things. Common IXP setup is to use transparent-as, and to support fine control of where routes are sent by tagging with communities. The latter requires using separate RIBs per peer (when a filter prevents the route server's "best route" from being sent to a particular peer you want another route to be sent instead). AFAIK most IXPs that stopped using OpenBGPd did so because of slow convergence times when filtering many routes. Prior to doing this, the one that I know about had already split to separate daemon instances for v4 and v6 to spread the work amongst more cores. They ran into some other problems (debuggable/fixable) but that was the killer. Current best practice for 32 bit communities is "if you're doing communities-based filtering, hand back the ASN and exchange it for a 16 bit one". Seriously. There are "extended communities" but they suffer the IPv6 problem of changing too much, plus they don't even solve the problem (they're 16 + 32 bit, where what is needed is 32 + 32 bit).
