update parsing error

[dteach-rv]

INFO: Parsing - (Type: mrt) ERROR: INVALID_MSG at parsebgp_utils.c:39 ERROR: Failed to parse message (-2:Invalid Message) WARNING: Failed to parse -

MRT file http://archive.routeviews.org/route-views.amsix/bgpdata/2021.01/UPDATES/updates.20210102.1830.bz2

https://github.com/CAIDA/libparsebgp/blob/master/lib/parsebgp_utils.c#L39

[dteach-rv]

It looks like this might be caused by a malformed extended community affecting the parsing of NLRI. From the collector. 57695 6939 12956 10429 270559 2001:7f8:1::a505:7695:1 from 2001:7f8:1::a505:7695:1 (78.142.193.34) Origin IGP, valid, external Community: 57695:12000 57695:12002 Extended Community: SoO:0:0 Last update: Thu Feb 4 18:13:25 2021 AS 57695 seems to be the peer flooding this info.

[dteach-rv]

This is most likely due to libparsebgp not supporting BGP add-path. When add-path is enabled, it changes the NLRI encoding to include a path identifier before the Length and Prefix fields. From RFC 7911

   Extended NLRI Encodings

   In order to carry the Path Identifier in an UPDATE message, the NLRI
   encoding MUST be extended by prepending the Path Identifier field,
   which is of four octets.

   For example, the NLRI encoding specified in [RFC4271] is extended as
   the following:

                  +--------------------------------+
                  | Path Identifier (4 octets)     |
                  +--------------------------------+
                  | Length (1 octet)               |
                  +--------------------------------+
                  | Prefix (variable)              |
                  +--------------------------------+

The short term fix is to skip parsing of any add-path enabled peers. The long term fix is to work this additional data into the libparsebgp strucutres.

[kenkeys]

For the record: Although the example message does appear to contain RFC 7911 style extended NLRI encodings, it does not use an RFC 8050 *_ADDPATH subtype, so it is in fact an invalid message. Libparsebgp should recover from the invalid message and be able to continue parsing, as it now does in 9d06052. Adding support for ADDPATH would also be good, but would not fix this issue.

[dteach-rv]

Great. Thanks @kenkeys. This will definitely help address the short term risk of one of our RV peers enabling TX add-path. The BGP daemon in FRR supports it, but the MRT dump functions do not. I've got a bug open in FRR to address this. For posterity. https://github.com/FRRouting/frr/issues/8049 is where that bug is being tracked.