When you are configuring a BNG gateway, one of the biggest concerns is with de payload length that our subscribers will have available to use on each packet.
Why this is a concern?
With the growth of the use of streaming applications, the traffic tries to use the maximum MTU available on the path. But as you know, on the IPv4 protocol this attribute considers the MTU negotiated by the two ends of the session, and sometimes, if we have a hop with the MTU smaller than what was negotiated between the two ends of the session, we will have fragmentation on the communication.
This fragmentation requires space on buffer to reconstruct the original packets, but to streaming, unfortunately is normal that we have an overflow and discard some content.
When I have to have this concern?
We have to worry about MTU in some points of our network, for example on my MPLS structure, on my transportation contracts, on my subscriber access, etc.
But why the title of this post is “The ppp-max-payload trap”?
One of the points where we must make attention to MTU on our structure is when we use PPPoE to our subscriber's access.
When we use PPPoE as the protocol to control the connection, we have to add 6 Bytes of the header on the original packet, then the MRU (Maximum Receive Unit) cannot be greater than 1494 Bytes.
The default configuration of Huawei´s BNG considers that is not necessary to negotiate the MRU of the connection during the link discovery phase of PPPoE process. If MRU of PPPoE connection is not negotiated during link discovery, the device directly forwards packets smaller than the negotiated MTU and fragments packets that are longer in length.
In some environments, I already saw administrators changing the default behavior of BNG using the below command:
[HUAWEI] pppoe ppp-max-payload enable
With this command, during the link discovery phase of PPP process, the MRU of the connection will be limited by the smaller value between MTU, and Max Payload value defined by the administrator.
Studying all the theories of this process, we cannot saw any problem, because in a perfect world all manufacturers correctly follow all RFC and other standards. In this perfect world, we can use any BNG product interacting with any CPE equipment and all of that we read until now works perfectly.
Unfortunately, we only see a perfect world at the end of Fairy Tales. In our real world the biggest concern of the administrators is to solve a lot of interoperability issues found between the different manufacturers.
Sometimes I am approached by ISP administrators asking about problems with your subscribers when trying to access streaming contents. This normally is a symptom of problems during the MTU negotiation. More than 80% of the ISPs that ask me about this problem are using this command and experimenting problems with low-cost CPE.
What I’ve already discovery is that there is some problem during the negotiation phase between Huawei and some low-cost CPEs and for this the MRU set to a wrong value.
All clients where I deactivate this command, turning the BNG to default configuration do not have this symptom anymore.
If you need to know more about the PPPoE process, you can use the HCIA-Datacom Training Material using this link. https://e.huawei.com/en/talent/ - /cert/product-details?certifiedProductId=287&authenticationLevel=CTYPE_CARE_HCIA&technicalField=IIC&version=1.0
To learn more about the command “pppoe max-payload” you can access this link https://support.huawei.com/hedex/hdx.do?docid=EDOC1100169782&id=EN-US_CLIREF_0314069563&lang=en
If you have more information to aggregate to this discussion, please, send to us commenting.
#HuaweiEntrepriseCommunity
#MVE
