Serverul Poky Little DHCP si Gasirea DORA

Este amuzant sa ne gandim la acea epoca si sa mergem rapid pana astazi, unde atributiile DHCP si strangerile de mana in 3 directii se intampla in milisecunde si nu vedem sau auzim nimic … daca ceva nu merge prost. Echipa Microsoft a pus recent la iveala o problema DHCP, care ne-a adus in minte cat de rapida este lumea astazi si cat de putin apreciem detaliile care se petrec sub acoperirea acestei viteze.

Povestea noastra incepe cu un raport conform caruia echipamentele client nu primesc sarcini DHCP de la serverul DHCP pe o scara foarte larga. Aici intra si DORA in aventura noastra … minus rucsacul. Orice fel de solutionare a problemelor DHCP necesita o intelegere a negocierii DORA: Descoperiti -> Oferta -> Cerere -> Confirmati. Inainte de a ne chema pentru asistenta, clientul a facut capturi de retea si a observat ca „A” din DORA (ACK sau Confirmare) nu sosea suficient de repede pentru a impiedica expirarea negocierii DHCP.

Prima regula de depanare. Aveti incredere, dar verificati . Pana in acest moment, nimeni nu captura trafic de pe serverul DHCP, asa ca trebuie sa vedem daca traficul paraseste serverul. O analiza rapida a capturii de retea de pe serverul DHCP a confirmat doua lucruri: DHCP ACKS erau trimise si ca DHCP ACKS erau trimise pe un ciclu extrem de intarziat. Administratorii de retea au verificat ca reteaua pentru acest site nu avea probleme ciudate de echilibrare a sarcinii / divizare a rutei sau de bucla de rutare, asa ca am concentrat atentia asupra performantei serverului DHCP.

Am verificat toti suspectii obisnuiti pentru performanta si nu au fost prezente probleme care sa ne determine sa suspectam ca CPU / Memorie / Disc / Retea au fost blocate. Contoare de performanta sunt disponibile pentru serverul DHCP, asa ca am aruncat o privire rapida acolo. Mai jos sunt contoare pentru serverul nostru DHCP, primul lucru care a iesit a fost ca Acks / Sec a fost anormal de scazut, doar sporadic saltand peste zero. De asemenea, retineti lungimea cozii active , ceea ce nu este normal. In cele din urma, contorul pentru milisecunde pe pachet (Avg) a fost foarte mare. Deci, acum incepem sa vedem un formular de coada pe server, dar adevarata intrebare este de ce?

Apoi, am facut cateva teste pentru a muta aproximativ jumatate din domeniile DHCP pe alt server pentru a vedea daca este ceva cu acel server. Jumatate din domenii au fost mutate pe un server partener pe site printr-o relatie de failover ad-hoc, cu failover eliminat lasand domeniile si configuratia lor pe serverul partener. Am verificat Perfmon si vedem ca aceleasi doua contoare ruleaza la niveluri ridicate. Deci, problema a urmat scopurile. Scopurile au fost mutate inapoi pe serverul original in blocuri pana cand contoarele au revenit in cele din urma la normal pentru a izola grupurile care aveau configuratia ofensatoare.

Cu perfmon care ruleaza pe masura ce domeniul de aplicare rau intra in pozitie, puteti vedea contorul Acks / Sec care reflecta intarzierea de sincronizare pe care o vedem in vizualizarea grafica:

Urmatorul pas a fost sa ne uitam la domeniile si optiunile de domeniu configurate pentru a vedea orice arata din loc. Acest mediu are o politica de configurare bine definita, astfel incat orice lucru iesit din comun tinde sa iasa in evidenta. Folosind unele PowerShell Fu, s-a constatat ca optiunile de scop pentru o statie de lucru utilizator au configurat un server TFTP si ceea ce ne-a atras atentia a fost ca numele serverului a fost specificat, nu adresa IP. Mai jos este comanda si iesirea pentru cautare:

Get-DhcpServerV4Scope | % {Write-Host „` r`n $ ($ _. Name) ”-ForegroundColor Red; Get-DHCPServerV4OptionValue –ScopeId $ _. ScopeId -OptionId 66 –ErrorAction SilentlyContinue}

Textul din coloana „Valoare” este ceea ce ati fi cautat. Captura de ecran de mai jos este doar un exemplu, iar „Valoarea” afiseaza valorile sirurilor reale care au fost introduse in Optiunea 66 pentru serverul TFTP.

In cazul nostru, am gasit un singur nume de eticheta, care a iesit din comun pentru configuratia lor normala. O verificare rapida a numelui serverului a aratat ca acesta nu putea fi rezolvat prin DNS si nici contactat in retea. Optiunea defuncta a fost eliminata de pe server si serviciul DHCP a repornit pe server si, ce stiti … Perfmonul serverului conteaza pentru lungimea cozii active si milisecundele pe pachet (Avg) a revenit la normal. Tradus liber, DORA este din nou fericita.

Pastrati-l simplu … cand configurati acest tip de lucruri, este intotdeauna o idee buna sa utilizati adresele IP in loc sa va bazati pe rezolutia numelui, mai ales atunci cand luati in considerare cat de devreme in configuratia retelei se afla acest proces. In cazul nostru, am avut si o problema de server inexistenta, dar presupunand ca era inca disponibila, utilizarea adresei IP scoate o veriga din lantul de complexitate pentru a ajunge la acel server TFTP. RFC5859 pentru adresa serverului TFTP specifica chiar utilizarea adresei IP pentru a elimina aceasta complexitate. Urmati sfaturile lor si pastrati lucrurile cat mai simple posibil.

In domeniul IT, rareori auziti recunostintele atunci cand lucrurile revin la normal, tacerea continutului trebuie sa fie muzica pentru urechi pentru a sti ca aveti lucruri fixate. In acest caz, schimbul fulgerator de DORA, strangeri de mana in 3 directii, negocieri TLS etc. sunt din nou in fundalul unde le apartine, utilizatorii concentrandu-se pe sarcinile lor de lucru / navigarea pe web / social media, indiferent ce fac utilizatorii normali in caz. 

Aveti grija si ramaneti in siguranta!