1 LABORATORIO DI INFORMATICA Network Management 5. Structure of Management Information (SMIv2) 5.3. NOTIFICATION-TYPE Claudio Salati Copyright © 2001 by.

Presentazione sul tema: "1 LABORATORIO DI INFORMATICA Network Management 5. Structure of Management Information (SMIv2) 5.3. NOTIFICATION-TYPE Claudio Salati Copyright © 2001 by."— Transcript della presentazione:

1 1 LABORATORIO DI INFORMATICA Network Management 5. Structure of Management Information (SMIv2) 5.3. NOTIFICATION-TYPE Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2 2 Notifiche spontanee LInternet 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 ce niente che differenzi sintatticamente tra loro definizioni di notifiche di diverse categorie

3 3 NOTIFICATION-TYPE ASN.1-valueID NOTIFICATION-TYPE [ OBJECTS { object-type-name {, object-type-name } } ] STATUS DESCRIPTION ""-delimited-string [ REFERENCE ""-delimited-string ] ::= object-identifier current | deprecated | obsolete -- espansione macro dello statement: -- ASN.1-valueID OBJECT IDENTIFIER ::= object-identifier -- ASN.1-valueID rappresenta lidentificatore della specifica notifica spontanea

4 4 NOTIFICATION-TYPE OBJECTS sequenza ordinata degli object-type una istanza dei quali e presente nella notifica. Ovviamente nessuno di questi object-type puo avere MAX- ACCESS 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 object- instace a suo piacimento

5 5 OBJECT presenti di default in ogni notifica (RFC 1907) sysUpTime OBJECT-TYPE SYNTAXTimeTicks MAX-ACCESSread-only STATUScurrent 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 SYNTAXOBJECT IDENTIFIER MAX-ACCESSaccessible-for-notify STATUScurrent DESCRIPTION "The authoritative identification of the notification currently being sent. This variable occurs as the second varbind in every SNMPv2- Trap-PDU and InformRequest- PDU." ::= { snmpTrap 1 }

6 6 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

7 7 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

8 8 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 }

9 9 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 }

10 10 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 }

11 11 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

12 12 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 lindirizzo di rete di ciascuno di questi manager? Nel management framework di Internet non ce 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 linvio di trap da parte di un agent, ma nessuna di queste proposte ha portato a qualche risultato!

13 13 Generazione e invio di notifiche spontanee Per il momento: lagente 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, loccorrenza dellevento obbliga lagent 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

14 14 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.

15 15 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 re- initializations of the network management system." ::= { snmp 30 } -- continua nella pagina successiva

16 16 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

17 17 Notifiche spontanee manager manager SNMPv2 introduce la possibilita di interazioni manager- manager. 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 dellarchitettura Per come e definita, linterazione InformRequest-Response consente solo ai due manager di scambiarsi informazioni sul valore conosciuto di una lista di oggetti.