проблема с DHCP

[inoyat]

Viva (KN-1912) RU,  3.9.2

 

interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    mac access-list type none
    security-level private
    ip address 192.168.0.1 255.255.255.0
    ip alias 192.168.12.254 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
 

ip dhcp pool _WEBADMIN
    range 192.168.0.50 192.168.0.199
    default-router 192.168.0.1
    dns-server 8.8.8.8
    lease 25200
    bind Home
    enable
 

В логах для некоторых клиентов вот такое:

DHCPDISCOVER received from cc:9d:a2:de:38:c0.

making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0.

DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0.

 

При этом не важно - клиент по проводу или "по воздуху".

[Илья Картавенко]

1 час назад, inoyat сказал:

Viva (KN-1912) RU,  3.9.2

 

interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    mac access-list type none
    security-level private
    ip address 192.168.0.1 255.255.255.0
    ip alias 192.168.12.254 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
 

ip dhcp pool _WEBADMIN
    range 192.168.0.50 192.168.0.199
    default-router 192.168.0.1
    dns-server 8.8.8.8
    lease 25200
    bind Home
    enable
 

В логах для некоторых клиентов вот такое:

DHCPDISCOVER received from cc:9d:a2:de:38:c0.

making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0.

DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0.

 

При этом не важно - клиент по проводу или "по воздуху".

Так это не ошибка. Выставьте для сегмента время аренды ip адреса 86400 секунд - 24 часа.  и все.

[inoyat]

18 минут назад, Илья Картавенко сказал:

Так это не ошибка. Выставьте для сегмента время аренды ip адреса 86400 секунд - 24 часа.  и все.

Как связано время аренды - и какие-то непонятные адреса из непонятного пула, которые выдаются клиентам?

[Илья Картавенко]

5 минут назад, inoyat сказал:

Как связано время аренды - и какие-то непонятные адреса из непонятного пула, которые выдаются клиентам?

Тогда проверяйте свои  настройки.

[inoyat]

2 минуты назад, Илья Картавенко сказал:

Тогда проверяйте свои  настройки.

Какие именно? DHCP-сервер работает, подавляющему большинству клиентов адреса раздаются согласно настройкам пула.

Однако у части клиентов - проблемы, выдается адрес из пула 0.0.0.Х

[Илья Картавенко]

1 час назад, inoyat сказал:

Viva (KN-1912) RU,  3.9.2

 

interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    mac access-list type none
    security-level private
    ip address 192.168.0.1 255.255.255.0
    ip alias 192.168.12.254 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
 

ip dhcp pool _WEBADMIN
    range 192.168.0.50 192.168.0.199
    default-router 192.168.0.1
    dns-server 8.8.8.8
    lease 25200
    bind Home
    enable
 

В логах для некоторых клиентов вот такое:

DHCPDISCOVER received from cc:9d:a2:de:38:c0.

making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0.

DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0.

 

При этом не важно - клиент по проводу или "по воздуху".

А у вас точно нет сегмента с таким пулом?

[inoyat]

1 минуту назад, Илья Картавенко сказал:

А у вас точно нет сегмента с таким пулом?

Точно

[Илья Картавенко]

10 минут назад, inoyat сказал:

Точно

Сколько устройств у вас в сети и сколько ip адресов разрешено выдавать в пуле?

[keenet07]

Проверьте нет ли в локалке какого-то устройства с собственным DHCP сервером. Он может шалить. Найти и отключить.

[sergeyk]

1 час назад, inoyat сказал:

Однако у части клиентов - проблемы, выдается адрес из пула 0.0.0.Х

Из вашего журнала видно, что он не выдаётся, а запрашивается клиентом.

DHCPDISCOVER received from cc:9d:a2:de:38:c0.
making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0.
DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0.

Строки выше означают, что

1. Сервер принял от cc:9d:a2:de:38:c0 широковещательный запрос на новый адрес.
2. Сервер предложил клиенту cc:9d:a2:de:38:c0 адрес 192.168.0.60.
3. Клиент cc:9d:a2:de:38:c0 прислал запрос на продление адреса 0.0.0.242.

[inoyat]

2 часа назад, sergeyk сказал:

Из вашего журнала видно, что он не выдаётся, а запрашивается клиентом.

Спасибо огромное!

Осталось понять причину такого поведения клиента

[Mamay]

1 час назад, inoyat сказал:

Осталось понять причину такого поведения клиента

То есть, DHCP (читаем keenetic) и не при делах вовсе. 

[inoyat]

36 минут назад, Mamay сказал:

То есть, DHCP (читаем keenetic) и не при делах вовсе. 

Все относительно....

Из замеченных в таком поведении клиентов - все новые iphone, а в логе выше - ТД Элтекс.

При этом - при замене кинетика на тупой TP-Link Archer C6 - все клиенты штатно получают адреса

Изменено 25 января, 2023 пользователем inoyat

[sergeyk]

5 часов назад, inoyat сказал:

Все относительно....

Из замеченных в таком поведении клиентов - все новые iphone, а в логе выше - ТД Элтекс.

При этом - при замене кинетика на тупой TP-Link Archer C6 - все клиенты штатно получают адреса

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

[Migel]

Явно в сети есть еще один DHCP...

[danil.ponomarev]

История такая... Долго с этим боролся, стоит в сети Microtik c DCHP, и ретрансляторы Keenetik парочку. Вот когда стоит режим Ретранслятор то логи в Микротике все синие, не может выдать адрес и соотнести с его MAC. 
Лечится только включением Keeneik в режим точки доступа,  DCHP отключить и  поставить внутренний адрес вручную из сети Микротик, без NAT и остальных галочек
Это первый вариант
Второй вариант включить Relay, и указать DCHP микротиком, в том же режиме Точки доступа. 
Оба варианта работают но лучше использовать первый
Еще "синева" возникала при подключении APPLE (в основном IPHONE), лечится в настройках айфона убрать галочки скрывать IP и подобное