În acest articol, vom încerca să creăm un server DHCP tolerant la erori pe Mikrotik RouterOS.
Cum funcționează DHCP
Aici suntem interesați de câmpul MAC Address Client. Serverul va răspunde.
Întregul proces arată astfel:
Configurarea remedierilor de depanare DHCP în Mikrtoik
Sa spus mult despre înființarea unui server DHCP și a unui client în Mikrotik RouterOS. Inclusiv, în cursul asociatului de rețea certificat Mikrotik - MTCNA. Aici nu vom lua în considerare un set tipic, ci atingeți câteva nuanțe pentru a vă asigura toleranța la defecte.
Parametrul Pragul de întârziere ajunge la salvare. Wiki Mikrotik spune:
Dacă câmpul secunde din pachetul DHCP este mai mic decât parametrul de întârziere-prag, pachetul este ignorat de serverul DHCP. Dacă parametrul nu este setat la niciunul, toate pachetele vor fi procesate.
Pachetele DHCPREQUEST și DHCPDISCOVER au un câmp secundar care descrie timpul scurs de la începerea activității clientului.
Faptul este că, dacă nu există răspuns de la server, clientul nu se calmează la o singură cerere. Acesta va trimite cereri către server cu o creștere exponențială a întârzierii, astfel încât să nu inunde mesajele sale cu rețeaua și încă să încerce să obțină DHCPACK sau DHCPOFFER.
Deci, parametrul de întârziere-prag verifică câmpul scurs de secunde din pachetul DHCPREQUEST și dacă numărul de secunde specificat în acest câmp este mai mic decât pragul de întârziere, serverul ignoră pur și simplu astfel de pachete. Și dacă este mai mult, atunci îi răspund.
Aici merită menționat faptul că în RouterOS 6.39.2, pe care efectuez experimente, pragul de întârziere afectează numai pachetele DHCPDISCOVER.
Deci, puteți pune două servere DHCP absolut identice în aceeași rețea, precizând că au parametri de întârziere-prag diferite. La unul ne-am pus în nici unul, la al doilea în 10 secunde. Acest lucru înseamnă că primul server va procesa toate cererile și dacă nu mai răspunde, fiecare solicitare care este "fault" timp de 10 secunde va fi procesată de al doilea server.
Mai precis, se vor întâmpla următoarele:
Client ---> difuzare DHCPDISCOVER --->
Acest pachet va ajunge la ambele servere, dar din moment ce secunde scurs = 0, numai serverul cu prag de întârziere = none va răspunde
Server1 ---> DHCPOFFER ---> difuzat
Client ---> DHCPREQUEST ---> difuzat
Server1 ---> DHCPACK ---> client
Permisul de închiriere / 2. Server1 încă în viață
S-ar părea că sarcina este finalizată. Serviciul DHCP este rezervat. Serverele fac schimb de informații despre înregistrările statice. Dacă unul dintre servere eșuează, cel de-al doilea preia întreaga lucrare. După ce gazda este dezactivată sau cu o nouă solicitare DHCPDISCOVERY, gazda trece la serverul primar.
Există un mic neplăcut. Scriptul, scris mai devreme, sincronizează înregistrările serverului 1 cu server2. Aceasta este, principala copie curentă a bazei de date este pe același server și toate modificările efectuate pe server2 nu vor fi replicate la server1. Și înregistrările care întrerup manual nu sunt calea noastră.
Puteți, bineînțeles, să turnați exact același script pe al doilea server și să configurați munca în echipă. Dar vom urma o altă cale.
Această metodă nu este descrisă în RFC și, cel mai probabil, o contrazice. Utilizați-vă pe propriul risc. Funcționează =)
Asta este! Serviciul DHCP este rezervat. Dacă unul dintre serverele DHCP nu reușește, rețeaua continuă să funcționeze, înregistrările statice de închiriere sunt sincronizate. Desigur, aici nu am rezolvat problema eșecului gateway-ului, dar acest lucru nu a fost inclus în subiectul postului. Vom vorbi despre acest lucru în următoarele postări.
Trimiteți-le prietenilor: