解决方案架构

概念验证 非生产级 DHCP 服务器集成方法

在这种方法中，DHCP 服务器在本地连接到交换矩阵的服务块功能。为实现冗余，在交换矩阵端配置 ESI-LAG，在服务器端配置普通 LAG。所有可能的 4,000+ VLAN 均已配置，并在此链路上向 DHCP 服务器公开。这样，交换矩阵本身就不需要额外配置 DHCP 中继，因为所有接入 VLAN 的第 2 层广播域都延伸至 DHCP 服务器。通过配置要侦听的匹配子接口，DHCP 服务器可以通过侦听客户端发送的 MAC 广播数据包来分配租约。这种方式是老式的，许多 DHCP 服务器（包括 Junos OS）都可以响应此流量。

注意：

在生产级设计和部署中显然不建议这样做。它可能有助于更快地建立网络，但这样的设计会带来严重的安全风险！

不建议在生产级设计中这样做的原因是，您会绕过交换矩阵设计的基本安全功能。通常，所有交换矩阵 VRF 都是相互隔离的。这会强制不同 VRF 中 VLAN 之间的所有流量都传输 WAN 路由器，从而实施防火墙等安全功能。通过将所有 VLAN 放置在服务块中 DHCP 服务器的链路上，我们绕过了 WAN 路由器，从而绕过了安全功能。如果攻击者发现安全漏洞（如开放式管理员登录）或配置不正确，则攻击者可以在所有 VLAN 之间跳转，还可以绕过 VRF 之间任何基于 WAN 路由器的筛选。 请注意这种权衡。

推荐的生产级 DHCP 服务器集成方法

推荐的生产级解决方案是遵循 IETF RFC 2131 和 RFC 3046 基于标准的方法，利用交换矩阵内部的 DHCP 中继转发到客户管理的 DHCP 服务器。

在园区交换矩阵中，DHCP 中继通常位于第 3 层网关 VRF 将流量从连接的接入交换机发送到北向功能的位置。这是因为这是网络中第 2 层广播域与剩余第 3 层转发之间的分界线。请求租约的 DHCP 客户端始终寻址此第 2 层域中的广播 MAC 地址，即 FF：FF：FF：FF：FF：FF。一旦此类消息到达 VRF，VRF 的 DHCP 中继功能（RFC 2131 将其称为 BOOTP 中继代理）就会将其作为 IP UDP 数据包转发到连接到交换矩阵或交换矩阵外部的 DHCP 服务器。与此同时，UDP 数据包中始终会嵌入向 DHCP 服务器转发其他信息：

• 网关 IP（RFC 2131 称之为“giaddr”）是 DHCP 数据包的源 IP 地址。DHCP 服务器将所有响应数据包发送回此嵌入 IP 地址。因此，响应数据包可以访问此 IP 地址非常重要。此报告的源 IP 可能因交换矩阵类型和 WAN 路由器集成方法而异。此 JVD 中说明的两种最流行的方法是：
  • 对于使用虚拟网关寻址的小型交换矩阵，将在每个交换矩阵 VRF 上本地配置的每个叠加 VLAN 的静态 IP 地址用作网关 IP。
  • 对于使用任播寻址的大型交换矩阵，分布在交换矩阵中的 VRF 将使用额外范围的叠加环路 IP。在此交换矩阵中配置 VRF 的所有节点上的每个 VRF 都会获得一个唯一的 IP 地址，用作网关 IP。因此，您拥有一个额外的叠加网络，但该网络在 VRF 之间共享。需要注意的是，在这种情况下，环路 IP 地址的使用有两种方式：
    • 在每台 EVPN 交换矩阵交换机上，始终有绑定到 lo0.0 接口的现有底层环路 IP 地址。它们用于 VXLAN、VTEP 和 EVPN BGP 信令。对于叠加传输，它们通常是不可见的。
    • 用于 DHCP 中继的新环路 IP 地址在叠加 VLAN 中可见。定义此叠加环路池时，请注意叠加 VLAN 不会在其他位置使用此范围。此外，此叠加环路池中的 IP 地址只能绑定到 VRF 所在的 EVPN 交换矩阵节点。
• 预计 DHCP 中继功能会嵌入其他信息，例如由 RFC 3046 中的 DHCP option 82 添加的信息。这有助于 DHCP 服务器识别客户端请求的来源，并能够更好地管理租期讲义决策。之所以需要这样做，是因为 DHCP 服务器将无法再接收来自本地 VLAN 的 DHCP 租用请求，因为它配置为侦听接收 UDP 数据包的 IP 地址套接字接口。DHCP 服务器供应商可在 option 82 中嵌入的可能属性可能有所不同，并且始终取决于与交换矩阵的集成。

如前所述，交换矩阵会配置 VRF 位于交换矩阵中的 DHCP 中继功能。请勿尝试在交换机上手动更改此设置。在交换矩阵配置字段内，您可以在配置网络和 VRF 的窗格中找到 DHCP 中继配置选项。其余的将由Juniper Mist™云自动部署在必要的节点上，如下图所示：

结构类型	DHCP 中继将配置在	支持的节点数
EVPN 多宿主	塌缩核心交换机	最多 4 个
CRB	核心交换机	最多 4 个
ERB	分布式交换机	多
在边缘路由 IP Clos	接入交换机	多

虚拟网关交换矩阵与任播交换矩阵

根据交换矩阵类型，叠加 VLAN（客户端流量所在的位置）可能需要额外的 IP 地址用于内部用途，虚拟网关交换矩阵就是这种情况。Juniper Mist园区交换矩阵配置以下交换矩阵类型：

交换矩阵类型	虚拟网关交换矩阵		任播交换矩阵
EVPN 多宿主		是的	---
CRB		是的	---
ERB		---	是的
IP Clos 交换矩阵		---	是的

在虚拟网关交换矩阵中，VRF 的数量通常非常有限。它们位于核心或塌缩核心层交换机上。Juniper Mist园区交换矩阵支持的最大核心或塌缩核心层交换机数量为 4 台。这意味着在交换矩阵中，某个 VRF 最多可以复制到每个冗余核心或塌缩核心层交换机四次。与虚拟网关交换矩阵相反，任播交换矩阵更适合规模更大的设计。因此，VRF 的位置要么位于分布交换机 （ERB） 上，要么位于接入交换机（IP Clos 交换矩阵）上。虚拟网关交换矩阵的本质是，系统需要一个额外的静态 IP 地址，对于位于交换矩阵中的每个 VLAN，该地址的每个 VRF 都是唯一的。因此，除了每个 VLAN 的共享网关 IP 地址外，该子网上最多还需要四个额外的唯一 IP 地址。

为什么会有这样的设计？交换矩阵上的某些流量有好处，例如 DHCP 中继。对于 DHCP 中继，系统在转发 DHCP 客户端请求时使用静态 IP 地址而不是网关 IP 地址。此行为可确保将 DHCP 响应数据包发送回正确的 VRF，因为静态 IP 地址对于 VLAN/核心交换机是唯一的。

考虑虚拟网关交换矩阵的另一种方法是，将其与传统的第 2 层网关故障切换设计（如 VRRP）进行比较。在那里，您始终有一个在网关（即我们的 VRF）之间浮动的 VIP，并且每个网关都需要为每个 VLAN 提供一个额外的唯一静态 IP。在Juniper Mist园区交换矩阵中，不需要 VRRP 协议，因为 EVPN 控制平面会接管该协议。

在任播交换矩阵中，消除了在每个子网中划分这些额外的静态 IP 地址所需的小小牺牲。这是因为安装 VRF 的分布/接入交换机规模更大，因此您在创建 VLAN 时必须规划好未来的增长。DHCP 中继等系统服务在任播交换矩阵中的工作方式略有不同，而且内部情况更加复杂。

选择哪个 IP 地址作为报告的网关 IP 地址？

通常，您必须在以下方法之一之间进行选择，以确定交换矩阵中 DHCP 中继功能转发的数据包中嵌入了哪个网关 IP 地址：

• 对于 EVPN 多宿主交换矩阵，UI 不提供任何选择，因此您将始终使用网关 IP 地址作为网关 IP。这样一来，DHCP 服务器仅通过分析转发的数据包中嵌入的网关 IP 地址，即可识别请求的来源 VLAN。
• 对于 CRB 交换矩阵，您可以选择虚拟网关静态 IP 地址设计：将字段“Loopback per-VRF subnet”留空，或者在园区交换矩阵对话的“Loopback per-VRF subnet”中填充 IP 前缀时，使用将叠加环路 IP 地址分配给交换矩阵中每个 VRF 的设计。
• 对于 ERB 和 IP Clos 等大型交换矩阵，我们建议在“Loopback per-VRF subnet”中输入 IP 前缀，作为园区交换矩阵配置的一部分。这样，交换矩阵会自动将此池范围之外的唯一叠加环路 IP 分配给交换矩阵中的每个 VRF。在这种情况下，我们还强烈建议利用 OSPF 或 BGP 等路由协议将 WAN 路由器集成到交换矩阵，因为使用这些叠加环路 IP 会使得难以预测如何从 WAN 路由器到达每个网关 IP。

虽然从技术上讲，可以在这些交换矩阵中将“Loopback per-VRF subnet”字段留空，但不建议这样做。如果留空，任播网关 IP 将是嵌入在转发数据包中的报告网关 IP。这不会导致在前往 DHCP 服务器的途中出现问题。但是，当 DHCP 服务器返回响应时，由于任播 IP 由交换矩阵内的多台交换机共享，响应数据包可能会被路由到并非发起请求的交换机，而该交换机可能位于不同的 PoD 或建筑物中。如果发生这种情况，当数据包到达未发起请求的交换机时，DHCP 中继功能将对响应进行解封装，并根据客户端的 MAC 地址确定必须将数据包转发至远程交换机。为此，它将使用 VXLAN 隧道将数据包从东向向重新发送至客户端实际连接的交换机。这会导致设计效率低下。

DHCP 服务器的位置

我们推荐的方法是将本地集成作为交换矩阵本身的一部分。

对于园区交换矩阵，服务叶称为服务块函数，在以下示例中，DHCP 服务器连接位置以北的一对物理交换机称为交换矩阵的组成部分。

DHCP 服务器还可以管理与自身不在同一 VRF 中的客户端的租约。但是，由于交换矩阵内部始终存在 VRF 到 VRF 隔离，因此必须通过 WAN 路由器交换数据包。

当无法进行此类本地集成时，还可以尝试将 DHCP 服务器作为外部元素集成到交换矩阵中。这是您在下图左上角看到的内容：

需要考虑的事项何时使用外部 DHCP 服务器？

将外部 DHCP 服务器集成到交换矩阵中时，要使这种方法取得成功，需要牢记两个关键点：

• 尽可能降低交换矩阵与 DHCP 服务器之间的延迟。如果您不知道延迟的影响，请不要考虑在公共云环境中作 DHCP 服务器。某些 DHCP 客户端在请求租约时可能非常激进，这可能导致未答复的 DHCP 租约请求在高延迟环境中堆积，从而使 DHCP 服务器过载。由于 DHCP 客户端行为在交换矩阵级别几乎不受影响，因此我们建议在将交换矩阵投入生产之前，先测试设计，重点关注整个往返延迟时间。
• 交换矩阵与 DHCP 服务器之间不支持任何形式的网络地址转换 （NAT）。以下摘自 IETF RFC 2131 中解释了其原因，其中描述了 DHCP 服务器必须如何响应客户端请求。请记住，“giaddr”是嵌入式网关 IP 地址：

您可能不知道此 RFC 描述的含义，因此我们提供了一个使用 Microsoft DHCP 服务器的流量示例，该服务器不根据 RFC 响应 SNAT 化的 DHCP 请求。

以下是为中继数据包创建的接入交换机的原始源 IP 和端口：

当 WAN 路由器将 SNAT 应用于转发的发现消息时，它会更改源 IP 和端口，如下所示：

但是，DHCP 服务器的响应会返回端口 67 上的原始嵌入式网关 IP，即应用 SNAT 之前交换矩阵内部的原始源 IP：

此数据包永远不会返回到 SNAT 防火墙。

Junos OS 中的优化，帮助您设计 DHCP 中继

通过 Junos OS 配置，以下几句语句有助于优化设计。我们在这里介绍一些关键参数，以防您想知道交换矩阵为什么会自动配置这些参数：

在 Junos OS 配置中，需要使用“仅转发”语句来防止设备监控不受控制的 DHCP 流量。

在 Junos OS 配置中，“relay-option-82 circuit-id-id-only”语句会在转发 option 82 DHCP 流量时同步 QFX 和 EX 交换机的行为（默认情况下，它们使用不同的属性）。此外，此属性将不再添加不需要的接口信息，如“IRB-irb.1099：ae10.0”或“IRB-irb.1099：vtep.32769”。添加此配置后，系统将仅报告 VLAN ID，从而简化了此字段中的字符串解析，Linux KEA DHCP 服务器可以利用该字段来分配正确的租约。

此处介绍了 Junos OS 配置语句“relay-option-82 server-id override”，这是我们的环境所需要的。它可帮助使用子选项 5 的 Microsoft DHCP 服务器确定数据包的来源并选择要分配的正确池。

将环路 IP 用作网关 IP 时，需要 Junos OS 配置语句“route-suppression destination”。它不用于虚拟网关地址静态 IP 作为网关 IP。

在 Junos OS 配置中，交换矩阵现在使用“no-dhcp-flood”选项配置所有 IRB 接口。这有助于限制客户端的 MAC 广播，以便并非所有 DHCP 中继设备都从重复的客户端接收相同的请求。如果不设置此选项，由于所有客户端请求都是 VLAN 中的广播数据包，因此原始请求将通过 VXLAN 复制并发送到配置了该 VRF 的所有交换矩阵节点，然后这些节点向 WAN 路由器执行 DHCP 中继。

注意：

如果您在实验室中将 vJunos-switch 用作虚拟交换机实例，可以知道虽然可以在虚拟交换机上配置“no-dhcp-flood”选项，但目前尚未实施。因此，您可能会观察到泛洪和使用了错误的网关 IP 地址。但是，这不应影响您对此进行测试的能力。这只是 vJunos 交换机的一个已知限制。