разблокировка сети Bitlocker в среде SDA

[barryjm]

Да, я тоже так думаю, но не был уверен на 100%, поэтому мне было интересно, удалось ли кому-нибудь еще заставить это работать в своей среде. Мы также открыли заявку в TAC и предоставили им наши pcaps, так что, надеюсь, мы получим подтверждение, является ли это проблемой или нет.

[Andrii Oliinyk]

Пожалуйста, держите нас в курсе и удачи в решении проблемы.

[Kris Pellens]

Можете ли вы предоставить номер SR дела TAC, которое вы открыли?

[barryjm]

К сожалению, я не могу этого сделать, поскольку дело содержит информацию, которую наш клиент считает конфиденциальной. Однако я буду держать вас в курсе всех результатов и решений, которые мы получим от Cisco или Microsoft.

[Cristian Matei]

Привет, @barryjm
Можете ли вы попробовать включить на уровне порта в пути между клиентом и сервером BOOTP функцию
ip dhcp snooping trust
? Посмотрите, сработает ли это? Спасибо, Кристиан.

[Andrii Oliinyk]

эта функция включена по умолчанию в VLAN, доступных пользователям EN. Честно говоря, с моей точки зрения, нет смысла включать ее где-то на маршрутизируемом пути за пределами BN сайта.

[Cristian Matei]

Привет, @Andrii Oliinyk
Почему так? Я имел в виду, если не ясно, на пути второго уровня, вплоть до DHCP Relay. Спасибо, Кристиан.

[Andrii Oliinyk]

Поскольку DHCP DISCOVER связался с AnycastGW EN с помощью L2-переключения и где «ip dhcp snooping» изначально настроен на вставку опции информации, где еще, кроме конфигурации EN, можно увидеть «ip dhcp snooping vlan USER-VLAN»?

[Cristian Matei]

Привет, @Andrii Oliinyk
Проблема связана с процессом BOOTP, верно, а не с DHCP. Включив путь уровня 2 в качестве доверенного DHCP-сниффинга, возможно, не будет необходимости вставлять OPTION 82, который не поддерживается BOOTP (насколько я понимаю, это проблема, которую мы пытаемся решить). Спасибо, Кристиан.

[Andrii Oliinyk]

Проблема заключается в том, что EN не вставляет опцию 82 в пакет запроса BOOTP во время отслеживания DHCP, в то время как для обычного пакета DHCP это делается. Это должны решить BU и разработчики, а не сообщество.

[Cristian Matei]

Привет, @Андрей Олийник
Да, я неправильно понял, в чем заключается проблема. Спасибо, Кристиан.

[barryjm]

Да, из захваченных пакетов мы видим, что нормальный трафик DHCP 0.0.0.0 -> 255.255.255.255 попадает в SVI пограничного узла, который имеет адрес помощника, поэтому коммутатор теперь отправляет пакет на адрес помощника с IP-адресом источника в качестве IP-адреса SVI, а также вводит опцию 82 в пакет. Процесс DHCP продолжается и присваивает клиенту IP-адрес x.x.x.x. После того, как клиент получает IP-адрес, он отправляет запрос BOOTP, который является x.x.x.x -> 255.255.255.255, также с портом udp 67. Широковещательная передача снова попадает в SVI пограничного узла и снова пересылается с помощью вспомогательного адреса, который удаляет IP-адрес клиента x.x.x.x и заменяет его IP-адресом SVI, но на этот раз не вставляет опцию 82, поэтому когда обратный трафик возвращается в фабрику на пограничном узле, он попадает на IP-адрес интерфейса LISP на пограничном узле, и, поскольку в исходном запросе BOOTP нет опции 82, пакет не маршрутизируется дальше. Мы подозреваем, что опция 82 не вставляется в запрос BOOTP, поскольку он не содержит опцию 53, как запрос DHCP, так как к этому моменту клиенту уже был назначен IP-адрес, хотя это еще не подтверждено. Cisco в настоящее время анализирует информацию, которую мы им отправили, а наш клиент также открыл заявку в Microsoft.

[Cristian Matei]

Привет, @barryjm
Если вы решите эту проблему с помощью TAC, было бы здорово представить, есть ли WA, который можно выполнить на стороне Cisco. Между тем, не уверен, что следующее может работать / переопределять встроенные требования SDA, однако я бы попробовал. Либо глобально отключите проверку вставки опции 82 в ответ BOOTP с помощью команды
no ip dhcp relay information check
(это повлияет на все SVI), либо сделайте это на уровне SVI с помощью команды
ip dhcp relay information check-reply none
. Спасибо, Кристиан.