Linux Mint    Ubuntu    openSUSE    Asterisk    FreeBSD    Android    Nokia N900    Игры в Linux
 Linux Mint    Ubuntu     openSUSE     Asterisk     FreeBSD     Android     N900     Games

ISC DHCP Failover state и управление через API

В статье Варианты DHCP серверов с отказоустойчивой конфигурацией я пытался рассказать как настроить DHCP Failover. Сейчас я хочу рассказать о некоторых особенностях такой конфигурации и способах их устранения. И так начнем. 

DHCP Failover это протокол, который во время работы переводит сервера в различные состояния работы. Начнем по порядку.

1. STARTUP state - как понятно из названия это первое состояние после запуска. Во время этого состояния сервер обновляет информацию от соседа, если такой уже работает, и заносит информацию в свою базу данных dhcpd.leases. В этом состоянии на все запросы от клиентов он отвечает unrespon, что можно видеть в логах. 

dhcpd: failover peer test: I move from normal to startup
dhcpd: DHCPDISCOVER from d0:54:2d:02:5a:7f via 10.43.28.1: not responding (startup)
dhcpd: DHCPDISCOVER from d0:54:2d:02:4d:27 via 10.43.28.1: not responding (startup)

Стартовый период обусловлен несколькими правилами. Так например если сервер был в нерабочем состоянии меньше чем значение MCLT, то период составит от 5 до 10 секунд. Если он не работал больше чем MCLT то время запуска будет от 30 до 60 секунд, а может и больше.

2. NORMAL state - тут должно быть то же все понятно. Нормальная работа сервера согласно конфигурации.

3. COMMUNICATIONS-INTERRUPTED state - состояние невозможности соединиться с другим сервером, для обмена информации. Вот от сюда и и начинается особенность. В этом состоянии сервер работает как и работал обслуживая все ранее выданные адреса и добавляя в базу новых клиентов. Он не считает, что его партнер не работает, а предполагает, что партнер всего лишь не может с ним связаться. Таким образом он располагает только половиной выделенного пула. Так же в этом состоянии не работает балансировка нагрузки, что и правильно.

4. PARTNER-DOWN state - состояние, при котором сервер считает, что его партнер не работает. Это состояние похоже на MMUNICATIONS-INTERRUPTED state но только в этом сервер располагает всем пулом адресов.

У партнеров есть еще много различных состояний, но я остановился на этом.

Теперь возникает вопрос когда сервер переходит из состояния COMMUNICATIONS-INTERRUPTED в состояние PARTNER-DOWN? Согласно документа  для этого есть специальный период называемый "Safe Period". Целью данного периода дать возможность персоналу определить неисправность или восстановить связь с партнерами. Кто знает может STP решил дерево перестроить.

Длина этого периода зависит в основном от числа не занятого ip пула в пределах данной подсети и частоты появления новых клиентов DHCP. Таким образом этот период может длится до нескольких дней. В Cisco, к примеру, данный период составляет 24 часа.

А вот с ISC DHCP не повезло, у него нет данного периода и если один из партнеров перестанет работать, то состояние PARTNER-DOWN так и не наступит. Печалька.

Перевести сервер в состояние PARTNER-DOWN можно только в ручную используя OMAPI. Для этого в настройках сервера в global секции нужно добавить параметр

omapi-port 7911;

Производитель рекомендует

omapi-port 7911;
omapi-key omapi_key;

key omapi_key {
algorithm hmac-md5;
secret Ofakekeyfakekeyfakekey==;
}

Для генерации ключа нужно использовать команду

Key Generation Hint

You can generate good random OMAPI keys using the dnssec-keygen utility, distributed with BIND.

e.g.: dnssec‐keygen ‐a HMAC‐MD5 ‐b 512 ‐n USER DHCP_OMAPI

У меня закрытая сеть и настроенный фаервол, я ключи не использовал.

После того как вы добавили порт и рестартанули демон, можно начинать использовать omshell. Самый простой способ и самый удобный использовать скрипт, вот мой вариант:

#!/bin/sh
omshell << EOF
connect
new failover-state
set name = "tste"
open
set local-state = 8
update
EOF

Где имя - это имя вашего Failover, а 8 - это в какое состояние ему перейти.
Код: 

1 - startup
2 - normal
3 - communications interrupted
4 - partner down
5 - potential conflict
6 - recover
7 - paused
8 - shutdown
9 - recover done
10 - resolution interrupted
11 - conflict done
254 - recover wait

Ну и пример:

root@test:~# omshell << EOF
connect
new failover-state
set name = "test"
open
set local-state = 4
update
EOF

> obj: <null>
> obj: failover-state
> obj: failover-state
name = "test"
> obj: failover-state
name = "test"
partner-address = 70:2a:ce:38
partner-port = 00:00:02:08
local-address = 70:2a:cd:d8
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:0e:10
load-balance-max-secs = 00:00:00:05
load-balance-hba = ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 00:00:00:08
partner-stos = 52:e8:95:74
local-stos = 52:e9:d9:83
hierarchy = 00:00:00:00
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00
> obj: failover-state
name = "test"
partner-address = 70:2a:ce:38
partner-port = 00:00:02:08
local-address = 70:2a:cd:d8
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:0e:10
load-balance-max-secs = 00:00:00:05
load-balance-hba = ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 4
partner-stos = 52:e8:95:74
local-stos = 52:e9:d9:83
hierarchy = 00:00:00:00
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00
> obj: failover-state
name = "test"
partner-address = 70:2a:ce:38
partner-port = 00:00:02:08
local-address = 70:2a:cd:d8
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:0e:10
load-balance-max-secs = 00:00:00:05
load-balance-hba = ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 4
partner-stos = 52:e8:95:74
local-stos = 52:e9:d9:83
hierarchy = 00:00:00:00
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00

dhcpd: failover peer test: I move from communications-interrupted to shutdown

Я готовил статью некоторое время и совсем недавно все же нашел в исходниках как заставить демона перейти в состояние partner down через определенное время. Делается это просто добавлением в конфиг следующий параметр:

auto-partner-down sec; 

Вот и пояснение:

auto-partner-down sec; This statement specifies a sec seconds time delay upon entering the communications-interrupted state when the server is unable to communicate with its failover peer. The default is 0. This option should be used with care.

Как раз по умолчанию отключено. Вот же изверги. Ну хоть бы в каком-то мане написали это. Уже проверил работает.

Jan 30 22:45:17 test dhcpd: failover peer test: I move from communications-interrupted to startup
Jan 30 22:45:33 test dhcpd: failover peer test: I move from startup to communications-interrupted
Jan 30 22:46:33 test dhcpd: failover peer test: I move from communications-interrupted to partner-down

Ну хоть бы в одном мане про это написали!!!! нету нигде!!! Только в исходниках и на этом замечательном ресурсе ))))

jekson аватар

это же надо разобраться ) у меня никогда не хватает терпения

Habi аватар

Сам вот как раз разбираюсь с настройками DHCP. Вроде бы несложно, но нужно время, чтобы все понять.