- ris-users - mailman.ripe.net

ZEBRA vs. libBGPdump parser
by Ado Maja 16 Oct '15

16 Oct '15

Dear all, I have noticed that when I use Zebra BGP parser the time stamp in BGP update messages (field TIME:) shows delay of exactly two hours in respect to when using libBGPdump parser. Both outputs are exactly same messages but I get two hours delay with Zebra tool. Which one can I take as correct one? libBGPdump output: TIME: 09/18/01 00:00:35TYPE: BGP4MP/MESSAGE/UpdateFROM: 192.65.185.130 AS559TO: 192.65.185.40 AS12654ORIGIN: IGPASPATH: 559 1836 286 1136 1136NEXT_HOP: 192.65.185.130ANNOUNCE 193.176.136.0/21 TIME: 09/18/01 00:00:37TYPE: BGP4MP/MESSAGE/UpdateFROM: 192.65.184.3 AS513TO: 192.65.185.40 AS12654ORIGIN: IGPASPATH: 513 209 6453 11367NEXT_HOP: 192.65.185.9ANNOUNCE 196.12.176.0/24 and Zebra output: TIME: 2001-9-18 02:00:35TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IPFROM: 192.65.185.130TO: 192.65.185.40BGP PACKET TYPE: UPDATEORIGIN: IGPAS_PATH: 559 1836 286 1136 1136NEXT_HOP: 192.65.185.130ANNOUNCED: 193.176.136.0/21 TIME: 2001-9-18 02:00:37TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IPFROM: 192.65.184.3TO: 192.65.185.40BGP PACKET TYPE: UPDATEORIGIN: IGPAS_PATH: 513 209 6453 11367NEXT_HOP: 192.65.185.9ANNOUNCED: 196.12.176.0/24 Best regards, Ado

2 1

New on RIPE Labs: Updates to the RIPE NCC Routing Information Service
by Colin Petrie 13 Oct '15

13 Oct '15

Dear colleagues, We've made some extensive improvements to the RIPE NCC Routing Information Service (RIS) which is an integral part of RIPEstat and heavily used by researchers and network operators. Please find more details on RIPE Labs: https://labs.ripe.net/Members/colin_petrie/updates-to-the-ripe-ncc-routing-… Kind regards, Colin Petrie RIPE NCC

1 0

Parsing issues with bgpdump (unknown attribute 0)
by Alexis Fasquel 12 Oct '15

12 Oct '15

Hello everyone, I’ve been using BGPDump to collect BGP data across multiple BGP server. Unfortunately, I’ve been having some issues parsing some MRT files. So I have a file (provided in attachment) that has been created by a Quagga instance (quagga-0.99.22.1-2013051601). All the beginning of the file seems to be parsed correctly, but at some point, I get a message with unknown attributes. As you can see on the screenshot below, the strange part about it is that the attribute type is supposedly 0 —which is not a correct attribute type if I’m referring to the RFC. Different versions of bgpdump have been tested, without any changes. And the actual issues come up right after: every announcement after this message seems to have something wrong (wrong prefix length/wrong AS path values…): Does anyone already encountered such troubles? Could it be a bug from BGPDump somewhere? Let me know if you have any idea or want some more detail about the issue. Alexis Fasquel Software Engineer @ PCH <http://www.pch.net/> +1-415-694-0585

2 2

Implicit Withdrawal - BGP Update Message
by Ado Maja 11 Oct '15

11 Oct '15

DearMaurizio and Colin, Thank youfor your responses. It was bymistake that I send an example where BGP messages are not coming from the samepeer. All four messages in the example were supposed to have same peer, andannounced IP address while different AS-PATH attribute. In thatcase I would have three implicit withdrawals, right? Colin, Are yousuggesting that if I look at five-days worth of BGP update messages and tryingto count how many implicit withdrawals during that time I have that I need to checkfirst appearance of every announced IP address and check if it is ‘truly’ newannouncement or possibly an implicit withdrawal that happened prior to the timeframe I am looking at? Also, Iwas completely ignoring the state change messages. Are you referring to the messagesbelow? I am not sure what to make out of those. Bestregards, Ado TIME:2001-9-16 00:00:09 TYPE:BGP4MP/BGP4MP_STATE_CHANGE AFI_IP FROM:192.65.185.151 OLD STATE:3 NEW STATE: 2 TIME:2001-9-16 00:00:09 TYPE:BGP4MP/BGP4MP_STATE_CHANGE AFI_IP FROM:192.65.185.151 OLD STATE:2 NEW STATE: 3

2 1

Implicit Withdrawal - BGP Update Message
by Ado Maja 11 Oct '15

11 Oct '15

Dear all,I am trying to account for all implicit withdrawal messages within a certain period of time looking at BGP update messages collected at rrc, Ripe. Implicit Withdrawal Definition: If the sender announces a route to a currently reachable address and the new route is identical to the current route, this is a duplicate announcement. Otherwise, the sender is replacing the current route with a new route and this is an implicit withdrawal. (Wang et al. in the "Observation and Analysis of BGP iBehavior under Stress") What I am trying to understand is how do I count implicit withdrawals? If for example, I have 4 BGP messages shown below that have same IP address and different AS-PATH attribute, how many implicit withdrawals do I have? Is it 3? If I look at consecutive messages that have same IP address and different AS-PATH attribute the result would be 3 (I compare first to the second, second to the third and third to the fourth – assuming they have same IP address and different AS-PATH I increment implicit withdrawals). But I have come across a solution that takes a first message and compares it to the rest of the messages. Than second message compares to the rest of the messages. And lastly compares the third to the fourth. In this case number of implicit withdrawals is 6. Please advise.Thanks for your help.TIME: 2001-9-16 00:00:06TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IPFROM: 192.65.185.144TO: 192.65.185.40BGP PACKET TYPE: UPDATEORIGIN: IGPAS_PATH: 6893 8938 1 297NEXT_HOP: 192.65.185.144ANNOUNCED: 192.152.102.0/24 TIME: 2001-9-16 00:00:18TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IPFROM: 192.65.184.3TO: 192.65.185.40BGP PACKET TYPE: UPDATEORIGIN: IGPAS_PATH: 513 10764 6509 297NEXT_HOP: 192.65.185.9ANNOUNCED: 192.152.102.0/24 TIME: 2001-9-16 00:00:36TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IPFROM: 192.65.185.144TO: 192.65.185.40BGP PACKET TYPE: UPDATEORIGIN: IGPAS_PATH: 6893 3561 209 297NEXT_HOP: 192.65.185.144ANNOUNCED: 192.152.102.0/24 TIME: 2001-9-16 00:00:44TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IPFROM: 192.65.185.130TO: 192.65.185.40BGP PACKET TYPE: UPDATEORIGIN: IGPAS_PATH: 559 8933 6509 297NEXT_HOP: 192.65.185.130ANNOUNCED: 192.152.102.0/24

3 2

libbgpdump 1.4.99.14 released
by Colin Petrie 13 Apr '15

13 Apr '15

Dear Colleagues, The RIPE NCC has released version 1.4.99.14 of libbgpdump, the library that reads RIS raw data files. The following new features have been added in this version: - Support for parsing MRT Type 5 (BGP) messages produced by earlier versions of Quagga/Zebra in the RIS raw data archives Various minor fixes include: - Fix for corruption at the end of bgpdump output - Updated the maximum permitted prefixes handled in a single BGP update message to match the RFC spec - Fix for crashes in int2str handling There will be another release shortly, combining some additional features and fixes for some other reported issues. You can download libbgpdump 1.4.99.14 from: http://www.ris.ripe.net/source/bgpdump/ Development of libbgpdump takes place on the Bitbucket repository: https://bitbucket.org/ripencc/bgpdump/ Please submit any bug reports and/or patches via the Bitbucket issue tracker. Kind Regards, Colin Petrie RIPE NCC

1 0

perl extension Net::BGPdump released
by Matt Sisk 10 Apr '15

10 Apr '15

Hello, I put together a perl extension for libbgpdump if anyone is interested: http://search.cpan.org/dist/Net-BGPdump/ Cheers, Matt

2 1

libbgpdump overall maintenance status, and looking for a security contact
by Christoph Biedl 28 May '14

28 May '14

Hello, according to the archive this list never saw much activity, and has been completely dead the past year. So let's see whether it actually still has readers ... My question is, is there still anyone doing maintenance on libbgpdump? The bug tracker has a few open issues that affect virtually every user of that package. And there are some more, as I wrote in issue #19: | while packaging libbgpdump for the Debian Linux distribution, I | found a few more issues than already listed here. In the spirit of | responsible disclosure I'd like to give you an opportinity fix the | vulnerabilities before they are public. This should be done together | with the at least three longstanding issues #2 (duplicates: #10, | #13, #17, #18), #12 and #15 that can be found here. So whoever is in charge, please get in touch with me. Christoph

2 1

RIS data collection issue
by Romeo Zwart 20 Jun '13

20 Jun '13

Dear all, We have been experiencing some issues with the RIS data collection process yesterday. For details please see: https://www.ripe.net/lir-services/service-announcements/ris-data-collection… Kind regards, Romeo Zwart RIPE NCC

1 0

RIS Statistics Report (2013-06-07 - 2013-06-14)
by Generic RIS Account 15 Jun '13

15 Jun '13

RIS Statistics Report (2013-06-07 - 2013-06-14) This report was generated at Fri, 14 Jun 2013 23:44:59 UTC . It analyses the BGP Routing Tables which are collected by RIS Remote Collectors at different locations around the world. Check http://www.ris.ripe.net/weekly-report/ for more info. Average ASPATH length. average variance max min global 5.22 5.48 66.00 1.00 rrc00 5.26 5.19 66.00 1.00 rrc01 4.98 5.50 65.00 1.00 rrc03 5.15 5.86 64.00 1.00 rrc04 5.49 5.17 64.00 1.00 rrc05 5.19 4.79 64.00 1.00 rrc06 5.47 5.51 58.00 1.00 rrc07 4.93 5.27 63.00 1.00 rrc12 5.08 5.49 64.00 1.00 rrc13 5.52 5.41 65.00 1.00 rrc14 4.87 6.79 63.00 1.00 rrc15 5.86 5.24 66.00 1.00 Warning: not all route collectors returned data, and therefore the results might not be complete

1 0