Skip to Content.
Sympa Menu

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: mc36 <>
  • Cc: "" <>, Pavle Vuletić <>, 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 11:02:50 +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=tXLQ5PDwEg7fmOtHzaPgHvCK+9zR4p0gehhnYO2TsPU=; b=iJzAl/JzlI7G2TudSjQEpYePihyhfsyTXPNeS3iWu3aaqzQereKOsim+Yssgby1fwUzvLHkfyBGNPL4v7jRxxh4af49ljmRCsdP9hDJ7g/kjRA9Ykz7E8MW6bXk94PSaNSJa149Tj0YuUQ7kzWqFMFsa3LN8E/jhwZFdFNplZC2BdS1f2XCEE1cmqo+jAcV2EQyPSRgXvmFR6Q6vNoGIjpeuh0ZPRVM+n+FrNCBZ9o0Nr6tnuKGmfCZQUKES03s/x4pJ31A0AN5l+iBcJCPgJhQ/oPkvo4GFt6ABxaoTXkj81HLGTPZLNyKsYPY/zPnm2QS31jxEYv0PvTXIMmNLOQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B8jOGZy6eBdPwfNHTmtLQGm68kn+FAgsxYxhcdae+wSC4pz4LD1TN0x9p1rtYnR5wPoz5xYxVq24EjQU3GBLQrGsDpR7tevu/VdWctbY0j7wvnPf0f1cLqS9utDdDS14wWSbkCFAMVEy1Yf/mqaQWX6xlWEeD6QKrZ8AtpoYpnfjH9drpLzDuYTd/2LikUq2aLHdM+/F25Ibfiye6FeKsI/Og0z+nSo3VVR10pLv4WdysJE04J8W6QQND3LkXYempLig+8uK73owhZvfzGhEqf3pSpd1VbwotE83fGAH0/u/qayI53NhPYUfJ+CMMjBvf+5X/5E4qfSTQsC23+uChw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jisc.ac.uk;
Well, we have different reasons for asking for new features, or for things to
be tested.

In this case, TimeMap and Microdep are work items elsewhere in WP6, and it’s
good, especially as this project nears its end and the new one starts in
January, to show examples of the work streams being able to feed into each
other. Microdep is all about measuring and analysing changes in network
behaviour and paths, it’s really interesting work.

Anyway, I’ll stop there. If Fabio or Claudio don’t respond on TimeMap, the
point is moot.

Tim

> On 26 Aug 2022, at 11:47, mc36 <> wrote:
>
> so please instead of trying to solve yourself and then pushing that, please
> ask for a solution to the original problem....
> dont get misunderstood, we're still happy to implement anything but imho
> this is the way to go if it comes to network monitoring...
> you dont need to consult the routers at all to have the full visibility and
> you can have arbitrary number of monitoring systems in parallel, it wont
> hurt the router cpus....
>
>
>
>
> On 8/26/22 12:17, Tim Chown wrote:
>> 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