排除網路中的APIPA地址故障

• 使用者電腦收到APIPA IP地址，並且使用者連線受到影響。

問題症狀

1. 特定VLAN上的使用者會遇到間歇性問題，即收到APIPA IP地址並失去與網路的連線。
2. 防火牆具有單個終端使用者MAC地址的多個ARP條目，如下所示：

Firewall/pri/act# show arp | include abcd.abcd.abcd
inside 10.1.1.12 abcd.abcd.abcd 30 
inside 10.1.1.13 abcd.abcd.abcd 40 
inside 10.1.1.14 abcd.abcd.abcd 51 
inside 10.1.1.15 abcd.abcd.abcd 53

故障排除步驟

1. 防火牆上的調試指向將響應傳送到終端使用者ARP探測的防火牆。

DHCPD/RA: creating ARP entry (10.1.1.12, abcd.abcd.abcd). 
DHCPRA: Adding rule to allow client to respond using offered address 10.1.1.12

這使終端裝置認為其地址重複。 

2.在終端裝置或防火牆上捕獲

完成DORA過程後，捕獲show end device sending DHCP Decline packets。

隔離

• 完成DORA過程後，介面內的防火牆通過充當代理來響應ARP探測。這使PC傳送DHCP失敗。 

行動計畫

• 使用命令「sysopt noproxyarp inside」在防火牆內部介面上禁用代理arp

解決方案/驗證

• 終端裝置在禁用proxy-arp後接收IP地址。

• 

  附註：確保沒有裝置充當終端使用者ARP探測的代理或傳送響應。

問題描述：

• 使用者電腦收到APIPA IP地址，並且使用者連線受到影響。

使用者症狀

1. 特定VLAN中的某些使用者無法通過無線AP獲取DHCP地址。
2. 防火牆針對單個終端使用者MAC地址有多個ARP條目

Firewall# show arp | i abcd
Inside 10.1.1.22 abcd.abcd.abcd 48
Inside 10.1.1.23 abcd.abcd.abcd 49
Inside 10.1.1.24 abcd.abcd.abcd 50

已執行故障排除

• DHCP提供已被交換機丟棄
• FTD會根據來自DHCP伺服器的DHCP提供來填充ARP。

***DROP*** Broadcast to Access-Tunnel disallowed (accessTunnelBroadcastDrop)

隔離

• 如果為SDA無線設定配置了僅L2 VLAN，則提供帶有廣播標誌的資料包不會到達AP。因為接入隧道預設不允許廣播資料包。

行動計畫

• 允許LISP環境中的「泛洪能力」。

router lisp 
instance-id 8456 
flood access-tunnel 

解決方案/驗證

• 在內部介面上連線的C9300中配置「泛洪接入隧道」後，客戶端接收DHCP地址。

問題描述：

• 使用者電腦收到APIPA IP地址，並且使用者連線受到影響。

症狀

1. Mac address-table顯示帶有「drop」的條目。

#show mac address-table interface gigabitethernet1/0/20           
Mac Address Table 
-------------------------------------------   
Vlan    Mac Address       Type        Ports 
----    -----------       --------    -----   
10    0000.0001.000a    DYNAMIC     Drop

2. Show Authentication會話顯示許多條目，可能超過2000甚至更10000。

switch2#show authentication sessions
Gi1/0/1  0000.0001.1234 N/A   UNKNOWN Unauth  0AFF0B8D000000EC000000AF
Gi1/0/1  0000.0001.2345 N/A   UNKNOWN Unauth  0AFF0B8D000000F00016B7D7
Gi1/0/1  0000.0001.3456 N/A   UNKNOWN Unauth  0AFF0B8D0028DE3500000000

故障排除步驟

• Packet capture（資料包捕獲）顯示來自不同源MAC地址的終端裝置的許多傳入資料包。
• 身份驗證會話限製為2000，一旦超過該限制，網路中就會出現意外問題
• https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-12/configuration_guide/sec/b_1612_sec_3650_cg/configuring_ieee_802_1x_port_based_authentication.html

隔離

•  這表示終端使用者介面卡問題。這將傳送交換機理解為隨機源MAC地址的格式錯誤的資料包。

行動計畫

• 配置「authentication host-mode multi-domain」，僅允許2個mac地址。
• 找出並隔離肇事裝置。

解決方案/驗證

• 配置此解決方法後，不會發現任何問題。

• 

  附註：確保啟用埠安全或Dot1x auth session host-mode multi-domain。

問題描述：

• 使用者電腦收到APIPA IP地址，並且使用者連線受到影響。
  

使用者症狀

1. 終端客戶端傳送資料包長度大於的EAP響應(示例：3736)實際預期封包長度1492。

Extensible Authentication Protocol
Code: Response (2)
Id: 4
Length: 1492
Type: TLS EAP (EAP-TLS) (13)
• EAP-TLS Flags: 0xc0
..0. .... = Start: False
EAP-TLS Length: 3736

已執行故障排除

• 交換機上的MTU設定為較小的系統範圍條目。（示例：1998bytes）
• 輸出介面配置了更大的大小。(範例：9198位元組)

隔離

• 整個路徑的MTU不相符造成問題。

行動計畫

• 將系統MTU更改為1500，然後重新載入交換機

解決方案/驗證

• 配置此設定後，身份驗證成功。

• 

  附註：確保在資料包流的整個路徑中啟用相同的MTU。

問題描述：

• 使用者電腦收到APIPA IP地址，並且使用者連線受到影響。

使用者症狀

• 在HA中部署VM時，如果在介面中應用此策略：

裝置跟蹤策略IPDT_POLICY

no protocol udp

跟蹤啟用

• 故障切換後，接入交換機將丟棄ARP應答。
  

已執行故障排除

1. 交換機將丟棄對探測器的ARP響應。
2. 交換機配置了IPDT防護。
3. IPDT — 保護丟棄ARP探測和終端裝置獲得APIPA。