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>

Reminder

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

upgrade

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

Publication Date:  2012-07-24 Views:  60 Downloads:  0
Issue Description
A carrier uses Huawei OptiX OSN 3500 (5.21.16.13) 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 MA5200G through a switch provided by Z (a competitor), while the EFT8 is connected to a PC through a Huawei switch. Try to connect the PC to the MA5200G based o PPPoE dialup. The dialup fails and no connection is set up.      
Alarm Information
None.      
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 capture packets at positions A, B, C, and D as shown in the networking diagram. The packet capturing 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 captured at D. The PADS packet captured 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.      
Suggestions
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.
      

END