SNMP

Simple Network Management Protocol (SNMP) - A protocol that enables a management

station to configure, monitor, and receive trap (alarm) messages from network devices.

The main people at the origin of the SNMP concept are :

Keith McCLOGHRIE

Marshall ROSE

Jeffrey D.CASE

Mark FEDOR

Martin LEE SCHOFFSTALL

James R.DAVIN.

At the beginning in 1988, there was the need of an administration tool for TCP/IP network and

most particularly for the Internet.

The starting point had been given by the IAB with the publication of the RFC 1052 in April

1988. This RFC is a requirement specification for the network management standard. It is

entitled "IAB Recommendations for the Development of Internet Network Management

Standards" and explain that the network management must :

Be as large as possible.

Have the wider diversity of implementation as possible.

Have the wider diversity of administration/management as possible.

Cover as much protocol layer as possible.

From that point things are going faster. An important part of the concept were already known by

previous development around routers notably SGMP (Simple Gateway Monitoring Protocol).

The following RFCs are the first documents dealing with SNMP published in 1988 :

RFC 1065 - Structure and Identification of Management Information for TCP/IP-based

internets

RFC 1066 - Management Information Base for Network Management of TCP/IP-based

internets

RFC 1067 - A Simple Network Management Protocol

This type of publication "RFC" is a very important point that explain the fast development of the

SNM Protocol.

After a previous study, a RFC is proposed as a status of standard. Then it normally becomes a

"Draft Standard" after a six month period.

At this point, there must be then at least two implementation of the protocol.

After a four month period, if the IESG recommend it as a standard, then the IAB take the final

decision to adopt the standard or not.

MECHANISM OF IETF STANDARDISATION.

Preliminary

Draft

Proposed

Draft

Draft

Standard

Standard

At

least

6

months

At

least

4

months

ISO and ITU-T ( International Telecommunication Union ) had in important influence on the

SNMP with their will of convergence.

The IAB wished that transition from one to the other architectures was as easy as possible.

Finally, the synchronisation between the two protocols had been very difficult and the

convergence plan based over CMOT (allowing TCP/IP management with CMIS/CMIP) has been

dropped off and thus SNMP moves forward .

Each protocol followed then his own development. The SNMP conception goes faster and the

RFC had been re-write with new functions. The 1.0 version was reached in May 1991 with the

followings RFC :

RFC 1155 -

Structure and Identification of Management Information for TCP/IP-based Internets Structure

and Identification of Management Information Guidelines for Object Names

Describe how management information has been structured into a global tree.

Lays down some restrictions to keep the protocol simplicity.

Introduce the rules for assigning names to objects.

RFC 1212 -

Concise MIB Definitions

Complete the RFC 1515 with technical definitions.

Improves on the definition techniques defined in RFC 1155.

RFC 1213 -

Management Information Base for Network Management of TCP/IP-based internets: MIB-II

This memo defines the second version of the Management Information Base (MIB-II) to use

with network management protocols in TCP/IP-based internets.

A listing of over 100 vars. Needed to keep the settings, the status and the statistics of the

operating systems of the network.

RFC 1157

A Simple Network Management Protocol (SNMP)

Define the messages that can be exchanged between the management station and the managed

entity to read or update values.

Define the alarm messages (TRAP) send by the system in stress status.

Define the message format and details if the communication protocol.

Different workgroup contribute to the development and the opening of the protocol by building

MIBs for all types of network equipment (Bridge, Router, Hub, ASCII monitors, WAN interface,

DS1, DS3, X25, Frame Relay, Ethernet, Token Ring, FDDI...) and also vendors protocols.

In November 1991 are published requirement for the integration of probes. This probe watch, do

survey and capture passively the traffic on a segment of the LAN for a later analysis. It maintains

statistics of the traffic, breakdown caused by protocol, source, destination and other criteria. A

network manager with the monitor is able to set threshold in monitor and set the management

station that must receive the alert messages.

April 1993, SNMP V2 becomes a standard. It offers new features that complete a few the lack of

the previous version such as security and authentication. This version is criticised because it

introduce complexity and a failure of compatibility with V1.

Finally in 1997, a merging group is created. Its main topic : create SNMP V3. There is also work

in order to adapt multimedia protocol to network management, development around Java or new

architectures and protocols (HMMP : Hypermedia Management Protocol).

The devices in the network contain information about themselves (like parameters and statistics).

Devices have current status that indicates if the running conditions are healthy and many

interesting knowing about its neighbourhood (active stations, statistics, problems).

This information are the heart of Simple Network Management. The key elements are the

following :

What piece of information is interesting ?

The interesting information have been conscripted. So, it leads to a standardisation of the

form and meaning of information stored across many different vendors products.

How to name it ?

You need the name of an item to ask for it. So, the management framework include a

well-defined way to assign names.

How to get it or change it ?

SNMP has become the nick for the entire Simple Network Management framework, but

SNMP refers only to a part of the framework that gets information from device and

changes the values (of the configuration parameters).

The Management Information' Nature

What kind of configuration, status and statistical information are associated with a device ?

Any network node has one or more interface to media.

Network interface has a defined configuration type (e.g. Ethernet, X.25 , and so on).

Interface have an operational status of Up, Down and Testing.

A system normally counts interface statistics (e.g. number of send and receive frames ...)

In the beginning, SNMP , was created to manage TCP/IP networks. Thus information a bout IP

and TCP received the earlier notice. Then later, information was described far the activities of

other protocols (such as DC Net, AppleTalk, IPX/SPX,), and every function of the multi-

protocol Routers that are linchpins nowadays need to be managed.

MIBs

The information may be stored at device as a combination of switchs, settings, hardware

counters, in memory variables and tables or files. This can be considered conveniently as a

database.

SNMP standards, use this logical database of network management information. It is called a

MIB (Management Information Base). The internal structure of those MIBs are not important for

the manager, but the way and the accessibility of the data base is very important.

Internet-Standard Management Model

This Internet Standard Management Model enable network manager to examine device data and

update configuration and status information.

AGENT SOFTWARE is installed in each device. It receive incoming message from the

manager. Message request read or write of device’s data.

The agent receive messages and send a response back. Agent does not have to wait for order to

act, if a serious problem arises or a significant event occurs, it send a TRAP (notification

message) to the manager.

Interactions between a manager and an agent.

MANAGER SOFTWARE are in management station (send message to AGENT and receive

Trap and Responses). It use UDP protocol to carries its messages.

Finally there is one application that enable end user to control the manager software and view

network information.

Network Management Application

These applications are not standardized. Management station vendors compete vigorously in

providing the best interface (graphical, intuitive information display, application, the best toolkit

for adding specialized application...).

What do those application do ? (Here are a few examples)

They map the tested LAN (What and which type of device are there, other station)

Render graphs of the traffic report

Managers can select its own parameters ( e.g. : significant event, spontaneous problems report,

message from other applications)

Thus information are useful, and LAN monitors add special capabilities to network

management. It is able to examine all of the traffic on a LAN based on any criteria (such as

traffic for a given protocol, traffic between a selected pair of station, traffic containing a selected

bit pattern).

MIB Variables

The problem is to know what information have to be kept. The information have to be

standardize without stifling useful additions and extensions. The SNMP community use the

following approach :

Define groups of useful parameters

Fine-tune of the fields after several month of experience (remove parameters and add new one)

Committees of experts to define MIB variables for special technologies ( bridges , token-ring

interfaces)

Add vendor-specific extension

MIB I

The first MIB . As SNMP was originally developed to satisfy requirement to manage TCP/IP

communications on the Internet , the MIB I concentrated on information specific to TCP/IP. This

first version included:

System description

The number of networking interfaces that has a system (Ethernet adapters, serial ports ..)

IP address associated with each network interface

Counts the numbers of incoming and outgoing datagrams

Table of information about active TCP connections

Technology Extensions

The IAB encouraged groups of vendors to define MIBs needed to manage their products. RFC

1286 describe a MIB for bridges, it expresses the philosophy of MIB construction.

It needs to keep MIB as simple as possible. And it was done thanks to the following criteria :

A small set of essential objects at starting, then you add only the objects that are needed.

Required objects are essential for either fault or configuration management

Consider evidence of current use and/or utility

Limit total number of objects

Exclude object derived from others

Avoid causing critical sections to be heavily instrumented

Private Enterprise Extensions

Any vendor can request a Branch or a subtree in the tree of management information. And define

its own variable necessary for its devices.

SNM Protocol

How to get the information stored in the MIB. SNM Protocol identifies :

Type of messages that can be sent between Manager and Agent

Message format

Communication protocol used

Messages sent between a manager and an agent.

Structure and Identification of Management Information

Each device contains a database of information that it would be useful to know about. This

database is called MIB.

SNMP define a simple set of messages that let us read and write database variables, and

receive trap reports of problem events.

But there is still the questions :

How to define and describe MIB variables, how are different variables related to one

another, how to identify a variable that we want to read or write, and how should the

variables be represented ?

The answers are given in the RFC 1155 Structure and Identification of Management Information

for TCP/IP-based Internets. This RFC follows the ISO / CCIT lead in dealing with the four

following issues :

MIB variables are defined and described using the ASN.1 (Abstract Syntax Notation 1)

datatype definition language. It allow to create data structures, like in other languages such as

Pascal or C, plus a few additional capabilities to go beyond the possibilities of other languages.

Network management information has been incorporated into a large tree administered by ISO

and CCITT (the tree structure helps us to visualise the relationship between variables).

The Identifiers for the Network Management are issued from the tree. The name of a

parameter is a sequence of number along the path from the root of the tree.

Basic Encoding Rules (BER) are used for translations of value of ASN.1 variables into a fixed

transmission format. Data will always be formatted in the same way (between managers and

agents). Then the agent and the manager translate in its own native language.

The SNM framework is very modular. It is has been a good choice motivated by the desire to do

ease later migration to ISO management standards.

Modularity adds new branch to the management information trees without any changes of

protocol.

The protocol is based on Read, Write and Event messages thus if we want to perform an action

we just define the variable that causes the action when it is set to 1. A new action is just a new

variable in the MIB.

Thus enormous expansions are possible without any change on the protocol.

STUCTURE and IDENTIFICATION of MANAGEMENT INFORMATION.

We are going to introduce the simple template that is issued to define network management

variables and we are going to be familiar with the tree-structured framework.

Structure of the Managed Objects

The management community use the OBJECT term instead of variable. An object has the

following specificities : a name, attributes and a set of operation that can be performed on the

object.

SNMP describe managed objects that hold the Network information. A MIB is a set of managed

objects.

A managed object is viewed as :

a unique name, OBJECT IDENTIFIER

Attributes

- datatype

- description (including details required to build the correct implementation)

- status information.

Valid operations that can be performed on the object (read, write, set)

VARIABLES:

Stored at a device is an individual instance of managed object. A variable have to be

implemented so that it conforms to its MIB object definition.

The formal template used to define MIB is the following one (here is the example of sysDescr in

RCF 1213)

sysDescr OBJECT-TYPE

SYNTAX DisplayString (SIZE (0.255))

ACCESS read-only

STATUS mandatory

DESCRIPTION

„Textual description of the entity.

This value include the full name and

the version identification of the system’s

hardware type, software operating-system

and networking software. It may only

contain ASCII printable characters "

::= { system 1 }

DATATYPE FOR MIB VARIABLES are simple such as integer or octet string.

OTHER OBJECTS

The interesting thing with the object-oriented point of view is that almost everything can be

considered as an object.

ISO AND CCITT STRUCTURE OF INFORMATION

ISO and CCITT use the idea of structuring information into global naming tree and assigning an

identifier to each objects.

The main ISO/CCITT Tree

Below the developpement of the MIB Node.

The MIB node and its object identifiers.

ADMINISTRATIVE NODES IN THE ISO/CCITT TREE

A node can be used as a register that indicates who is in charge of the objects under it. A node is

defined in the tree for each administrative entity.

THE SUBTREE UNDER INTERNET CONTROL

Under internet there are 6 nodes. For this part about SNMP V.1 we are concerned with the mgmt,

experimental and private node. They are administrated by the Internet Assignment Numbers

Authority. The mgmt (management) subtree is made of all accepted standard network

management variables. Experimentation and research are under the experimental node.

GROUPS IN MIB MODULE

A module is a publication made by experts defining MIB object for a particular area of

technology. Groups are smaller units than large module. It is a group of objects. Useful groups

can be implemented by a vendor for a product.

VENDOR MIB DEFINITIONS

The private subtree enables private organizations to enhance the usefulness of SNMP. Into its

own part of the subtree, a vendor uses product identifiers an the MIB definition that are needed

to manage its products. Product identifiers combined with the MIB-II system description variable

allows a device to identify itself precisely.

GLOBAL TREE TO ASSIGN IDENTIFIERS

The objects are a leaf node in the global tree. Each of the node is assigned a label consisting of

an integer and a quick description. The identifier of an object is a series of integer guiding

through the tree from the root to the good leaf. This is called the OBJECT IDENTIFIER .

The text part of each node helps to recognize what the string of number stands for. This:

iso_org_dod_internet_mgmt_mib-2_interfaces_ifTable_ifEntry_ifOperStatus is

easier to understand than 1.3.6.1.2.1.2.2.1.8 the same in the number format.

OBJECT IDENTIFIER indicates the kind of object that we want to know things about. If the

bridge or the router have more than one interface, we need to know the good one we are

interested in.

An instance identifier is used to indicate the precise value we want to see. The variable has the

form OBJECT IDENTIFER.value_we_want.

Using the preceding example we had 1.3.6.1.2.1.2.2.1.8 thus to have the third interface (in that

case it is an interface) we have 1.3.6.1.2.1.2.2.1.8.3.

The principle is that to form a variable name from OBJECT IDENTIFIER, we only have to add

an index at the end that show the item we want to access.

In the case an object defining one-and-only type of thing (e.g. description of a system, or its

location). The variable is added a 0. The path is OBJECT IDENTIFIER , and to have the

parameter we are asking for OBJECT IDENTIFIER .0.

UDP has been chosen and recommended for SNMP transport protocol. This is fine because at the

beginning, SNMP was targeted at managing Internet nodes and the predominant Internet

protocol suite TCP/IP . The choice of TCP/IP suite continue to make sense because IP became

the protocol for commercial backbone networks. And users can count on a TCP/IP

implementation available on any type of host and router .

TCP and UDP provide transport services. But UDP was preferred... This is due to TCP

characteristics, it is a complicate protocol and it consume to many memory and CPU resources.

Where as UDP is easy to build and run. Into devices (repeaters and modems) vendors have built

simple version of IP and UDP. Thus the total software needed is small and can be stored in a

ROM. UDP is well suited to the brief request / response message used in network management

communication.

Use of UDP Port Numbers

UDP application port numbers are used to identify the origin and the destination endpoints of a

message. Most standard service operate out of well-known ports, their port number are

predefined so that their partner know where they are. Many client application take a port number

out of a pool of available port numbers, and they let it free when they are done with it.

SNMP use of UDP port numbers.

The five SNMP Protocol Data Units (PDU) are in SNMP V.1 :

Get-request

is used to request the values of one or more MIB variables.

Get-next-request

is used to read the values of variables in the MIB but sequentially. It is often used to read though

a table of values. After a first read with the get-request, get-next-request are used to read through

the remaining rows.

Set-request

is used to update one of the MIB values.

Get-response

is returned as an answer to a get-request, a get-next-request or set-request message.

Trap

is used to support significant events (e.g. a cold or a warm restart or a link that has gone down).

UNIT OF INFORMATION

A get-request or set-request can read or write a single or several items. An item is a simple

variable (example: system name). We can also say that SNMP recognizes that variables are

leaves at the bottom of the naming tree.

The problem is that a manager does not know all the variables. Even when a new implementation

replaces an old one, he do not know all the variable. The get-next-request is helpful then. The

manager is able to walk through the MIB using the get-next-request command. Thus, the

manager knows all the OBJECT IDENTIFIER . When MIB variable are added, the old meanings

of the MIB do not change and there are new values in the table .

The MESSAGE FORMAT in SMMP

How does it works ? The next figure shows quickly how.

Manager talking to a new agent implementation.

Get-request and get-response Message Formats

The fields contained in those messages are the following one :

Version : version of SNMP (0 is for version 1)

Community : password used to control access to node information. It does not provide a lot of

protection against spying on the LAN .

Command : one of the five message type.

Request ID : used to correlate the request and its answer. Because a station can shoot hundreds

of request at the same time.

Error status : in response, it is used to indicate if the request was successful or not.

Error index : in case of error indicates which variable in the request caused problem.

A list of pairing OBJECT IDENTIFIER (string of integer) and variable value of the parameter

pointed by the OBJECT IDENTIFIER.

The get-request and the get-response contain the same fields. So it is easy for an agent to build

an answer to a request just by filling the holes in the get-request. Thus, get-request contains

fields set a 0 or NULL values.

A get-request can be sent for multiple variables. Then it contains the list of the variables we want

to be retrieved. The get-response fills each value from each variable of the list.

The problem with SNMP version 1, is that if for one of the requested variable, the agent is

unable to provide a value, the whole get-request will fail. Even if it is one out of the ten variables

we wanted to retrieve.

The maximal number of value to retrieve is limited by the maximum message size handle by the

manager and the agent. This maximum size is expected to be over 484 bytes in SNMP standards.

Get-next-request

The get-next-request, in its simplest use, is for a walk through a table one row at a time.

The get-next-request has the same overall format as get-request and get-response. The Command

type identifies which is which.

Different sets of variables are appropriate for bridges, routers and hosts. The variables in a pair

of routers may be different because the interface can be different in the two devices (e.g. one is

Ethernet and FDDI LANs, the other Token-Rings and T1 lines).

To know what variables are stored at a node, we can manage the node by manually creating a

master configuration database in a management station. We could, in this database, record the

type of node and the categories of MIB variables supported at the node.

In this case we would have to maintain the database by hand, each time by adding and deleting

the entries each time the configuration changed.

The other way to know the stored variable at the node is to implement a management application

that will dynamically discovers nodes of the network and ask the node what are the variables and

what they support. This second method is the way that good management station operates. The

station can operate this way because of the get-next-request operator.

The Communities The access to an agent is restricted by the community. The manager sending a message to the

agent gives its community. The community defines what level of access the manager has. Agents

have to be configured in order to know one or more community, and which right (level of access)

each community owns.

There is also community right for traps. The agent needs to know where to send its traps. It is

also configurable.

Trap message enables agent to report a serious condition to a management station. The message

is send once and it is not a chorus of complains from the device about something that is already

figured out.

As previously, for the other messages, the trap message has fields identifying the version and the

community password. Then the trap format is different and there are five other fields :

enterprise fields contain an OBJECT IDENTIFIER which name the device that sends the trap.

generic-trap contains 7 values :

o coldStart - the sender is reinitializing and its configuration may change

o warmStart - the sender is reinitializing but its configuration will not change

o linkDown - failure in one of the agent’s links

o linkUp - one of the agent’s links has come up

o authenticationFailure - the agent received a protocol message improperly authenticated

o egpNeighborLoss - an Exterior Gateway Protocol neighbor is down

o enterpriseSpecific - The trap is identified as not being one of the basic one

specific-trap field is used when the generic-trap value is enterpriseSpecific.

time ticks is the time since the initialization of the entity that send the trap.

The Enterprise specific traps can be used to define hundreds or thousands of Enterprise-specific

trap types. Those specific trap types are defined as they are needed. The 'enterprise' that defines

those traps is MIB standards group , vendors and corporate network management organizations.

Each of them adds different new traps. MIB standard groups add technology-specific traps,

vendors add product-specific traps, and corporate groups add traps that meet their special

management needs.

Manager receiving a trap.

Trap Definition Macro

RCF 1215 defined a TRAP-TYPE macro template that helps MIB designers and vendors to

define SNMP v.1 traps. The macro give the following fields that we can identify :

Enterprise : for the trap definition. This will point to a MIB subtree , or identify the entity the

trap has been designed for.

specific-trap is the number of the traps as they are defined.

you can define a list of MIB variables that will be carried in the trap message. It can be useful

in order to diagnose the problem.

a description of the trap.

Optionally, it is a reference part that relates to another trap, alarm , event ... anything

appropriate for a MIB module.

The template of trap definition is very flexible. Vendors can choose the variables that they need

and implement a product-specific message for their product.

The MIB definers may have forgotten to include something that a is important for a vendor, he

could then wrote a trap definition.

It is convenient to developers that they don’t need to wait for an official upgrade of specification

before fixing the oversight. The RFC 1215 gives the right of a legal implementation of extra

variable at the end of the official variable-list. The only condition is that the variable value is

accompanied by its OBJECT IDENTIFIER; a management application will be able to understand

the additional information that has been added.

The original MIB for managing a TCP/IP internet (now called MIB-I) was defined in RFC 1066

in 1988 and was updated in RFC 1156 in 1990. The MIB-II, published in RFC 1213 in 1991,

added a number of useful variables missing from MIB-I.

Guidelines

MIB variables have to be simple elements because of the purpose of the SNMP. So these

variables are elementary stand-alone quantities, integers, octet strings, or object identifiers.

Sometimes variables are logically organised into tables.

Extensibility

The tree of MIB variables does not have limits; it can grow and grow... So, it is not surprising

that definitions need to be improved or updated occasionally. If the improvement involves a

major change, an updated version of the MIB will simply define a completely new variable and

mark the old one as deprecated or outright obsolete.

The MIB-II tree

Eleven groups are referenced in the original MIB-II document (RFC 1213). One of these, CMOT

( ISO Common Management Information on top of TCP/IP ), is no more used because this

project was abandoned. The 10 remaining groups describe the most basic information needed to

manage a TCP/IP internet.

(Simple / OBJECT IDENTIFIER)

SNMP use the following basic ASN.1 datatypes as the most important ones :

OBJECT IDENTIFIER

INTEGER

OCTET STRING

NULL

BIT STRING ( SNMP V2 )

This is an example of how is written a datatype :

The INTEGER datatype.

ifNumber OBJECT-TYPE

SYNTAX INTEGER

ACCESS read-only

STATUS mandatory

DESCRIPTION

" The number of network interfaces

( regardless of their current states)

present on this system."

:== { interface 1 }

MIB-II system group (1.3.6.1.2.1.1)

Interfaces group (1.3.6.1.2.1.2)

Address Translation group (1.3.6.1.2.1.3)

Internet Protocol group (1.3.6.1.2.1.4)

Internet Control Message Protocol group (1.3.6.1.2.1.5)

Transmission Control Protocol group (1.3.6.1.2.1.6)

User Datagram Protocol group (1.3.6.1.2.1.7)

Exterior Gateway Protocol group (1.3.6.1.2.1.8)

SNMP group (1.3.6.1.2.1.11)

Transmission group (1.3.6.1.2.1.10)

The MIB-II system Group (1.3.6.1.2.1.1)

This group is essential for every device. It contains information about the administrative name of

the system, the name of the contact person, the system description, etc..

The most important is the sysObjectID (OBJECT IDENTIFIER assigned to a each product by its

vendor).

There is also the sysUpTime object that measures the time (in hundredths of a second) since a

system’s network was last initialized.

Example:

# snmpwalk -v1 -Os -c public 10.31.71.101 SysObjectID

sysObjectID.0 = OID: enterprises.1663.1.1.1.1.24

# snmpwalk -v1 -Os -c public 10.31.71.101 1.3.6.1.2.1.1

sysDescr.0 = STRING: SANbox 5602 FC Switch

sysObjectID.0 = OID: enterprises.1663.1.1.1.1.24

sysUpTimeInstance = Timeticks: (9873867) 1 day, 3:25:38.67

sysContact.0 = STRING: TechSupport

sysName.0 = STRING: SB5602.101

sysLocation.0 = STRING: TSLab71

sysServices.0 = INTEGER: 2

sysORLastChange.0 = Timeticks: (15) 0:00:00.15

sysORID.1 = OID: snmpFrameworkMIBCompliance

sysORID.2 = OID: snmpMPDCompliance

sysORID.3 = OID: usmMIBCompliance

sysORID.4 = OID: snmpMIB

sysORID.5 = OID: tcpMIB

sysORID.6 = OID: ip

sysORID.7 = OID: udpMIB

sysORID.8 = OID: vacmBasicGroup

sysORDescr.1 = STRING: The SNMP Management Architecture MIB.

sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching.

sysORDescr.3 = STRING: The management information definitions for the SNMP User-

based Security Model.

sysORDescr.4 = STRING: The MIB module for SNMPv2 entities

sysORDescr.5 = STRING: The MIB module for managing TCP implementations

sysORDescr.6 = STRING: The MIB module for managing IP and ICMP implementations

sysORDescr.7 = STRING: The MIB module for managing UDP implementations

sysORDescr.8 = STRING: View-based Access Control Model for SNMP.

sysORUpTime.1 = Timeticks: (13) 0:00:00.13

sysORUpTime.2 = Timeticks: (13) 0:00:00.13

sysORUpTime.3 = Timeticks: (13) 0:00:00.13

sysORUpTime.4 = Timeticks: (14) 0:00:00.14

sysORUpTime.5 = Timeticks: (14) 0:00:00.14

sysORUpTime.6 = Timeticks: (15) 0:00:00.15

sysORUpTime.7 = Timeticks: (15) 0:00:00.15

sysORUpTime.8 = Timeticks: (15) 0:00:00.15

Simple Network Management Protocol version 2 (SNMPv2) - A proposed update of version 1

that provides additional administrative structure, authentication, and privacy.

New

Datatypes

Better Textual

Convention

Definitions

Better

OBJECT-

TYPE

Definitions

Preserve

integrity or

order of sets

Better control

of table row

adds / delete

MIB

Compliance

Requierments

Vendor

Capabilities

Statements

Some of the SNMP v2 improvements.

When the version 2 was created, MIB writers had discovered that some datatype definitions

required more precision. So, SNMP v2 have differences from v1, and it brings Protocol

improvements .

Simple Network Management Protocol version 3 (SNMPv3) - A proposed update of version 3

that provides additional security and administrative capabilities.

The third version of the Simple Network Management Protocol (SNMPv3) was published as

proposed standards in RFCs 2271 to 2275 in January 1998. This version is build upon the two

first versions of SNMP and so it reuse the SNMPv2 standards documents (RFC 1902 to RFC

1908).

SNMP v3 Framework augments the original SNMP and the SNMPv2 specifications with

additional security and administration capabilities.

The new features of SNMPv3 include:

Security

authentication and privacy

authorisation and access control

Administrative Framework

naming of entities

people and policies

user names and key management

notification destinations

proxy relationships

remotely configurable via SNMP operations

SNMPv3 Security and Administration

The SNMPv3 document series defined by the SNMPv3 Working Group consists of five

documents at this time (RFC 2271 to RFC 2275).

Architecture / Security and Administration

It is the purpose of the SNMPv3 Architecture document, RFC 2271, to define an architecture for

defining SNMP Management Frameworks. It defines a number of terms and clarifies and extends

the naming of

engines and applications

entities (service providers such as the engines in agents and managers)

identities (service users)

management information, including support for multiple logical contexts.

The document contains a small MIB module which is implemented by all authoritative SNMPv3

protocol engines. An authoritative engine is the receiver of a message such as a get or set, or the

sender if the message does not require a response.

Message Processing and Dispatching

The Message Processing and Dispatching for the SNMP, proposed in RFC 2272, defines the

procedures for dispatching multiple versions of SNMP messages to the proper SNMP Message

Processing Models. It also provides the way to dispatch PDUs to SNMP applications. Finally,

this document describes one Message Processing Model - the SNMPv3 Message Processing

Model.

An SNMPv3 protocol engine MUST support at least one Message Processing Model and MAY

support more than one. For example, in a multilingual system which provides simultaneous

support of SNMPv3 and SNMPv1 and/or SNMPv2.

SNMPv3 Applications

Five types of application which can be associated with an SNMP engine are described in RFC

2273. These applications are :

Command Generators

Command Responders

Notification Originators

Notification Receivers

Proxy Forwarders.

The document also defines MIB modules for specifying targets of management operations, for

notification filtering, and for proxy forwarding.

User-based Security Model (USM)

It was proposed in RFC 2274 and it describes the User-based Security Model for SNMPv3. It

defines the Elements of Procedure for providing SNMP message-level security. The USM

protects the user against four threats, which are :

modification of information

masquerade

message stream modification

disclosure (optionally)

The USM uses MD5 (Message Digest Algorithm) and the Secure Hash Algorithm to provide

data integrity, to directly protect against data modification attacks, to indirectly provide data

origin authentication, and to defend against masquerade attacks. It also uses Data Encryption

Standard (DES) to protect against disclosure.

The document also includes a MIB for remotely monitoring and managing the configuration

parameters for the USM.

View-based Access Control Model (VACM)

It was proposed in RFC 2275 and it describes the View-based Access Control Model for

SNMPv3. It defines the Elements of Procedure for controlling access to management

information.

The VACM can simultaneously be associated in a single engine implementation with multiple

Message Processing Models and multiple Security Models.

The document also includes a MIB for remotely managing the configuration parameters for the

View-based Access Control Model.

Linux SNMP tools

What RPMs are required? Install the following RPMs:

[root@RH4U4-x86 Desktop]# rpm -qa | grep -i snmp

net-snmp-5.1.2-11.EL4.7

net-snmp-libs-5.1.2-11.EL4.7

net-snmp-utils-5.1.2-11.EL4.7

[root@RH4U4-x86 Desktop]# ls -l

total 2484

-rw-r--r-- 1 root root 517196 Mar 25 11:56 net-snmp-5.1.2-

11.el4_6.11.2.i386.rpm

-rw-r--r-- 1 root root 1832960 Mar 25 11:58 net-snmp-libs-5.1.2-

11.el4_6.11.2.i386.rpm

-rw-r--r-- 1 root root 161330 Mar 25 11:59 net-snmp-utils-

5.1.2-11.el4_6.11.2.i386.rpm

[root@RH4U4-x86 Desktop]# rpm -Uvh net-snmp-*

Preparing...

########################################### [100%]

1:net-snmp-libs

########################################### [ 33%]

2:net-snmp

########################################### [ 67%]

3:net-snmp-utils

########################################### [100%]

[root@RH4U4-x86 Desktop]# rpm -qa | grep -i snmp

net-snmp-5.1.2-11.el4_6.11.2

net-snmp-utils-5.1.2-11.el4_6.11.2

net-snmp-libs-5.1.2-11.el4_6.11.2

[root@RH4U4-x86 Desktop]# snmpwalk --version

NET-SNMP version: 5.1.2

[root@RH4U4-x86 Desktop]# ls -l /usr/bin | grep -i snmp

-rwxr-xr-x 1 root root 6740 Dec 23 17:04 snmpbulkget

-rwxr-xr-x 1 root root 8464 Dec 23 17:04 snmpbulkwalk

-rwxr-xr-x 1 root root 21209 Dec 23 17:04 snmpconf

-rwxr-xr-x 1 root root 15108 Dec 23 17:04 snmpdelta

-rwxr-xr-x 1 root root 8480 Dec 23 17:04 snmpdf

-rwxr-xr-x 1 root root 6480 Dec 23 17:04 snmpget

-rwxr-xr-x 1 root root 6336 Dec 23 17:04 snmpgetnext

lrwxrwxrwx 1 root root 8 Mar 25 12:00 snmpinform ->

snmptrap

-rwxr-xr-x 1 root root 41860 Dec 23 17:04 snmpnetstat

-rwxr-xr-x 1 root root 7916 Dec 23 17:04 snmpset

-rwxr-xr-x 1 root root 10556 Dec 23 17:04 snmpstatus

-rwxr-xr-x 1 root root 18148 Dec 23 17:04 snmptable

-rwxr-xr-x 1 root root 11444 Dec 23 17:04 snmptest

-rwxr-xr-x 1 root root 10836 Dec 23 17:04 snmptranslate

-rwxr-xr-x 1 root root 8920 Dec 23 17:04 snmptrap

-rwxr-xr-x 1 root root 17612 Dec 23 17:04 snmpusm

-rwxr-xr-x 1 root root 15852 Dec 23 17:04 snmpvacm

-rwxr-xr-x 1 root root 8332 Dec 23 17:04 snmpwalk

What are the different SNMP commands

available?

The most common used will be ‟snmpwalk‟ because it allows more flexibility…less restrictions. Snmpwalk basically does a „snmpgetnext‟ and continually repeats until going through all OIDs supported by default unless other wise specified in the command syntax.

===============================================================================

snmpget - communicates with a network entity using SNMP GET Requests.

SYNOPSIS

snmpget [COMMON OPTIONS] [-Cf] OID [OID]...

DESCRIPTION

snmpget is an SNMP application that uses the SNMP GET request to query for information on a

network entity. One or more object identifiers (OIDs) may be given as arguments on the command

line. Each variable name is given in the format specified in variables(5).

For example:

snmpget -c public zeus system.sysDescr.0

will retrieve the variable system.sysDescr.0:

system.sysDescr.0 = "SunOS zeus.net.cmu.edu 4.1.3_U1 1 sun4m"

If the network entity has an error processing the request packet, an error packet will be

returned and a message will be shown, helping to pinpoint in what way the request was mal-

formed. If there were other variables in the request, the request will be resent without the

bad variable.

Examples:

# snmpget -v1 -Os -c public 10.31.71.101 sysObjectID.0

sysObjectID.0 = OID: enterprises.1663.1.1.1.1.24

# snmpget -v1 -Of -c public 10.31.71.101 sysObjectID.0

.iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0 = OID:

.iso.org.dod.internet.private.enterprises.1663.1.1.1.1.24

# snmpget -v1 -Oa -c public 10.31.71.101 sysObjectID.0

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-

SMI::enterprises.1663.1.1.1.1.24

# snmpget -v1 -On -c public 10.31.71.101 sysObjectID.0

.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.1663.1.1.1.1.24

Comments:

If using snmpget, you must know the exact OID and append a „.0‟ to it. The ASCII format of the OID is case-sensitive. If using numerical format, just remember to append a „.0‟ similar to the ASCII format.

===============================================================================

snmpgetnext - communicates with a network entity using SNMP GET NEXT Requests.

SYNOPSIS

snmpgetnext [COMMON OPTIONS] [-Cf] OID [OID]...

DESCRIPTION

snmpget is an SNMP application that uses the SNMP GETNEXT request to query for information on a

Network entity. One or more object identifiers (OIDs) may be given as arguments on the command

Line. Each variable name is given in the format specified in variables(5). For each one, the

Variable that is lexicographically "next" in the remote entity’s MIB will be returned.

For example:

snmpgetnext -c public zeus interfaces.ifTable.ifEntry.ifType.1

will retrieve the variable interfaces.ifTable.ifEntry.ifType.2:

interfaces.ifTable.ifEntry.ifType.2 = softwareLoopback(24)

If the network entity has an error processing the request packet, an error message will be

shown, helping to pinpoint in what way the request was malformed.

Examples:

# snmpgetnext -v1 -OT -c public 10.31.71.101 sysObjectID.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (16653030) 1 day,

22:15:30.30

# snmpgetnext -v1 -On -c public 10.31.71.101 sysObjectID.0

.1.3.6.1.2.1.1.3.0 = Timeticks: (16655967) 1 day, 22:15:59.67

# snmpgetnext -v1 -On -c public 10.31.71.101 sysUpTimeInstance.0

.1.3.6.1.2.1.1.4.0 = STRING: TechSupport

# snmpgetnext -v1 -On -c public 10.31.71.101 sysUpTimeInstance

.1.3.6.1.2.1.1.4.0 = STRING: TechSupport

# snmpgetnext -v1 -OT -c public 10.31.71.101 sysUpTimeInstance

SNMPv2-MIB::sysContact.0 = STRING: TechSupport

Comments:

If using snmpgetnext, this always returns the next OID following the OID used in the command string. In the example above, if doing snmpgetnext to sysObject.0 (.1.3.6.1.2.1.1.2.0), it returns the next OID which is sysUpTimeInstance (.1.3.6.1.2.1.1.3.0). This command is more flexible since you don‟t need to enter the exact OID (ASCII or numerical format) and is actually similar to the command used in snmpwalk.

===============================================================================

snmpbulkget - communicates with a network entity using SNMP GETBULK Requests.

SYNOPSIS

snmpbulkget [APPLICATION OPTIONS] [COMMON OPTIONS] OID [OID]...

DESCRIPTION

snmpbulkget is an SNMP application that uses the SNMP GETBULK request to query a network entity

efficiently for information. One or more object identifiers (OIDs) may be given as arguments

on the command line. Each variable name is given in the format specified in variables(5).

If the network entity has an error processing the request packet, an error packet will be

returned and a message will be shown, helping to pinpoint why the request was malformed.

Examples:

# snmpbulkget -v2c -OT -c public 10.31.71.101 sysObjectID.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (17005608) 1 day,

23:14:16.08

SNMPv2-MIB::sysContact.0 = STRING: TechSupport

SNMPv2-MIB::sysName.0 = STRING: SB5602.101

SNMPv2-MIB::sysLocation.0 = STRING: TSLab71

SNMPv2-MIB::sysServices.0 = INTEGER: 2

SNMPv2-MIB::sysORLastChange.0 = Timeticks: (15) 0:00:00.15

SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-

MIB::snmpFrameworkMIBCompliance

SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance

SNMPv2-MIB::sysORID.3 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance

SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB

# snmpbulkget -v2c -On -c public 10.31.71.101 sysObjectID.0

.1.3.6.1.2.1.1.3.0 = Timeticks: (17011703) 1 day, 23:15:17.03

.1.3.6.1.2.1.1.4.0 = STRING: TechSupport

.1.3.6.1.2.1.1.5.0 = STRING: SB5602.101

.1.3.6.1.2.1.1.6.0 = STRING: TSLab71

.1.3.6.1.2.1.1.7.0 = INTEGER: 2

.1.3.6.1.2.1.1.8.0 = Timeticks: (15) 0:00:00.15

.1.3.6.1.2.1.1.9.1.2.1 = OID: .1.3.6.1.6.3.10.3.1.1

.1.3.6.1.2.1.1.9.1.2.2 = OID: .1.3.6.1.6.3.11.3.1.1

.1.3.6.1.2.1.1.9.1.2.3 = OID: .1.3.6.1.6.3.15.2.1.1

.1.3.6.1.2.1.1.9.1.2.4 = OID: .1.3.6.1.6.3.1

Comments:

If using snmpbulkget, it send only one snmp request to the snmp agent, the agent then responses with a single response packet (depending on packet size) which includes the payload containing all OIDs requested. Most snmp queries only use one request followed by one response for each single OID. This includes snmpget, snmpgetnext, snmpwalk, etc.. Not supported on v1.

===============================================================================

snmptable - obtain and print an SNMP table

SYNOPSIS

snmptable [COMMON OPTIONS] [-Cb] [-CB] [-Ch] [-CH] [-Ci] [-Cf STRING] [-Cw WIDTH] AGENT TABLE-

OID

DESCRIPTION

snmptable is an SNMP application that repeatedly uses the SNMP GETNEXT or GETBULK requests to query for information on a network entity. The parameter TABLE-OID must specify an SNMP table.

snmptable is an SNMP application that repeatedly uses the SNMP GETNEXT or GETBULK requests to query for information on a network entity. The parameter TABLE-OID must specify an SNMP table.

AGENT identifies a target SNMP agent, which is instrumented to monitor the given objects. At its simplest, the AGENT specification will consist of a hostname or an IPv4 address. In this situation, the command will attempt communication with the agent, using UDP/IPv4 to port 161 of the given target host. See snmpcmd(1) for a full list of the possible formats for AGENT.

Examples:

In the Fibre Alliance (FA) MIB, it supports multiple tables. In the first example, this was a multi-switch fabric, but ProxyEnable=False so it snmp request only returned data the that out-of-band switch.

# snmptable -v2c -OT -c public -m MIB:./fa_40.mib 10.31.71.101 connUnitRevsTable

SNMP table: FCMGMT-MIB::connUnitRevsTable

connUnitRevsUnitId connUnitRevsIndex

connUnitRevsRevId connUnitRevsDescription

"10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 [................]" 1

"V7.4.0.0.96" "Active Firmware image"

"10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 [................]" 2

"V7.4.0.0.96" "Flasher Shell Version"

"10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 [................]" 3

"0" "Hardware ASIC Version."

In a multi-switch fabric and ProxyEnable=True on the out-of-band switch, it will return all OIDs for every switch in the fabric. This fabric had three switches.

# snmptable -v2c -OT -c public -m MIB:./fa_40.mib 10.31.71.101 connUnitRevsTable

SNMP table: FCMGMT-MIB::connUnitRevsTable

connUnitRevsUnitId connUnitRevsIndex

connUnitRevsRevId connUnitRevsDescription

"10 00 00 C0 DD 02 CC 7A 00 00 00 00 00 00 00 00 [.......z........]" 1

"V7.4.0.0.96" "Active Firmware image"

"10 00 00 C0 DD 02 CC 7A 00 00 00 00 00 00 00 00 [.......z........]" 2

"V7.4.0.0.96" "Flasher Shell Version"

"10 00 00 C0 DD 02 CC 7A 00 00 00 00 00 00 00 00 [.......z........]" 3

"0" "Hardware ASIC Version."

"10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 [................]" 1

"V7.4.0.0.96" "Active Firmware image"

"10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 [................]" 2

"V7.4.0.0.96" "Flasher Shell Version"

"10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 [................]" 3

"0" "Hardware ASIC Version."

"10 00 00 C0 DD 07 2D 3C 00 00 00 00 00 00 00 00 [......-<........]" 1

"V7.4.0.0.96" "Active Firmware image"

"10 00 00 C0 DD 07 2D 3C 00 00 00 00 00 00 00 00 [......-<........]" 2

"V7.4.0.0.96" "Flasher Shell Version"

"10 00 00 C0 DD 07 2D 3C 00 00 00 00 00 00 00 00 [......-<........]" 3

"0" "Hardware ASIC Version."

Also notice the order of the data of the output. This particular connUnitRevsTable has three OIDs defined. But the order in which the data is returned is based on the lowest to highest switch WWN as defined by the Fibre Alliance (FA) MIB. If using the Fabric Element (FE) MIB, the order of output for tables will be based on lowest to highest Domain ID. Why different? The two MIBs were written by two different groups and had different requirements.

In this Fabric Element MIB query of the fcFeModuleTable to a multi-switch fabric, but the out-of-band switch had ProxyEnabled=false.

# snmptable -v2c -OT -c public -m MIB:./fe.mib 10.31.71.101 fcFeModuleTable

SNMP table: FIBRE-CHANNEL-FE-MIB::fcFeModuleTable

fcFeModuleDescr fcFeModuleObjectID fcFeModuleOperStatus

fcFeModuleFxPortCapacity fcFeModuleName

SANbox 5602 FC Switch SNMPv2-SMI::enterprises.1663.1.1.1.1.24 online

20 "10 00 00 C0 DD 06 FA A1 [........]"

In this Fabric Element MIB query of the fcFeModuleTable to a multi-switch fabric, but the out-of-band switch had ProxyEnabled=True. Notice the order of output. For the Fabric Element (FE) MIB, the results are indexed based on the lowest to highest Domain ID.

# snmptable -v2c -OT -c public -m MIB:./fe.mib 10.31.71.101 fcFeModuleTable

Cannot find module (MIB): At line 0 in (none)

SNMP table: FIBRE-CHANNEL-FE-MIB::fcFeModuleTable

fcFeModuleDescr fcFeModuleObjectID fcFeModuleOperStatus

fcFeModuleFxPortCapacity fcFeModuleName

SANbox 5602 FC Switch SNMPv2-SMI::enterprises.1663.1.1.1.1.24 online

20 "10 00 00 C0 DD 06 FA A1 [........]"

SANbox 5200 FC Switch SNMPv2-SMI::enterprises.1663.1.1.1.1.17 online

20 "10 00 00 C0 DD 02 CC 7A [.......z]"

SANbox 5600 FC Switch SNMPv2-SMI::enterprises.1663.1.1.1.1.23 online

20 "10 00 00 C0 DD 07 2D 3C [......-<]"

Comments:

If using snmptable, it will only work when actually querying an agent that supports tables for the OID specified. This can be useful since an OID can have multiple objects defined. As an example would be our FC switch that has multiple FC ports. To display each individual port can be cumbersome unless exact OID is known. Snmptable provide a more readable format output. The FE and FA MIBs supported without FC product use tables for some OIDs.

===============================================================================

snmpwalk - communicates with a network entity using SNMP GETNEXT requests.

SYNOPSIS

snmpwalk [APPLICATION OPTIONS] [COMMON OPTIONS] [OID]

DESCRIPTION

snmpwalk is an SNMP application that uses SNMP GETNEXT requests to query a network entity for a

tree of information.

An object identifier (OID) may be given on the command line. This OID specifies which portion of the object identifier space will be searched using GETNEXT requests. All variables in the subtree below the given OID are queried and their values presented to the user. Each variable name is given in the format specified in variables (5).

If no OID argument is present, snmpwalk will search MIB-2. If the network entity has an error processing the request packet, an error packet will be returned and a message will be shown, helping to pinpoint why the request was malformed.

If the tree search causes attempts to search beyond the end of the MIB, the message "End of MIB" will be displayed.

Examples:

# snmpwalk -v1 -OT -c public 10.31.71.101

SNMPv2-MIB::sysDescr.0 = STRING: SANbox 5602 FC Switch

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.1663.1.1.1.1.24

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (17546162) 2 days, 0:44:21.62

SNMPv2-MIB::sysContact.0 = STRING: TechSupport

SNMPv2-MIB::sysName.0 = STRING: SB5602.101

SNMPv2-MIB::sysLocation.0 = STRING: TSLab71

SNMPv2-MIB::sysServices.0 = INTEGER: 2

<snip>

If providing a specific MIB, you can start the snmpwalk from a certain OID as in this example to the Fabric Element (FE) MIB in a multi-switch fabric.

# snmpwalk -v1 -On -m MIB:./fe.mib -c public 10.31.71.101 1.3.6.1.2.1.75

Cannot find module (MIB): At line 0 in (none)

.1.3.6.1.2.1.75.1.1.1.0 = Hex-STRING: 10 00 00 C0 DD 02 CC 7A

.1.3.6.1.2.1.75.1.1.2.0 = Hex-STRING: 10 00 00 C0 DD 06 FA A1

.1.3.6.1.2.1.75.1.1.3.0 = Gauge32: 3

.1.3.6.1.2.1.75.1.1.4.1.2.1 = STRING: SANbox 5602 FC Switch

.1.3.6.1.2.1.75.1.1.4.1.2.2 = STRING: SANbox 5200 FC Switch

.1.3.6.1.2.1.75.1.1.4.1.2.3 = STRING: SANbox 5600 FC Switch

.1.3.6.1.2.1.75.1.1.4.1.3.1 = OID: .1.3.6.1.4.1.1663.1.1.1.1.24

.1.3.6.1.2.1.75.1.1.4.1.3.2 = OID: .1.3.6.1.4.1.1663.1.1.1.1.17

.1.3.6.1.2.1.75.1.1.4.1.3.3 = OID: .1.3.6.1.4.1.1663.1.1.1.1.23

.1.3.6.1.2.1.75.1.1.4.1.4.1 = INTEGER: online(1)

.1.3.6.1.2.1.75.1.1.4.1.4.2 = INTEGER: online(1)

.1.3.6.1.2.1.75.1.1.4.1.4.3 = INTEGER: online(1)

<snip>

And in these examples using the Fibre Alliance (FA) MIB in a multi-switch fabric as the starting point with different outputs of the same data:

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 1.3.6.1.3.94

.1.3.6.1.3.94.1.1.0 = INTEGER: 3

.1.3.6.1.3.94.1.2.0 = STRING: "http://0a1f4765"

.1.3.6.1.3.94.1.3.0 = Timeticks: (0) 0:00:00.00

.1.3.6.1.3.94.1.4.0 = Timeticks: (17317360) 2 days, 0:06:13.60

.1.3.6.1.3.94.1.5.0 = Timeticks: (0) 0:00:00.00

.1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0

DD 02 CC 7A 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0

DD 06 FA A1 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0 DD

07 2D 3C 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.2.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0

DD 02 CC 7A 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.2.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0

DD 06 FA A1 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.2.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0 DD

07 2D 3C 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.3.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: switch(4)

.1.3.6.1.3.94.1.6.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: switch(4)

.1.3.6.1.3.94.1.6.1.3.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: switch(4)

.1.3.6.1.3.94.1.6.1.4.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: 20

.1.3.6.1.3.94.1.6.1.4.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: 20

.1.3.6.1.3.94.1.6.1.4.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: 20

.1.3.6.1.3.94.1.6.1.5.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: online(2)

.1.3.6.1.3.94.1.6.1.5.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: online(2)

.1.3.6.1.3.94.1.6.1.5.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: online(2)

<snip>

# snmpwalk -v1 -OT -m MIB:./fa_40.mib -c public 10.31.71.101 1.3.6.1.3.94

FCMGMT-MIB::uNumber.0 = INTEGER: 3

FCMGMT-MIB::systemURL.0 = STRING: "http://0a1f4765"

FCMGMT-MIB::statusChangeTime.0 = Timeticks: (0) 0:00:00.00

FCMGMT-MIB::configurationChangeTime.0 = Timeticks: (17317360) 2 days, 0:06:13.60

FCMGMT-MIB::connUnitTableChangeTime.0 = Timeticks: (0) 0:00:00.00

FCMGMT-MIB::connUnitId.'.......z........' = Hex-STRING: 10 00 00 C0 DD 02 CC 7A 00 00 00

00 00 00 00 00 [.......z........]

FCMGMT-MIB::connUnitId.'................' = Hex-STRING: 10 00 00 C0 DD 06 FA A1 00 00 00

00 00 00 00 00 [................]

FCMGMT-MIB::connUnitId.'......-<........' = Hex-STRING: 10 00 00 C0 DD 07 2D 3C 00 00 00

00 00 00 00 00 [......-<........]

FCMGMT-MIB::connUnitGlobalId.'.......z........' = Hex-STRING: 10 00 00 C0 DD 02 CC 7A 00

00 00 00 00 00 00 00 [.......z........]

FCMGMT-MIB::connUnitGlobalId.'................' = Hex-STRING: 10 00 00 C0 DD 06 FA A1 00

00 00 00 00 00 00 00 [................]

FCMGMT-MIB::connUnitGlobalId.'......-<........' = Hex-STRING: 10 00 00 C0 DD 07 2D 3C 00

00 00 00 00 00 00 00 [......-<........]

FCMGMT-MIB::connUnitType.'.......z........' = INTEGER: switch(4)

FCMGMT-MIB::connUnitType.'................' = INTEGER: switch(4)

FCMGMT-MIB::connUnitType.'......-<........' = INTEGER: switch(4)

FCMGMT-MIB::connUnitNumports.'.......z........' = INTEGER: 20

FCMGMT-MIB::connUnitNumports.'................' = INTEGER: 20

FCMGMT-MIB::connUnitNumports.'......-<........' = INTEGER: 20

FCMGMT-MIB::connUnitState.'.......z........' = INTEGER: online(2)

FCMGMT-MIB::connUnitState.'................' = INTEGER: online(2)

FCMGMT-MIB::connUnitState.'......-<........' = INTEGER: online(2)

<snip>

Comments:

Snmpwalk is the most useful tool as it is very flexible and will go walk through all available OIDs defined. If some OIDs are not defined, it will not walk through them. But if you provide the MIB in the snmpwalk command line, it will display those OIDs if the agent supports them.

===============================================================================

snmpset - communicates with a network entity using SNMP SET Requests.

SYNOPSIS

snmpset [COMMON OPTIONS] OID TYPE VALUE [OID TYPE VALUE]...

DESCRIPTION

snmpset is an SNMP application that uses the SNMP SET request to set information on a network entity. One or more object identifiers (OIDs) must be given as arguments on the command line.

A type and a value to be set must accompany each object identifier. Each variable name is given in the format specified in variables(5).

The TYPE is a single character, one of:

i INTEGER

u UNSIGNED

s STRING

x HEX STRING

d DECIMAL STRING

n NULLOBJ

o OBJID

t TIMETICKS

a IPADDRESS

b BITS

Most of these will use the obvious corresponding ASN.1 type. value, and the ’u’ unsigned type is also used for handling Gauge32 values. If you have the proper MIB file loaded, you can, in most cases, replace the type with an ’=’ sign. For an object of type OCTET STRING this

will assume a string like the ’s’ type notation. For other types it will do "The Right Thing".

For example:

snmpset -c private -v 1 test-hub system.sysContact.0 s dpz@noc.rutgers.edu ip.ipforwarding.0 = 2 will set the variables s

ysContact.0 and ipForwarding.0:

system.sysContact.0 = STRING: "dpz@noc.rutgers.edu"

ip.ipForwarding.0 = INTEGER: not-forwarding(2)

If the network entity has an error processing the request packet, an error packet will be returned and a message will be shown, helping to pinpoint in what way the request was mal-formed.

Examples:

How to put a switch offline using the snmpset command to switch in a multi-switch fabric requires the following information; OID.0, TYPE, and VALUE. First determine the current OID value for each switch in the fabric using snmpwalk or snmpgetnext using the numerical output. The order returned is indexed based on the lowest to highest WWN since the Fabre Alliance (FA) MIB is used.

The snmpwalk returns the current connUnitControl for all switches in the fabric.

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitControl

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

Then using those results, an snmpget can also be done to get the same information to learn what the full OID is for each switch in the fabric. The syntax can be very difficult to get correct, but once the full OID string is known using snmpwalk (above example), those results can be used. The snmpget is more difficult because you need to include the full OID string for each switch WWN (converted to decimal) followed by eight zeros (.0.0.0.0.0.0.0.0).

# snmpget -v1 -Oa -m MIB:./fa_40.mib -c public 10.31.71.101

connUnitControl.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitControl.'.......z........' = INTEGER: onlineConnUnit(6)

# snmpget -v1 -Oa -m MIB:./fa_40.mib -c public 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitControl.'................' = INTEGER: onlineConnUnit(6)

# snmpget -v1 -Oa -m MIB:./fa_40.mib -c public 10.31.71.101

connUnitControl.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitControl.'......-<........' = INTEGER: onlineConnUnit(6)

To use snmpset, be cautious of what the full OID is, the variable type, and the value. In the example, I will be putting switch with WWN = 10:00:00:c0:dd:06:fa:a1 to an Offline state.

Switch WWN = 10:00:00:c0:dd:06:fa:a1 (hex) in decimal is 16.0.0.192.221.6.250.161

# snmpset -v1 -Oa -m MIB:./fa_40.mib -c private 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 i 5

FCMGMT-MIB::connUnitControl.'................' = INTEGER: offlineConnUnit(5)

And to check:

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitControl

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER:

offlineConnUnit(5)

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.110 connUnitControl

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

Or

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.111 connUnitControl

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

To put the switch to an Online state, change the variable:

# snmpset -v1 -Oa -m MIB:./fa_40.mib -c private 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 i 6

FCMGMT-MIB::connUnitControl.'................' = INTEGER: onlineConnUnit(6)

Then an snmpwalk should return with all three switches in the fabric if it merges

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitControl

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

.1.3.6.1.3.94.1.6.1.22.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

Comments:

Using snmpset can be very tricky and usually requires trial and error technique. Depending on the MIB and how the Units are indexed can play a very big role in a multi-switch fabric. Once the full OID is known, then the TYPE (i.e. integer, string, etc) needs to be correct. If the OID supports writes, then the VALUE also needs to be correct.

=========================================================================

snmptrap, snmpinform - sends an SNMP trap to a manager

SYNOPSIS

snmptrap -v 1 [COMMON OPTIONS] [-Ci] enterprise-oid agent generic-trap specific-trap uptime

[OID TYPE VALUE]...

snmptrap -v [2c|3] [COMMON OPTIONS] [-Ci] uptime trap-oid [OID TYPE VALUE]...

snmpinform -v [2c|3] [COMMON OPTIONS] uptime trap-oid [OID TYPE VALUE]...

DESCRIPTION

snmptrap is an SNMP application that uses the SNMP TRAP operation to send information to a net-work manager. One or more object identifiers (OIDs) can be given as arguments on the

command line. A type and a value must accompany each object identifier. Each variable name is given in the format specified in variables(5).

When invoked as snmpinform, or when -Ci is added to the command line flags of snmptrap, it sends an INFORM-PDU, expecting a response from the trap receiver, retransmitting if required.

Otherwise it sends an TRAP-PDU or TRAP2-PDU.

If any of the required version 1 parameters, enterprise-oid, agent, and uptime are specified as empty, it defaults to 1.3.6.1.4.1.3.1.1 (enterprises.cmu.1.1), hostname, and host-uptime respectively.

The TYPE is a single character, one of:

i INTEGER

u UNSIGNED

c COUNTER32

s STRING

x HEX STRING

d DECIMAL STRING

n NULLOBJ

o OBJID

t TIMETICKS

a IPADDRESS

b BITS

which are handled in the same way as the snmpset command.

For example:

snmptrap -v 1 -c public manager enterprises. Spider test-hub 3 0 ’’ interfaces.iftable.ifen-try.ifindex.1 i 1 will send a generic linkUp trap to manager, for interface 1.

=========================================================================

Comments:

To use snmptrap requires that the snmp agent supports this. Currently, our switch does not support this capability.

SNMP commands to FC switch using supported

MIBs?

Our Fibre Channel Switch firmware supports the following MIBs:

MIB-II – Generic MIB supported by almost all SNMP capable products.

Fibric Element MIB (rfc2837) – This is an industry standard MIB

Fibre Alliance 4.0 MIB – This is also an industry standard MIB for Fibre Channel Switches, but adds more than the FE MIB.

QLogic MIB – This private MIB adds capability to Operational change port states and additional Traps not in FA MIB.

Documentation is your friend. The SNMP manual for the supported MIBs is this first place to start in determining what works or doesn‟t work. Some OIDs defined in the supported MIBs are either not supported (does not apply), or has limited support. The other alternative is to actually look at the MIB file since it is ASCII readable.

If doing snmpset commands, this requires „admin authority‟. If some user has an open Telnet/SSH session with admin authority, the snmpset requests will fail.

Example SNMP commands to an FC switch.

How many switches are in the fabric?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 uNumber

.1.3.6.1.3.94.1.1.0 = INTEGER: 3

# snmpget -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 uNumber.0

.1.3.6.1.3.94.1.1.0 = INTEGER: 3

Comments: This particular fabric has 3 switches. This assumes that the out-of-band switch has ProxyEnabled=True.

What models of switches are in the fabric?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitProduct

.1.3.6.1.3.94.1.6.1.7.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = STRING: "SANbox 5200 FC

Switch"

.1.3.6.1.3.94.1.6.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = STRING: "SANbox 5602 FC

Switch"

.1.3.6.1.3.94.1.6.1.7.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = STRING: "SANbox 5600 FC

Switch"

What are the serial numbers of each switch in the fabric?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitSn

.1.3.6.1.3.94.1.6.1.8.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = STRING: "FAM0331000007"

.1.3.6.1.3.94.1.6.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = STRING: "0441A00168"

.1.3.6.1.3.94.1.6.1.8.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = STRING: "0537A00314"

What are the Domain IDs of each switch?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitDomainId

.1.3.6.1.3.94.1.6.1.11.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = Hex-STRING: FF FC 65

.1.3.6.1.3.94.1.6.1.11.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = Hex-STRING: FF FC 66

.1.3.6.1.3.94.1.6.1.11.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = Hex-STRING: FF FC 64

Comments: The Domain ID uses only on byte. In this example, there are three switches in the fabric at Domain IDs 65, 66, & 64. Notice the order in which they are displayed. The reason is because the switch with Domain ID 65 has the lowest WWN and so on.

What are the switches WWNs?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitId

.1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0

DD 02 CC 7A 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0

DD 06 FA A1 00 00 00 00 00 00 00 00

.1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0 DD

07 2D 3C 00 00 00 00 00 00 00 00

Comments: The return string has the switches WWN always followed by eight octets of zero‟s. Another way is to convert the full numerical OID from hex to decimal. In the OID above it includes 16.0.0.192.221.6.250.161 for one of the switches in the fabric. If each octet in decimal is converted to hex, it should comes out to match the switches WWN of 10:00:00:C0:DD:06:FA:A1.

Decimal Hex

16 10

0 00

0 00

192 C0

221 DD

6 06

250 FA

161 A1

What are the IP addresses of each switch in the fabric?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitUrl

.1.3.6.1.3.94.1.6.1.10.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = STRING:

"http://10.31.71.111"

.1.3.6.1.3.94.1.6.1.10.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = STRING:

"http://10.31.71.101"

.1.3.6.1.3.94.1.6.1.10.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = STRING:

"http://10.31.71.110"

What many devices (Initiators/Targets) are attached to the fabric?

# snmpwalk -v1 -On -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitSnsMaxEntry

.1.3.6.1.3.94.5.1.1.0 = INTEGER: 11

Comments: In my fabric, I had 3 Initiators, 2 RAID connections, and 2 JBODs (w/ 3 disks each)

What are the WWNN, WWPN, and Port address of each device attached to the fabric?

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitSnsPortName

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.249.40

.101.8.225 = Hex-STRING: 50 05 07 67 0E 4F F9 28

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.253.22

5.101.8.226 = Hex-STRING: 50 05 07 67 0E 4F FD E1

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.254.15

1.101.8.232 = Hex-STRING: 50 05 07 67 0E 4F FE 97

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143.249.4

0.101.10.225 = Hex-STRING: 50 05 07 67 0E 8F F9 28

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143.253.2

25.101.10.226 = Hex-STRING: 50 05 07 67 0E 8F FD E1

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143.254.1

51.101.10.232 = Hex-STRING: 50 05 07 67 0E 8F FE 97

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.0.0.224.139.8.97.61.

102.0.0 = Hex-STRING: 21 00 00 E0 8B 08 61 3D

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.0.0.224.139.26.201.4

0.102.2.0 = Hex-STRING: 21 00 00 E0 8B 1A C9 28

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.1.0.224.139.40.97.61

.102.1.0 = Hex-STRING: 21 01 00 E0 8B 28 61 3D

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.32.28.0.160.184.17.73.116

.100.15.0 = Hex-STRING: 20 1C 00 A0 B8 11 49 74

FCMGMT-

MIB::connUnitSnsPortName.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.32.44.0.160.184.17.73.116

.100.13.0 = Hex-STRING: 20 2C 00 A0 B8 11 49 74

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitSnsNodeName

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.249.40

.101.8.225 = Hex-STRING: 50 05 07 67 0E 0F F9 28

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.253.22

5.101.8.226 = Hex-STRING: 50 05 07 67 0E 0F FD E1

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.254.15

1.101.8.232 = Hex-STRING: 50 05 07 67 0E 0F FE 97

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143.249.4

0.101.10.225 = Hex-STRING: 50 05 07 67 0E 0F F9 28

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143.253.2

25.101.10.226 = Hex-STRING: 50 05 07 67 0E 0F FD E1

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143.254.1

51.101.10.232 = Hex-STRING: 50 05 07 67 0E 0F FE 97

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.0.0.224.139.8.97.61.

102.0.0 = Hex-STRING: 20 00 00 E0 8B 08 61 3D

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.0.0.224.139.26.201.4

0.102.2.0 = Hex-STRING: 20 00 00 E0 8B 1A C9 28

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.1.0.224.139.40.97.61

.102.1.0 = Hex-STRING: 20 01 00 E0 8B 28 61 3D

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.32.28.0.160.184.17.73.116

.100.15.0 = Hex-STRING: 20 0C 00 A0 B8 11 49 74

FCMGMT-

MIB::connUnitSnsNodeName.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.32.44.0.160.184.17.73.116

.100.13.0 = Hex-STRING: 20 0C 00 A0 B8 11 49 74

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitSnsPortIdentifier

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.

249.40.101.8.225 = Hex-STRING: 65 08 E1

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.

253.225.101.8.226 = Hex-STRING: 65 08 E2

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.79.

254.151.101.8.232 = Hex-STRING: 65 08 E8

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143

.249.40.101.10.225 = Hex-STRING: 65 0A E1

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143

.253.225.101.10.226 = Hex-STRING: 65 0A E2

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.80.5.7.103.14.143

.254.151.101.10.232 = Hex-STRING: 65 0A E8

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.0.0.224.139.8.

97.61.102.0.0 = Hex-STRING: 66 00 00

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.0.0.224.139.26

.201.40.102.2.0 = Hex-STRING: 66 02 00

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.33.1.0.224.139.40

.97.61.102.1.0 = Hex-STRING: 66 01 00

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.32.28.0.160.184.17.

73.116.100.15.0 = Hex-STRING: 64 0F 00

FCMGMT-

MIB::connUnitSnsPortIdentifier.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.32.44.0.160.184.17.

73.116.100.13.0 = Hex-STRING: 64 0D 00

Can port statistics be gathered?

Use the following example to return Decode Errors. The output returns the Invalid Tx Words (or Decode Errors) on a port. This example is what was returned for a three switch fabric. On the second switch with ports 0, 1, 2 with Initiators attached I unplugged/re-plugged the cable resulting in Decode Errors on those ports. Notice that the output is in hex and that the port is ones based.

connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = Hex-

STRING: 00 00 00 00 00 00 01 4D

OID = connUnitPortStatCountInvalidTxWords

Switch WWN = .16.0.0.192.221.6.250.161

Padding = .0.0.0.0.0.0.0.0

Port# (ones based) = .1 (This is switch port 0)

Value (Hex) = 00 00 00 00 00 00 01 4D (Convert to decimal if comparing to ‘show

port x’ output)

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101

connUnitPortStatCountInvalidTxWords

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.1 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.2 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.3 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.4 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.5 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.6 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.7 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.8 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.9 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.10 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.11 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.12 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.13 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.14 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.15 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.16 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.17 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.18 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.19 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0.20 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 =

Hex-STRING: 00 00 00 00 00 00 01 4D

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 =

Hex-STRING: 00 00 00 00 00 00 50 3B

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 =

Hex-STRING: 00 00 00 00 00 09 10 0D

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.7 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.8 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.9 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.10 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.11 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.12 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.13 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.14 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.15 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.16 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.17 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.18 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.19 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.20 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.1

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.2

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.3

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.4

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.5

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.6

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.7

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.8

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.9

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.10

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.11

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.12

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.13

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.14

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.15

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.16

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.17

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.18

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.19

= Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitPortStatCountInvalidTxWords.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0.20

= Hex-STRING: 00 00 00 00 00 00 00 00

Comments: Using snmp queries to connUnitPortStatisticsTable can return most port info and more. This includes Port Status, Error counters, Port Speed, SFP info, etc.

Can zoning be viewed or changed using snmp?

No, only the current active Zoneset can be viewed and can not be changed using SNMP. To view zoning, using snmp request to connUnitZoneTable.

What is the active Zoneset name? ZS1

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitZonesetName

FCMGMT-MIB::connUnitZoneSetName.1.1 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.1.2 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.1.3 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.2.1 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.2.2 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.2.3 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.3.1 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.3.2 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.3.3 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.3.4 = STRING: "ZS1"

FCMGMT-MIB::connUnitZoneSetName.3.5 = STRING: "ZS1"How many zones are there? 3

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitZoneSetNumZones

FCMGMT-MIB::connUnitZoneSetNumZones.1.1 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.1.2 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.1.3 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.2.1 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.2.2 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.2.3 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.3.1 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.3.2 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.3.3 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.3.4 = INTEGER: 3

FCMGMT-MIB::connUnitZoneSetNumZones.3.5 = INTEGER: 3

What are the zone names? Z1, Z2, Z3

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitZoneName

FCMGMT-MIB::connUnitZoneName.1.1 = STRING: "Z1"

FCMGMT-MIB::connUnitZoneName.1.2 = STRING: "Z1"

FCMGMT-MIB::connUnitZoneName.1.3 = STRING: "Z1"

FCMGMT-MIB::connUnitZoneName.2.1 = STRING: "Z2"

FCMGMT-MIB::connUnitZoneName.2.2 = STRING: "Z2"

FCMGMT-MIB::connUnitZoneName.2.3 = STRING: "Z2"

FCMGMT-MIB::connUnitZoneName.3.1 = STRING: "Z3"

FCMGMT-MIB::connUnitZoneName.3.2 = STRING: "Z3"

FCMGMT-MIB::connUnitZoneName.3.3 = STRING: "Z3"

FCMGMT-MIB::connUnitZoneName.3.4 = STRING: "Z3"

FCMGMT-MIB::connUnitZoneName.3.5 = STRING: "Z3"

What are the Members of each Zone?

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitZoneMemberID

FCMGMT-MIB::connUnitZoneMemberID.1.1 = Hex-STRING: 64 0D 00 00 00 00 00 00 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.1.2 = Hex-STRING: 65 08 00 00 00 00 00 00 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.1.3 = Hex-STRING: 66 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.2.1 = Hex-STRING: 64 0D 00 00 00 00 00 00 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.2.2 = Hex-STRING: 65 08 E1 00 00 00 00 00 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.2.3 = Hex-STRING: 66 01 00 00 00 00 00 00 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.3.1 = Hex-STRING: 20 2C 00 A0 B8 11 49 74 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.3.2 = Hex-STRING: 21 00 00 E0 8B 1A C9 28 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.3.3 = Hex-STRING: 50 05 07 67 0E 4F F9 28 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.3.4 = Hex-STRING: 50 05 07 67 0E 4F FD E1 00 00 00 00 00

00 00 00

FCMGMT-MIB::connUnitZoneMemberID.3.5 = Hex-STRING: 50 05 07 67 0E 4F FE 97 00 00 00 00 00

00 00 00

What zoning type are the members of each Zone? 1 = WWPN, 2 = Domain & Port ID, 3 = FC Address

# snmpwalk -v1 -Ob -m MIB:./fa_40.mib -c public 10.31.71.101 connUnitZoneMemberIdType

FCMGMT-MIB::connUnitZoneMemberIdType.1.1 = INTEGER: 2

FCMGMT-MIB::connUnitZoneMemberIdType.1.2 = INTEGER: 2

FCMGMT-MIB::connUnitZoneMemberIdType.1.3 = INTEGER: 2

FCMGMT-MIB::connUnitZoneMemberIdType.2.1 = INTEGER: 3

FCMGMT-MIB::connUnitZoneMemberIdType.2.2 = INTEGER: 3

FCMGMT-MIB::connUnitZoneMemberIdType.2.3 = INTEGER: 3

FCMGMT-MIB::connUnitZoneMemberIdType.3.1 = INTEGER: 1

FCMGMT-MIB::connUnitZoneMemberIdType.3.2 = INTEGER: 1

FCMGMT-MIB::connUnitZoneMemberIdType.3.3 = INTEGER: 1

FCMGMT-MIB::connUnitZoneMemberIdType.3.4 = INTEGER: 1

FCMGMT-MIB::connUnitZoneMemberIdType.3.5 = INTEGER: 1

From Switch CLI:

SB5602.101 #> zoning list

Active (enforced) ZoneSet Information

ZoneSet Zone ZoneMember

------- ---- ----------

ZS1

Z1

100,13

101,8

102,0

Z2

640d00

6508e1

660100

Z3

20:2c:00:a0:b8:11:49:74

21:00:00:e0:8b:1a:c9:28

50:05:07:67:0e:4f:f9:28

50:05:07:67:0e:4f:fd:e1

50:05:07:67:0e:4f:fe:97

Comments: Can only view the current active Zoneset. Cannot be modified using SNMP.

Can performance information be gathered using snmp?

Yes/No. By default, there are no OIDs defined in the supported MIBs that display the performance of the switch. For a workaround, see KB article:

How can SNMP be used to gather performance throughput on a port?

Responsiveness of snmpsets:

When doing snmpsets to a switch and actually changing the switch config, this can take approximettly 2 seconds. The reason is because in the background on the switch, the configuration needs to be edited, saved, and then activated. Because the config file needs to be saved to NVRAM before activating, all these steps add up. Although, if making Operational state changes, this is immediate since the config file does not get modified/activated.

Traps, Traps, Traps, Traps

Traps are the most complicated to understand. The SNMP documentation for the switch explains the different severity levels, but its not always clear because not every trap is listed. Rather only the group that they apply to or what severity level the developers set for each particular event.

Once you understand what events will trigger a trap for the various severity levels and what severity level is configured, then you understand about 90% of traps for the switch.

Wireshark is your friend. If customer‟s application is not deciphering the traps, it is most likely the application problem. Have them capture a Wireshark trace and provide the steps they did to produce the trap event along with switch dump_support file. A lot of times the snmp trap severity levels are not set correctly in order to cause a trap.

There are several different traps our switch firmware supports:

MIB-II Generic Traps – This includes coldStart, AuthenticationFailure, EnterpriseSpecific, etc.

Fibre Alliance Traps – This includes connUnitStatusChange, connUnitDeletedTrap, connUnitEventTrap, connUnitSensorStatusChange, connUnitPortStatusChange

QLogic Private Traps – This includes qlSB2PortLinkDown, qlSB2PortLinkUp, qlconnUnitAddedTrap,

Other – qlgcMPStatusChange

Below are some example traps captured in a network trace triggered by various events:

In this example, unplugging my Initiator connected to port 5 resulted in 5 traps.

connUnitPortStatusChange Trap (1.3.6.1.3.94.0.6) because connUnitPortStatus=unused(2), connUnitPortState=offline(3). This OID ‘1.3.6.1.3.94.1.10.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6‟ interprets to connUnitPortStatus (1.3.6.1.3.94.1.10.1.7) for Switch WWN=10.00.00.C0.DD.06.FA.A1 and .0.0.0.0.0.0.0.0.6‟ is the Port# (ones based) returns connUnitPortStatus=unused(2):

2008-02-04 12:35:25 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1084464

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.6 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.10.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 var03_value=2

var04_oid=1.3.6.1.3.94.1.10.1.6.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 var04_value=3

qlSB2PortLinkDown (1.3.6.1.4.1.1663.1.3.0.10) trap is defined in the QLogic MIB:

2008-02-04 12:35:25 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1084466

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.4.1.1663.1.3.0.10 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.4.1.1663.1.3.10.1.1.3.1.6 var03_value=1

var04_oid=1.3.6.1.4.1.1663.1.3.10.1.1.4.1.6 var04_value=2

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-04 12:35:25 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1084473

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=97

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="6;97;1;0;0;[Mon Feb 4 12:35:23 CST 2008][0][0x0][Topology oper change]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-04 12:35:25 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1084473

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=98

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="9;98;1;0;0;102;1;[Mon Feb 4 12:35:23 CST 2008][0][0x0][NameServer oper

change]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-04 12:35:26 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1084473

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=99

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.10.1.23.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="29;99;0;0;0;[Mon Feb 4 12:35:23 CST 2008][0][0x0][Port HW state change.

Port:5]"

In this example, re-plugging my Initiator to port 5 resulted in 5 traps.

connUnitPortStatusChange Trap (1.3.6.1.3.94.0.6) because connUnitPortStatus=unused(2), connUnitPortState=online(2). This OID ‘1.3.6.1.3.94.1.10.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6‟ interprets to connUnitPortStatus (1.3.6.1.3.94.1.10.1.7) for Switch WWN=10.00.00.C0.DD.06.FA.A1 and .0.0.0.0.0.0.0.0.6‟ is the Port# (ones based) returns connUnitPortStatus=unused(2):

2008-02-04 13:08:16 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1281571

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.6 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.10.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 var03_value=2

var04_oid=1.3.6.1.3.94.1.10.1.6.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 var04_value=2

qlSB2PortLinkUp (1.3.6.1.4.1.1663.1.3.0.11) trap is defined in the QLogic MIB:

2008-02-04 13:08:16 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1281574

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.4.1.1663.1.3.0.11 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.4.1.1663.1.3.10.1.1.3.1.6 var03_value=1

var04_oid=1.3.6.1.4.1.1663.1.3.10.1.1.4.1.6 var04_value=1

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-04 13:08:16 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1281579

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var03_value=102

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="6;102;1;0;0;[Mon Feb 4 13:08:13 CST 2008][0][0x0][Topology oper change]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-04 13:08:16 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1281579

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var03_value=103

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="9;103;1;0;0;102;1;[Mon Feb 4 13:08:13 CST 2008][0][0x0][NameServer oper

change]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-04 13:08:17 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1281580

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var03_value=104

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.10.1.23.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="29;104;0;0;0;[Mon Feb 4 13:08:14 CST 2008][0][0x0][Port HW state change.

Port:5]"

In first example trap below, the connUnitSensorStatusChange Trap returned

‘1.3.6.1.3.94.1.8.1.4.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1‘ translates to the SB5602 as connUnitSensorStatus for switch WWN=10.00.00.C0.DD.06.FA.A1 is .0.0.0.0.0.0.0.0.1 for PS1 Status returns connUnitSensorStatus=Unknown(1).

Example (Pulled PS1/FAN1 assembly caused 3 traps):

connUnitSensorStatusChange Trap (1.3.6.1.3.94.0.5) for Power Supply 1 because connUnitSensorStatus=Unknown(1)

2008-02-04 11:47:28 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=796772

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.5 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.8.1.4.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=1

connUnitStatusChange Trap (1.3.6.1.3.94.0.5) because connUnitStatus=warning(4), connUnitState=online(2)

2008-02-04 11:47:28 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=796789

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.1 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.6.1.6.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 var03_value=4

var04_oid=1.3.6.1.3.94.1.6.1.5.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 var04_value=2

connUnitSensorStatusChange Trap (1.3.6.1.3.94.0.5) for FAN1 because connUnitSensorStatus=Unknown(1)

2008-02-04 11:47:28 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=796791

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.5 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.8.1.4.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 var03_value=1

[root@RH4U4-x86 mibs]# snmpwalk -v1 -O b -c public -m MIB:./fa_40.mib 10.31.71.101

connUnitSensorTable

Cannot find module (MIB): At line 0 in (none) FCMGMT-MIB::connUnitSensorUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = Hex-STRING:

10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 FCMGMT-MIB::connUnitSensorUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 = Hex-STRING:

10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 FCMGMT-MIB::connUnitSensorUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 = Hex-STRING:

10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 FCMGMT-MIB::connUnitSensorUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 = Hex-STRING:

10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 FCMGMT-MIB::connUnitSensorUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 = Hex-STRING:

10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 FCMGMT-MIB::connUnitSensorUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 = Hex-STRING:

10 00 00 C0 DD 06 FA A1 00 00 00 00 00 00 00 00 FCMGMT-MIB::connUnitSensorIndex.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = INTEGER: 1 FCMGMT-MIB::connUnitSensorIndex.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 = INTEGER: 2 FCMGMT-MIB::connUnitSensorIndex.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 = INTEGER: 3 FCMGMT-MIB::connUnitSensorIndex.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 = INTEGER: 4 FCMGMT-MIB::connUnitSensorIndex.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 = INTEGER: 5 FCMGMT-MIB::connUnitSensorIndex.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 = INTEGER: 6 FCMGMT-MIB::connUnitSensorName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = STRING:

"Power supply 1 Status" FCMGMT-MIB::connUnitSensorName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 = STRING:

"Power supply 2 Status" FCMGMT-MIB::connUnitSensorName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 = STRING: "Fan

1 Status" FCMGMT-MIB::connUnitSensorName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 = STRING: "Fan

2 Status" FCMGMT-MIB::connUnitSensorName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 = STRING:

"Temperature Status" FCMGMT-MIB::connUnitSensorName.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 = STRING:

"Temperature Sensor 1 Value" FCMGMT-MIB::connUnitSensorStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = INTEGER:

unknown(1) FCMGMT-MIB::connUnitSensorStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 = INTEGER:

ok(3) FCMGMT-MIB::connUnitSensorStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 = INTEGER:

unknown(1) FCMGMT-MIB::connUnitSensorStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 = INTEGER:

ok(3) FCMGMT-MIB::connUnitSensorStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 = INTEGER:

ok(3) FCMGMT-MIB::connUnitSensorStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 = INTEGER:

ok(3) FCMGMT-MIB::connUnitSensorMessage.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = STRING:

"NotInstalled" FCMGMT-MIB::connUnitSensorMessage.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 = STRING:

"Good" FCMGMT-MIB::connUnitSensorMessage.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 = STRING:

"NotInstalled" FCMGMT-MIB::connUnitSensorMessage.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 = STRING:

"Good" FCMGMT-MIB::connUnitSensorMessage.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 = STRING:

"Normal" FCMGMT-MIB::connUnitSensorMessage.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 = STRING:

"24 degrees C" FCMGMT-MIB::connUnitSensorType.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 = INTEGER:

power-supply(5)

FCMGMT-MIB::connUnitSensorType.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 = INTEGER:

power-supply(5) FCMGMT-MIB::connUnitSensorType.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 = INTEGER:

fan(4) FCMGMT-MIB::connUnitSensorType.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 = INTEGER:

fan(4) FCMGMT-MIB::connUnitSensorType.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 = INTEGER:

board(8) FCMGMT-MIB::connUnitSensorType.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 = INTEGER:

board(8) FCMGMT-MIB::connUnitSensorCharacteristic.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 =

INTEGER: power(9) FCMGMT-MIB::connUnitSensorCharacteristic.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.2 =

INTEGER: power(9) FCMGMT-MIB::connUnitSensorCharacteristic.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.3 =

INTEGER: airflow(7) FCMGMT-MIB::connUnitSensorCharacteristic.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.4 =

INTEGER: airflow(7) FCMGMT-MIB::connUnitSensorCharacteristic.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.5 =

INTEGER: temperature(3) FCMGMT-MIB::connUnitSensorCharacteristic.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.6 =

INTEGER: temperature(3) [root@RH4U4-x86 mibs]#

In this example of resetting (cmd=reset) the switch resulted in 5 traps. Note that one of them is a Generic Trap for ColdStart. The number of traps sent from the switch can vary depending on the number of FC port connections there are. I did not have any FC devices attached to simplify the results.

connUnitStatusChange Trap (1.3.6.1.3.94.0.1) because connUnitStatus=OK(3), connUnitState=OK(3):

2008-02-05 11:52:04 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=71517

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.1 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.6.1.6.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 var03_value=3

var04_oid=1.3.6.1.3.94.1.6.1.5.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 var04_value=3

Coldstart Trap (1.3.6.1.6.3.1.1.4.1.0):

2008-02-05 11:54:00 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1332

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.6.3.1.1.5.1 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.6.3.1.1.4.3.0 var03_value=1.3.6.1.4.1.1663.1.1.1.1.24

var03_mib_name=snmpTrapEnterprise

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-05 11:54:05 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1733

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=0

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="16;0;0;0;0;[Tue Feb 05 11:54:03.643 CST 2008][A][1005.006D][unable to

synchronize with NTP server,IP addr 10.20.33.35, retrying every 15 seconds]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-05 11:55:48 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=12037

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=2

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="5;2;1;0;0;[Tue Feb 5 11:55:46 CST 2008][0][0x0][Fabric oper change]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-05 11:55:48 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=12042

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=3

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="6;3;1;0;0;[Tue Feb 5 11:55:46 CST 2008][0][0x0][Topology oper change]"

In this example of doing an NDCLA (cmd=hotreset) the switch resulted in 2 traps. Note that one of them is a Generic Trap for ColdStart. The number of traps sent from the switch can vary depending on the number of FC port connections there are. I did not have any FC devices attached to simplify the results.

Coldstart Trap (1.3.6.1.6.3.1.1.4.1.0):

2008-02-05 15:01:49 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1313

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.6.3.1.1.5.1 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.6.3.1.1.4.3.0 var03_value=1.3.6.1.4.1.1663.1.1.1.1.24

var03_mib_name=snmpTrapEnterprise

connUnitEvent Trap (1.3.6.1.3.94.0.4):

2008-02-05 15:01:54 Local7.Debug 10.31.71.101 community=public

agent_ip=10.31.71.200 version=Ver2 var01_oid=1.3.6.1.2.1.1.3.0 var01_value=1715

var01_mib_name=sysUpTimeInstance var02_oid=1.3.6.1.6.3.1.1.4.1.0

var02_value=1.3.6.1.3.94.0.4 var02_mib_name=snmpTrapOID

var03_oid=1.3.6.1.3.94.1.11.1.3.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var03_value=0

var04_oid=1.3.6.1.3.94.1.11.1.7.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1 var04_value=3

var05_oid=1.3.6.1.3.94.1.11.1.8.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var05_value=1.3.6.1.3.94.1.6.1.1.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

var06_oid=1.3.6.1.3.94.1.11.1.9.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0.1

var06_value="16;0;0;0;0;[Tue Feb 05 15:01:52.452 CST 2008][A][1005.006D][unable to

synchronize with NTP server,IP addr 10.20.33.35, retrying every 15 seconds]"

This example shows several connUnitSensorStatusChange Traps (1.3.6.1.3.94.0.5) for Temperature. connUnitSensorStatus value returned changed from Warning(4) to Normal(3)

from the extracted traps below. This line

‘experimental.94.1.8.1.4.16.0.0.192.221.13.30.189.0.0.0.0.0.0.0.0.5)’ that it is

connUnitSensorStatus for Switch WWN=10.00.00.C0.DD.0D.1E.BD for connUnitSensor Indexed of .0.0.0.0.0.0.0.0.5. On the SANbox5602, this ‘.0.0.0.0.0.0.0.0.5’ points to Temperature

Status. See my snmpwalk of the connUnitSensorTable above.

connUnitSensorStatusChange Trap #1 (1.3.6.1.3.94.0.5): Value: OID: SNMPv2-SMI::experimental.94.0.5 Item name: 1.3.6.1.3.94.1.8.1.4.16.0.0.192.221.13.30.189.0.0.0.0.0.0.0.0.5

(SNMPv2-SMI::experimental.94.1.8.1.4.16.0.0.192.221.13.30.189.0.0.0.0.0.0.0.0.5) valueType: value (0) value: simple (4294967295) simple: integer-value (0) Value: INTEGER: 4 ---------------------

Temperature=Warning(4) connUnitSensorStatusChange Trap #2 (1.3.6.1.3.94.0.5) Value: OID: SNMPv2-SMI::experimental.94.0.5 Item name: 1.3.6.1.3.94.1.8.1.4.16.0.0.192.221.13.30.189.0.0.0.0.0.0.0.0.5

(SNMPv2-SMI::experimental.94.1.8.1.4.16.0.0.192.221.13.30.189.0.0.0.0.0.0.0.0.5) valueType: value (0) value: simple (4294967295) simple: integer-value (0) Value: INTEGER: 3 ---------------------

Temperature=Normal(3)

connUnitEvent Trap (1.3.6.1.3.94.0.4):

Value: STRING: "29;9;0;0;0;[Mon Dec 24 11:27:49 IST 2007][0][0x0][Port HW state change. Port:9]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

Value: STRING: "29;11;0;0;0;[Mon Dec 24 11:28:00 IST 2007][0][0x0][Port HW state change. Port:8]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

Value: STRING: "29;13;0;0;0;[Mon Dec 24 11:28:13 IST 2007][0][0x0][Port HW state change. Port:8]"

connUnitEvent Trap (1.3.6.1.3.94.0.4):

Value: STRING: "29;15;0;0;0;[Mon Dec 24 11:28:20 IST 2007][0][0x0][Port HW state change. Port:9]"

How do you configure traps on a switch using Linux SNMP tools? Do you

have some examples?

There is a way to add and delete the trap clients using the Fibre Alliance (FA) MIB. For

more information, see our SNMP manual and look for trapRegRowState

(1.3.6.1.3.94.2.3.1.4) in the section (5.13) on Trap Table. The trapRegRowState OID

allows you to Read and Write or configure the SNMP trap clients.

Below are some samples and the results using the SNMP tools included with Linux.

View current SNMP trap clients (default settings):

[root@RH30U4 snmp]# snmptable -v1 -c public -m MIB:./fa_40.mib 10.20.71.100 trapRegTable

SNMP table: FCMGMT-MIB::trapRegTable

trapRegIpAddress trapRegPort trapRegFilter trapRegRowState

10.0.0.254 162 warning rowInactive

[root@RH30U4 snmp]# snmpwalk -v1 -c public -m MIB:./fa_40.mib 10.20.71.100

trapRegTable

FCMGMT-MIB::trapRegIpAddress.10.0.0.254.162 = IpAddress: 10.0.0.254

FCMGMT-MIB::trapRegPort.10.0.0.254.162 = INTEGER: 162

FCMGMT-MIB::trapRegFilter.10.0.0.254.162 = INTEGER: warning(6)

FCMGMT-MIB::trapRegRowState.10.0.0.254.162 = INTEGER: rowInactive(2)

Add a second trap client:

[root@RH30U4 snmp]# snmpset -v1 -c private -m MIB:./fa_40.mib 10.20.71.100 trapRegRowState.10.20.32.221.162 i 2

FCMGMT-MIB::trapRegRowState.10.20.32.221.162 = INTEGER: rowInactive(2)

[root@RH30U4 snmp]# snmptable -v1 -c public -m MIB:./fa_40.mib 10.20.71.100 trapRegTable

SNMP table: FCMGMT-MIB::trapRegTable

trapRegIpAddress trapRegPort trapRegFilter trapRegRowState

10.0.0.254 162 warning rowInactive

10.20.32.221 162 warning rowInactive

The ‘i 2’ used indicates that this is an integer value of 2 which is for ‘rowInactive(2), -

Row exists, but trap disabled’. In otherwords, the trap is not configured.

Presently, both traps are configured, but not enabled as ‘trapRegRowState=rowInactive’

because the example used ‘i 2’.

If you want to add a trap that is enabled, do:

[root@RH30U4 snmp]# snmpset -v1 -c private -m MIB:./fa_40.mib 10.20.71.100 trapRegRowState.10.20.32.223.162 i 3

FCMGMT-MIB::trapRegRowState.10.20.32.223.162 = INTEGER: rowActive(3)

[root@RH30U4 snmp]# snmptable -v1 -c public -m MIB:./fa_40.mib 10.20.71.100 trapRegTable

SNMP table: FCMGMT-MIB::trapRegTable

trapRegIpAddress trapRegPort trapRegFilter trapRegRowState

10.0.0.254 162 warning rowInactive

10.20.32.221 162 warning rowInactive

10.20.32.223 162 warning rowActive

The ‘i 3’ used indicates that this is an integer value of 3 which is for ‘rowActive(3) –

Row exists and is enabled for sending traps’. In otherwords the trap is enabled.

To delete a configured trap, do:

[root@RH30U4 snmp]# snmpset -v1 -c private -m MIB:./fa_40.mib 10.20.71.100 trapRegRowState.10.20.32.221.162 i 1

FCMGMT-MIB::trapRegRowState.10.20.32.221.162 = INTEGER: rowDestroy(1)

[root@RH30U4 snmp]# snmptable -v1 -c public -m MIB:./fa_40.mib 10.20.71.100 trapRegTable

SNMP table: FCMGMT-MIB::trapRegTable

trapRegIpAddress trapRegPort trapRegFilter trapRegRowState

10.0.0.254 162 warning rowInactive

10.20.32.223 162 warning rowActive

If you want to change the severity level or trapRegFilter, do:

[root@RH30U4 snmp]# snmpget -v1 -c private -m MIB:./fa_40.mib 10.20.71.100 trapRegFilter.10.20.32.223.162

FCMGMT-MIB::trapRegFilter.10.20.32.223.162 = INTEGER: warning(6)

[root@RH30U4 snmp]# snmpset -v1 -c private -m MIB:./fa_40.mib 10.20.71.100 trapRegFilter.10.20.32.223.162 i 4

FCMGMT-MIB::trapRegFilter.10.20.32.223.162 = INTEGER: critical(4)

[root@RH30U4 snmp]# snmpget -v1 -c private -m MIB:./fa_40.mib 10.20.71.100 trapRegFilter.10.20.32.223.162

FCMGMT-MIB::trapRegFilter.10.20.32.223.162 = INTEGER: critical(4)

[root@RH30U4 snmp]# snmptable -v1 -c public -m MIB:./fa_40.mib 10.20.71.100 trapRegTable

SNMP table: FCMGMT-MIB::trapRegTable

trapRegIpAddress trapRegPort trapRegFilter trapRegRowState

10.0.0.254 162 warning rowInactive

10.20.32.223 162 critical rowActive

In the above example of changing the severity level, the ‘i 4’ indicates that this is an

integer value of 4. Based on the various severity levels defined in the FA MIB, a value of

4 = critical.

How can SNMP be used to gather performance throughput on a

port?

Question

How can SNMP be used to gather performance throughput on a port?

Answer

By default, the supported SNMP MIBs for the QLogic FC switches do not include

throughput data in MB/sec.

As a workaround, use a SNMPget command to a particular OID defined in the supported

MIBs done at regular intervals (1/sec), calculate the difference, then average it out to

determine the MB/sec throughput.

Example:

First, determine which port counter or other port statistic to monitor. In this example,

using connUnitPortStatCountTxElements as defined in the Fibre Alliance 4.0 MIB

(FA_40.mib). See the SNMP manual included with the MIB download.

Do an snmpwalk of connUnitPortStatTable using snmp command (Linux snmp tools):

# snmpwalk -v1 -O b -c public -m MIB:./fa_40.mib 10.31.71.100 connUnitPortStatTable

In this output, it will return the connUnitPortStatCountTxElements values for each port.

The output syntax is 'OID.<switch_wwn>.0.0.0.0.0.0.0.0.<port#> = value'. Note: the

<switch_wwn> is in hex format, as is the value returned. The <port#> is 1-based. So

switch port 0, starts at 1 on this 20 port switch.

Extracted:

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.1 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.2 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.3 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.4 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.5 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.6 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.7 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.8 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.9 =

Hex-STRING: 00 00 00 00 01 A2 43 80

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.10 =

Hex-STRING: 00 00 00 00 01 A2 4D C4

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.11 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.12 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.13 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.14 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.15 =

Hex-STRING: 00 00 00 00 00 46 7D 28

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.16 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.17 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.18 =

Hex-STRING: 00 00 00 00 00 01 92 20

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.19 =

Hex-STRING: 00 00 00 00 00 00 00 00

FCMGMT-

MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.20 =

Hex-STRING: 00 00 00 00 00 01 91 54

Using value returned for port 8 which is 01A24380 (hex), converting it to decimal would

return 27411328 (This is the number of bytes transmitted on a port):

FCMGMT-MIB::connUnitPortStatCountTxElements.16.0.0.192.221.6.250.180.0.0.0.0.0.0.0.0.9 = Hex-STRING: 00 00 00 00 01 A2

43 80

To verify it matches the port statistics counter, using telnet (clish), do the 'show port x'

(x=port#) command:

SANbox#> show port 8

Port Number: 8

------------ AdminState Online OperationalState Online

AsicNumber 0 PerfTuningMode Normal

AsicPort 8 PortID 020800

ConfigType GL PortWWN 20:08:00:c0:dd:06:fa:b4

DiagStatus Passed RunningType F

EpConnState None MediaPartNumber JSH-42S4AA3

EpIsoReason NotApplicable MediaRevision

IOStreamGuard Enabled MediaType 400-M5-SN-I

LinkSpeed 4Gb/s MediaVendor JDS UNIPHASE

LinkState Active MediaVendorID 0000019c

LoginStatus LoggedIn SymbolicName Port8

MaxCredit 16 SyncStatus SyncAcquired

MediaSpeeds 1Gb/s, 2Gb/s, 4Gb/s XmitterEnabled True

ALInit 5 LIP_F8_AL_PS 0 ALInitError 0 LIP_F8_F7 0 BadFrames 0 LinkFailures 3

Class2FramesIn 0 Login 4

Class2FramesOut 0 Logout 4

Class2WordsIn 0 LoopTimeouts 0

Class2WordsOut 0 LossOfSync 4

Class3FramesIn 1740 PrimSeqErrors 0

Class3FramesOut 15550 RxLinkResets 4

Class3Toss 0 RxOfflineSeq 0

Class3WordsIn 26339 TotalErrors 19

Class3WordsOut 6852832 TotalLinkResets 4

DecodeErrors 16 TotalLIPsRecvd 2

EpConnects 0 TotalLIPsXmitd 5

FBusy 0 TotalOfflineSeq 5

FlowErrors 0 TotalRxFrames 1740

FReject 0 TotalRxWords 26339

InvalidCRC 0 TotalTxFrames 15550

InvalidDestAddr 0 TotalTxWords 6852832 LIP_AL_PD_AL_PS 0 TxLinkResets 0

LIP_F7_AL_PS 0 TxOfflineSeq 5

LIP_F7_F7 2

SANbox #>

connUnitPortStatCountTxElement matches up with 'TotalTxWords x 4'.

connUnitPortStatCountTxElement returns the number of bytes transferred on a port.

TotalTxWords returns the total number of FC words transmitted on a port. One FC word

is 4 Bytes. So, to determine the total number of bytes transmitted on a port, take the

TotalTxWords value multiplied by four and that should match the value returned for

connUnitPortStatCountTxElements converted to decimal.

Now, to determine throughput, at regular intervals (1/sec) do the same snmpget command

to get the before and after values, calculate the difference, and that will give you the

number of Bytes transferred in one second.

SNMPv3

SNMPv3 provides increased security. The SNMPv3 data is encrypted on the wire. SNMPv1 and v2c use cleartext on the wire.

In order to do SNMPv3 requests to the switch, you must first setup the SNMPv3 configuration on the switch and this includes; Username, Group, Authentication enabled/disabled, Type of Authentication, Authentication password, & Privacy.

Example:

SANbox(admin) #> snmpv3user add

A list of SNMPV3 user attributes with formatting and default values as

applicable will follow.

Enter a new value OR simply press the ENTER key where-ever allowed to

accept the default value.

If you wish to terminate this process before reaching the end of the list,

press "q" or "Q" and the ENTER OR "Ctrl-C" key to do so.

Username (8-32 chars) : snmpuser1

Group (0=ReadOnly, 1=ReadWrite) [ReadWrite ] : 1

Authentication (True/False) [True ] : t

AuthType (1=MD5, 2=SHA) [MD5 ] : 1

AuthPhrase (8-32 chars) : ******** -

- password1

Confirm AuthPhrase : ******** -

- password1

Privacy (True/False) [False ] : t

PrivType (1=DES) [None ] : 1

PrivPhrase (8-32 chars) : ******** -

- password2

Confirm PrivPhrase : ******** -

- password2

Do you want to save and activate this setup ? (y/n): [n] y

SNMPV3 user saved and activated.

SANbox(admin) #> snmpv3user list

Username Group AuthType PrivType

-------- ----- -------- --------

snmpuser1 ReadWrite MD5 DES

Here’s how you can query with net-snmp provided SNMPv3 commands:

Syntax: snmp_command -v3 -c private -m ALL –M your_mib_path switch_ip -u snmpv3_username -l security_level -a authentication_algorithm -A authentication_passcode -x

privacy_algorithm -X privacy_passcode OID

-u is the SNMPv3 username as created on the switch

The –c (community) option corresponds to the ReadOnly or ReadWrite group that you added the SNMPv3 user to on the switch.

The –l (that‟s lower case L) option could be noauthnopriv (if during user creation you specified False for “Authentication”), authnopriv (if during user creation you specified True for

“Authentication” and False for “Privacy”), authpriv (if during user creation you specified True for both “Authentication” and “Privacy”)

The –a and –A options are the authentication algorithm and passcode respectively you provided during user creation

The –x and –X options are the privacy algorithm and the passcode respectively you provided during user creation.

Examples:

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitID

FCMGMT-MIB::connUnitId.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0 DD 02

CC 7A 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitId.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0 DD 06

FA A1 00 00 00 00 00 00 00 00

FCMGMT-MIB::connUnitId.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = Hex-STRING: 10 00 00 C0 DD 07 2D

3C 00 00 00 00 00 00 00 00

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitState

FCMGMT-MIB::connUnitState.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: online(2)

FCMGMT-MIB::connUnitState.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: online(2)

FCMGMT-MIB::connUnitState.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: online(2)

# snmpget -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitState.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitState.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: online(2)

# snmpget -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitState.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitState.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: online(2)

# snmpget -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitState.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitState.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: online(2)

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitStatus

FCMGMT-MIB::connUnitStatus.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: ok(3)

FCMGMT-MIB::connUnitStatus.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: ok(3)

FCMGMT-MIB::connUnitStatus.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: ok(3)

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitProduct

FCMGMT-MIB::connUnitProduct.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = STRING: "SANbox 5200 FC

Switch"

FCMGMT-MIB::connUnitProduct.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = STRING: "SANbox 5602 FC

Switch"

FCMGMT-MIB::connUnitProduct.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = STRING: "SANbox 5600 FC

Switch"

# snmptable -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitSensorTable

SNMP table: FCMGMT-MIB::connUnitSensorTable

connUnitSensorUnitId connUnitSensorIndex connUnitSensorName connUnitSensorStatus

connUnitSensorMessage connUnitSensorType connUnitSensorChar

"10 00 00 C0 DD 02 CC 7A" 1 "Power supply 1 Status" ok

"Good" power-supply power

"10 00 00 C0 DD 02 CC 7A" 2 "Temperature Status" ok

"Normal" board temperature

"10 00 00 C0 DD 02 CC 7A" 3 "Temp Sensor 1 Value" ok

"24 degrees C" board temperature

"10 00 00 C0 DD 06 FA A1" 1 "Power supply 1 Status" ok

"Good" power-supply power

"10 00 00 C0 DD 06 FA A1" 2 "Power supply 2 Status" ok

"Good" power-supply power

"10 00 00 C0 DD 06 FA A1" 3 "Fan 1 Status" ok

"Good" fan airflow

"10 00 00 C0 DD 06 FA A1" 4 "Fan 2 Status" ok

"Good" fan airflow

"10 00 00 C0 DD 06 FA A1" 5 "Temperature Status" ok

"Normal" board temperature

"10 00 00 C0 DD 06 FA A1" 6 "Temp Sensor 1 Value" ok

"24 degrees C" board temperature

"10 00 00 C0 DD 07 2D 3C" 1 "Power supply 1 Status" ok

"Good" power-supply power

"10 00 00 C0 DD 07 2D 3C" 2 "Temperature Status" ok

"Normal" board temperature

"10 00 00 C0 DD 07 2D 3C" 3 "Temp Sensor 1 Value" ok

"24 degrees C" board temperature

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitControl

FCMGMT-MIB::connUnitControl.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

# snmpget -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

# snmpset -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 i 5

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER:

offlineConnUnit(5)

# snmpget -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER:

offlineConnUnit(5)

# snmpset -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101

connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 i 6

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitControl

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitControl

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l authPriv -a md5 -A

password1 -x des -X password2 10.31.71.101 connUnitControl

FCMGMT-MIB::connUnitControl.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER: onlineConnUnit(6)

Examples with switch SNMPv3 Authentication=False and Privacy=False:

SANbox #> admin start

SANbox (admin) #> snmpv3user edit

A list of SNMPV3 user attributes with formatting and current attribute values for the specified SNMPV3 user will follow.

Enter a new value OR simply press the ENTER key where-ever allowed to accept the current value.

If you wish to terminate this process before reaching the end of the list,

press "q" or "Q" and the ENTER OR "Ctrl-C" key to do so.

Username (8-32 chars) : snmpuser1

Group (0=ReadOnly, 1=ReadWrite) [ReadWrite ] : 0

Authentication (True/False) [True ] : f

Do you want to save and activate this setup ? (y/n): [n] y

SNMPV3 user saved and activated.

SB5602.101 (admin) #> snmpv3user list

Username Group AuthType PrivType

-------- ----- -------- --------

snmpuser1 ReadOnly None None

SANbox (admin) #> admin end

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l noauthnoPriv

10.31.71.101 connUnitControl

FCMGMT-MIB::connUnitControl.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

FCMGMT-MIB::connUnitControl.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = INTEGER:

onlineConnUnit(6)

# snmpwalk -v3 -Ob -c private -m ALL -m MIB:./fa_40.mib -u snmpuser1 -l noauthnoPriv

10.31.71.101 connUnitProduct

FCMGMT-MIB::connUnitProduct.16.0.0.192.221.2.204.122.0.0.0.0.0.0.0.0 = STRING: "SANbox

5200 FC Switch"

FCMGMT-MIB::connUnitProduct.16.0.0.192.221.6.250.161.0.0.0.0.0.0.0.0 = STRING: "SANbox

5602 FC Switch"

FCMGMT-MIB::connUnitProduct.16.0.0.192.221.7.45.60.0.0.0.0.0.0.0.0 = STRING: "SANbox 5600

FC Switch"

Conclusion:

For the most part, SNMP is fairly simple. Although the most complicated is Traps and SNMPv3 since there is limited documentation and the implementation can vary. If you know your hardware and all the various components with in it, understanding most of the SNMP responses should be straight forward.