ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
5. Structure of Management Information (SMIv2)
5.3. NOTIFICATION-TYPE
Claudio Salati
Copyright © 2001 by Claudio Salati
1
Notifiche spontanee
•
L’Internet management framework prevede due categorie di
notifiche spontanee
1. Notifica agent  manager (trap)
• non-confermata
• PDU utilizzati: SNMPv2-Trap-PDU
2. Notifica manager  manager
• Confermata
• PDU utilizzati: InformRequest-PDU, Response-PDU
•
In ogni caso il contenuto di una notifica spontanea e’ definito
tramite lo stesso statement: NOTIFICATION-TYPE
•
Non c’e’ niente che differenzi sintatticamente tra loro definizioni
di notifiche di diverse categorie
2
NOTIFICATION-TYPE
ASN.1-valueID NOTIFICATION-TYPE
[ OBJECTS
{ object-type-name { , object-type-name } } ]
STATUS
<status>
DESCRIPTION
""-delimited-string
[ REFERENCE
""-delimited-string ]
::= object-identifier
<status> 
current | deprecated | obsolete
-- espansione macro dello statement:
-- ASN.1-valueID OBJECT IDENTIFIER ::= object-identifier
-- ASN.1-valueID rappresenta l’identificatore della specifica notifica spontanea
3
NOTIFICATION-TYPE
•
OBJECTS
• sequenza ordinata degli object-type una istanza dei quali e’
presente nella notifica.
• Ovviamente nessuno di questi object-type puo’ avere MAXACCESS not-accessible (ne’ puo’ quindi essere di categoria
diversa da semplice o colonna).
• Quando gli object-type citati sono di categoria colonna (e
quindi ammettono istanze multiple) la clausola
DESCRIPTION deve indicare come individuare le istanze
che devono essere presenti nella notifica.
• In ogni caso, anche in assenza della clausola OBJECTS,
ogni notifica contiene come prime due object-instance
sysUpTime.0 e snmpTrapOID.0.
• Dopo quelle previste esplicitamente dalla definizione della
notifica, un agent puo’ inserire nella notifica altre objectinstace a suo piacimento
4
OBJECT presenti di default in ogni notifica (RFC 1907)
sysUpTime OBJECT-TYPE
SYNTAX
TimeTicks
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The time (in hundredths of a second) since the network
management portion of the system was last re-initialized."
-- This variable occurs as the first varbind in every SNMPv2-Trap-PDU
-- and InformRequest- PDU.
::= { system 3 }
snmpTrapOID OBJECT-TYPE
SYNTAX
OBJECT IDENTIFIER
MAX-ACCESS
accessible-for-notify
STATUS
current
DESCRIPTION
"The authoritative identification of the notification currently being sent.
This variable occurs as the second varbind in every SNMPv2Trap-PDU and InformRequest- PDU."
::= { snmpTrap 1 }
5
NOTIFICATION-TYPE - identificazione specifica
•
Il PDU di trap SNMPv2 e' identico come struttura a tutti gli altri
PDU del protocollo:
 SNMPv2-Trap-PDU ::=
[7] IMPLICIT PDU
•
Non prevede quindi alcun campo dedicato all'identificazione
della specifica notifica che e' stata generata.
•
E' solo il valore dell'object-instance snmpTrapOID.0
(che e' obbligatoriamente presente come secondo VarBind del
campo variable-bindings)
che indica quale specifico notification-type e' convogliato
dall'SNMPv2-Trap-PDU
6
NOTIFICATION-TYPE
•
STATUS
indicazione dello stato di utilizzabilita' del notification-type
•
DESCRIPTION
una descrizione in linguaggio naturale del notification-type, e in
particolare della sua semantica specifica.
Quando rilevante deve consentire di identificare le specifiche
object-instance presenti nella notifica.
•
REFERENCE
se il notification-type e' in qualche modo correlato ad un altro
notification-type, questa clausola consente di riferirlo tramite una
indicazione in linguaggio naturale
7
NOTIFICATION-TYPE: esempio da RFC 1907
coldStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A coldStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself and that its
configuration may have been altered."
::= { snmpTraps 1 }
warmStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A warmStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself such that its
configuration is unaltered."
::= { snmpTraps 2 }
8
NOTIFICATION-TYPE: esempio da RFC 1907
authenticationFailure NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"An authenticationFailure trap signifies that the SNMPv2
entity, acting in an agent role, has received a protocol
message that is not properly authenticated. While all
implementations of the SNMPv2 must be capable of
generating this trap, the snmpEnableAuthenTraps object
indicates whether this trap will be generated."
::= { snmpTraps 5 }
9
NOTIFICATION-TYPE: esempio da RFC 1573
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 entity, acting in agent
role, has detected that the ifOperStatus object for one of its
communication links is about to transition into the down state."
::= { snmpTraps 3 }
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMPv2 entity, acting in an agent
role, has detected that the ifOperStatus object for one of its
communication links has transitioned out of the down state."
::= { snmpTraps 4 }
10
NOTIFICATION-TYPE: esempio da RFC 1573
Commento
• Notare che la clausola DESCRIPTION non fornisce alcuna
regola esplicita che consenta di identifcare quali istanze degli
object-type citati nella clausola OBJECTS debbano essere
presenti.
• Intuitivamente si capisce pero’ che sono quelle relative alla riga
della tabella ifTable corrispondente al link che sta per subire o ha
subito (a seconda della notifica) una transizione di stato
operativo.
• La semantica di queste notifiche e’ stata ampiamente
rimaneggiata in RFC 2233
• Vedi le nuove definizioni delle notifiche
• Vedi sez. 3.1.12, 3.1.13, 3.1.14, 3.1.15
11
Generazione e invio di notifiche spontanee
•
Se capita uno degli eventi previsti dagli statement
NOTIFICATION-TYPE delle MIB supportate, cosa deve fare un
agent?
• La MIB gli indica un dovere o solo una possibilita’ di
generare una trap?
• E verso quale/i manager generarla?
• E quale e’ l’indirizzo di rete di ciascuno di questi manager?
•
Nel management framework di Internet non c’e’ niente di simile
alla classe eventForwandingDiscriminator (X.721) del framework
TMN!
•
In realta’ ci sono state proposte per MIB capaci di consentire a
un manager di controllare l’invio di trap da parte di un agent, ma
nessuna di queste proposte ha portato a qualche risultato!
12
Generazione e invio di notifiche spontanee

Per il momento: l’agente deve conoscere per altra via a quali
manager inviare trap, e quali sono i loro indirizzi di rete.
E' attraverso la consolle locale del sistema gestito che vengono
registrati sull'agent i manager interessati alle notifiche ed i loro
indirizzi di rete.
•
•
In assenza di meccanismi di controllo la regola generale e’:
•
Quando una MIB definisce una notifica correlata ad un
certo evento, l’occorrenza dell’evento obbliga l’agent a
generare trap
•
“The destination(s) to which a SNMPv2-Trap-PDU is sent is
determined in an implementation-dependent fashion by the
SNMPv2 entity.” (RFC 1905)
Quanto detto per le notifiche generate da un agent si applica
anche a quelle generate da manager
13
Generazione e invio di notifiche spontanee
•
caso per caso, e' possibile che una MIB che definisce una notifica
definisca anche uno o piu' oggetti destinati a controllarne la
generazione
• in questo caso,
• e se gli attributi di controllo della generazione della notifica
sono accedibili anche in scrittura
• un manager e' in grado di controllare la generazione della
notifica
•
notare che il controllo di generazione della notifca si applica
in modo globale e uniforme per tutti i manager destinazione
•
Esempi di notifiche la cui generazione e', secondo la relativa MIB,
controllabile da manager:
• trap authenticationFailure di RFC 1907 (vedi seguito).
• trap di link up/down di RFC 1573/2233 (controllate
individualmente per ciascuna interfaccia tramite l'object-type
colonna ifLinkUpDownTrapEnable). Vedi lez. 9.
14
Controllo della generazione di notifiche spontanee
-- da RFC 1907
snmpEnableAuthenTraps OBJECT-TYPE
SYNTAX
INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"Indicates whether the SNMP entity is permitted to generate
authenticationFailure traps.
The value of this object overrides any configuration
information; -- configurazioni effettuate da consolle locale
as such, it provides a means whereby all authenticationFailure
traps may be disabled.
Note that it is strongly recommended that this object be stored
in non-volatile memory so that it remains constant across reinitializations of the network management system."
::= { snmp 30 }
-- continua nella pagina successiva
15
Controllo della generazione di notifiche spontanee
authenticationFailure NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"An authenticationFailure trap signifies that the SNMPv2 entity, acting
in an agent role, has received a protocol message that is not properly
authenticated.
While all implementations of the SNMPv2 must be capable of
generating this trap, the snmpEnableAuthenTraps object
indicates whether this trap will be generated.
::= { snmpTraps 5 }
•
quando si dice che "The value of this object overrides any
configuration information" ci si riferisce a configurazioni dell'agent
effettuate tramite consolle locale
•
ogni notifica dovrebbe (come nel caso di authenticationFailure)
definire nel suo behaviour se e come la sua generazione e'
controllabile dal manager
16
Notifiche spontanee manager  manager
•
SNMPv2 introduce la possibilita’ di interazioni managermanager.
•
Queste interazioni sono pero’ limitate alla notifica di eventi
•
Non sono in realta’ definite delle MIB per descrivere un modello
di interazione manager–manager
(RFC 1451"Manager-to-Manager MIB" ha solo valore storico)
•
Non e’ definita una architettura layerizzata di gestione come nel
TMN, dove ad esempio
• Si definisce una ripartizione delle funzioni di gestione tra i
diversi layer
• Si estrapola il modello manager-agent per descrivere le
interazioni tra tutti i livelli dell’architettura
•
Per come e’ definita, l’interazione InformRequest-Response
consente solo ai due manager di scambiarsi informazioni sul
valore conosciuto di una lista di oggetti.
17