排除IP地址為0.0.0.0的重複錯誤消息故障

簡介

本文檔介紹Microsoft Windows Vista及更高版本使用者收到的「重複IP地址0.0.0.0」錯誤消息及其解決方案。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

問題

在Microsoft Windows Vista及更高版本中，Microsoft引入了一種新機制，用於在發生動態主機配置協定(DHCP)進程時檢測網路上的重複地址。RFC 5227中介紹了此新檢測流程。

2.1.1節中定義了此檢測流程的一個觸發器。以下是定義：

此外，如果在此時間段內，主機收到任何地址解析協定(ARP)探測，其中資料包的「目標IP地址」是要探測的地址，並且資料包的「傳送方硬體地址」不是主機任何介面的硬體地址，則主機應同樣將此視為地址衝突，並向配置代理發出如上所述的錯誤訊號。如果兩台（或更多台）主機因某種原因無意中配置了同一地址，並且兩台主機同時正在探測該地址，以確認是否可以安全地使用該地址，則會發生這種情況。

Cisco IOS^®使用源自地址0.0.0.0的地址地址解析協定(ARP)探測功能，在IP裝置跟蹤發生時維護IP裝置跟蹤快取，並在Cisco IOS交換機上啟用使用該功能的功能（例如802.1x）。IP裝置跟蹤的目的是讓交換機獲取並維護通過IP地址連線到交換機的裝置清單。探測器未填充磁軌條目。它用於在獲取條目後啟用和維護表中的條目。將存取控制清單(ACL)套用到介面時，就會使用此IP位址，將ACL中的來源位址替換為使用者端IP位址。當存取清單與802.1x或Cisco交換器上的任何其他Flex-Auth功能一起使用時，此功能至關重要。

重複的IP地址原因

如果交換機在Microsoft Windows PC處於重複地址檢測階段時發出客戶端的ARP探測，則Microsoft Windows會將該探測檢測為重複的IP地址，並顯示一條消息，表示在網路上找到0.0.0.0的重複IP地址。PC未獲取IP地址，使用者必須手動釋放/續訂地址、斷開連線並重新連線到網路，或者重新啟動PC以獲取網路訪問許可權。

以下是失敗封包序列的範例：

解決方案

有多種方法可用於解決此問題。以下是可能的解決方法清單：

• 防止此問題發生的最有效方法是設定交換器，使其傳送不符合RFC的ARP探測，以便從PC所在的VLAN中的交換器虛擬介面(SVI)取得探測。如果為虛擬區域網(VLAN)配置了SVI，並且使用了下面兩個命令中的任意一個，則IP裝置跟蹤(IPDT)探測中的傳送方IP地址永遠不會是0.0.0.0。因此，可以肯定不會發生重複的IP地址錯誤。
  
  此命令格式適用於較舊的代碼版本：
  
  

  ip device tracking probe use-svi

  此配置當前不會在Microsoft Windows中觸發重複地址檢測錯誤消息。此方法的警告是，運行DHCP的Microsoft Windows客戶端所在的每個VLAN中的每台交換機上都必須存在SVI。此方法難以擴展，因此Cisco建議使用IP裝置跟蹤探測延遲作為主要方法。SVI目前在6500系列交換器平台上不可用。此命令在2900、3500和3700系列交換器平台上的Cisco IOS版本12.2(55)SE和4500系列交換器平台上的15.1(1)SG版中實施。
  
  此命令格式適用於較新的代碼版本：
  
  

  ip device tracking probe auto-source fallback 
        
        
        
         
         
           [override] 
          
        

  此最新指令行介面(CLI)命令是透過Cisco IOS版本15.2(2)E中的Cisco錯誤ID CSCtn27420匯入。新增此命令是為了允許使用者定義的ARP請求源IP地址，而不是需要使用預設源IP地址0.0.0.0。新的全域性命令 ip device tracking probe auto-source fallback 0.0.0.x 255.255.255.0 override  允許使用者在子網中使用主機地址0.0.0.x，以避免出現任何重複的IP地址問題。  如果特定VLAN沒有SVI，則使用回退主機IP作為探測源。
  
  
• 解決此問題的主要非SVI替代方法是延遲來自交換機的探測，以便Microsoft Windows有時間完成重複IP地址檢測。這僅在存取連線埠和連結方案上有效。輸入以下命令以延遲探測：
  
  

  ip device tracking probe delay 10

  RFC為重複地址檢測指定一個十秒的視窗。如果延遲裝置跟蹤探測，則幾乎在所有情況下都會解決此問題。除了探測延遲，當交換機檢測到來自PC的探測時，延遲也會重置。例如，如果探測計時器已計為五秒鐘，並且檢測到來自PC的ARP探測，則該計時器將重置為十秒。 如果同時啟用DHCP監聽，則此視窗可以進一步減小，因為這樣同樣會重置計時器。 在極少數情況下，PC在交換機傳送探測之前傳送一個ARP探測毫秒，這仍會觸發一條重複地址消息給終端使用者。此命令是在Cisco IOS版本15.0(1)SE（在2900、3500和3700系列交換器平台上）、版本15.0(2)SG（在4500系列交換器平台上）和版本12.2(33)SXI7（在6500系列交換器平台上）中引入的。
  
  
• 用於解決此問題的另一種方法涉及對客戶端進行故障排除，以確定在鏈路聯機後如此晚的時間出現重複地址檢測的原因。交換機無法確定此過程發生的時間，因此請估計為探測延遲設定的時間以防止衝突。為了有效地排除重複地址檢測出現如此晚的原因，有關IP裝置跟蹤探測器行為的進一步資訊非常有用。
  
  ARP探測是在兩種情況下傳送的：
  
  
  • 與IPDT資料庫中的當前條目關聯的連結從DOWN狀態移動到UP狀態。
  • 已經處於UP狀態的連結與IPDT資料庫中的條目相關聯，該連結具有過期的探測間隔。
    
    
  輸入以下命令以設定IP裝置跟蹤探測間隔：
  
  

  ip device tracking probe interval 
        
        
        
        

  預設間隔是三十秒。要檢視此資訊，請輸入以下命令：
  
  

  show ip device tracking all
  
  IP Device Tracking = Enabled
  IP Device Tracking Probe Count = 3
  IP Device Tracking Probe Interval = 30
  IP Device Tracking Probe Delay Interval = 0
  ------------------------------------------------------------
  IP Address  MAC Address   Vlan  Interface            STATE
  ------------------------------------------------------------
  10.0.0.1   a820.661b.b384  301  GigabitEthernet0/1  INACTIVE
  
  Total number interfaces enabled: 1
  Enabled interfaces:
     Gi0/1
  

  初始條目從DOWN狀態移動到UP狀態後，除非交換機在探測延遲間隔內看不到來自該裝置的流量，否則不會傳送進一步的探測。此外，如前所述，只有在PC傳送ARP探測毫秒後（同時）交換機傳送ARP探測時，才會發生衝突。

相關資訊

• 思科技術支援與下載