案例：現網中新增無線 AP，終端接入該 AP 后 802.1X 認證失敗？教科書般排障來了！
本期分享的案例是有線網絡的相關問題。
問題背景
甲方是一家大型的國企單位，注重安全保密工作，要接入核心現網就需要通過WPA/WPA2—802.1X認證認證成功才能成功入網。正好最近增添辦公場所，所以新增了多個無線AP。但IT發現，手機、筆記本、平板等無線接入該AP后概率性沒法通過認證入網！AC、AP都是同一個廠商某C的設備，只不過新增AP是新型號，二外接radius認證服務器是其它三方的。
網絡拓撲簡化如下：
- AC、AP、交換機等網絡設備所在網段為192.168.1.1/24
- radius三方認證服務器所在網段為10.64.X.X/24
好了，針對這個問題，我們一起來看下如何分析！
802.1X協議認知
對于802.1X無線認證，我們要對其原理有一個清晰的認識，否則便是“書到用時方恨少”。好了，復雜的原理我不講，后續出一期《圖解802.1X協議》詳解，這里就簡單講大概邏輯：
- radius服務器上配置如基于MAC的用戶認證，并設置用戶賬號密碼；
- A終端輸入認證服務器IP、賬號密碼后接入無線；
- AP收到A終端的接入認證后（無線EAPOL），向服務器發起認證請求（RADIUS協議報文），問它A終端接入要不要放行；
- radius服務器收到AP過來的聞訊后查自己的庫，對照MAC、賬號密碼等信息OK，于是返回告知AP可放行（RADIUS協議報文）；
- AP收到后，就發A終端過去上網了。
排查思路
了解上述機制后，我們就可以考慮排查思路了：
- 確認入網終端輸入的服務器IP、賬號密碼等參數信息是否正確；
- 確認AC上的radius認證配置是否正確；
- 確認無線終端與無線AP之間交互的EAPOL報文是否正常；
- 確認AP與radius服務器之間的RAIDUS報文交互是否正常。
顯然這類問題，除了1、2步檢查相關配置，剩下的就需要分析報文了。
排查分析
第一步、確認終端配置、AC參數配置是否正確
終端參數配置無問題，因為在舊AP可以正常認證成功。所以看下AC上給AP下發的配置，相關命令如下：
# 查看RADIUS方案配置
[beijing-AC] display radius scheme server_radius
Radius scheme name: server_radius
Server-type: extended
Primary authentication server: 10.64.9.113
Port: 1812
State: active
....
# 查看認證方案配置
[beijing-AC] display authentication scheme server_auth
Authentication scheme name: server_auth
Authentication mode: radius
Radius scheme: server_radius
....以上便是關鍵信息，認證方案是radius沒問題，服務器IP和認證端口1812也填的是對的。其它無用的敏感信息我就不附了。
第二步、確認無線終端與無線AP的交互
終端接入會發EAPOL認證報文給AP，但這個是無線層的，現場沒有無線抓包條件和手段，這一步忽略。
第三步、確認正常和異常無線AP與radius服務器的交互
抓取正常和異常AP的上聯口報文：
發現異常新增AP是有將RADIUS報文發出去的，但是沒有得到服務器響應。
而正常的舊AP能與服務器正常交互，并最最終收到服務器accept的放行指示。
到這里，乍一看是服務器那邊未響應radius認證導致？可能是存在相關的限制之類的，因此向負責radius服務器的人詢問，得到的答復是并未有任何的限制。
然后另一個懷疑點就是報文可能沒有被服務器收到報文，但是那邊沒有條件在radius服務器接口處抓包，所以下一步只能深入分析兩種radius報文的區別了。
第四步、報文分析
通過琢磨和分析，我們看到，這兩種報文的目的MAC竟然是不一致的！
因為是跨三層訪問，目的MAC則是核心交換機192.168.1.1接口的MAC，然而新增AP學得是錯誤的04:d7:a5:aa:eb:e8，說明AP有線側過來的ARP還有其它設備聲明自己是192.168.1.1，即IP沖突！過濾ARP和對應MAC，果然發現有設備ARP：
并且留意到該ARP打了VLAN tag=1，原來是上聯交換機trunk類型同時也透傳了VLAN，但新舊AP實際上是沒有VLAN1的業務的，所以AP收到該tag=1的ARP后不應該學進去了：
綜上分析，明確了是新型號AP的未知BUG，自身未配置透傳VLAN1的情況下收到了ARP tag=1的報文，也把它學到自己的表項里面去了。
問題總結和解決方案
問題總結：AP上聯交換機將ARP tag=1的報文透傳給了AP，其中有設備的IP與核心的IP沖突都是192.168.1.1。新型號AP的存在未知BUG，自身未配置透傳VLAN1的情況下收到了ARP tag=1的報文，也把它學到自己的表項里面去了，因此發radius報文跨三層給服務器時，目的MAC封錯。
解決方案：
- 方法1：上聯口不透傳VLAN1即可，現場也沒有用到VLAN1業務，采取了這種方法
- 方法2：新型號AP升級固件解決。
