Friday, March 19th, 2010...1:16 am

Ruch sieciowy prawdę Ci powie … DHCP

Jump to Comments

Z niekończącej się serii przypadków pod wspólnym tutułem "Ruch sieciowy prawdę Ci powie" prezentujemy odcinek #1 … zagadka tajemniczego DHCP.

W życiu konsultant są takie dni, w których rozwiązuje problemy. Problemy są różne … czasami proste, czasami mniej proste. Ostatnio trafił do mnie problem z opisu dziwny, a mianowicie:

  • Stacja robocza w sieci znajdująca się uzyskiwała adres IP z serwera DHCP, tak jak być powinno
  • Po jakimś czasie, stacja ta zmieniała w swojej konfiguracji IP serwery DNS na inne, zaprzyjaźnione a jednak inne. Zaprzyjaźnione w tym wypadku oznacza, że znajdowały sie one w trochę inne lokalizacji I nazwy rozwiązywały też trochę inaczej.

Problem powodował inne problemy, na przykład takie że nazwy rozwiązywały sie na trochę inne adresy, co powodowało, że aplikacje użytkowników działały trochę inaczej.

Po fazie spekulacji różnych opcji I możliwości (jako że to Win7 to może Direct Access, albo ogólnie IPv6 albo I chochlik … tak, napewno chochlik) przyszedł czas prawdy ostatecznej – zajrzyjmy do ruchu sieciowego. I cóż tam widzimy …

Ruch prawdę Ci powie

… klient DHCP ma to do siebie, że zachłanny jest na adresy.  W celu tychże uzyskania rozsyła po sieci różnorakie żądania (rekłestami zwane). Rzeczony klient nasz takie żądania i  owszem wysyłał w postaci dyskusji:

  • DHCP Discover –> DHCP Offer
  • DHCP Request –> DHCP Ack.

Wynikiem takiej rozmowy jest uzyskanie przez klienta adresu IP. Nasz klient w tej konwersacji rozmawiała z serwerem lokalnym, nazwijmy go SerwerA (jakże oryginalnie).

Dla osób nie zaznajomionych I zastanawiających się skąd adres 255.255.255.255 przypominam że DHCP działa używając rozgłoszeń, broadcastam zwanych.

Prawem klienta DHCP jest dowiedzenie się więcej o swojej sieci. W tym celu, po uzyskaniu adresu IP może on posłużyć się pakietem DHCP Inform, celem uzyskania dodatkowych informacji. Odpowiedzią na taki pakiet jest DHCP Ack zawierający te dodatkowe opcję. I w przypadku naszego klienta takoż było:

(pełny rozmiar po kliknięciu)

Problem jedynie polegał na tym, że odpowiedzi na zadane pytanie DHCP Inform udzialał już serwer DHCP, który nazwiemy SerweremB, który grzecznie stał w sieci, prawdopodobnie za routerem i na zapytania czekał.

(pełny rozmiar po kliknięciu)

I tajemnica rozwiązana.

Ale wnioski, wnioski …

Wnioski z nauki są conajmniej dwa. Pierwszy to taki, że jeżeli  już w sieci znajdują się dwa serwery DHCP to warto zadbać o to, aby ich konfiguracja była spójna.

Drugia jak w tytule … ruch sieciowy prawdę Ci powie I czasami (w 95% pewnie bym zaryzykował) zamiast zastanawiać się co się dzieje warto sięgnąć po to narzędzie … parafrazując Dr Housa … ruch sieciowy nigdy nie kłamie.

No nic, miłego analizowania … 🙂

P.S.#1 Jeżeli ktoś jest zainteresowny co te wszystkie komunikaty znaczą to zapraszam do KB 169289 tudzież do RFC2131.

P.S #2. Co do serwerów DHCP to w Windows 2008 R2 zaszła mała zmiana co do obsługi rezerwacji – opisana w KB 2005980. Też wyszło najaw (dla mnie) przy okazji jakiegoś zapytania.

 

10 Comments

  • Zgadzam się, ludzie kłamią. Nawet jeśli o tym nie wiedzą. Często w dobrej wierze przekazują nie tyle fakty, co ich własną interpretację. Też zdecydowanie wolę logi i inne źródła informacji.

    A jeśli chodzi o przytoczony przez Ciebie przykład, to zapytam się nieśmiało: a ipconfig /all i linia “DHCP Server” 🙂

  • @PS#2
    w sumie zmiana logiczna – ale dobrze wiedzieć 🙂
    Przy okazji, link do KB ma kropkę na końcu, przez co… nie znajduje strony. Również bing na stronie błędu nie odnajduje artykułu. Dopiero google przychodzi z pomocą i wyjaśnia, że chodzi o tą nieszczęsną kropkę na końcu 🙂
    Pozdr.

  • @Zygmunt … poprawione 🙂

  • @Paweł
    I tutaj ciekawostka jest taka, że w takim przypadku ipconfig /all pokazuje w linii DHCP Server cały czas ServerA … ale dobra próba :).

  • “I tutaj ciekawostka jest taka, że w takim przypadku ipconfig /all pokazuje w linii DHCP Server cały czas ServerA … ale dobra próba :).” – moim zdaniem, zawsze będzie pokazywał serwer, który przydzielił samą adresację IP… czyli pokaże się serwerA.

    Chyba jedynym sensownym rozwiązaniem jest skonfigurowanie parametru opóźnienia “Delay in DHCP Offer” na drugim serwerze. Maksymalna wartość opóźniania to 1000 milli sekund.

  • A ja mam jednak inną refleksję. Niech każdy serwer DHCP ma taką konfigurację jaką mieć powinien w tym różny serwer DNS, wpisy o PXE, proxy itp. bo generalnie to skoro dwa serwery DHCP to znaczy że w różnych podsieciach zatem wszystko OK tylko czemu między tymi podsieciamy były puszczone brodcasty? Albo inaczej, czemu otwarcie bradcastów między sieciami nie zostało poprzedzone analizą czy nie trzeba czegoś filtrować. W tym wypadku taka analiza powinna podsunąć konieczność wyfiltrowania z broadcastów tego co powinno być przez “ServerA” obsłużone.

    BTW: czemu w tekście zamiast spójnika “i” piszesz “ja” 😉

  • @Krzysiu … co do BTW – czasami zapomnę skorygować autokorekty Live Writera 🙂

    A ogólnie refleksję masz słuszną … tylko jak zwykle, życie ..

  • A takie pytanie mam odnośnie tego artykułu. Mam podobną sytuację.
    W sieci są 2 serwery DHCP i stacja kliencka dostaje IP z jednego (ze wszystkimi parametrami: dns, brama,…) a po jakimś czasie dostaje parametry (dns itd) z drugiego serwera.
    Czy można jakoś się przed tym zabezpieczyć? Niestety oba serwery muszą być w sieci, z tym że tylko do konfiguracji jednego z nich mam dostęp.

    Będę wdzięczny za wszelkie sugestie.

  • @NPiotrek – A rozwiązanie najprostsze czyli porozmawianie z tym kto zarządza tym drugim serwerem nie wchodzi w grę?

  • No właśnie nie bardzo. To dosyć duża sieć w której działa ten inny DHCP, ja dostałem pewien zakres (w zasadzie 2) którymi mam zarządzać.
    sieć: 10.173.96.0 maska: 255.255.240.0
    moje zakresy to: 10.173.103.0-255 i 10.173.104.0-255
    Komputery z moich zakresów muszą mieć bramę: 255.255.240.0 i router 10.173.97.1
    Natomiast mój serwer DHCP ma IP: 10.173.102.12 maska jak wyżej.

    Wiem, trochę pokręcone. 🙂

Leave a Reply