From henk at ripe.net Tue May 27 10:18:58 2008 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 27 May 2008 10:18:58 +0200 Subject: [ris-int] [Fwd: Quagga question] Message-ID: <483BC3F2.10107@ripe.net> Hi RIS team, See below. Any comments or ideas? Olaf helped with us on myASn in the past, so we should say a little bit more than just a standard answer. Henk -------- Original Message -------- Subject: Quagga question Date: Tue, 27 May 2008 09:42:26 +0300 From: Olaf Maennel To: Henk Uijterwaal CC: Ashley Flavel Dear Henk, how are you? haven't heard from you for a while now... Hope everything is okay?! Ashley, one of my colleagues in Australia, was looking into errors in quagga and suspects that updates could sometimes be reordered if they arrive within a very short time (= not written to file in chronological order). Are you aware of anything like that? Thanks, olaf On 27/05/08 4:44 AM, "Ashley Flavel" wrote: > Hi guys, > > I'm looking at making the CleanBGP stuff usable by others (including > myself). Just found an interesting 'feature' of the data. I'm not > sure if it is a bug in the Quagga route monitor collecting the data, > but this is what is happening... > > If two updates are received at the same timestamp for the same prefix, > I have been assuming that the ordering of them in the file dictates > which order they were received in. However, this is not necessarily > the case :( I have found cases where a prefix is updated twice in the > same second and the ordering of the updates is incorrect in the files > (I know this as I have tables which tell me the entry which is > present). It gets worse... I have also found cases where updates with > a gap of 1 second are recorded in the incorrect order. > > I have a way to deal with this... I keep a history of the last update > prior to the current update (if it is within 5 seconds -- I could make > this larger if I needed to). Then when I compare my constructed table > at a timestamp, if a difference occurs, I can check if this is as a > result of the ordering of 'almost simultaneous' updates. > > So... although this is annoying -- it also adds to the 'things you > need to be careful about' when analysing the data. > > Ash > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections From eromijn at ripe.net Tue May 27 10:52:24 2008 From: eromijn at ripe.net (Erik Romijn) Date: Tue, 27 May 2008 10:52:24 +0200 Subject: NCC#2008053970 [ris-int] [Fwd: Quagga question] In-Reply-To: <483BC3F2.10107@ripe.net> References: <483BC3F2.10107@ripe.net> Message-ID: Hi, we've never seen this problem, but we've never specifically looked for it either. I have been doing things with the dump code for ASN32, so I know some parts of it. Looking into the code briefly just now, the dumping of the packet seems to be done by bgp_dump_packet_func, which is called by bgp_dump_packet which is called by bgp_read (which processes incoming BGP packets). So, it would seem that the processing of the packet is done -after- the dump, but I'm not sure about it. If so, it could be that the BGP route handling in quagga actually switches the order around or has some other bug, and that the dump is correct. OTOH, the dump code is probably one of the least tested parts... I would suggest confirming with tcpdump whether the dumpfile is actually in the wrong order, to be sure that the bug is not actually in the BGP handling. However, I have no time to do this. But, as it may affect RIS, I'd like to know about any news :) cheers, Erik On May 27, 2008, at 10:18 AM, Henk Uijterwaal wrote: > Hi RIS team, > > See below. Any comments or ideas? > > Olaf helped with us on myASn in the past, so we should say a little > bit > more than just a standard answer. > > Henk > > > -------- Original Message -------- > Subject: Quagga question > Date: Tue, 27 May 2008 09:42:26 +0300 > From: Olaf Maennel > To: Henk Uijterwaal > CC: Ashley Flavel > > > Dear Henk, > > how are you? haven't heard from you for a while now... Hope > everything is > okay?! > > Ashley, one of my colleagues in Australia, was looking into errors > in quagga > and suspects that updates could sometimes be reordered if they > arrive within > a very short time (= not written to file in chronological order). > Are you > aware of anything like that? > > Thanks, > > olaf > > > > On 27/05/08 4:44 AM, "Ashley Flavel" > wrote: >> Hi guys, >> I'm looking at making the CleanBGP stuff usable by others (including >> myself). Just found an interesting 'feature' of the data. I'm not >> sure if it is a bug in the Quagga route monitor collecting the data, >> but this is what is happening... >> If two updates are received at the same timestamp for the same >> prefix, >> I have been assuming that the ordering of them in the file dictates >> which order they were received in. However, this is not necessarily >> the case :( I have found cases where a prefix is updated twice in >> the >> same second and the ordering of the updates is incorrect in the files >> (I know this as I have tables which tell me the entry which is >> present). It gets worse... I have also found cases where updates >> with >> a gap of 1 second are recorded in the incorrect order. >> I have a way to deal with this... I keep a history of the last update >> prior to the current update (if it is within 5 seconds -- I could >> make >> this larger if I needed to). Then when I compare my constructed >> table >> at a timestamp, if a difference occurs, I can check if this is as a >> result of the ordering of 'almost simultaneous' updates. >> So... although this is annoying -- it also adds to the 'things you >> need to be careful about' when analysing the data. >> Ash > > > > > > -- > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > Is one of the choices leaving the office open? > Alan Greenspan on the next > elections > -- Erik Romijn RIPE NCC software engineer http://www.ripe.net/ Information Services dept. From ruben at ripe.net Tue May 27 11:16:10 2008 From: ruben at ripe.net (Ruben van Staveren) Date: Tue, 27 May 2008 11:16:10 +0200 Subject: NCC#2008053970 [ris-int] [Fwd: Quagga question] In-Reply-To: References: <483BC3F2.10107@ripe.net> Message-ID: <452CCC77-E826-4017-AA3C-876931A0FBF8@ripe.net> Hoi, On 27 May 2008, at 10:52, Erik Romijn wrote: > Hi, > > However, I have no time to do this. But, as it may affect RIS, I'd > like to know about > any news :) I think it might be worthwhile to have a shadow rrc as a testbed for quagga. It would get it's data by peering with one of the other rrc's (preferably one of the least busiest ) and just does the dumping so you can compare the dumps > > > cheers, > Erik - Ruben -- Ruben van Staveren RIPE Network Coordination Center Information Services Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444 PGP finger print 6501 4389 A675 477E DCE5 53D8 9108 49E2 DAFC 271B -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From henk at ripe.net Tue May 27 12:39:10 2008 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 27 May 2008 12:39:10 +0200 Subject: NCC#2008053970 [ris-int] [Fwd: Quagga question] In-Reply-To: <452CCC77-E826-4017-AA3C-876931A0FBF8@ripe.net> References: <483BC3F2.10107@ripe.net> <452CCC77-E826-4017-AA3C-876931A0FBF8@ripe.net> Message-ID: <483BE4CE.1050206@ripe.net> Ruben van Staveren wrote: > > Hoi, > > > On 27 May 2008, at 10:52, Erik Romijn wrote: > >> Hi, >> >> However, I have no time to do this. But, as it may affect RIS, I'd >> like to know about >> any news :) > > I think it might be worthwhile to have a shadow rrc as a testbed for > quagga. It would get it's data by peering with one of the other rrc's > (preferably one of the least busiest ) and just does the dumping so you > can compare the dumps Actually, I think you need a very busy RRC then do something like: BGP-feed ---> | DAG Card | ---> | RRC | +----------+ +-----+ | | Updates Updates | | V V File File Then compare the order in which they appear on the file. Henk >> >> >> cheers, >> Erik > > > - Ruben > > > -- > Ruben van Staveren RIPE Network Coordination Center > Information Services Singel 258 Amsterdam NL > http://www.ripe.net +31 20 535 4444 > PGP finger print 6501 4389 A675 477E DCE5 53D8 9108 49E2 DAFC 271B > > > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections