Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configure SNMP for Routing Instances

Understand 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.

Figure 1: SNMP Data for Routing InstancesSNMP Data for Routing Instances

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 routing 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.

Enable the Management Routing Instance

To enable the SNMPv3 management routing instance:

  1. Configure the management-instance statement.

  2. Commit the configuration.

Remove the Management Routing Instance

To remove the SNMPv3 management routing instance:

  1. Delete or deactivate the SNMPv3 management routing instance statement.

You cannot configure the Junos management routing instance (mgmt_junos) at the [edit snmp v3 management-routing-instance <routing-instance>] hierarchy level since the mgmt_junos has the access to all routing instances by default.

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 Firewalls 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).

Identify 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.

Note:

Junos SNMP agent uses @ as the special character to specify a specific routing instance information as part of a community string. For example, if a routing instance is configured on a device for a community, the community string used in SNMP query is routinginstance@community.

If you want to poll the device from NMS and retrieve statistics of all the routing instances, the community string should be used in SNMP query is @community. Do not specify any routing instance name before 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.

Note:

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.

Enable 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).

Specify 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.

Note:

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: Configure 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:

Example: Configure Routing Instance in a Community

This example shows the configuration of a routing instance InBandManagement for a community myCommunity1.

The routing instance is restricted to an interface et-0/0/16. The restricted clients are configured as SNMPClients in the policy options.

The following snmpwalk command shows how to send SNMP request from the configured client to the interface et-0/0/16 as routinginstance@community:

Configure 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.

Note:

You cannot restrict the SNMP manager of the default routing instance from accessing SNMP information.