Podstawy sieci z Cisco IOS. Moduł 4: DHCP (Dynamic Host Configuration Protocol)

Do komunikacji i działania w sieci Internet wymagana jest odpowiednia konfiguracja. Potrzebne do tego parametry można określić w sposób ręczny lub bardziej automatyczny i dynamiczny. Przez wszystkie moduły tego szkolenia, cała konfiguracja potrzebna do działania w sieci IP była wykonywana ręcznie. W tym module zajmiemy się już konfiguracją dynamiczną z użyciem protokołu DHCP (Dynamic Host Configuration Protocol). Funkcja klienta DHCP jest domyślnie aktywna na interfejsach sieciowych większości urządzeń końcowych. Dzięki temu w wygodny sposób i z jednego miejsca można dokonać zarówno konfiguracji, jak i rekonfiguracji wielu punktów dostępowych, telefonów czy komputerów. Protokół DHCP został opisany w dokumentach RFC2131 i RFC2132.

Protokół DHCP działa w architekturze klient/serwer. Służy do przydzielania konfiguracji urządzeniom działającym w sieci IP. Bazuje on na protokole BOOTP (Bootstrap Protocol), opisanym w dokumentach RFC951 i RFC1542. Zastosowanie tych samych numerów portów, architektury oraz wspólnego formatu nagłówka wiadomości sprawia, iż zarówno serwer DHCP (ang. DHCP Server), jak i przekaźnik DHCP (ang. DHCP Relay) jest w stanie równolegle obsługiwać zarówno klientów BOOTP, jak i DHCP.

Dla protokołów BOOTP i DHCP zostały zarezerwowane dwa dobrze znane numery portów 67/udp i 68/udp. Na porcie 67/udp nasłuchuje serwer DHCP, a na porcie 68/udp klient DHCP. Zastosowanie stałego portu dla klienta jest czymś nietypowym. Najczęściej spotykamy się z tym, że klient wybiera dla siebie jakiś tymczasowy losowy port czy też inaczej port efemeryczny (ang. ephemeral port). Gdyby takie podejście zostało zastosowane dla protokołu DHCP, to wysyłane na adres rozgłoszeniowy (ang. broadcast) odpowiedzi do klienta DHCP, trafiałyby dodatkowo do różnych usług i aplikacji działających na innych komputerach i urządzeniach w sieci lokalnej, które wylosowały akurat ten sam numer portu. Potencjalnie mogłoby to powodować jakieś problemy w ich działaniu. Dlatego właśnie klient DHCP zawsze korzysta z dobrze znanego portu 68/udp.

Serwer DHCP zapewnia trzy metody alokacji adresów: dynamiczną, automatyczną i manualną. W metodzie automatycznej, serwer DHCP przyznaje klientowi adres IP na stałe. W metodzie dynamicznej, adres IP przydzielany jest tylko na określony czas. Metoda manualna umożliwia administratorowi przypisanie konkretnego adresu dla konkretnego klienta. Najczęściej korzysta się z metody dynamicznej, która pozwala na przydzielenie adresów IP ze zdefiniowanej wcześniej puli. Dotyczy to zarówno nowych, jak i zwolnionych adresów IP. Metoda ta często mieszana jest z metodą manualną, gdzie dla wybranych urządzeń, które pełnią jakąś określoną funkcję w sieci (np. drukarki), przypisuje się z użyciem DHCP konkretne adresy IP.

Na slajdzie poniżej widać budowę nagłówka BOOTP/DHCP. Warto zwrócić uwagę na oznaczone kolorem brązowym pole "flags". Został w nim zdefiniowany tylko 1-bit o nazwie "broadcast". Z jego użyciem klient, który nie ma jeszcze adresu IP, może wskazać serwerowi DHCP, w jaki sposób chce otrzymać od niego odpowiedź. Z użyciem rozgłaszania lub bezpośrednio na adres skierowany (ang. unicast). Odpowiedzi generowane bez użycia rozgłaszania nie zaśmiecają lokalnej sieci i nie są przetwarzane przez wszystkie znajdujące się w niej urządzenia. O ile nowsze systemy radzą sobie z ich obsługą, to niestety dawniej niektóre miały z tym problem.

Bit ten adresuje problem z przetwarzaniem odpowiedzi DHCP zaadresowanych na adres IP, którego stos TCP/IP jeszcze nie obsługuje. Dotyczył on niektórych systemów operacyjnych, szczególnie tych wczesnych. Warto pamiętać, że DHCP korzysta z protokołu UDP, a ten enkapsulowany jest w protokole IP. Zatem o ile odpowiedź zaadresowana w warstwie drugiej na adres MAC karty sieciowej klienta była przetwarzana i przekazywana do warstwy wyżej, to niestety już dalej warstwa trzecia sprawdzała nagłówek IP i odrzucała taki pakiet. Znajdował się tam nie obsługiwany przez nią adres IP. Dzięki temu bitowi klient DHCP może nakazać serwerowi DHCP, by ten generował odpowiedzi z użyciem adresów rozgłoszeniowych w warstwie drugiej i trzeciej.

Format nagłówka DHCP jest zgodny z BOOTP i składa się z następujących pól:

• "op" (Operation) - określa czy wiadomość jest zapytaniem (1 dla BOOTREQUEST) czy odpowiedzią (2 dla BOOTREPLY).
• "htype" (Hardware Type) - określa typ adresu sprzętowego (1 dla Ethernet).
• "hlen" (Hardware Length) - określa długość adresu sprzętowego w oktetach (6 dla Ethernet).
• "hops" - ustawiana przez klienta na zero (0) i zwiększana o jeden (1) przez każdy przekaźnik DHCP (ang. DHCP Relay).
• "xid" (Transaction ID) - wartość ustawiana przez klienta, którą serwer przepisuje w odpowiedzi. Pozwala klientowi powiązać odpowiedź z zapytaniem.
• "secs" - ilość sekund od momentu, kiedy klient rozpoczął proces uzyskiwania adresu IP (obecnie nie ma zastosowania),
• "flags" - aktualnie został zdefiniowany tylko opisany wyżej bit "broadcast". Z jego użyciem klient wskazuje w jaki sposób chce uzyskać odpowiedź (1 to broadcast, a 0 to unicast).
• "ciaddr" (Client IP Address) - klient wstawia w to miejsce swój aktualny adres IP (jeżeli już jakiś posiada), w innym przypadku pole to ma wartość zero.
• "yiaddr" (Your IP Address) - przydzielony dla klienta adres IP. Pole to wypełnia serwer DHCP.
• "siaddr" (Server IP Address) - adres IP serwera, który ma zostać użyty w następnym kroku procesu bootstrapowania klienta. 
• "giaddr" (Gateway IP Address) - adres IP przekaźnika BOOTP/DHCP (ang. DHCP Relay).
• "chaddr" (Client Hardware Address) - adres sprzętowy klienta określony parametrami "htype" i "hlen".
• "sname" (Server Name) - pole nie zawsze wypełniane, zawiera nazwę hostname serwera lub przy odpowiednio ustawionej opcji DHCP "Option Overload" listę dodatkowych opcji DHCP.
• "file" (Boot File Name) - pole nie zawsze wypełniane, zawiera ścieżkę do pliku rozruchowego (ang. boot file) lub przy odpowiednio ustawionej opcji DHCP "Option Overload" listę dodatkowych opcji DHCP.
• "options" - pole o zmiennej długości, przenoszące dodatkowe parametry (bardzo duże zastosowanie w DHCP).

Różnica w budowie nagłówka BOOTP i DHCP jest znikoma. Na jego końcu, w miejscu opcjonalnego pola "vendor-extension", które w BOOTP miało stałą długość 64-oktetów, pojawiło się pole o zmiennej długości "options" (do 312 oktetów).

Minimalna wielkość pakietu IP to 576 oktetów. Jest to minimalna wielkość, jaką powinna obsługiwać każda implementacja tego protokołu. Kiedy odejmiemy od tej wartości nagłówek IP (20-oktetów), nagłówek UDP (8-oktetów) oraz standardowy nagłówek DHCP (236-oktetów) to pozostanie nam 312-oktetów na pole "options" nagłówka DHCP.

Pole "options" jest kompatybilne wstecz. Zarówno w BOOTP, jak i DHCP rozpoczyna się od tak zwanego Magic Cookie o wartości 99.130.83.99 (0x63825363), które określa sposób interpretacji dalszej zawartości tego pola. Protokół BOOTP obsługuje dużo mniejszą ilość opcji od protokołu DHCP. Chodzi zarówno o ich rodzaj, jak i sumaryczną ilość w polu "options".

Znajdujące się tam opcje posiadają stałą lub zmienną długość. Opcje o stałej długości składają się tylko z 8-bitowego pola "Code". Opcja "pad option" ma wartości 0. Stosowana jest jako dopełnienie czy wyrównanie innych opcji do granicy słowa. Opcja "end option" ma wartości 255. Stosowana jest na końcu pola opcji. Za "end option" mogą znajdować się już jedynie "pad option". 

Parametry wykorzystywane przez protokół DHCP, w tym parametry konfiguracyjne klienta, przenoszone są w ramach opcji o zmiennej długości. Składają się one z trzech pól. Pola "Code" określającego tag opcji, pola "Len" określającego długość czy też wielkość pola "Value" oraz pole "Value" z właściwą wartością. Kilka z nich zostało wyszczególnionych na slajdzie. Większość posiada na tyle intuicyjne nazwy, że nie wymaga dodatkowego komentowania. Kilka z tych opcji omówimy dokładniej na kolejnych slajdach.

Umieszczenie większej ilości opcji wymaga użycia pól nagłówka DHCP "sname" i "file". Rolą tych pól steruje opcja 52 "Option Overload", która określa, czy któreś z nich, czy też oba są stosowane do przenoszenia dodatkowych opcji, zamiast pełnienia swojej standardowej, opisanej wyżej roli. W ten sposób na opcje możemy wykorzystać więcej niż 312-oktetów pola "options".

W opcji 53 "DHCP Message Type" określony jest typ wiadomości DHCP. Więcej o tej opcji będzie na kolejnych slajdach.

Opcja 54 "Server Identifier" zawiera adres IP serwera DHCP. Pozwala ona wskazać klientowi w zapytaniu wybrany serwer DHCP czy też wybraną ofertę DHCP. W ofercie DHCP, z użyciem tego pola wskazany zostaje adres IP serwera DHCP, dzięki czemu klient może się z nim dalej komunikować już w sposób bezpośredni, z użyciem adresu skierowanego (ang. unicast). Dzięki temu polu inne serwery DHCP dowiadują się o tym, że została wybrana oferta inna niż ich i mogą swoją konfigurację zaoferować komuś innemu.

W opcji 55 "Parameter Request List" zawarta jest lista parametrów czy też opcji DHCP, o jaką prosi klient. Lista ta składa się zwykle z kilku oktetów (1-oktekt na opcję). Wartość każdego z oktetów odpowiada wartości pola "Code" opcji DHCP, o jaką prosi klient.

Z użyciem opcji 56 "Message" istnieje możliwość przekazania przez serwer DHCP dodatkowego tekstu w formacie NVT ASCII. Jego przykładem może być informacja w wiadomości DHCPNAK o powodzie, dla którego dany adres nie może zostać przydzielony czy też użyty. Klient DHCP może wyświetlić treść tej wiadomości użytkownikowi.

Został także zdefiniowany zakres opcji do lokalnych zastosowań, których funkcję i format można samodzielnie definiować. Mieści się on w przedziale od 224 do 254 (31 opcji). Zakres ten został opisany w RFC3942.

Działanie protokołu DHCP w dużej mierze opiera się na polu "options". Dlatego warto zapoznać się z jego dokładną budową, w trakcie naszych ćwiczeń. Opcji tych jest oczywiście dużo więcej. By się z nimi zapoznać warto zacząć od dokumentu RFC2132.

Na kolejnych slajdach przejdziemy jeszcze przez kilka z tych opcji dokładniej i też omówimy kilka dodatkowych. Niemniej, proszę pamiętać o tym, że jest to szkolenie podstawowe, wprowadzające do wybranych protokołów i technologii. Zatem ani w tym module, ani w żadnym innym, nie poruszamy bardziej zaawansowanych zastosowań. Jesteśmy tu na poziomie sieciowego przedszkola.

Opcja 61 "Client Identifier" stosowana jest przez klienta DHCP. Przekazuje on w niej swój unikalny identyfikator. Jest on używany przez serwer DHCP do indeksowania przyznanych dzierżaw adresów IP i konfiguracji. Musi być on unikalny, zatem w ramach jednej domeny DHCP nie może się powtarzać. W przypadku DHCP jest on też wykorzystywany do przypisywania konkretnych ustawień konkretnym urządzeniom. W przypadku BOOTP, do tego celu stosuje się wartość z pola "chaddr".

Wartość tego identyfikatora może bazować na adresie sprzętowym karty sieciowej. W tym przypadku, w polu "Type" znajduje się identyfikator technologii w jakiej pracuje karta sieciowa. Jest to wartość "1" dla technologii Ethernet. Zaraz za tym polem znajduje się już właściwy adres sprzętowy karty. W przypadku technologii Ethernet, będzie to adres MAC. Zatem w przypadku stosowania tego formatu i technologii Ethernet, każdy adres MAC zostanie rozszerzony o wartość "01" na początku. Będzie można to zaobserwować na kolejnych slajdach, zarówno przy konfiguracji, jak i weryfikacji dzierżaw DHCP.

Stosowanie generowanych w ten sposób identyfikatorów ma swoje minusy. Identyfikator klienta zmienia się wraz ze zmianą jego interfejsu sieciowego. W ten sposób klient traci swój adres IP i co za tym idzie dostęp do powiązanych z nim zasobów oraz wskazujące na niego nazwy domenowe. Zatem taka zmiana musi być w pewien sposób skoordynowana i wymaga zaangażowania administratora IT. Kolejnym problemem są urządzenia posiadające więcej niż jeden interfejs sieciowy. Dla przykładu przewodową kartę Ethernet i bezprzewodową kartę Wi-Fi. Obie karty wykorzystuje jeden system, który ma jedną nazwę. Niemniej, każda z tych kart posiada inny unikalny identyfikator. Zatem, każda z kart uzyska inny unikalny adres IP. O ile nie wydaje się to być niczym niepokojącym, to należy pamiętać o innych usługach w sieci, w tym usługach katalogowych, jak usługa DNS. Tylko jeden z tych adresów IP zostanie powiązany z nazwą tego urządzenia czy komputera. Zdarzyć się może, że będzie to akurat ten, który przestanie być zaraz dostępny, choć jego dzierżawa będzie aktywna i ważna przez jeszcze bardzo długi okres.

Problemy te zostały już zaadresowane w DHCPv6 (RFC3315). Stąd w ten sam sposób zdecydowano się je zaadresować w DHCPv4 (RFC4361). Do tego celu zostało użyte pole "Type" o wartości "255". Znajduje się po nim opisany niżej unikalny identyfikator węzła.

Wspomniany indentyfikator węzła daje możliwość klientowi używania na każdym z interfejsów zarówno takiej samej, jak i różnej konfiguracji od serwera DHCP. Dodatkowo, kiedy konfiguracje te są różne, serwer DHCP zawsze wie, że należą one do tego samego klienta. Klient może też używać tego samego identyfikatora do uzyskania adresu IPv4 i IPv6.

Aby to osiągnąć, unikalny identyfikator węzła został podzielony na dwie części. Jedną z nich jest DUID (DHCP Unique Identifier), który jednoznacznie identyfikuje danego klienta. Drugą IAID (Identity Association Identifier), który identyfikuje otrzymane IA (Identity Association) i musi być unikalny w ramach danego klienta DHCP. Każde IA jest oddzielną konfiguracją adresów od serwera DHCP i musi być powiązane z jednym z IAID danego klienta DHCP. Wszystkie IAID należące do tego samego klienta muszą mieć zawsze tą samą wartość DUID. Ten sam DUID stosowany jest dla DHCPv4 i DHCPv6.

IAID ma zawsze 4-oktety, a DUID może mieć różną długość (2-oktety "Type Code" i do 128-oktetów na właściwy identyfikator). Wartość DUID musi być unikalna pomiędzy klientami. Zostały zdefiniowane trzy różne sposoby generowania wartości DUID:

• [ "Type Code" = 1 ]: DUID-LLT (Based on Link Local Address Plus Time) - bazuje na typie adresu sprzętowego, adresie warstwy łącza danych i czasie. Przeznaczony dla urządzeń nie posiadających zainstalowanych na stałe kart sieciowych. Powstały w ten sposób DUID powinien być stosowany przez system nawet po wyjęciu użytej do jego wygenerowania karty sieciowej.
• [ "Type Code" = 2 ]: DUID-EN (Assigned by Vendor Based on Enterprise Number) - bazuje na unikalnym identyfikatorze producenta i przydzielonej przez niego wartości identyfikatora. Przeznaczony dla systemów wbudowanych w konkretne rozwiązania, gdzie generuje go producent.
• [ "Type Code" = 3 ]: DUID-LL (Based on Link Local Address) - bazuje na typie adresu sprzętowego i adresie warstwy łącza danych. Przeznaczony dla urządzeń z przytwierdzonym na stałe interfejsem karty sieciowej (np. interfejs na płycie głównej).

O ile adres warstwy łącza danych może zostać wybrany z interfejsu, który w trakcie generowania DUID podłączony jest do sieci z serwerem DHCP, to bardziej istotne jest to, aby zapewniał on unikalność. Wygenerowany raz DUID jest stosowany później na wszystkich interfejsach. Wartość czasowa, to wartość modulo 2³² z ilości sekund od północy 1 stycznia 2000 roku (UTC). Typ adresu sprzętowego musi być poprawnie nadaną przez  IANA (Internet Assigned Numbers Authority) wartością "Hardware Type". Unikalny identyfikator producenta jest numerem "Private Enterprise Number", jaki również przydzielany jest przez IANA.

Jeżeli pole "Type" zawiera wartość "0", to identyfikator ma inną wartość. Najczęściej jest to jakiś ręcznie wpisany ciąg znaków ASCII.

Zastosowanie w protokole DHCP pola "chaddr" do identyfikacji klienta i przypisywania adresów IP jest przestarzałe i nie powinno być już stosowane. Niemniej, ciągle stosowane jest dla klientów BOOTP. Nie dołączają oni opcji 61 "Client Identifier". Urządzenia stosujące BOOTP ciągle są spotykane w sieciach. Najczęściej są nimi jakieś już dość stare drukarki. DHCP realizuje powiązanie konfiguracji z zawartością pola "chaddr" tylko wtedy, gdy w polu "options" nie jest przenoszona opcja 61 "Client Identifier".

Na poniższym slajdzie, w czarnej tabelce znajduje się zestawienie reguł dotyczących sposobu generowania odpowiedzi przez serwer DHCP (pole "op" nagłówka ma wartość "1" oznaczającą "BOOTREPLY"). To, w jaki sposób zostanie wygenerowana odpowiedź, zależne jest od zapytania DHCP (pole "op" nagłówka ma wartosć "2" oznaczające "BOOTREQUEST").

Jeżeli klient ma już adress (pole "ciaddr" jest niezerowe), to bez względu na ustawienie bitu "broadcast" pola "flags", odpowiedź zawsze zostanie wysłana na adres skierowany, wskazany w połu "ciaddr", w warstwie trzeciej i adres skierowany warstwy łącza danych określony z użyciem protokołu ARP. Drugim wierszem tej tabeli zajmiemy się trochę dalej, kiedy będziemy omawiać działanie przekaźnika DHCP. Ostatnie dwa wiersze tabeli dotyczą scenariusza, w którym klient nie posiada jeszcze adresu. W takim przypadku wartość flagi "broadcast" pola "flags" określa to, w jaki sposób będzie generowana odpowiedź. Jeżeli pole "broadcast" ma wartość "0", to odpowiedź w warstwie trzeciej zostanie wysłana na adres z pola "yiaddr", a w warstwie drugiej na adres z pola "chaddr". Protokół ARP nie jest używany, gdyż klient nie ma jeszcze adresu IP, więc niebyłby w stanie odpowiedzieć na zapytanie ARP. Jeżeli pole "broadcast" ma wartość "1", to odpowiedź zostanie wysłana na adres rozgłoszeniowy w warstwie drugiej i trzeciej.

W każdej wiadomości DHCP musi znajdować się opcja 53 "DHCP Message Type". Określa ona typ wiadomości DHCP. Do najbardziej popularnych typów wiadomości DHCP zalicza się m.in. (istnieje dużo więcej typów wiadomości DHCP):

• DHCPDISCOVER - wysyłane przez klienta (najczęściej rozgłaszane) w celu zlokalizowania dostępnych serwerów DHCP.
• DHCPOFFER - wysyłane przez serwer DHCP w odpowiedzi na DHCPDISCOVER. Zawiera ofertę parametrów konfiguracyjnych.
  
• DHCPREQUEST - żądanie oferowanych parametrów od wybranego serwera DHCP i niejawne odrzucenie ofert od wszystkich pozostałych. Stosowane także do potwierdzenia poprawności wcześniej przydzielonego adresu (np. po restarcie systemu) i do przedłużenia dzierżawy. Wysyłane przez klienta.
• DHCPDECLINE - informacja od klienta o tym, że otrzymany adres jest już zajęty (używany przez inny węzeł).
• DHCPACK - pozytywna odpowiedź na żądanie DHCPREQUEST z parametrami konfiguracyjnymi od serwera DHCP.
• DHCPNAK - negatywna odpowiedź na żądanie DHCPREQUEST od serwera DHCP (np. dzierżawa wygasła lub nie ta podsieć).
• DHCPRELEASE - zwolnienie dzierżawy przez klienta DHCP.
• DHCPINFORM - zapytanie klienta o dodatkowe parametry konfiguracyjne (klient posiada już adres).

Na powyższym slajdzie została zobrazowana typowa interakcja pomiędzy klientem, a serwerem DHCP. Warto ją bardziej wnikliwie przeanalizować. W większości przypadków DHCPDISCOVER będzie wysyłane na adres rozgłoszeniowy (ang. broadcast). Niemniej dopuszcza się przypadek, w którym klient zna serwer DHCP i wtedy wysyła takie zapytanie na adres skierowany (ang. unicast). Jest to widoczne w obramowaniu z lewej strony osi. DHCPDISCOVER może zawierać opcje sugerujące konkretny adres oraz długość czasu dzierżawy. Bardziej klasyczny przypadek, pokazujący całą procedurę uzyskania parametrów konfiguracyjnych pokazuje najdłuższa oś po środku. Klient wysyła tam DHCPDISCOVER na adres rozgłoszeniowy. Wiadomość ta dociera do wszystkich serwerów DHCP. Każdy z serwerów DHCP wysyła do klienta DHCPOFFER, gdzie w polu "yiaddr" i innych opcjach pola "options" umieszczone zostają oferowane parametry konfiguracyjne. Serwer DHCP powinien wcześniej sprawdzić, czy oferowany adres nie jest już używany w sieci (zachowanie to jest konfigurowalne w Cisco IOS). Klient może otrzymać ofertę z jednego lub większej ilości serwerów DHCP. Klient wybiera jedną z ofert. Najczęściej będzie to ta oferta, która zawiera wcześniej używaną konfigurację lub przyszła jako pierwsza. To czy oferta została wysłana na adres rozgłoszeniowy czy skierowany, zależne jest od ustawienia bitu "broadcast" w polu "flags" wiadomości DHCPDISCOVER. Na rysunku poniżej widać oba warianty. Kiedy oferta zostanie już wybrana, klient wysyła na adres rozgłoszeniowy DHCPREQUEST. W wiadomości tej musi zostać umieszczona opcja 54 "Server Identifier", która wskazuje wybrany serwer DHCP, co też jest niejawnie odrzuceniem oferty od wszystkich pozostałych serwerów. W ten sposób niewybrane serwery DHCP wiedzą, że klient nie wybrał ich oferty. Jeżeli wybrany w DHCPREQUEST serwer DHCP nadal może przydzielić oferowane parametry konfiguracyjne, wprowadza stosowne wpisy do tablicy powiązań DHCP (ang. DHCP Bindings) i wysyła do klienta DHCPACK z listą parametrów konfiguracyjnych. Jeżeli na tym etapie serwer DHCP jednak nie może już przydzielić tej konfiguracji, wysyła w odpowiedzi DHCPNAK i klient musi rozpocząć całą procedurę od początku (widać to w obramowaniu u dołu głównej osi powyższego slajdu). Po odebraniu DHCPACK klient przeprowadza ostateczną weryfikację. Sprawdza z użyciem procedury DAD (Duplicate Address Detection), czy otrzymany adres nie jest używany w sieci. Jeżeli nie jest, przypisuje go do interfejsu. Jeżeli jest, wysyła do serwera wiadomość DHCPDECLINE i rozpoczyna całą procedurę na nowo (widać to na slajdzie powyżej, na prawo od głównej osi - fioletowy przebieg wymiany wiadomości DHCP).

Na głównej osi powyższego slajdu, pomiędzy dwiema fioletowymi liniami przerywanymi w poziomie, widać dalszą, okresową wymianę wiadomości DHCPREQUEST i DHCPACK. Jest ona powiązana z przedłużaniem już posiadanej przez klienta dzierżawy. Na prawo od głównej osi, pomiędzy tymi samymi liniami widać też opcjonalną wiadomość DHCPINFORM od klienta, który posiada już adres, ale prosi o dodatkowe parametry konfiguracyjne.

Jeżeli dzierżawa nie wygasła, a klient chce ja zwolnić, wysyła do serwera DHCPRELEASE.

Dynamiczna alokacja rezerwuje adres na określony czas, zwany czasem dzierżawy (ang. lease time). Jest on określany z użyciem opcji 51 "IP Address Lease Time". Klient może korzystać z otrzymanego adresu do czasu upłynięcia tego czasu dzierżawy.

Jeżeli dzierżawa nie dobiegła końca, klient może ją przedłużyć. Domyślnie jest to realizowane po upłynięciu czasu T1, określonego z użyciem opcji 58 "Renewal (T1) Time Value". Jeżeli się to nie uda, to jeszcze przed wygaśnięciem dzierżawy, a po minięciu czasu T2, określonego w opcji 59 "Rebinding (T2) Time Value", klient stara się uzyskać jakąkolwiek konfigurację umożliwiającą dalsze działanie w sieci. W tym celu zaczyna na nowo rozgłaszać swoje zapytanie by zlokalizować jakikolwiek serwer DHCP. W ten sposób stara się on zachować jak najdłuższą ciągłość działania w sieci, do czego wymagane jest posiadanie odpowiedniego adresu.

Zarówno proces odnowienia obecnej dzierżawy, jak i dalej proces otrzymania całkiem nowego adresu realizowany jest w miarę upływu czasu z coraz to większą częstotliwością. Widać to na wykresie w prawym górnym rogu powyższego slajdu.

W związku z tym, że proces uzyskania adresu korzysta z rozgłaszania, domyślnie działanie DHCP jest ograniczone do lokalnego segmentu sieci. Niemniej, serwery DHCP nie znajdują się zawsze, w każdym z lokalnych segmentów sieci. Szczególnie tych średnich i większych sieci. Tam, gdzie istnieje duża ilość logicznych sieci VLAN oraz lokalizacji, byłoby to zbyt problematyczne w realizacji i potem dalszym utrzymaniu. O wiele wygodniej jest korzystać z jednego lub dla rendundancji kilku scentralizowanych serwerów DHCP. W szczególności, kiedy chodzi o obsługę komputerów i urządzeń mobilnych użytkowników.

Rozwiązaniem tego problemu jest przekaźnik DHCP (ang. DHCP Relay). Przekaźnik DHCP odbiera wysyłane do serwerów DHCP pakiety rozgłoszeniowe i przekazuje je do nich z użyciem transmisji skierowanej. Dzięki temu, serwer czy serwery DHCP, mogą zostać umiejscowione w całkiem innym segmencie sieci, a nawet w innej lokalizacji. Przed przekazaniem wiadomości do serwera, przekaźnik DHCP wstawia adres IP z interfejsu, na którym odebrał tę wiadomość, do pola "giaddr" w nagłówku wiadomości DHCP. Dzięki temu polu, serwer DHCP wie, z jakiej puli adresów powinien oferować klientowi parametry konfiguracyjne. Będzie to ta pula, której adresy należą do tej samej podsieci, co adres umiejscowiony w polu "giaddr".

Do wyboru odpowiednich parametrów konfiguracyjnych dla klienta można też użyć opcji 82 "Relay Agent Information Option", która opcjonalnie może zostać dołączona przez przekaźnika DHCP. Opcja 82 nie jest przekazywana do klienta DHCP.

Wróćmy jeszcze do drugiego wiersza czarnej tabeli. Jeżeli serwer DHCP otrzyma zapytanie, w którym pole "giaddr" ma niezerową wartość (zapytanie od przekaźnika DHCP), to odpowiedź zostanie wygenerowana na adres skierowany, wskazany w polu "giaddr" w warstwie trzeciej i adres skierowany warstwy łącza danych określony z użyciem protokołu ARP. Wiadomość od serwera do przekaźnika DHCP zostanie wysłana na port 67/udp, a nie 68/udp. Komunikacja pomiędzy serwerem DHCP i przekaźnikiem DHCP odbywa się z użyciem tylko portu 67/udp (port źródłowy 67/udp i port docelowy 67/udp). Port 68/udp dotyczy tylko klienta.

Przekaźnik DHCP potrzebny jest do momentu, w którym klient uzyska adres i pozna tożsamość (adres) serwera DHCP. Od tego momentu klient komunikuje się już bezpośrednio z serwerem DHCP. Zostało to zobrazowane na niebieskiej osi powyższego slajdu, zaraz za pierwszą fioletową linią przerywaną w poziomie. Na tym etapie warto dokładnie przeanalizować znajdujący się tam przebieg wymiany wiadomości DHCP z dodatkowym zaangażowaniem zarówno przekaźnika DHCP, jak i proxy DHCP.

Zdarza się, że nie chcemy aby klient poznał tożsamość serwera DHCP. Najczęściej z powodów bezpieczeństwa lub też chęci kierowania wszystkich wiadomości przez określone urządzenie. W takim celu stosowane jest proxy DHCP (ang. DHCP Proxy). Cała komunikacja pomiędzy klientami i serwerami DHCP przechodzi zawsze przez proxy DHCP. Klienci nigdy nie poznają tożsamości prawdziwego serwera DHCP. Zostało to zobrazowane na osi widocznej w prawym dolnym rogu powyższego slajdu. Do ukrycia tożsamości serwera DHCP dochodzi poprzez modyfikację opcji 54 "Server Identifier", która wskazuje na proxy DHCP.

O ile w systemie Cisco IOS usługa serwera i przekaźnika DHCP jest domyślnie aktywna, to do działania wymaga dodatkowej konfiguracji. Aby wyłączyć te usługi, należy użyć polecenia trybu konfiguracji globalnej: "no service dhcp".

Konfiguracja usługi serwera DHCP składa się z 2 kroków. Wykluczenia odpowiednich zakresów z dynamicznej alokacji i konfiguracji puli adresowej z parametrami konfiguracyjnymi.

Zwykle w ramach jednej podsieci stosuje się zarówno adresację statyczną, jak i dynamiczną. Statycznie skonfigurowany adres IP posiada zarówno brama domyślna, jak i często różne urządzenia i serwery usługowe. Dobrze, aby serwer DHCP nie próbował przydzielać adresów z zakresów, jakie przewidzieliśmy do innych zastosowań niż dynamiczna alokacja. Aby tego dokonać, należy posłużyć się poleceniem trybu konfiguracji globalnej: "ip dhcp excluded-address". W peleceniu tym można wskazać zarówno pojedynczy adres, jak i zakres adresów w formie od do. Każde kolejne wydanie tego polecenia powoduje dodanie kolejnego wykluczenia z dynamicznej alokacji. Aby usunąć dane wykluczenie, należy użyć formy "no" tego polecenia.

Następnym krokiem jest konfiguracja puli czy też pól z parametrami konfiguracyjnymi. Warto nadać jej jakąś intuicyjną nazwę, która sprawi, że nasza konfiguracja będzie się sama dokumentować. Aby tego dokonać należy użyć polecenia trybu konfiguracji globalnej: "ip dhcp pool". Po wydaniu tego polecenia wejdziemy do trybu konfiguracji puli DHCP, gdzie dostępna będzie masa parametrów konfiguracyjnych. Aby się z nimi zapoznać należy użyć "?". My przejdziemy tylko przez kilka najbardziej popularnych, których nazwy nie wymagają większego komentowania. Należy do nich "network" po którym podajemy adres sieci i maskę (zapis kropkowo dziesiętny lub z prefiksem), "default-router" po którym podajemy adres IP bramy domyślnej, "dns-server" po którym podajemy listę serwerów DNS oraz "domain-name" po którym podajemy nazwę domenową.

Do weryfikacji przyznanych dzierżaw służy polecenie trybu EXEC: "show ip dhcp binding". Po wydaniu tego polecenia zobaczymy po jednym wierszu dla każdej przydzielonej konfiguracji. Widać tam przyznany adres, identyfikator klienta oraz czas dzierżawy.

Nasz przykład pokazuje dwa wpisy w tablicy powiązań. Na zielonawym tle widać wpis dla identyfikatora klienta zaczynającego się od "01". Na żółtawym tle widać identyfikator zaczynający się od "00". Pierwszy oktet tych identyfikatorów znajduje się w czerwony obramowaniu. Ten zaczynający się od "01" wygenerowany został na podstawie pul "Hardware Type" i "Hardware Address". Zatem w naszym przykładzie bazuje ona na adresie MAC karty sieciowej Ethernet. Na początku adresu MAC została wstawiona wartość "01" określająca technologię Ethernet. Drugi, zaczynający się od "00" został zdekodowany i zapisany z użyciem ASCII z lewej strony slajdu, na żółtym tle. Jest to domyślna konstrukcja identyfikatora klienta, jaką generuje router z systemem Cisco IOS na interfejsie, który pobiera dynamicznie adres IP z serwera DHCP. Identyfikator ten składa się z trzech elementów. Nazwy producenta "cisco", adresu MAC interfejsu sieciowego "c800.844c.4c63" oraz skróconej nazwy interfejsu "Gi0", gdzie separatorem jest znak "-".

Przydatne też bywa polecenie trybu EXEC: "show ip dhcp server statistics". Udostępnia ono informacje statystyczne dotyczące m.in. zużywanej pamięci przez usługę serwera DHCP oraz ilości odbieranych i wysyłanych typów wiadomości BOOTP i DHCP.

W ramach każdej puli DHCP można wskazać inny czas dzierżawy. Domyślnie wynosi on 24-godziny. Do modyfikacji czasu dzierżawy służy polecenie trybu konfiguracji puli DHCP: "lease". Jeżeli chcemy wskazać czas krótszy niż kilka dni, to ilość dni musi zostać ustawiona na zero. Jeżeli chcemy wskazać w nim czas krótszy niż kilka godzin, to należy zarówno dni, jak i godziny ustawić na zero.

Tylko podstawowe i najbardziej popularne parametry mają swoje nazwy i dostępne są w trybie konfiguracji puli DHCP w postaci dedykowanego polecenia. Pozostałe można konfigurować z użyciem polecenia trybu konfiguracji puli DHCP: "option". Na slajdzie powyżej widać przykład konfiguracji opcji 150. Wskazujemy tam adres IP serwera TFTP z konfiguracją dla telefonów IP.

Przy konfiguracji konkretnego adresu IP dla konkretnego urządzenia najcześciej stosuje się dodatkowe, dedykowane pule. Warto stosować dla nich odpowiednie nazwy, które pozwolą powiązać je z danym urządzeniem. Do wskazania konkretnego urządzenia, w konfiguracji puli DHCP należy podać jego identyfikator klienta. Służy do tego polecenie trybu puli DHCP: "client-identifier". Jeżeli jest to komputer, to najczęściej taki identyfikator będzie zawierał na początku "01" i dalej adres MAC jego karty sieciowej. Gdy mamy do czynienia ze starszym typem urządzenia, które obsługuje BOOTP, należy skorzystać z polecenia trybu konfiguracji puli DHCP: "hardware-address", po którym należy podać jego adres MAC. Kolejnym krokiem jest wskazania konkretnego adresu, z jakiego urządzenie to powinno korzystać. Do tego celu służy polecenie konfiguracji puli DHCP: "host". Polecenia konfiguracji puli DHCP "network" i "host" wzajemnie się wykluczają, stąd nie da się użyć obu w tej samej puli DHCP.

W ramach puli dla pojedynczego hosta można również wskazać szereg innych parametrów. Jeżeli tego nie zrobimy, to zostaną one odziedziczone z puli nadrzędnej. Dziedziczenie parametrów realizowane jest w oparciu o hierarchię adresową (podsieci i nadsieci). Jeżeli adres ("host") lub podsieć ("network") danej puli jest mniejszą częścią podsieci innej puli, to domyślnie dziedziczone są z tej puli nadrzędnej parametry konfiguracyjne, które nie zostały zdefiniowane w puli podrzędnej. Zatem w puli podrzędnej każdy z parametrów może zostać nadpisany. Zachowanie takie jest porządane i wygodne jako, że często definiujemy parametry konfiguracyjne wspólne dla całej podsieci w puli z adresami dynamicznymi, a następnie tworzymy pule dla kilku pojedynczych hostów, gdzie nie musimy już ponownie powielać wartości dla tych samych parametrów.

W naszym przykładzie widać dwie pule dla pojedynczego hosta. Ta na niebieskawym tle dotyczy klienta DHCP, a ta na zielonawym klienta BOOTP. Obie pule są w zakresie puli nadrzędnej dla całej podsieci 10.1.0.0/23. Zatem odziedziczą one zdefiniowane w niej parametry bramy domyślnej, serwerów DNS oraz nazwy domenowej.

Konfiguracja przekaźnika DHCP jest bardzo prosta. Należy wejść do konfiguracji interfejsu bezpośrednio podłączonego do sieci, gdzie działają klienci DHCP i użyć w nim polecenia "ip helper-address". Parametrem tego polecenia jest adres IP serwera DHCP. Na danym interfejsie należy użyć tego polecenia po jednym razie dla każdego serwera DHCP.

Polecenie "ip helper-address" dodatkowo włączy przekazywanie do wskazanego czy wskazanych adresów IP także innych pakietów rozgłoszeniowych. Aby je wykluczyć, należy posłużyć się poleceniem trybu konfiguracji globalnej: "no ip forward-protocol udp". Lista dodatkowych numerów portów, dla których domyślnie włączone jest przekazywanie pakietów rozgłoszeniowych, została wyszczególniona na slajdzie. W naszym przypadku istotne jest przekazywanie tylko 67/udp.

Do weryfikacji skonfigurowanych przekaźników DHCP służy polecenie trybu EXEC: "show ip interface".

Aby aktywować na interfejsie dynamiczne pobieranie adresu (klient DHCP) z serwera DHCP, należy w trybie jego konfiguracji użyć polecenia: "ip address dhcp". Wydanie tego polecania bez żadnych parametrów sprawi, że identyfikator klienta przybieże postać widoczną na czerwonawym tle poniższego zrzutu poleceń. Na samym jego początku mamy "00", a dalej ciąg znaków według wzorca "cisco-chaddr-INTERFACE". Widzieliśmy go już 4-slajdy wyżej na żółtawym tle. Z użyciem parametru "client-id ascii" tego polecenia, można podać własny ciąg znaków, który przyjmie postać identyfikatora klienta. Widać to na niebieskawym tle.

Najczęściej jednak stosuje się parameter "client-id" po którym podaje się nazwę interfejsu, z którego mają zostać użyte parametry dla identyfikatora klienta. Jego użycie widać na zielonawym tle.

Aby zwolnić otrzymaną dzierżawę, należy użyć polecenia trybu EXEC: "release dhcp". Wskazujemy po nim interfejs, na którym zostało skonfigurowane dynamiczne pobieranie adresu z użyciem DHCP. O ile odnowienie dzierżawy następuje automatycznie, to można je wymusić z użyciem polecenia trybu EXEC: "release dhcp", po którym wskazuje się odpowiedni interfejs.

Cisco IOS posiada dodatkowy mechanizm, który umożliwia serwerowi DHCP zapamiętywanie zwolnionych dzierżaw. Domyślnie są one usuwane. Dzięki tym informacjom jest on w stanie przydzielać w późniejszym czasie ponownie te same adresy. Zapamiętane tak wpisy są usuwane dopiero, kiedy zabraknie wolnych adresów. Aby tę funkcję aktywować, należy użyć polecenia trybu konfiguracji globalnej: "ip dhcp remember". Po jej włączeniu, zwolnione adresy zostaną oznaczone w wyniku polecenia trybu EXEC: "show ip dhcp binding" w kolumnie "Type" jako "Remembered". Ich użycie będzie możliwe, kiedy ponownie o dzierżawę poprosi ten sam identyfikator klienta lub kiedy zabraknie w puli wolnych adresów.

Do weryfikacji otrzymanej dzierżawy w systemie Cisco IOS służy polecenie trybu EXEC: "show dhcp lease". Widać tam m.in.: czas dzierżawy, czasy T1 i T2, otrzymany adres IP, maskę, bramę domyślną oraz zastosowany do tego celu identyfikator klienta.

Informacje o znanych serwerach DHCP można wyświetlić z użyciem polecenia trybu EXEC: "show dhcp server". Widać tam też dodatkowe parametry, jak serwery DNS czy nazwa domenowa oraz statystyki wysłanych i otrzymanych wiadomości DHCP.

Domyślnie, dystans administracyjny dla otrzymanej od serwera DHCP bramy domyślnej wynosi 254. Brama domyślna widoczna jest powyżej, na czerwonawym tle w wydruku polecenia trybu EXEC: "show ip route" (dystans administracyjny widać linijkę niżej).

O ile wpisy w tablicy powiązań wygasają same po minięciu czasu dzierżawy (jeżeli nie zostanie ona odnowiona), to można też je usuwać ręcznie. Służy do tego celu polecenie trybu EXEC: "clear ip dhcp binding". Do usuwania zapamiętanych zwolnionych dzierżaw służy polecenie trybu EXEC: "clear ip dhcp remembered binding". Pule statyczne dla pojedynczych hostów należy usuwać z trybu konfiguracji globalnej poprzez użycie polecenia "no".

Należy pamiętać, że użycie tych poleceń nie powoduje usunięcia adresu na kliencie DHCP. Klient DHCP nadal będzie z tego adresu korzystał zgodnie z czasem dzierżawy, jaki wcześniej otrzymał. Podobnie będzie z innymi parametrami konfiguracyjnymi. Ich zmiana w puli DHCP nie spowoduje natychmiastowej zmiany po stronie klienta. Dlatego, jeżeli zależy nam na szybkiej aktualizacji parametrów, najlepiej na kliencie DHCP zwolnić konfigurację i wymusić ręcznie uzyskanie nowej lub po prostu go zrestartować.

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ą Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. lub telefonicznie +48 797 004 932 lub +48 797 004 938.