部分的に故障した/故障したスイッチがDHCPを通過できないのはなぜですか？
私はこれに何度か気づきました：スイッチが奇妙に振る舞い始めます。通常、スイッチが完全に失敗しない場合、注目される傾向があるのはDHCPが機能しないことです。
今日、LinksysSRW-224Pが故障しました。 DHCPリースを更新するときまで、接続されたままのシステムは正常に機能していました。リースの期限が切れると動作を停止しましたが、それまでは障害を検出できませんでした。これにはPoEVoIP電話が含まれます。リースが終了するまでは正常に動作し、リースが終了すると正常に動作します。
私は、上記のLinksys、3種類の3Com、そしておそらく半ダースのダムスイッチでこれに気づきました。
障害のあるスイッチに敏感になるDHCPについてはどうですか？
おそらく、DHCPが機能しない理由を尋ねるのではなく、間違った方向からこれを見ているのかもしれません。パケット損失や破損がある信頼性の低いネットワークでTCPベースの通信が機能する理由を尋ねるべきかもしれません。
TCPベースの通信は信頼できることを目的としており、プロトコルは通信を再試行するように設計されています。UDPなどの他のプロトコルは信頼できません。 DHCPはたまたまUDPを使用しています。典型的なネットワークでは、最近見られるもののほとんどはTCPベースです。その復元力の特性は、障害のあるハードウェアを介して通信を継続できるようにしている可能性があります。
[〜＃〜] dhcp [〜＃〜] はhttpリクエストと言うよりも少し複雑だと思います。しかし、スイッチが壊れているかどうかを確認する方法は、DHCP要求がスイッチを介して成功したかどうかを確認することであると主張しようとしています。実際のVOIPトラフィックを見ると、パケット損失に気付くと思います。 VOIP（UDP）パケット損失は、ドロップされる％によっては、通話で目立つ場合があります。いくつかがドロップされても大したことではありませんが、DHCP要求の場合、これらのパケットは実際には重要であり、再送信されないため、要求が中断されます。
DHCPがあなたのために行うすべてのことを理解するのに役立つかもしれません（ Cisco経由 ）。
Bootp/dhcpヘルパーリクエストを転送する機能はありますか？
編集：わかりました、それらはレイヤー3スイッチではないので（おそらくこれをもう少し詳しく読む必要があります）、おそらくdhcp転送には関与していません。
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サブネットに配置するもの）のみを保持する必要があります。
2つのNetgearスマートスイッチでこの動作を確認しました。どちらの場合も、スイッチはすべてのブロードキャストトラフィックを無視していました。そのため、DHCP要求と応答は渡されませんでした。
私が考えることができる唯一のことは、スイッチが新しく割り当てられたIPを反映するためにARPキャッシュを正しく更新できない可能性があるということです。