OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field

Thu Nov 29 21:21:14 UTC 2012

If you hear anything more, I'd be interesting in knowing about it.  I had a
an upstream going up and down last night; reportedly their BGP process was
core dumping due to a BGP attribute issue.  I never found out what vendor
it was though.

Paul

On Thu, Nov 29, 2012 at 12:33 PM, Michael Sinatra <
michael at rancid.berkeley.edu> wrote:

> 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/[email protected]/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
> >
>
>
>