FAQs

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

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

    Posted 11-24-2013 14:59
    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

    [/code]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