This is an old revision of the document!
În cadrul acestui laborator vom folosi următoarea topologie formată din două rutere CISCO (R1
și R2
) și două mașini virtuale (gateway
și monitor
). Acestea sunt conectate conform schemei de mai jos:
Vom rula o masină virtuală în cloud-ul facultății. Pentru a porni o astfel de masină urmăriți tutorialul de la această adresă. Când creați instanța de mașină virtuală (în fereastra “Launch instance”):
Availability zone
să alegeți CI
sau hp
.Instance Boot Source
să alegeți Boot from Image
.Image Name
(apărută după ce efectuați pasul de mai sus) să alegeți imaginea SAISP Template v1
.
Flavor
alegeti m1.medium
sau c1.medium
Pentru a pregăti configurația de laborator, pe mașina virtuală folosiți comenzile următoare din contul utilizatorului student
:
student@mjolnir:~/saisp$ cd saisp/ student@mjolnir:~/saisp$ wget --user=user-curs --ask-password http://repository.grid.pub.ro/cs/saisp/laboratoare/lab-03.zip student@mjolnir:~/saisp$ unzip lab-03.zip
În urma dezarhivării rezultă două fișiere imagine KVM (format qcow2
, monitor.qcow2
și gateway.qcow2
), directorul cisco/
și un script de pornire a topologiei (lab03-start
). Imaginea de bază base.qcow2
este deja în directorul saisp/
și este baza pentru celelalte două fișiere: gateway.qcow2
și monitor.qcow2
.
Pentru pornirea topologiei de mai sus, rulați scriptul lab03-start
:
student@mjolnir:~/saisp$ ./lab03-start
Pentru accesarea celor două mașini (gateway
și monitor
) folosiți SSH către adresele IP aferente fiecăreia. Pentru conectarea la mașina virtuală pentru gateway
folosiți comanda
student@mjolnir:~/saisp$ ssh -l root 192.168.1.3
iar pentru conectarea la monitor
folosiți comanda
student@mjolnir:~/saisp$ ssh -l root 192.168.1.4
Pentru accesarea celor două rutere CISCO (R1
și R2
) folosiți telnet
către adresele IP aferente fiecăruia. Pentru conectarea la ruterul R1
folosiți comanda
student@mjolnir:~/saisp$ telnet 192.168.1.1
iar pentru conectarea la R2
folosiți comanda
student@mjolnir:~/saisp$ telnet 192.168.1.2
Parola pe cele două mașini virtuale este student
atât pentru utilizatorul root
cât și pentru utilizatorul student
. Pentru cele două rutere parola de enable
este student
.
Înainte de a implementa o soluție de monitorizare centralizată, trebuie să ne asigurăm că ceasurile tuturor sistemelor din rețea sunt sincronizate. În caz contrar, evenimentele monitorizate nu vor putea fi corelate.
Protocolul care realizeaza acest lucru este NTP
(Network Time Protocol). De obicei, o stație are rolul de server NTP, iar echipamentele sunt clienți NTP. În topologia prezentată anterior stația monitor
va avea rol de server de NTP, iar ruterele R1
și R2
și stația gateway
vor avea rolul de clienți.
În sistemele Debian-base, pachetul ntp
conține atât serverul, cât și clientul de NTP. Funcționalitatea implicită este următoarea:
UDP 123
.
Pe ambele stații Linux vom instala pachetul ntp
:
root@monitor:~# apt-get install ntp root@gateway:~# apt-get install ntp
Pe gateway
configurăm serviciul NTP să foloseasca stația monitor
ca server de NTP. În fișierul /etc/ntp.conf
comentăm toate liniile de încep cu server
și adăugăm linia server 192.168.1.4
. Resetați serviciul ntp
:
root@gateway:~# cat /etc/ntp.conf |grep 192.168 server 192.168.1.4 iburst root@gateway:~# /etc/init.d/ntp restart [ ok ] Stopping NTP server: ntpd. [ ok ] Starting NTP server: ntpd.
Pentru a lista toate serverele NTP folosite, vom utiliza comanda ntpq
:
root@gateway:~# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.1.4 89.36.18.21 3 u 50 64 1 0.373 5.896 0.081
Pentru a configura ruterul R1
să aibă rol de client NTP, vom specifica adresa serverului în modul global de configurare:
R1>enable Password: R1#conf t R1(config)# ntp server 192.168.1.4
Verificarea funcționării protocolului se realizează prin comenzi de tip show
:
R1#show clock .12:57:55.421 UTC Sun Mar 9 2014
R1#show ntp status Clock is synchronized, stratum 3, reference is 192.168.1.4 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18 reference time is D6C6EF40.C43D8165 (13:46:40.766 UTC Sun Mar 9 2014) clock offset is 14.9852 msec, root delay is 20.75 msec root dispersion is 642.38 msec, peer dispersion is 414.18 msec
R1#show ntp associations address ref clock st when poll reach delay offset disp *~192.168.1.4 80.96.120.253 2 11 128 137 12.1 14.99 414.2 * master (synced), # master (unsynced), + selected, - candidate, ~ configured
Configurați pe ruterul R2
ca server de NTP stația monitor
.
O soluție simplă pentru monitorizarea centralizată o reprezintă jurnalizarea la distanță (remote). Toate echipamentele din rețea vor trimite mesajele de jurnalizare (logging) către un server central.
În Linux, daemon-ul ce asigură jurnalizarea este rsyslogd
. Acesta este deja instalat pe majoritatea sistemelor Linux.
În mod implicit, rsyslogd
nu acceptă conexiuni din exterior. Pentru a activa această opțiune, trebuie editat fișierul de configurare /etc/rsyslog.conf
și decomentate liniile ce activează recepționarea de mesaje UDP sau TCP.
Vom realiza acest lucru pe statia monitor
:
# provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514
După ce am decomentat liniile trebuie să resetăm serviciul rsyslog
:
root@monitor:~# /etc/init.d/rsyslog restart [ ok ] Stopping enhanced syslogd: rsyslogd. [ ok ] Starting enhanced syslogd: rsyslogd.
Pentru ca un router Cisco sa trimită mesaje de jurnalizare (logging) către un server extern, adresa acestui server trebuie configurată în modul global. În cazul nostru, vom configura adresa IP a stației monitor
pe ruterul R1
:
R1(config)# logging 192.168.1.4
De asemenea, se poate specifica și nivelul de logging. Vor fi trimise doar mesajele cu un nivel cel puțin la fel de grav ca nivelul specificat:
R1(config)# logging trap debugging
Pentru a verifica funcționalitatea, activați debugging-ul protocolului ICMP pe ruterul R1
și executați comanda ping
:
R1#debug ip icmp ICMP packet debugging is on R1#ping google.ro Translating "google.ro"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 173.194.70.94, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/40 ms
După cum se observă nu a apărut în consola ruterului nici un mesaj de debug. Vom verifica fișierul /var/log/syslog
de pe stația monitor
:
root@monitor:~# cat /var/log/syslog Mar 9 15:56:57 192.168.1.1 19: Mar 9 13:56:56.524: ICMP: echo reply rcvd, src 173.194.70.94, dst 192.168.1.1 Mar 9 15:56:57 192.168.1.1 20: Mar 9 13:56:56.564: ICMP: echo reply rcvd, src 173.194.70.94, dst 192.168.1.1 Mar 9 15:56:57 192.168.1.1 21: Mar 9 13:56:56.608: ICMP: echo reply rcvd, src 173.194.70.94, dst 192.168.1.1
Opriți debugging-ul protocolului ICMP:
R1#no debug ip icmp ICMP packet debugging is off
Configurați pe ruterul R2 jurnalizarea remote și testați funcționalitatea:
Soluția prezentată până acum are dezavantajul că toate mesajele sunt stocate în același fișier. Dacă dorim ca mesajele de la un anumit ruter să fie stocate într-un fișier separat, vom folosi opțiunea facility
ce ne permite clasificarea mesajelor de logging. Pe ruter R1 se configurează logging facility
diferit:
R1(config)# logging facility local1
Pe statia monitor
, în /etc/rsyslog.conf
vom specifica un fișier destinație pentru tipul de logging local1
, după care vom reseta serviciul:
root@monitor:~# cat /etc/rsyslog.conf |grep -B 2 R1 #### RULES #### ############### local1.* /var/log/R1.log root@monitor:~# /etc/init.d/rsyslog restart
local1
) sunt predefinite și NU pot fi înlocuite cu orice șir de caracter. Caracterul .
plasat după tipul de logging (local1
) este urmat nivelul de logging pentru care se va face scrierea în fișier. În acest caz caracterul *
semnifică orice nivel de logging al mesajelor.
Pentru testare:
R1#debug ip icmp ICMP packet debugging is on R1#ping acs.pub.ro Translating "acs.pub.ro"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 141.85.227.151, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/32 ms root@monitor:~# cat /var/log/R1.log Mar 9 16:11:16 192.168.1.1 45: Mar 9 14:11:15.651: ICMP: echo reply rcvd, src 141.85.227.151, dst 192.168.1.1 Mar 9 16:11:16 192.168.1.1 46: Mar 9 14:11:15.655: ICMP: echo reply rcvd, src 141.85.227.151, dst 192.168.1.1 Mar 9 16:11:16 192.168.1.1 47: Mar 9 14:11:15.687: ICMP: echo reply rcvd, src 141.85.227.151, dst 192.168.1.1
Configurați un fișier separat de logging și pentru ruterul R2
.
Folosind soluția de jurnalizare remote, în cazul în care dorim să monitorizăm lucruri diferite, trebuie sa realizăm configurații diferite pe fiecare stație monitorizata, fiind o soluție one-way (client către server).
O alternativa este activarea serviciului de SNMP (Simple Network Management Protocol) pe fiecare dispozitiv monitorizat. SNMP este implementat în majoritatea echipamentelor de rețea și expune informații despre toate subsistemele unui dispozitiv (utilizare procesor, memorie, număr de interfețe, număr de pachete pe fiecare interfață, etc.). Interogarea fiecarui dispozitiv se va face centralizat de către stația de management, în cazul nostru stația monitor
.
Protocolul SNMP a evoluat trecând prin mai multe versiuni. Cele mai folosite în ziua de astăzi sunt versiunile 2c
și 3
.
Versiunea 2c
nu dispune de criptarea datelor (trimite parola în clar) și este folosită în general în rețelele interne cu circuit închis. ce poartă adesea numele de rețea de management. Implementarea se realizeaza printr-un VLAN de management, unde numai echipamentele și stația de monitorizare au acces (nu există trafic de date public).
Versiunea 3
dispune de autentificare pe bază de utilizator și parolă și asigură criptarea datelor. Este folosită în general peste rețelele publice.
În continuare vom configura versiunea 2c
a protocolului. Pentru a funcționa, versiunea 2c
are nevoie de un community string
- un șir de caractere ce este partajat între server și client (acea parolă care se trimite în clar).
Pe un router Cisco, community string
-ul se definește din modul global de configurare (în cazul nostru, parola va fi public
):
R1(config)#snmp-server community public ro
Cuvântul cheie ro
ce apare după community-ul public
specifică faptul că folosind acest community se pot realiza doar operații read-only. Pentru securitate crescută, în general vom păstra atributul ro
dacă vom face doar monitorizare.
Pentru a testa funcționalitatea vom folosi utilitarul snmpwalk
de pe stația monitor. Acesta întoarce toate proprietățile pe care protocolul SNMP le expune pe un echipament:
root@monitor:~# snmpwalk -v2c -c public 192.168.1.1 iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS Software, 3600 Software (C3640-JS-M), Version 12.4(12), RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Fri 17-Nov-06 13:59 by prod_rel_team" iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.9.1.110 iso.3.6.1.2.1.1.3.0 = Timeticks: (1242819) 3:27:08.19 iso.3.6.1.2.1.1.4.0 = "" iso.3.6.1.2.1.1.5.0 = STRING: "R1" iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1 iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3 iso.3.6.1.2.1.2.2.1.2.1 = STRING: "FastEthernet0/0" iso.3.6.1.2.1.2.2.1.2.3 = STRING: "Null0" iso.3.6.1.2.1.2.2.1.3.1 = INTEGER: 6 iso.3.6.1.2.1.2.2.1.3.3 = INTEGER: 1 iso.3.6.1.2.1.2.2.1.4.1 = INTEGER: 1500 iso.3.6.1.2.1.2.2.1.4.3 = INTEGER: 1500 iso.3.6.1.2.1.2.2.1.5.1 = Gauge32: 100000000 iso.3.6.1.2.1.2.2.1.5.3 = Gauge32: 4294967295 ^Ctrl+C root@monitor:~# snmpwalk -v2c -c public 192.168.1.1|wc -l 541
După cum se poate observa prin SNMP obținem toate informațiile necesare, de la tipul echipamentului (CISCO
), versiunea sistemului de operare (12.4(12)
) la numărul de pachete ce au trecut print-o interfață Ethernet. De asemenea se observă un număr relativ mare de proprietăți expuse de SNMP (~540
).
Încercați folosirea versiunilor 1
și 3
. Observați că folosirea versiunii 3 eșuează. În mod implicit, la configurarea unei comunități echipamentele CISCO vor folosi versiunea 1
sau 2c
a protocolului SNMP.
Se observă că fiecare intrare are ca și cheie un șir de numere care poartă numele de OID (Object Identifier). În general este greu să lucrăm cu astfel de chei întrucât ele nu au nici o semnificație. Fiecare producător construiește baze de date ce poartă numele de MIB (Management Information Base) în care se asociază cuvinte cheie cu semnificație clară (sysUptime
) cu câte o înșiruire de numere (OID-uri). Poate fi făcută o paralelă cu serviciul DNS care face legătura între nume de domenii și adrese IP.
MIB-urile sunt stocate în fișiere pe sistemul ce realizează interogarea SNMP (în cazul de față stația monitor
). Pentru a descărca aceste MIB-uri există deverse tool-uri. Noi vom folosi snmp-mibs-downloader
:
root@monitor:~# apt-get install snmp-mibs-downloader
O dată instalat, acest va descărca automat toate MIB-urile și le va plasa în /var/lib/mibs
. Noi vom folosi MIB-ul cu numele IF-MIB
(/var/lib/mibs/ietf/IF-MIB
) pentru a realiza interogări legate de interfețe către ruterul R1
. Vom lista toate numele interfețelor de pe R1
:
root@monitor:~# snmpwalk -c public -v 2c 192.168.1.1 IF-MIB::ifName IF-MIB::ifName.1 = STRING: Fa0/0 IF-MIB::ifName.3 = STRING: Nu0
Se observă că Fa0/0
are numărul instanței 1
. Acest număr al instanței este cheia prin care putem afișa și alte caracteristici ale interfeței cum ar fi tipul interfeței:
root@monitor:~# snmpwalk -c public -v 2c 192.168.1.1 IF-MIB::ifType IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.3 = INTEGER: other(1)
Se observă că instanța 1
e de tip ethernetCsmacd
. Asocierea cu Fa0/0
se face prin numărul instanței.
Afișați viteza interfeței Fa0/0
, șirul de caractere descriptiv, numărul de octeți trimiși și primiți și dacă au existat erori pe interfață (Hint: inspectați fișierul /var/lib/mibs/ietf/IF-MIB
pentru a afla numele proprietăților de afișat).
Utilitarul snmpwalk
întoarce toate înstanțele găsite pentru o anumită proprietate. Dacă se știe în mod particular numele proprietății și numărul unei instanțe se poate folosi snmpget
pentru a găsi valoarea asociată (într-un script vom folosi snmpget
în general):
root@monitor:~# snmpget -c public -v 2c 192.168.1.1 IF-MIB::ifName.1 IF-MIB::ifName.1 = STRING: Fa0/0
Pentru ruterul R2 dorim configurarea SNMP versiunea 3. Pentru acest lucru vom crea un grup SAISP
pe care să permitem doar interogările pentru versiunea 3:
R2(config)#snmp-server group SAISP v3 ? auth group using the authNoPriv Security Level noauth group using the noAuthNoPriv Security Level R2(config)#snmp-server group SAISP v3 auth
Avem opțiunea auth
care ne permite autentificarea. NoPriv
se referă la faptul că datele efective nu vor fi criptate (această imagine de IOS nu suportă modul de criptare al datelor transmise de SNMP).
După acest pas trebuie să configurăm un utilizator și o parolă pentru accesul la informațiile SNMP:
R2(config)#snmp-server user student SAISP v3 auth md5 student1
student
se referă la numele utilizatorului creat, SAISP
este grupul configurat mai sus, iar student1
este parola pentru acest utilizator (trebuie să fie de minim 8 caractere).
De pe stația monitor
vom realiza o interogarea folosind versiunea 3:
root@monitor:~# snmpget -v 3 -l AuthNoPriv -u student -a md5 -A student1 192.168.1.2 IF-MIB::ifName.1 IF-MIB::ifName.1 = STRING: Fa0/0
Se observă că am specificat versiunea 3 (-v 3
), comunitatea public
a dispărut întrucât autentificarea se face pe bază de utilizator (-u student
) și parolă (-A student1
). Observați că a trebuit să specificăm obligatoriu tipul de comunicație (-l AuthNoPriv
- autentificare fără criptate) și modalitatea de criptare a parolei folosită (-a md5
). Chiar dacă nu se criptează datele, credențialele NU sunt trimise în clar.
Dezactivați folosirea versiunii 1 și 2c a protocolului SNMP de pe ruterul R2.
În exercițiul 03. [15p] Configurare server SNMP pe echipamente CISCO am configurat serverul de SNMP pe rutere CISCO. După cum am precizat anterior SNMP este implementat în general pe toate echipamentele, inclusiv pe sistemele Linux.
Pe statia gateway
, vom instala pachetul snmpd
care conține serverul de SNMP:
root@gateway:~# apt-get install snmpd
În mod implicit acesta ascultă doar pe localhost
. Trebuie să modificăm linia agentAddress udp:127.0.0.1:161
în agentAddress udp:161
(pe orice intefață) din fișierul de configurare al snmpd
(/etc/snmp/snmpd.conf
) și să resetăm daemonul (/etc/init.d/snmpd restart
).
Dorim să realizăm o interogare de pe stația monitor
către stația gateway
prin care să listăm toate interfețele:
root@monitor:~# snmpwalk -v2c -c public 192.168.1.3 IF-MIB::ifName IF-MIB::ifName = No more variables left in this MIB View (It is past the end of the MIB tree)
Acest comportament e cauzat tot de o configurație a daemonului snmpd
. În fișierul de configurare pe linia în care se specifică comunitatea (parola) rocommunity public default -V systemonly
se observă opțiunea -V systemonly
care limitează proprietățile expuse doar la cele legate de starea sistemului (exemplu: uptime-ul), systemonly
fiind un subset de OID-uri definit mai sus în fișier.
Eliminăm acea opțiune, resetăm serviciul snmpd
și refacem interogarea:
root@gateway:~# cat /etc/snmp/snmpd.conf |grep rocomm # rocommunity public default -V systemonly rocommunity public default root@gateway:~# /etc/init.d/snmpd restart [....] Restarting network management services:: snmpd root@monitor:~# snmpwalk -v2c -c public 192.168.1.3 IF-MIB::ifName IF-MIB::ifName.1 = STRING: lo IF-MIB::ifName.2 = STRING: eth0 IF-MIB::ifName.3 = STRING: eth1
Cuvântul cheie default
din linia ce configurează comunitatea public
permite oricărei adresă IP să facă interogarea. Dacă dorim securizarea interogării la o clasă de adrese IP (192.168.1.0/24 în cazul nostru) putem înlocui default
cu clasa respectivă (192.168.1.0/24
):
root@gateway:~# cat /etc/snmp/snmpd.conf|grep 192. rocommunity public 192.168.1.0/24 root@gateway:~# /etc/init.d/snmpd restart [....] Restarting network management services:: snmpd root@monitor:~# snmpwalk -v2c -c public 192.168.1.3 IF-MIB::ifName IF-MIB::ifName.1 = STRING: lo IF-MIB::ifName.2 = STRING: eth0 IF-MIB::ifName.3 = STRING: eth1 root@gateway:~# snmpwalk -v2c -c public 192.168.0.3 Timeout: No Response from 192.168.0.3 root@gateway:~# tail -1 /var/log/syslog Mar 9 19:11:51 gateway snmpd[4984]: Connection from UDP: [192.168.0.3]:55453->[192.168.0.3]:161
Se observă că la interogarea folosind adresa IP sursă 192.168.0.3
, serverul nu mai răspunde (automat se folosește adresa IP sursă 192.168.0.3
când facem interogarea de pe aceeași mașină către aceeași adresă IP).
SNMP este un protocol extensibil putând adăuga noi proprietăți care să fie exportate serverelor de management/monitorizare. Putem crea script-uri custom care să preia valori din sistem și să le expună prin SNMP.
Creați un script pe stația gateway
care întoarce numărul de intrări din passwd
:
root@gateway:~# cat /tmp/getUserNo #!/bin/bash echo Numarul de utilizatori din sistem este: $(getent passwd | wc -l) root@gateway:~# chmod +x /tmp/getUserNo root@gateway:~# /tmp/getUserNo Numarul de utilizatori din sistem este: 26
Dorim să exportăm rezultatul acestui script prin SNMP pentru ca stația monitor
să poată să îl preia. În fișierul /etc/snmp/snmpd.conf
avem la dispoziție comanda extend
(/extend
). Vom adăuga o nouă intrare de tipul extend-sh
:
root@gateway:~# cat /etc/snmp/snmpd.conf |grep getUser extend-sh userNo /tmp/getUserNo root@gateway:~# /etc/init.d/snmpd restart [....] Restarting network management services:: snmpd
Conform comentariilor din snmpd.conf
ieșirea scriptului este exportată prin proprietatea NET-SNMP-EXTEND-MIB::nsExtendOutput1Table
:
root@monitor:~# snmpwalk -v2c -c public 192.168.1.3 NET-SNMP-EXTEND-MIB::nsExtendOutput1Table|grep userNo NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."userNo" = STRING: Numarul de utilizatori din sistem este: 26 NET-SNMP-EXTEND-MIB::nsExtendOutputFull."userNo" = STRING: Numarul de utilizatori din sistem este: 26 NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."userNo" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."userNo" = INTEGER: 0
După cum se vede scriptul este executat, iar output-ul acestuia este trimis prin SNMP. Adăugați un nou user pe stația gateway
și executați interogarea de mai sus. Observați modificarea valorii la 27
.
Procesul de monitorizare presupune colectarea continuă de date la intervale regulate de timp. În timp, volumul de date crește foarte mult, iar spațiul ocupat de acestea devine o problemă. Luând în calcul și faptul că granularitatea datelor colectate la un moment dat în timp poate să scadă o dată cu trecerea timpului (ex.: nu ne interesează traficul pe o interfață de acum un an la o granularitate de un minut, ci la o oră este rezonabil) a fost proiectat un nou tip de bază de date: Round Robin Database (RRD).
Dimensiunea acesteia este cunoscuta de la momentul creării, în funcție de numărul de tipuri de date colectate și de granularitatea acestora. După cum îi spune și numele, aceasta stochează datele într-un spațiu finit, iar când acel spațiu alocat este epuizat, datele inițiale se vor suprascrie. Înainte de suprascriere se face o arhivare
a datelor suprascrise (de cele mai multe ori se folosește media aritmetică pe intervalul de timp respectiv).
Utilitarul cu ajutorul căruia vom crea și popula bazele de date se numește rrdtool
. Acesta permite 3 operații:
create
(creare bază de date)update
(inserare valori bază de date)graph
(generează un grafic funcție de timp pe baza valorilor introduse)
Pe stația monitor instalăm utilitarul rrdtool
:
root@monitor:~# apt-get install rrdtool
Pentru a crea o bază de date, comanda rrdtool create
primește următorii parametri:
Vom crea o bază de date ce are ca timp de început/referință ora curentă a stației monitor
. rrdtool
are nevoie de această valoare în numărul de secunde trecut de la 1 Ianuarie 1970. Acesta poate fi obținut cu comanda date
:
root@monitor:~# date +%s 1394405025
Pasul folosit va fi de 5 secunde (în practică se folosește pasul de 300 de secunde, dar acum dorim să colectăm mai multe date într-un interval scurt de timp pentru a putea genera un grafic relevant):
root@monitor:~# rrdtool create target.rrd \ --start 1394405025 \ --step 5 \ DS:speedIn:COUNTER:10:U:U \ DS:speedOut:COUNTER:10:U:U \ RRA:AVERAGE:0.5:2:60 \ RRA:AVERAGE:0.5:60:12
După cum se observă am creat 2 variabile de tipul COUNTER
care se numesc speedIn
și speedOut
(pentru alte tipuri de variabile vezi Curs 03 - Monitorizarea rețelei). Valoarea lor maximă este nespecficată (U
- undefined). Valoarea 10
reprezintă numărul de secunde cât așteaptă după date noi, iar dacă este depășit se inserează o valoarea specială UNKNOWN
pentru a nu afecta mediile calculate.
Tipul de arhivare configurat este AVERAGE
și o dată la 2 valori, realizează media acestora după care vechile valori vor fi suprascrise. Sunt păstrate 60 astfel de medii, în final aceste 60 medii fiind suprascrise și ele. Timpul acoperit de această arhivare este de 10 minute (5 secunde x 2 x 60).
O altă arhivare configurată este dată media a 60 de valori (deci 300 de secunde), fiind ținute 12 de astfel de medii. Această arhivare acoperă 300 secunde x 12 = 60 minute
. Deci baza noastră de date ne poate oferi statistici ale traficului pe o interfață de rețea la diferite nivele de granularitate (în ultimele 10 minute este calculată media la nivel de 10 secunde, iar în ultima oră este calculată media la 1 minut).
Copiați și completați scriptul de mai jos pentru a obține valorile pentru variabilele octetsIn
și octetsOut
. Acestea reprezintă numărul de octeți (trimiși și primiți) de pe interfața eth0
a stației gateway
(Hint: snmpwalk
, IF-MIB::ifInOctets
urmat de numărul instanței). Scriptul colectează numărul de octeți din 5 în 5 secunde și îl introduce în baza de date target.rrd
(rrdtool update target.rrd $(date +%s):inOctets:outOctets
):
#!/bin/bash rm -rf target.rrd # Init timestamp. timestamp=$(date +%s) # Align timestamp to multiple of 5 seconds. timestamp=$(($timestamp/5*5)) init_timestamp=$timestamp rrdtool create target.rrd \ --start $timestamp \ --step 5 \ DS:speedIn:COUNTER:10:U:U \ DS:speedOut:COUNTER:10:U:U \ RRA:AVERAGE:0.5:2:60 \ RRA:AVERAGE:0.5:60:12 for i in $(seq 1 24); do sleep 5 timestamp=$(($timestamp + 5)) outOctets=$(...) inOctets=$(...) rrdtool update target.rrd $timestamp:$inOctets:$outOctets done echo --start $init_timestamp --end $timestamp
Comanda rrdtool update
primește timestamp-ul ( scp root@192.168.1.4:speed.png .
</code>
Nagios este unul din cele mai utilizate utilitare de monitorizare a infrastructurii de rețea. Pe stația monitor
se află instalată o instanță de Nagios ce monitorizeaza stația gateway
folosind comanda ping
și serviciul SSH de pe aceasta.
Deschideți un browser web și intrați pe adresa http://192.168.1.4/nagios3
. Folosiți utilizatorul nagiosadmin
și parola student
. În meniul din stânga selectați Hosts
și Services
și observați cele 2 stații prezente (localhost
fiind stația monitor
în sine adăugată implicit și gateway
fiind stația configurată de noi cu serviciul SSH).
Observați configurațiile făcute în fișierul /etc/nagios3/conf.d/gateway.cfg
.
Creați câte un nou host în fișierul /etc/nagios3/conf.d/cisco.cfg
pentru fiecare din ruterele CISCO (R1
și R2
). Creați câte un serviciu asociat fiecărui ruter care verifică dacă serviciul telnet
răspunde cererilor (Hint: grep -r telnet /etc/nagios-plugins
).
Restartati serviciul nagios
si observati ca cele doua routere apar in Hosts
si Services
.
În fisierul gateway.cfg
creați un nou serviciu asociat stației gateway
care să verifice serverul WEB aflat pe aceasta.
În cazul în care acesta nu răspunde să trimită o notificare pe adresa de e-mail a colegului de lângă voi.
Note: Va trebui sa creati un fisier mycontacts.cfg
în care sa definiti un obiect contact
și un obiect contactgroup
(urmăriți fișierul /etc/nagios3/conf.d/contacts_nagios2.cfg
în care este creat grupul admins
). După ce ați terminat de configurat, nu uitați să resetați serviciul nagios3
.
Pentru a putea trimite alerte, Nagios are nevoie de un server de e-mail local. Pe stația monitor
instalați un server de e-mail:
root@monitor:~# apt-get install postfix
Închideți serverul web pe stația gateway
și verificați dacă primiți alerte pe e-mail.
Pentru a putea colecta date despre diferite stații la distanță, uneori trebuie să executăm anumite comenzi pe acele stații. Până acum toate verificările făcute cu Nagios au fost prin interogări de servicii. Dacă dorim să aflăm spre exemplu spațiul liber de pe disc trebuie să executăm o comandă pe acea stație. Nagios vine cu un plugin numit NRPE care poate fi instalat pe orice server din rețea cu scopul de a colecta datele dorite (folosirea procesorului, memoriei, discului, exact ca intrarea implicită localhost
din Nagios).
Vom instala pe gateway
pachetul nagios-nrpe-server
:
root@gateway:~# apt-get install nagios-nrpe-server
Trebuie să permitem stației monitor să se conecteze la serverul NRPE modificând intrarea allowed_hosts
din fișierul /etc/nagios/nrpe.cfg
:
root@gateway:~# cat /etc/nagios/nrpe.cfg |grep 192.168 allowed_hosts=192.168.1.4
Apoi, reporniti serviciul nagios-nrpe-server
pe statia gateway
:
root@gateway:~# /etc/init.d/nagios-nrpe-server restart
Pe stația monitor
va trebui instalat plugin-ul pentru NRPE al Nagios:
root@monitor:~# apt-get install nagios-nrpe-plugin
Pe monitor
, vom configura serviciul NRPE pentru a ne trimite alerte în cazul în care încărcarea procesului de pe stația gateway
este în limite maxime:
root@monitor:/etc/nagios3/conf.d# cat gateway.cfg [...] define service{ use generic-service ; Name of service template to use host_name gateway service_description NRPE Service check_command check_nrpe_1arg!check_load contact_groups coleg }
Observați în interfața grafică noul serviciu adăugat (încărcarea procesorului - load average
). Modificați pe stația gateway
valorile parametrilor la care sunt generate notificările de warning
și critical
:
root@gateway:~# cat /etc/nagios/nrpe.cfg |grep check_load command[check_load]=/usr/lib/nagios/plugins/check_load -w 5,1,0.5 -c 15,10,5
Pentru a varia încărcarea procesorului, rulați programul CPU intensive de mai jos timp de 5 minute și observați cum se modifică valorile raportate de Nagios (îl opriți cu Ctrl+c
):
root@gateway~# cat loop.sh #!/bin/bash i=0 while true do i=$((i++)) done
În mod analog, folosind NRPE, verificați starea încărcării memoriei și a discului de pe stația gateway
.
În cazul unei rețele de mari dimensiuni este destul de greu să creăm script-uri la cerere și să generăm grafice folosind rrdtool
în linie de comandă. Peste aceste utilitare (snmp
, rrdtool
) au fost dezvoltate aplicații integrate ce ușurează munca unui administrator. CACTI este un astfel de framework ce folosește SNMP pentru a colecta statistici și rrdtool
pentru a genera grafice.
Instalați pachetul cacti
pe stația monitor
alegând opțiunile implicite (configurați peste tot parola student
):
root@monitor:~# apt-get install cacti
După instalare intrați pe adresa http://192.168.1.4/cacti
cu user-ul admin
și parola admin
(selectați opțiunile implicite până ajungeți la ecranul de login). Adăugați ruterele R1
, R2
și stația gateway
și creați grafice cu:
Hint: CACTI-graph-howoto.