В тази статия ще се опитаме да създадем един срив DHCP сървър на MikroTik RouterOS.
Принципът на работа на DHCP
Тук ние се интересуваме от Client MAC Address поле. Това, че той ще бъде отговорен сървър.
Целият процес изглежда така:
Конфигуриране на DHCP Failover в Mikrtoik
За конфигурацията на DHCP сървър и клиент в Mikrotik RouterOS каза много. По-специално, в хода на Mikrotik Certified Network Associate - MTCNA. Там няма да се смятат за типичен настройка, и докосване на някои от нюансите, за да се осигури устойчивост на откази.
Помощ идва параметър Забавяне на прага. Уики Mikrotik каза:
Ако сек поле в пакета DHCP е по-малко от параметър закъснение-праг, тогава пакетът е игнориран от сървър DHCP. Ако е на висота - всички пакети ще бъдат обработени.
Пакетът DHCPREQUEST и поле DHCPDISCOVER секунди, като описва времето, което е изтекло от началото на дейността на клиента.
Факт е, че при липса на отговор от страна на сървъра, клиентът не почива на една заявка. Той ще изпрати заявки до сървъра с експоненциално нарастване на закъснението, за да не се наводни посланията си мрежа и по този начин все още се опитва да получи DHCPACK или DHCPOFFER.
Така че да забави-праг теренни проверки параметър секунди изтекли DHCPREQUEST пакет, и ако броят на секунди, посочени в тази област е по-малко от забавяне-праг, сървърът просто игнорира такива пакети. И ако повече, а след това да отговори на тях.
Заслужава да се отбележи, че в RouterOS 6.39.2, където прекарвам експерименти, забавяне праг засяга само пакетите DHCPDISCOVER.
Това означава, че можете да поставите на една и съща мрежа, две абсолютно идентични DHCP сървър, което означава, че имат различни параметри на забавяне-праг. Един проявява в нито един, а вторият в 10 секунди. Това означава, че първият сървър ще обработва всички искания и ако спре да отговаря, а след това всяка заявка, "мръсен" за 10 секунди, ще бъдат обработвани от втория сървър.
За да бъдем по-точни, ще се случи следното:
Клиент ---> DHCPDISCOVER ---> излъчване
Този пакет ще достигне двата сървъра, но като изтекли секундите = 0, тогава единственият отговор е сървъра, от който забавяне праг = няма
Server1 ---> DHCPOFFER ---> излъчване
Клиент ---> DHCPREQUEST ---> излъчване
Server1 ---> DHCPACK ---> клиент
Той премина на лизинг време / 2. Server1 все още жив
Тя ще изглежда, че задачата е завършена. DHCP услуга е запазено. Exchange Server информация за статични записи. В случай на счупване на един от сървърите, работата поема втория. След изключване на хост или ново искане DHCPDISCOVERY, приемащата превключва към главния сървър.
Имаше един малък неудобство. Script написани преди това се синхронизира с SERVER2 за запис server1. Това означава, че основната копие на текущата база данни се намира на един сървър, както и всички направени промени в SERVER2 няма да се репликират на server1. Ръчно прекъсване запис - не ни начин.
Можете, разбира се, да обхваща точно същия сценария на втория сървър и да ги настроите да работят заедно. Но ние ще отидем в другата посока.
Този метод не е описана в RFC, както може и му противоречат. Използвайте на свой собствен риск. Аз работя =)
Това е всичко! DHCP услуга е запазено. В случай на отказ на някой от мрежов сървър DHCP продължава да работи статични лизингови записи са синхронизирани. Разбира се, тук не сме решили проблема с шлюз провал, но това не е било предмет на гладно. Нека поговорим за това в следващия пост.