我有一个DHCP服务器通过DHCP中继服务多个子网。 当它发送DHCP提供时，它将服务器标识符（选项54）设置为它自己的IP地址。
当客户需要更新时，他们尝试单播到该IP地址，这些IP地址都不能路由到。
当使用中继时，如何单播到DHCP服务器应该工作？ 在更新状态期间客户端的预期行为是否无法通过单播进行更新，然后在时间T2之后的REBINDING状态期间是否通过广播进行更新？
是的，一点没错。
客户端无法将单播路由到他们的DHCP服务器有点奇怪，但这不是问题; 他们只会在租赁期内稍后续约（这会让您在DHCP服务器上的停机时间稍微缩短一些）。
通过从DHCP客户端到DHCP服务器的单播消息来促进续租（在T1阶段）。 为什么来自客户子网的单播stream量不能路由到服务器子网？ 如果来自客户端子网的DHCPDiscover消息未被路由（中继）到服务器子网，原始广播如何中继到服务器子网？ 如果没有stream量在子网之间路由，那么客户如何获得一个IP地址呢？
在一天结束时，来自DHCP客户子网的stream量通过路由器（通过在原始DHCPDiscover阶段期间和随后在T2阶段期间来自DHCP中继代理的单播消息的方式）和/或经由直接来自单播在T1更新阶段的DHCP客户端。
如您所述，如果客户端到达T2阶段，则它将提交一个广播更新请求，DHCP中继代理应该将其中继（单播）给DHCP服务器。
编辑
这是一个理论问题还是你真的有这个问题？
编辑2
换个angular度看我的答案：当客户端在T1阶段发起续租请求时，续约请求是直接从客户端到服务器的单播消息（单播是直接的一对一通信），所以DHCP中继代理根本不应该参与。 如果客户端达到T2更新阶段，那么更新请求通过广播消息发送，并且应该由DHCP中继代理（实际上是来自DHCP中继代理的单播消息）中继。
如果T1阶段单播消息没有从客户端子网路由到服务器子网，则这是路由/networking问题，而不是DHCP问题。
好吧看来我不能评论以前的答案，但只是垃圾邮件给你一个额外的答案。
我认为这不完全是一个路由问题。 看下面这个非常基本的例子来理解：
=>我在哪里需要知道服务器的MAC地址？ 无处。 我不能确定我收到的数据包的源MAC，不pipe是广播还是单播，都是服务器的MAC。 无论如何，T1超过arpcaching超时的可能性很大。
通常我会ARP的siaddr。 如果单播服务器IP不在我的链路上呢？ 那么我最终会放弃请求和任何连续的重试，直到我进入REBINDING状态。
这里没有真正的路由错误。 这是一个拓扑问题，我甚至无法实施一个解决scheme，我会将续订发送到'giaddr'IP，因为这违反了标准。