一部のスイッチの電話がDHCPプロセスを完了できない
背景
Windows DHCPサーバー（Server 2008 R2）で複数のスコープのアドレスを配布しています。これらのスコープの1つは、一部のMitel IP Phone用です。電話機は、dhcpオプション125を使用して設定情報を取得するように設定されています。電話が起動したとき、使用するVLANがわからないため、接続されているポートのデフォルト（タグなし）VLANを取得するだけです。 dhcpサーバーはそれにオプション125情報を含む応答を提供し、電話はこの応答からどのVLANを使用すべきかを読み取ることができます。次に、電話機は元のアドレスを解放し、正しいVLANタグを使用して新しいDHCPリースを要求します。また、電話機には通常、パススルーポートに接続されたコンピュータがあります。コンピューターからのパケットはタグ付けされないため、PCはポートの元の（タグ付けされていない）VLANに留まります。これは何年も私たちのために働いてきました。
問題と症状
過去数週間のどこかで何かが変わったので、何が起こったのかわかりません。電話機は、再起動しない限り機能し続けます。つまり、dhcp更新要求を正しく処理する必要があります。特定のスイッチに接続された電話は、再起動後も存続します。ただし、他のスイッチに接続された電話は、再起動時にプロセスを完了できません。私たちの電話はすべて、UPSでバックアップされたPoEを使用しているため、再起動してから長い時間がかかります。これは、問題が最初に発生した時期がわからないことを意味します。私が知っているのは、昨日再起動したときに1台の電話が故障したことです。今日のトラブルシューティングでは、スイッチクローゼットをリセットしました。現在、そのスイッチの電話はどれも機能していません（ありがたいことに、それはまだ少数です）。 1月の終わりごろ、怪我をしたユーザーの電話を1階の一時的なワークスペースに移動したときに、問題が発生していたことも知っています。
電話が起動するのを見ると、最初のアドレスが正常に取得されていることがわかります。次に、オプション125情報を正常に読み取り、正しいVLANタグを設定して、元のIPリースを解放します。 サーバーから正しいVLANに関するオファーを受信して受け入れることもできます。しかし、それは物事が止まるところです。スマートフォンの画面に「DHCP: Offer 2 ACC "ですが、Windows DHCPサーバーはリースを記録しておらず、電話は移動しません。DHCPREQUESTパケットがWindowsサーバーに到達しないため、電話はWindowsからの最後のACKを待機していると推測できます続行しても大丈夫です。
回避策
やっと電話が使えるようになった。そのためには、まずコンピュータを切断する必要がありました。次に、電話のスイッチポートを電話のVLANでタグなしに設定し、PCのVLANではメンバーシップを設定しません。これで電話は正しく再起動します。この時点で、スイッチポートの構成を元の場所に戻すことができます。ポートをリセットしているときに誰もその番号に電話をかけない限り、電話でビートが失われることはありません。その後、コンピュータを再接続できます。明らかに、それは理想的なプロセスではありませんが、電話が再起動することはめったにないので、根本的な原因が見つかるまで、それを使用して人々を再び働かせることができます。現在、オフィスは1週間閉鎖されているので、この問題は実際には週末の間座ることができます（電話が置かれている個々のオフィスのキーはありません）。
私が修正したこの電話は、コアスイッチに直接接続されているサーバールームのサービス電話です。問題はコアスイッチのルーティングまたは処理タグの問題である可能性があります。そのため、回避策は、パケットが最初に他のスイッチを通過する（タグ付けされる）リモートオフィスでは効果的ではありませんが、私は非常に驚きますそれが発生した場合、dhcpの更新と実際の電話での会話を正しく処理している必要があることがわかっていることを前提としています。
ひねりは、ポートをPC VLANにタグ付けしたままにすると、代わりに電話が「DHCP: Offer 1 ACC "。これを成功させるには、そのVLANを完全に削除する必要があります。
注：回避策が遠隔の建物で有効であることを確認しました。これにより、私のデバイスが何らかの理由で正しいVLANに割り当てられていないのではないかと疑っています。コアスイッチで問題が発生し、ネットワーク上の複数の場所でほぼ同時に発生したという事実は、コアスイッチに問題がある可能性を示しています。特に確認することはありませんが、週末の終わり頃にメンテナンスウィンドウをスケジュールして、スイッチを再起動します。ファームウェアを更新することもあります。
環境
コアスイッチはHP 5406zlです。このスイッチは、VLAN間ルーティングを処理します。 Windows DHCPサーバーはスイッチに直接接続されています。エンドポイントスイッチはファイバーSFPを介してコアスイッチに接続され、これらのポートは両端のすべてのVLANのタグが付けられています。コアスイッチは、各VLANをip helper-address DHCPサーバーをポイントする設定とdhcp relay-option 82 replace行を追加して、dhcpサーバーが使用するスコープを認識できるようにします。これらの構成、およびエンドポイントスイッチのポート構成は、少なくとも16か月は変更されていません。その間に他のスイッチと電話のリセットがありました。
エンドポイントスイッチのほとんどはHP 2530シリーズです。これらのスイッチは正常に動作しているようです（3種類の2530の電話が今日正しく再起動しました）。問題があるのは古いスイッチです。動作しない古い3Com 4200と4210があります。前述のコアスイッチに直接接続されているサービス電話も機能しません。
質問
この時点で私の推測では、dhcpサーバー上のWindowsの更新によって動作が変更されたと考えられますが、その方法はわかりません。または、コアスイッチがそのREQUESTパケットを正しく処理していない可能性がありますが、そこには何も変更されていないと確信しており、特定のエンドポイントスイッチのみが影響を受ける理由を説明していません。この問題を解決するにはどうすればよいですか？
更新：
失敗した電話からのdhcpログの抜粋を次に示します。
10,03/06/15,12：40：40、割り当て、10.1.2.158、、08000F197844、、3189088995,0 , 11,03/06/15,12：40：40、更新、10.1.2.158、 、08000F197844、、3189088995,0 , 12,03/06/15,12：40：41、Release、10.1.2.158、、08000F197844、、3189088995,0 , 15,03/06/15,12： 40：45、NACK、10.1.2.154、、08000F197844、、0,6 , 15,03/06/15,12：40：45、NACK、10.1.2.154、、08000F197844、、0,6 ,
10.x.x.xのアドレスはPCのVLANです（この選択は、この場所よりも前から行われています）。電話は最初はそのようなアドレスを取得するはずなので、それは予想されます。ただし、リリースメッセージの後、192.168.16.xの範囲のアドレスのオファーを見つけることも期待しています。電話でオファーが受け入れられたことを確認できるためです（「ACC」を誤って解釈していない限り）。電話がそれを受信したと思っていても、サーバーがそのようなアドレスを発行しようとするのを見たことがないのは興味深いことです。
ネットワーク上に不正なdhcpサーバーがあるという考えを検討しました（Windowsサーバーの前にアドレスを渡しますが、電話が継続するために必要なdhcpオプションがないため）。 PC VLANへのパスを完全に削除します。私は朝、ラップトップを電話のVLAN用に設定されたポートに接続してテストしますが、それまでに他に誰かより良い説明があれば、ぜひ聞かせてください。
スイッチ構成のコピーは次のとおりです。
今日、DHCPサーバーに接続しているポートの電話VLANのVLANタグを削除することで、問題を修正しました。同様のスキーム（別名：802.1qを使用するWifi SSID）を使用する他のシステムがタグを必要とするか、クライアントがアドレスを取得できないため、これが機能したのは非常に奇妙です。うまくいったので、一生懸命見ていませんが、-whyの理論を使って答えを見てみたいと思います。
この問題が再び発生する場合は、DHCPスコープのサイズと使用中のリースの数を確認することをお勧めします。古いDHCPリースが破棄されていない場合、サーバーはプールにアドレスが残っていないと考え、新しいアドレスを割り当てることができない場合があります。これは、VLANで応答するデバイスがない場合でも当てはまります。 DHCPスコープが7日間の場合、新しいリースを取得できるようになるまでに最大7日間かかることがあります。同様に、構成を変更すると問題が解決します。これは、新しい範囲のアドレスが提供される可能性があるか、構成の変更によってはリースがフラッシュされる可能性があるためです。リースのライフタイムを非常に短い値に設定することをお勧めします。これが当てはまる場合は、そのスコープの1時間のようにします。これを確認するには、リースを手動で削除し、問題が再び発生した場合に、電話が新しいアドレスを取得できるようになったかどうかを確認します。
問題のあるスイッチのいずれかの側でパケットキャプチャを実行し、Wiresharkでこれを確認することを検討する必要があります。これにより、1）トラフィックが不正なDHCPサーバーによって（MACアドレスに基づいて）インターセプトされているかどうか、および2）何かが破壊されたりドロップされたりしている（たとえば、DHCPリレーが必要な場合など）かどうかを知ることができます。これにはポートのミラーリングが必要な場合があります。または、3comがスイッチでの直接キャプチャをサポートしている場合があります。