Skip to Content.

rare-dev - Re: [rare-dev] RES: perfSONAR on RARE/FreeRtr

Subject: Rare project developers

List archive


Re: [rare-dev] RES: perfSONAR on RARE/FreeRtr


Chronological Thread 
    < Chronological >      < Thread >
  • From: Tim Chown <>
  • To: "" <>, Pavle Vuletić <>
  • Cc: Marcos Felipe Schwarz <>, Frédéric LOUI <>, Ivana Golub <>, Xavier Jeannin <>, Mohácsi János <>, Visky Balázs <>
  • Subject: Re: [rare-dev] RES: perfSONAR on RARE/FreeRtr
  • Date: Fri, 26 Aug 2022 10:17:02 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jisc.ac.uk; dmarc=pass action=none header.from=jisc.ac.uk; dkim=pass header.d=jisc.ac.uk; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5nMSZv1RdiHOL0m2kEr8vrGW4t0PdfGEl2opvcKEMt4=; b=K0x/6x/holTVopoMN5uFXwfHe/fCjEvYXeCHL3COA140R3RYR4bSRGyAhfPyu1ldHmtXx9Fgz9UNq4b/zhWptmqEb1rR+t4mVU848Nnc9nbk6YQ1CtPdIT2Olv+ocWOR5t0eJZpNvPayBv2LvlE5l+sN+9MZiqB8xwCYeFfktBY9NFtNVNXRAuMWcdfEYDF/oVJLA05QDtRQ/h+0UPO7NweJ+DuVQ9NfO2yqJ1ADlV9q8LBdf/hzxBOTDzdnN4BHAcr8qI8ifYxZB0NJ5/J+yMFWo9HhsbRQ6kdEbCDoh7ie1hENSX7YZvaDozI4lirZ8EapCX9Y1m7XjhV8/fezww==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h/GOBtqn0ooaZIgMFgKX/WCNiWKJhIop/IrGU/nThtX4KPRoSDEmOyxWFeiicPd1rLEUJutnZ3LqKELrQoTz8P0jfMVWPOe6spjBh20upoLz/a/e4aNfXVI8w/nwZxXkcN8TM+bX97C1kA4pcUQ7PArDNCaNGe1INKtLrneccWZ45P2jvdm4T9wrmmBo3yfDwC/AYbjKgl6dadBcPGvqnG2LKwKDQJH/GmywTFZnZGg9L4fdxxb0rbWp2d6b6i0iZRLj8toM1SfiCbA91zND9Bb7GBI4zm0mQGSJoGGPHN0asJmQERL3okNRAJ0NkU8mOk59DJ5he7zWL/cL6LcjsQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jisc.ac.uk;
This might be interesting for Olav’s microdep work in Task 3, copying Pavle.

> On 26 Aug 2022, at 11:14, mc36 <> wrote:
>
> if you need, and since this output is good as is, if you need this in
> streaming telemetry or prometheus then that...
> in kifu we went the prometheus way and this table _graphs_ nicely when
> there is a flappy (i/e)bgp somewhere
>
> On 8/26/22 12:12, mc36 wrote:
>> or maybe a bmp demo?
>> if they shut the backup geant link then it'll become false, and the change
>> will be 2...
>> when they noshut it, then the state will be true again, but the change
>> will be 3...
>> so if you didn't listened to janos at that time, we disabled snmp for
>> years now...
>> bmp.wdcvhpc#show bmp bmp
>> from peer
>> as state change last
>> 195.111.97.83 152.66.0.124
>> 2547 true 1 5d14h
>> 195.111.97.83 195.111.103.206
>> 12301 true 1 5d14h
>> 195.111.97.108 62.40.96.23
>> 20965 true 1 5d14h
>> 195.111.97.108 62.40.96.24
>> 20965 true 1 5d14h
>> 195.111.97.108 62.40.102.26
>> 20965 true 1 5d14h
>> 195.111.97.108 62.40.124.101
>> 20965 true 1 5d14h
>> 195.111.97.108 80.239.195.56
>> 1299 true 1 5d14h
>> 195.111.97.108 81.183.2.166
>> 5483 true 1 5d14h
>> 195.111.97.108 83.97.88.81
>> 21320 true 1 5d14h
>> 195.111.97.108 94.21.255.13
>> 20845 true 1 5d14h
>> 195.111.97.108 193.188.137.1
>> 5507 true 1 5d14h
>> 195.111.97.108 193.188.137.2
>> 5507 true 1 5d14h
>> 195.111.97.108 193.188.137.53
>> 5400 true 1 5d14h
>> 195.111.97.108 193.188.137.74
>> 8708 true 1 5d14h
>> 195.111.97.108 193.188.137.125
>> 3303 true 1 5d14h
>> 195.111.97.108 193.188.137.142
>> 199524 true 1 5d14h
>> 195.111.97.108 193.188.137.175
>> 6939 true 1 5d14h
>> 195.111.97.108 193.224.231.138
>> 65012 true 1 5d14h
>> 195.111.97.108 195.191.97.254
>> 59649 true 1 5d14h
>> 195.111.97.108 213.222.185.3
>> 21334 true 1 5d14h
>> 195.111.97.108 2001:738:1040:193:224:231:136:138 65012 true 1
>> 5d14h
>> 195.111.97.108 2001:798:1::65
>> 21320 true 1 5d14h
>> 195.111.97.108 2001:798:1b:10aa::5 20965
>> true 1 5d14h
>> 195.111.97.108 2001:7f8:35::3303:1 3303
>> true 1 5d14h
>> 195.111.97.108 2001:7f8:35::5507:1 5507
>> true 1 5d14h
>> 195.111.97.108 2001:7f8:35::5507:2 5507
>> true 1 5d14h
>> 195.111.97.108 2001:7f8:35::6939:1 6939
>> true 1 5d14h
>> 195.111.97.108 2001:2000:3080:14f5::1 1299
>> true 1 5d14h
>> 195.111.97.108 2a01:368:1fe::11
>> 20845 true 1 5d14h
>> 195.111.97.109 62.40.124.17
>> 20965 true 1 5d14h
>> 195.111.97.109 83.97.88.85
>> 21320 true 1 5d14h
>> 195.111.97.109 149.11.10.9
>> 174 true 1 5d14h
>> 195.111.97.109 193.188.137.1
>> 5507 true 1 5d14h
>> 195.111.97.109 193.188.137.2
>> 5507 true 1 5d14h
>> 195.111.97.109 193.188.137.125
>> 3303 true 1 5d14h
>> 195.111.97.109 193.188.137.142
>> 199524 true 1 5d14h
>> 195.111.97.109 193.224.231.142
>> 65012 true 1 5d14h
>> 195.111.97.109 195.191.97.254
>> 59649 true 1 5d14h
>> 195.111.97.109 213.163.3.173
>> 12301 true 1 5d14h
>> 195.111.97.109 2001:738:1040:193:224:231:140:142 65012 true 1
>> 5d14h
>> 195.111.97.109 2001:798:1::69
>> 21320 true 1 5d14h
>> 195.111.97.109 2001:798:10:10aa::15 20965
>> true 1 5d14h
>> 195.111.97.109 2001:7f8:35::3303:1 3303
>> true 1 5d14h
>> 195.111.97.109 2001:7f8:35::5507:1 5507
>> true 1 5d14h
>> 195.111.97.109 2001:7f8:35::5507:2 5507
>> true 1 5d14h
>> 195.111.97.109 2001:978:2:27::7:1 174
>> true 1 5d14h
>> 195.111.97.112 81.183.245.9
>> 5483 true 1 5d14h
>> bmp.wdcvhpc#
>> On 8/26/22 12:05, mc36 wrote:
>>> im not against the perfsonar at all, the more measures the better...
>>>
>>> but to spot the routing and/or prefix changes, we have log-spf in isis,
>>> ospf and lsrp
>>>
>>> if you still use icinga, prometheus any basically anything, all these
>>> could be barked back that is:
>>> the monitoring asks regularly the single management box part of the igp,
>>> as as soon as the routing change happens, the show will differ so it'll
>>> tell you what happened
>>>
>>> frederic, could you please show tim the icinga demo from the p4lab after
>>> to let the others catch the idea?
>>> (no worries, i'll be with you to back you up if the vc will be after my
>>> lunch)
>>>
>>> imho that was the stf15 presentation about:
>>> http://www.freertr.org/present/geant-bmp.pdf
>>> we did it with niall's help, he _flapped_ 2 times the hbone backup link
>>> and we got an alert which needed to be cleared...
>>>
>>>
>>> janos, balazs, if frederic fails to find a proper timeslot, could you
>>> please help a bit here by demoing what happens when you shut
>>> szeged-debrecen for a minute or so?
>>>
>>> thanks,
>>> cs
>>>
>>>
>>>
>>>
>>>
>>> On 8/26/22 11:54, Tim Chown wrote:
>>>>> On 26 Aug 2022, at 10:48, mc36 <> wrote:
>>>>>
>>>>> On 8/26/22 11:41, Tim Chown wrote:
>>>>>>> On 25 Aug 2022, at 14:56, mc36 <> wrote:
>>>>>>>
>>>>>>> hi,
>>>>>>>
>>>>>>> On 8/25/22 15:41, Marcos Felipe Schwarz wrote:
>>>>>>>> 1. supports all perfsonar test, including bandwith at 100G and
>>>>>>>> above. With 2., we'll be limited by the CPU resources of the switch
>>>>>>>> and cpu-todataplane performance, which normally are very limited.
>>>>>>> so true, moreover, if you do 100g measurements in every 10ms then the
>>>>>>> user traffic will be heavily suppressed...
>>>>>>> imho doing a twamp measurements in every 10ms should give good enough
>>>>>>> results
>>>>>> perfSONAR usually runs three types of test - throughput, latency
>>>>>> (including loss), and path. Latency is run continuously (but is very
>>>>>> lightweight), but throughput is only by default run once every 6
>>>>>> hours, for 30 seconds, so it will not generally affect user traffic,
>>>>>> and with TCP tests, it will be fair in competing for
>>>>>> bandwidth.
>>>>> which is partially true as we all know about the bandwidth*delay product
>>>>>
>>>>> consider that you'll perform it over a very long distances
>>>>
>>>> Yes, some tests will be intercontinental, but the R&E backbones are
>>>> generally not congested, so any loss, and thus drop in performance
>>>> (unless maybe using BBR) is likely caused by issues in the end sites.
>>>> There s a few hundred CERN experiment sites running perfSONAR with
>>>> these sorts of tests, usually between countries or continents.
>>>>
>>>> Tim


Archive powered by MHonArc 2.6.19.

Top of Page