Jeff and NANOG: We are currently dropping the bad attribute within our network (as293) and are working with the customer to determine the origin of the attribute (equipment, code rev, etc.). The bad attribute should not be leaking beyond our AS at all. If you're filtering routes from AS68, you should be able to resume accepting routes from that AS. michael On 11/29/12 12:44 AM, Jeff Wheeler wrote:
I had two downstream BGP customers experience problem with an OpenBGPd bug tonight. Before diving into detail, I would like to link this mailing list thread, because this is not a new issue and a patch is available: http://www.mail-archive.com/misc@openbsd.org/msg115071.html
For the following DFZ routes, I see wrong use of the fifth bit in the Attribute Flags field: Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin 192.65.95.253 0x0000: 0000 0044 c041 5ffd Updated routes: 128.165.0.0/16 141.111.0.0/16 192.65.95.0/24 192.12.184.0/24 204.121.0.0/16
According to RFC 4271 page 17, "the low-order four bits of the Attribute Flags octet are unused. They MUST be zero when sent and MUST be ignored when received." I read "ignored" to mean, don't tear down the BGP session and print a cryptic error that the user probably will be unable to debug. The OpenBGPd guys clearly agree and have supplied a patch, so affected users should visit the above mailing list link, and install it.
Here are my notes for this RFC page and a small diagram of the packet header, because surprisingly, there isn't one in the RFC already http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry about the poor quality of this, but it is past 3am here, and I know of several operators (besides my downstream customers) who are experiencing this problem right now.
If I were someone who is broken by this right now, I would either patch my OpenBGPd or ask your eBGP neighbors not to send you the above five routes (filtering it on your own OpenBGPd router probably won't help.)
Thanks, I hope this is helpful