Because this problem included many devices, so we focused on one service from RNC to NodeB (see attachment "topo 2"). The ports of CX600 A were G1/1/1 and G1/1/19 in this service. Checking port statistic, we found there's packet loss in history.
<CX600 A>display port-queue statistics interface GigabitEthernet 1/1/1 ef outbound
Current usage percentage of queue: 0
186,156,407,829 packets, 54,729,983,866,753 bytes
3,035,671,974 packets, 992,681,124,613 bytes
Checking port configuration, we found there's port shaping about EF queue. It's possibly that packet loss caused service interruption.
<CX600 A>display current-configuration interface GigabitEthernet 1/1/1
port-queue ef pq shaping 100 outbound
Analyzing the traffic model, in normal case,service of CX600 A's g1/1/1 is 70M. When CX600 B's downstream link was broken, CX600 A's PTN mac address would be aged, meanwhile, PTN C always sent traffic to PTN D. So this part of traffic(40M around) would be broadcasted in all CX600, , so CX600 A's port bandwidth,100M, was insufficient. As a result, service was broken.
Since we know the root cause, we apply the unknown uni-cast suppression in CX600 A, after that, problem is solved.
1.RNC has problem.
2.Switch has problem
3.PTN has problem
4.CX600 has problem