RETI LOCALI Parte Sesta NETWORK MANAGEMENT Gianfranco Prini

RETI LOCALI Parte Sesta NETWORK MANAGEMENT Gianfranco Prini DSI - Università di Milano gfp@dsi. unimi. it

NOTA DI COPYRIGHT • • • Queste trasparenze (slide) sono protette dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo e il copyright delle slide (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica, testo, tabella, disegno) sono di proprietà dell'autore. Le slide possono essere riprodotte e utilizzate liberamente dagli istituti di ricerca, scolastici e universitari italiani afferenti al Ministero della Pubblica Istruzione e al Ministero dell'Università e della Ricerca Scientifica e Tecnologica per scopi istituzionali e comunque non a fini di lucro. In tal caso non è richiesta alcuna autorizzazione. Ogni altro utilizzo o riproduzione, completa o parziale ( ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di calcolatori e a stampa), sono vietati se non preventivamente autorizzati per iscritto dall'autore. L'informazione contenuta in queste slide è ritenuta essere accurata alla data riportata nel frontespizio. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, etc. In ogni caso essa è soggetta a cambiamenti senza preavviso. L'autore non assume alcuna responsabilità per il contenuto delle slide (ivi incluse, ma non limitatamente, la correttezza, la completezza, l'applicabilità, l'adeguatezza per uno scopo specifico e l'aggiornamento dell'informazione). In nessun caso possono essere rilasciate dichiarazioni di conformità all'informazione contenuta in queste slide. In ogni caso questa nota di copyright non deve mai essere rimossa e deve essere riportata fedelmente e integralmente anche per utilizzi parziali.

ARGOMENTI • Inquadramento generale • Aree funzionali • Sistemi e piattaforme • Protocolli e standard

NETWORK MANAGEMENT INQUADRAMENTO GENERALE

NETWORK MANAGEMENT Processo consistente nel controllare una rete complessa al fine di massimizzare la sua efficienza e la sua produttività

DEFINIZIONI E PERIMETRO • Apparati: l'insieme delle interfacce di comunicazione delle macchine (ma non le macchine medesime) e dei vari dispositivi di interconnessione (esclusi quelli del fornitore di servizi di TLC) • Moduli: l'insieme degli apparati e delle loro componenti software, ivi incluse le porzioni dei sistemi operativi del caso • Rete: l'insieme dei moduli e dei canali trasmissivi che collegano gli apparati

CONFIGURAZIONE: COME NASCE E COME EVOLVE (1) • Costruzione: determinazione del tipo di connettività desiderata, selezione dei moduli piu adatti a realizzarla, loro installazione e configurazione • Manutenzione: sostituzione di moduli guasti o che richiedono aggiornamenti di release, o che richiedono upgrade • Espansione: aggiunta di moduli per connettere nuove utenze, oppure per offrire nuovi servizi o maggiore banda

CONFIGURAZIONE: COME NASCE E COME EVOLVE (2) • Ottimizzazione: riconfigurazione della rete sulla base dell'analisi dei profili di traffico o delle esigenze di affidabilità e/o di sicurezza, anche sfruttando la disponibilità di sempre nuovi apparati e di servizi sempre più sofisticati • Diagnosi: isolamento di guasti dovuti a malfunzionamenti localizzati o a cattiva configurazione degli apparati, oppure analisi post mortem del problema che ha portato a una situazione di disastro

OBBIETTIVI TECNICI • Garantire il buon funzionamento di una rete (fonia e dati), conservando traccia dei principali eventi a futura memoria • Conservare un'informazione accurata sulla configurazione della rete al fine di consentire ai gestori di visualizzarla e di modificarla con procedure semplici • Segnalare l'insorgere di situazioni di allarme, o che comunque richiedono un intervento correttivo del gestore

OBBIETTIVO ORGANIZZATIVO Sostituire l'operatore umano nella gestione della rete, eseguendo per quanto possibile automaticamente i compiti di routine, consentendo al network engineer di dedicarsi ad attività a più alto valore aggiunto, quali la pianificazione e lo sviluppo della rete, l'analisi delle prestazioni e dell'affidabilità, etc.

NETWORK MANAGEMENT AREE FUNZIONALI

AREE FUNZIONALI Cinque aree funzionali identificate dal Network Management Forum (ISO) 1 - Fault Management 2 - Configuration Management 3 - Security Management 4 - Performance Management 5 - Accounting Management

FAULT MANAGEMENT • Processo consistente nella gestione dei malfunzionamenti e dei guasti • Consiste di tre passi – Individuazione del problema – Isolamento del problema – Soluzione del problema • Esempio: individuare qual'è l'apparato guasto che non consente a un utente di effettuare una connessione (meglio ancora, individuare il guasto prima che l'utente se ne accorga)

CONFIGURATION MANAGEMENT • Processo consistente nell'individuare e nel configurare gli apparati critici per il funzionamento della rete • Esempio: individuare tutti i bridge per i quali si richiede l'installazione di patch software, operazione da effettuare con gradualità, su un arco di molti giorni, e conservando traccia di quanto è stato fatto fino a un certo punto e quanto ancora resta da fare

SECURITY MANAGEMENT • Processo consistente nel controllare l'accesso all'informazione contenuta in apparecchiature connesse alla rete • Esempio: limitare l'accesso alla rete (o a sue sottoreti) da parte di utenti o di sistemi che non si ritengono affidabili, oppure correlare i tempi in cui si sono verificati tentativi di intrusione in uno dei sistemi critici con i periodi di login dei vari utenti, riportando all'operatore ogni attività anomala successiva

PERFORMANCE MANAGEMENT • Processo consistente nel misurare le prestazioni dei moduli hardware e software e dei canali trasmissivi • Esempio: misura di throughput totale, percentuali di utilizzo, tassi di errore, tempi di risposta, latenza, etc. , anche al fine di individuare profili di traffico che consentano di anticipare eventi critici (p. es. saturazione di canali) e quindi di adottare le contromisure del caso

ACCOUTING MANAGEMENT • Processo consistente nel tener traccia dei profili di utilizzo della rete da parte dei singoli utenti (o di gruppi di utenti) onde garantire che questi dispongano di risorse adeguate, eventualmente ridefinendo i diritti di accesso alla rete • Esempio: in caso di saturazione di un server di rete, individuare se un utente o un gruppo di utenti vi contribuisce per una percentuale significativa, se del caso installando un server dedicato

NETWORK MANAGEMENT SISTEMI E PIATTAFORME

SISTEMI DI NETWORK MANAGEMENT • Approccio storico: utilizzo di strumenti specializzati per singoli sottosistemi di comunicazione (modem, router, etc. ) • Esigenza di unificare strumenti spesso incompatibili e/o non integrabili • Architettura: centralizzata, gerarchica o distribuita • Piattaforma: fornisce le funzionalità di base per gestire un'ampia gamma di apparati di rete

FUNZIONI E COMPONENTI DELLA PIATTAFORMA (1) • Console grafica (GUI) di interfaccia • Mappatura automatica e "animata" – "Scoperta" degli apparati presenti in rete (autodiscovery) – Rappresentazione grafica della topologia (automapping) – Stato della console coerente con lo stato degli apparati • Sistema di gestione delle basi di dati • Metodi di interrogazione degli apparati – Formati standard dell'informazione di management (MIB) • Sistema di menu personalizzabile • Log degli eventi in formato testo

FUNZIONI E COMPONENTI DELLA PIATTAFORMA (2) • Strumenti per il tracciamento di grafici • Librerie per la programmazione delle applicazioni (API) – Consente l'accesso da programma (vs. da console) alle funzioni della piattaforma, al fine di automatizzare le funzioni di gestione di mano in mano che esse diventano routinarie • Meccanismi per garantire la sicurezza – Il database di network management è un bocconcino prelibato per gli hacker e per i cracker, visto che contiene tutte le informazioni vitali per il funzionamento della rete – Devono essere addizionali rispetto ai meccanismi offerti dal sistema operativo

PRINCIPALI PIATTAFORME COMMERCIALI • • Sun. Net Manager (Sun. Connect) Open. View (Hewlett-Packard) Net. View (IBM), basata su Open. View Star. Sentry (AT&T) • Differenziate nei dettagli, tutte quante forniscono le funzionalità di base necessarie per il network management

NETWORK MANAGEMENT NETWORK MANAGEMEMT: PROTOCOLLI

RUOLO DEI PROTOCOLLI E DEI GESTORI DELLA RETE • I protocolli non stabiliscono procedure o norme perseguire obbiettivi di gestione della rete, ma si limitano a fornire strumenti per acquisire dati e per monitorare/configurare apparati • L'analisi dei dati ricade comunque sui gestori della rete e sulla loro capacità di scrivere eventualmente applicazioni significative per il loro trattamento

PROTOCOLLI DI NETWORK MANAGEMENT • Scopo: acquisire dagli apparati tutte le informazioni utili alla migliore gestione della rete, e inviare agli apparati tutte le istruzioni del caso • Protocolli di complessità differenziata – Bassa: definire un formato comune dei dati e consentire un accesso semplificato alle informazioni – Media: come sopra, ma proteggendo i parametri critici e impedendo a chiunque non autorizzato di modificarli – Elevata: eseguire le procedure di network management direttamente sugli apparati remoti, rendendo la gestione degli apparati indipendente dal protocollo di management

PROTOCOLLI: DELL'ARTE STATO • SNMP (Simple Network Management Protocol) è un po' di più di un semplice strumento di acquisizione di dati: esso dispone di funzionalità di monitoraggio e di aggiornamento di parametri di rete • SNMPv 2 migliora grandemente SNMP • La limitatezza di questi protocolli non consente oggi di realizzare applicazioni di rete avanzate altrimenti possibili – Obbiettivo: migliorare sia la tecnologia che i protocolli

STRUMENTI PRIMORDIALI Servizio di Echo di ICMP (Internet) – Ogni host che riceve una Echo Request conforme al protocollo ICMP è tenuto a inviare una Echo Reply – Ping incorpora una Echo Request e una Echo Reply, e nelle sue implementazioni normalmente fornisce anche indicazioni sul turnaround time e sul numero di pacchetti perduti (o, meglio, di mancate Replya Request emesse) – La mancata ricezione di una Reply non necessariamente implica una mancanza di connettività: è possibile che sia andato perduto il messaggio di Request o quello di Reply • Meccanismo di poll utilissimo, ma non offre funzionalità di push, assai più utili per una gestione proattiva della rete

PROTOCOLLI: ESEMPI DI RICHIESTE ELEMENTARI • Servizi di query – – Nome dell'apparato Versione del software dell'apparato Numero di interfacce dell'apparato Numero di pacchetti per secondo "visti" da un' interfaccia • Servizi di configurazione – – Nome dell'apparato Indirizzo di rete dell'apparato Stato operativo di un'interfaccia dell'apparto Stato operativo dell'aparato • Rappresentazione dell'informazione indipendente dal particolare apparato

MIB: MANAGEMENT INFORMATION BASE • Definizione rigorosa dell'informazione accessibile attraverso un protocollo • Dati in formato strutturato e gerarchico – RFC 1065 - Structure and Identification of Management Information for TCP/IP-based Internets » Evoluto nello standard RFC 1155 – RFC 1066 - Prima versione di MIB per reti TCP/IP (MIB-I) » Evoluto nello standard RFC 1156 • Introduce la possibilità di estendere lo standard per trattare altri paramentri (e. g. l'utilizzo della CPU di controllo dell'apparato) – RFC 1158 - Seconda versione di MIB (MIB-II) » Evoluto nello standard RFC 1213 • Ulteriori MIB focalizzati per tecnologia

TIPI DI DATO DEFINITI DA RFC 1155 (SMI) • Network Address - Indirizzo appartenente a una famiglia di protocolli (definito solo IP) • Ip. Address - Indirizzo IP (32 bit) • Counter - Intero non negativo che può crescere da 0 a 232 -1 • Gauge - Idem, ma che può anche decrescere • Time. Ticks - Intero non negativo, esprime un intervallo in centesimi di secondo a decorrere da un itante predefinito • Opaque - Sintssi arbitraria, usata per il testo

PROTOCOLLO SNMP • Proposto inizialmente come RFC 1067, poi come RFC 1098, e definitivamente approvato come standard RFC 1157 • Modello client-server – SNMP Station: modulo che emette una richiesta » Get-Request per richiedere informazioni all'Agent » Get-Next-Request per richiedere righe successive di tabelle dell'Agent (ritorna errore a fine tabella) » Set-Request per configuarare parametri dell'Agent – SNMP Agent: modulo che formula la risposta » Get-Response per fornire informazioni alla Station » Trap per riportare un evento a una Station predefinita

TIPI DI TRAP • Coldstart - Indica che l'apparato si sta reinizializzando con una nuova configurazione o con una nuova release del protocollo, oppure che l'apparato è stato appena alimentato • Warmstart - Idem, ma conservando configurazione e release di protocollo precedente, oppure come conseguenza di un reset dell'Agent dell'apparato • Link down, Link up - Indicano la sopravvenuta caduta e il sopravvenuto ripristino di un link • Failure of authentication - Indica che l'Agent ha ricevuto una richiesta non autenticabile • EGP neighbour loss - Indica la sopravvenuta irraggiungibilità di un host contiguo nel protocollo EGP • Enterprise specific - Definibile dal costruttore

ASPETTI DI SICUREZZA, EFFICIENZA E APPLICABILITA' • Un Agent può richiedere alla Station di inviare una password ad ogni richiesta – Le password sono dette community string – Possono essere differenziate (e. g. su base R/O o R/W) – Vengono inviate in chiaro sulla rete • SNMP è inefficiente nella gestione di tabelle di grandi dimensioni – Il download di una riga di tabella richiede la trasmissione di un totale di 8 pacchetti – Oggi si gestiscono tabelle anche con migliaia di righe • Standardizzato solo per reti IP – Altre architetture di rete lo implementano, o usano proxy

PROTOCOLLO SNMPv 2 RISPETTO A SNMPv 1 (1) • Ridefinizione e aggiunta di tipi di dato per superare problemi di wrapping – Counter e Gauge ribattezzati Couter 32 e Gauge 32 – Couter 64 - interi non negativi compresi tra o e 264 -1 – Nsap. Address - indirizzi NSAP del Network Layer OSI • Aggiunta di comandi per nuovi servizi – Get. Bulk. Request - per richiedere una intera tabella – Inform. Request - richiesta di informazioni da parte un network manager a un altro network manager • Supporto per protocolli aggiuntivi – Apple. Talk (Apple), IPX (Novell) e CLNS (OSI) di

PROTOCOLLO SNMPv 2 RISPETTO A SNMPv 1 (2) • Aggiunta di meccanismi di crittografia e di autenticazione dei messaggi • Possibilità di garantire a un manager solamente l'accesso a porzioni di MIB • Revisione completa di MIB, con loro classificazione in 5 gruppi – Statistiche SNMPv 2, statistiche SNMPv 1, risorse di un oggetto (operazioni dinamiche ammesse), trap e set • Compatibilità tra le due versioni – Gli apparati che implementano solo SNMPv 1 non rispondono a richieste SNMPv 2 (sono riconoscibili)

RMON • RFC 1757 - Remote Network Monitoring Information Base – Proposto inizialmente come RFC 1271 – Un apparato conforme a RMON raccoglie informazioni sul segmento (o sui segmenti) di rete a cui esso appartiene – Informazioni classificate in 9 gruppi: Statistics, History, Alarm, Host. Top. N, Matrix, Filter, Packet Capture, Event • Standard molto articolato, definisce le procedure per raccogliere informazioni di ogni tipo e di notevole dettaglio sulle attività di rete da molti punti di vista