perfsonar development work

[Cesaroni Giovanni <>]

HI,
I agree with Jeff on using standard MIBs , since we didn't get any specific request.
We can always consider adding some enterprise MIBs later on.
Within GARR I have changed the error acquisition system,
to consider physical interfaces instead of logical ones and I'm now collecting the following MIBs:

Input Errors -> ifInErrors
Output Errors -> ifOutErrors
Input Drops -> ifInDiscards
Output Drops -> ifOutDiscards

From what I have seen, getting data from all user accesses and from the backbone links,
no Output Errors have occurred and in general if they appear it's too late to prevent the problem since they mean an interface break down.
Input Drops on Juniper are related to other events like, for example, the policer discards that have not to be considered as errors.

Some example plots:


Policer discards:



Input errors:



Output Drops:



As we stated initially, I would consider only the ifInErrors and ifOutDiscards, also given the confirmation I got from the GARR NOC & PERT guys


Cheers,
Giovanni

Nicolas Simar wrote:

Loukik Kudarimoti wrote:

Nicolas Simar wrote:

So what could be the process?

1) Currently Szymon is gathering the information about the counters that are monitored by the NRENs. (ST)
2) Identify what information can identically retrieved across multiple platform. (ST)
3) From that list, we should ask the PERT what counter they would need access to (even if it is currently retrieved by all the NRENs who answered) (GC)
4) Once we got the answer, go for the implementation (RL)

At this moment, if we are only looking for PERT's requirement specification on input errors and packet drops, this sounds fine to me.
(I do have a question. We did a requirements capture at the beginning of this project. Does that provide us any input?)

Yes, it allowed us to see the directions where to get to. Now that we are closer to a final product, we need also to be closer from the way those people will be using the product. In addition, there are several input errors that exists. We want to make sure that we are picking up the right one(s) ;-)

Should we add an additional step between three and four to get a validation from the NOCs (via your NOCs and via the APM mailing list)?

Although doing that would be ideal, I fear that if we don't pick a few candidates and ask them questions, it will be difficult to get a good response in a short period of time.

Yes, this is the best, target few NOC people: those are candidates
- Simon Leinen - switch
- Robert Stoy - dfn
- Matjas Strauss - Arnes
- Toby Rodwel - Dante (to ensure follow-up from their side)

Nicolas

Loukik.

Let me know if this is a suitable approach and the time consideration we would have.

Cheers,
Nicolas


Loukik Kudarimoti wrote:

Cesaroni Giovanni wrote:

Hi,
I was wandering about the choice of the relevant information that could be extracted from the router counters,
I don't know why in particular input errors and output drops have been chosen.
I think it is necessary to involve the PERT, that is the main user of the developed tools and owning the required experience  to validate the choice of what is needed.

I completely agree.
It would then be easier for GEANT2 and all NRENs to understand what exactly is required and who needs it.


Loukik.

I'm anyhow convinced  that what we need are the errors coming from the physical interfaces of  the routers
I'm reporting here just a list of possible parameters which could be an input for the discussion with PERT

for Juniper routers:


 
and for cisco:
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.2.1.2.2.1&translate=Translate&submitValue=SUBMIT&submitClicked=true <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.2.1.2.2.1&translate=Translate&submitValue=SUBMIT&submitClicked=true>
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.2.2.1.1 <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.2.2.1.1>


Giovanni

Szymon Trocha wrote:

Szymon Trocha wrote:

Nicolas Simar wrote:

Hi All,

out of this initial thread, seven NRENs have answered. Thank you very much :-) (see results in attachment and first analyses at the bottom of the email).

But we haven't been able to conclude, we are missing some input from the people who do not monitor the following metrics: (input errors, output drops, link status, router cpu, temperature).

Dear all,

We are talking all the time about input errors and output drops. But these are general terms. Which counters are you really having in mind? Please give SNMP OIDs which you are (or want) collecting.

So... Nobody is collecting them? I thought we were going to add this new metrics to RRD MA. I would like to hear it from people who requested adding input and output errors.

Regards,

-- 
Giovanni Cesaroni
..............................................
CONSORTIUM GARR
The Italian Academic and Research Network

Tel. +39 06 4962 2535
Fax  +39 06 4962 2044
E-mail
..............................................  

-- 
Giovanni Cesaroni
..............................................
CONSORTIUM GARR
The Italian Academic and Research Network

Tel. +39 06 4962 2535
Fax  +39 06 4962 2044
E-mail 
..............................................