I own a MikroTik RB5009 and subscribe to a 2Gbps fiber plan (with 1Gbps upload) using a GPON SFP ONU Stick (NIJIKA). This setup replaces the stock ONU provided by the ISP.

Since ROS 7.19, Mikrotik has fixed Flow Control of RB5009, as side effect queue need to manage.

Why Not Use the Stock ONU?

Most stock ONUs come with internal queuing and shaping, which often limits performance — especially upload speed, where 1Gbps upload cannot be sustained indefinitely due to SoC queue aggressive to prevent drop. Also not forget stock ONU has speedtest.net exception just to make customer happy, and customer not know that bandwidth are 100% all time.

To bypass this, I use a “dumb” GPON SFP stick that has:

• No internal queue
• Only basic asynchronous flow control and pause frame support

This gives full control to the MikroTik — but it comes with a catch.

MikroTik Tx Drop Problem

Since the SFP stick doesn’t manage queues by default:

• MikroTik is not aware that the GPON side has no buffering
• Pause frames from the ONU are often ignored
• This leads to Tx drops on sfp-sfpplus1 and vlans
• Symptoms: LCP echo loss, PPPoE instability, or jitter-sensitive apps failing

The Fix: Move Queue Control to MikroTik

We must handle upload queuing properly using MikroTik’s features:

• Disable FastTrack
• Reboot to flush sessions
• Add queue trees and use packet marks for upload traffic

Packet Marking (Upload)

We’ll mark all upload packets leaving the PPPoE interface:

/ip firewall mangle add chain=postrouting out-interface=pppoe-out1 action=mark-packet new-packet-mark=upload comment="queue: upload"
/ipv6 firewall mangle add chain=postrouting out-interface=pppoe-out1 action=mark-packet new-packet-mark=upload comment="queue: upload"

Custom Queue Types

Multi-Queue PFIFO for Physical Interfaces

As speed increase, default 50 queue size are not sufficient for gigabit or more, cause queue become overflow and interface start dropping packet. So we added few for 1G (large), 5G (xl) and 10G (xxl)

/queue type add name=multi-queue-ethernet-large kind=mq-pfifo mq-pfifo-limit=2000
/queue type add name=multi-queue-ethernet-xl kind=mq-pfifo mq-pfifo-limit=4000
/queue type add name=multi-queue-ethernet-xxl kind=mq-pfifo mq-pfifo-limit=8000

FQ-CoDel for PPPoE

As my ISP still relying on PPPoE, despite old protocol inefficient.

/queue type add name=fq-codel-pppoe kind=fq-codel fq-codel-quantum=1492

Apply Custom Queues

Set Default Queue for All Physical Interfaces

Change all physical interface to multi-queue-ethernet-default

/queue interface set [ find default-queue=only-hardware-queue ] queue=multi-queue-ethernet-default

Apply Larger Queue on GPON WAN Interface

Physical WAN interface use larger multi-queue-ethernet-large

/queue interface set sfp-sfpplus1 queue=multi-queue-ethernet-large

Add Queue Tree for Upload

/queue tree add name=ppp.upload parent=global packet-mark=upload queue=fq-codel-pppoe max-limit=1G

ℹ️ Why parent=global?

Shaping happens before the traffic hits any interface. No stress on the interface.

⚠️ Why max-limit=1G?

My ISP provisions upload at around 1040 Mbps, but leaving a buffer headroom of ~40 Mbps allows FQ-CoDel to queue and pace traffic properly.

You should run multiple speed tests, average your real upload speed, and set max-limit accordingly. Avoid using full 100% to prevent burst-induced packet loss.

GPON & the Myth of 2Gbps

By design, GPON supports:

• 2.488 Gbps downstream
• 1.244 Gbps upstream (shared among users)

Yet many ISPs — including those in Singapore, Japan (Hikari), Italy, and more — are now offering 2Gbps plans over GPON.

How Is This Possible?

ISPs rely on burst performance and low average utilization per user

High-end ONUs often have 2.5GbE ports, but users aren’t told that the upstream GPON link is still limited to 1244 Mbps

Without proper shaping, this causes:

• Tx drops on routers
• Excessive latency and jitter
• Application instability

Why ISPs Do This

It’s a business-driven decision:

• To attract high-paying customers
• To increase ROI before upgrading to XG(S)-PON
• Hybrid OLTs can run GPON and XGSPON side-by-side using separate wavelengths

Eventually, high-speed users will migrate to XGSPON, while GPON remains for lower-tier plans.

Final Thoughts

If you’re running high-speed GPON:

• Don’t assume the ONU handles queues for you
• Offload all shaping to your router
• Use packet marking + fq_codel or cake
• Leave headroom in max-limit to avoid saturating your optical uplink