Hello, Yes, libbgpdump is a really great tool. We are using it with success. The lib is fast and simple. Unfortunately the source code still use some defines that not follow RFC-6396, example: BGPDUMP_TYPE_ZEBRA_BGP instead BGP4MP.
https://bitbucket.org/ripencc/bgpdump/wiki/Home They say: "This format is described in the Internet Draft grow-mrt-13." According to what they says the lib follow a draft. I don't think it's a big problem because no big changes was done since MRT draft 13 until RFC-6396 but could be a good idea to update the documentation and nomenclatures. The same should be done with Quagga bgpd daemon. -- Pedro On Tue, Nov 27, 2012 at 3:32 PM, Larry Blunk <[email protected]> wrote: > > libbgpdump supports both the BGP4MP_MESSAGE UPDATE message MRT type > and the TABLE_DUMP/TABLE_DUMP_V2 table dump types. > > -Larry > > > > > On 11/27/2012 11:52 AM, Robert Raszuk wrote: >> >> Thx again both Larry and Mattia, >> >> Actually I am more looking for parsing MRT BGP4MP_MESSAGE containing >> bunch of raw UPDATE messages from peers rather then table dumps. >> >> However libbgpdump seems like a good starting point ... if for nothing >> else then for parsing common message headers. >> >> Many thx, >> R. >> >> >> On Tue, Nov 27, 2012 at 5:45 PM, Larry Blunk <[email protected]> wrote: >>> >>> >>> libbgpdump is available at http://www.ris.ripe.net/source/ and >>> contains the bgpdump tool which will read and process the table dump >>> and update files in the Routeviews and RIPE RIS archives. >>> >>> -Larry >>> >>> >>> >>> On 11/27/2012 11:33 AM, Robert Raszuk wrote: >>>> >>>> >>>> Thx Larry ! >>>> >>>> Any pointer to best MRT opensource tools repository for parsing the >>>> messages and maybe even performing some analysis on them (in >>>> particular related to BGP) ? >>>> >>>> Rgs, >>>> R. >>>> >>>> On Tue, Nov 27, 2012 at 5:28 PM, Larry Blunk <[email protected]> wrote: >>>>> >>>>> >>>>> On 11/27/2012 11:17 AM, Robert Raszuk wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> Does anyone (in particular cc-ed authors) recall what is the status, >>>>>> planned update, planned progress to RFC of this document: >>>>>> >>>>>> http://tools.ietf.org/id/draft-ietf-grow-mrt-04.txt >>>>>> >>>>>> Thx, >>>>>> R. >>>>>> >>>>> >>>>> It's an RFC now -- >>>>> >>>>> http://tools.ietf.org/html/rfc6396 >>>>> >>>>> Unfortunately, section 4.3.4 does not match the >>>>> current Quagga/libbgpdump implementations. The RFC >>>>> says to omit the AFI/SAFI/NLRI fields in the MP_REACH_NLRI >>>>> attribute (since that info is already in the MRT >>>>> RIB Entry Header), but the current implementations >>>>> simply copy the attribute as-is in the RIB Entry >>>>> field. >>>>> >>>>> Regards, >>>>> Larry Blunk >>>>> >>>>> >>> > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
