SK
Size: a a a
2020 July 02
VK
суть в том, что annyconnect после подключения добавлял опции в дхцп реквесты
VK
да, на езернет интерфейсе
VK
а жунипер продлевал лизу, но не отправлял ack клиенту )
VK
интересный баг был )
VK
я только запутался а баг кому направляли в циску что сует свои опшионсы куда не попадя или в джунипер?
в juniper. по rfc он должен просто игнорить и процессить реквест
VK
а он этого не делал, вернее делал на половину
Z
а жунипер продлевал лизу, но не отправлял ack клиенту )
продлевал, но не отправлял, т.е.?
VK
продлевал, но не отправлял, т.е.?
да
VK
ну тогда их попытка съехать выглядит забавно, да )
они пытались :
Hi Vladimir,
I spoke with engineering and ran some additional tests. I found that we do not support the PAD (0) option. Based on RFC 2132, this is not mandatory and would need to be implemented. Therefore, this is not a bug and will require an enhancement request/RLI to be submitted to request support of the PAD option. If required, you can work with your account representative to submit the RLI request.
Here is an observation and a question for you:
In the dhcp traceoptions log, I see the following log indicating a bad requested parameter:
Jul 21 10:03:07.684185 [NOTE] [default:default] parameter (0)
One question I do have is if the PAD option is needed in this case. I see that that immediately following the PAD(0) is a Private (240) option. Is this Private option configured on the DHCP server and does the client need it aligned? The configuration you provided does not have this option configured, so it would not be returned with or without the PAD (0).
I searched the database and the only other case I could find regarding this option was resolved by the customer replacing an old CPE that did not actually require the PAD options to be sent. I’m wondering if that is the case for you and your customer as well?
VA
Сергей Краснов
для этого нужно поэксплуатировать бушные 5010 и самому набить все шишки, по-моему : )
a смотрели arista 7050-64 / 7050-52 / 7124 ?