On 2015-04-16, Mike Hammett <openbsd-m...@ics-il.net> 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.
