DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е

IPoE related questions
Post Reply
amindomao
Posts: 13
Joined: 17 Apr 2015, 08:59

DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е

Post by amindomao »

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.
Attachments
Selection_555.png
Selection_555.png (47.2 KiB) Viewed 3108 times
KaYot
Posts: 55
Joined: 25 Mar 2015, 10:54

Re: DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е

Post by KaYot »

IMHO это одна из разновидностей темы с переключальщиками viewtopic.php?f=10&t=2154.
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е

Post by dimka88 »

KaYot wrote: 07 Dec 2018, 15:19 IMHO это одна из разновидностей темы с переключальщиками viewtopic.php?f=10&t=2154.
Тут немного другое, accel шлет ACK на REQUEST клиента в старый VLAN, который переехал в другой vlan. Т.е. по факту это можно считать новым клиентом, но никак не отправлять ACK в старый VLAN. Я с RFC немного накосячил, и меня поправил Владислав, сославшись на следующее, если прилетел сервер id, то должны реагировать, хоть NAK хоть ACK но реакция должна быть.
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.
   
amindomao
Posts: 13
Joined: 17 Apr 2015, 08:59

Re: DHCP ACK при REQUEST'е от того же клиента в другом VLAN'е

Post by amindomao »

dimka88 wrote: 07 Dec 2018, 18:01
KaYot wrote: 07 Dec 2018, 15:19 IMHO это одна из разновидностей темы с переключальщиками viewtopic.php?f=10&t=2154.
Тут немного другое, accel шлет ACK на REQUEST клиента в старый VLAN, который переехал в другой vlan. Т.е. по факту это можно считать новым клиентом, но никак не отправлять ACK в старый VLAN. Я с RFC немного накосячил, и меня поправил Владислав, сославшись на следующее, если прилетел сервер id, то должны реагировать, хоть NAK хоть ACK но реакция должна быть.
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.
   
Тогда, выходит, мое первоначальное предположение - верно. Любопытно, реализует ли, в итоге, xeb?
Post Reply