01-12-2026 09:26 AM
Hello all,
My organization was testing Bitlocker Network Unlock in our SDA environment and was running into issues. I was curious if anyone else has setup network unlock in their SDA environment. I'm pretty sure the reason we are having issues is because the BOOTP request from the client is not getting tagged with option 82. I can see the BOOTP reply from the WDS server to the client but it never reaches the client which is making me think it is arriving on the border node and not going any further since option 82 is not being inserted in the BOOTP packet and it is using the SVI IP of the edge node which also exists on the border node. The DHCP packets are getting option 82 just not the BOOTP packets. If anyone has managed to get network unlock to work, were there any configurations you had to do other than setting the IP helper addresses and setting the port in low-impact mode with a pre-auth ACL?
Solved! Go to Solution.
01-24-2026 05:40 AM
is the SDA deployment with ISE integration with 802.1x ?
check this post :
https://community.cisco.com/t5/network-access-control/ise-with-bitlocker-network-unlock/td-p/4467087
=====️ Preenayamo Vasudevam ️=====
***** Rate All Helpful Responses *****
01-24-2026 10:42 AM - edited 01-24-2026 10:42 AM
solution for UEFI boot requests in non-SDA env. as it DOESNT require information option unlike to how SDA does for Fabric DHCP.
01-26-2026 06:14 AM
Dear barryjm,
Can you at least provide:
- the date/time you have opened the case?
- Cisco's team working on the case?
- the description of the case?
We've opened today case SR 700334461 with description: Bitlocker Network Unlock in SDA Environment not working.
Many thanks.
01-27-2026 05:09 AM
Answer from Cisco TAC:
Unfortunately, the BOOTP protocol does not support the option 82.
This is the reason why the Fabric Edge is not inserting this option in the packet.
A colleague from the BU is the one who filed the following document explaining the lack of support:
Doc Bug: BOOTP protocol not supported in SDA fabric
CSCwh46171
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh46171
Given the BOOTP protocol does not support the option 82, when the reply arrives to the border, the packet is dropped given there is no information on where to send this packet to. This is the process followed by the DHCP Offer packet.
The same issue was observed on several other cases with versions 17.6.x, 17.9.x and 17.12.x. So this situation has been observed repeatedly, due to the lack of support of the option 82 and thereby, the colleague from the BU filed the document, for awareness.
From the Cisco side there is no software image or workaround to address the issue.
Please let me know if you have any questions or comments.
01-27-2026 05:30 AM
That is very unfortunate. Thank you for the update. Our case is still open and the ECN HTTS team is scheduling a call with us to discuss it but it sounds like we will end up getting the same answer. If I hear anything different I will definitely update this thread. Thank you!
04-28-2026 07:26 AM
Hello everyone,
As an update to this issue, we ended up getting this submitted as a feature request and it seems like it is getting a lot of attention. We still haven't heard anything regarding whether this is something that has been accepted yet, only that Cisco has started to receive a lot of requests regarding this being supported. If anyone else is running into this issue I highly encourage you to talk to your Cisco representative as the more people that bring this up the better the chances are of getting this implemented in the future. Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide