バックグラウンド
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月の終わり近くに機能していたことも知っています。
電話が起動するのを見ると、最初のアドレスを取得できることがわかります。次に、オプション125情報を正常に読み取り、正しいvlanタグを設定し、元のIPリースを解放します。サーバーから正しいVLANでオファーを受け取り、受け入れることさえできます。しかし、それは物事が停止する場所です。電話の画面には「DHCP: Offer 2 ACC」というメッセージが表示されますが、Windows DHCPサーバーはリースを記録しておらず、電話は移動しません。DHCP REQUESTパケットがWindowsサーバーに到達することはないと推測できるので、電話はWindowsからの継続的なACKを待っています。
回避策
私はついに電話を再び使えるようになりました。そのためには、まずコンピューターを切断する必要がありました。次に、PC VLANのメンバーシップなしで、電話VLANで電話のスイッチポートをタグなしに設定します。これで、電話機は正しく再起動します。この時点で、スイッチポートの設定を元の場所に戻すことができ、ポートをリセットしているときに誰もその番号に電話をかけない限り、電話機はビートを逃しません。その後、コンピューターを再接続できます。明らかに、これは理想的なプロセスではありませんが、電話が再起動することはめったにないので、根本的な原因が見つかるまで人々を再び働かせることはできません。現在、オフィスは1週間閉鎖されているため、この問題は実際に週末に座ることができます（電話がある個々のオフィスのキーはありません）。
私が修正したこの電話は、コアスイッチに直接接続されたサーバールームのサービス電話です。問題はコアスイッチのタグのルーティングまたは処理の問題である可能性があります。そのため、パケットが他のスイッチを最初に通過する（タグ付けされる）リモートオフィスでは回避策が有効になりませんが、非常に驚かされますそれが発生した場合、dhcpの更新と実際の電話での会話を正しく処理する必要があることがわかっているためです。
ねじれは、ポートがPC VLANでタグ付けされたままになると、代わりに電話がメッセージ「DHCP: Offer 1 ACC」で失敗することを意味します。これを成功させるには、そのVLANを完全に削除する必要があります。
注：回避策が遠隔地の建物で効果的であることを確認しました。これにより、デバイスが何らかの形で正しいVLANに割り当てられていないのではないかと疑われます。コアスイッチで問題が発生し、ほぼ同時にネットワーク上の複数の場所で問題が発生したという事実は、コアスイッチが問題である可能性があることを示しています。特別なことは何もありませんが、週の終わり近くにスイッチをリブートするためのメンテナンスウィンドウをスケジュールしています。ファームウェアを更新することもあります。
環境
コアスイッチはHP 5406zlです。このスイッチはVLAN間ルーティングを処理します。Windows DHCPサーバーは、スイッチに直接接続されています。エンドポイントスイッチはファイバSFPを介してコアスイッチに接続され、これらのポートは両端のすべてのVLANに対してタグ付けされます。コアスイッチは、各vlanをip helper-addressDHCPサーバーを指す設定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、Assign、10.1.2.158、、08000F197844、、3189088995,0 ,,, 11,03 / 06 / 15,12：40：40、Renew、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.xxxアドレスはPC vlanです（この選択は、この場所で私より前に行われました）。電話は最初にそのような種類のアドレスを取得する必要があります。ただし、リリースメッセージの後で、192.168.16.xの範囲のアドレスのオファーが見つかることも期待しています。これは、電話でオファーが受け入れられたことを確認できるためです（「ACC」と誤解しない限り）。サーバーがそのようなアドレスを発行しようとするのを見たことがないのは興味深いことです。
私はネットワーク上に不正なdhcpサーバーがあるという考えを考えました（Windowsサーバーの前にアドレスを配りますが、電話が続行するために必要なdhcpオプションはありません）が、電話がなぜ機能するのかは説明されていませんPC VLANへのパスを完全に削除します。とにかく午前中にラップトップを電話VLAN用に設定されたポートに接続してテストしますが、その間に他の誰かがより良い説明を持っているなら、それを聞きたいです。
スイッチ構成のコピーは次のとおりです。