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
March 19th, 2010 at 8:16 am
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”
March 19th, 2010 at 10:09 am
@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.
March 19th, 2010 at 12:54 pm
@Zygmunt … poprawione
March 19th, 2010 at 12:55 pm
@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 :).
March 21st, 2010 at 6:37 pm
“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.
March 23rd, 2010 at 11:11 am
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”
March 23rd, 2010 at 11:21 pm
@Krzysiu … co do BTW - czasami zapomnę skorygować autokorekty Live Writera
A ogólnie refleksję masz słuszną … tylko jak zwykle, życie ..
April 8th, 2010 at 11:07 am
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.
April 9th, 2010 at 12:46 am
@NPiotrek - A rozwiązanie najprostsze czyli porozmawianie z tym kto zarządza tym drugim serwerem nie wchodzi w grę?
April 9th, 2010 at 8:20 am
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