Rare project developers

[mc36 <>]

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