☰

为什么部分故障/发生故障的交换机无法通过 DHCP？

tag-icon • tag-icon dhcp ethernet switch
为什么部分故障/发生故障的交换机无法通过 DHCP？

我注意到过几次这种情况：交换机开始出现异常。通常，如果交换机没有完全失效，人们会注意到 DHCP 不起作用。

今天我们的 Linksys SRW-224P 出现故障。仍处于连接状态的系统工作正常，直到需要续订 DHCP 租约。租约到期后，它们停止工作，但在此之前我们无法检测到故障。这包括 PoE VoIP 电话 - 它们工作正常，直到租约到期，届时它们就完蛋了。

我在上述 Linksys、三种 3Com 以及可能有六个哑交换机上都注意到了这一点。

DHCP 的哪些方面使其对交换机故障很敏感？

答案1

也许您从错误的方向看待这个问题，而不是问为什么 DHCP 不起作用，也许您应该问为什么基于 TCP 的通信可以在存在数据包丢失或损坏的不可靠网络上工作。

基于 TCP 的通信是可靠的，并且该协议旨在重试通信，而其他协议（如 UDP）则不可靠。DHCP 恰好使用 UDP。在典型的网络上，您现在看到的大多数都是基于 TCP 的。它的弹性属性可能就是允许您在发生故障的硬件上继续进行通信的原因。

答案2

我会这样说DHCP比 http 请求稍微复杂一些，但我认为找出交换机是否坏掉的一种方法就是检查 DHCP 请求是否通过交换机成功。我敢肯定，如果您查看实际的 VOIP 流量，您会注意到数据包丢失。VOIP（UDP）数据包丢失在通话中可能很明显，具体取决于丢失的百分比。如果丢失了一些数据包，这没什么大不了的，但对于 DHCP 请求，这些数据包实际上很重要，因为它们不会被重新传输，所以会破坏请求。

了解 DHCP 为您做的所有事情可能会有所帮助（通过思科）。

答案3

转发 bootp/dhcp 辅助请求的能力？

编辑：好的，因为它们不是第 3 层交换机（可能应该更仔细地阅读这一点），所以它们可能不参与 dhcp 转发。

答案4

DHCP 不仅仅是基于广播。它是基于“请求”的。首先连接到网络，然后请求该网络上的地址，然后从 DHCP 服务器发送回复，该回复要么持有地址租约，要么报告失败。客户端内部会重复该请求，每隔几秒发送一次请求并等待响应。

但是，如果未收到该响应，如果该响应被丢弃，或者如果它没有正确通过交换设备，您将无法获得地址。请检查以确保您的子网配置正确。我注意到许多人喜欢使用 x.0.x 位来仅容纳静态管理设备（交换机和打印机），同时将计算机和服务器保持在 x.1.x 或其他位置（这只是一个示例）。如果您没有在子网掩码中正确包含 x.0.x，则最终可能会出现位掩码丢弃 dhcp 请求或错误路由它们的情况。

请记住将此 x.0.x 作为主要起始地址，然后继续设置子网，使其尽可能宽，并使用与您的 dhcp 完全匹配的掩码；请注意，sume 将根据实际 dhcp 服务器设置子网，这没有用，它会导致数据包泄漏。如果您将 dhcp 设置为不分发静态部分，您仍然需要将其设置在子网内。

如果您对 dhcp 进行子网划分，则应重新配置掩码，将位掩码更改加 1。如果您将 dhcp 上的掩码划分为 255.255.252.0 子网，则需要在交换机上将掩码划分为 255.255.251.0 子网，以允许对 x.0.x 地址掩码（在客户端输入的静态路由）的请求与网络的其余部分一样携带 dhcp 信号。确保您的子网掩码允许需要交互的子网相互看到，即使只是为了传递 dhcp 请求。

您可以通过设置工作组或域限制来分离 Windows 计算机（现在还有 Mac）上的网络服务。服务访问应通过登录而不是通过 VLAN 来处理。如果您知道如何将脚本写入服务器，则登录可以控制您收到的地址，但只有在绝对必要时才这样做。VLAN 应仅通过遵循地址掩码方案到物理位置来帮助网络技术人员跟踪、追踪和修复问题。

请记住，您可以桥接掩码完全不同的 VLAN，但这仅允许它们从网络角度而不是访问级别相互看到。如果它们需要访问服务，则应将所有 VLAN 桥接到主接口，并且该接口应带有包含所有 VLAN 的完整掩码，而 VLAN 接口仅带有主掩码 255.255.255.0（或您放置在其上的任何 VLAN 子网）。

相关内容