- ris-users - mailman.ripe.net

New RIS Remote Route Collectors at CATNIX Barcelona, SwissIX Zurich, France-IX Paris and Marseille
by Colin Petrie 12 Nov '15

12 Nov '15

Dear colleagues, The RIPE NCC is pleased to announce three new Remote Route Collectors (RRCs) for the Routing Information Service (RIS). RRC18 is now online at CATNIX in Barcelona. We would like to thank Maria Isabel Gandia, Manel Pérez, and CSUC for their help. RRC20 is now online at SwissIX in Zurich. We would like to thank Ulf Kieber and SwissIX for their help. RRC21 is now online at France-IX Paris and France-IX Marseille, hosted in Paris. We would like to thank Arnaud Fenioux and FranceIX for their help. The data from these new collectors is already available via RIPEstat. The raw data will be available in the archives in the near future. Peering with RIS ---------------- If you would like to peer with us, please fill in the form at: http://www.ris.ripe.net/cgi-bin/peerreg.cgi For more information about peering with RIS, please see: https://www.ripe.net/analyse/internet-measurements/routing-information-serv… About RIS ------------- RIS aims to collect and store Border Gateway Protocol (BGP) routing information and make it publicly available for the Internet community. The RIPEstat tools that provide access to this data can help network operators troubleshoot routing problems by providing eBGP data collected over time without being limited to a single BGP view. RIS deploys RRCs at major Internet exchanges, where they peer with other networks. At this time, RIS has more than 600 peers at 18 different Internet exchanges. For more information, please see: https://ripe.net/ris/ If you have any further questions, please contact <ris at ripe.net> Regards, Colin Petrie Systems Engineer RIPE NCC

1 0

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 12 Oct '15

12 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