我已经多次注意到：一个开关开始performance奇怪。 通常，如果交换机没有完全失败，那么会发现DHCP不起作用。
我们今天有一个Linksys SRW-224P失败。 仍然连接的系统正常工作，直到需要更新其DHCP租约。 一旦租约到期，他们停止工作，但直到那时我们无法检测到失败。 这包括PoE VoIP电话 – 他们的工作正常，直到他们的租约到了，他们完成。
我已经注意到了上面提到的Linksys，3Com的3种types，还有可能有6个愚蠢的开关。
什么是关于DHCP，使它对交换机故障敏感？
也许你正从错误的方向看待这个问题，而不是问为什么DHCP不起作用，也许你应该问为什么基于TCP的通信工作在丢包或损坏的不可靠networking上。
基于TCP的通信意味着可靠，协议被devise为重试通信，其他协议如UDP不可靠。 DHCP恰巧正在使用UDP。 在典型的networking上，你现在看到的大部分都是基于TCP的。 它的弹性属性可能会让你继续在失败的硬件上进行通信。
我想说的是， DHCP比说http请求更复杂一点，但是我会辩论自己试图声明一个方法来查明你的交换机是否中断，是通过它检查DHCP请求是否成功。 我很确定，如果你看看你的真实VOIPstream量，你会注意到丢包。 VOIP（UDP）数据包丢失可能在呼叫中显着，具体取决于被丢弃的百分比。 如果有几个被丢弃，这没什么大不了的，但是对于DHCP请求，这些数据包实际上是非常重要的，因为它们不会被重传，所以会中断请求。
可能会派上用场了解所有DHCP为你做的事情（ 通过思科 ）。
转发bootp / dhcp帮助器请求的能力？
编辑：好的，因为他们不是第3层交换机（可能应该读一点更密切），他们可能不涉及到DHCP转发。
我已经看到两个Netgear智能交换机上的这种行为。 在这两种情况下，交换机都忽略了所有的广播stream量。 所以DHCP请求和回复没有被传递。
DHCP不仅仅是基于广播。 它是“请求”的基础。 有一个到networking的连接，然后是在该networking上的地址请求，然后是从DHCP服务器发送的应答，该应答包含地址租约或报告失败。 请求在客户端内部重复，每隔几秒发送一次请求并等待响应。
但是，如果没有收到响应，如果丢弃，或者没有正确通过交换设备，您将无法获得地址。 检查以确保您的子网已正确configuration。 我注意到许多人喜欢使用x.0.x位来保存静态托pipe设备（交换机和打印机），同时将计算机和服务器保留在x.1.x或其他位置（这只是一个示例）。 如果您的子网掩码没有正确包含x.0.x，那么最终可能会出现丢弃dhcp请求的位掩码或错误路由。
请记住将此x.0.x作为主要起始地址，然后继续根据需要将掩码与您的dhcp完全匹配地设置为尽可能宽的子网; 请注意，sume将会针对实际的dhcp服务器设置子网划分，这是没有用的，它会产生分组泄漏。 如果你设置你的dhcp不发放静态部分，你仍然需要将它设置在你的子网中。
如果你的dhcp子网，你应该重新configuration掩码，加1位掩码更改。 如果你的DHCP服务器的子网掩码是255.255.252.0，那么你的交换机上需要子网255.255.251.0，以允许对x.0.x地址掩码（在客户端input的静态路由）的请求携带dhcp信号与networking的其他部分相同。 确保你的子网掩码允许需要交互的子网看到对方，即使只是通过DHCP请求。
您可以通过设置工作组或域的限制，在Windows机器（现在是Mac）上分离networking服务。 访问服务应该通过login来处理，而不是由vlan来处理。 如果您知道如何将脚本写入您的服务器，则login可以控制您收到的地址，但只有在绝对必要时才能执行。 VLAN只能用于帮助networking技术追踪，追踪和解决问题，方法是将地址屏蔽scheme应用到物理位置。
请记住，你可以桥接完全不同的掩码，但这只允许他们从networking的angular度来看待对方，而不是访问级别。 如果他们需要访问服务，则vlan应该全部桥接到一个主要接口，并且该接口应该携带包含所有vlan的完整掩码，而vlan接口仅携带主掩码255.255.255.0（或者任何你所穿过的vlan子网） 。
我唯一能想到的是交换机可能无法正确更新其ARPcaching以反映新分配的IP。