Giter Site home page Giter Site logo

bgpdump's Introduction

bgpdump's People

Contributors

alexisfasquel avatar cunha avatar dependabot[bot] avatar fobser avatar robert-scheck avatar spakka avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bgpdump's Issues

Too many prefixes

When I was running bgpdump I got the Too many prefixes error for some files. For example:
(base) root@devcloud:/data/anycast_monitor/routeviews# /usr/bin/bgpdump -m route-views2.updates.20220308.0015.bz2 | head
2022-03-08 08:33:37 [info] logging to syslog

/var/log/messages-20220307:Mar 7 03:17:09 VM-66-201-centos bgpdump: too many prefixes (1851628600 > 88)
(base) root@devcloud:/data/anycast_monitor/routeviews# date
Tue Mar 8 08:34:37 CST 2022
(base) root@devcloud:/data/anycast_monitor/routeviews# date -u
Tue Mar 8 00:34:43 UTC 2022

But it works ok with another file
(base) root@devcloud:/data/anycast_monitor/routeviews# /usr/bin/bgpdump -m route-views.saopaulo.updates.20220308.0015.bz2 | head
2022-03-08 08:35:22 [info] logging to syslog
BGP4MP|1646698500|A|2001:12f8::223:254|26162|2804:fec:2000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698500|A|2001:12f8::223:254|26162|2804:fec:9000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698501|A|2001:12f8::254|26162|2804:fec:2000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698501|A|2001:12f8::254|26162|2804:fec:9000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698501|A|2001:12f8::218:121|52720|2804:fec:2000::/36|52720 262493|IGP|2001:12f8::218:121|0|0||NAG||
BGP4MP|1646698501|A|2001:12f8::218:121|52720|2804:fec:9000::/36|52720 262493|IGP|2001:12f8::218:121|0|0||NAG||
BGP4MP|1646698501|A|2001:12f8::253|26162|2804:fec:2000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698501|A|2001:12f8::253|26162|2804:fec:9000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698501|A|2001:12f8::223:253|26162|2804:fec:2000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||
BGP4MP|1646698501|A|2001:12f8::223:253|26162|2804:fec:9000::/36|262493|IGP|2001:12f8::212:142|0|0|26162:65011|NAG||

This is running on a Centos machine. I also noticed that the max prefix is changing, could you help me to understand what happened here?

Also, I tried on another machine with the same two files, there's no such problem. Both of the two files can be parsed.

Incorrect parsing of NLRI

When parsing an MRT with this base64 representation (which appears in http://data.ris.ripe.net/rrc00/2010.11/updates.20101107.2220.gz with index 5118):

TNcm+AAQAAEAAABMG2oxbgAAAAEMAAE/wQAEHP////////////////////8APAIAAAAhQAEBAEACDAIFG2oN3TBlvJPHZEADBAwAAT/ACAQbCw0LDQsNCw==

these bytes appear after the path attribute:

0d 0b 0d 0b

and should represent NLRI prefixes.

Parsing these bytes should result in a prefix with length 13 (first byte - 0x0d), where the start address is the first 13 bits of the following two bytes - 0x0b0d, as stated in https://tools.ietf.org/html/rfc4271#section-4.3:

        The Prefix field contains an IP address prefix, followed by
        the minimum number of trailing bits needed to make the end
        of the field fall on an octet boundary.  Note that the value
        of trailing bits is irrelevant.

So, ignoring the trailing bits, the prefix should be 11.8.0.0/13.
However, bgpdump outputs this:

TIME: 11/07/10 22:23:52
TYPE: BGP4MP/MESSAGE/Update
FROM: 12.0.1.63 AS7018
TO: 193.0.4.28 AS12654
ORIGIN: IGP
ASPATH: 7018 3549 12389 48275 51044
NEXT_HOP: 12.0.1.63
COMMUNITY: 6923:3339
ANNOUNCE
  11.13.0.0/13                     

so it appears bgpdump uses full two bytes as the start address, and does not ignore trailing bits.

Furthermore, there is still one byte left in the message, which is not enough to represent a prefix, but bgpdump does not provide any indication of that.

Upstream .so name versioning?

I'm the Fedora and EPEL package maintainer of bgpdump since 2019. As of writing, there still doesn't seem to be proper upstream .so name versioning in libbgpdump.

Yes, I'm aware that something like SOFLAGS="-shared -Wl,-soname,libbgpdump.so.0" could be passed while building (even the correct symlinks need to be generated manually then), but this still doesn't let downstreams know whether the old and the new version are ABI compatible or not, thus this should be IMHO really handled by upstream.

Quoting from section "SONAME handling" from https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning:

The SONAME field is written to the shared object by linker, using (at least in case of ld) the -soname SONAME flags. This can be passed as an option to gcc like this:

$ gcc $CFLAGS -Wl,-soname,libfoo.so.0.n -o libfoo.so.0.n

If you want to check if the SONAME field is set and what value it has, use the objdump command (from binutils):

$ objdump -p /path/to/libfoo.so.0.n | grep 'SONAME'

Please note that this issue is also meant as very kind try to convince you as upstream to start versioning your .so library (as our Fedora Packaging Guidelines request).

Extended Message Support for BGP (RFC 8654)

Now that the RFC is out it would be nice if bgpdump supports it.
Currently when parsing a file longer than 4k it is confused about the number of prefixes in the MP_UNREACH_NLRI attribute (for example), reporting

[error] too many prefixes (20428 > 2050)

long_withdrawal.gz

BGP4MP_ET parsing errors

Hi bgpdump maintainers,

I ran into some weird issues while parsing a RouteViews MRT file.
The file in question is http://routeviews.org/route-views3/bgpdata/2021.04/UPDATES/updates.20210416.1515.bz2.

I'm using the latest bgpdump (commit bd89016) with the following switches: -v, -m, -p. It looks as if the file contains prefixes that don't make any sense. Here are a few examples:

BGP4MP_ET|7680|1618586116.561183|A|104.218.61.166|213262|250.0.0.0/208|213262 38008 6939 32098 13999 262916|IGP|104.218.61.166|0|0|38008:103 64600:103 64601:38008|AG|262916 187.245.92.32|
BGP4MP_ET|13162|1618586139.260903|A|104.218.61.166|213262|0.0.0.0/238|213262 38008 6939 64049 55836 17488|IGP|104.218.61.166|0|0|38008:103 64600:103 64601:38008 65521:20|NAG||
BGP4MP_ET|21837|1618586171.006855|W|104.218.61.166|213262|160.0.0.0/160
BGP4MP_ET|258040|1618586913.681759|A|104.218.61.166|213262|80.0.0.0/127|213262 38008 6939 7738 8167 28292|IGP|104.218.61.166|0|0|38008:103 64600:103 64601:38008 65521:20|NAG||

...and many more
Note the corrupt NLRI - 250.0.0.0/208, 0.0.0.0/238, 160.0.0.0/160, 80.0.0.0/127

Is this a bgpdump bug? A corrupt file? Something else?

And just to make sure we're talking about the same file, here's its hash:

> sha256sum updates.20210416.1515.bz2                                                                                                                                       
5c693ec797d32efb1189bd522ce65fca419d914364c167c1158271f55a12ed83  updates.20210416.1515.bz2

> sha512sum updates.20210416.1515.bz2                                                                                                                                       
3624be266dbfe40947dc4754ec82fcf5f8a632bb90af4dcf704f7fcd961380d4baa559e0dedfb01ced70619b1a8d8220ba1e07b0c62c32b7b364cd9489e6c819  updates.20210416.1515.bz2

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.