How does an SNMPv1 Trap-PDU identify an event compared with an SNMPv2-Trap-PDU, and where does each carry the event's time and source?
answer
- fixed fields versus varbinds
- generic-trap 0 to 6
- first two varbinds are special
- enterprise, then .0, then specific-trap
basics
~20 sA v1 Trap-PDU names the event in fixed fields: enterprise, agent-addr, generic-trap 0-6, specific-trap and time-stamp. An SNMPv2-Trap-PDU has none of these; its first two varbinds, sysUpTime.0 and snmpTrapOID.0, carry the time and the event's identity.
solid answer
~40 sThe SNMPv1 `Trap-PDU` (RFC 1157) has its own layout: `enterprise` (an OID, normally the agent's `sysObjectID`), `agent-addr` (an IPv4 address), `generic-trap` (0 coldStart, 1 warmStart, 2 linkDown, 3 linkUp, 4 authenticationFailure, 5 egpNeighborLoss, 6 enterpriseSpecific), `specific-trap`, `time-stamp` (TimeTicks since the agent's management system initialised) and the varbinds. The `SNMPv2-Trap-PDU` (RFC 3416) uses the ordinary PDU shape: varbind 1 is `sysUpTime.0`, varbind 2 is `snmpTrapOID.0`, whose value is the notification's OID, then the notification's objects. There is no `agent-addr`; a receiver uses the message's source or, after a proxy that translated a v1 trap, `snmpTrapAddress.0`. RFC 3584 maps one to the other: generic traps 0-5 become `snmpTraps.1`-`.6`, and an enterprise-specific trap becomes the enterprise OID, then `0`, then the specific-trap number.
go deeper
Recall that SNMPv1 traps have fixed header fields while v2 traps start with two special varbinds, sysUpTime.0 and snmpTrapOID.0.
Explain every v1 field, the seven generic-trap values, and how RFC 3584 maps generic and enterprise-specific traps to snmpTrapOID values.
Show that time is relative uptime and source depends on the transport, and how a collector should timestamp, detect restarts and keep identity through NAT or proxies.
Weigh how much a mixed v1/v2 estate costs in translation rules, lost Counter64 notifications and fragile identity, and when retiring v1 targets pays for itself.
## Why the format matters A collector that receives a notification must answer three questions: **which event** is this, **when** did it happen, and **which device** sent it. SNMPv1 and SNMPv2 answer them in different places, and a pipeline that mixes old and new devices — or a proxy that converts between them — has to know both layouts. ## The SNMPv1 Trap-PDU (RFC 1157) The v1 `Trap-PDU` (context tag `[4]`, a tag RFC 3416 now lists as obsolete) is the one PDU with a layout of its own: | Field | Type | Meaning | |---|---|---| | `enterprise` | OBJECT IDENTIFIER | type of object generating the trap, "see sysObjectID" | | `agent-addr` | NetworkAddress | address of the object generating the trap; RFC 1155 defines NetworkAddress with a single choice, `IpAddress` (4 octets) | | `generic-trap` | INTEGER | coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), enterpriseSpecific(6) | | `specific-trap` | INTEGER | the enterprise's own code, present even when generic-trap is not 6 | | `time-stamp` | TimeTicks | time since the network entity was last (re)initialised | | `variable-bindings` | VarBindList | "interesting" information; for linkDown and linkUp the first one is the `ifIndex` of the interface | So in v1 the event's identity is the **pair** (`generic-trap`, `specific-trap`) qualified by `enterprise`, and the source is a field the agent writes itself. ## The SNMPv2-Trap-PDU (RFC 3416) SNMPv2 dropped the special layout. An `SNMPv2-Trap-PDU` (tag `[7]`) and an `InformRequest-PDU` (tag `[6]`) have the same shape as every other PDU — request-id, error-status, error-index, varbinds — and the meaning moves into the varbind list: 1. **Varbind 1** — `sysUpTime.0`: when the event happened, in hundredths of a second since the agent's network management portion was last re-initialised. 2. **Varbind 2** — `snmpTrapOID.0` (`1.3.6.1.6.3.1.1.4.1.0`): its **value** is the OID of the notification, as defined by a `NOTIFICATION-TYPE`. 3. **Then** the objects named in that definition's `OBJECTS` clause, in order, and any extra varbinds the agent chooses to add. A v2 `linkDown` therefore looks like this (values illustrative): | # | Name | Value | |---|---|---| | 1 | `sysUpTime.0` | 123456 (1,234.56 s) | | 2 | `snmpTrapOID.0` | `1.3.6.1.6.3.1.1.5.3` (linkDown, `snmpTraps.3`, defined in IF-MIB) | | 3 | `ifIndex.7` | 7 | | 4 | `ifAdminStatus.7` | the interface's admin state | | 5 | `ifOperStatus.7` | the interface's operational state | There is **no agent-addr**. The receiver identifies the sender from the transport — the UDP source address — and, in SNMPv3, from the message's security parameters and context. ## Mapping between them (RFC 3584) RFC 3584 (BCP 74, coexistence between SNMP versions) gives the exact translation: - `time-stamp` ↔ `sysUpTime.0`, value unchanged. - `generic-trap` 0-5 ↔ the standard notifications `snmpTraps.1` to `snmpTraps.6` (`1.3.6.1.6.3.1.1.5.1` coldStart ... `.5.6` egpNeighborLoss). The OID's last number is the generic code **plus one**. - `generic-trap` 6 with enterprise `E` and specific-trap `S` ↔ `snmpTrapOID` = `E.0.S`. Enterprise `1.3.6.1.4.1.32473.1` (32473 is the enterprise number reserved for documentation) with specific-trap 12 becomes `1.3.6.1.4.1.32473.1.0.12`. - A **proxy** converting a received v1 trap appends `snmpTrapAddress.0` (the v1 agent-addr), `snmpTrapCommunity.0` and `snmpTrapEnterprise.0`, so the original source survives the hop. - Going the other way, a notification whose varbinds include a **Counter64** cannot be encoded as a v1 trap at all. ## Reading time and source correctly - **Time is relative.** Both `time-stamp` and `sysUpTime.0` are TimeTicks counted from the agent's last re-initialisation, not a wall clock. 123456 means 1,234.56 seconds — about 20.6 minutes — after that point. A collector must stamp its own arrival time, and a value that is smaller than the previous one from the same device means the agent restarted. - **TimeTicks wrap.** The type runs to 4,294,967,295 hundredths, so it wraps after about 497.1 days of uptime. - **Source is fragile.** A v1 `agent-addr` is what the agent claims, and it can only hold IPv4. A v2 notification's source is the packet's source address, which NAT or a relay rewrites. For identity across such paths, SNMPv3's engine ID and security name are steadier than an address. ## The interview point The strong answer names the fields, says that v2 moved identity and time into the first two varbinds, and can convert an enterprise-specific v1 trap to its v2 OID in one's head — because that conversion is exactly where hand-written collector rules go wrong.
- How does a receiver detect from notifications alone that an agent restarted?Compare sysUpTime.0 (or a v1 time-stamp) with the previous value from that device. Both count from the agent's last re-initialisation, so a value smaller than the last one means the agent restarted — or, after roughly 497.1 days, that the 32-bit TimeTicks wrapped. A coldStart or warmStart notification says the same directly, but it can be lost like any other trap, so the decreasing uptime is the check that does not depend on it.
- Why can a v2 notification with a Counter64 varbind not be forwarded to a v1-only collector?Because SNMPv1 has no Counter64 type. RFC 3584 says that if the SNMPv2 varbinds contain any Counter64 object, translation to v1 notification parameters cannot be performed and the notification cannot be sent using SNMPv1. A proxy or a multi-lingual agent drops it for that target, so a v1 collector silently never sees it.
saying these in an interview costs you the question
- The SNMPv2-Trap-PDU still has enterprise and agent-addr fields.
- The first varbind of a v2 trap identifies the notification.
- A trap's time-stamp is wall-clock time when the event happened.
- Enterprise-specific trap 12 maps to enterprise OID followed directly by 12.
- generic-trap 2 maps to snmpTraps.2 when converted to SNMPv2.
- A v1 agent-addr can carry an IPv6 address for a dual-stack device.