Article ID: 5672
Products
DFE
Protocols/Features
SNMPv1
SNMPv2c
Commands
'set snmp community'
'context router'
Symptoms
Cannot poll DFE router and switch MIBs using one community name
"Community already exists!"
"Error! SET command failed"
Cause
As explained in
5232, it is possible to define specific Contexts when configuring a DFE System for SNMP access.
On the DFE, a specification of 'context router' yields Router MIB access (or 'context router
x' for Router MIB access on behalf of router instance
x) and omission of 'context router' yields Switching MIB access; while each context references a unique Community Name.
An attempt to use the same SNMPv1/SNMPv2c Community Name for more than one context results in edit errors, as in the following example:
DFE(rw)->set snmp community testme
DFE(rw)->set snmp community testme securityname testme2 context router1
Community "testme" already exists!
Error! SET command failed
DFE(rw)->
It is thus not possible to monitor both Router MIBs (example: 'ipRouteEntry=1.3.6.1.2.1.4.21.1') and Switching MIBs (example: 'rmon=1.3.6.1.2.1.16') by means of a single Community Name.
It is also notable that the value of 'sysObjectID=1.3.6.1.2.1.1.2' (used by the NMS as one identifying characteristic in the device view) changes depending upon the context being used for access. For instance, on one device a Routing context may show a "etsysOidDevDFEPlatinumRouter" identifier, while a Switching context shows "etsysOidDevMatrixN3", making a different context look like a different device entirely.
Solution
FAD (Functions as Designed)
Any change would require instancing of the virtual router MIBs, which do not provide for instancing. The Context element, along with the associated Community Name, effectively provides the necessary instancing.
Note that what is stated herein is true of firmware versions through 6.x. As of version 7.x, there will no longer be separate contexts, so the DFE will act similarly to other products.
