EXTREME-MPLS-TE-MIB: View SNMP OID List / Download MIB

VENDOR: EXTREME NETWORKS


 Home MIB: EXTREME-MPLS-TE-MIB
Download as:   
SNMPv2-CONF, SNMPv2-SMI, EXTREME-MPLS-MIB, MPLS-TE-STD-MIB, SNMPv2-TC

Download standard MIB format if you are planning to load a MIB file into some system (OS, Zabbix, PRTG ...) or view it with a MIB browser. CSV is more suitable for analyzing and viewing OID' and other MIB objects in excel. JSON and YAML formats are usually used in programing even though some systems can use MIB in YAML format (like Logstash).
Keep in mind that standard MIB files can be successfully loaded by systems and programs only if all the required MIB's from the "Imports" section are already loaded.
The tree-like SNMP object navigator requires no explanations because it is very simple to use. And if you stumbled on this MIB from Google note that you can always go back to the home page if you need to perform another MIB or OID lookup.


Object Name OID Type Access Info
 extremeMplsTeMIB 1.3.6.1.4.1.1916.1.37.2
Extreme extensions to mplsTeStdMIB
     extremeMplsTeScalars 1.3.6.1.4.1.1916.1.37.2.1
     extremeMplsTeObjects 1.3.6.1.4.1.1916.1.37.2.2
         extremeMplsTunnelTable 1.3.6.1.4.1.1916.1.37.2.2.1 no-access
The mplsTunnelTable (see RFC 3812) allows new MPLS tunnels to be created between an LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that only point-to-point tunnel segments are supported, although multipoint-to-point and point- to-multipoint connections are supported by an LSR acting as a cross-connect. Each MPLS tunnel can thus have one out-segment originating at this LSR and/or one in-segment terminating at this LSR. Extreme Networks MPLS implementation allows tunnel instances with a common endpoint to be grouped at the ingress LSR to provide redundancy. The role of each tunnel in the group must be configured and is indicated by extremeMplsTunnelRedundancyType. The failover to a redundant tunnel is implementation dependent.
             extremeMplsTunnelEntry 1.3.6.1.4.1.1916.1.37.2.2.1.1 no-access
An entry in this table represents an extension to an MPLS tunnel reported in the mplsTunnelTable (see RFC 3812). An entry can be created by a network administrator or by an SNMP agent as instructed by an MPLS signalling protocol. An entry in this table displays an ingress tunnel only since the tunnel type is a configured value at the local node and is not exchanged by the signalling protocol.
                 mplsTunnelRedundancyType 1.3.6.1.4.1.1916.1.37.2.2.1.1.1 integer read-write
Identifies the tunnel redundancy type associated with this tunnel instance. A value of primary(1) or secondary(2) MAY be assigned by the network administrator or by an SNMP manager at the time of setting up the tunnel. Enumeration: 'primary': 1, 'secondary': 2.
                 mplsTunnelRedundancyStatus 1.3.6.1.4.1.1916.1.37.2.2.1.1.2 integer read-only
Indicates the actual redundancy status of this tunnel. When the status is active, the tunnel is the preferred tunnel in the group. Enumeration: 'active': 1, 'standby': 2.
                 mplsTunnelTransportStatus 1.3.6.1.4.1.1916.1.37.2.2.1.1.3 bits read-write
Indicates the type of traffic the tunnel group can be used for sending. When the allowAllIp(0) bit is set, IP traffic destined for all IPv4 routes will be allowed over any tunnel in the group marked active. When the allowAssignedIpOnly(1) bit is set, IP traffic destined only for IPv4 static routes that have been explicitly configured to use this tunnel group will be allowed. When the allowAllLayer2Vpn(2) bit is set, layer 2 VPN traffic for all layer 2 VPNs will be allowed over any tunnel in the group marked active. When the allowAssignedLayer2VpnOnly(3) bit is set, layer 2 VPN traffic destined only for pseudo-wires that have been explicitly configured to use this tunnel group will be allowed. Bits: 'allowAllIp': 0, 'allowAsignedLayer2VpnOnly': 3, 'allowAllLayer2Vpn': 2, 'allowAssignedIpOnly': 1.
     extremeMplsTeConformance 1.3.6.1.4.1.1916.1.37.2.3