Transcript Management Architecture and Standards

Management Architecture and
Standards II
IACT 418 IACT 918
Corporate Network Planning
Gene Awyzio
Spring 2001
SNMP - the Management
Protocol Used for TCP/IP
SNMP includes the following key capabilities:



Get
Set
Trap
The standards do not specify


The number of management stations
The ratio of management stations to agents
SNMP - the Management
Protocol Used for TCP/IP
In general, it is prudent to have at least two
systems capable of performing the
management station functions
As SNMP is simple it can handle many agents
SNMP is designed to be an application-level
protocol that is part of the TCP/IP protocol
suite which operates over the user datagram
protocol (UDP)
SNMP - the Management
Protocol Used for TCP/IP
SNMP - the Management
Protocol Used for TCP/IP
SNMP - the Management
Protocol Used for TCP/IP
From a management station, three
types of SNMP messages are issued on
behalf of a management application:



GetRequest
GetNextRequest
SetRequest
SNMP - the Management
Protocol Used for TCP/IP
The first two are two variations of the
get function
All three messages are acknowledged
by the agent in the form of a
GetResponse message, which is passed
up to the management application
SNMP - the Management
Protocol Used for TCP/IP
An agent may issue a trap message in
response to an event that affects the MIB and
the underlying managed resources - this is
received by the manager
SNMP relies on UDP, which is connectionless
so SNMP is itself connectionless ie each
exchange is a separate transaction between a
management station and an agent
Trap - Directed Polling
Preferred strategy is:



A management station can poll all of the
agents it knows for some key information
Once the baseline is established, the
management station refrains from polling
Each agent is responsible for notifying the
management station of any unusual event
Trap - Directed Polling
These events are communicated in
SNMP messages known as traps
Once a management station is alerted
to an exception condition, it chooses to
take the appropriate action
Trap - Directed Polling
Trap-directed polling can result in
substantial savings of


Network capacity
Agent processing time
Reduces unnecessary polling of agents
by managers thus reducing
management induced network traffic
Limitations of SNMP
SNMP may not be suitable for the
management of very large networks


Each agent needs to be polled and generates trap
traffic
SNMP is not suited to retrieving large volumes of
data such as a entire routing table
SNMP traps are unacknowledged meaning the
agent generating the trap does not know if
the manager received it
Limitations of SNMP
Basic SNMP standard only provides
trivial authentication
SNMP does not directly support
imperative commands with parameters,
conditions, status and results
Limitations of SNMP
SNMP MIB model is limited not
supporting sophisticated management
queries based on object values or types
SNMP does not support manager to
manager communications ie no
mechanism for one manager to find out
about another network managers,
managed network elements
SNMPv2 :1991/1992
Networks grow larger and larger


SNMPv1 became more and more inadequate
OSI implementations and standardization were still
not ready
Network managers recognised this, so the call
went out for an extension to SNMP

in the mean time till OSI’s CMIP became available
SNMPv2 :1991/1992
One major flaw

SNMPv1 did not have any security facilities
For this reason SNMPv1 network human
managers often disabled the ‘set’ PDU
crippling the network management
facility
Adding Security
To address this problem a set of RFC’s called
‘secure SNMP’ was issued as proposed in July
1992

secure SNMP did not address other deficiencies
related to performance and functionality of
SNMPv1
SMP was also issued in July 1992 as a set of
8 documents, they were not RFC’s

They constituted a private proposal to the internet
community to upgrade SNMPv1
SMP
The proposed extensions defined in
SMP fell into three categories



Scope
Size, speed, and efficiency
Security and privacy
SMP and Secure SNMP
The ‘Internet community’ came to the
consensus that there should be a
second generation SNMP that would


include both security and functional
enhancements
enable users and vendors to make a
smooth transition from SNMPv1 to what
becomes known as SNMPv2
Adding Security
Two working groups were formed:


one for security aspects
one for all other aspects such as protocol
and management information
Work began in October 1992 to be
completed March 1993, but was
completed by end of 1992
Adding Security
The work of the two groups was
combined and published as proposed
internet standards in March 1993
SNMPv2 was revised in 1996 by an IETF
task Force

New RFC’s contained no security!
The rest of the standard experienced
minor changes
Community
The standard SNMPv2 makes use of the
SNMPv1 message wrapper, with its use
of the community concept

This “administrative framework” for
SNMPv2 is termed “community based
snmpv2” or SNMPv2c
Community
In SNMPv1 an SNMP community is a
relationship between


A SNMP agent
A set of SNMP managers
That defines authentication, access
control, and proxy characteristics
Community
In SNMPv1

Communities are defined locally within the agent
 Each community is given a unique (within the agent)
community name

The management station must keep track of and
store all the community names of each of its
managed agents
 The management stations within the community are
provided with and must use this community name in all
set and get operations with this agent

There is no reason why the same name may not
be used by different agents - as the agent uses
this name locally
Community
The SNMPv2 message is wrapped with
a PDU in a SNMPv1 format


including a version number
A community name
What Happened to the
Security?
Little enthusiasm among vendors and users
for the way in which security was specified in
the 1993 documents
When the work began on the 1996
documents, it was hoped that some minor
tune-ups to the security portion would suffice
As the effort was nearing completion it was
shown that the security portion of snmpv2
was fatally flawed!
What Happened to the
Security?
To make a long story short, there was an
extension of the deadline for completing the
new snmpv2 documents to allow time for a
new consensus to develop on a new security
specification




Deadlock occurred
No consensus reached
Time ran out
Then the plug was pulled on the process and the
new snmpv2 was issued without security
enhancements
What Happened to the
Security?
This decision had the advantage of
solidifying the specification of the many
functional enhancements found in
snmpv2, but leads onto the need for
another version of SNMP (version 3)
Standards
RFC
1901
1902
1903
1904
1905
1906
1907
1908
Title
Introduction to community-based SNMPv2
Structure of management information for SNMPv2
Textual conventions for SNMPv2
Conformance statements for SNMPv2
Protocol operations for SNMPv2
Transport mappings for SNMPv2
Management information base for SNMPv2
Coexistence between version 1 and version 2 of
the internet-standard network management
framework
SNMPv2 Enhancements
An overall change implemented in
SNMPv2 is that it can support either a
highly centralized network management
strategy or a distributed one
For distributed some systems can
operate as both a manager and a agent
SNMPv2 Enhancements
For a system acting in dual modes of
agent and manager it:


accepts commands from a superior
management system
it can also issue trap messages to the
superior manager
SNMPv2 Enhancements
The key enhancements to SNMP that
are provided in SNMPv2 fall into the
following categories:



Structure of management information
(SMI)
Manager-to-manager capability
Protocol operations
SNMPv2 Protocol operations
enhancements (over SNMPv1)
The most noticeable change in protocol
operations is the inclusion of two new PDUs:


GetBulkRequest PDU : enables the manager to
retrieve large blocks of data
efficiently --- it is
well suited to retrieving multiple rows in a table eg
routing table.
InformRequest PDU : enables one manager to
send trap type of information to another manager.
SNMPv1 and SNMPv2
coexistence
SNMPv2 was designed to co-exist with
SNMPv1
This involved two areas of the standards:


management information
protocol operations
protocol operations

Two approaches are described in the standard:
 use of proxy agents
 use of bilingual managers
For the proxy agent:
For the proxy agent:
The main point here is that
GetBulkRequest is converted to a
GetNextRequest with only the first
“row” of the table or variables being
accessible (but the device is SNMPv1
enabled so its expecting that this is the
norm)
For the bilingual manager:
For the bilingual manager:
This setup requires the manager to be
able to handle both protocols and
manager SNMPv1 and SNMPv2 agents
While SNMPv2 provided enhancements
in functionality, especially in the
manager to manager functions, the lack
of security still inhibits the secure use of
SNMP on managed networks.