CISCO-CONTEXT-MAPPING-MIB

A single SNMP agent sometimes needs to support multiple instances of the same MIB module, and does so through the use of multipl...

  • Organization:

    Cisco Systems, Inc.

  • Module:

    CISCO-CONTEXT-MAPPING-MIB

  • Version:

    2008-11-22

  • File:

    CISCO-CONTEXT-MAPPING-MIB.yang

  • Abstract:

    A single SNMP agent sometimes needs to support multiple instances of the same MIB module, and does so through the use of multipl...

  • Contact:

    Cisco Systems
    Customer Service

    Postal: 170 W Tasman Drive
    San Jose, CA 95134
    USA

    Tel: +1 800 553-NETS

    E-mail: cs-snmp@cisco.com

  • Check for an additional details:

    YANG Catalog

  • Description:

    A single SNMP agent sometimes needs to support multiple
    instances of the same MIB module, and does so through the
    use of multiple SNMP contexts. This typically occurs because
    the technology has evolved to have extra dimension(s), i.e.,
    one or more extra data and/or identifier values which are
    different in the different contexts, but were not defined in
    INDEX clause(s) of the original MIB module. In such cases,
    network management applications need to know the specific
    data/identifier values in each context, and this MIB module
    provides mapping tables which contain that information.

    Within a network there can be multiple Virtual Private
    Networks (VPNs) configured using Virtual Routing and
    Forwarding Instances (VRFs). Within a VPN there can be
    multiple topologies when Multi-topology Routing (MTR) is
    used. Also, Interior Gateway Protocols (IGPs) can have
    multiple protocol instances running on the device.
    A network can have multiple broadcast domains configured
    using Bridge Domain Identifiers.

    With MTR routing, VRFs, and Bridge domains, a router now
    needs to support multiple instances of several existing
    MIB modules, and this can be achieved if the router's SNMP
    agent provides access to each instance of the same MIB module
    via a different SNMP context (see Section 3.1.1 of RFC 3411).
    For MTR routing, VRFs, and Bridge domains, a different SNMP
    context is needed depending on one or more of the following:
    the VRF, the topology-identifier, the routing protocol instance,
    and the bridge domain identifier.
    In other words, the router's management information can be
    accessed through multiple SNMP contexts where each such
    context represents a specific VRF, a specific
    topology-identifier, a specific routing protocol instance
    and/or a bridge domain identifier. This MIB module provides
    a mapping of each such SNMP context to the corresponding VRF,
    the corresponding topology, the corresponding routing protocol
    instance, and the corresponding bridge domain identifier.
    Some SNMP contexts are independent of VRFs, independent of
    a topology, independent of a routing protocol instance, or
    independent of a bridge domain and in such a case, the mapping
    is to the zero length string.

    With the Cisco package licensing strategy, the features
    available in the image are grouped into multiple packages
    and each packages can be managed to operate at different
    feature levels based on the available license. This MIB
    module provides option to associate an SNMP context to a
    feature package group. This will allow manageability of
    license MIB objects specific to a feature package group.

    As technology evolves more we may need additional
    identifiers to identify the context. Then we would need
    to add those additional identifiers into the mapping.

© 2023 YumaWorks, Inc. All rights reserved.