Kontynuujemy temat rejestracji zdarzeń z wykorzystaniem serwera Syslog. Wpis ten jest kontynuacją wpisu: Rejestracja zdarzeń z wykorzystaniem serwera Syslog lecz tym razem skupiamy się na systemie Linux i wykorzystaniu deamona rsyslog.

Ponieważ jak już zaznaczyłem wpis ten jest kontynuacją tak więc część informacji została celowo pominięta tak by nie powielać ich ponownie. To co nie zostało poruszone w tym wpisie, znajdziesz Czytelniku w artykule, do którego link podałem Ci powyżej.

Zarządzając daną siecią komputerową najkorzystniejszą dla Nas sytuacją i stanem jak najbardziej pożądanym jest prawidłowo działająca sieć. Nasze wszystkie działania administracyjne sprowadzają się do tego by osiągnąć stan pełnej funkcjonalności sieci. Jeśli wszystko działa - możemy być z siebie dumni lecz nie oznacza to, że możemy spocząć na laurach. Awarie sieci i urządzeń ją tworzących są na porządku dziennym i prędzej czy później każdy administrator z takim problemem będzie musiał się zmierzyć. Z reguły awarie i mogące nastąpić komplikacje w działaniu sieci można z dość dużą dozą prawdopodobieństwa przewidzieć. No chyba, że mamy do czynienia z sytuacją nagłą, taką jak przepięcie w sieci elektrycznej, której efektem jest uszkodzenie urządzenia bądź atakiem hackerskim. Ale jak to już w życiu bywa nie do końca na wszystko mamy wpływ.

Administratorzy by sprawnie zarządzać swoją siecią muszą dysponować narzędziami, które pozwolą im na kształtowanie ruchu sieciowego według własnych potrzeb i wymagań. Takim narzędziem, które pozwala na filtrację pojawiających się w sieci pakietów jest lista ACL. Mechanizm ACL jest bardzo ważnym elementem konfiguracji routera gdyż pozwala na ustalenie zasad, które niepożądanym użytkownikom zabronią dostępu do sieci a tym zaufanym udostępnią niezbędne usługi.

W tym artykule kontynuujemy zapoczątkowany w poprzednim wpisie temat uwierzytelnienia użytkowników na urządzeniach CISCO lecz tym razem do wykonania tego zadania wykorzystamy serwer TACACS.

Enhanced Interior Gateway Routing Protocol jest protokołem, który należy do grupy protokołów wektora odległości. EIGRP jest protokołem bezklasowym (wsparcie dla różnej długości maski sieci), pojawił się w 1992 w IOS wersji 9.21 i stanowi rozwinięcie protokołu IGRP. Klasowy protokół IGRP został opracowany przez firmę Cisco jako zamiennik protokołu RIP niwelując tym samym jego ograniczenia (metryka pod postacią skoków, rozmiar sieci ograniczony do 15 skoków). Lecz rozwiązania zaproponowane w tym protokole choć innowacyjne (np. złożona metryka wyliczana z uwzględnieniem: szerokości pasma, niezawodności, opóźnienia oraz obciążenia) stały się niewystarczające. Nowe ulepszenia poszerzające protokół IGRP (np. algorytm DUAL) spowodowały narodzenie się nowego protokołu EIGRP. Co jest ważne protokół ten został w całości opracowany przez firmę Cisco i stanowi własność tej firmy (Cisco proprietary) co w konsekwencji wymusza na nas stosowanie urządzeń Cisco ponieważ nie zadziała on na sprzęcie pochodzącym od innych producentów (podobnie jak opisywany wcześniej protokół CDP). Dla administratorów przejście z protokołu IGRP na EIGRP okazało się dosyć proste gdyż protokoły te korzystają z podobnego zestawu poleceń. IGRP został wycofany wraz z pojawieniem się wersji 12.2(13)T i 12.2(R1s4) systemu Cisco IOS.