Cacti - wykresy stanu portów w switchach

Cacti jest przepotężnym narzędziem do zbierania i graficznej prezentacji najprzeróżniejszych parametrów sieci. W podstawowej instalacji są to wykresy obciążenia procesora, interfejsów sieciowych, zajętości pamięci itp. Cacti może być rozbudowane o wiele przeróżnych wykresów jak monitorowanie środowiska, zasilania, stanu serwerów (HTTP, DNS) i wiele innych. 

Niedawno spotkałem się z potrzebą monitorowania zajętości portów na switcha. Najprostszym sposobem było zaprzęgnięcie działającego już w sieci Cacti do dodatkowej pracy. W tym celu znalazłem na forum Cacti skrypt, który w zamierzeniu autora miał odczytywać potrzebne parametry - ilość wszystkich portów ethernet i portów, które działają w danym momencie. Przerobiłem go do swoich celów i dodałem nową funkcjonalność - odczyt portów w stanie Admin Up. Dodatkowo przystosowałem skrypt do działania z innymi switchami, nie tylko Cisco, ale również HP Procurve i 3COM.

Poniższe skrypty należy skopiować do katalogu /usr/share/cacti/site/scripts

check_ports_cisco.php

check_ports_hp.php

check_ports_3com.php

Cisco - większość switchy, sprawdzone na C3560, C2960, C3750 i C6505

HP - Procurve 2510G, 2524 (będzie działać ze wszystkimi switchami które numerują interfejsy cyframi), 1810G-8 i 4000M (modularny)
3COM - SuperStack II 3300, SuperStack III 4400 i 4500, Baseline 2226 Plus

Następnie, po zalogowaniu się do Cacti z prawami administratora musimy skonfigurować kilka zależnych od siebie elementów:

1. Data Input Methods

Input Fields - przy ich pomocy przekazujemy parametry do skryptu

Output Fields - przy ich pomocy odbieramy ze skryptu dane, ich nazwy muszą być identyczne z tymi które są w skrypcie

Jeżeli chcemy, by parametry do skrypty były przekazywane automatycznie na podstawie informacji zdefiniowanych w karcie urządzenia (Device), takich jak. IP adres, SNMP community, czy SNMP version, należy przy definiowaniu Input Field w polu Special Type Code wpisać jedno z podanych słów kluczowych, np. hostname dla adresu IP lub nazwy kanonicznej urządzenia.

2. Data Templates

W Data Templates definiujemy w jaki sposób RRDTools ma obsługiwać napływające ze skryptu dane. Ważne jest zdefiniowanie odpowiedniej ilości pól w szablonie, należy pamiętać o zapisywaniu szablonu po każdorazowym utworzeniu i edycji nowego pola.

3. Graph Templates  

 Tu definiujemy jak ma wyglądać wykres.

4. Device i Create Graph

Na koniec na karcie urządzenia dodajemy z listy rozwijanej nowy szablon i po wybraniu linka Create Graph For This Host dodajemy nowy wykres.

5. A tak wygląda efekt końcowy

Pole niebieskie to całkowita ilość interfejsów. Pole zielone to interfejsy w stanie Admin UP a czerwona linia to aktualnie aktywne interfejsy - w stanie Oper Up.

Pliki z gotowymi szablonami do switchy Cisco i HP 

generowane za pomocą Cacti 0.8.8a 

Rancid - narzędzie do monitorowania zmian i backupu konfiguracji - część 1

W codziennej pracy z sieciami prędzej czy później natkniemy się na problem archiwizacji konfiguracji urządzeń sieciowych - routerów, switchy, firewalli itp. Na rynku jest dostępne wiele różnych płatnych narzędzi takich jak Kiwi CatTools czy kombajn Cisco LMS . Co jednak w sytuacji, gdy np. budżet IT niedużej firmy nie pozwala na zakup komercyjnego rozwiązania? Przy małej ilości urządzeń można sobie pozwolić na ręczne backupy konfiguracji urządzeń, ale gdy ilość urządzeń rośnie nakład czasu potrzebny do wykonania backupów rośnie. Oczywiście można się posiłkować skryptami automatyzującymi pracę, lecz może być to dość karkołomne dla mniej doświadczonych adminów.

Rozwiązaniem tego problemu może być RANCID (Really Awesome New Cisco confIg Differ) - znakomite narzędzie przeznaczone do automatycznego backupu konfiguracji urządzeń sieciowych. Oprócz tego RANCID potrafi zachowywać różne wersje konfiguracji i porównywać je za pomocą CVS (Concurrent Version System). Wbrew nazwie RANCID potrafi backupować urządzenia różnych producentów takich jak:  Juniper, HP, Foundry itd. Do działania nie są potrzebne dodatkowe protokoły jak SNMP. Rancid loguje się do urządzenia i kopjuje konfigurację. Sam RANCID jest narzędziem działającym w trybie tekstowym, można go jednak doposażyć w graficzną nakładkę CVS-WEB.

 instalacja RANCIDa

Opis instalacji dotyczy systemu Linux Debian 6.0
Do prawidłowego działania RANCIDa potrzebne są następujące programy:
- Apache2
- CVS
- RANCID :)
- CVS-WEB  

Do instalacji pakietów możemy użyć albo graficznego managera pakietów, albo tekstowego apt-get. W obu przypadkach, przy prawidłowo zainstalowanym Debianie, instalacja pakietu RANCID automatycznie zainstaluje potrzebne powiązane pakiety (Apache2, CVS). Na koniec będzie potrzebne doinstalowanie pakietu CVS-WEB.

Zatem zaczynamy:

1. Najpierw instalujemy RANCIDa

    #apt-get install rancid

W trakcie instalacji zostanie utworzone konto użytkownika i jego katalog domowy.

2. Teraz edytujemy plik konfiguracyjny rancid.conf znajdujący się w katalogu /etc/rancid . Należy dodać przynajmniej jedną grupę. 

   LIST_OF_GROUPS="urzadzenia"

Przy większych sieciach, może być pomocne skonfigurowanie kilku grup. Nazwy grup muszą być rozdzielone znakiem spacji. 

   LIST_OF_GROUPS="ruter switch firewall"  

 3. Następnie należy skonfigurować plik o nazwie .cloginrc zawierający hasła potrzebne do zalogowania się na urządzenia. Edytujemy plik zachowując odpowiednią składnię w zależności od urządzenia, w przykładzie składnia dla urządzeń Cisco

add password 1.1.1.1 {USER_PASSWORD} {ENABLE_PASSWORD}
add autoenable 1.1.1.1 1

Jeśli urządzenie używa protokołu SSH zamiast telnet (np. Cisco PIX/ASA) do konfiguracji  dodajemy: 

add method 1.1.1.1 ssh

Znak "#" standartowo oznacza komentarz, zatem jeśli chcemy z jakiegoś powodu wyłączyć dane urządzenie z backupów to wystarczy że postawimy "#" na początku odpowiedniej linii.

Należy być bardzo ostrożnym z uprawnieniami pliku .cloginrc gdyż przechowuje on hasła w postaci tekstowej niezaszyfrowanej. Jedyną możliwością ochrony pliku jest ograniczenie praw dostępu do pliku wyłacznie dla właściciela. Zatem ustawiamy

  chmod 600 /home/rancid/.cloginrc
  chown -R rancid:rancid /home/rancid 

4. Kolej teraz na stworzenie architektury CVS. W tym celu należy zalogować się na konto użytkownika rancid 

  su rancid
  rancid@linux:~ /home/rancid/rancid/bin/rancid-cvs

Po tym w katalogu rancida powinna zostac utworzona struktura CVS on nazwie grupy jaką podaliśmy w pliku konfiguracyjnym.

5. Teraz dodajemy urządzenia do grupy /home/rancid/rancid/{nazwa_grupy}/router.db
Składnia pliku jest prosta: "ip_address":"typ_urządzenia":"status"  np.:

   1.1.1.1:cisco:up

 Następnie testujemy, czy rancid ma dostęp do skonfigurowanego urządzenia.

   rancid@linux:~ /home/rancid/rancid/bin/clogin 1.1.1.1

1.1.1.1
spawn telnet 1.1.1.1
Trying 1.1.1.1...
Connected to 1.1.1.1.
Escape character is '^]'.

User Access Verification

Username:
Password:
Router#

6. I uruchamiamy RANCIDa

  rancid@linux:~ /home/rancid/rancid/bin/rancid-run

Logi RANCID są dostępne w katalogu /var/log/rancid. 

7. By RANCID sprawdzał konfiguracje bez naszego udziału trzeba do crona dodać

   crontab -e -u rancid

   # uruchom rancid-run każdego dnia o 01:00 
   0 1 * * * /home/rancid/rancid/bin/rancid-run

Poza tym możemy pokusić się o automatyczne usuwanie logów. Rancid zapisuje osobne logi dla każdej grupy po każdorazowym zakończeniu pracy. Przy dużej ilości urządzeń i grup oraz szczególnie częstym uruchamianiu skryptu logów będzie bardzo dużo i ich ilość będzie przyrastała w zastraszającym tempie. Pokusiłem się o automatyczne usuwanie starych logów. By to zrobić do crona należy dodać linię.

  crontab -e -u rancid 

  # czyść logi co miesiąc o 00:15 

  15 00 1 * * find /var/lib/rancid/logs/ -type f -mtime +30 -exec rm {} \;

 instalacja CVS-WEB

RANCID pracuje, ale jak odczytać wyniki jego pracy? Można zrobić to przez interfejs tekstowy CVSa, ale jest to dość trudne. Z pomocą przychodzi nam bardzo przejrzysty i łatwy w użyciu CVS-WEB.
Zatem:

1. Instalujemy pakiet

  apt-get install cvsweb

2. W pliku /etc/cvsweb/cvsweb.conf należy odnaleźć sekcję @CVSrepositories i dodać katalog gdzie znajduje się główne repozytorium.

@CVSrepositories = (
#'local' => ['Local Repository', '/var/lib/cvs'],
'moje_urzadzenia' => ['urządzenia', '/var/lib/rancid/CVS'],
#'freeebsd' => ['FreeBSD', '/var/ncvs'],
#'openbsd' => ['OpenBSD', '/var/ncvs'],
#'netbsd' => ['NetBSD', '/var/ncvs'],
#'ruby' => ['Ruby', '/var/anoncvs/ruby'],
);

Następnie tworzymy link symboliczny do katalogu, gdzie znajdują się ikony i pliki css

  ln -s /usr/share/cvsweb /var/www/cvsweb

3. Teraz możemy przetestować CVS-WEB wpisując w przeglądarce:

  http://127.0.0.1/cgi-bin/cvsweb

Cisco - Jak EEM rozwiązał problem z tunelami IPSEC

Jakiś czas temu natknąłem się na problem z tunelami IPSEC. Wszystkie rutery które są w sieci są podłączone do Internetu łączami kablowymi UPC. Niestety mimo, że adresy IP są stałe, to UPC co 24 godziny "odświeża" połączenie, co powoduje zerwanie szyfrowanych tuneli IPSEC. Nie byłby to żaden problem, bo normalnie ponowne zestawienie tunelu jest praktycznie niezauważalne dla zwykłego użytkownika. Tymczasem zdarza się że pomimo ponownego zestawienia łącza internetowego, tunel IPSEC nie nawiązuje poprawnie komunikacji i nie ma łączność pomiędzy oddziałem a centralą. Jest to o tyle uciążliwe, że trzeba zalogować się na zdalny ruter i zrestartować interfejs Tunnel. Tu z pomocą przychodzi mało znane narzędzie Cisco - Embedded Event Manager EEM. EEM dostarcza narzędzie do wykrywania i reagowania na różne zdarzenia występujące w sieci lub na urządzeniu. Do jego oprogramowania służy dość prosty język skryptowy. W opisywanym wyżej przypadku sprawdzana jest ilość peerów EIGRP i jeżeli jest ona mniejsza od 1, skrypt restartuje interfejs Tunnel. Do sprawdzenia użyte zostało SNMP i OID zwracający potrzebną wartość. Całość działa bardzo skutecznie i czy to po chwilowych, czy też po dłuższych przerwach, komunikacja IPSEC jest przywracana bez udziału użytkownika czy administratora.

!

event manager applet Tunnel_restart
  event snmp oid 1.3.6.1.4.1.9.9.449.1.5.1.1.3.0.100.8 get-type exact entry-op lt entry-val 1 exit-op ge exit-val 1 exit-time 20 poll-interval 60
  action 101 syslog priority notifications msg "Restart Tunnel100 interface due to IP-SEC problem"
  action 102 cli command "enable"
  action 103 cli command "conf t"
  action 104 cli command "inter Tu100"
  action 105 cli command "shutdown"
  action 106 cli command "no shutdown"
  action 107 cli command "end"
!