Version: NE40E V300R003C02B697
SCGSymptom: The customer complained that the access speed for GPRS services was low.
Huawei performed the following operations to address the problem:
1. Pinged the related IP address on the SCG from the GGSN. Packet loss occurred and the delay was great.
2. Pinged NE40E-A1 from the GGSN. No packet loss occurred and the delay was small. It was suspected that a fault occurred between NE40E-A1 and the SCG.
3. Pinged NE40E-A1 and the SCG from the switch. No packet loss occurred and the delay was small.
4. Pinged NE40E-A1 from the SCG. No packet loss occurred and the delay was small.
5. Checked traffic statistics on NE40E-A1, NE80E-B1, and NE40E-B1 about packets to the GGSN and SCG. Packet loss occurred between NE80E-B1 and NE40E-A1.
6. Ran display interface brief to check interface occupancy on NE80E-B1 and NE40E-A1. One interface in the IP-Trunk from NE40E-A1 to NE80E-B1 reached 97%, and the occupancies of other member interfaces were 40% to 50%. It was suspected that the problem was caused by hash-related issues.
7. Consulted the GGSN engineers about the GPRS traffic model. A GRE tunnel, which was set up between the GGSN and the SCG, carried all GPRS traffic. However, the recent GPRS traffic was greater than 155 Mbit/s (STM-1).8. Checked NE40ENE80E IP-TRUNK configurations. The flow-based HASH algorithm for load sharing was used by default. NE40E hashed all GPRS traffic carried by the GRE tunnel to only one member interface because it detected only one pair of source and sink tunnel IP addresses, resulting in congestion on the interface.