Skip to content

FTTH Guide (For end-users in India)

This is a straightforward article that is applicable to any FTTH (i.e. PON) customer (retail or otherwise, networking enthusiast or noob) in India and I will update its content as technology progresses over time.

Assumption(s)

  1. You are willing to bridge the ONT/ONU device and use your own router to handle the WAN interface
    • Because these devices are not meant for routing/Wi-Fi

Networking Topology

FTTH deployment in India is dominated by GPON & EPON

  1. GPON
    • Superior to EPON
    • Uses an ONT device on the end-user’s termination point
  2. EPON
    • Inferior to GPON
    • Uses an ONU device on the end-user’s termination point

ONT/ONU Devices

  1. There exist xPON ONUs that work with both GPON & EPON
  2. Now the ONU/ONT can either come with an APC or UPC connector
    • For some odd reason, LCOs/ISPs have the habit of installing APC cable for a UPC connector and vice versa which can damage the optical module on the ONT/ONU
      • Ensure you take the responsibility to make them install the right connector

Bridge Mode

  1. Huawei’s Guide is good enough for general purposes and idea
  2. Some ONTs/ONUs do not have a dedicated bridge mode option, in which case you will need to delete all the “WAN” interfaces and it will automatically bridge
    • If your provider uses VLAN tagging for the PON link, you will need to VLAN tag from your router

Some configuration parameters to take care of

  1. Do not forget to set IP Protocol to IPv4/IPv6 if the option is available like this in the ONT/ONU bridge interface
  2. Do not forget to set bridge MTU to 1500 like this if the option is available
    • Set it to 1520 if it allows that value in order to enable jumbo frame negotiation with some devices like MikroTik
      • If it is capped at 1500 it will lead to problems with PPPoE interfaces, which is elaborated further down in this article
    • If the option is not available then the firmware would automatically set it to 1500
  3. Do not forget to set the correct MTU on the router if your provider uses PPPoE
    (Set it to 1500,1492 initially, whichever your router supports the most and then test to find the optimal size)
    • Some routers have auto-MTU which does the job for you, use it if available
  4. Set different subnets for ONT & Router
    • Example:
      ONT: 192.168.1.1/24 (255.255.255.0 subnet-mask)
      Router: 192.168.2.1/24 (255.255.255.0 subnet-mask)

Odd Problem(s) with some ONT/ONU models

  1. Some models capped bridge MTU at 1500
    • This only affects PPPoE interfaces
      • So if your ISP deployed RFC4638, you will not be able to take advantage of it
      • If you want to prevent fragmentation
        • Drop the MTU on the router’s PPPoE interface by subtracting 8 bytes from ISP’s provided MTU (do not confuse this with PPPoE’s 8 Byte overhead). I arrived at this number by testing them out with trial and error
          • So for example, if ISP’s MTU is 1492 then -8, the resulting MTU would be 1484
          • Real-Life Example – BSNL’s PPPoE MTU is 1460 then -8, the resulting MTU would be 1452

These models do not have the odd problem(s) mentioned above

Regarding MTU in General

Now we know the standard MTU for ethernet is 1500. But in India, the majority of ISPs are using PPPoE for customer access, which has 8 bytes overhead so that leaves us with 1492. Worse some ISPs even cap it lower than 1492 for nonsensical reasons and do not deploy RFC4638.

The IETF published RFC 8900 which shows why anything lesser than 1500 will result in an un-optimal experience for end hosts/users/devices. Even if you correctly set the MTU on the WAN interface (which you always should), not all websites/apps/remote destinations will be able to send/receive ICMP Packet Fragmentation (Type 4), some routers along the path of the internet will drop ICMP due to misconfiguration or an ignorant admin.

So the only work-around is to enable TCP MSS Clamping and set it clamp to the MTU (since we already determined the proper MTU for the WAN interface) if your router/network OS has this option. By doing so, you will reduce the impact of broken MTU at least for TCP traffic. UDP would be left out in this, though since we have set the correct MTU on the WAN interface, the impacts of broken PMTUD should be negligible in most cases and if it works as expected, UDP traffic would fragment accordingly.

I tested this in my home network with an ISP whose MTU and MRU are capped at 1460 with a 200Mbps package. Now with TCP MSS clamping disabled on the WAN interface, TCP bandwidth performance dropped by 50% (from 200Mbps to 100Mbps), with TCP MSS clamping enabled on the WAN interface, TCP bandwidth performance went back up to the original 200Mbps package. The reason is for this is due to the fact that PMTUD simply is not a reliable method to fragment packets/determine MSS for the TCP connection to the remote end-host that I was running the speed test on.

Published inNetworking

Be First to Comment

    Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.