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

• clientul obtine ceasul de la niște servere predefinite;
• serverul acceptă interogari de la alți clienți pe portul 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

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:

• timpul de început/referință
• pasul cu care datele vor fi introduse în baza de date (la nivel de secundă)
• variabilele ce vor reține datele efective
• tipul de arhivare folosit și momentul la care să se facă arhivarea

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

in-out-octets

#!/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:

• [10p] încărcarea procesorului pentru fiecare în parte
• [10p] traficul pentru fiecare interfață de rețea de pe fiecare echipament

Hint: CACTI-graph-howoto.