1. использую vlan-mon, shared=1
2. start=dhcpv4
3. посылаю DHCP запрос, mikrotik ( в качестве DHCP-клиента ) получает адрес, сессия поднимается, все норм
4. перетыкаю mikrotik в другой VLAN
5. mikrotik при этом адрес не сбросил, то есть в другом VLAN'е шлет не DISCOVER, а REQUEST
6. accel, при этом, на REQUEST отвечает ACK в VLAN, который vlan-mon поднял ранее; видно на картинке; <—— проблема именно в этом
7. если заставить mikrotik послать DISCOVER, то процесс авторизации проходит с самого начала и все ок.
По моему мнению, в описанном случае, mikrotik в другом VLAN'е - это новый клиент и ему нужно послать NAK при поступлении REQUEST'а без предварительного DISCOVER'а.
UPD: dimka88 предложил более правильный вариант, сообразный RFC - просто молчать в такой ситуации. Тогда клиент после нескольких REQUEST'ов без ответа пошлет DISCOVER.
DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е
DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е
- Attachments
-
- Selection_555.png (47.2 KiB) Viewed 3144 times
Re: DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е
IMHO это одна из разновидностей темы с переключальщиками viewtopic.php?f=10&t=2154.
Re: DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е
Тут немного другое, accel шлет ACK на REQUEST клиента в старый VLAN, который переехал в другой vlan. Т.е. по факту это можно считать новым клиентом, но никак не отправлять ACK в старый VLAN. Я с RFC немного накосячил, и меня поправил Владислав, сославшись на следующее, если прилетел сервер id, то должны реагировать, хоть NAK хоть ACK но реакция должна быть.KaYot wrote: ↑07 Dec 2018, 15:19 IMHO это одна из разновидностей темы с переключальщиками viewtopic.php?f=10&t=2154.
https://www.ietf.org/rfc/rfc2131.txt
Code: Select all
4.3.2 DHCPREQUEST message
A DHCPREQUEST message may come from a client responding to a
DHCPOFFER message from a server, from a client verifying a previously
allocated IP address or from a client extending the lease on a
network address. If the DHCPREQUEST message contains a 'server
identifier' option, the message is in response to a DHCPOFFER
message. Otherwise, the message is a request to verify or extend an
existing lease. If the client uses a 'client identifier' in a
DHCPREQUEST message, it MUST use that same 'client identifier' in all
subsequent messages. If the client included a list of requested
parameters in a DHCPDISCOVER message, it MUST include that list in
all subsequent messages.
Re: DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е
Тогда, выходит, мое первоначальное предположение - верно. Любопытно, реализует ли, в итоге, xeb?dimka88 wrote: ↑07 Dec 2018, 18:01Тут немного другое, accel шлет ACK на REQUEST клиента в старый VLAN, который переехал в другой vlan. Т.е. по факту это можно считать новым клиентом, но никак не отправлять ACK в старый VLAN. Я с RFC немного накосячил, и меня поправил Владислав, сославшись на следующее, если прилетел сервер id, то должны реагировать, хоть NAK хоть ACK но реакция должна быть.KaYot wrote: ↑07 Dec 2018, 15:19 IMHO это одна из разновидностей темы с переключальщиками viewtopic.php?f=10&t=2154.
https://www.ietf.org/rfc/rfc2131.txtCode: Select all
4.3.2 DHCPREQUEST message A DHCPREQUEST message may come from a client responding to a DHCPOFFER message from a server, from a client verifying a previously allocated IP address or from a client extending the lease on a network address. If the DHCPREQUEST message contains a 'server identifier' option, the message is in response to a DHCPOFFER message. Otherwise, the message is a request to verify or extend an existing lease. If the client uses a 'client identifier' in a DHCPREQUEST message, it MUST use that same 'client identifier' in all subsequent messages. If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages.