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 .188.8.131.52.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 <context>' 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"
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.184.108.40.206.220.127.116.11 = 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 .18.104.22.168 view systemview included .22.214.171.124 # 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 <context>' 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.
Finally, to query via the proxy:
$ snmpget -v2c -c cmty_remotehost1 proxyhost sysContact.0