Snmpd_proxy

Simply proxy access

Integrating a remote branch

Integrating a branch from a remote device into the Net-SNMP agent is useful if you only care about a subset of objects available from the remote device. One example would be to import a devices enterprise branch:

# proxy enterprise tree (mixed in w/net-snmp agent objects) proxy -v 2c -c remote-community myswitch .1.3.6.1.4.1.171

Now when the enterprise branch is walked, the enterprise objects for myswitch will be included.

Integrating an entire tree

If you need objects from the remote device that conflict with objects for the local agent, you have two choices.

Contexts as selectors

You can use SNMPv3 contexts (or SNMPv2 context mapping) to select between the agent and the proxied device.

SNMPv2 context mapping require some configuration setup, so we'll cover that first. We need a v1/v2c community string for the proxied host. We'll assign these to the same 'notConfigUser' defined by default. We use '-Cn ' to assign a context to the community:

com2sec -Cn ctx_myswitch notConfigUser  default       cmty_myswitch

Now we need a view to allow all objects we want to integrate from the remote device. For simplicity, we'll just import everything:

view    allview          included        .1

We need to allow the 'notConfigUser' (a member of 'notConfigGroup') access for these contexts.

access  notConfigGroup ctx_myswitch            any       noauth    exact  allview none none

Finally, the proxy configuration:

# proxy whole tree under a context proxy -Cn ctx_myswitch -v 2c -c remote-community switch .1.3

Restart snmpd, and you should get different results based on your community string or SNMPv3 context:

$ snmpgetnext -v 2c -c public localhost .1.3.6 RFC1213-MIB::sysDescr.0 = STRING: "Linux snmp.example.com"

$ snmpgetnext -v 2c -c cmty_myswitch localhost .1.3.6 RFC1213-MIB::sysDescr.0 = STRING: "D-Link DES-3226L Fast Ethernet Switch"

$ snmpgetnext -v 3 -n ctx_myswitch -u MD5DESUser -a MD5 -A "PasswordA" -x DES -X "PasswordX" -l authPriv localhost .1.3.6 RFC1213-MIB::sysDescr.0 = STRING: "D-Link DES-3226L Fast Ethernet Switch"

Remapping OIDs

A much simple configuration is to simply remap the entire remote tree to unused space in the local tree. Everything Net-SNMP implements is in the .iso.org (.1.3) tree. So you could remap a remote tree to iso.4 (.1.4), and no contexts or special community strings are needed.

The major disadvantage to this is that it completely breaks mapping of OIDs to MIB object names. If you are monitoring specific objects by OIDs, then you might not care.

# proxy whole tree to somewhere else proxy -v 2c -c remote_community switch .1.4 .1.3

$ snmpgetnext -v 2c -c public localhost .1.3 RFC1213-MIB::sysDescr.0 = STRING: "Linux snmp.example.com"

$ snmpgetnext -v 2c -c public localhost .1.4 iso.4.6.1.2.1.1.1.0 = STRING: "D-Link DES-3226L Fast Ethernet Switch"

proxy to multiple devices

If you want to have the same OID tree proxied to muliple devices, (e.g. so the proxy responds as if it were the proxied device), you need to use contexts. Contexts were introduced in SNMPv3, but Net-SNMP had a feature to have a SNMPv1 community string map to a context for proxying. You will need a unique community string per proxied device.

Setting up SNMPv1 (and v2c) community/context mapping

(Skip this section if you are going to be using SNMPv3 to access the proxy agent).

Normal access control looks like this:

# define a simple view 'systemview', which includes everthing under .1.3.6.1
view    systemview     included      .1.3.6.1

# map 'public' community to the 'notConfigUser'
com2sec notConfigUser  default       public

# map 'notConfigUser' to 'notConfigGroup'
group   notConfigGroup v1            notConfigUser
group   notConfigGroup v2c           notConfigUser

# give 'notConfigGroup' read access to objects in the view 'systemview'
access  notConfigGroup ""            any       noauth    exact  systemview none none

For proxy acess to multiple remote hosts, we need a v1/v2c community string for each proxied host. We'll assign these to the same 'notConfigUser' defined above. We also have to use '-Cn ' to assign a context to each, which is how the proxy configuration will know which remote host to set requests to.

com2sec -Cn ctx_remotehost1 notConfigUser  default       cmty_remotehost1 com2sec -Cn ctx_remotehost2 notConfigUser  default       cmty_remotehost2

Now, we need to allow the 'notConfigUser' (a member of 'notConfigGroup') access for these contexts. Since we used a common prefix for the context name, we just need one access line using prefix matching, instead of two using exact matching:

access  notConfigGroup ctx_remotehost            any       noauth    prefix  systemview none none

Setting up the proxy configuration

Now, to set up the proxy:

proxy -Cn ctx_remotehost1  -v 2c -c public  remotehost1  .1.3

# Note: this should be 1 line, without the '\' continuation.. proxy -Cn ctx_remotehost2  -v 3 -u MD5DESUser -a MD5 -A "PasswordA" \       -x DES -X "PasswordX" -l authPriv  remotehost2  .1.3

Start snmpd (or restart it, if it was already running), and then test your new setup.

Testing

Finally, to query via the proxy:

$ snmpget -v2c -c cmty_remotehost1 proxyhost sysContact.0