SNMP GET
GET is the most basic SNMP operation: a manager asks an agent for the current value of one or more specific OIDs, and the agent responds with those values. If you've ever queried a single stat from a device - current CPU load, a specific interface's status - you were using GET.
A single GET request can ask for multiple OIDs at once, bundled into one request/response exchange rather than one round trip per value - useful when you know exactly which handful of values you want and don't need to walk anything.
Basic syntax
Using net-snmp's command-line tools:
snmpget -v2c -c public 192.168.1.1 1.3.6.1.2.1.1.1.0
snmpget -v2c -c public 192.168.1.1 sysDescr.0 sysUpTime.0 sysContact.0
Each OID you ask for must be an exact, existing OID - typically a scalar instance (ending in .0) or a specific row/column instance in a table. You can't GET a table or a whole subtree at once; that's what a walk (built on GETNEXT or GETBULK) is for.
What happens when the OID doesn't exist
This is where GET's behavior differs meaningfully by version. In SNMPv1, if any requested OID doesn't exist on the agent, the entire request fails with a single error (noSuchName) - you get nothing back for the whole batch, not even the OIDs that were valid. SNMPv2c and v3 improved this significantly: instead of failing the whole request, an individual varbind that doesn't resolve comes back with a specific exception value - noSuchObject or noSuchInstance - while the rest of the response still contains real data for the OIDs that did exist. See No Such Instance / No Such Object for the distinction between those two specific exception values.
Why a GET request can hang or time out
Because SNMP runs over UDP (see what is SNMP), there's no built-in delivery guarantee. If the agent never receives the request, or the response gets lost on the way back, the manager just waits until its own timeout expires - it has no way to distinguish "the device is slow" from "the packet never arrived" from "the agent is misconfigured and silently dropped it." See SNMP timeout for the most common underlying causes.
GET vs. the other read operations
GET requires you to already know the exact OID you want. If you're exploring a device and don't know its exact OIDs in advance - or you want everything under a subtree, like every row of a table - you'd use GETNEXT or, more efficiently for large tables, GETBULK instead.