Transcript 2. SNMPv3 and Network Management

Enterprise Network Management
Chapter 2
SNMPv3 and Network Management
Jiun
January 2005
Chapter 2: SNMPv3 and Network Management
1
SNMPv3 Structure
• SNMPv3 entity consists of two main
components:
• An SNMP engine
• A collection of SNMP applications
Chapter 2: SNMPv3 and Network Management
2
SNMPv3 Engine
• The SNMPv3 engine is made up of four
subcomponents:
• Dispatcher handles message sending and receiving.
• Message subsystem handles message processing for
SNMPv3, SNMPv2c, SNMPv1, and any other models.
• Security subsystem handles security processing for
SNMPv3 user-based security model (USM),
SNMPv1/v2c community-based security model, and
any additional (newly defined) models.
• Access control subsystem handles the granting/rejecting
of access to specific managed objects.
Chapter 2: SNMPv3 and Network Management
3
SNMPv3 Engine (cont.)
•
Two important points to note about the
engine subcomponents are that they:
•
•
Can hand off the message processing to each
other as required.
Are themselves extensible entities.
Chapter 2: SNMPv3 and Network Management
4
A collection of SNMP applications
• There are currently five SNMPv3 applications
defined:
•
•
•
•
Command generators, create SNMP messages.
Command responders, respond to SNMP messages.
Notification originators, send trap or inform messages.
Notification receivers, receive and process trap or
inform messages.
• Proxy forwarders, forward messages between SNMP
entity components.
Chapter 2: SNMPv3 and Network Management
5
SNMPv3 Message Formats
• The message format is broken down into four
overall sections made up of the following:
• Common data: These fields occur in all SNMPv3
messages.
• Security model data: This area has three subsections—
one general, one for authentication, and one for privacy
data.
• Context: These two fields are used to provide the
correct context in which the protocol data unit (PDU)
should be processed.
• PDU: This area contains an SNMPv2c PDU.
Chapter 2: SNMPv3 and Network Management
6
SNMPv3 Message Formats (cont.)
Figure 2-1. SNMPv3 message format.
Chapter 2: SNMPv3 and Network Management
7
SNMPv3 Message Formats (cont.)
• Common Data
•
•
•
•
•
MessageVersion
MessageID
MaxMessageSize
MessageFlags
MessageSecurity
Chapter 2: SNMPv3 and Network Management
8
SNMPv3 Message Formats (cont.)
• Security Model Data
• General
•
•
•
•
EngineID
EngineBoots
EngineTime
UserName
• Authentication Protocol
• MD5 (Message Digest)
• SHA (Secure Hash Algorithm)
• Privacy Protocol
• DES Key (Data Encryption Standard)
Chapter 2: SNMPv3 and Network Management
9
SNMPv3 Message Formats (cont.)
• Context
• ContextName
• ContextID
• PDU
• MessageFlags
Chapter 2: SNMPv3 and Network Management
10
SNMPv3 Message Formats (cont.)
• SNMPv3 Message Exchanges
• SNMPv3 GetRequest
• SNMPv3 Get-NextRequest
• SNMPv3 GetBulkRequest
• SNMPv3 SetRequest
• SNMPv3 Notifications
• Access Rights
• Message Size
• SNMPv3 Security
Figure 2-2. SNMP GetRequest and GetResponse messages.
Chapter 2: SNMPv3 and Network Management
11
SNMPv3 Message Formats (cont.)
• Problems with SNMP:
• SNMP is not transaction-oriented but instead offers an
all-or-nothing style of execution. It is difficult to
manipulate very large data sets.
• Scalability issues where tables grow to include
thousands of rows.
• Notifications are not guaranteed to arrive at their
destination. Management operations (such as get or set)
can time out if the network is congested or the agent
host is heavily loaded.
• SNMP messages use the UDP protocol (best-effort
datagram service).
Chapter 2: SNMPv3 and Network Management
12
SNMPv3 Message Formats (cont.)
• The Different Versions of SNMP :
• SNMPv1
• SNMPv2c
• SNMPv3
Chapter 2: SNMPv3 and Network Management
13
SNMPv3 Message Formats (cont.)
• SNMP Applications: MIB Browsers
• MIB browsers are specialized tools used to
examine the values of MIB object instances on
a given agent. A MIB browser can be a fully
integrated GUI-based application or a simple
text-based one.
Chapter 2: SNMPv3 and Network Management
14
SNMPv3 Message Formats (cont.)
A Closer Look at a MIB
1.
2.
3.
4.
5.
6.
7.
8.
9.
The BEGIN keyword indicates the start of the
MIB (arrow 1).
The IMPORTS keyword introduces descriptors
from external MIBs in a similar way to #include
in C and import in Java. The IMPORTS statement
identifies the descriptor and the module in which
it is defined (arrow 2).
The MODULE-IDENTITY keyword describes an
entry point name for objects defined later in the
MIB. The objects defined further down "hang" off
this name (arrow 3), as shown by the black
arrowed line.
The DESCRIPTION keyword provides details
about the MIB content (arrow 4).
The REVISION keyword indicates the change
history of the MIB (arrow 5).
The OBJECT IDENTIFIER keyword defines
either new managed objects or placeholders for
them in the MIB (arrow 6).
A sample, scalar, read-only integer object,
mplsTunnelConfigured, is shown (arrow 7).
The remainder of the MIB (more scalars and
tables) is skipped over (arrow 8).
The MIB finishes with the END keyword (arrow
9).
Figure 2-5. An extract from one of the draft-standard MPLS MIBs .
Chapter 2: SNMPv3 and Network Management
15
SNMPv3 Message Formats (cont.)
• Managed Objects :
• Managed objects are the basic unit of exchange
between an NMS and NEs. The managed
objects are defined in the MIB and deployed in
the network.
Chapter 2: SNMPv3 and Network Management
16
SNMPv3 Message Formats (cont.)
• There Is only One MIB :
• One merit of a standard MIB is ease of
extension. As new technologies are invented
and deployed, the associated managed objects
must be defined in new MIB modules. The
latter can then be added to the standard MIB in
an orderly fashion, e.g., by using enterprisespecific numbers.
Chapter 2: SNMPv3 and Network Management
17
SNMPv3 Message Formats (cont.)
• Analogy for an NMS:
• In the case of operating systems, some of the
abstract objects are:
•
•
•
•
•
Files
Applications
Processes
Devices, such as hard disks and network interfaces
Soft objects, such as print jobs and semaphores
Chapter 2: SNMPv3 and Network Management
18
SNMPv3 Message Formats (cont.)
• Analogy for an NMS (cont.):
• NMS also employ the above objects in addition to other
objects specific to network management:
• MIB modules
• Applications—agents and managers
• Devices—remote NEs
• Soft objects—connections, paths, interfaces, and so
on
Chapter 2: SNMPv3 and Network Management
19
Network Elements
Figure 2-6. Typical NE software components. (in no particular order )
Chapter 2: SNMPv3 and Network Management
20
Network Elements (cont.)
• An example of an NE is an intelligent line
card, which is hosted inside another system,
such as a PABX, ATM/MPLS switch, or IP
router Command generators create SNMP
messages.
Chapter 2: SNMPv3 and Network Management
21
Network Elements (cont.)
• Some characteristics of intelligent line cards include
the following:
• They can extend the lifespan of the host by adding
advanced functions such as SNMP and VoIP for a
PABX.
• They can take a long time to develop.
• Operators like to extract the maximum performance
from them—for example, port bandwidth.
• They increasingly incorporate numerous layer 1, 2, and
3 protocols.
Chapter 2: SNMPv3 and Network Management
22
Network Elements (cont.)
• High loading can occur when:
• Many voice calls are in transit through a PABX.
• Large numbers of ATM virtual circuits are transporting
many ATM cells.
• Large numbers of IP packets are in transit across a
router.
• Network topology changes result in routing protocol
convergence.
Chapter 2: SNMPv3 and Network Management
23
Introducing MPLS: First Chunk
• On a more general note, a good
understanding of MPLS is important for
appreciating issues such as traffic
engineering, network-QoS, and connectionoriented IP networks. Many voice calls are in
transit through a PABX
Chapter 2: SNMPv3 and Network Management
24
The Trend Towards IP
• Reasons for this migration towards IP:
• IP has become the lingua franca of networking.
• End-user devices, such as mobile phones, PDAs, and TV set-top
boxes, have become IP-capable.
• Existing layer 2 devices do not easily support massive (scalable)
deployment of layer 3 protocols.
• The need for specialized layer 2 maintenance skills is reduced.
• A single layer 3 control plane is easier to manage.
• Aggregation of IP traffic becomes possible, improving scalability.
• Different (guaranteed) levels of network service can be sold to
customers.
• Management system object models can become more generic.
Chapter 2: SNMPv3 and Network Management
25
The Trend Towards IP (cont.)
• MPLS is a good starting point for this
migration because:
• MPLS allows traffic engineering (putting the traffic
where the bandwidth is).
• MPLS integrates IP QoS with layer 2 QoS.
• Many vendors are providing MPLS capability in their
devices—for example, Cisco, Juniper, Nortel Networks,
and Marconi.
Chapter 2: SNMPv3 and Network Management
26
MPLS Concepts
• MPLS is a forwarding technology. Its
purpose is to receive an incoming traffic
type (layer 2 or 3) at the network edge,
encapsulate it, and then transmit it through
an MPLS core (or cloud). At the exit from
the cloud, another edge device removes the
MPLS header and forwards the traffic
towards its destination.
Chapter 2: SNMPv3 and Network Management
27
MPLS Concepts (cont.)
Figure 2-7. An MPLS network joining enterprise branches.
Chapter 2: SNMPv3 and Network Management
28
MPLS Concepts (cont.)
• Taking the first IP packet that arrives, LER1 can:
• Forward the packet unlabeled; the packet is
then routed to the next hop. In this mode, the
MPLS nodes act as pure IP routers.
• Drop the packet.
• Encapsulate the packet with an MPLS label and
push it onto an LSP.
Chapter 2: SNMPv3 and Network Management
29
MPLS Concepts (cont.)
• An LSP has the following characteristics:
• The LSP is created manually or via a signaling protocol.
• The path taken by the LSP may be either user-specified or computed by
LER1.
• The LSP may have reserved resources, such as bandwidth, along the path.
• There is a link between LER1 and LSR3, but the incoming traffic does not
take this route. Instead, traffic at LER1 is pushed onto the LSP and
follows the route LER1-LSR1-LSR2-LSR3.
• IP traffic from IP Router 1 landing on LER1 is MPLS-encapsulated and
forwarded across the LSP all the way to LER2. LER2 removes the MPLS
encapsulation, carries out an IP lookup, and forwards the IP packet to IP
Router 2.
• Only two IP lookups are required in getting from IP Router 1 through the
MPLS cloud to IP Router 2.
• Once the IP traffic is MPLS-encapsulated, all subsequent routing is done
using a label rather than any IP packet header-based addressing.
• MPLS provides a QoS function.
Chapter 2: SNMPv3 and Network Management
30
MPLS Concepts (cont.)
• Definition of an LSP
• LSP is comprised of the following components on the originating LER:
• A tunnel
• A cross-connect
• An out-segment
• Each LSR in the core then supports the LSP by providing the following
components:
• An in-segment
• A cross-connect
• An out-segment
• Finally, the terminating LER provides the endpoint for the LSP using the
following components:
• An in-segment
• A cross-connect
Chapter 2: SNMPv3 and Network Management
31
Summary
• SNMPv3 provides several compelling advantages
over previous versions.
• MIB browsers represent an indispensable tool for
both NMS software developers and network
managers.
• An NMS can also be arbitrarily complex with a
great many components.
• NEs are those components that combine together
to make up a managed network.
Chapter 2: SNMPv3 and Network Management
32