Posted by: Munda Sanichari on: October 7, 2008
You use GETNEXT, typically, to get selected columns from one or more rows of a table. If you want the values for columns S(1)..S(s) from columns C(1)..C(c) (where s<c (and there are N rows), you would make N+1 GETNEXT requests. (This assumes that the varBinds for columns S(1)..S(s) will fit in a request and response message.)
You use GETBULK, typically, as an optimisation of GETNEXT, and you would not typically know how many rows will be in the table. You just issue GETBULKs until you get all of the rows, just like using GETNEXT.
With GETNEXT, you know when you are done when the response is not the next row. Likewise, with GETBULK. However, instead of getting a single set of extra varBinds, you get upto the the value of maxRepeaters. This behavior is called “overshoot”. If the agent and manager support large max message sizes, and the maxRepeaters
is large, then you will have many extra varBinds in the last reponse to GETBULK. Typically, this is not too bad.
Posted by: Munda Sanichari on: October 7, 2008
SNMPv2 had been announced for many months, and most of us assumed that it was accepted as the next step up from SNMPv1. That assumption was false. In fact there were several points on which the members of the IETF subcommittee could not agree. Primary among them was the security and administrative needs of the protocol. Simply put, SNMPv2*/SNMPv1+/SNMPv1.5 is SNMPv2 without the contentious pieces, but *with* the stuff everyone agrees is of value. You may wish to check
Posted by: Munda Sanichari on: October 7, 2008
In the SNMPv1 protocol, there is a single type of operation to send an unsolicited message from an agent to a manager, which is a [v1]Trap. SMIv1 uses the TRAP-TYPE construct to define the conditions when such a message can be generated, the identification of the message, and the management information to be contained in the message.
When the second version of the SNMP framework was created, it was realized that the simple model for sending unsolicited messages needed to be generalized and a few problems solved. The class of unsolicited messages was renamed to notfications, and contained two types, which are v2TRAP (an unconfirmed notification), and INFORM (a confirmed notification). (Please note that an it is incorrect to characterize v1/v2TRAPs as unreliable and INFORMs as reliable.) Due to politics at the time, INFORMS were labelled as “manager-to-manager” communication. However, this labelling has been fixed (and anyone that claims that INFORMs are “manager-to-manager” communications is living with a 1996 world view and not a present world view!)
The first and second frameworks for SNMP-based management do not contain a standard mechanism to configure where to send notification nor the other details such as which type, and the security parameter values. The result has been proprietary definitions that vary in sophistication. The simplest is a table of IP addresses where to send traps (with no support for INFORMs, and other properties).
The third version of the SNMP framework contains in RFC 2573 and RFC 2576 a VERY RICH mechanism for managing notification generation.
Posted by: Munda Sanichari on: October 7, 2008
I am relatively ignorant about SNMP. However, I have spent a reasonable amount of effort investigating agents, managers, the technology, and I have read most of the important RFCs. There are a bunch of related but simple, practical questions to which I cannot get a straight answer: Are SNMP traps useful in the real world? Can you depend on traps being sent across networks? Do agents repeat traps? How do you select a polling interval if there are traps you consider very important?
RFC 1215 (the one with the TRAP-TYPE macro) says traps are a bad idea (well, sort of). RFC 1224 seems to describe a method to acknowledge SNMP traps and throttle them? What’s the real feeling…you know, in practice? The real state of the art?
Shyamal Prasad
Traps are very useful to us. They let us know when a router link goes down, when network performance is degrading, when a power failure has occurred, etc. – just to name a few.
You don’t poll for traps – the agent just sends the traps to the network management station(s) you tell it to send them to. Now you can program the network management station to take automatic action if you so desire. For example, if one of our ethernet concentrators sends us traps on a misbehaving port we automatically do some checking and if it is a situation that could potentially take our whole segment down we automatically partition the port off of the network. I’m sure this has saved numerous network outages.
Yes, agents may send repetitive traps. The way you throttle or deal with them depends on the software you use on your network management station. All that said – you cannot rely on traps alone. For example, if I die – I cannot pick up the phone and tell someone that “I am dead”. Neither can a SNMP agent. Therefore it is good to poll the agents periodically just to see if they are alive and well.
NOTIFICATION-TYPE
The current terminology in use in SNMP is the following:
The NOTIFICATION-TYPE construct is used to define events or conditions of interest in a managed system. (In the earlier, but now obsolete, version of the SMI, the TRAP-TYPE construct was used.)SNMPv1 protocol contains the TRAP message type that is sent when an event or condition defined by a NOTIFICATION-TYPE construct occurs.
SNMPv2c and SNMPv3 protocols contain the v2TRAP and INFORM message types that are sent when an event or condition defined by a NOTIFICATION-TYPE construct occurs. A v2TRAP message is not confirmed, and an INFORM message is confirmed (that is, a response message is sent back).
There is no such thing as an alarm in SNMP.
Posted by: Munda Sanichari on: October 7, 2008
“Automated topology discovery is a hard problem due to the diversity of deployed systems and the wide distribution of resource information. I will briefly mention some reasons why a ping/traceroute based approach will not work : subnetting, tunneling, firewalls, virtual LANS. Your network topology discovery tool would have to extract more information like subnet masks, etc and use heuristics for “guessing” the real topology. You may want to refer to the project resources WWW page at the URL
http://www.cs.columbia.edu/networks97/project3/resources.html
Posted by: Munda Sanichari on: October 7, 2008
There are several varients of the SNMPv2 protocol. They are:
SNMPv2p(OBSOLETE): For this version, much work was done to update the SNMPv1 protocol and the SMIv1, and not just security. The result was updated protocol operations, new protocol operations and data types, and party-based security from SNMPsec. This version of the protocol, now called party-based SNMPv2 is defined by RFC 1441, RFC 1445, RFC 1446, RFC 1448, and RFC 1449. (Note this protocol has also been called SNMPv2 classic, but that name has been confused with community-based SNMPv2. Thus, the term SNMPv2p is preferred.)
SNMPv2c(experimental, but widely used): This version of the protocol is called community string-based SNMPv2. It is an update of the protocol operations and data types of SNMPv2p, and uses community-based security from SNMPv1. It is defined by RFC 1901, RFC 1905, and RFC 1906.
SNMPv2u(experimental): This version of the protocol uses the protocol operations and data types of SNMPv2c and security based on users. It is defined by RFC 1905, RFC 1906, RFC 1909, and RFC 1910.
SNMPv2*(experimental): This version combined the best features of SNMPv2p and SNMPv2u. (It is also called SNMPv2star.) The documents defining this version were never published as RFCs. Copies of these unpublished documents can be found at the WEB site owned by SNMP Research (a leading SNMP vendor and previously a proponent of this version).
Posted by: Munda Sanichari on: October 7, 2008
Smoke testing is done to verify that the build (to be tested) is done properly. (The build is a new / updated version of software). The motive is to check that the application build is working fine and does not crash.
Sanity Testing – is done to verify whether the new / updated build is functioning properly. (Note the difference – smoke checks the application build; sanity checks the build functionality at higher level.)
Posted by: Munda Sanichari on: October 7, 2008
Partition testing is an approach to program testing in which the input domain of the program is divided into partitions and test cases are selected from each partition. An alternative approach, known as random testing, is to select test cases at random from the entire input domain. If all partitions are equal in sizes and the number of test cases selected from each partition is the same, then partition testing has a better chance of detecting at least one failure than random testing. They proved that partition testing is better than random testing so long as test cases are selected in proportion to the size of partitions. Partition testing performs better if the sampling rates are higher for partitions with higher failure rates.
Posted by: Munda Sanichari on: October 7, 2008
Testing the application with a load that application supposed to sustain as per the SRS. Here we check the performance of the application at different load levels and is acceptable or not.
Stress testing is, keeping the application under heavy loads than expected maximum loads in peak hours and checking how it affects application. This is generally done to do “failure recovery” testing.
Posted by: Munda Sanichari on: October 7, 2008
Alpha Test Beta Test
For S/w Application For S/w Product
By customer site people By customer site like people
In development site In customer side environment
Virtual environment Real Time Environment
