perfSONAR User Q&A and Other Discussion

[Nina Jeliazkova <>]

Hi Loukik,

I’ve noticed that the ‘rogue interface’ problem in GEANT2 is partially
fixed now through its removal from service’s configuration. However, the
full fix would involve its replacement with the correct
rt1.bud.hu.geant2.net interface, which is currently missing from the
configuration:

so-0/1/1
description "LowQ Link to ISTF 2 (Pr:T-Systems Id:041/3001)";
address 62.40.125.65/30;

In fact our NREN uses two access circuits to GEANT2
(rt1.bud.hu.geant2.net) with load-balancing enabled and that’s why they
both need to be monitored. Currently, only the following one is present
in GEANT2 RRD MA’s configuration:

so-0/1/0
description "Link to ISTF 1 (Pr:T-Systems Id:041/3002)";
address 62.40.124.109/30;

The whole issue emerged after the second access circuit (Pr:T-Systems
Id:041/3001) was migrated to a new interface, while the old slot was
made available for a new DWS circuit:

so-6/0/0
description "Link to DANTE World Service Telia 10G (Pr:Telia
Id:IC-119706/118178)";
address 213.248.76.30/30;

This is described in GEANT2 TT #914061 (05/10/2006):

http://archive.dante.net/operations/secure/database/noc-tickets-showticket.phtml?absid=2681&noc=geant2

I’m providing all these details, because they suggest a special
workflow, which needs to be established by each participating NREN/NOC.
Either the perfSONAR service configuration files need to be
automatically re-generated periodically (let’s say once every 24 hours)
or such changes should be reflected through well established interaction
between NOC people and monitoring service maintainers. Here in Bulgaria
we’ve found the second solution to work better for us, maybe because we
have a relatively small number of circuits to maintain and few people
working for the NREN/NOC as well ;-)

Kind regards,
Nina


Loukik Kudarimoti написа:
> This should now be resolved. Let me know if it isn't.
>
> There are a few interfaces which are not showing the capacity. This is
> because the script we are using needs to be tweaked to properly pick
> up information about VLANs and such.
>
> Loukik.
>
>
>
> Vedrin Jeliazkov wrote:
>> Hello Mark,
>>
>> Thanks for your feedback!
>>
>> We also noticed this problem a few days ago. One possible thing to
>> check in
>> GEANT2 RRD MA's config is whether the counters in
>>
>> /home/taksometro/cricket-data/bandwidth/rt1.bud.hu.geant2.net/so-6_0_0.rrd
>>
>>
>> are stored indeed in Bps (bytes per second), as reported by the
>> service. They
>> might have been instead multiplied to become bps (bits per second).
>> However,
>> even such multiplication could not justify your findings below, so
>> perhaps
>> only a closer look would reveal the real issue.
>>
>> Best regards,
>> Vedrin
>>
>> Mark Gordon 
>> <>
>>  wrote:
>>
>>  
>>> Hello everyone,
>>>
>>>          I was working with querying utilization data from
>>> measurement archives when I noticed one was reporting utilization
>>> data for an interface greater than it's capacity.  The interface in
>>> question is istf-bckp.rt1.bud.hu.geant2.net (62.40.125.65)
>>> outbound.  At the time I was querying the utilization was 6% over
>>> the capacity, but extending my search backward a little showed that
>>> it had been up as much as 60% above capacity.  I queried the MA with
>>> the following interface ...
>>>
>>> ....<nmwgt:interface
>>>     
>> xmlns:nmwgt="<http://ggf.org/ns/nmwg/topology/2.0/>http://ggf.org/ns/nmwg/topolo
>>
>> gy/2.0/">
>>  
>>> ....    <nmwgt:hostName>rt1.bud.hu.geant2.net</nmwgt:hostName>
>>> ....    <nmwgt:ifName>so-6/0/0</nmwgt:ifName>
>>> ....    <nmwgt:ifDescription>LowQ Link to ISTF 2 (Pr:T-Systems
>>> Id:041/3001)</nmwgt:ifDescription>
>>> ....    <nmwgt:ifAddress>62.40.125.65</nmwgt:ifAddress>
>>> ....    <nmwgt:direction>out</nmwgt:direction>
>>> ....    <nmwgt:authRealm>GEANT2</nmwgt:authRealm>
>>> ....    <nmwgt:capacity>155520000</nmwgt:capacity>
>>> ....</nmwgt:interface>
>>>
>>> and got the following datum like this back
>>>
>>> ....<nmwg:datum timeValue="1184141100" value="2.5468027626764405E8"
>>> valueUnits="Bps"/>
>>>
>>> 2.5468027626764405E8 = 254680276
>>> 254680276 > 155520000
>>>
>>> Thanks
>>> -Mark
>>>     
>>
>>
>>
>>   

-- 
---------------------------------
Dr. Nina Nikolova-Jeliazkova
Institute for Parallel Processing
Bulgarian Academy of Sciences
Acad. G. Bonchev St 25-A
1113 Sofia, Bulgaria
Tel: +359 886 802011
ICQ: 10705013
www: http://ambit.acad.bg/nina
---------------------------------
PGP Public Key
http://cert.acad.bg/pgp-keys/keys/nina-nikolova-0xEEABA669.asc
        8E99 8BAD D804 1A43 27B7  7F87 CF04 C7D1 EEAB A669
---------------------------------------------------------------