Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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