Introduction To Network Administration: Additional Topics of Interest

1722ch6atol.
qxd 7/13/06 10:49 AM Page 1
CHAPTER 6
Introduction to Network Administration
Additional Topics of Interest

Network Services ……………………………………………………………………………………………2
Choice of NOS ………………………………………………………………………………………………3

Macintosh …………………………………………………………………………………………………4
Microsoft …………………………………………………………………………………………………4
Novell ………………………………………………………………………………………………………7
UNIX / Linux ………………………………………………………………………………………………7
Network Management Essentials ………………………………………………………………………10

Common Management Information Protocol (CMIP) ……………………………………………12
Simple Network Management Protocol (SNMP) …………………………………………………13
SNMP Architecture and Operation ………………………………………………………………13
Minimizing SNMP Overhead ………………………………………………………………………16
Management Information Base …………………………………………………………………18
SNMP Messages ……………………………………………………………………………………19
SNMP Version 2 ……………………………………………………………………………………20
SNMP Version 3 ……………………………………………………………………………………21
Comparing SNMP Versions ………………………………………………………………………22
Configuring SNMP …………………………………………………………………………………23
RMON ………………………………………………………………………………………………………25
Syslog ………………………………………………………………………………………………………27
© 2006 WAN Technologies CCNA 4 Companion Guide by Allan Reid, ISBN 1587131722
1722ch6atol.qxd 7/13/06 10:49 AM Page 2
2 WAN Technologies CCNA 4 Companion Guide
Network Services
Network operating systems (NOS) are designed to provide network processes to clients. In the
Microsoft world, these processes are called services, but in the UNIX/Linux world they are
called daemons. These processes provide the same functionality, but how they are loaded and
managed varies between NOSs. Table 6-1 lists some of the more common TCP/IP services.
Table 6-1 Common TCP/IP Services
Service TCP/IP Protocol
World Wide Web HTTP

File transfer FTP, TFTP
File sharing NFS
Internet mail SMTP, POP3, IMAP
Remote administration Telnet, SNMP
Directory services DNS, LDAP
Automatic network address configuration DHCP
Network administration SNMP
Depending on the NOS, some or all of these processes might be installed during a default
installation. Most current NOSs rely on the TCP/IP suite of protocols because of its widespread
acceptance and openness. Unfortunately, this same openness has made TCP/IP vulnerable to
attack. Denial of service (DoS) attacks, viruses, and worms have forced NOS designers to
reconsider the services that are installed and started automatically. Because of this, it might be
necessary to manually install and start some processes. From a security perspective, only serv-
ices required for proper network operation should be installed.
When a user submits a print job on a network, it is moved into a queue. Each queue is associat-
ed with a physical printer. Print queues process the print jobs in a first-in, first-out (FIFO) man-
ner. Because jobs may be delayed because large print jobs are at the head of the queue, print
services give the network administrator tools to manage the print queue. Administrators can
start or stop the queue and prioritize and delete print jobs.
File sharing is an extremely important aspect of a NOS. Many different file-sharing services are
available, but the most common are Windows File Sharing and Sun Microsystems’ Network
File System (NFS). File sharing lets a user add, delete, and modify files stored remotely as
though they were stored on the local device. In many instances, the user doesn’t even know the
files’ physical location.
Dynamic Host Configuration Protocol (DHCP) allows the automatic configuration of clients
with network address information. When a client first powers up, it requests this configuration
Chapter 6: Introduction to Network Administration 3
information from any DHCP server on the network. The DHCP server provides this informa-
tion through a series of exchanges. The network configuration information is leased to the
client for a specified period of time. When this lease period expires, the client may request a
renewal of the lease or return the resources to the pool for reallocation.
Domain Name System (DNS) translates a domain name into an IP address for use on the net-
work. All network communications on a TCP/IP-based network rely on the IP address to speci-
fy the location of the remote resource. Although machines work well with numbers, humans do
not. Humans work much better with names, so we commonly use domain names with such
things as web browsers and e-mail programs. When a domain name is specified, DNS translates
the name into an IP address before using it on the network.
Web services are probably the most common network service available on the Internet. Most
organizations, and many individuals, maintain their own websites to advertise their products
and capabilities or share information. Web servers use client/server technology, in which the
client (web browser) requests information from a web server. Common web browsers include
Microsoft’s Internet Explorer, Netscape Navigator, Firefox, and Opera. The most common web
servers in use are Microsoft’s Internet Information Services (IIS) and Apache. Apache was orig-
inally designed for use in the Linux world but is now available for most flavors of UNIX as
well as various Microsoft platforms. Quite often a company creates a website for information
retrieval and links it to FTP for file download.
File Transfer Protocol (FTP) is a session-oriented protocol that allows files to be moved
between the local and remote hosts. FTP requires that the user authenticate before files can be
transferred. Not only does this service allow remote employees to download files, but many
organizations also provide anonymous FTP sites for their customers to download the latest driv-
ers and patches. With anonymous FTP, users can enter the login name “anonymous” to connect.
Choice of NOS
The choice of NOS is not easy; it depends on many factors. Some NOSs, such as Apple’s OS X,
are designed to run on a specific hardware platform. Others, like the Microsoft Windows series
and the UNIX/Linux platforms, are designed to function as both an OS and a NOS. Still others,
such as Novell NetWare, are designed to function solely as a NOS.
Some NOSs, such as those produced by Microsoft and Novell, are commercial in nature, so a
license must be purchased to legally deploy the software. These licenses can be extremely
expensive, but the ready supply of highly trained support specialists and the extensive technical
support from the manufacturer help reduce these products’ total cost of ownership. One limita-
tion of a commercial NOS is that the development cycle is extremely structured, so it might be
necessary to wait quit a while for new features or enhancements to become available.
Open-source products such as Linux have become a viable alternative to the commercial NOS
offerings. These products are often available free of charge but offer no formal technical sup-
port. Support is available via user groups, and some organizations bundle these products with
technical support for a fee. Before implementing an open-source solution, an organization must
complete a detailed cost analysis to determine whether it can support the product both during
and after the installation. Because these products do not currently hold a significant market
share, individuals with the appropriate level of technical knowledge and skills are in short sup-
ply and can often cost more than their counterparts in the commercial NOS environment.
Macintosh
Apple’s Macintosh computer system, which is better known as simply the Mac, has made great
inroads in the educational and graphic arts sectors. These computer systems have been designed
for easy networking and offer support for many different types of networks, including
AppleTalk and Ethernet. Macs can be easily integrated into networks running Microsoft,
Novell, or UNIX/Linux servers, and they fully support TCP/IP.
The current Mac OS is called Mac OS X. It was released in public beta in September 2000 and
has full backward compatibility with earlier versions of the OS. The open-source core of Mac
OS X is called Darwin. It is based largely on the FreeBSD kernel, with enhancements from a
number of additional sources. The move to an open-source UNIX-like kernel gives OS X great
power and stability. This core enables support for protected memory, preemptive multitasking,
advanced memory management, and symmetric multiprocessing, making OS X an extremely
powerful OS.
Mac OS X is designed to provide a graphical user interface (GUI) and environment suitable for
the home user while providing numerous powerful and customizable tools required by the IT
professional. This OS offers a fully integrated address book, e-mail, chat, browsing, and many
other tools, including a ZeroConf networking configuration initiative. Apple continues to
enhance this OS with every new release. Apple has now ported the OS to the Intel platform,
making it available to those not running Apple hardware.
Although originally designed to work only on the Mac platform, OS X has now been ported to
run on CPUs produced by Intel. This may increase its acceptance in the business and technical
communities.
Microsoft
The Microsoft product line is a continually evolving series of operating systems that are
designed to fit into specific markets. To keep pace with new applications and hardware plat-
forms, Microsoft encourages customers to continually update their operating systems to the
newest available ones. Effective July 2006, support is no longer available for the Windows NT
4 line or Windows 95, 98, 98SE, and Me. The Windows 95/98/98SE/Me product line was
designed to support older processors and systems. It does not optimize the benefits of the newer
hardware, as do the more recent 32-bit operating systems.
Windows NT 4.0 was designed to provide a stable platform for mission-critical applications.
This product was released in both Workstation and Server varieties. One major advantage of
Windows NT 4.0 was that it allowed older applications to be executed in virtual machines
(VMs), which isolates the resources allocated to one program from those allocated to another.
With the implementation of VMs, the crash of one application does not affect other applications
running in different VMs. Before Windows NT 4.0, any application crash usually meant that the
machine had to be restarted.
Windows NT introduced the network domain structure. Each domain is controlled by a single
machine called the primary domain controller (PDC), which houses a copy of the Security
Accounts Management (SAM) database. Backup domain controllers (BDCs) contain a read-
only copy of the SAM in case the PDC goes offline for any reason. When a user logs into the
domain, the supplied credentials are authenticated against the SAM, and then the user is given
access to the appropriate system resources. The network administrator can use the User
Manager for Domains on the PDC to add/delete and manage users.
Microsoft has indicated that Windows NT no longer meets the security issues of the customer
base. With the increasing adoption of the Windows 2000 family, Microsoft has officially retired
the product and is encouraging customers to upgrade to Windows 2000 or Windows 2003.
The next system released by Microsoft was Windows 2000. This family of operating systems
builds on the NT kernel and provides more-advanced features such as an encrypted file system
to protect stored data and plug-and-play capabilities that let you easily upgrade computer hard-
ware.
Windows 2000 allows users and other network resources to be put into containers called orga-
nizational units (OUs). Administrative control over each OU can be delegated to individuals or
groups, a feature that was not available with Windows NT. The Windows 2000 Professional
platform is designed to work as a client in the network. As such, it does not provide most net-
work services offered by the server version. Windows 2000 Professional does offer some limit-
ed server capabilities, providing file and print server capabilities, along with web and FTP, for a
maximum of ten simultaneous connections.
Windows 2000 Server can provide file, print, and web services, along with DHCP, DNS, and
other commonly encountered network services. Windows 2000 Server introduced Active
Directory (AD), which functions in a manner similar to NetWare’s NDS. AD provides a cen-
tralized point to manage users, groups, services, and resources. Windows 2000 Server provides
capabilities for integration with NetWare, UNIX, and AppleTalk networks and can additionally
be configured to provide dialup services for mobile users. Windows 2000 Advanced Server pro-
vides additional services required to support Enterprise networks. Windows 2000 Datacenter
Server is a specialized high-end version of Windows 2000 Server, supporting up to 32-way
symmetric multiprocessing (SMP) and up to 64 GB of physical memory. Like Windows 2000
Advanced Server, it provides both clustering and load-balancing services as standard features.
Windows Server 2003 is designed to be an evolutionary step beyond Windows 2000. This oper-
ating system offers many enhancements and an evolving line of editions. Windows Server 2003
has been released in four versions:
■ Standard Edition is designed for most normal departmental workloads. It provides intelli-
gent file and printer sharing, more-secure Internet connectivity, and centralized desktop
policy management. It provides high levels of dependability, scalability, and security.
■ Enterprise Edition differs from Windows Server 2003 Standard Edition R2 primarily in
its support for high-performance servers and its capability to cluster servers for greater
load handling. This is the solution for deploying highly available and scalable applications
such as networking, messaging, inventory, and customer service systems; databases;
e-commerce Web sites; and file and print servers.
■ Datacenter Edition has been designed for the highest levels of scalability and reliability. It
supports mission-critical solutions for databases; enterprise resource planning software;
high-volume, real-time transaction processing; and server consolidation. This version is
available in both 32-bit and 64-bit versions. It is designed to support mission-critical work-
loads in enterprise data centers.
■ Web Edition is designed for dedicated Web serving and hosting. It delivers a single-pur-
pose solution for Internet service providers, application developers, and others who use or
deploy specific Web functionality. Windows Server 2003 Web Edition takes advantage of
improvements in IIS 6.0, Microsoft ASP.NET, and the Microsoft .NET Framework to make
it easier to build and host Web applications, Web pages, and XML Web services. It is
designed as a single-purpose Web server.
Windows XP was released as a client operating system to replace Windows 2000 Professional.
This OS provides all the features found in Windows 2000 Professional, but it offers a much
cleaner user interface and enhanced support for many multimedia applications. Windows XP
has additionally simplified such tasks as network setup and introduced many wizards to simpli-
fy tasks. XP was released in four varieties to match client requirements:
■ Home Edition
■ Professional Edition
■ Media Center Edition
■ Tablet PC Edition
In February 2006, Microsoft announced the product lineup of its new Vista operating system.
The Windows Vista product lineup consists of six versions—two for businesses, three for con-
sumers, and one for emerging markets: Windows Vista Business, Windows Vista Enterprise,
Windows Vista Home Basic, Windows Vista Home Premium, Windows Vista Ultimate, and
Windows Vista Starter. Windows Vista is slated for business availability in November 2006,
with broad consumer availability in January 2007.
Novell
The NOS produced by Novell is called NetWare. Originally, this NOS supported a proprietary
protocol called SPX/IPX, but with the release of Version 5, it incorporated support for TCP/IP
along with SPX/IPX. The newest versions of NetWare are based entirely on the TCP/IP proto-
col stack.
NetWare is an outstanding file and print server that has an enormous user base. It was built
from the ground up to offer extremely stable and secure core networking services. Novell
recently began providing improved web-based access to the applications bundled with the oper-
ating system, but it continues to stress its core networking services. In addition, Novell has
made an effort to expand the NetWare kernel’s capability to run many open-source applications
such as MySQL and Apache. Reports indicate that future releases of NetWare may be done on
a Linux kernel.
Many organizations have implemented Novell NetWare in their backbone to provide user
authentication along with file and print services and then incorporate other servers for specific
applications and functions. Novell Directory Services (NDS) has long been popular with net-
work administrators for providing a single point of administration for network resources and
users. NDS provides a graphical set of tools that allows users of computers at remote locations
to be added, updated, and managed centrally. Applications can be distributed electronically and
maintained centrally. NDS runs not only on NetWare, but also on Microsoft and UNIX plat-
forms, making it ideal for integrating large multivendor networks.
UNIX / Linux
In the early days of computing, machines from different vendors couldn’t communicate. Often
even machines from the same vendor required interpreters to allow communications. To try to
develop a convenient, interactive, useable computer system that could support many users, a
group of computer scientists from Bell Labs and GE in 1965 joined an effort underway at MIT.
It was called the MULTICS (Multiplexed Information and Computing Service) mainframe
timesharing system. Unfortunately, the MULTICS project failed, but Ken Thompson and
Dennis Ritchie at AT&T Bell Laboratories continued developing a lower-cost alternative, which
was named UNIX as a pun on its MULTICS roots.
The UNIX OS was initially created in assembly language, but Thompson knew that it should be
written in a high-level language to allow flexibility and portability. Initial attempts at using
FORTRAN on a PDP-7 led to frustration, so Thompson created a very simple language he
named B. He later modified and enhanced it to create the C language. Thompson and Ritchie
then rewrote the entire UNIX OS in C.
During the 1970s, much work was done on the UNIX OS by Bell Labs and also many universi-
ties, including the University of California at Berkeley. Throughout its development, UNIX has
been owned and developed by many different organizations, each of which helped develop the
product into the extremely stable, versatile OS that exists today.
Initial marketing of the UNIX product was geared toward large organizations with powerful
computers. This is still the environment that many UNIX installations support. However, today
UNIX can be found running on all types of computers, from PCs to mainframes, and it comes
in many different varieties. UNIX is the OS of choice for many organizations and in many mis-
sion-critical environments.
Many versions of UNIX are currently available in the marketplace. Because it was originally
conceived and developed for large computer installations, UNIX has made only a small pene-
tration into the home desktop market. Sun Microsystems’ entry into the UNIX market is named
Solaris and is one of the most widely used versions of UNIX. Solaris can run on many different
platforms, including Intel-based PCs. Some other common flavors of UNIX include
■ Hewlett Packard UNIX (HP-UX)
■ Berkeley Software Distribution (BSD) UNIX, which has produced derivatives such as
FreeBSD
■ Santa Cruz Operation (SCO) UNIX
■ IBM UNIX (AIX)
In 1991, Linus Torvalds, a graduate student in Helsinki, Finland, saw the advantages of the
UNIX operating system and also recognized the limitations of the operating systems available
in the PC market at the time. Torvalds was extremely frustrated by the instability of the avail-
able PC operating systems and the high cost of licensing and running a UNIX-based system.
He set out to develop a UNIX-like OS that would run on an Intel 80386-based machine but that
would be constructed entirely of code that would be free for everyone to use. This was the
beginning of Linus’ UNIX, or Linux.
Linux was created entirely in the C programming language to function like UNIX, but it is
created by a worldwide team of developers to be free of any UNIX code, thus eliminating the
problem of royalties. Linux is released under a licensing scheme that makes the source code
freely available, allowing end users to customize the software and correct any issues that may
arise. Although the source code must remain freely available, many organizations spend time
collecting, organizing, and documenting these products and then market them as a commercial
distribution. Often, the software is bundled with support packages and marketed to organizations.
Versions of Linux are available for most 32-bit and 64-bit processors, including Intel, Motorola,
DEC Alpha, and PowerPC chips. Linux can be found running on machines from mainframes to
PCs. Linux distributions come and go, but some of the more popular Linux distributions are
■ Red Hat Linux
■ Open Linux
■ Slackware
■ Debian
■ SUSE Linux
Another popular UNIX-like OS is BSD. It was developed by the Computer Systems Research
Group (CSRG) at the University of California at Berkeley (UCB). This software started as a set
of additional software and patches to AT&T’s UNIX version 6. The AT&T copyrighted code
was removed from the BSD products and in 1993 BSD was released as a completely open-
source operating system. BSD forms the basis of Darwin, Apple’s open-source core of the Mac
OS X operating system. Although not Linux, it has much the same functionality and is compet-
ing in the same market space. BSD is currently available in a number of versions:
■ FreeBSD has been optimized for the PC platform. It includes easy installation and support
for a wide assortment of hardware. FreeBSD supports the i386 and alpha architectures.
■ NetBSD supports a wide assortment of platforms, from small handhelds to large alpha
servers.
■ OpenBSD focuses on security and cryptography. This product includes the OpenSSH suite
of secure network connectivity tools.
Linux has many advantages that have helped it gain acceptance in the business world. The fact
that this software is freely obtainable is of great importance. However, you must consider the
actual cost of the software, along with the cost of implementation and maintenance, to get a
true appreciation of the total cost of ownership.
From a technical standpoint, Linux is an operating system with great technical merit and stabil-
ity. The TCP/IP protocol stack is integrated into the kernel instead of being an add-on, making
Linux a network-ready operating system. This OS was designed to be a multiuser, multitasking
network operating system from the ground up, without the addition of extra modules and func-
tionality. Linux is a true 32-bit operating system that supports virtual memory and preemptive
multitasking. In addition, the open availability of the source code allows the operating system
to be enhanced and improved by anyone. Unfortunately, the open availability of the source code
also allows hackers to exploit apparent weaknesses in the operating system.
One area of weakness with Linux is the limited availability of appropriate application software.
However, this disadvantage is rapidly disappearing. Many applications are now being developed
for the UNIX/Linux market. Products such as WINE allow some Microsoft applications to run
on a Linux platform. This has started to increase the acceptance of Linux into the business
community for desktop use. However, Linux is still primarily used for server-based applications
such as web and e-mail.
Network Management Essentials

Network management is simply the ability to monitor and control a computer network from a
central location. The International Organization for Standardization (ISO) has defined a concep-
tual model describing network management. This model consists of four submodels, as illus-
trated in Figure 6-1 and as described in the following list:
■ The Organization model describes the components of a network management system and
their interrelationships. This includes items such as the manager and agents. The arrange-
ment of these devices leads to different types of architectures.
■ The Information model describes the structure and storage of network management infor-
mation. The information is stored in a database called the Management Information Base
(MIB). The OSI has defined the structure of management information (SMI) to define the
syntax and semantics of management information stored in the MIB.
■ The Communication model deals with how management information is moved between
the agent and the manager. It is concerned with the transport protocol, application protocol,
and messages and responses between the agent and manager.
■ The Functional model includes the following key areas:
— Fault management provides facilities that allow network managers to discover prob-
lems with managed devices and the network, to determine their cause, and to take
remedial action. To accomplish this, fault management provides mechanisms to report
problems, log reports, perform diagnostic tests, and correct faults.
— Configuration management monitors network configuration information so that the
effects of specific hardware and software may be managed and tracked. It lets you ini-
tialize, reconfigure, operate, and shut down managed devices.
— Accounting management measures network utilization by individuals or groups. It
provides billing information, regulates users and groups, and helps maintain network
performance at an acceptable level.
— Performance management gathers statistical information from the various managed
entities on the network so that network performance may be maintained at an accept-
able level. It monitors the utilization and error rates of network components and provides
a consistent level of performance by ensuring that devices have sufficient capacity.
— Security management controls access to network resources. It not only limits access
to resources but also reports security breaches and attempts.
Figure 6-1 ISO Network Management Model
Network
Management
Organization Information Communication Functional

Model Model Model Model
The general network management architecture consists of several components, as illustrated in

Figure 6-2 and as described in the following list:
■ The Network Management Station (NMS) runs the network management application,
which gathers information about managed devices from the management agents that reside
in these devices.
■ A managed device is any node on the network that contains a management agent. These
devices include computers, printers, switches, and routers.
■ A management agent provides information about a managed device to a network manage-
ment application. Management agents may also accept control information.
■ The Network Management Protocol is used by the network management application and
the management agent to exchange information.
■ Management information is exchanged between the network management application
and the management agents. It allows a managed device to be controlled and monitored.
Figure 6-2 Network Management Architecture
NMS
Management Management
Information Protocol
Agent
Managed
Device
In addition to running the network management software, the NMS provides an interface that
allows the operator to monitor and control managed devices as well as interact with the net-
work management application. A typical NMS receives and processes large quantities of data
and then displays a graphical representation of the network’s status. Some network manage-
ment applications allow threshold and trigger events to be configured that automatically invoke
predefined actions when the condition is met. The network management application is designed
to accomplish the following:
■ Perform tests and take automatic corrective actions (such as reconfiguration or shutdown of
a managed device) when necessary
■ Log network events
■ Present status information and alerts to the operator
Network monitoring software, both application and agents, is based on a specific network man-
agement protocol. The choice of protocol depends on a number of factors, including the net-
work’s scope and nature, the operating systems in use, and the management system’s require-
ments. Although proprietary network management protocols exist, most implementations use
either the Common Management Information Protocol (CMIP) or Simple Network
Management Protocol (SNMP). CMIP is used extensively in the telecommunications industry,
and SNMP is more often encountered in TCP/IP-based networks.
Common Management Information Protocol (CMIP)

Common Management Information Protocol (CMIP) is an Open Standards Interconnection-
(OSI) based network management protocol designed to run on the ISO protocol stack. CMIP is
described in RFC 1095 and RFC 1189. It is formally defined by the ITU-T X.700 series of rec-
ommendations. The CMIP specification for TCP/IP networks is called CMOT (CMIP over
TCP), and the version for IEEE 802 LANs is called CMOL (CMIP over LLC). CMIP was
developed to make up for the deficiencies encountered in SNMP. It is used extensively in the
telecommunications field.
CMIP defines how network management information is exchanged between network manage-
ment applications and agents, not the functionality of the network management application
itself. It uses an ISO reliable connection-oriented transport mechanism. Its built-in security sup-
ports access control, authorization, and security logs. This exchange of information occurs
through managed objects, which are a characteristic of a managed device that can be moni-
tored, modified, or controlled and that can be used to perform tasks.
Network management applications can initiate transactions, with the management agents using
the following operations:
■ ACTION requests an action to occur as defined by the managed object.
■ CANCEL_GET cancels an outstanding GET request.
■ CREATE creates an instance of a managed object.

■ DELETE deletes an instance of a managed object.
■ GET requests the value of a managed object instance.
■ SET sets the value of a managed object instance.
The EVENT_REPORT operation can be initiated by the management agent and is used to
send notifications or alarms to the management application. These are sent in response to pre-
defined conditions set in the network management application using the ACTION operation.
CMIP has many advantages over SNMP:
■ CMIP variables can be used to relay information or perform tasks.
■ CMIP has built-in security that supports authorization, access control, and security logs.
■ CMIP allows management applications to accomplish more with a single request.
■ CMIP provides better reporting of unusual network conditions.
To provide this functionality, CMIP is an extremely complex procedure that requires large
amounts of system resources to implement. Because of its complexity, a highly skilled operator
is required to properly implement and operate a CMIP-based network management system. In
addition, the most common protocol stack in the LAN world is TCP/IP, and many LAN devices
support only SNMP. For these reasons, CMOT installations are extremely scarce, and SNMP is
still the most widely deployed network management protocol.
Simple Network Management Protocol (SNMP)

SNMP was developed in the mid-1980s by the Internet Engineering Task Force (IETF). It was
formally adopted as a standard for TCP/IP in 1989. The goal of SNMP is to provide a standard,
simplified, extensible way to manage LAN-based products. SNMP was designed to reduce the
complexity of network management and to minimize the resources required to support it.
SNMP Architecture and Operation

SNMP describes how management information is exchanged between a network management
application and management agents. SNMP is a simple message-based request/response
application-layer protocol that uses User Datagram Protocol (UDP) ports 161 and 162 for data
delivery. The SNMP architecture consists of the following elements:
■ The Network Management Station (NMS) is the workstation that hosts the network man-
agement application.
■ The Network Management Application (NMA) is a collection of software that polls
management agents for information and also provides control information to clients. In
addition, the NMA provides the user interface.
■ The Management Information Base (MIB) defines the information that can be collected
and managed by the network management application.
■ A management agent provides information contained in the MIB to management applica-
tions and accepts control information. The information provided may be in response to
polling by the NMA or may be provided in an unsolicited manner in response to a precon-
figured trap.
A management agent may keep track of a number of items, including the following:
■ Number and state of virtual circuits
■ Number of certain kinds of error messages received
■ Number of bytes and/or packets moving into or out of a device
■ Maximum output queue length
■ Broadcast messages sent and received
■ Network interfaces going up or down
The MIB is a database of managed objects that resides on the management agent. These objects
are characteristics of a managed device that can be monitored, modified, or controlled by the
following commands:
■ GET_REQUEST requests the value of an object instance from the agent.
■ GET_NEXT_REQUEST requests the next instance of an object from an agent.
■ GET_RESPONSE is the returned answer to GET_NEXT_REQUEST,
GET_REQUEST, or SET_REQUEST commands.
■ SET_REQUEST sets the value of an object instance within an agent.
■ TRAP sends a trap event asynchronously to a management application. The types of
events that can be trapped include such things as device failure, agent start/stop/restart, or
the change in a device’s state.
By specifying only the protocol used between the network management application and the net-
work monitoring agent, an SNMP application can be used with agents from multiple vendors.
Legacy equipment can also be communicated with by using an SNMP proxy function. Unlike
CMIP, SNMP is simple to implement and does not require large amounts of resources to func-
tion.
The SNMP manager polls for information gathered by the agents. Each agent gathers informa-
tion about the device in which it is incorporated and stores this information in a local MIB.
This information is then sent to the SNMP manager in response to the manager’s polling. This
is called a two-tier system (see Figure 6-3). SNMP events are driven by trap messages generat-
ed as a result of device parameters.
Figure 6-3 SNMP Two-Tiered Model

Polling Traps
NMS
Network Unsolicited
Queries Events
MIB
Agent Agent
Managed Managed
Device Device
In networks that have legacy devices or devices with proprietary management interfaces, a
three-tiered system is required that incorporates a proxy agent. The NMS communicates with
the proxy agent using SNMP. The proxy agent then translates the messages into a form appro-
priate to the device being communicated with. Messages from the managed device are received
by the proxy agent and are translated back into SNMP messages for delivery to the NMS, as
illustrated in Figure 6-4.
Figure 6-4 SNMP Proxy Agents and RMON Probes
NMS
MIB RMON
Proxy
Agent Probe
Agent
Unmanaged
Managed
Element
Element
The management entity or NMS issues specific requests to gather information from the man-
agement agents. The manager processes this information and presents it in a number of forms,
depending on the requirements. The information may simply be logged for later analysis, dis-
played through the use of a graphing utility, or compared to preset values to determine if a cer-
tain condition has been met.
The manager also allows the administrator to configure managed devices using SNMP. This is
accomplished by issuing changes to values in the managed device to alter its configuration.
Minimizing SNMP Overhead

To reduce the overhead on the network caused by monitoring activities, some network manage-
ment applications use remote monitoring (RMON) probes. The role of the RMON probe is to
gather information from the management agent and store it locally, as illustrated in Figure 6-8.
The network manager periodically polls the RMON probe to retrieve a summary of the man-
agement information. Because only a summary of the collected information is transferred when
the RMON probe is polled, bandwidth consumption is minimized.
Network management applications such as CiscoWorks and HP OpenView run on ordinary
workstations equipped with large amounts of RAM. They rely on the network operating system
to provide the network protocol stack and all required communication functions.
In small networks, a centralized management arrangement is appropriate, as shown in Figure 6-5.
As networks grow in size and complexity, increased polling frequencies are required to gather
the necessary information. This increased polling puts a burden on network bandwidth and can
seriously impact network performance if a centralized network management scheme is used. In
large networks, a distributed management system might be more appropriate.
Figure 6-5 Centralized Network Management Arrangement

NMS
MIB
Site A Site C
Site B
Enterprise Network
In a decentralized network, a distributed management system is more appropriate than a cen-

tralized one. In this arrangement, the local NMS can act in either a client/server arrangement,
as shown in Figure 6-6, or a peer arrangement, as shown in Figure 6-7. In a client/server
arrangement, one NMS assumes the role of server, and the rest act as clients. The clients gather
information from the local agents and send it to the server NMS for centralized storage. An
alternative arrangement is to have each local NMS maintain its own databases, thus distributing
the management information over several peer NMSs.
Figure 6-6 Client/Server NMS Arrangement

Server Central
NMS MIB
Client Client Client

NMS NMS NMS
Local Local Local

Query Query Query
Site A Site B Site C
Enterprise Network
Figure 6-7 Peer-to-Peer NMS Arrangement

Peer Local
NMS MIB
Local MIB Local MIB Local MIB

Peer Peer Peer
NMS NMS NMS
Local Local Local

Query Query Query
Site A Site B Site C
Enterprise Network
Because monitored devices must process the manager’s request, excessive polling can have a
severe negative impact on their performance. A general rule is to monitor only critical devices
and links and to keep the polling as infrequent as possible. This minimizes the consumption of
bandwidth by management processes and also minimizes the impact of frequent polling of the
devices themselves.
Management Information Base

A Management Information Base (MIB) is a structured database used to store information on
managed elements. The structure, naming, and encoding of the MIB are defined by SMI. MIB-I
refers to the initial MIB definition, which defines eight groups and 114 managed objects. MIB-
II refers to the current definition and extends the number of managed objects to 185. SNMPv2
includes support for MIB-II.
Managed objects in the SNMP environment are arranged in a hierarchical or tree structure. A
tree’s leaf objects are the actual managed objects, with each managed object representing some
managed resource, activity, or related information. Managed objects are assigned a unique
object identifier (OID) based on the Abstract Syntax Notation (ASN.1) standard. These num-
bers take on the form of a number in dot notation, as shown in Figure 6-8.
Figure 6-8 SNMP ASN.1 OID
MIB extensions exist for each set of related network entities that can be managed. For example,
MIBs in the form of RFCs are available for AppleTalk, DNS, FDDI, and RS-232c network
objects. Product developers can create and register new MIB extensions. The IETF maintains a
list of these RFCs that is readily accessible on its website. After a vendor has received an
assigned enterprise value, it is then responsible for creating and maintaining all subtrees.
SNMP Messages
SNMP uses UDP as a transport protocol. Because UDP is both connectionless and unreliable, it
is up to the management application to determine how to cope with lost messages. SNMP itself
has no provision for guarantee of delivery.
Figure 6-9 shows the SNMPv1 message format. The message header contains a version number
and community name. The community name defines an access environment for a group of
NMSs and serves as a very weak form of authentication. NMSs with the same community
name are said to exist within the same administrative domain. All SNMP-based management
applications need to be configured to use the correct community strings. Some organizations
have a policy to change the community string at regular intervals to prevent unauthorized use
on the SNMP services. It is a good idea not to use the default values of public and private for
the community strings.
Figure 6-9 SNMPv1 Message Format
Message
PDU
Header
SNMPv1 protocol data units (PDUs) contain a specific command and operands that indicate the
object instances involved in the transaction. The SNMPv1 PDU fields are variable in length, as
prescribed by ASN.1. The Get, GetNext, Response, and Set PDUs contain the same fields, as
shown in Figure 6-10.
Figure 6-10 SNMPv1 Get, GetNext, Response, and Set PDU Format
PDU Request Error Error Object 1 Object 2 Object x

Type ID Status Index Value 1 Value 2 Value x
Variable Bindings
The fields in the SNMPv1 Get, GetNext, Response, and Set PDUs are as follows:
■ PDU Type specifies the type of PDU transmitted. 0 = GetRequest, 1 = GetNextRequest,
2 = GetResponse, and 3 = SetRequest.
■ Request ID associates SNMP requests with responses.
■ Error Status indicates one of a number of errors and error types. Only the response opera-
tion sets this field. Other operations set this field to 0.
■ Error Index associates an error with a particular object instance. Only the response opera-
tion sets this field. Other operations set this field to 0.
■ Variable Bindings is the data field of the SNMPv1 PDU. Each variable binding associates
a particular object instance with its current value. This field is ignored for Get and GetNext
requests.
The SNMPv1 Trap PDU consists of eight fields, as shown in Figure 6-11:
■ Enterprise identifies the type of managed object generating the trap.
■ Agent Address is the address of the managed object generating the trap.
■ Generic Trap Type is one of a number of generic trap types.
■ Specific Trap Code is one of a number of specific trap codes.
■ Time Stamp is how much time has elapsed between the last network reinitialization and
trap generation.
a particular object instance with its current value.
Figure 6-11 SNMPv1 Trap PDU
Enterprise Agent Generic Specific Trap Time Object 1 Object 2 Object x

Address Trap Type Code Stamp Value 1 Value 2 Value x
Variable Bindings
SNMP Version 2
In 1993 SNMP version 2 was adopted. SNMPv2 is an evolution of SNMPv1. The Get,
GetNext, and Set operations used in SNMPv2 are exactly the same as in SNMPv1; however,
SNMPv2 enhances some of them. SNMPv2 defines two new operations: GetBulk and Inform.
The GetBulk operation is used to efficiently retrieve large blocks of data. Figure 6-12 shows the
format of the GetBulk message. The Inform operation allows one NMS to send trap informa-
tion to another NMS and then receive a response.
Figure 6-12 SNMPv2 GetBulk PDU
PDU Request Non- Max Object 1 Object 2 Object x

Type ID repeaters Repetitions Value 1 Value 2 Value x
Variable Bindings
The fields in the SNMPv2 GetBulk PDU format are as follows:

■ PDU Type identifies the PDU as a GetBulk operation.
■ Request ID associates SNMP requests with responses.
■ Nonrepeaters specifies the number of object instances in the Variable Bindings field that
should be retrieved no more than once from the beginning of the request. This field is used
when some of the instances are scalar objects with only one variable.
■ Max Repetitions defines the maximum number of times that other variables beyond those
specified by the Nonrepeaters field should be retrieved.
a particular object instance with its current value.
SNMPv2 extends SNMP’s basic functionality by adding the following:
■ Manager-to-manager communication, which allows multiple managers to coexist and share
information and provides enhanced scalability
■ Enhanced security by providing mechanisms for encryption, authentication, and authoriza-
tion
■ Improved efficiency and performance through the use of bulk data transfer
■ Support for additional protocols, including IPX/SPX and AppleTalk
■ 64-bit counters to prevent counter rollover
SNMP Version 3
The current version of SNMP is SNMPv3. SNMPv3 adds security and remote configuration
capabilities to the earlier versions. SNMPv3 introduces the User-based Security Model (USM)
for message security and View-based Access Control Model (VACM) for access control.
SNMPv3 also introduces the ability to dynamically configure the SNMP agent using the SNMP
SET commands to modify the MIB objects that represent the agent’s configuration. This
dynamic configuration support lets you add, delete, and modify configuration entries either
locally or remotely. Figure 6-13 illustrates the SNMPv3 protocol structure, which is described
in the following list:
■ Version—For SNMPv3 this is 3.
■ ID—A unique identifier used between two SNMP entities to coordinate Request and
Response messages.
■ Msg Size—Maximum size of a message in octets, supported by the message’s sender.
■ Msg Flags—An octet string containing three flags in the least-significant 3 bits:
reportableFlag, privFlag, and authFlag.
■ Security Model—An identifier that indicates which security model was used by the sender
and therefore which security model must be used by the receiver to process this message.
■ Authoritative Engine ID—The SNMP engine ID of the authoritative SNMP engine

involved in the message’s exchange. This value refers to the source for a Trap, Response,
or Report and to the destination for a Get, GetNext, GetBulk, Set, or Inform.
■ Authoritative Engine Boots—The SNMP Engine Boots value of the authoritative SNMP
engine involved in the message’s exchange.
■ Authoritative Engine Time—The SNMP Engine Time value of the authoritative SNMP
engine involved in the message’s exchange.
■ Username—The user (principal) on whose behalf the message is being exchanged.
■ Authentication Parameters—Null if authentication is not being used for this exchange.
Otherwise, this is the authentication parameter.
■ Privacy Parameter—Null if privacy is not being used for this exchange. Otherwise, this is
a privacy parameter.
■ Context Engine Type—Within an administrative domain, a contextEngineID uniquely
identifies an SNMP entity that may realize an instance of a context with a particular
contextName.
■ Context Name—An SNMP context is a collection of management information that can be
accessed by an SNMP entity.
■ PDU (Protocol Data Unit)—The PDU types for SNMPv3 are the same as for SNMPv2.
Figure 6-13 SNMPv3 Protocol Structure

Message Processed by MPM
Msg Security
Version ID Msg Size Flag Model
Message Processed by USM

Authoritative Authoritative Authoritative User Authentication Privacy
Engine ID Boots Engine Time Name Parameters Parameter
Scoped PDU
Context Context PDU
Engine Type Name
Comparing SNMP Versions

Table 6-2 summarizes the differences between the three available versions of SNMP.
Table 6-2 Comparing the Versions of SNMP
Version Level Authorization Encryption Description
SNMPv1 noAuthNoPriv Community string No Uses a community string

match for authentication.
SNMPv2c noAuthNoPriv Community string No Uses a community string
SNMPv3 noAuthNoPriv Username No Uses a username string
authNoPriv MD5 or SHA No Provides authentication
based on HMAC-MD5 or
HMAC-SHA algorithms.
authPriv MD5 or SHA DES Adds 56-bit DES encryp-
tion in addition to
authentication.
Configuring SNMP
Configuring SNMP on a Cisco device requires the completion of a minimum of three tasks:
■ Task 1—Define the relationship between the SNMP agent and manager using a communi-
ty string.
■ Task 2—Configure the SNMP-Server hosts.
■ Task 3—Configure the device to send SNMP notifications.
Although this enables SNMP, many more commands and configuration options are available to
customize its functionality.
Task 1
Define the relationship between the SNMP agent and manager using a community string. The
community string acts like a password to regulate access to the agent. To accomplish this, use
the following command:
Router(config)#snmp-server community string [ro | rw]
string is the actual SNMP community string. Common community strings such as public and pri-
vate should be avoided. In networks where security is of prime importance, the string should be
changed on a regular basis. The optional parameter ro sets the string to read-only status, which
allows authorized managers to retrieve MIB objects but not modify them. If the parameter is speci-
fied as rw, authorized managers have read-write access and can both read and modify MIB objects.
Task 2
Configure the SNMP-Server hosts using the following command:
Router(config)#snmp-server host host-id [traps | informs][version {1 | 2c | 3
[auth | noauth | priv]}] community-string [udp-port port-number] [notification-type]
This command specifies whether you want the SNMP notifications sent as traps or informs, the
version of SNMP to use, the security level of the notifications (for SNMPv3), and the recipient
(host) of the notifications.
Task 3
Configure the device to send SNMP notifications. These notifications may be either traps or
informs. Configuring these notifications is a five-step process:
Step 1. Specify the engine ID for the remote host:
Router(config)#snmp-server engineID remote remote-ip-addr remote-engineID
Step 2. Configure an SNMP user to be associated with the host just created:
Router(config)#snmp-server user username groupname [remote host [udp-port port]
{v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-
list]
Step 3. Configure an SNMP group:

Router(config)#snmp group groupname {v1 | v2 | v3 {auth | noauth | priv}} [read
readview]
[write writeview] [notify notifyview] [access access-list]
Step 4. Specify whether you want the SNMP notifications sent as traps or informs, the ver-
sion of SNMP to use, the security level of the notifications (for SNMPv3), and the
recipient (host) of the notifications:
Router(config)#snmp-server host host [traps | informs] [version {1 | 2c | 3
[auth | noauth | priv]}] community-string [notification-type]
Step 5. Enable sending of traps or informs, and specify the type of notifications to be sent.
If a notification-type is not specified, all supported notifications are enabled on the
router. To discover which notifications are available on your router, enter the snmp-
server enable traps command:
Router(config)#snmp-server enable traps [notification-type [notification-
options]]
Although it isn’t necessary, configuring the SNMP device with contact information can prove
beneficial. You can specify the SNMP server location and contact with the following commands:
Router(config)#snmp-server location text
Router(config)#snmp-server contact text
In both of these commands, the text string is used to describe the system location and contact
information. This information is stored in the MIB objects sysLocation and sysContact,
respectively.
RMON
Remote Monitoring (RMON) is a standard monitoring specification that enables various net-
work monitors and console systems to exchange network-monitoring data. RMON became a
proposed standard in 1992 as RFC 1271 (for Ethernet) and then became a draft standard in
1995 as RFC 1757, effectively making RFC 1271 obsolete. RMON1 is for the data link layer,
and RMON2 is for the network-to-application layer.
SNMP agents monitor specific devices and store the information in the MIB. The RMON spec-
ification adds to the capabilities of MIB-II. It defines a set of statistics and functions that can be
exchanged between RMON-compliant console managers and network probes. RMON provides
network administrators with comprehensive network-fault diagnosis, planning, and perform-
ance-tuning information. Monitoring devices, called agents or probes, can be placed on critical
network segments and analyze every frame on the segment. This allows a large volume of sta-
tistics to be collected from the network segment itself.
The RMON standard for Ethernet defines nine groups of monitoring elements (see Table 6-3),
each providing specific sets of data to meet common network-monitoring requirements. RFC
1513 adds a tenth group for Token Ring-unique parameters. Because each group is optional,
vendors do not need to support all the groups within the MIB. Interoperability between the var-
ious vendors of RMON-based diagnostic tools is ensured by defining a specific MIB structure
for all nine groups.
Table 6-3 RMON Monitored Elements
RMON Group Function Elements

Statistics Contains statistics measured by the Packets dropped, packets sent, bytes
probe for each monitored interface sent (octets), broadcast packets,
on this device. multicast packets, cyclic redundancy
check (CRC) errors, runts, giants,
fragments, jabbers, collisions, and
counters for packets ranging from 64
to 128, 128 to 256, 256 to 512, 512 to
1024, and 1024 to 1518 bytes.
History Records periodic statistical samples Sample period, number of samples,
from a network and stores them for items sampled.
later retrieval.
Alarm Periodically takes statistical samples Includes the alarm table and requires
from variables in the probe and the implementation of the event
compares them with previously group. Alarm type, interval, starting
configured thresholds. If the threshold, stop threshold.
monitored variable crosses a
threshold, an event is generated.
Host Contains statistics associated with Host address, packets, and bytes
each host discovered on the network. received and transmitted, as well
as broadcast, multicast, and error
packets.
HostTopN Prepares tables that describe the Statistics, host(s), sample start and
hosts that top a list ordered by one stop periods, rate base, duration.
of their base statistics over an interval
specified by the management station.
Thus, these statistics are rate-based.
Matrix Stores statistics for conversations Source and destination address pairs
between sets of two addresses. As and packets, bytes, and errors for
the device detects a new conversation, each pair.
it creates a new entry in its table.
Filters Enables packets to be matched by Bit-filter type (mask or no mask),
a filter equation. These matched filter expression (bit level),
packets form a data stream that conditional expression (and or not)
might be captured or that might to other filters.
generate events.
Packet Capture Enables packets to be captured Size of the buffer for captured packets,
after they flow through a channel. full status (alarm), number of
captured packets.
Events Controls the generation and Event type, description,
notification of events from last time event sent.
this device.
Syslog
The Syslog facility, as described in RFC 3164, provides a transport mechanism to allow devices
to send event notification messages across an IP network to a Syslog server. Applications,
processes, and the operating system of Cisco devices generate messages about the activity of
devices and also error conditions that are normally logged to the system console. The Syslog
utility built into Cisco devices uses UDP port 514 to send these unsolicited messages to a net-
work management station.
The Syslog packet is limited in size to 1024 bytes and contains the following information:
■ Facility
■ Severity
■ Hostname
■ Timestamp
■ Test message
Syslog messages are categorized based on the source that generated them (see Table 6-4). This
categorization is called the facility and is represented by an integer value, as shown in Table 6-4.
Keep in mind that Syslog was designed to work in a UNIX environment, so many of the facility
values relate to this environment. Messages that do not fit into one of the preassigned facility
values can use one of the eight local values. By default, Cisco IOS-based devices use local7 to
send messages to the Syslog server.
Table 6-4 Syslog Message Sources
Integer Facility
0 Kernel messages
1 User-level messages
2 Mail system
3 System daemons
4 Security/authorization messages
5 Messages generated internally by Syslogd
6 Line printer subsystem
7 Network news subsystem
8 UUCP subsystem
9 Clock daemon
10 Security/authorization messages
continues
Table 6-4 Syslog Message Sources continued
Integer Facility
11 FTP daemon
12 NTP subsystem
13 Log audit
14 Log alert
15 Clock daemon
16 Local use 0 (local0)
The sending device also reports the severity value. Cisco devices use severity levels of emer-
gency to warning to report problems with hardware. A system restart or an interface change in
state is reported through the notice level. A system reload is reported through informational
messages. System debug output is reported through the debug level. Table 6-5 describes the
available severity levels.
Table 6-5 Syslog Severity Levels
Integer Severity
0 Emergency: The system is unusable.

1 Alert: Action must be taken immediately.
2 Critical: Critical conditions.
3 Error: Error conditions.
4 Warning: Warning conditions.
5 Notice: Normal but significant conditions.
6 Informational: Informational messages.
7 Debug: Debug-level messages.
The hostname is the device’s configured name. Devices with multiple interfaces use the IP
address of the interface that is sending the message. The timestamp contains the time that the
message was generated. The message is a text string that contains information about the error
or condition.
For the network management station to receive messages from Cisco devices, these devices
must be configured properly. The fist step is to turn on logging with the following command:
Router(config)#logging on
After this is done, you must specify the location of the Syslog server using the following com-
mand:
Router(config)#logging hostname | IP address
You can configure the severity level of the messages that must be logged using the following
command:
Router(config)#logging trap level
You can switch on the time stamps in the logged messages with the following command:
Router(config)#service timestamps log datetime

Introduction To Network Administration: Additional Topics of Interest

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Network Administration: Additional Topics of Interest

Uploaded by

Copyright:

Available Formats

1722ch6atol.

qxd 7/13/06 10:49 AM Page 1

Introduction to Network Administration

Additional Topics of Interest

Choice of NOS ………………………………………………………………………………………………3

Network Management Essentials ………………………………………………………………………10

2 WAN Technologies CCNA 4 Companion Guide

Table 6-1 Common TCP/IP Services

Service TCP/IP Protocol

World Wide Web HTTP

Chapter 6: Introduction to Network Administration 3

4 WAN Technologies CCNA 4 Companion Guide

Chapter 6: Introduction to Network Administration 5

6 WAN Technologies CCNA 4 Companion Guide

Chapter 6: Introduction to Network Administration 7

8 WAN Technologies CCNA 4 Companion Guide

Chapter 6: Introduction to Network Administration 9

10 WAN Technologies CCNA 4 Companion Guide

Network Management Essentials

Chapter 6: Introduction to Network Administration 11

Figure 6-1 ISO Network Management Model

Organization Information Communication Functional

The general network management architecture consists of several components, as illustrated in

Figure 6-2 Network Management Architecture

12 WAN Technologies CCNA 4 Companion Guide

Common Management Information Protocol (CMIP)

Chapter 6: Introduction to Network Administration 13

■ CREATE creates an instance of a managed object.

Simple Network Management Protocol (SNMP)

SNMP Architecture and Operation

14 WAN Technologies CCNA 4 Companion Guide

Chapter 6: Introduction to Network Administration 15

Figure 6-3 SNMP Two-Tiered Model

Figure 6-4 SNMP Proxy Agents and RMON Probes

16 WAN Technologies CCNA 4 Companion Guide

Minimizing SNMP Overhead

Figure 6-5 Centralized Network Management Arrangement

Chapter 6: Introduction to Network Administration 17

In a decentralized network, a distributed management system is more appropriate than a cen-

Figure 6-6 Client/Server NMS Arrangement

Client Client Client

Local Local Local

Site A Site B Site C

Figure 6-7 Peer-to-Peer NMS Arrangement

Local MIB Local MIB Local MIB

Local Local Local

Site A Site B Site C

18 WAN Technologies CCNA 4 Companion Guide

Management Information Base

Figure 6-8 SNMP ASN.1 OID

Chapter 6: Introduction to Network Administration 19

Figure 6-9 SNMPv1 Message Format

PDU Request Error Error Object 1 Object 2 Object x

20 WAN Technologies CCNA 4 Companion Guide

Figure 6-11 SNMPv1 Trap PDU

Enterprise Agent Generic Specific Trap Time Object 1 Object 2 Object x

Figure 6-12 SNMPv2 GetBulk PDU

PDU Request Non- Max Object 1 Object 2 Object x

The fields in the SNMPv2 GetBulk PDU format are as follows:

Chapter 6: Introduction to Network Administration 21

22 WAN Technologies CCNA 4 Companion Guide

■ Authoritative Engine ID—The SNMP engine ID of the authoritative SNMP engine

Figure 6-13 SNMPv3 Protocol Structure