<div dir="ltr">Hi,<div><br></div><div>i run bird as a route collector in DN42 and so get a variety of different BGP daemons peering with and passing routes to the collector. <div>We recently ran in to an issue where MRT dumps from bird were not readable by any of the common MRT parsers and, on investigation, found a bug in how bird handles the BGP Path Attribute Extended Length flag.</div><div><br></div><div>The issue occurred because peers using the FRR daemon set the Extended Length flag on the AS PATH attribute by default, regardless of the actual data length. When bird re-encodes the AS Path (for example as part of the MRT dump) it correctly re-calculates whether to use an 8 bit or 16 bit length field for the attribute, but simply copies the flags and does not reset the Extended Length flag in the 8 bit case. This results in an AS PATH attribute being output that has the Extended Length flag set but with the actual length field being only 8 bits. Of course, any parsers trying read this get very confused. </div><div><br></div><div>A simple fix is to ensure the Extended Length flag is cleared when encoding the 3 byte attribute header:</div><div><br></div><div>diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c<br>index 6752cb7f..5c7b4fdd 100644<br>--- a/proto/bgp/attrs.c<br>+++ b/proto/bgp/attrs.c<br>@@ -118,7 +118,7 @@ bgp_set_attr(ea_list **attrs, struct linpool *pool, uint code, uint flags, uintp<br> static inline int<br> bgp_put_attr_hdr3(byte *buf, uint code, uint flags, uint len)<br> {<br>-  *buf++ = flags;<br>+  *buf++ = flags & ~BAF_EXT_LEN;<br>   *buf++ = code;<br>   *buf++ = len;<br>   return 3;<br></div><div><br></div><div>Cheers</div><div><br></div><div><br></div><div>Simon</div><div><br></div><div><br></div></div></div>