SNMPMIBs

SNMP is a protocol that provides the communication between an SNMP manager (usually the management station) and the SNMP agent in IP networks. The SNMP agent is a software component that runs on a device to be managed. SNMP provides a standardized framework for managing devices in the network. Part of the framework is the MIBs and the Structure of Management Information (SMI). The SMI provides the mechanisms to define the MIB. Plenty of MIBs are available, and new ones are always being defined. Most protocols have their own MIBs. However, other MIBs are not tied to a certain protocol, but rather to a certain software component on the SNMP agent. You can access SNMP MIBs by using a simple command on a management station or by a complicated piece of software with a graphical user interface running on the management station managing up to thousands of devices in the network. The MIB is actually composed of a collection of objects that refer to a managed entity on the device. The value of the objects can be read by a GET or GETNEXT command issued from the management station. In some cases, you can set the managed object with a SET command from the management station. Look at Figure 14-12 for an overview of the SNMP protocol.

Figure 14-12 SNMP Protocol Overview

Get-request Get-next-request

Set-Request

IP Network

Network Management SNMP Agent

Station

Get-response <-

Trap

SNMP can manage nodes in the network in two fashions: a polling fashion and an interrupt-driven fashion. In the polling fashion, a management station periodically polls or queries the devices in the network. A problem is the frequency to poll the devices when monitoring the status of the network devices—such as the routers. If a problematic event occurs, such as an interface going down, it might take a while before the polling station notices the event. Therefore, the second fashion is interrupt-driven. As soon as an event occurs on the managed device, SNMP sends a trap to the management station informing it of the change.

A MIB is a collection of managed objects, each with a name (value), status, access, and syntax. Many MIBs are available, some of which are defined by standard bodies and some of which are proprietary or enhanced with proprietary information. This book lists only the MIBs that are related to MPLS and that are supported in Cisco IOS. Following are the MIBs that fit into that category:

It should be obvious what most MIBs represent by looking at their name. The MPLS-LDP-MIB is the MIB that has objects related to LDP. It holds objects that are related to the LDP router ID, LDP peer information, and sessions. The MPLS-LSR-MIB holds objects that are related to counters, the LFIB, incoming and outgoing labels, and so on. In short, the MPLS-LSR-MIB can give the same information as seen with the show mpls forwarding-table command. The MPLS-TE-MIB is the MIB that holds objects related to TE. The MPLS-VPN-MIB is the MIB that deals with VRF-specific objects.

The PW in some MIBs stands for pseudowire; these MIBs are related to AToM if the underlying network protocol is MPLS. IF-MIB is the name of the interface MIB. It has been enhanced in Cisco IOS to support the MPLS layer. As such, statistics can be polled for labeled traffic that is being forwarded through the router. You can check the operational status of MPLS on an interface and the MPLS MTU of an interface by using this MIB.

Some MIBs that are related to routing are not really related to MPLS directly. However, without routing, MPLS is not possible; therefore, when talking about managing MPLS networks, it is necessary to manage IP routing, too. That is why if you are running OSPF in your network, you will be interested in the OSPF-MIB. If you are running MPLS VPN, the MIBs BGP4-MIB and CISCO-BGP4-MIB will be attractive. When you are running MPLS TE, the RSVP-MIB will captivate you.

Now is a good time to look at an example from the MPLS-TE MIB. An object tracks the state transitions of the TE tunnel. The object name is mplsTunnelStateTransitions, and the Object Identifier (OID) is 1.3.6.1.3.95.2.2.1.26. This OID uniquely defines the object. It defines which organization assigns the MIB, which MIB it is, and which object it is from that MIB. The OID is a list of integers, read from left to right, that uniquely indicates the managed object. Figure 14-13 shows the OID tree of the object mplsTunnelStateTransitions.

Figure 14-13 OID of mplsTunnelStateTransitions

Figure 14-13 OID of mplsTunnelStateTransitions

All OIDs of all MIBs can be represented in such an OID tree. In this example, 1.3.6.1.3.95.2.2.1.26 translates to iso (1) . org (3) . dod (6) . internet (1) . experimental (3) . mplsTeMIB (95) . mplsTeObjects (2); mplsTunnelTable (2); mplsTunnelEntry (1); mplsTunnelStateTransitions (26). The MPLS TE objects are defined in RFC 3812, which defines the MPLS TE MIB. Example 14-19 shows how the RFC defines the OID 1.3.6.1.3.95.2.2.1.26.

Example 14-19 OID 13.6.13.95.2.2.1.26

mplsTunnelStateTransitions OBJECT

-TYPE

SYNTAX Counter32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Specifies the number of

times the

state

(mplsTunnelOperStatus

of this

tunnel instance

has changed."

::= { mplsTunnelEntry 33 }

The access permission is read-only, its status is current, and its type is counter32. This OID allows you to track the number of state transitions of the TE tunnel. In other words, you can track the state changes (up/down) on the head end router for the TE tunnel interface. On the management station, you can retrieve this information with an snmpwalk or snmpget command. Look at Example 14-20 for the output from the snmpwalk command for the object mplsTunnelStateTransitions.

Example 14-20 snmpwalk of OID 1.3.6.1.3.95.2.2.1.26

nms{1}1249: snmpwalk -c cisco 10.48.70.116 1.3.6.1.3.95.2.2.1.26

SNMPv2-SMI::experimental.95.2.2.1.26.1.0.180944385.180944388 = Counter32: 9

SNMPv2-SMI::experimental.95.2.2.1.26.1.543.180944388.180944385 = Counter32: 0

The TE tunnel changed its state nine times on the LSR with IP address 10.48.70.116.

Another example is the retrieval of the LSR identifier that LDP uses. Example 14-21 shows how the mplsLdpLsrId object is defined in the MPLS LDP MIB.

Example 14-21 mplsLdpLsrId

mplsLdpLsrId OBJECT-

TYPE

SYNTAX

MplsLsrIdentifier

MAX-ACCESS

read-only

STATUS

current

DESCRIPTION

"The Label Switching Router's Identifier."

::= { mplsLdpLsrObjects 1 }

As you can see, the object name or OID is not the most readable term and not the easiest to find when you are looking for a specific management object. It can be a tedious job, but www.cisco.com has "Cisco IOS MIB Tools," which can help you find the right object and translate the object name into the OID and vice versa. In Example 14-22, you can see the output of the SNMP Object Navigator on www.cisco.com of the mplsLdpLsrId object.

Example 14-22 mplsLdpLsrId by SNMP Object Navigator

Object

mplsLdpLsrId

OID

1.3.6.1.4.1.9.10.65.1.1.1

Type

MplsLsrIdentifier

Permission

read-only

Status

current

MIB

MPLS-LDP-MIB

Description

The LSR's Identifier.

Example 14-23 shows the snmpwalk for the object mplsLdpLsrId on the router new-york.

Example 14-23 snmpwalk of OID 1.3.6.1.4.1.9.10.65.1.1.1

nms{1}1164: snmpwalk -c cisco 10.48.70.116 1.3.6.1.4.1.9.10.65.1.1.1

SNMPv2-SMI::enterprises.9.10.65.1.1.1.0 = Hex-STRING: 0A C8 FE 01

The returned value of mplsLdpLsrId is the LSR identifier in hexadecimal. The value OA C8 FE 01 in hexadecimal is 10.200.254.1 in dotted decimal.

Example 14-24 shows that object mplsOutSegmentOctets (OID 1.3.6.1.3.96.1.7.1.1) returns the number of octets (bytes) switched out on this segment or LSP. It matches the number of Bytes Label Switched for each LSP, as seen in the LFIB on this LSR.

Example 14-24 snmpwalk of OID 1.3.6.1.3.96.1.7.1.1

nms{1}1239

snmpwalk

-c

cisco 10.48.

70.109 1.3.6.1.3.

96.1.7.1.1

SNMPv2

SMI:

experimental

.96

1.7

1.1.

8705 = Counter32:

0

SNMPv2

SMI:

:experimental

.96

1.7

1.1.

9217 = Counter32:

0

SNMPv2

SMI:

:experimental

.96

1.7

1.1.

9729 = Counter32:

0

SNMPv2

SMI:

:experimental

.96

1.7

1.1.

10241 = Counter32

: 1009

SNMPv2

SMI:

experimental

.96

1.7

1.1.

10753 = Counter32

: 6423184

SNMPv2

SMI:

experimental

.96

1.7

1.1.

11265 = Counter32

: 0

SNMPv2

SMI:

experimental

.96

1.7

1.1.

11777 = Counter32

: 0

SNMPv2

SMI:

experimental

.96

1.7

1.1.

12289 = Counter32

: 0

SNMPv2

SMI:

experimental

.96

1.7

1.1.

12801 = Counter32

: 0

SNMPv2

SMI:

experimental

.96

1.7

1.1.

13313 = Counter32

: 6826536

SNMPv2

SMI:

experimental

.96

1.7

1.1.

13825 = Counter32

: 0

london#show mpls forwarding

table

Local

Outgoing

Prefix

Bytes Label

Outgoing

Next Hop

Label

Label or VC

or

Tunnel Id

Switched

interface

16

No Label

10.

9.9.

5/32

0

Fa0/0/0

10.48.70.106

17

Pop

Label

10.

200

214

0/24

0

PO5/0/0

point2point

18

16

10.

200

216

0/24

0

PO5/0/0

point2point

19

17

10.

200

217

0/24

0

PO5/0/0

point2point

20

Pop

Label

10.

200

254

3/32

1009

PO5/0/0

point2point

21

18

10.

200

254

4/32

6423184

PO5/0/0

point2point

22

19

10.

200

254

5/32

0

PO5/0/0

point2point

23

20

10.

200

254

6/32

0

PO5/0/0

point2point

24

Pop

Label

10.

200

254

4 1

[543] \

0

Et0/1/3

10.200.210.1

25

28

10.

200

254

1 1

[9] \

0

PO5/0/0

point2point

26

Pop

Label

10.

200

254

1/32

6826536

Et0/1/3

10.200.210.1

27

22

44.

44.44.44/32

0

PO5/0/0

point2point

Traps are unsolicited information sent via SNMP. Informs are also unsolicited information sent via SNMP; the difference is that informs are acknowledged, whereas traps are not. For MPLS, you can enable three kinds of traps: LDP, TE, and VPN. Example 14-25 shows the possible MPLS traps in Cisco IOS.

Example 14-25 Traps for MPLS in Cisco IOS

london(config)#snmp-server enable traps mpls ?

ldp Allow SNMP MPLS label distribution protocol traps traffic-eng Allow SNMP MPLS traffic engineering traps vpn Allow SNMP MPLS Virtual Private Network traps london(config)#snmp-server enable traps mpls ldp ?

pv-limit Enable MPLS LDP path vector limit mismatch traps session-down Enable MPLS LDP session down traps session-up Enable MPLS LDP session up traps threshold Enable MPLS LDP threshold exceeded traps

london(config)#snmp-server enable traps mpls traffic-eng ?

down Enable MPLS TE tunnel down traps reroute Enable MPLS TE tunnel reroute traps up Enable MPLS TE tunnel up traps

london(config)#snmp-server enable traps mpls vpn ?

illegal-label Enable MPLS VPN illegal label threshold exceeded traps max-threshold Enable MPLS VPN maximum threshold exceeded traps mid-threshold Enable MPLS VPN middle threshold exceeded traps vrf-down Enable MPLS VPN vrf down traps vrf-up Enable MPLS VPN vrf up traps

To send SNMP notification messages to a server within a VRF, use the VRF keyword for the snmp-server command on the PE. Example 14-26 shows this command in action.

Example 14-26 VRF-Aware snmp-server Command snmp-server host 10.254.9.40 vrf cust-one Cisco

Micro Expression Master

Micro Expression Master

If You Could Read Everyone Life A Book You Can Have Better Career, Great Relationships And Become Successful. This Book Is One Of The Most Valuable Resources In The World When It Comes To Reading the smallest and tiniest body Language and know what people are thinking about.

Get My Free Ebook


Post a comment