发布时间: 2019-07-04 | 浏览次数: 520 | 下载次数: 0 | 作者: 00062943 | 文档编号: ETC0002846765
【Problem Summary】ME60 下挂静态语音业务掉线问题
【Problem Details】
基本组网如下:
用户X.X.X.X(AAAA-AAAA-AAAA)-----[onu]-----[olt]----(G0/0/21[S5300](XG0/1/2)-----(g1/0/1)[S9300](eth-trunk1)----- Eth-Trunk1.703 [ME60]
1,在ME60上确认,故障时ME60上用户在线.
<ME60-X16>display access-user ip-address 172.21.233.63 vpn-instance CTVPN3000000-JXNGN
-------------------------------------------------------------------
User access index : 32106
State : Used
User name : ME60-X16-63201275000000@fttb-ngn-iad
Domain name : test
User backup state : No
User access interface : Eth-Trunk1.703
User access PeVlan/CeVlan : 2750/-
User access slot : 1
User MAC : AAAA-AAAA-AAAA
User IP address : X.X.X.63
User gateway address : X.X.X.1
User Basic IP Type : -/-/-
User MSIDSN name : -
EAP user : No
MD5 end : No
MTU : 1500
User access type : VLAN-static
User authentication type : Bind authentication
.........
Access start time : 2014-12-24 09:29:28
Accounting start time : 2014-12-24 09:29:28
Online time (h:min:sec) : 82:06:13
2,交换机上基于IP地址做流量统计,确认收发正常.
<S9306>display traffic policy statistics interface g 1/0/1 in
Interface: GigabitEthernet1/0/1
Traffic policy inbound: liu
Rule number: 2
Current status: OK!
Board : 1
Item Packets Bytes
---------------------------------------------------------------------
Matched 14 1,484
+--Passed 14 1,484
+--Dropped 0 0
+--Filter 0 0
+--URPF - -
+--CAR 0 0
3,ME60查看丢弃记录,确认是ping不通时是由于目的MAC不等于本机MAC丢弃。
4,再次回到交换机,基于MAC统计用户流量,确认ping用户不通时用户回上来的报文的目的MAC不等于ME60的trunk接口的MAC(TTTT-TTTT-TTTT)了,而是等于ME60的一个接口MAC(PPPP-PPPP-PPPP)。由此怀疑是终端的ARP在跳变。
[S9306]display traffic policy statistics interface Eth-Trunk 1 outbound verbose rule-base
rule 15 permit source-mac AAAA-AAAA-AAAA ffff-ffff-ffff dest-mac TTTT-TTTT-TTTT ffff-ffff-ffff
Passed Packet 103,Passed Bytes 11,479
Droped Packet 0,Droped Bytes 0
rule 21 permit source-mac AAAA-AAAA-AAAA ffff-ffff-ffff dest-mac PPPP-PPPP-PPPP ffff-ffff-ffff
Passed Packet 214,Passed Bytes 32,813
Droped Packet 0,Droped Bytes 0
分析ARP跳变的可能原因,有两种可能:
(1)ME60发出的ARP的MAC地址有问题
(2)对端从其他设备还能收到IP相同的ARP报文
5,在ME60上debug ARP报文,确认ME60发出的ARP报文的MAC地址正常。由此确认是下游设备问题。
Dec 25 2014 16:44:53.480.1+08:00 ME60-X16 ADA/7/ADATS_DBG:Slot=2;
TS_Send Output begin: IfIndex=0x32 cur_time(0, 144063361)
send_blade=4, send_port=3, vland_id=2750
VrfId=0, L3_type=0, packet_type=0
Total length = 60,
TS MODE Mbuf Content (64byte):
AAAA AAAA AAAA TTTT TTTT TTTT 8100 eabe
0806 0001 0800 0604 0001 f84a bf66 7aa4
ac15 e901 0818 1a1f c83e ac15 e919 0000
0000 0000 0000 0000 0000 0000 7aa4 1088
6,客户排查OLT,确认此OLT是做了静态MAC绑定,绑定的MAC地址就是PPPP-PPPP-PPPP
解除该绑定后问题恢复。
7,跟客户核实这个问题的发生背景,确认之前ME60和S9306是单条链路对接,后来扩容多条链路进行eth-trunk捆绑,S9306下挂的ZTE的OLT为了实现同局域网(VLAN)内的通信,在接口上面绑定了ME60 (G1/0/2)端口的MAC,上行设备进行链路调整之后,对应的MAC绑定并没有取消,从而导致下挂的语音业务上送的MAC概率性改变,取消对应的MAC绑定之后问题解决。
对于链路调整、设备割接、板卡替换的情况,需要提前识别下游设备是否有MAC精确绑定,如果有,直接操作会业务中断。
此时都需要解除MAC绑定,待调整稳定后再根据实际情况重新绑定。