DHCPv6服务器配置中基于Vendor Class匹配PXEClient:Arch:00011失败的问题咨询

看起来你遇到的问题核心是DHCPv6 Vendor Class Option的结构理解有误，导致你的substring匹配逻辑完全命中了错误的内容。咱们一步步拆解：

首先看你的客户端发送的Vendor Class数据：

Vendor Class
Option: Vendor Class (16)
Length: 38
Value: 000001570020505845436c69656e743a417263683a303030...
Enterprise ID: Intel Corporation (343)
vendor-class-data: PXEClient:Arch:00011:UNDI:003016

这里要划重点：DHCPv6的Vendor Class Option（代码16）不是纯文本格式，它的结构是固定的：

• 前4字节是Enterprise ID的二进制值（这里就是00000157，对应十进制343，也就是Intel的企业ID）
• 后面才是data-len字段加上实际的vendor-class-data文本内容

而你的配置里犯了两个关键错误：

1. 错误地把option dhcp6.vendor-class定义为text类型，忽略了它的结构化本质
2. 用substring(option dhcp6.vendor-class, 0, 20)去匹配，而前4字节是二进制的企业ID（非可打印文本），所以你匹配的内容开头根本不是PXEClient:...，自然不会命中

解决办法 #

方法一：使用正确的结构化定义（推荐）

首先删除你自定义的option dhcp6.vendor-class code 16 = text;，ISC DHCPv6默认已经对Vendor Class Option有正确的结构化支持。然后修改你的匹配逻辑，先验证企业ID，再匹配vendor-class-data的内容：

subnet6 3ffe:501:ffff:9::/64
{
    range6 3ffe:501:ffff:9::3 3ffe:501:ffff:9::ffff;
    # 先匹配Intel的企业ID，再匹配vendor-class-data的前缀
    if option dhcp6.vendor-class.enterprise-id = 343 and 
       substring(option dhcp6.vendor-class.data[0].vendor-data, 0, 17) = "PXEClient:Arch:00011" {
        option dhcp6.bootfile-url "tftp://[3ffe:501:ffff:1:1:0:d:202]/_H3CCustomized_ZBB_ARM.efi";
    }
}

这里option dhcp6.vendor-class.data[0].vendor-data就是客户端发送的PXEClient:Arch:00011:UNDI:003016文本，取前17个字符正好是你要匹配的PXEClient:Arch:00011。

方法二：临时 workaround（不推荐，仅用于验证）

如果你暂时不想修改结构化定义，也可以调整substring的起始位置，跳过前4字节的企业ID：

option dhcp6.vendor-class code 16 = text;
subnet6 3ffe:501:ffff:9::/64
{
    range6 3ffe:501:ffff:9::3 3ffe:501:ffff:9::ffff;
    # 跳过前4字节的企业ID，从第5字节开始匹配
    if substring(option dhcp6.vendor-class, 4, 17) = "PXEClient:Arch:00011" {
        option dhcp6.bootfile-url "tftp://[3ffe:501:ffff:1:1:0:d:202]/_H3CCustomized_ZBB_ARM.efi";
    }
}

这个方法不推荐的原因是：二进制转文本可能会出现不可控的字符编码问题，而且不同客户端的Vendor Class结构可能有差异，结构化匹配才是长期可靠的方案。

备注：内容来源于stack exchange，提问作者Kang Zayn