語音業務單通故障分析

故障現象

陽江某個集團客戶報障用戶寬帶業務正常，語音業務不穩定，出現通話幾秒鐘后無音或中斷現像，通過Ping有語音問題用戶的ONU，出現間接性丟包。

故障分析

通過檢查OLT配置，確認語音與寬帶業務是走不同物理鏈路，語音業務走gei_1/19/1上行，寬帶業務走smartgroup1聚合端口上行。查看語音網關設備告警及OLT日志、OLT側抓包分析如下：

圖1 OLT語音業務上聯口狀態信息

圖2 不正常丟包的ONU

1.在OLT語音業務上聯口gei_1/19/1數據包統計信息發現，Input方向有嚴重丟包及CRC校驗錯誤情況發現，OLT語音業務上聯口狀態信息如圖1所示。

Input：ONU 回復信息方向，出現大量丟包，一般可能存在光路不好、接口協商模式不對、數據配置錯誤等問題。

通 過 排 查，OLT和ONU設備端口的收發光正常，雙方端口是自動協商，并且通過更換兩端對應接口的光模塊，問題依舊。但是在排查過程中，發現有部分客戶的語音在開通后一直能夠正常使用，光路只有一條，只是IP地址屬于不同網段，所以可能問題出在是數據配置上。

2.OLT側抓包分析

如圖2所示，不正常丟包下的ONU，從OLT（10.102.234.1）Ping問 題ONU（10.102.234.251） 時，ICMP Request消息包在SEQ=50/12800之前都可以得到ONU的Reply，但是在SEQ=51/13056之后，就沒有收到ONU應答，直到SN=414廣播消息發出后，才得到ONU的Reply消息。在此期間，有6個ICMP Request消息沒有得到響應，中斷時長約為15秒。根據IP通信原理，在局域網內是根據MAC地址來實際尋址的，此次問題應該為ONU ARP表項間歇性老化，未及時學習更新造成。

通過過濾出ARP廣播包，發現有問題的ONU收到廣播包的間隔時間約為24秒左右，序號為445和583之間間隔。而語音正常的ONU的廣播報時間為16秒。

通過核查不正常10.102.234.1這個網段和正常的10.101.234.1這個網段的數據配置，發現正常網段的IP，有一部分配到了其他OLT的用戶，可能與此網段的IP分在不同的設備上有關，當其他OLT用戶的ARP請求報文或是ARP廣播報文是廣播方式，又與這臺OLT是同一個VLAN，所以也會廣播到這臺OLT下，增大了頻率。

圖3 上聯交換機無回復ARP請求

至此問題定位基本可以判斷出主要是由于ARP列表老化造成ONU沒有MAC地址對應表，從而導致無法正常傳送包，但是ONU基本沒有什么配置內容，更換正常的ONU到有問題的網段，問題可以重現，所以推斷出問題應該出現在OLT配置數據上。

3.通過下載正常OLT的局數據配置和此臺OLT配置進行比對，發現開局時為了滿足集團客戶PON口下不同用戶語音業務互通需求，此臺OLT開啟了MFF代理功能（MFF：MAC Forced Forwarding，MAC 強制轉發，可禁止同一子網的兩個用戶間直接互通，并把用戶的上行流量強制轉發到網關，由網關轉發流量來實現用戶間的三層互通），但OLT配置MFF代理IP所指向設備（OLT上聯S9303交換機）卻末開啟ARP PROXY功能，導致此臺OLT將所有用戶語音IP的ARP請求轉送到上層S9303時，此設備全未回復ARP請求，從而導致每隔一段時間即出現因終端不知網關ARP信息，而數據丟包情況發生。消息如圖3所示。

解決方法

因為此臺OLT下特殊組網，一個語音VLAN帶5個IP網段，OLT上設置MFF代理只能配置一個代理服務器IP地址，無法滿足5個網段所有用戶同OLT下互通需求，所以關閉OLT的此代理功能，在語音網關設備交換機上開啟ARP Proxy功能，此OLT下不同用戶二層互通，通過網關進行轉發，即能防止廣播泛洪，也能滿足此語音VLAN下所有用戶的互通問題。

維護建議

1.OLT與上聯設備對接時，建議兩邊端口模式配置一致，全部自協商或強制。

2.語音業務VLAN下，建議一個VLAN一個IP網段，VLAN下帶用戶越多，故障風險越高。

3.建議OLT開啟端口保護功能，能有效防止廣播泛洪或用戶電腦ARP病毒干擾其他用戶業務等問題。

4.當OLT下用戶有互通需求時，建議由網關設備開啟ARP代理功能。

5.數據配置最好按照業務的標準模板進行，否則出現問題，需要耗費大量的時間進行排查，對于非標準模板配置時，一定要做好業務驗證工作，防止業務開通后用戶的投訴，提升用戶使用感知。