No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


The QinQ service is activated on the EGS4 board of the OptiX OSN 3500, but PPPoE dialup fails

Publication Date:  2019-07-04 Views:  140 Downloads:  0

Issue Description

A carrier uses Huawei OptiX OSN 3500 ( to reconstruct its local network. The carrier uses the matched versions of the EGS4 (board software 413) and the EFT8. The carrier uses the MSP ring network. (The fault is not related to the actual networking mode.) The central office uses the EGS4, while other offices use the EFT8. The EGS4 is interconnected with Huawei Quidway MA5200Gthrough a switch provided by other company while the EFT8 is connected to a PC through a Huawei switch. Try to connect the PC to the MA5200Gbased o PPPoE dialup. The dialup fails and no connection is set up.      

Alarm Information


Handling Process

The EGS4 should add four filling bytes to the PADS packet after removing the S tag. In this way, the packet contains 64 bytes and the switch does not discard it. On the EGS4, run a PTP command to enable the runt packet repair function. The PPPoE dialup then succeeds and the services are activated.

For details, see the attachment.      

Root Cause

As the Datacom engineers say, PPPoE dialup consists of two steps:
1.The PC and the MA5200G exchange PPPoE protocol authentication packets.
1) The PPPoE terminal sends a PADI packet to the BASS.
2) The BASS sends a PADO packet to the PPPoE terminal.
3) The PPPoE terminal sends a PADR packet to the BASS.
4) The BASS sends a PADS packet to the PPPoE terminal.
2.A link is set up upon link authentication.
The data engineers help us to get packets at positions A, B, C, and D as shown in the networking diagram. From the packages discovers the following problem: The first three steps in the protocol authentication are normal. When the MA5200G is sending a PADS packet, the PADS packet is not found at D. The PADS packet found at C contains only 60 bytes. To confirm that the PPPoE dialup failure is caused by the PADS packet, try to access the Internet and download contents through the MA5200G by using static ARP. Accessing the Internet and downloading contents succeed. The related Huawei experts say that Huawei switch discards the received 60-byte PADS packets as abnormal packets because an Ethernet packet usually contains at least 64 bytes. (A packet that contains less than 64 bytes is called a runt packet.) Each PADS packet sent by the MA5200G contains 64 bytes. Why does the packet become 60 bytes after it passed the transmission network? On the current network, all QinQ services were activated on the layer 2 (L2) switch and are activated on the transmission EGS4 for the first time. The EGS4 board attaches an external tag (S) to all uplink packets (sent to the MA5200G) and removes the S tag from all downlink packets. The 64-byte PADS packet sent by the MA5200G contains a 4-byte S tag. After the EGS4 removes the S tag, the transmission network transparently transmits the packet to Huawei switch. Huawei switch then discards the packet as an abnormal packet. If the QinQ services are activated on a switch, this problem does not occur because the switch removes the S tag and then adds four filling bytes to the packet when sending the packet. The packet still contains 64 bytes, so the switch that connects to the EFT8 does not discard the packet.      


1.An outstanding problem exists after the runt packet repair function is enabled: The runt packet repair function of the EGS4 board needs to be enabled again upon a power failure of the equipment or reset of the board. According to the Ethernet principles, the filling bytes need to be added to the position where the tag was. Huawei needs to develop a software version that supports this function as soon as possible, so that the function needs not to be enabled upon any reset.
2.Packets that contain less than 64 bytes exist in many cases. For this reason, we suggest that  abnormal packets be judged according to the packet headers but not merely their lengths.