From alexis at pch.net Fri Oct 9 19:35:22 2015 From: alexis at pch.net (Alexis Fasquel) Date: Fri, 9 Oct 2015 10:35:22 -0700 Subject: Parsing issues with bgpdump (unknown attribute 0) Message-ID: <81F3D530-2F0C-49D8-A5E4-A7567F6F02B4@pch.net> 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 +1-415-694-0585 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-10-09 03.48.10.png Type: image/png Size: 123746 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-10-09 04.11.44.png Type: image/png Size: 133693 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: route-collector.pao.pch.net-mrt-bgp-updates-2015-08-01-04-12.gz Type: application/x-gzip Size: 6787 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cpetrie at ripe.net Sat Oct 10 13:22:16 2015 From: cpetrie at ripe.net (Colin Petrie) Date: Sat, 10 Oct 2015 13:22:16 +0200 Subject: Parsing issues with bgpdump (unknown attribute 0) In-Reply-To: <81F3D530-2F0C-49D8-A5E4-A7567F6F02B4@pch.net> References: <81F3D530-2F0C-49D8-A5E4-A7567F6F02B4@pch.net> Message-ID: <5618F4E8.7040209@ripe.net> Hi Alexis, I would suspect you have a corrupted dump file. If I run 'bgpdump -v' over your provided dump file, I get the same output as you, but also on stderr: [warn] ERROR attribute is truncated: expected=98 remaining=17 [warn] ERROR attribute is truncated: expected=129 remaining=16 [warn] ERROR attribute is truncated: expected=65535 remaining=29 [warn] ERROR attribute is truncated: expected=65535 remaining=18 [warn] ERROR attribute is truncated: expected=98 remaining=25 [warn] ERROR attribute is truncated: expected=65535 remaining=11 [warn] ERROR attribute is truncated: expected=65535 remaining=1 [warn] ERROR attribute is truncated: expected=65535 remaining=1 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [error] bgpdump_read_next: incomplete dump record (0 bytes read, expecting -1) So a length field somewhere is telling the parser to read an incorrect amount of data from the stream, which then throws off the field alignment. You'd probably need to stare at your MRT file with a hex editor for a while if you want to find the problem :) Of course, how bgpdump handles it (or doesn't!) might be better :) it could probably do a better job of trying to re-align on later messages. Hope this helps, Cheers, Colin On 09/10/15 19:35, Alexis Fasquel wrote: > 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. -- Colin Petrie Systems Engineer RIPE NCC From adomaja at yahoo.com Sun Oct 11 12:26:28 2015 From: adomaja at yahoo.com (Ado Maja) Date: Sun, 11 Oct 2015 10:26:28 +0000 (UTC) Subject: Implicit Withdrawal - BGP Update Message References: <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrigna at dia.uniroma3.it Sun Oct 11 14:03:21 2015 From: patrigna at dia.uniroma3.it (Maurizio Patrignani) Date: Sun, 11 Oct 2015 14:03:21 +0200 Subject: Implicit Withdrawal - BGP Update Message In-Reply-To: <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> References: <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> Message-ID: <561A5009.7070303@dia.uniroma3.it> Dear Ado, the term "implicit withdrawal" applies to a BGP update U_2 that comes to a BGP speaker from the same peer P that sent a previous update U_1. When the peer P sends the second update U_2, the meaning is that the previous update U_1 is implicitly withdrawn by P and replaced with U_2. In other words, the sequence U_1, U_2 has the same effect of U_1, Withdrawal, U_2. The four BGP announcements that you list in your email do not come all from the same peer of router 192.65.185.40. However, the third announcement (FROM: 192.65.185.144, AS_PATH: 6893 3561 209 297) is an implicit withdrawal of the first (FROM: 192.65.185.144, AS_PATH: 6893 8938 1 297). There is only one implicit withdrawal in the sequence. After all four announcements are received by router 192.65.185.40, router 192.65.185.40 has to choose its best route to prefix 192.152.102.0/24. The choice is among the 2nd, 3rd and 4th route, since the 1st announcement is implicitly withdrawn by the 3rd. Best, Maurizio On 10/11/2015 12:26 PM, Ado Maja wrote: > 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:06 > TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP > FROM: 192.65.185.144 > TO: 192.65.185.40 > BGP PACKET TYPE: UPDATE > ORIGIN: IGP > AS_PATH: 6893 8938 1 297 > NEXT_HOP: 192.65.185.144 > ANNOUNCED: 192.152.102.0/24 > TIME: 2001-9-16 00:00:18 > TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP > FROM: 192.65.184.3 > TO: 192.65.185.40 > BGP PACKET TYPE: UPDATE > ORIGIN: IGP > AS_PATH: 513 10764 6509 297 > NEXT_HOP: 192.65.185.9 > ANNOUNCED: 192.152.102.0/24 > TIME: 2001-9-16 00:00:36 > TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP > FROM: 192.65.185.144 > TO: 192.65.185.40 > BGP PACKET TYPE: UPDATE > ORIGIN: IGP > AS_PATH: 6893 3561 209 297 > NEXT_HOP: 192.65.185.144 > ANNOUNCED: 192.152.102.0/24 > TIME: 2001-9-16 00:00:44 > TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP > FROM: 192.65.185.130 > TO: 192.65.185.40 > BGP PACKET TYPE: UPDATE > ORIGIN: IGP > AS_PATH: 559 8933 6509 297 > NEXT_HOP: 192.65.185.130 > ANNOUNCED: 192.152.102.0/24 -- Maurizio "Titto" Patrignani Dipartimento di Ingegneria, Universita' Roma Tre Tel +39.06.57333233, Fax +39.06.57333612 http://www.dia.uniroma3.it/~patrigna -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpetrie at ripe.net Sun Oct 11 14:21:34 2015 From: cpetrie at ripe.net (Colin Petrie) Date: Sun, 11 Oct 2015 14:21:34 +0200 Subject: Implicit Withdrawal - BGP Update Message In-Reply-To: <561A5009.7070303@dia.uniroma3.it> References: <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> <1916664772.2046706.1444559188541.JavaMail.yahoo@mail.yahoo.com> <561A5009.7070303@dia.uniroma3.it> Message-ID: <561A544E.50700@ripe.net> Hi Ado, It will also depend on whether your update messages are immediately preceded by a BGP session state change for a given peer IP (transitioning to state 6 (established)). If the session has just reset, then the first message you see for a {peer,prefix} is an announce, and subsequent announces (for the same {peer,prefix} but a different path) are implicit withdrawals. But if you just analyze a batch of RIS update files for a given time window, it is not correct to assume that the first message for a {peer,prefix} is a new announce. You'd need to load the RIB dump (bview) from just before your time window, to establish if the prefix was already in the RIB, to determine if the first announce you see is a new announce or also an implicit withdrawal. You'll also need to take into account, the session resets that occur during your time window. If a state change occurs, that will also effectively withdraw all the prefixes already received from that peer. Cheers, Colin On 11/10/15 14:03, Maurizio Patrignani wrote: > Dear Ado, > > the term "implicit withdrawal" applies to a BGP update U_2 that comes > to a BGP speaker from the same peer P that sent a previous update U_1. > When the peer P sends the second update U_2, the meaning is that the > previous update U_1 is implicitly withdrawn by P and replaced with U_2. > In other words, the sequence U_1, U_2 has the same effect of U_1, > Withdrawal, U_2. > The four BGP announcements that you list in your email do not come > all from the same peer of router 192.65.185.40. However, the third > announcement (FROM: 192.65.185.144, AS_PATH: 6893 3561 209 297) is an > implicit withdrawal of the first (FROM: 192.65.185.144, AS_PATH: 6893 > 8938 1 297). There is only one implicit withdrawal in the sequence. > After all four announcements are received by router 192.65.185.40, > router 192.65.185.40 has to choose its best route to prefix > 192.152.102.0/24. The choice is among the 2nd, 3rd and 4th route, since > the 1st announcement is implicitly withdrawn by the 3rd. > > Best, > Maurizio > > On 10/11/2015 12:26 PM, Ado Maja wrote: >> 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:06 >> TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP >> FROM: 192.65.185.144 >> TO: 192.65.185.40 >> BGP PACKET TYPE: UPDATE >> ORIGIN: IGP >> AS_PATH: 6893 8938 1 297 >> NEXT_HOP: 192.65.185.144 >> ANNOUNCED: 192.152.102.0/24 >> >> TIME: 2001-9-16 00:00:18 >> TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP >> FROM: 192.65.184.3 >> TO: 192.65.185.40 >> BGP PACKET TYPE: UPDATE >> ORIGIN: IGP >> AS_PATH: 513 10764 6509 297 >> NEXT_HOP: 192.65.185.9 >> ANNOUNCED: 192.152.102.0/24 >> >> TIME: 2001-9-16 00:00:36 >> TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP >> FROM: 192.65.185.144 >> TO: 192.65.185.40 >> BGP PACKET TYPE: UPDATE >> ORIGIN: IGP >> AS_PATH: 6893 3561 209 297 >> NEXT_HOP: 192.65.185.144 >> ANNOUNCED: 192.152.102.0/24 >> >> TIME: 2001-9-16 00:00:44 >> TYPE: BGP4MP/BGP4MP_MESSAGE AFI_IP >> FROM: 192.65.185.130 >> TO: 192.65.185.40 >> BGP PACKET TYPE: UPDATE >> ORIGIN: IGP >> AS_PATH: 559 8933 6509 297 >> NEXT_HOP: 192.65.185.130 >> ANNOUNCED: 192.152.102.0/24 > > > -- > Maurizio "Titto" Patrignani > Dipartimento di Ingegneria, Universita' Roma Tre > Tel +39.06.57333233, Fax +39.06.57333612 > http://www.dia.uniroma3.it/~patrigna > -- Colin Petrie Systems Engineer RIPE NCC From adomaja at yahoo.com Sun Oct 11 18:21:17 2015 From: adomaja at yahoo.com (Ado Maja) Date: Sun, 11 Oct 2015 16:21:17 +0000 (UTC) Subject: Implicit Withdrawal - BGP Update Message References: <1003153244.2016024.1444580477599.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1003153244.2016024.1444580477599.JavaMail.yahoo@mail.yahoo.com> 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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpetrie at ripe.net Sun Oct 11 18:41:53 2015 From: cpetrie at ripe.net (Colin Petrie) Date: Sun, 11 Oct 2015 18:41:53 +0200 Subject: Implicit Withdrawal - BGP Update Message In-Reply-To: <1003153244.2016024.1444580477599.JavaMail.yahoo@mail.yahoo.com> References: <1003153244.2016024.1444580477599.JavaMail.yahoo@mail.yahoo.com> <1003153244.2016024.1444580477599.JavaMail.yahoo@mail.yahoo.com> Message-ID: <561A9151.6090407@ripe.net> Hi Ado, On 11/10/15 18:21, Ado Maja wrote: > It was by mistake that I send an example where BGP messages are not > coming from the same peer. All four messages in the example were > supposed to have same peer, and announced IP address while different > AS-PATH attribute. > In that case I would have three implicit withdrawals, right? Yes, if all four messages were the same prefix and same peer, then you would have three (or four) implicit withdrawals. > Are you suggesting that if I look at five-days worth of BGP update > messages and trying to count how many implicit withdrawals during that > time I have that I need to check first appearance of every announced IP > address and check if it is ?truly? new announcement or possibly an > implicit withdrawal that happened prior to the time frame I am looking at? Yes exactly, if you want to be accurate in your count. That is what the RIB dumps (the bview) files help you with. They give you a snapshot at a time, for you to base your update analysis on. Otherwise you'd need to search through previous update files looking for either an earlier update message for the same {peer,prefix}, or a peer session reset. > Also, I was completely ignoring the state change messages. Are you > referring to the messages below? I am not sure what to make out of those. Yes those are the state change messages. They indicate a transition in the BGP Finite State Machine for a BGP speaker (see RFC4271, section 8) For the most part, you can ignore all of them except for transitions to/from state 6 (Established). If a peer session goes in or out of state 6, then a new session has been established or torn down, and any data you were considering about that peer should be reset too. If the session resets, whenever it comes back up, it is likely that the peer will re-announce the prefixes it had in its RIB before the reset. This is the initial startup phase. So when the peer sends you an announce for a prefix after a state change, the first announcement is *not* an implicit withdrawal. But any further messages after that (with the same {peer,prefix}) are implicit withdrawals. Until the next time the state changes. Hope this makes sense. Cheers Colin -- Colin Petrie Systems Engineer RIPE NCC From alexis at pch.net Mon Oct 12 07:09:42 2015 From: alexis at pch.net (Alexis Fasquel) Date: Sun, 11 Oct 2015 22:09:42 -0700 Subject: Parsing issues with bgpdump (unknown attribute 0) In-Reply-To: <5618F4E8.7040209@ripe.net> References: <81F3D530-2F0C-49D8-A5E4-A7567F6F02B4@pch.net> <5618F4E8.7040209@ripe.net> Message-ID: Hi Colin, Thank you for your answer, I was also suspecting file corruption, although I have to admit that I was hoping that it would not be it :) I guess my next move is to understand why some of my files get corrupted. Thank you agin for the help! Cheers, Alexis > On 10 Oct 2015, at 04:22, Colin Petrie wrote: > > Hi Alexis, > > I would suspect you have a corrupted dump file. > > If I run 'bgpdump -v' over your provided dump file, I get the same > output as you, but also on stderr: > > [warn] ERROR attribute is truncated: expected=98 remaining=17 > [warn] ERROR attribute is truncated: expected=129 remaining=16 > [warn] ERROR attribute is truncated: expected=65535 remaining=29 > [warn] ERROR attribute is truncated: expected=65535 remaining=18 > [warn] ERROR attribute is truncated: expected=98 remaining=25 > [warn] ERROR attribute is truncated: expected=65535 remaining=11 > [warn] ERROR attribute is truncated: expected=65535 remaining=1 > [warn] ERROR attribute is truncated: expected=65535 remaining=1 > [warn] process_zebra_bgp_message: unsupported AFI 4096 > [warn] process_zebra_bgp_message: unsupported AFI 4096 > [warn] process_zebra_bgp_message: unsupported AFI 4096 > [warn] process_zebra_bgp_message: unsupported AFI 4096 > [warn] process_zebra_bgp_message: unsupported AFI 4096 > [warn] process_zebra_bgp_message: unsupported AFI 4096 > [error] bgpdump_read_next: incomplete dump record (0 bytes read, > expecting -1) > > So a length field somewhere is telling the parser to read an incorrect > amount of data from the stream, which then throws off the field alignment. > > You'd probably need to stare at your MRT file with a hex editor for a > while if you want to find the problem :) > > Of course, how bgpdump handles it (or doesn't!) might be better :) it > could probably do a better job of trying to re-align on later messages. > > Hope this helps, > > Cheers, > Colin > > > On 09/10/15 19:35, Alexis Fasquel wrote: >> 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. > > -- > Colin Petrie > Systems Engineer > RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From adomaja at yahoo.com Mon Oct 12 16:51:30 2015 From: adomaja at yahoo.com (Ado Maja) Date: Mon, 12 Oct 2015 14:51:30 +0000 (UTC) Subject: ZEBRA vs. libBGPdump parser References: <1922349806.2407980.1444661490277.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1922349806.2407980.1444661490277.JavaMail.yahoo@mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpetrie at ripe.net Tue Oct 13 10:23:49 2015 From: cpetrie at ripe.net (Colin Petrie) Date: Tue, 13 Oct 2015 10:23:49 +0200 Subject: New on RIPE Labs: Updates to the RIPE NCC Routing Information Service Message-ID: <561CBF95.8020103@ripe.net> 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-information-service Kind regards, Colin Petrie RIPE NCC From cpetrie at ripe.net Fri Oct 16 16:40:17 2015 From: cpetrie at ripe.net (Colin Petrie) Date: Fri, 16 Oct 2015 16:40:17 +0200 Subject: ZEBRA vs. libBGPdump parser In-Reply-To: <1922349806.2407980.1444661490277.JavaMail.yahoo@mail.yahoo.com> References: <1922349806.2407980.1444661490277.JavaMail.yahoo@mail.yahoo.com> <1922349806.2407980.1444661490277.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56210C51.3090000@ripe.net> On 12/10/15 16:51, Ado Maja wrote: > 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. bgpdump.c uses gmtime() zebra-dump-parser.pl uses localtime() > Which one can I take as correct one? They are both correct ;-) -- Colin Petrie Systems Engineer RIPE NCC