An SNMPv3 manager must monitor a few legacy switches that speak only SNMPv1; what does an SNMP proxy forwarder do, and where should it sit?

## What "proxy" means in SNMP RFC 3413 §1.5 notes that "proxy" has historically meant several things, and picks one: | Historical meaning | Is it RFC 3413's proxy forwarder? | |---|---| | Forwarding SNMP requests to another entity regardless of the object types, e.g. across transports or between SNMP versions | yes - the closest meaning | | Translating SNMP into some non-SNMP management protocol | no | | Aggregating objects whose values depend on several remote items | no | The rule that separates a **proxy forwarder** from an agent: a proxy forwarder forwards messages "according to the context, and irrespective of the specific managed object types being accessed", while a **command responder** processes requests per object and "must have the detailed definition of the MIB view". Implementing a proxy forwarder is optional. ## How the proxy chooses where to send things RFC 3413 §3.5 lists four classes of message a proxy forwarder handles: 1. **Read-Class and Write-Class** (Get, GetNext, GetBulk, Set): delivered to the engine "downstream in the path" to the information, chosen from the request's context; the response is carried back. 2. **Notification-Class** (SNMPv2-Trap, Inform): forwarded to the engines that should hear about that context. 3. **Response-Class**: matched to the request or notification it answers and sent back to its initiator. 4. **Internal-Class** (such as Report): likewise matched and returned. The mapping from incoming to outgoing target is implementation-specific, typically a preconfigured translation table; if that table is SNMP-manageable it must use the `SNMP-PROXY-MIB` module. For a confirmed notification, the proxy forwards the target's response when it arrives rather than answering at once, so the originator's acknowledgement still means delivery. ## Version translation for an SNMPv1-only switch RFC 3584 (Best Current Practice 74) defines the PDU translations. With an SNMPv3 manager upstream and an SNMPv1 switch downstream (RFC 3584 §4.3.1): - A `GetBulkRequest-PDU` is forwarded as a `GetNextRequest-PDU`, acting as if non-repeaters and max-repetitions were both 0 - so a bulk walk degrades to one GetNext per step on the v1 leg. - A `tooBig` response is reshaped for the newer version: for a plain request the varbinds are removed and error-index set to 0; for a translated GetBulk the proxy retries once with only the first varbind. - An SNMPv1 `Trap-PDU` is translated by RFC 3584 §3's rules and forwarded as an `SNMPv2-Trap-PDU`; the original agent-addr and community survive in `snmpTrapAddress` and `snmpTrapCommunity`. The reverse case - an SNMPv1 manager behind the proxy and a newer agent in front - has its own rules in RFC 3584 §4.3.2, mostly about hiding `Counter64` values that SNMPv1 cannot carry. A v1-only switch has no 64-bit counters to return, so high-speed interfaces on it are limited to what its 32-bit objects can show; the proxy cannot add data the device lacks. ## Where to put it, and what it costs The security picture decides placement: - **Upstream leg** (manager to proxy): SNMPv3 with authentication and privacy. - **Downstream leg** (proxy to switch): SNMPv1, whose community travels in cleartext in every request. So the proxy belongs as close to the legacy switches as possible, ideally on the same isolated management segment, so the community crosses the fewest links. It also becomes: - a **single point of failure** for monitoring those switches - plan for its loss; - a **choke point** that holds the downstream communities - harden it like a manager; - an extra hop with its own timeouts, which slows bulk walks that it has turned into GetNext steps; - a place where configuration drifts: every legacy switch's community and address lives in the proxy's translation table, and must change there when the switch changes. The proxy is a bridge, not a fix. It buys time until the legacy switches can be replaced by devices that speak SNMPv3 themselves. ## Proxy, AgentX and mid-level manager | | Proxy forwarder | AgentX master agent | Mid-level manager | |---|---|---|---| | Speaks SNMP on both sides | yes | upstream only; AgentX downstream | yes | | Interprets objects | no | dispatches by registered region | yes | | Visible to the manager | yes, as an intermediary | no - looks like one agent | yes, as an agent of its own | RFC 2741 states that transparency to managers is what differentiates AgentX subagents from SNMP proxy agents.