Cisco Cisco IOS Software Release 12.2(33)SRE

mplsOutSegmentTopLabel.7.0.0.0.0.16.0.1 = 3

mplsOutSegmentTopLabel.7.0.0.0.0.17.0.1 = 3

mplsOutSegmentTopLabel.7.0.0.0.0.18.0.1 = 3

mplsOutSegmentTopLabel.7.0.0.0.0.19.0.1 = 17

mplsOutSegmentTopLabel.8.2.10.0.0.1.32.0.1 = 17

mplsOutSegmentTopLabel.8.2.10.0.0.3.32.0.1 = 3

mplsOutSegmentTopLabel.8.2.10.30.0.16.0.1 = 3

Out-segment’s interface (mplsOutSegmentIInterface) 

mplsOutSegmentInterface.7.0.0.0.0.0.0.1 = 0

mplsOutSegmentInterface.7.0.0.0.0.2.0.1 = 0

mplsOutSegmentInterface.7.0.0.0.0.16.0.1 = 0

mplsOutSegmentInterface.7.0.0.0.0.17.0.1 = 55

mplsOutSegmentInterface.7.0.0.0.0.18.0.1 = 55

mplsOutSegmentInterface.7.0.0.0.0.19.0.1 = 55

mplsOutSegmentInterface.8.2.10.0.0.1.32.0.1 = 55

mplsOutSegmentInterface.8.2.10.0.0.3.32.0.1 = 55

mplsOutSegmentInterface.8.2.10.30.0.16.0.1 = 55

For more information on how to read the indexing for MPLS-LSR-STD-MIB objects, see 

 and 

the 

Cisco IOS Release 12.2(33)SRB includes the VPN Aware LSR MIB feature that enables the 
MPLS-LSR-STD-MIB to get VPN context information. This feature adds support for different contexts 
for different MPLS VPNs. Users of the MIB can display per-VPN entries in the MPLS-LSR-STD-MIB 
tables. The VPN Aware LSR MIB feature does not change the syntax of the MPLS-LSR-STD-MIB. It 
changes the number and types of entries within the tables. 

The MPLS-LSR-STD-MIB can show information about only one context at a time. You can specify 
either a global context or an MPLS VPN context using an SMNP security name. The security name must 
match the SNMP community name when an SNMP request is performed on a MIB entry.

SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated 
with a context, that VPN’s specific MIB data exists in that context. Associating a VPN with a context 
enables service providers to manage networks with multiple VPNs. Creating and associating a context 
with a VPN enables a provider to prevent the users of one VPN from accessing information about users 
of other VPNs on the same networking device. 

VPN-aware SNMP requires that SNMP manager and agent entities operating in a VPN environment 
agree on mapping between the SNMP security name and the VPN name. This mapping is created by you 
using different contexts for the SNMP data of different VPNs, which is accomplished through the 
configuration of the SNMP View-based Access Control Model MIB (SNMP-VACM-MIB). The 
SNMP-VACM-MIB is configured with views so that a user on a VPN with a security name is allowed 
access to the restricted object space within the context of only that VPN.

SNMP request messages undergo three phases of security and access control before a response message 
is sent back with the object values within a VPN context: 

The first security phase is authentication of the username. During this phase, the user is authorized 
for SNMP access. 

The second phase is access control. During this phase, the user is authorized for SNMP access to the 
group objects in the requested SNMP context.