Podstawy sieci z Cisco IOS. Moduł 1: Wstępna konfiguracja i weryfikacja
Wstępna konfiguracja dotyczy uniwersalnych parameterów, które ustawiamy niezależnie od docelowego zastosowania danego urządzenia. Do określania nazwy urządzenia służy polecenie "hostname". Warto nadawać nazwy z przyjętą w ramach organizacji nomenklaturą nazewniczą. Jeśli jej nie ma lub nie jest ona dobrze przemyślana, to warto poświęcić wcześniej na to trochę czasu.
Na pewno w infrastrukturze produkcyjnej nie nazywa się urządzeń tak samo, jak w sieci szkoleniowej czy skryptach ćwiczeń. Stąd nie należy wzorować się na przyjętych w naszych materiałach nazwach przy konfiguracji infrastruktury produkcyjnej.
Zdarza się, że dopiero z czasem dochodzi do nas, że przyjęty sposób nazewnictwa nie jest do końca dobry czy coś nie zostało w nim uwzględnione. Tak jest z wieloma rzeczami przy projektowaniu czy budowaniu czegoś.
Dlatego jeżeli ktoś chce zrobić coś raz i mieć spokój, to zachęcamy do konsultacji takich rzeczy z nami, czy nawet zlecenie zaprojektowania ich nam. Oczywiście nie chodzi tutaj o samo dobranie nazw, choć i to czasem lepiej, jak zrobi ktoś, kto ma doświadczenie i wie co w praktyce jest, a co nie jest istotne oraz ma styczność z wieloma różnymi wymaganiami i scenariuszami.
Oprócz nazwy urządzenia, trzeba również określić nazwę domenową. Razem tworzą one tak zwany FQDN (Fully Qualified Domain Name), który unikalnie identyfikuje konkretne urządzenie. Nazwa urządzenia istnieć będzie w ramach domeny, którą definiujemy poleceniem: "ip domain-name" lub "ip domain name".
Serwery nazw wskazujemy poleceniem: "ip name-server". Polecenie to może zawierać listę serwerów DNS (oddzielone spacją " ") lub też można je wydać kilka razy, co spowoduje dopisanie kolejnego serwera do listy. Maksymalnie może być ich 6.
Poznane tutaj polecenia można usunąć z konfiguracji poprzez użycie na ich początku słowa "no". Dotyczy to zresztą dużej większości poleceń, jakie wydajemy w Cisco IOS CLI, a w szczególności tych wydawanych w trybie konfiguracji globalnej.
Na samym początku pracy w Cisco IOS warto włączyć synchroniczne logowanie zdarzeń. Włączenia lub wyłączenia synchronicznego logowania zdarzeń można dokonać oddzielnie dla linii portu konsoli oraz każdej linii wirtualnej z użyciem odpowiednio poleceń: "logging synchronous" i "no logging synchronous". Zostało to pokazane na powyższym slajdzie.
Na żółtawym tle zrzutu poleceń widać co dzieje się, kiedy pojawia się zdarzenie w trakcie wpisywania polecenia, przy wyłączonym synchronicznym logowaniu zdarzeń. Niby wystarczy wtedy użyć tabulatora (klawisz "TAB") i pokaże nam się to co już wpisaliśmy. Niemniej czasem piszemy tak szybko, że taki nagle wrzucony komunikat może nas zdezorientować i popełnimy literówkę.
Włączenie synchronicznego logowania zdarzeń powoduje, że komunikaty generowane przez urządzenie nie są wrzucane w linię wpisywanego polecenia przez co łatwiej się pracuje z urządzeniem. Widać to na zielonawym tle zrzutu poleceń.
Oprócz interfejsów fizycznych, urządzenie może posiadać wiele interfejsów logicznych. Jednym z nich jest interfejs pętli zwrotnej "loopback". Warto tego interfejsu nie traktować 1 do 1, jak interfejsu loopback, który znajduje się w systemach urządzeń końcowych czy serwerów. Tam ma on adres IPv4 127.0.0.1/8 i/lub IPv6 ::1/128.
Zgodnie z dokumentem RFC 5735, blok adresowy 127.0.0.0/8 przypisany jest do urządzeń typu host, a nie urządzeń sieciowych i nie powinien się pojawić nigdzie w sieci poza hostem. Stąd jak widać na czerwonawym tle zrzutu poleceń poniżej, urządzenie sieciowe odmawia przyjęcia takiego adres IP na swoim interfejsie loopback z komunikatem "Not a valid host address - 127.0.0.1".
Natomiast idea interfejsu pętli zwrotnej czy interfejsu loopback w obu przypadkach jest taka sama. Chodzi o stworzenie stabilnego interfejsu, który zawsze będzie działał. Gdyby na hostach nie było interfejsu loopback, to każda utrata połączenia z siecią mogłaby skutkować awarią jego usług. Przestałoby istnieć gniazdo na którym nasłuchiwały usługi, kiedy interfejs zmienił status na "down". Interfejs loopback sprawia, że takie gniazdo zawsze istnieje, zmienia się tylko lista obsługiwanych przez nie adresów IP, w zależności od stanu różnych interfejsów - "up" lub "down". Wymagany jest minimum jeden aktywny i jest nim właśnie loopback.
Na urządzeniach sieciowych takiemu interfejsowi przypisuje się inny, często mający określone znaczenie adres IP. Najczęściej jest on unikalny na każdym z urządzeń, choć to zależy od jego przeznaczenia - więc nie jest to zawsze prawdą. My zaczniemy od najbardziej typowych zastosowań tego interfejsu, jakim jest utrzymanie stabilnego identyfikatora dla usług tego urządzenia oraz zapewnienia jednoznacznie identyfikowalnego adresu źródłowego dla ruchu generowanego przez to urządzenie.
To pierwsze jest potrzebne, jako że w niektórych przypadkach adresy IP mają charakter rozstrzygający. Jeżeli wszystkie inne parametry są takiego same, to decyduje adres IP. Stąd w zależności od tego, który z adresów IP zostanie wybrany na identyfikator danego urządzenia czy usługi, inaczej zbudować się może logiczna topologia naszej sieci.
Drugie wynika z utrzymania porządku i prostoty. Urządzenia sieciowe mogą mieć wiele interfejsów. Domyślnie dla pakietów generowanych przez takie urządzenie wybierany jest interfejs najbliższy miejscu przeznaczenia. W zależności od tego co dzieje się w sieci, nie zawsze musi być to ten sam interfejs. A dzięki interfejsowi loopback, może to być zawsze ten sam interfejs.
Zatem, dzięki interfejsowi loopback zdarzenia wysyłane do serwera Syslog mogą zawsze do niego trafiać z tego samego adresu IP. Upraszcza to diagnozę i minimalizuje pominięcie istotnych zdarzeń. Analogicznie, ruch wysyłany do usług NTP, DNS czy sieci Internet również może zawsze pochodzić z tego samego adresu IP. Dzięki temu reguły filtrujące mogą być o wiele prostsze.
Jeżeli mamy 256 urządzeń i każdemu z nich przypisujemy do interfejsu loopback kolejny adres z podsieci 10.0.1.0/24: 10.0.1.0/32, 10.0.1.1/32, 10.0.1.2/32, aż do 10.0.1.255/32, to wystarczy jedna reguła filtrująca, która dopuszcza do czegoś ruch z naszych urządzeń sieciowych. Bez interfejsu loopback musielibyśmy uwzględnić w regułach wszystkie adresy IP każdego z urządzeń. Byłoby tego bardzo dużo, co utrudniałoby zarządzanie i przejrzystość, a to niestety przekłada się na błędy i awarie.
O ile interfejs loopback powinien być domyślnie włączony, to użycie w nim polecenia "no shutdown" nie spowoduje niczego złego.
Interfejsy na routerach lub kartach z portami w trybie L3 są najczęściej domyślnie wyłączone. Za to porty przełącznika czy lub na kartach z portami w trybie L2 są najczęściej domyślnie włączone. Stąd, kiedy jesteśmy w konfiguracji interfejsu fizycznego routera albo interfejsu SVI (Switch Virtual Interface), który jest interfejsem L3, to należy dodatkowo wykonać polecenie "no shutdown".
Interfejs fizyczny routera można zwykle łatwo zlokalizować. Znajduje się on na obudowie urządzenia.
Natomiast o interfejsach SVI będzie więcej w drugim module. Na ten moment warto zapamiętać, że jest to interfejs logiczny wewnątrz urządzenia. Jest on osiągalny przez wszystkie porty L2, które należą do tego samego VLAN co numer SVI (w tym połączeń typu Trunk z tym VLAN). Przełączniki L2 posiadają aktywny tylko jeden taki interfejs w danej chwili i służy on tylko do zdalnego zarządzania urządzeniem. Natomiast przełączniki L3 mogą mieć ich wiele i dodatkowo pomiędzy nimi przekazywać pakiety IP.
Podobnie jak w systemach z rodziny GNU/Linux mamy plik "/etc/hosts", a w systemach z rodziny Microsoft Windows plik "%WinDir%\System32\Drivers\Etc\hosts", tak samo i w urządzeniach sieciowych możemy tworzyć lokalne odwzorowania nazw, które to mogą nadpisywać to co znajduje się w DNS. W systemie Cisco IOS służy do tego polecenie "ip host", gdzie podajemy nazwę domenową, a zaraz po niej listę adresów IP. Warto zapoznać się z opcjami tego polecenia, gdyż oprócz domyślnego rekordu A, można także tworzyć rekordy MX, NS i SRV. Na urządzeniach sieciowych polecenie to rzadko bywa potrzebne.
Na tym slajdzie prześledzić możemy zarówno konfigurację, jak i weryfikację wcześniej omówionych parametrów. Służy do tego polecenie "show hosts", gdzie widać ustawioną nazwę domenową, serwery DNS oraz utworzone wpisy statyczne.
Warto zwrócić uwagę na wiersz "Name/address lookup uses static mappings" po wpisaniu "no ip domain lookup" w miejscu wcześniej widocznych serwerów DNS. Polecenie to wyłącza dynamiczne rozwiązywanie nazw, zatem skonfigurowane serwery DNS przestają być używane i urządzenie korzysta tylko z wpisów statycznych ustawionych z użyciem polecenia "ip host". W dolnej części wydruku polecenia "show hosts" widać listę ustawionych ręcznie wpisów statycznych czy odwzorowań nazw na adresy IP.
Gdy nie jesteśmy pewni stanu interfejsu albo nomenklatury nazewnictwa stosowanej dla interfejsów w ramach danej platformy, warto posłużyć się poleceniem: "show ip interface brief". Od niego często rozpoczyna się zarówno diagnozę, jak i konfigurację.
To co na tym etapie jest dla nas najbardziej kluczowe, to rozpoznanie nazwy interfejsu (widać ją najbardziej z lewej), adresu IP jaki posiada interfejs (druga kolumna, gdzie "unassigned" oznacza, że nie ma on przypisanego adresu IP) oraz statusu interfejsu:
- "administratively down" oznacza, że interfejs jest wyłączony i należy wydać w nim polecenie "no shutdown".
- "down" może oznaczać niewpięty bądź zły kabel lub niewłączony interfejs po drugiej stronie kabla.
- "up" oznacza, że interfejs jest włączony i widzi drugą stronę.
To tak w dużym uproszczeniu, na tyle szczegółowo, na ile na tym etapie jest to niezbędne.
Na żółtawym tle naszego zrzutu poleceń widać interfejs, który nie został w ogóle włączony. Za to na zielonawym widać interfejs, który został włączony i "widzi" drugą stronę połączenia kablowego.
Jeżeli potrzebne jest nam więcej informacji o interfejsie czy interfejsach, jak m.in. jego adres MAC, maska podsieci czy statystyki dotyczące wysłanych i odebranych pakietów, w tym wykrytych błędów w transmisji i odbiorze ramek, należy posłużyć się poleceniem: "show interface". Dla zawężenia wyniku możemy wskazać w tym poleceniu konkretny interfejs. Najważniejsze dla nas na tym etapie informacje znajdują się na niebieskawym tle.
Do weryfikacji połączenia pomiędzy urządzeniami w sieci TCP/IP służy narzędzie "ping". W swojej najprostszej postaci jego składania w Cisco IOS CLI jest taka sama, jak w systemach z rodziny GNU/Linux czy Microsoft Windows. Jako parametr polecenia "ping" podajemy zadany adres IP i naciskamy klawisz "ENTER". Oczywiście w każdym z systemów polecenie to może mieć dostępny nieco inny zestaw bardziej zaawansowanych opcje i stosować dla nich nieco inną składnię.
W systemie Cisco IOS każde odebranie odpowiedzi jest oznaczone z użyciem znaku wykrzyknika "!", a przekroczenie czasu oczekiwania na odpowiedź z użyciem kropki ".". Drukowane mogą być też inne znaki, oznaczające najczęściej jakiś konkretny rodzaj problemu, ale te dwa są najczęściej spotykane i dla nas na tym etapie wystarczające.
Zatem na czerwonawym tle widać całkowity brak odpowiedzi, a na zielonawym poprawną widoczność pomiędzy adresami IP. Warto zastanowić się nad tym, co widać na żółtawym tle. Z czego wynikać może to pierwsze przekroczenie czasu oczekiwania?
Aby w naszym przykładzie mogło dojść do komunikacji, wymagane jest zaadresowanie pakietu IP i ramki Ethernet. Zatem by wysłać pakiet "ICMP Request" czy inaczej "Echo Request" będący zapytaniem, wymagane jest określenie źródłowego i docelowego adresu IP oraz źródłowego i docelowego adresu MAC (Ethernet). Docelowy adres IP podajemy jako parametr polecenia "ping", a źródłowy jest znany nadawcy jako, że to jego własny adres IP. Podobnie nadawca zna adres MAC swojego interfejsu sieciowego. Jedyne co nie jest mu znane i też nie jest podawane przez nas, to docelowy adres MAC.
Za tą brakującą informację odpowiedzialny jest protokół ARP (Address Resolution Protocol). Jego zadaniem jest mapowanie adresów IPv4 na adres warstwy drugiej. W naszym przykładzie korzystamy z technologii Ethernet, zatem są to adresy MAC. Protokół ten wysyła zapytanie w postaci pakietu "ARP Request" na adres rozgłoszeniowy (ang. broadcast), który składa się z samych jedynek i ma wartość: "FF:FF:FF:FF:FF:FF". Zapytanie to trafia do wszystkich urządzeń w danym segmencie sieci Ethernet.
Zapytanie to zawiera adres IP i adres MAC nadawcy oraz adres IP docelowego odbiorcy tego zapytania. Wszystkie hosty z danego segmentu sieci Ethernet przetwarzają to zapytanie, ale tylko ten będący odbiorcą, którego adres IP kryje się w zapytaniu, wygeneruje na niego odpowiedź. Niemniej zanim to zrobi, utworzy w swojej lokalnej tablicy ARP odwzorowanie z użyciem danych z zapytania ARP o nadawcy, wiążące jego adres IP z jego adresem MAC.
"ARP Reply" będący odpowiedzią ARP jest wysyłana już na adres skierowany (ang. unicast), tylko do nadawcy zapytania.
Kiedy nadawca zapytania ARP otrzyma odpowiedź jest w stanie utworzyć w swojej tablicy ARP wpis wiążący adres IP z szukanym adresem MAC. Dopiero po tym jest w stanie wysłać komunikat "ICMP Request". Niemniej w tej sytuacji całość trwała na tyle długo, że z punktu polecenia "ping" zdążył minąć czas oczekiwania na odpowiedź. Jako, że wszystkie informacje są zapamiętane w tablicy ARP, to procedury tej nie trzeba za każdym razem powtarzać. Stąd kolejne odpowiedzi przychodzą już w wymaganym czasie.
Polecenie "ping" może posiadać dodatkowe parametry. Na zrzucie widać, że zostało wydane z opcjami:
- "size 1500", określający rozmiar całego pakietu, razem z nagłówkiem IP i ICMP (warto pamiętać, że w systemach z rodziny GNU/Linux czy Microsoft Windows odpowiednikiem tej wartości będzie 1472, jako że tam rozmiar wskazywany w poleceniu nie zawiera w sobie 20-oktetów nagłówka IP oraz 8-oktetów nagłówka ICMP).
- "source GigabitEthernet 0", wskazuje interfejs poprzez który zostaną wysłane zapytania.
- "repeat 10", wskazuje ilość zapytań, domyślnie jest to 5.
Warto pamiętać, że odpowiedź "ICMP Reply" przepisuje całą zawartość pola danych z zapytania "ICMP Request". Zatem ma ona ten sam rozmiar. Przenoszony jest w niej m.in. znacznik czasowy, stąd w przypadku nadmiernego zaniżenia rozmiaru nie będziemy widzieli w wydruku polecenia "ping" czasu podróży pakietu.
Polecenie "ping" w trybie User EXEC nie umożliwia podawania żadnych bardziej zaawansowanych parametrów, co widać na samym dole naszego zrzutu poleceń. W zasadzie można podać wtedy tylko docelowy adres IP.
Na routerach i przełącznikach najczęściej usługa HTTP/HTTPS nie jest nam do niczego potrzebna. W takich przypadkach najlepiej ją wyłączyć. Sposób weryfikacji tego czy usługa ta działa oraz jej dezaktywacji został pokazany na poniższym zrzucie poleceń.
Jeżeli z jakiś powodów usługa HTTP/HTTPS musi działać, najlepszą praktyką jest ograniczenie dostępu do niej tylko z wybranych VLAN, podsieci czy nawet adresów IP sieci lokalnej LAN. Na pewno nie powinna być ona dostępna dla całej sieci Internet.
Po konfiguracji urządzenia należy zapisać jego ustawienia. Służy do tego polecenie "copy running-config startup-config". Kopiuje ono zawartość konfiguracji bieżącej "running-config" do miejsca, gdzie składowana jest konfiguracja startowa "startup-config". Aby zrestartować urządzenie i sprawdzić czy posiada po restarcie odpowiednią konfigurację, należy użyć polecenia "reload".
Na żółtawym tle widać jak zaraz po wpisaniu "reload" system pyta nas czy chcemy zapisać konfigurację i mamy wybór "[yes/no]". Następnie na czerwonawym tle mamy możliwość zatwierdzenia restartu, poprzez użycie klawisza "ENTER" lub "y". Na tym etapie można też to anulować z użyciem "n" lub innego klawisza (wyłączając z tego te zatwierdzające).
Kiedy konfiguracja jest zapisana, czyli zawartość "running-config" odpowiada zawartości "startup-config", system Cisco IOS nie pyta nas w trakcie wydawania polecenia "reload" o to, czy chcemy zapisać konfigurację. Widać to na zielonawym tle.
Procedura restartu urządzenia do ustawień fabrycznych czy też usunięcia jego konfiguracji polega na usunięciu "startup-config" i restarcie urządzenia z użyciem polecenie "reload".
Warto przyjrzeć się uważnie zrzutowi poleceń i ze zrozumieniem przeczytać to, o co na poszczególnych etapach pyta nas system Cisco IOS. Często, kiedy chcemy szybko zrestartować urządzenie do ustawień fabrycznych, usuwamy konfigurację, wpisujemy "reload" i odruchowo, nie czytając dokładnie pytań na wszytko odpowiadamy "yes" i naciskamy "ENTER".
W naszym przykładzie widać, że system zapytał nas o to, czy chcemy zapisać konfigurację. Stąd, jeśli wpisaliśmy "yes", to urządzenie po restarcie włączy się z tymi samymi ustawieniami co wcześniej. Zatem nie zostanie zrestartowane do ustawień fabrycznych.
Restart urządzenia może zostać zaplanowany na późniejszą porę. Z użyciem parametrów polecenia "reload" możemy wskazać po jakim czasie lub kiedy dokładnie urządzenie ma wykonać restart. Jeżeli przed tym czasem zmienimy zdanie, można to anulować.
Mechanizm ten bywa przydatny, jeżeli restart urządzenia może odbywać się tylko w określonym oknie serwisowym (np. w nocy) lub dokonujemy zmian, na skutek których możemy się odciąć od urządzenia. O ile w tym drugim przypadku bardziej użyteczne wydają się inne mechanizmy systemu Cisco IOS, o tyle ten jest bardzo prosty w użyciu.
Na zrzucie został zaplanowany restart urządzenia po 2-godzinach i 30-minutach od wpisania polecenia.
Jak widać w lewym dolnym rogu, z użyciem parametru "at" polecenie "reload" można też określić czas restartu poprzez wskazanie dokładnej godziny i daty. Poleceniem "show reload" możemy zweryfikować czy i kiedy został zaplanowany restartu urządzeni.
Za pomocą polecenia "reload cancel" możemy anulować zaplanowany restart.
Przed kolejną porcją wiedzy zachęcamy do przećwiczenia i utrwalenia tej poznanej tutaj. Skorzystaj z naszych ćwiczeń!
Zachęcamy do śledzenia nas w mediach społecznościowych Facebook i LinkedIn.
Zapraszamy do kontaktu drogą mailową
