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?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
Version: NE40 VRP3.10 2321 and NE20 VRP5.30 23122004
The networking diagram is as follows:
Multiple NE20s and an NE40 are connected through an MP-Group interface with the bandwidth 4 Mbit/s. EBGP is running on the NE20s and the NE40. The NE40, C6509, and S8512 are connected through GE interfaces running OSPF.
Symptom: The clients attached to the NE20s access the S8512 at a lower rate. When the clients ping the S8512 by sending large packets, the packets are lost.
Check the CPUs and memories of the NE40 and NE20s, both are normal. Therefore, the problem is nor caused by the insufficient processing capabilities of the routers.
Use the client to ping the NE40 by sending large packets and the packets are lost. However, the number of CRC error packets is not increased on the MP-Group interface through the NE20 and NE40 are connected. Therefore, the problem is not caused by a failure in the physical interface or link.
Use the NE40 to ping the S8512 by sending large packets and the packets are not lost. This proves that the interface and link through which the NE40 and the S8512 are connected are working properly. Packet loss occurs on the link between the NE40 and the NE20.
Perform the EACL test on the NE40. The NE40 can receive all the ICMP Request messages that the client sends to ping the S8512 and forward them to the S8512. Meanwhile, the NE40 can receive all the ICMP Reply messages that the S8512 sends.
Since packet loss all occurs when multiple clients attached to the NE20s ping the S8512, it cannot be the NE20 fault. Based on the preliminary analysis, the packet loss occurs on the CPOS interface on the NE40.
Capture the packets on the GE interface through which the NE40 and the C6509 are connected. The test result shows that the packets with which the S8512 responds to the client are defragmented 1500-byte TCP packets. Check the traffic statistics on the MP-Group and find that the traffic volume is over 2 Mbits. Since the traffic statistics on the interface is displayed as an average value for a specific period, the statistics cannot show the traffic burst. Based on the analysis of the captured packets on the GE interface, there is a high probability that the S8512 responds to the client with large packets, causing traffic burst. As a result, the packets are discarded on the CPOS interface on the NE40.
Based on the further analysis, queue scheduling is configured on the low-speed interface on the NE40. The default flow in the BE queue can only use 1/32 of the token bucket (256 kbits), that is, 8 kbits. If the traffic burst size exceeds 8 kbits within a second, packet loss will occur. This problem does not occur on flows in the EF queue. Therefore, configure QoS for the flow from the client to the S8512 and define the flow to be in the EF queue.
Set the bandwidth for the flow in the EF queue to 3.2 Mbit/s on the MP-Group interface. As a result, the flow in the EF queue occupies 80% of the total available bandwidth (3.2 Mbit/s/4 Mbit/s = 80%). After the preceding configurations are complete, no packet loss occurs when the client pings the S8512 by sending large packets. The services recover. Although packet loss occurs when the client pings the other network segments attached to the NE40, the services are not interrupted because the services are running based on small packets.
Configure QoS for the flow from the client to the S8512 and define the flow to be in the EF queue. Set the bandwidth for the flow in the EF queue to 3.2 Mbit/s on the MP-Group interface. As a result, the flow in the EF queue occupies 80% of the total available bandwidth (3.2 Mbit/s/4 Mbit/s = 80%).