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.
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:
Configure the management-instance statement.
[edit]user@host#set snmp v3 management-routing-instance <routing-instance>Commit the configuration.
[edit]user@host#commit
Remove 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>
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.
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.
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.
Class |
MIB |
Objects |
|---|---|---|
Class 2 |
rfc3813.mib |
mplsLsrStdMIB Examples: mplsInterfaceTable mplsInSegmentTable mplsOutSegmentTable mplsLabelStackTable mplsXCTable (and related MIB objects) |
igmpmib.mib |
igmpStdMIB Note:
The |
|
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.
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.
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:
[edit snmp] logical-system-trap-filter;
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.
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.
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.
Routing instances specified at the [edit snmp community community-name] hierarchy level are added to the
default logical system in the community.
[edit snmp]
community community1 {
clients {
10.209.152.33/32;
}
routing-instance test-ri {
clients {
10.19.19.1/32;
}
}
}
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:
[edit snmp]
community community1 {
clients {
10.209.152.33/32;
}
logical-system test-LS {
routing-instance test-ri {
clients {
10.19.19.1/32;
}
}
}
}
Example: Configure Interface Settings for a Routing Instance
This example shows an 802.3ad ae0 interface configuration allocated to a routing instance named INFrtd:
[edit chassis]
aggregated-devices {
ethernet {
device-count 5;
}
}
[edit interfaces ae0]
vlan-tagging;
aggregated-ether-options {
minimum-links 2;
link-speed 100m;
}
unit 0 {
vlan-id 100;
family inet {
address 10.1.0.1/24;
}
}
[edit interfaces fe-1/1/0]
fastether-options {
802.3ad ae0;
}
[edit interfaces fe-1/1/1]
fastether-options {
802.3ad ae0;
}
[edit routing-instances]
INFrtd {
instance-type virtual-router;
interface fe-1/1/0.0;
interface fe-1/1/1.0;
interface fe-1/1/5.0;
interface ae0.0;
protocols {
ospf {
area 0.0.0.0 {
interface all;
}
}
}
}
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:
router# snmpwalk -Os router1 INFrtd@public dot3adAggTable dot3adAggMACAddress.59 = 0:90:69:92:93:f0 dot3adAggMACAddress.65 = 0:90:69:92:93:f0 dot3adAggActorSystemPriority.59 = 0 dot3adAggActorSystemPriority.65 = 0 dot3adAggActorSystemID.59 = 0:0:0:0:0:0 dot3adAggActorSystemID.65 = 0:0:0:0:0:0 dot3adAggAggregateOrIndividual.59 = true(1) dot3adAggAggregateOrIndividual.65 = true(1) dot3adAggActorAdminKey.59 = 0 dot3adAggActorAdminKey.65 = 0 dot3adAggActorOperKey.59 = 0 dot3adAggActorOperKey.65 = 0 dot3adAggPartnerSystemID.59 = 0:0:0:0:0:0 dot3adAggPartnerSystemID.65 = 0:0:0:0:0:0 dot3adAggPartnerSystemPriority.59 = 0 dot3adAggPartnerSystemPriority.65 = 0 dot3adAggPartnerOperKey.59 = 0 dot3adAggPartnerOperKey.65 = 0 dot3adAggCollectorMaxDelay.59 = 0 dot3adAggCollectorMaxDelay.65 = 0
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.
user@host# show interfaceset-0/0/16:0 { unit 0 { family inet { address 192.168.1.3/24; } } }user@host# show policy-optionsprefix-list SNMPClients { 10.0.10.2/32; 192.168.1.2/32; }user@host# show snmp{ community myCommunity1 { authorization read-only; routing-instance InBandManagement { client-list-name SNMPClients; } } routing-instance-access; }user@host# show routing-instancesrouting-instances { InBandManagement { instance-type virtual-router; interface et-0/0/16:0.0; } }
The following snmpwalk command shows how to send SNMP request from
the configured client to the interface et-0/0/16 as
routinginstance@community:
user@ubuntu:~# snmpwalk -v2c -c InBandManagement@myCommunity1 -On 192.168.1.3 SNMPv2-MIB::sysDescr
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:
[edit snmp]
routing-instance-access {
access-list {
ri1 restrict;
ls1/default;
ls1/ri2;
ls1*;
}
}
The configuration given in the example:
Restricts clients in
ri1from accessing SNMP information.Allows clients in
ls1/default,ls1/ri2, and all other routing instances with names starting withls1to 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.