.. _snmptraps: **************************************************************************************************** Trap SNMP **************************************************************************************************** .. contents:: Contenuti Introduzione ============ Sanet puo' ricevere TRAP SNMP, storicizzarle all'interno del proprio Log ed eventualmente *cercare* di processarle. La ricezione delle trap e' delegata ad un processo di appoggio **NON ATTIVO DI DEFAULT**. Flusso di ricezione =================== Il flusso di elaborazione e' il seguente: 1. La trap viene ricevuta dal processo delegato alla ricezione delle TRAP 2. La trap viene storicizzata 3. Sanet cerca di associare la trap ad un nodo di sanet e processare la trap con un datagroup *passivo*. 4. Eventuali allarmi generati dal datagroup (dalle sue condition) vengono inviati ad entables :: SANET SERVER +------------------------------------------------+ | | | (1) +-------+ (3) (4) | switch ------*trap*-------> | trapd |------> datagroup------*alarm*-------> ENTABLES ------> MAIL | +-------+ | | | | | | | (2) | | | | `----------------`---> LOG | | | +------------------------------------------------+ Limiti della gestione delle Trap SNMP ========================================================================================== Elmenti monitorabili ------------------------------------------------------- Al momento il sistema di gestione della trap **non consente di sfruttare il meccanismo di calcolo automatico dell'ifindex/stindex/swrunindex/devindex**. (Vedere ad esempio :ref:`monitoring-concepts-ifindex`) Questo significa che e' possibile associare le trap ricevute **solo** a *nodi* (e i loro datagroup) in maniera automatica. **NOTA**: Tentare di associare trap a nodi o interfacce e' possibile con sistemi non facilmente automatizzabili. Per questo motivo tutti i datagroup *passivi* che si vogliono implementare **devono** essere implementati per essere **applicabili solo** a *nodi* (o *node template*). Limite a cosa e' possibile gestire nelle espressioni ---------------------------------------------------------------------- Le espressioni di *datasource*/*condition* di datagroup passivi sono *limitate*. 1. Non e' possibile chiedere valori di OID diverse da quelle contenute nella *varbind list* della TRAP. 2. Non e' possibile effettuare SNMP Walk o utilizzare altre funzioni che si basano su operazioni di walk snmp. 3. L'accesso a simboli speciali (*ifindex*, *linked_ifindex*, *cluster instance*, ecc) produrra eccezioni con conseguente stato *uncheckable*. Trap SNMP non gestite -------------------------------- Sanet potrebbe non essere in grado di processare le trap in input per due motivi: 1. Non riesce ad associare l'indirizzo IP sorgente della trap a nessun nodo. (Vedi :ref:`snmptrap-node-association`) 2. Non riesce a processare la trap attraverso nessun datagroup *passivo* definito per quel nodo. ( Vedi :ref:`snmptrap-configure-datagroup` ). Quando una di queste due condizioni si verifica Sanet invia una mail per segnalare la mancata gestione delle trap. Si veda il paragrafo :ref:`snmptrap-config-strange-traps-notification` per i dettagli. .. _snmptrap-node-association: Associazione con i nodi di sanet -------------------------------- Le TRAP SNMP contengono solo l'indirizzo IP sorgente del noto che ha generato la trap. Sanet cerca di *individuare* a quale nodo associare la trap in fase di memorizzazione del log. Se Sanet non riesce ad individuare il nodo, la trap viene solo semplicemente memorizzata con indicazione *solo* dell'indirizzo IP sorgente. Algoritmo per trovare il nodo di sanet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Calcola il FQDN (Full Qualified Domain Name) dall'indirizzo IP sorgente della trap 2. Calcola il DN (Domain Name) dell'host su cui e' in esecuzione Sanet 3. Rimuovi il DN dal FQDN della trap. 4. Cerca in sanet il nome del nodo corrispondente. Configurazione ========================================================================================== Abilitare la ricezione delle trap ---------------------------------------- Indicare nel file di configurazione l'indirizzo su cui mettere in ascolto Sanet per le TRAP. Esempio: :: SNMPTRAP_LISTEN = ('0.0.0.0', 162) .. _snmptrap-configure-datagroup: Configurare un datagroup per processare le trap -------------------------------------------------------------------------------- Per fare in modo che un datagroup venga utilizzato da Sanet per processare delle TRAP bisogna: * Configurare il datagroup come *passivo* impostando il *min-period* a *zero*. * Configurare il campo *passive-match* del datagroup inpostando la OID della trap da processare. Esempio: :: datagroup-template dgtrap ... passive-match 1.3.6.1.6.3.1.1.5.3 minperiod 0 ... exit .. important:: Specificando il *passive-match* come *espressione regolare* e' possibile fare match di OID parziali o sub-OID. Esempio: :: datagroup-template dgtrap ... passive-match regex:^1.3.6.1.6.* minperiod 0 ... exit .. _snmptrap-config-strange-traps-notification: Configurazione Notifica delle TRAP non gestite -------------------------------------------------------------------------------- Nel file di configurazione di Sanet (settings.py) si possono specificare i parametri (from, to, body) per l'invio di mail in due casi: * Trap ricevute ma non associate a nessun nodo. Sono definite trap *sconosciute* o *unknown*. * Trap ricevute, associate ad un nodo con successo, ma non processate da alcun datagroup. Sono definite trap *non gestite* o *unmanaged*. Nel soggetto/corpo della mail e' possibile utilizzare delle *wildcard* per fornire maggiori dettagli sulla trap segnalata. :: SNMPTRAP_MAIL_CONF = { 'from': 'sanet.trapd@localhost', # # Settings for TRAPs from unknown hosts # 'unknown': { # You can use the following wildcard inside the subject/body text: # # {{receive_time}} = timestamp # {{source_ip}} = Source IP # {{trap_oid}} = TRAP OID # {{trap_msg}} = Verbose TRAP description # 'to' : 'root@localhost', 'subject' : '[sanet trapd] Trap from unknown host {{source_ip}}', 'body' : 'Received SNMP Trap at {{receive_time}}.\n\n{{trap_msg}}s', }, # # Settings for unhandled TRAPs linked to sanet nodes # 'unmanaged': { # Default notification address. If a node specifies the 'notify-address' # field, the field will be used instead of this default. 'to' : 'root@localhost', # You can use the following wildcard inside the subject/body text: # # {{receive_time}} = timestamp # {{source_ip}} = Source IP # {{trap_oid}} = TRAP OID # {{trap_msg}} = Verbose TRAP description # {{sanet_node}} = Sanet node name # 'subject' : '[sanet trapd] Unmanaged TRAP from {{source_ip}} for node {{sanet_node}}', 'body' : 'Received SNMP Trap at {{receive_time}}.\n\n{{trap_msg}}', } } Trap non gestite e notify-address -------------------------------------------------------------------------------- Se la configurazione di un nodo specifica l'attributo *notify-address*, le trap *unmanaged* vengono inviate all'indirizzo indicato mentre l'indirizzo specificato in configurazione nella sezione 'unmanaged' viene ignorato. Gestione trap non ricevute e stato dei datagroup ================================================ E' possibile che le Trap non vengano ricevute. Questo potrebbe lasciare un datagroup (e le sue condition) in uno stato *inconsistente*. E' possibile forzare lo stato *UP* o *DOWN* di un intero datagroup o di alcune sue condition con il comando: :: sanet-manage force_dg_status [options] Le opzioni disponibili sono: :: --status STATUS Codice dello stato: UP o DN --tenant TENANT Nome del tenant. Default: il tenant primario --reason REASON Verbstatus che comparira' nei log --conditions CONDITIONS Elenco coi nomi delle condition da aggiornare. Default: tutte. -l LOGLEVEL Livello di verbosita dell'output Esempio: :: sanet-manage force_dg_status 'localhost;;dgtrap' --reason "test" --status UP Trap e agenti remoti ==================== E' possibile configurare gli agenti remoti per ricevere le trap e "inoltrarle" al server centrale. Questo permette di ricevere trap anche da apparati che non sono in grado di comunicare direttamente con il server centrale. :: switch -----*TRAP*--------------------------+ +----> +--------+ +----------+ | SANETD |----> | ENTABLES | +------------+ .....> +--------+ +----------+ switch -----*TRAP*----->|remote agent|....... +------------+ Per ottenere questo risultato e' necessario: * Abilitare le trap SNMP sul server centrale (anche se potrebbe non essere in grado di riceverle) * Abilitare le trap SNMP sugli agenti remoti. Vedi sezione: :ref:`remote-agent-trap-snmp`.