Re: Counter32 and Counter34: read-only/accessible-for-notify only
[ First - *please* don't mail me privately, without copying any responses to the mailing list. I don't have the time or inclination to offer private, unpaid, SNMP consultancy. Keep discussions to the list, where others can both learn and offer advice. Thanks. ] On 23 April 2012 18:11, Lawrence Widman wid...@cecst.com wrote: Dave, Many thanks for your reply. Please forgive my ignorance: I'm new at this. I am writing an agent that accepts the status of a network device and makes it available to a monitoring system. If counters cannot be set by any process, how are the values updated? It's not that counters cannot be set by any process. Rather that they cannot be set via the SNMP SET request. snmpd has to be getting the information from someplace, I would think. I searched the RFC for every occurrence of counter and did not find any explanation of how counters get updated, That doesn't really surprise me - the RFCs are purely describing the operation of the SNMP protocol (and syntax of the MIB files). They are concerned with how the management information is used - not how it is obtained in the first place. ... and looked at google without result. One possibility is that another variable accepts a rate and the extended agent adds the rate to a given counter, but if that were the case one would think the standard would allow pairing of the two variables. Take a step back (TM), and think for a moment about what problem SNMP is trying to address. The network manager needs to know what's happening on their network - to find out information about the systems they are looking after.Counters are typically used to monitor how many times something has happened - whether that's something unusual or unexpected (how many times the building has caught fire), or something perfectly normal (the number of packets sent on a given network interface). In both cases, this information will be stored somewhere (the safety log, or an internal field in the relevant kernel driver).All that the agent is doing is retrieving this value from the underlying subsystem, and passing it on to the network administrator in a standard form. So the counters will be maintained and updated by the underlying subsystem. And similarly for all the other MIB variables. This is an important point - the agent is *not* typically responsible for maintaining the values that it reports. It's simply a middle-man. It may keep a local cached copy of this data (e.g. network statistics or the routing table), but this would be purely for performance reasons. The source of the data would be the underlying subsystem, and it's _this_ that is responsible for maintaining it, updating counters, etc. OK? I understand if you do not have time for dumb questions. If so, please accept my thanks for the information you provided. Don't worry about it. As I keep telling our students, I like easy questions. I can answer easy questions. It's the hard ones that are more of a problem. And the only dumb question is the one you don't ask. (together with the question you ask twice because you didn't like the answer first time round. Now that *does* annoy me!) Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
[FWD] Re: Counter32 and Counter34: read-only/accessible-for-notify only
On Tue, Apr 24, 2012 at 08:35:59AM +0100, Dave Shield wrote: [ First - *please* don't mail me privately, without copying any responses to the mailing list. I don't have the time or inclination to offer private, unpaid, SNMP consultancy. Keep discussions to the list, where others can both learn and offer advice. Thanks. ] Noted. Shall I post your response to the list for the next person to see? I'll be happy to do so but just want to make sure that is OK with you. I'll include the above so the new next newbie will know that too. Take a step back (TM), and think for a moment about what problem Ooh, another (TM). I'll file that away: it's good! All that the agent is doing is retrieving this value from the underlying subsystem, The source of the data would be the underlying subsystem, and it's _this_ that is responsible for maintaining it, updating counters, etc. Yup, makes sense. I was trying to keep my extension of the agent pure and have another process feed it data via snmpset, but what I should have done was to see how the system processes are queried (cpu usage, etc). I still have to understand how the agent knows periodically to check them, but using the TASB(TM) principle, it's obvious that data access by snmpget via MODE_GET simply tells the agent to get the required information from the subsystem instead of its local data cache, and return it. Duh. So, let me know about posting your detailed reply to the list, and then I'll post this too in case it would be useful to someone. Thanks again! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
[FWD] Re: Counter32 and Counter34: read-only/accessible-for-notify only
On Tue, Apr 24, 2012 at 01:49:55PM +0100, Dave Shield wrote: Noted. Shall I post your response to the list for the next person to see? I'll be happy to do so but just want to make sure that is OK with you. I'll include the above so the new next newbie will know that too. Errr my response _was_ copied to the list. So it's already both out there, and archived for the future. (And the above text is my standard addition for whenever anyone contacts me direct - if you check the list archives, you'll find plenty of examples of this. It fluctuates, but there have been around 40 in the last twelve months) I'm posting this to the list too. I was insufficiently clever before in not noticing that your first reponse was Cc'd to the list. I posted my response to your reponse too: hopefully some other newbie will learn this point too! I still have to understand how the agent knows periodically to check them There are two basic mechanisms - on demand, or periodic. The most common approach is for the agent to retrieve the relevant data when a request comes in - either for _every_ request, or holding it in a local cache, and checking whether the data is too old and needs to be refreshed. Again, there are plenty of examples of this in the code base, and explanations on the mailing list. The alternative approach is for the agent to regularly reload the data automatically (perhaps in a separate thread, or a separate process that populates an external cache). That way the data is always available for processing a request, and doesn't need to be loaded explicitly. This is particularly useful when loading the data will take a long time, and the client application may time out and resend the requests. It's less common, but the 'cache_handler' helper does provide support for this too. Have a browse through the mail archives - you ought to find mention of both approaches. Ah, that explains the references to an external cache when running mib2c. There's a lot to learn here. I'll get to it. (I'm thinking: this makes sense under V1/V2c, but under V3 if a separate process maintains an external cache, or if the agent has to spend its time fetching outside information instead of only responding to requests, why not let snmpset change counters and restrict the privilege to specific outside processes using V3 authentication, and avoid the overhead of an external cache or of the agent doing non-SNMP-related work? So now I have to go understand why that doesn't make sense.) Thanks again! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
