Defining a SNMP Router Context on N-Series to Poll Router MIBs

[FAQ_User]

Article ID: 5232

Products
Matrix N-Series DFE

Goals
Sample configuration.

Symptoms
Cannot query route table.
Cannot poll route table.
Router IP does not reply to router SNMP MIBS, e.g. ipRouteEntry=1.3.6.1.2.1.4.21.1.

Cause
Default SNMP configurations do not include access to router-specific MIBs.

Of Enterasys products, only the DFE may have separate switch and router contexts. A router context needs to be set up to access these MIBs, polled either from a router interface address or the switch host IP address.

Solution
With SNMPv1/v2c...

• a Community Name is referenced by a Group which is given Access to possibly multiple contexts and a MIB View for each.
• each Community Name is defined for a specific context, so Community Name selection determines the context.

With SNMPv3...

• a User Name is referenced by a Group which is given Access to possibly multiple contexts and a MIB View for each.
• the User Name has no context, so a separate parameter makes that determination.
• As two examples; with NetSight Console MIB Tools the user would type "router" into the Context field, and with the Unix snmpwalk utility the user would specify context option "-n router".

Restated, the context possibilities are defined using one or more 'set snmp access...' commands referencing the same Access name, collectively permitting among other things the overall support of both switch context access (no context parameter) and router context access ('context router').

Within the subset of these possibilities, the actual context used is dictated by the SNMPv1/SNMPv2c Community Name context or the manually entered SNMPv3 context parameter used.

The total set of combinations is shown here:
SNMP Access Community Name Manual Resulting
version context context context context

v1/v2c -none- -none- n/a switch
v1/v2c -none- router n/a -fails-
v1/v2c router -none- n/a -fails-
v1/v2c router router n/a router
v1/v2c -both- -none- n/a switch
v1/v2c -both- router n/a router

v3 -none- n/a -none- switch
v3 -none- n/a router -fails-
v3 router n/a -none- -fails-
v3 router n/a router router
v3 -both- n/a -none- switch
v3 -both- n/a router router

As is apparent from the above chart, the most flexible result occurs when the Access is given both context permissions. Then by merely varying the Community Name or manual context, it is a simple matter to access either switch or router MIBs.

For example, let us assume the following configuration:
set snmp view viewname All subtree 1
set snmp view viewname All subtree 0.0

set snmp group groupRW user myCommName security-model v1
set snmp group groupRW user myCommName security-model v2c
set snmp group groupRW user myUserName security-model usm

set snmp access groupRW security-model v1 exact read All write All notify All
set snmp access groupRW security-model v1 context router exact read All write All notify All
set snmp access groupRW security-model v2c exact read All write All notify All
set snmp access groupRW security-model v2c context router exact read All write All notify All
set snmp access groupRW security-model usm privacy exact read All write All notify All
set snmp access groupRW security-model usm privacy context router exact read All write All notify All

set snmp community mySwitchComm securityname myCommName
set snmp community myRouterComm securityname myCommName context router
set snmp user myUserName authentication md5 privacy

Given that configuration, then...

• with SNMPv1/SNMPv2c and Community Name mySwitchComm, a switch context is used.
• with SNMPv1/SNMPv2c and Community Name myRouterComm, a router context is used.
• with SNMPv3 and User Name myUserName and no context specified, a switch context is used.
• with SNMPv3 and User Name myUserName and a router context specified, a router context is used.

Firmware version notes:

• With firmware through 5.x, the router context includes a trailing slot number (e.g. 'context router1') to indicate the chassis slot which is supporting the specified router - one of possibly two in the system.
• With firmware 6.x, the router context is generically specified as 'context router' because there is only one router instance and it is not specifically assigned to a particular slot.
• With firmware 7.x, separate switch and router contexts are no longer supported by default. However, the use of VRF will require a unique context for each virtual router's MIBs.

See also: 5245 and 5672.