本期分享的案例是有線網絡的相關問題。

背景介紹

粉絲是個專做弱電智能化的工程商，某小區項目做完后，時不時會發生監控、門禁、對講運行癱瘓問題，持續好幾年了。來看看這位朋友的反饋：

問題很復雜，當然是要付費解決。OK，一起進入正題吧。

網絡拓撲

典型的小區弱電智能化拓撲，簡化如下：

問題現象

出現問題時，大部分終端均會掉線，如下圖的監控、對講等設備離線：

沒什么可說的，問題很顯性就是掉線。

排查分析

問題排查比較久，這邊我就單刀直入的給予分析情況了。

(1) 這三個業務VLAN中存在未知單播幀廣播泛洪，該幀目的均為不存在網絡中的MAC設備，總體泛洪數量打10W+包/秒，業務完全癱瘓；

(2) 未知單播幀當廣播轉發當然是符合預期的，但是為什么量這么大？大概率只有一種可能—未知單播幀被回彈導致風暴。進一步發現，泛洪的未知單播幀的源MAC是0201，這個MAC地址是核心交換機的MAC：

什么意思？意思是核心把這個未知單播幀向下廣播轉，卻又被下聯網絡回彈了，造成風暴。

(3) 為了佐證這個猜想，我們直接在匯聚交換機上查看MAC地址漂移記錄就行，相關命令：dis mac-address flapping record

可以明確看到，在VLAN20這個業務網絡中，源MAC為0201的核心交換發出來的未知單播幀，在1、5、20這幾個下聯口之間不斷漂移。即：

• 上聯核心將未知單播幀以廣播的形式發給匯聚，匯聚向下1、5、20轉發；
• 但匯聚下聯口收到該報文后又彈回來，該未知單播幀報文在1、5、20口之間形成了巨大環路，整個VLAN20充斥著該未知單播幀，業務癱瘓；
• 至于為什么報文會回彈回來，我猜測八成和無線網橋有關：

但沒有條件進一步收集證據分析，我這里也就不點明了。

原因定位及解決方案

根本原因：VLAN20、21、22等業務VLAN充斥著大量的未知單播包，以10W/秒的速率泛洪造成整網癱瘓，這是目前比較能明確看到的現象。

解決方案：既然是泛洪，便做抑制解決，在各個匯聚交換機上對“未知單播幀”做抑制，相關命令：unicast-suppression pps 1   //端口使能，每秒只轉發1個包。

后續情況：

目前來看已解決，問題閉環。