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 <olaf@maennel.net> To: Henk Uijterwaal <henk@ripe.net> CC: Ashley Flavel <ashley.flavel@adelaide.edu.au> 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" <ashley.flavel@adelaide.edu.au> 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
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 <olaf@maennel.net> To: Henk Uijterwaal <henk@ripe.net> CC: Ashley Flavel <ashley.flavel@adelaide.edu.au>
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" <ashley.flavel@adelaide.edu.au> 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.
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
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
participants (3)
-
Erik Romijn -
Henk Uijterwaal -
Ruben van Staveren