Poziomy uprzywilejowania

Tryb konfiguracyjny zarezerwowany jest dla poziomu 15 (p. artykuł w numerze 8), do którego użytkownik uzyskuje dostęp po wykonaniu polecenia enable i podaniu hasła enable secret (jeśli ręcznie wyłączone zostało hasło enable secret, należy podać hasło enable password). Na dowolny poziom uprzywilejowania można wejść komendą enable xx, gdzie w miejsce xx wpisuje się żądany poziom. Użytkownika może jednak spotkać niespodzianka. - ponieważ standardowo poziomy od 2 do 14 nie jest włączona ochrona hasłem. System operacyjny w ogóle nie pozwala na nie wejść, przechodząc z niższego poziomu na wyższy. Aby stan ten zmienić, należy do wybranego poziomu przypisać hasło. W tym celu należy przejść na poziom 15, wywołać tryb konfiguracyjny i wykonać polecenie:

2600(config)#enable secret level xx haslo

Parametr xx oznacza numer poziomu, dla którego definiowane jest hasło. Ponieważ użyliśmy polecenia enable secret, hasło dla poziomu xx przechowywane będzie w skrypcie konfiguracyjnym w postaci zaszyfrowanej, uniemożliwiającej jego odczytanie.

Aby przejść na określony poziom, idąc z wyższego na niższy, należy posłużyć się poleceniem disable xx (polecenie disable bez parametrów oznacza powrót na poziom 1). Warto zauważyć, iż polecenie disable pozwalające przejść na poziom niższy nie wymaga podawania hasła dla tego poziomu.

Ponieważ w pewnych sytuacjach standardowe zestawy poleceń, zdefiniowane dla poszczególnych poziomów mogą okazać się niewystarczające, administrator może wybrane polecenia przypisać do poziomów, na których nie są one normalnie dostępne. Jako przykład rozważmy sytuację, w której administrator routera chciałby dodać dla poziomu 0 komendę pozwalającą wyświetlić zawartość tabeli routingu. Wyprzedzając nieco tematykę omawianą w następnych artykułach, polecenie pozwalające wyświetlić zawartość tabeli routingu ma postać show ip route. Aby komendę tę przypisać do poziomu 0, należy wykonać polecenie konfiguracyjne:

2600(config)#privilege exec level 0 sh ip route

Po wykonaniu tego polecenia komenda show z parametrem route dla protokołu ip będzie dostępna na poziomie 0, o czym można się przekonać, wykonując polecenie help bądź sprawdzając działanie polecenia sh ip route. Na poziomie 0 nie będą dostępne wszystkie warianty komendy show, tylko składnia sh ip route, co można sprawdzić w kontekstowym systemie pomocy, wywoływanym znakiem "?":

C2600>?

Exec commands:

Disable Turn off privileged commands

Enable Turn on privileged commands

Exit Exit from the EXEC

Help Description of the interactive help system

Logout Exit from the EXEC

Show Show running system information

C2600>show ?

WORD Flash device information - format <dev:>[partition]

ip IP information

C2600>show ip ?

Route IP routing table

Ochrona dostępu do routera

W konfiguracji standardowej dostęp do routera poprzez linię konsoli nie jest chroniony żadnym hasłem. Jeżeli w konkretnej firmie obowiązują bardziej restrykcyjne zasady bezpieczeństwa sieci, należy to zmienić. Opiszemy dwie metody zabezpieczania dostępu do routera: w pierwszej użytkownicy muszą znać wspólne dla wszystkich hasło, w drugiej każdy użytkownik uwierzytelniany jest na podstawie indywidualnego konta i hasła. Aby zdefiniować wspólne dla wszystkich hasło chroniące dostęp do routera poprzez linię konsoli, należy przejść do trybu konfiguracyjnego linii konsoli numer 0, następnie włączyć uwierzytelnianie i określić hasło:

C2600(config)#line console 0

C2600(config-line)#login

C2600(config-line)#password haslo

Ponieważ w tej metodzie od wszystkich użytkowników wymagane jest to samo hasło, może się ona okazać w pewnych sytuacjach niewystarczająca. Lepszą metodą weryfikowania dostępu do routera będzie sprawdzanie użytkownika poprzez indywidualne konto i hasło. Konfiguracja linii konsoli w tym przypadku będzie nieco inna. Komenda login musi być uruchomiona z parametrem określającym bazę kont użytkowników. Jeżeli na przykład stosowana ma być lokalna, utworzona na routerze baza kont, to konfiguracja jest następująca:

C2600(config)#line console 0

C2600(config-line)#login local

Zauważmy, że w powyższym przykładzie nie ma komendy password, gdyż hasło wspólne dla wszystkich użytkowników nie ma w tym przypadku zastosowania. Przy używaniu komendy login local należy unikać pewnej pułapki, która może zablokować normalne korzystanie z routera - po wykonaniu polecenia login local, przy każdej próbie podłączenia się do routera pojawi się pytanie o konto użytkownika i hasło; jeżeli więc nie będzie lokalnej bazy kont (a standardowo jej nie ma), nie będzie możliwe poprawne uwierzytelnianie. Trzeba najpierw zdefiniować konta użytkowników, a dopiero potem użyć komendy login local.

Polecenie konfiguracyjne pozwalające utworzyć nowe konto użytkownika ma składnię: username Nazwa password Haslo. Polecenie to wymaga podania nazwy konta i hasła wykorzystywanego w procesie uwierzytelniania. Konta utworzone poleceniem username są przechowywane i widoczne w aktualnej konfiguracji routera, stąd należy pamiętać o regularnym zapisywaniu jej w pamięci NVRAM. Domyślnie użytkownik, który weryfikowany jest przy dostępie do routera poprzez indywidualne konto i hasło, umieszczany jest na poziomie 1 (poziom użytkownika). Można również do każdego konta indywidualnie przypisać inny domyślny poziom pracy, na który użytkownik będzie automatycznie przełączany. W tym celu należy ponownie posłużyć się komendą username. W poniższym przykładzie tworzone jest konto Admin2 z hasłem cisco, a dodatkowo do tego konta przypisywany jest domyślny poziom uprzywilejowania 7:

C2600(config)#username Admin2 password cisco

C2600(config)#username Admin2 privilege level 7

Korzystanie z polecenia konfiguracyjnego login local jest rozwiązaniem skutecznym, choć może być nieco uciążliwe, gdyż wymaga definiowania lokalnej bazy danych na każdym z routerów. Innym sposobem rozwiązania problemu weryfikacji jest zastosowanie centralnej usługi uwierzytelniającej podłączających się użytkowników. Rozwiązanie to oparte w praktyce na usługach zewnętrznych RADIUS lub TACACS+ oferuje również możliwość autoryzacji i rejestracji wykonywanych działań. Przykładową sytuację, w której router Cisco jest klientem serwera RADIUS przedstawia rysunek poniżej.

Uwierzytelnienie użytkownika za pomocą zewnętrznej usługi RADIUS

Przy próbie podłączenia się do routera, np. poprzez port konsoli, router pracujący jako klient przesyła do centralnego serwera prośbę o uwierzytelnienie użytkownika. Serwer RADIUS, zawierający centralną bazę informacji o użytkownikach, przeprowadza proces weryfikacji, dodatkowo może określić rodzaj dozwolonych dla użytkownika operacji (autoryzacja) oraz kontrolować i zapisywać w dzienniku ich realizację. Protokół RADIUS pozwala w praktyce na wykonywanie trzech niezależnych działań (nie tylko uwierzytelniania), jest on przykładem tzw. protokołu AAA (Authentication, Authorization, Accounting). Aby włączyć na routerze Cisco korzystanie ze wszystkich usług AAA, należy w trybie konfiguracji globalnej wykonać polecenie aaa new-model, a następnie skonfigurować realizację procesu uwierzytelniania, autoryzacji i kontroli poleceniami: aaa authentication, aaa authorization i aaa accounting. Poniższe przykładowe komendy konfiguracyjne pozwalają wskazać serwer RADIUS oraz określić klucz stosowany do zaszyfrowania przesyłanego hasła użytkownika (podobnie konfiguruje się współpracę z serwerem TACACS+, który też jest protokołem AAA):

C2600(config)#radius-server host 131.107.2.250

C2600(config)#radius-server key klucz

Zastosowanie protokołów AAA pozwala w optymalny sposób zarządzać procesem uwierzytelniania użytkowników, zwłaszcza w środowisku dużej, wielosegmentowej sieci lokalnej, wyposażonej w wiele routerów. Przed wdrożeniem tego rozwiązania należy zastanowić się nad wyborem odpowiedniego protokołu. Protokół RADIUS (oparty na UDP) jest rozwiązaniem otwartym, nadającym się bardzo dobrze dla środowisk niejednorodnych, w których wykorzystywane są urządzenia różnych producentów. Natomiast protokół TACACS+ (oparty na TCP) jest rozwiązaniem firmy Cisco i przeznaczony jest dla sieci wykorzystujących urządzenia tej firmy.

Oprócz podłączenia poprzez port konsoli możliwy jest także dostęp do routera poprzez linie terminali wirtualnych VTY. Najczęściej wykorzystywany jest do tego celu protokół Telnet. Aby ustanowić sesję telnetową do zdalnego routera, konieczne jest wcześniejsze poprawne skonfigurowanie interfejsu tego routera (m.in. wpisanie adresu IP), poprzez który sesja zostanie nawiązana. Standardowo router Cisco udostępnia 5 linii terminali wirtualnych, przez które można się do niego podłączyć. Linie te przyznawane są użytkownikom dynamicznie i nie wiadomo, która zostanie wykorzystana na kolejne połączenie. Z tego powodu najczęściej konfiguruje się wszystkie 5 linii VTY jednocześnie. Ochrona dostępu do routera poprzez linie VTY wygląda bardzo podobnie, jak w przypadku podłączania się poprzez port konsoli. Dlatego bez dodatkowego omawiania tych samych rozwiązań, zapoznajmy się z przykładami konfiguracji linii VTY. Aby włączyć ochronę dostępu do routera na poziomie pojedynczego hasła, należy wykonać polecenia:

C2600(config)#line VTY 0 4

C2600(config-line)#login

C2600(config-line)#password haslo

Zapis line VTY 0 4 w pierwszym poleceniu oznacza linie VTY o numerach od 0 do 4, czyli wszystkie 5 linii. Pamiętajmy, że hasło chroniące dostęp przez linie VTY definiowane jest już w dialogu konfiguracyjnym (w odróżnieniu od portu konsoli), zatem polecenie password w tym przypadku służyć będzie jedynie do jego zmiany. Aby włączyć korzystanie z lokalnej bazy kont użytkowników w procesie uwierzytelnienia, należy wykonać następujące polecenia:

C2600(config)#line VTY 0 4

C2600(config-line)#login local

Dodatkowym sposobem zwiększenia bezpieczeństwa przy dostępie do routera poprzez linie VTY jest określenie dozwolonych adresów, z których połączenie może być ustanowione. Można wskazać na przykład adresy komputerów, przy których pracują administratorzy. Realizuje się to przez wykorzystanie podpolecenia access-class w ramach konfiguracji linii VTY. W praktyce polecenie to korzysta ze zdefiniowanych wcześniej list dostępu dla protokołu IP, które omówione zostaną w jednym z dalszych artykułów. Dodatkowo dla linii terminali wirtualnych warto zdefiniować parametry automatycznego rozłączania połączenia. Poniżej pokazujemy dwa przykłady ustawiające czasy rozłączania. Komenda pierwsza oznacza bezwzględne rozłączenie sesji użytkownika po 60 minutach. Polecenie drugie ustawia rozłączanie po 15 minutach i 30 sekundach bezczynności. Komenda absolute-timeout nie ma zdefiniowanej wartości domyślnej, polecenie exec-timeout przyjmuje domyślnie wartość 10 minut:

C2600(config)#line VTY 0 4

C2600(config-line)#absolute-timeout 60

C2600(config-line)#exec-timeout 15 30

Zarówno hasło zdefiniowane poleceniem enable password, jak i hasła przypisane do kont użytkowników oraz hasła zabezpieczające dostęp do routera poprzez linie konsoli czy linie VTY przechowywane są w postaci jawnej w konfiguracji routera. Może się zdarzyć, zwłaszcza gdy skrypt konfiguracyjny nagrywany jest na serwerze TFTP, że hasła te zostaną odczytane przez niepowołane osoby. Aby temu zapobiec, należy w trybie konfiguracji globalnej wykonać polecenie service password-encryption. Wszystkie wprowadzone jawnie hasła przedstawione zostaną w konfiguracji w postaci zaszyfrowanych łańcuchów znaków, poprzedzonych cyfrą 7, wskazującą algorytm szyfrowania (z wyjątkiem hasła enable secret, które szyfrowane jest innym algorytmem). Oczywiście podczas logowania użytkownik cały czas posługuje się hasłem w postaci jawnej. Warto zauważyć, że wyłączenie usługi szyfrującej nie powoduje odszyfrowania haseł. W postaci jawnej hasła zostaną pokazane w konfiguracji dopiero po ich następnej zmianie.

Procedura "naprawiania" hasła

Jeżeli administrator routera zapomni hasła uprawniającego do przejścia na poziom 15, nie będzie mógł wprowadzić żadnych zmian konfiguracyjnych. Podobny problem może pojawić się wówczas, gdy administrator otrzymuje router już skonfigurowany, na przykład z innego oddziału firmy, bez informacji o związanym z nim haśle. Proces tzw. naprawienia hasła dla trybu uprzywilejowanego polega w zasadzie na jego nadpisaniu nową wartością. Może go przeprowadzić osoba podłączona do routera poprzez port konsoli. Przede wszystkim router musi zostać uruchomiony w specjalnym trybie monitora pamięci ROM po to, aby zmodyfikować szesnastobitową wartość rejestru systemowego. W tym celu w ciągu pierwszych 60 sekund od włączenia routera (wartość podawana w dokumentacji Cisco), z konsoli należy wybrać specjalną kombinację klawiszy, przerywającą normalny proces startu. Najczęściej jest to kombinacja CTRL_Break, choć może być różna w zależności od rodzaju emulowanego terminala. Inne kombinacje, które warto przetestować to np. CTRL_B lub Alt_B. Przykładowo kombinacja CTRL_Break działa poprawnie w programie HyperTerminal systemu Windows 98 czy Windows 2000 (ale nie Windows NT 4.0). Po wybraniu CTRL_ Break router uruchamiany jest w trybie monitora pamięci ROM. Przy każdym starcie routera hasło związane z poziomem 15 odczytywane jest z konfiguracji startowej. Procedura naprawcza rozpocznie się więc od ustawienia w rejestrze wartości, która zmusi router do pominięcia (ale nie skasowania) konfiguracji startowej przy jego następnym uruchomieniu. W tym celu na routerze 2600, wykorzystywanym w większości naszych przykładów, wykonać należy polecenie confreg 0x2142 (standardowa wartość rejestru to 0x2102). Cyfra szesnastkowa 4 na trzeciej pozycji rejestru oznacza pominięcie wczytywania konfiguracji startowej. Jeżeli nie wiemy, jaką wartość rejestru należy ustawić, można uruchomić program confreg w trybie dialogowym, w którym odpowiedzi na kolejne pytania pozwalają zdefiniować różne parametry pracy routera, ustawiając odpowiednie bity w rejestrze. Większość pytań nie dotyczy w ogóle hasła, więc można pozostawić proponowane domyślne wartości. Tylko pytanie Ignore system config info wymaga odpowiedzi Yes. Po zdefiniowaniu rejestru należy ponownie uruchomić router poleceniem reset.

Proces uruchamiania routera powinien zakończyć się pytaniem o wejście do dialogu konfiguracyjnego. Dzieje się tak dlatego, iż router nie wczytał konfiguracji startowej i wówczas zawsze proponuje dialog konfiguracyjny. Po udzieleniu przeczącej odpowiedzi zauważymy, że nazwa routera ma postać: Router. W kolejnych krokach należy:

1. Wejść do trybu uprzywilejowanego poprzez wykonanie komendy enable (system nie zapyta o hasło);
2. Wczytać konfigurację startową do pamięci RAM: copy start runn;
3. wejść do trybu konfiguracyjnego: conf term;
4. Zdefiniować nowe hasło, np.: enable secret cisco1;
5. Przywrócić poprzednią postać rejestru: config-register 0x2102;
6. W konfiguracji każdego interfejsu wyłączyć polecenie shutdown (domyślnie router nieskonfigurowany ma wyłączone interfejsy, a jest nim na przykład router, który nie wczytał konfiguracji startowej);
7. Nagrać konfigurację aktualną z nowym hasłem w pamięci NVRAM: copy runn start;
8. Ponownie uruchomić router i przetestować nowe hasło.

Obsługa komunikatów generowanych przez router

Zdarzenia zachodzące na routerze oraz poszczególne działania systemu operacyjnego mogą być monitorowane i zapisywane w postaci komunikatów, co ułatwia diagnostykę i naprawianie ewentualnych błędów. Komunikaty opisujące pracę routera oraz będące wynikiem działania polecenia debug, śledzącego wybrane procesy, mogą być wysyłane do czterech różnych odbiorców, zgodnie z rysunkiem poniżej.

Standardowo wszystkie komunikaty wyświetlane są na terminalu konsoli. Dodatkowo można skonfigurować wyświetlanie komunikatów w sesjach telnetowych (połączenia VTY) oraz wysyłanie komunikatów do zewnętrznego serwera usługi syslog. Czwartą opcją jest zapisywanie komunikatów w wewnętrznym buforze routera. Dla każdego z wymienionych czterech przypadków można niezależnie skonfigurować poziom szczegółowości raportowanych zdarzeń (p. tabela). Standardowo dla linii konsoli oraz linii terminali wirtualnych włączony jest najbardziej szczegółowy poziom raportowania (debugging) oznaczający monitorowanie wszystkich zdarzeń, dla usługi syslog włączony jest poziom komunikatów informacyjnych (informational), natomiast buforowanie komunikatów w pamięci jest wyłączone.

Komunikaty routera mogą być wysłane do czterech urządzeń

Poziom 7 (debugging), oprócz tego, że oznacza zbieranie wszystkich komunikatów opisujących pracę routera, jest również wymagany dla poprawnego raportowania zdarzeń związanych z działaniem polecenia debug. Podstawową komendą konfiguracyjną służącą do określania miejsc, w których będą zbierane komunikaty oraz definiowania poziomów szczegółowości jest globalne polecenie konfiguracyjne logging. W poniższej sekwencji poleceń wyłączono raportowanie na linii konsoli, włączono wysyłanie komunikatów na linie VTY (na poziomie 6), zdefiniowano maksymalny poziom szczegółowości (7) komunikatów wysyłanych do zewnętrznej usługi syslog pracującej pod adresem 131.108.1.250 oraz ustalono, że zdarzenia będą monitorowane w wewnętrznym buforze (8192 bajty) routera:

C2600(config)#no logging console

C2600(config)#logging monitor informational

C2600(config)#logging 131.108.1.250

C2600(config)#logging trap debugging

C2600(config)#logging buffered 8192

Polecenie logging trap pozwala ustalić poziom raportowania dla komunikatów wysyłanych do usługi syslog. Najczęściej jest to usługa uruchamiana na hostach systemu Unix, a zbierane zdarzenia zapisywane będą w pliku tekstowym.

Poleceniem logging monitor włącza się wysyłanie komunikatów na linie terminali wirtualnych VTY, ale nie jest to równoznaczne z odbieraniem ich w sesjach protokołu Telnet. Po ustanowieniu połączenia na jednej z pięciu linii terminali wirtualnych, wymagane jest dodatkowo wykonanie polecenia terminal monitor, które spowoduje wyświetlanie komunikatów w tej konkretnej sesji telnetowej.

Polecając zbieranie komunikatów do wewnętrznego bufora na routerze, pamiętać należy o tym, iż jest on tworzony w pamięci RAM, tak więc wszystkie zgromadzone w nim komunikaty zostaną utracone po każdym ponownym uruchomieniu routera. To rozwiązanie, choć wygodne - komunikaty z bufora można w dowolnej chwili wyświetlić na ekranie konsoli - nie nadaje się do archiwizowania zdarzeń. Do tego celu należy wykorzystać zewnętrzną usługę syslog. Domyślny rozmiar bufora komunikatów wynosi 4096 bajtów, a zawarte w nim komunikaty oraz aktualną konfigurację raportowania wyświetlić można poleceniem show logging. Poniżej prezentujemy wynik tego polecenia dla przykładowej konfiguracji routera, w której włączono buforowanie komunikatów. Zwróćmy uwagę na wyświetlany czas monitorowanych zdarzeń:

C2600#show logging

Syslog logging: enabled (0 messages dropped,0 flushes, 0 overruns)

Console logging: level debugging, 25 messages logged

Monitor logging: level debugging, 5 messages logged

Logging to: vty66(5)

Trap logging: level informational, 29 message lines logged

Buffer logging: level debugging, 25 messages logged

Log Buffer (4096 bytes):

02:34:23: %SYS-5-CONFIG_I: Configured from console by console

02:35:22: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up

02:35:24: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down

Jak zaznaczyliśmy wcześniej, włączenie najwyższego poziomu raportowania 7 jest wymagane do poprawnego posługiwania się poleceniem debug. Komenda ta, dostępna na poziomie uprzywilejowanym, pozwala monitorować pracę różnego rodzaju procesów i protokołów działających na routerze. Poszczególne komunikaty opisujące śledzony proces mogą być wysyłane do jednego z czterech odbiorców, jak to opisaliśmy wcześniej. Jako przykład posługiwania się poleceniem debug, prezentujemy narzędzie przeznaczone do testowania komunikacji w sieci IP - program ping. Wysyła on sekwencję pakietów echo protokołu ICMP pod wskazany adres IP, oczekując na taką samą liczbę odpowiedzi w postaci pakietów echo reply. Śledzenie działania programu ping wymaga następującej składni komendy debug: debug ip icmp. Oto przykładowa sekwencja komunikatów wynikowych:

C2600#debug ip icmp

ICMP packet debugging is on

C2600#ping 131.107.10.245

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 131.107.10.245, timeout is 2 seconds: !!!!!

Success rate is 100 percent (5/5), Round-trip min/avg/max = 1/2/4 ms

C2600#

03:30:53: ICMP: echo reply rcvd, src 131.107.10.245, dst 131.107.10.1

03:30:53: ICMP: echo reply rcvd, src 131.107.10.245, dst 131.107.10.1

03:30:53: ICMP: echo reply rcvd, src 131.107.10.245, dst 131.107.10.1

03:30:53: ICMP: echo reply rcvd, src 131.107.10.245, dst 131.107.10.1

03:30:53: ICMP: echo reply rcvd, src 131.107.10.245, dst 131.107.10.1

Warto zauważyć, iż polecenie debug nie obejmuje pakietów echo protokołu ICMP wysyłanych przez router. Dlatego też w komunikatach wynikowych widać tylko pięć pakietów zwrotnych echo reply (nie ma 5 wysyłanych pakietów echo).

Czasami w procesie rozwiązywania problemów komunikacyjnych, niezbędne jest włączenie śledzenia całej komunikacji protokołu IP. W tym celu wykonać należy komendę: debug ip packet. Poniżej przedstawiamy ponownie przykład działania programu ping - fragment komunikatów wyraźnie pokazuje, iż tym razem komenda debug obejmuje zarówno pakiety wysyłane, jak i odbierane.

C2600#debug ip packet

IP packet debugging is on

C2600#ping 131.107.10.245

Sending 5, 100-byte ICMP Echos to 131.107.10.245, timeout is 2 seconds: !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

C2600#

03:35:19: IP: s=131.107.10.1 (local),

  d=131.107.10.245 (Ethernet0/0), len 100, sending

03:35:19: IP: s=131.107.10.245 (Ethernet0/0),

  d=131.107.10.1 (Ethernet0/0), len 100, rcvd 3

Innym często stosowanym poleceniem jest komenda debug ip rip, pozwalająca nadzorować i wykrywać ewentualne błędy w działaniu protokołu routingu dynamicznego RIP. Ponieważ proces śledzenia może generować na ekranie konsoli bardzo dużo komunikatów, które nakładają się na inne wpisywane polecenia, psując ich czytelność (ale nie składnię), można posłużyć się poleceniem konfiguracyjnym linii konsoli: logging synchronous. Komenda ta zablokuje nakładanie się wyświetlanych komunikatów na aktualnie wpisywane polecenie. Do wyłączenia polecenia debug służy standardowo składnia no debug śledzony_proces. Przykładowo polecenie no deb all wyłącza wszystkie procesy śledzenia.

Współpraca z serwerem nazewniczym DNS

Posługiwanie się bezpośrednio adresami IP w takich poleceniach, jak ping, traceroute czy telnet może być bardzo niewygodne. W sieci IP zwykle stosowane są nazwy pełniące rolę aliasów opisujących adresy IP. Oczywiście łatwiej można zapamiętać nazwy, ale w celu ustanowienia połączenia na poziomie warstwy sieciowej, muszą one zostać przetłumaczone na adresy IP. Można w tym celu zastosować usługę nazewniczą DNS.

Nazwy DNS są wieloczłonowe i składają się z nazwy hosta oraz wieloelementowej nazwy domeny, na przykład: www.firma.com. Aby router Cisco odwoływał się do serwera DNS w celu przetłumaczenia nazwy, należy posłużyć się globalnym poleceniem konfiguracyjnym ip name-server adres_IP. Można wskazać kilka serwerów DNS, podając ich adresy IP. Dodatkowo warto wpisać do konfiguracji domyślną nazwę domeny DNS, która będzie automatycznie dodawana do nazw hostów. Jeżeli na przykład wykonano polecenie konfiguracyjne ip domain-name firma.com, to wywołanie polecenia ping tftp_server spowoduje poszukiwanie w serwerze DNS nazwy tftp_server.firma.com. Komenda ip domain-list pozwala określić dodatkowe nazwy domen, które będą kolejno dodawane do nazwy hosta w procesie tłumaczenia nazwy na adres IP. Jeżeli w sieci firmowej nie jest stosowana usługa DNS, można na routerze Cisco wyłączyć odwołania do niej poleceniem konfiguracyjnym no ip domain-lookup. Pozwoli to uniknąć niepotrzebnych prób poszukiwania serwera DNS, na przykład w sytuacji, gdy niepoprawnie wpisano polecenie. Router Cisco interpretuje błędne polecenie jako nazwę hosta, z którym ma być ustanowiona sesja Telnet i metodą rozgłoszeniową próbuje odnaleźć serwer DNS w celu przetłumaczenia tej nazwy, co najczęściej jest stratą czasu.

Jeśli nie można wykorzystać serwera DNS w procesie tłumaczenia nazw, można posłużyć się globalnym poleceniem konfiguracyjnym ip host do zdefiniowania lokalnych, statycznych powiązań nazw i adresów IP. W poniższym przykładzie definiowany jest alias Sopot związany z adresem 131.107.10.245:

C2600(config)#ip host Sopot 131.107.10.245

Poleceniem show hosts można wyświetlić lokalny bufor nazw, w którym pokazywane są wszystkie aliasy na stałe przypisane do adresów IP (poleceniem ip host) oraz tymczasowe wpisy będące wynikiem poszukiwania nazwy w serwerze DNS:

C2600#show hosts

Default domain is firma.com

Name/address lookup uses domain service

Name servers are 131.107.10.245

Host			Flags		Age	Type	Address(es)

Gdynia.firma.com	(temp, OK)	0 	IP	131.107.10.245

Sopot			(perm, OK)	0 	IP	131.107.10.245

Konfigurowanie protokołu SNMP

Protokół SNMP (Simple Network Management Protocol) opracowany został do nadzorowania, diagnozowania oraz zdalnego zarządzania urządzeniami pracującymi w sieci TCP/IP. Wyróżniamy dwa podstawowe składniki w architekturze SNMP: oprogramowanie agenta, zwykle zaszyte w urządzeniu sieciowym oraz oprogramowanie menedżera SNMP, dostarczane na przykład jako specjalizowana aplikacja (p. rysunek).

Komunikacja między menedżerem i agentem SNMP

Komunikacja między menedżerem i agentem, realizowana przy wykorzystaniu standardowego zestawu poleceń, pozwala menedżerowi zebrać podstawowy zestaw informacji o urządzeniu, na którym pracuje agent. Informacje, które menedżer może uzyskać od agenta zdefiniowane są w postaci obiektów w bazach danych MIB (Management Information Base). Każdy obiekt w bazie ma swój unikatowy identyfikator, poprzez który menedżer ma do niego dostęp. Typowe polecenia, za pomocą których menedżer uzyskuje informacje o określonych obiektach to: GET i GET-NEXT, natomiast poleceniem SET menedżer wymusza ustawienie wartości wybranego obiektu. Dodatkowo agent może z własnej inicjatywy wysyłać do menedżera komunikaty typu TRAP, co dzieje się na skutek wystąpienia pewnych zdarzeń. System operacyjny routera Cisco wyposażony jest w oprogramowanie agenta SNMP, ale do poprawnej pracy wymaga dodatkowej konfiguracji. Aby agent zaakceptował polecenie przysyłane od menedżera. musi być spełniony warunek przynależności do tej samej społeczności SNMP (community). Nazwę społeczności, do której należy agent (router Cisco) można zdefiniować już w dialogu konfiguracyjnym lub później globalnym poleceniem konfiguracyjnym snmp-server community. W poleceniu tym można też podać tryb dostępu do agenta: RO (tylko do odczytu - polecenia GET i GET-NEXT) bądź RW (do odczytu i zapisu - również polecenie SET) oraz numer standardowej listy dostępu, dzięki której można określić dozwolone adresy IP dla menedżerów przysyłających żądania. Do standardowych zdarzeń zachodzących na routerze Cisco, które powodują wysłanie komunikatu Trap do wybranego menedżera należy błąd uwierzytelnienia. Jest to przypadek, gdy do agenta przychodzi żądanie z obcej społeczności. Oprócz informowania o próbach nieuprawnionego dostępu, agent wysyła typowo do swojego menedżera komunikaty Trap dla zdarzeń ponownego uruchomienia routera bądź zmiany stanu interfejsu. Inne komunikaty typu Trap wysyłane przez agenta konfiguruje się poleceniem snmp-server host. Komenda ta pozwala określić adres IP menedżera SNMP, nazwę społeczności menedżera oraz rodzaje komunikatów Trap, które będą do menedżera wysyłane.

Poniżej przedstawiamy przykład konfiguracji protokołu SNMP. Zauważmy, że router może należeć do kilku społeczności. Dla społeczności Public włączona jest opcja RO (tylko do odczytu), dla społeczności Private włączony jest pełen dostęp (RW). W przypadku społeczności Private ustawiono kontrolowanie adresu IP menedżera poprzez listę dostępu nr 5. Ostatnia komenda definiuje adres IP menedżera, do którego wysyłane będą komunikaty Trap, określa też rodzaj wysyłanych komunikatów trap. W tym przykładzie router C2600 informować będzie swojego menedżera o zdarzeniach dotyczących protokołu ISDN oraz o zmianach w konfiguracji.

C2600(config)#snmp-server community Public RO

C2600(config)#snmp-server community Private RW 5

C2600(config)#snmp-server host 131.107.10.245 Public isdn config

Programy graficzne przeznaczone do zdalnego zarządzania routerem Cisco bardzo często opierają swoje działanie na protokole SNMP. W takim przypadku niezbędne będzie określenie właściwej nazwy społeczności, w której pracuje router. Dodatkowo, aby ułatwić zarządzanie, na routerze można skonfigurować dwa parametry opisowe, określające położenie routera oraz osobę kontaktową. Parametry te definiuje się w postaci łańcuchów znaków za pomocą polecenia snmp-server location oraz snmp-server contact.

Wykrywanie sąsiadów - protokół CDP

Częstym problemem podczas poprawnej konfiguracji routerów w sieciach wielosegmentowych jest uwzględnienie dodatkowych urządzeń, które pracują w naszym bezpośrednim sąsiedztwie. Firma Cisco opracowała metodę wykrywania urządzeń własnej produkcji bez względu na to, jakim protokołem warstwy sieciowej się one posługują. Protokół CDP (Cisco Discovery Protocol) działa w warstwie łącza danych, stosując technologię rozgłoszeń typu multicast i może być uruchamiany na dowolnym medium obsługującym hermetyzację SNAP. Oznacza to, że protokół CDP może wykrywać urządzenia Cisco w sieciach LAN, Frame Relay czy ATM, a dwa sąsiednie routery zostaną rozpoznane nawet wówczas, gdy stosują różne protokoły warstwy sieciowej (IP, IPX, AppleTalk). Urządzenia z włączonym protokołem CDP rozsyłają cyklicznie (standardowo co 60 sekund) informację o sobie, nasłuchując jednocześnie ogłoszeń od sąsiadów.

Protokół CDP jest domyślnie włączony na wszystkich interfejsach routera , tak więc nie ma potrzeby wykonywania żadnych dodatkowych operacji, aby zobaczyć efekt jego działania. W wielu przypadkach, gdy zależy nam na wysokim stopniu bezpieczeństwa, wskazane jest zablokowanie protokołu lub przynajmniej ograniczenie jego rozgłoszeń. Poleceniem no cdp run w trybie konfiguracji możemy wyłączyć protokół CDP w całości, natomiast poleceniem no cdp enable w trybie konfiguracji interfejsu blokujemy działanie protokołu na tym konkretnym interfejsie. Jest to szczególnie przydatna konfiguracja na routerze brzegowym, pomiędzy naszą siecią lokalną a Internetem.

Efekt działania protokołu CDP można zaobserwować, wykonując polecenie show cdp neighbors. Wyświetlona zostanie lista bezpośrednich sąsiadów routera, w tym informacje: poprzez jaki port dane urządzenie jest osiągalne, czas, przez jaki dana informacja będzie dla nas wartościowa (czas buforowania holdtime wynosi domyślnie 180 sekund), typ danego urządzenia, platforma, oraz identyfikator zdalnego interfejsu:

C2600#sh cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater

Device ID   Local Intrfce   Holdtme   Capability   Platform   Port ID

1720e       Eth 0/0         131       R            1720       Fas 0

Jak pokazuje ramka, sąsiadem routera C2600 jest router z serii 1720 o nazwie 1720e. Jest on osiągalny poprzez interfejs Eth0/0, a informacja ta przechowywana będzie w buforze jeszcze przez 131 sekund. Dokładniejsze informacje na temat danego urządzenia można uzyskać, korzystając z polecenia show cdp entry Device_ID, gdzie jako identyfikator należy podać nazwę z kolumny Device ID. Szczegółowe informacje związane z wszystkimi urządzeniami wykrytymi przez protokół CDP można uzyskać, wydając polecenie show cdp entry *. Aktualną konfigurację protokołu CDP dla wybranego interfejsu wyświetlić można poleceniem show cdp interface typ_interfejsu.