某些交換機上的電話無法完成 DHCP 程序
背景
我有一個 Windows DHCP 伺服器（Server 2008 R2）為多個範圍分發地址。其中一個範圍適用於某些 Mitel IP 電話。電話被配置為使用 dhcp 選項 125 來獲取配置資訊。當電話啟動時，它不知道要使用哪個 vlan，因此它只會獲取它所連接的任何埠的預設（未標記）vlan。dhcp 伺服器給它一個包含選項 125 資訊的響應，並且電話能夠從該響應中讀取它應該使用的 vlan。然後電話會釋放其原始地址並使用正確的 vlan 標籤請求新的 dhcp 租約。電話通常還具有連接到直通埠的電腦。來自電腦的數據包永遠不會被標記，因此 PC 將保留在埠的原始（未標記）vlan 上。這已經為我們工作了多年。
問題和症狀
在過去幾週的某個地方，發生了一些變化，我不確定是什麼。只要電話不重新啟動，它們就會繼續工作，這意味著必須正確處理 dhcp 更新請求。連接到某些交換機的手機甚至可以在重啟後存活下來。但是，連接到其他交換機的電話在重新啟動時將無法完成該過程。我們所有的電話都使用由 UPS 支持的 PoE，所以很久沒有重啟了。這意味著我不知道問題何時首次出現。我所知道的是，昨天重啟時一部手機出現故障，今天在對其進行故障排除時，我們重置了那個開關櫃。現在，該交換機上的所有電話都無法正常工作（謝天謝地，它仍然是一個小數字）。我也知道一月底的時候一切都在運轉，
當我看著手機啟動時，我可以看到它成功地獲得了第一個地址。然後它成功讀取選項 125 資訊，設置正確的 vlan 標籤，並釋放原始 IP 租約。它甚至能夠接收和接受來自伺服器的正確 vlan 的報價。然而，這就是事情停止的地方。電話在螢幕上顯示“
DHCP: Offer 2 ACC”的消息，但 Windows DHCP 伺服器沒有記錄租約，電話永遠不會繼續執行。我只能猜測 DHCP REQUEST 數據包永遠不會到達 Windows 伺服器，因此手機正在等待來自 Windows 的最終 ACK，它可以繼續。解決方法
我終於可以讓電話再次工作了。為此，我必須先斷開電腦。然後我將電話的交換機埠設置為在電話 vlan 上未標記，在 PC vlan 上沒有成員資格。手機現在將正確重啟。此時，我可以將交換機埠配置放回應有的位置，只要在我重置埠時沒有人嘗試撥打該號碼，手機就不會錯過任何一個節拍。然後我可以重新連接電腦。顯然，這不是一個理想的過程，儘管由於手機很少重啟，我將能夠使用它讓人們再次工作，直到找到根本原因。辦公室現在本週關閉，因此這個問題實際上將被允許在周末進行（我沒有電話所在的各個辦公室的鑰匙）。
我固定的這個電話是伺服器機房的服務電話，直接連接到我們的核心交換機。問題可能是核心交換機上的路由或處理標籤的問題，因此該解決方法在數據包首先通過（由其他交換機標記）的遠端辦公室無效，但我會感到非常驚訝如果發生這種情況，鑑於我知道它必須正確處理 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 更新改變了行為，但我不知道如何。或者可能核心交換機沒有正確處理該請求數據包，但我確信那裡沒有任何改變，也沒有解釋為什麼只有某些端點交換機受到影響。我該如何解決這個問題？
更新：
以下是故障電話的 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.xxx 地址是 PC vlan（這個選擇早於我在這個地方）。電話應該首先獲得這種地址，所以這是意料之中的。但是，在發布消息之後，我還希望找到 192.168.16.x 範圍內的地址的報價，因為我可以在電話上看到報價已被接受（除非我誤解了“ACC”）。有趣的是，我從未見過伺服器嘗試發出這樣的地址，即使電話認為它收到了地址。
我考慮過網路上有一個流氓 dhcp 伺服器的想法（它在 Windows 伺服器之前分發一個地址，但沒有電話繼續所需的 dhcp 選項），但這並不能解釋為什麼電話工作當且僅當我完全刪除了任何通往 PC vlan 的路徑。無論如何，我都會在早上通過將我的筆記型電腦連接到電話 vlan 的埠來測試它，但如果其他人同時有更好的解釋，我很想听聽。
這是交換機配置的副本：
我今天通過刪除連接到我們的 dhcp 伺服器的埠上的電話 vlan 的 vlan 標籤解決了這個問題。這對我來說很奇怪，因為其他使用類似方案的系統（又名：使用 802.1q 的 Wifi SSID）需要標籤或客戶端無法獲取地址。它奏效了，所以我不會太努力，但我有興趣看到理論的答案，為什麼會這樣。
您應該考慮在有問題的交換機的任一側執行數據包擷取，然後在 Wireshark 中查看。這將能夠告訴您 1) 流量是否被流氓 DHCP 伺服器攔截（基於 MAC 地址）和 2) 是否有東西被破壞或丟棄（例如，也許您需要 DHCP 中繼）。這可能需要埠鏡像，或者 3com 可能支持直接在交換機上擷取。