Configuring SNMP for Routing Instances
Understanding SNMP Support for Routing Instances
Junos OS enables SNMP managers for all routing instances to request and manage SNMP data related to the corresponding routing instances and logical system networks.
In Junos OS:
Clients from routing instances and/or logical systems other than the default can access MIB objects and perform SNMP operations only on the routing instance and/or logical system networks to which they belong.
Clients from the default routing instance can access information related to all routing instances and logical system networks.
The Junos management routing instance (mgmt_junos) is a special instance. Clients from the management routing instance are treated as if they were in the default routing instance and can access information related to all routing instances and logical system networks.
Before Junos OS Release 8.4, only the SNMP manager in the default routing instance (inet.0) had access to the MIB objects.
With the increase in virtual private network (VPN) service offerings, this feature is useful particularly for service providers who need to obtain SNMP data for specific routing instances (see Figure 1). Service providers can use this information for their own management needs or export the data for use by their customers.
If no routing instance is specified in the request, the SNMP agent operates as before:
For nonrouting table objects, all instances are exposed.
For routing table objects, only those associated with the default routing instance are exposed.
Note The actual protocol data units (PDUs) are still exchanged over the default (inet.0) routing instance, but the data contents returned are dictated by the routing instance specified in the request PDUs.
SNMPv3 Management Routing Instance
Starting in Junos OS 19.4R1, you can access information related to all routing instances and logical system networks and not specific to ingress routing instance by configuring the SNMPv3 management interface in a required management instance. You can configure the management instance configuration statement at the [edit SNMP v3] hierarchy level.
Benefits
SNMPv3 management routing instance enables all the SNMPv3 requests from non-default routing instance as if the requests are from default routing instance. Using SNMPv3 management routing instance, you access the information related to all routing instances and logical system networks.
Enabling the Management Routing Instance
To enable the SNMPv3 management routing instance:
- Configure the management-instance statement.
[edit]user@host# set SNMP v3 management-routing-instance <routing-instance> - Commit the configuration.
[edit]user@host# commit
Removing the Management Routing Instance
To remove the SNMPv3 management routing instance:
- Delete or deactivate the SNMPv3 management routing instance
statement.
[edit]user@host# delete SNMP v3 management-routing-instance <routing-instance>
SNMP MIBs Supported for Routing Instances
Table 1 shows enterprise-specific MIB objects supported by Junos OS and provides notes detailing how they are handled when a routing instance is specified in an SNMP request. An en dash (–) indicates that the item is not applicable.
Table 1: MIB Support for Routing Instances (Juniper Networks MIBs)
Object | Support Class | Description/Notes |
|---|---|---|
jnxProducts(1) | – | Product Object IDs |
jnxServices(2) | – | Services |
jnxMibs(3) jnxBoxAnatomy(1) | Class 3 | Objects are exposed only for the default logical system. |
mpls(2) | Class 2 | All instances within a logical system are exposed. Data will not be segregated down to the routing instance level. |
ifJnx(3) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxAlarms(4) | Class 3 | Objects are exposed only for the default logical system. |
jnxFirewalls(5) | Class 4 | Data is not segregated by routing instance. All instances are exposed. |
jnxDCUs(6) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxPingMIB(7) | Class 3 | Objects are exposed only for the default logical system. |
jnxTraceRouteMIB(8) | Class 3 | Objects are exposed only for the default logical system. |
jnxATM(10) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxIpv6(11) | Class 4 | Data is not segregated by routing instance. All instances are exposed. |
jnxIpv4(12) | Class 1 | jnxIpv4AddrTable(1). Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxRmon(13) | Class 3 | jnxRmonAlarmTable(1). Objects are exposed only for the default logical system. |
jnxLdp(14) | Class 2 | jnxLdpTrapVars(1). All instances within a logical system are exposed. Data will not be segregated down to the routing instance level. |
jnxCos(15) jnxCosIfqStatsTable(1) jnxCosFcTable(2) jnxCosFcIdTable(3) jnxCosQstatTable(4) | Class 3 | Objects are exposed only for the default logical system. |
jnxScu(16) jnxScuStatsTable(1) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxRpf(17) jnxRpfStatsTable(1) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxCfgMgmt(18) | Class 3 | Objects are exposed only for the default logical system. |
jnxPMon(19) jnxPMonFlowTable(1) jnxPMonErrorTable(2) jnxPMonMemoryTable(3) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxSonet(20) jnxSonetAlarmTable(1) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxAtmCos(21) jnxCosAtmVcTable(1) jnxCosAtmScTable(2) jnxCosAtmVcQstatsTable(3) jnxCosAtmTrunkTable(4) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
ipSecFlowMonitorMIB(22) | – | – |
jnxMac(23) jnxMacStats(1) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
apsMIB(24) | Class 3 | Objects are exposed only for the default logical system. |
jnxChassisDefines(25) | Class 3 | Objects are exposed only for the default logical system. |
jnxVpnMIB(26) | Class 2 | All instances within a logical system are exposed. Data will not be segregated down to the routing instance level. |
jnxSericesInfoMib(27) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxCollectorMIB(28) | Class 1 | Only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed. |
jnxHistory(29) | – | – |
jnxSpMIB(32) | Class 3 | Objects are exposed only for the default logical system. |
Table 2 shows Class 1 MIB objects (standard and enterprise-specific MIBs) supported by Junos OS. With Class 1 objects, only those logical interfaces (and their parent physical interfaces) that belong to a specific routing instance are exposed.
Table 2: Class 1 MIB Objects (Standard and Juniper MIBs)
Class | MIB | Objects |
|---|---|---|
Class 1 | 802.3ad.mib | (dot3adAgg) MIB objects: dot3adAggTable dot3adAggPortListTable (dot3adAggPort) dot3adAggPortTable dot3adAggPortStatsTable dot3adAggPortDebugTable |
rfc2863a.mib | ifTable ifXTable ifStackTable | |
rfc2011a.mib | ipAddrTable ipNetToMediaTable | |
rtmib.mib | ipForward (ipCidrRouteTable) | |
rfc2665a.mib | dot3StatsTable dot3ControlTable dot3PauseTable | |
rfc2495a.mib | dsx1ConfigTable dsx1CurrentTable dsx1IntervalTable dsx1TotalTable dsx1FarEndCurrentTable dsx1FarEndIntervalTable dsx1FarEndTotalTable dsx1FracTable ... | |
rfc2496a.mib | dsx3 (dsx3ConfigTable) | |
rfc2115a.mib | frDlcmiTable (and related MIB objects) | |
rfc3592.mib | sonetMediumTable (and related MIB objects) | |
rfc3020.mib | mfrMIB mfrBundleTable mfrMibBundleLinkObjects mfrBundleIfIndexMappingTable (and related MIB objects) | |
ospf2mib.mib | All objects | |
ospf2trap.mib | All objects | |
bgpmib.mib | All objects | |
rfc2819a.mib | Example: etherStatsTable | |
Class 1 | rfc2863a.mib | Examples: ifXtable ifStackTable |
rfc2665a.mib | etherMIB | |
rfc2515a.mib | atmMIB objects Examples: atmInterfaceConfTable atmVplTable atmVclTable | |
rfc2465.mib | ip-v6mib Examples: ipv6IfTable ipv6AddrPrefixTable ipv6NetToMediaTable ipv6RouteTable | |
rfc2787a.mib | vrrp mib | |
rfc2932.mib | ipMRouteMIB ipMRouteStdMIB | |
mroutemib.mib | ipMRoute1MIBObjects | |
isismib.mib | isisMIB | |
pimmib.mib | pimMIB | |
msdpmib.mib | msdpmib | |
jnx-if-extensions.mib | Examples: ifJnxTable ifChassisTable | |
jnx-dcu.mib | jnxDCUs | |
jnx-atm.mib | Examples: jnxAtmIfTable jnxAtmVCTable jnxAtmVpTable | |
jnx-ipv4.mib | jnxipv4 Example: jnxIpv4AddrTable | |
jnx-cos.mib | Examples: jnxCosIfqStatsTable jnxCosQstatTable | |
jnx-scu.mib | Example: jnxScuStatsTable | |
jnx-rpf.mib | Example: jnxRpfStatsTable | |
jnx-pmon.mib | Example: jnxPMonFlowTable | |
jnx-sonet.mib | Example: jnxSonetAlarmTable | |
Class 1 | jnx-atm-cos.mib | Examples: jnxCosAtmVcTable jnxCosAtmVcScTable jnxCosAtmVcQstatsTable jnxCosAtmTrunkTable |
jnx-mac.mib | Example: jnxMacStatsTable | |
jnx-services.mib | Example: jnxSvcFlowTableAggStatsTable | |
jnx-coll.mib | jnxCollectorMIB Examples: jnxCollPicIfTable jnxCollFileEntry |
Table 3 shows Class 2 MIB objects (standard and enterprise-specific MIBs) supported by Junos OS. With Class 2 objects, all instances within a logical system are exposed. Data will not be segregated down to the routing instance level.
Table 3: Class 2 MIB Objects (Standard and Juniper MIBs)
Class | MIB | Objects |
|---|---|---|
Class 2 | rfc3813.mib | mplsLsrStdMIB Examples: mplsInterfaceTable mplsInSegmentTable mplsOutSegmentTable mplsLabelStackTable mplsXCTable (and related MIB objects) |
igmpmib.mib | igmpStdMIB Note: The igmpmib.mib is the draft version of the IGMP Standard MIB in the experimental tree. Junos OS does not support the original IGMP Standard MIB. | |
l3vpnmib.mib | mplsVpnmib | |
jnx-mpls.mib | Example: mplsLspList | |
jnx-ldp.mib | jnxLdp Example: jnxLdpStatsTable | |
jnx-vpn.mib | jnxVpnMIB | |
jnx-bgpmib2.mib | jnxBgpM2Experiment |
Table 4 shows Class 3 MIB objects (standard and enterprise-specific MIBs) supported by Junos OS. With Class 3, objects are exposed only for the default logical system.
Table 4: Class 3 MIB Objects (Standard and Juniper MIBs)
Class | MIB | Objects |
|---|---|---|
Class 3 | rfc2819a.mib | rmonEvents alarmTable logTable eventTable agentxMIB |
rfc2925a.mib | pingmib | |
rfc2925b.mib | tracerouteMIB | |
jnxchassis.mib | jnxBoxAnatomy | |
jnx-chassis-alarm.mib | jnxAlarms By default, SRX Series devices queries jnxAlarms mib only on the primary node of redundancy group 0 (RG0) and not on the secondary node. | |
jnx-ping.mib | jnxPingMIB | |
jnx-traceroute.mib | jnxTraceRouteMIB | |
jnx-rmon.mib | jnxRmonAlarmTable | |
jnx-cos.mib | Example: jnxCosFcTable | |
jnx-cfgmgmt.mib | Example: jnxCfgMgmt | |
jnx-sonetaps.mib | apsMIBObjects | |
jnx-sp.mib | jnxSpMIB | |
ggsn.mib | ejnmobileipABmib | |
rfc1907.mib | snmpModules | |
snmpModules | Examples: snmpMIB snmpFrameworkMIB |
Table 5 shows Class 4 MIB objects (standard and enterprise-specific MIBs) supported by Junos OS. With Class 4 objects, data is not segregated by routing instance. All instances are exposed.
Table 5: Class 4 MIB Objects (Standard and Juniper MIBs)
Class | MIB | Objects |
|---|---|---|
Class 4 | system | Example: sysORTable |
rfc2011a.mib | ip (ipDefaultTTL, ipInReceives) icmp | |
rfc2012a.mib | tcp tcpConnTable ipv6TcpConnTable | |
rfc2013a.mib | udp udpTable ipv6UdpTable | |
rfc2790a.mib | hrSystem | |
rfc2287a.mib | sysApplOBJ | |
jnx-firewall.mib | jnxFirewalls | |
jnx-ipv6.mib | jnxIpv6 |
Support Classes for MIB Objects
When a routing instance is specified, all routing-related MIB objects return data maintained by the routing instance in the request. For all other MIB objects, the data returned is segregated according to that routing instance. For example, only those interfaces assigned to that routing instance (for example, the logical interfaces [ifls] as well as their corresponding physical interfaces [ifds]) are exposed by the SNMP agent. Similarly, objects with an unambiguous attachment to an interface (for example, addresses) are segregated as well.
For those objects where the attachment is ambiguous (for example, objects in sysApplMIB), no segregation is done and all instances are visible in all cases.
Another category of objects is visible only when no logical system is specified (only within the default logical system) regardless of the routing instance within the default logical system. Objects in this category are Chassis MIB objects, objects in the SNMP group, RMON alarm, event and log groups, Ping MIB objects, configuration management objects, and V3 objects.
In summary, to support routing instances, MIB objects fall into one of the following categories:
Class 1—Data is segregated according to the routing instance in the request. This is the most granular of the segregation classes.
Class 2—Data is segregated according to the logical system specified in the request. The same data is returned for all routing instances that belong to a particular logical system. Typically, this applies to routing table objects where it is difficult to extract routing instance information or where routing instances do not apply.
Class 3—Data is exposed only for the default logical system. The same set of data is returned for all routing instances that belong to the default logical system. If you specify another logical system (not the default), no data is returned. Typically this class applies to objects implemented in subagents that do not monitor logical system changes and register their objects using only the default context (for example, Chassis MIB objects).
Class 4—Data is not segregated by routing instance. The same data is returned for all routing instances. Typically, this applies to objects implemented in subagents that monitor logical system changes and register or deregister all their objects for each logical system change. Objects whose values cannot be segregated by routing instance fall into this class.
See SNMP MIBs Supported for Routing Instances for a list of the objects associated with each class.
SNMP Traps Supported for Routing Instances
You can restrict the trap receivers from receiving traps that are not related to the logical system networks to which they belong. To do this, include the logical-system-trap-filter statement at the [edit snmp] hierarchy level:
If the logical-system-trap-filter statement is not included in the SNMP configuration, all traps are forwarded to the configured routing instance destinations. However, even when this statement is configured, the trap receiver associated with the default routing instance will receive all SNMP traps.
When configured under the trap-group object, all v1 and v2c traps that apply to routing instances (or interfaces belonging to a routing instance) have the routing instance name encoded in the community string. The encoding is identical to that used in request PDUs.
For traps configured under the v3 framework, the routing instance name is carried in the context field when the v3 message processing model has been configured. For other message processing models (v1 or v2c), the routing instance name is not carried in the trap message header (and not encoded in the community string).
Identifying a Routing Instance
With this feature, routing instances are identified by either the context field in v3 requests or encoded in the community string in v1 or v2c requests.
When encoded in a community string, the routing instance name appears first and is separated from the actual community string by the @ character.
To avoid conflicts with valid community strings that contain the @ character, the community is parsed only if typical community string processing fails. For example, if a routing instance named RI is configured, an SNMP request with RI@public is processed within the context of the RI routing instance. Access control (views, source address restrictions, access privileges, and so on) is applied according to the actual community string (the set of data after the @ character—in this case public). However, if the community string RI@public is configured, the protocol data unit (PDU) is processed according to that community and the embedded routing instance name is ignored.
Logical systems perform a subset of the actions of a physical router and have their own unique routing tables, interfaces, policies, and routing instances. When a routing instance is defined within a logical system, the logical system name must be encoded along with the routing instance using a slash ( / ) to separate the two. For example, if the routing instance RI is configured within the logical system LS, that routing instance must be encoded within a community string as LS/RI@public. When a routing instance is configured outside a logical system (within the default logical system), no logical system name (or / character) is needed.
Also, when a logical system is created, a default routing instance (named default) is always created within the logical system. This name should be used when querying data for that routing instance (for example, LS/default@public). For v3 requests, the name logical system/routing instance should be identified directly in the context field.
To identify a virtual LAN (VLAN) spanning-tree instance (VSTP on MX Series 5G Universal Routing Platforms), specify the routing instance name followed by a double colon (::) and the VLAN ID. For example, to identify VSTP instance for VLAN 10 in the global default routing instance, include default::10@public in the context (SNMPv3) or community (SNMPv1 or v2) string.
Enabling SNMP Access over Routing Instances
To enable SNMP managers in routing instances other than the default routing instance to access SNMP information, include the routing-instance-access statement at the [edit snmp] hierarchy level:
If this statement is not included in the SNMP configuration, SNMP managers from routing instances other than the default routing instance cannot access SNMP information. This setting applies to requests for any version of SNMP (SNMP v1, v2, or v3).
Specifying a Routing Instance in an SNMPv1 or SNMPv2c Community
You can specify the routing instance along with the client information when you add a client to an SNMP community. To specify the routing instance to which a client belongs, include the routing-instance statement followed by the routing instance name and client information in the SNMP configuration.
The following example shows the configuration statement to add routing instance test-ri to SNMP community community1.
Routing instances specified at the [edit snmp community community-name] hierarchy level are added to the default logical system in the community.
If the routing instance is defined within a logical system, include the routing-instance statement at the [edit snmp community community-name logical-system logical-system-name] hierarchy level, as in the following example:
Example: Configuring Interface Settings for a Routing Instance
This example shows an 802.3ad ae0 interface configuration allocated to a routing instance named INFrtd:
The following snmpwalk command shows how to retrieve SNMP-related information from router1 and the 802.3ae bundle interface belonging to routing instance INFrtd with the SNMP community public:
Configuring Access Lists for SNMP Access over Routing Instances
You can create and maintain access lists to manage access to SNMP information. Access list configuration enables you to allow or deny SNMP access to clients of a specific routing instance, and applies to requests for any version of SNMP.
The following example shows how to create an access list:
The configuration given in the example:
Restricts clients in ri1 from accessing SNMP information.
Allows clients in ls1/default, ls1/ri2, and all other routing instances with names starting with ls1 to access SNMP information.
You can use the wildcard character (*) to represent a string in the routing instance name.
You cannot restrict the SNMP manager of the default routing instance from accessing SNMP information.