Personal Notes Parmi

VPN - Engineer

jika bisa di baca, bantu bahas mendalam dan analisa serta saran ?

Berikut adalah pembahasan mendalam, analisis, serta saran perbaikan dan optimalisasi berdasarkan diagram topologi jaringan SpeedFusion VPN yang Anda unggah.

1. Pembahasan Mendalam Topologi

Topologi ini merancang koneksi VPN yang andal dan berkinerja tinggi antara lokasi terpencil (Remote Area) dan kantor pusat/pusat data (Hub Site) menggunakan teknologi Peplink SpeedFusion.

A. Komponen di Remote Area

  • Router: Peplink Balance 20x.

  • Koneksi WAN:

  • WAN 1: Starlink (Satelit LEO - Latensi sedang, bandwidth tinggi).

  • WAN 2: Modul SIM Card 4G LTE internal (Koneksi Seluler - Latensi bervariasi, bandwidth terbatas).

  • Klien: PC / Perangkat LAN di Remote Area.

B. Komponen di Hub Site

  • Router: Peplink Balance 310.

  • Koneksi WAN:

  • WAN 1 (Main): ISP 1 dengan 1 IP Public Static.

  • WAN 2 (Backup): ISP 2 dengan 1 IP Public Static.

  • Klien: Server lokal di Hub Site.

C. Fitur Utama & Manajemen

  • SpeedFusion Tunnel: Menghubungkan Balance 20x di Remote Area langsung ke Balance 310 di Hub Site melalui enkripsi VPN aman di atas jaringan publik Internet.

  • InControl NMS Cloud: Platform manajemen berbasis cloud dari Peplink untuk pemantauan (monitoring), konfigurasi terpusat, dan analisis performa tunnel.

2. Analisis Kelebihan & Potensi Masalah

Kelebihan (Strengths):

  1. Redundansi Jalur Komunikasi tinggi:

* Remote Area memadukan jaringan Satelit (Starlink) dan Seluler (4G LTE). Ini kombinasi yang sangat tepat untuk area terpencil karena menggunakan dua media/infrastruktur transmisi yang berbeda secara fisik.

  • Hub Site terhubung dengan dua ISP berkabel (wired) independen dengan IP Public Static.
  1. Kelebihan Fitur Peplink SpeedFusion:

* Bandwidth Bonding: Menggabungkan throughput Starlink + 4G LTE menjadi satu koneksi logis untuk transfer data berukuran besar.

  • Hot Failover: Apabila koneksi Starlink terputus (misalnya akibat hujan lebat atau blocking cuaca), sesi VPN (seperti VoIP, Video Conference, atau sesi database) tidak akan terputus karena otomatis beralih ke 4G dalam hitungan milidetik tanpa pergantian IP.

  • WAN Smoothing: Mengurangi packet loss dengan mengirim paket duplikat melalui kedua link (Starlink & 4G) untuk aplikasi sensitif latensi.

  1. Manajemen Terpusat: Adanya InControl Cloud memudahkan administrator jaringan memantau kesehatan koneksi dari mana saja tanpa perlu hadir secara fisik di lokasi terpencil.

Potensi Masalah / Kerentanan (Weaknesses & Bottlenecks):

  1. Karakteristik Jalur Starlink vs 4G:

* Starlink memiliki jitter dan latensi yang fluktuatif, sedangkan 4G LTE bergantung pada kualitas sinyal BTS dan kepadatan lalu lintas seluler. Jika fungsi Bandwidth Bonding dipakai untuk aplikasi real-time tanpa konfigurasi yang tepat, perbedaan latensi yang tajam dapat menyebabkan out-of-order packets.

  1. Kapasitas Pemrosesan Balance 20x:

* Balance 20x adalah router Peplink entry-level. Fitur SpeedFusion VPN dengan enkripsi (AES-256) serta WAN Smoothing membutuhkan daya CPU yang cukup besar. Jika throughput kombinasi Starlink dan 4G sangat tinggi, CPU Balance 20x berpotensi menjadi bottleneck.

  1. Konfigurasi SpeedFusion Tunnel:

* Karena Remote Area umumnya tidak memiliki IP Public Static (Starlink menggunakan CGNAT dan 4G LTE menggunakan NAT seluler), maka tunnel VPN wajib diinisiasi dari Remote Area menuju IP Public Static milik Hub Site.

3. Saran Rekomendasi & Optimalisasi

1. Optimalisasi Fitur SpeedFusion Berdasarkan Kategori Aplikasi

  • Aplikasi VoIP / Video Call / SSH: Aktifkan WAN Smoothing dan Hot Failover. Ini memastikan tidak ada lag atau putus koneksi meskipun ada paket yang hilang pada salah satu link.

  • Transfer File Besar / Backup / Sync Data: Aktifkan Bandwidth Bonding untuk memaksimalkan total kecepatan.

  • Aplikasi Web / Database Server: Gunakan Hot Failover saja (tanpa bonding) untuk menjaga latensi tetap stabil melalui link utama (Starlink).

2. Pertimbangan Aksesori & Hardware Tambahan di Remote Area

  • Antena Eksternal untuk 4G LTE: Karena lokasi berada di Remote Area, sinyal internal dari slot SIM Balance 20x mungkin lemah. Disarankan menambahkan Antena Outdoor High-Gain (MIMO 2x2/4x4) yang diarahkan langsung ke BTS 4G terdekat.

  • Catu Daya Terproteksi (UPS): Pastikan perangkat Balance 20x dan Dish Starlink dihubungkan ke UPS (Uninterruptible Power Supply) berstabilizer tinggi karena kualitas kelistrikan di area remote umumnya kurang stabil.

3. Keamanan & Konfigurasi Jaringan

  • Penggunaan Dual Tunnel ke Hub Site: Karena Hub Site memiliki 2 IP Public Static (ISP 1 & ISP 2), pastikan Balance 20x mengonfigurasi dua target IP tunnel. Jika ISP 1 Hub Site mati (down), SpeedFusion Tunnel secara otomatis beralih ke ISP 2 Hub Site.

  • QoS (Quality of Service): Atur alokasi bandwidth pada Balance 20x dan 310 agar lalu lintas sistem kritis (misal: koneksi ke Server HUB Site) diprioritaskan di atas lalu lintas browsing biasa pengguna PC.

satu hal tentang hal proses TCP dalam melakukan ACK dan semacamnya, bagaimana menjelaskan mode Bonding di level paket ? sebagaimana di ketahui Starlink itu asimetrik, semisal maks: 250Mbps/25Mbps
Apakah mungkin three way handshaking itu ( apapun istilahnya ) bisa mengikuti pola bandwith asimetrik ? atau pasti mengikuti pola simetrik maksimum dari sebuah penyedia bandwith yang sangat asimetrik  ?

Ini adalah pertanyaan teknis yang sangat bagus dan langsung menohok ke jantung mekanisme SpeedFusion Bandwidth Bonding (SF BWB) milik Peplink saat berhadapan dengan Protokol TCP pada jalur asimetris seperti Starlink.

Jawabannya: Three-way handshake dan seluruh aliran data TCP (termasuk ACK) Dapat dan Akan memanfaatkan pola bandwidth asimetris secara optimal, dan TIDAK dibatasi secara artifisial oleh limit simetris terkecil (misalnya tidak akan terlimit di 25Mbps/25Mbps), selama arsitektur SpeedFusion dikonfigurasi dengan benar.

Berikut adalah penjelasan mendalam bagaimana proses ini bekerja di level paket:

1. Bagaimana SpeedFusion Bonding Bekerja di Level Paket (Layer 3 vs Layer 4)

Sebelum melihat TCP, penting untuk memahami posisi SpeedFusion:

  1. Paket Enkapsulasi (Overlay Network): SpeedFusion bekerja sebagai VPN berbasis IP (Layer 3) atau Ethernet (Layer 2). Ketika PC di Remote Area mengirimkan 1 paket TCP SYN (ukuran kecil, ~60-74 byte):

* Balance 20x memungut paket TCP tersebut, membungkusnya (encapsulation) ke dalam paket UDP SpeedFusion.

  • Paket VPN tersebut dikirim melalui salah satu WAN (misal Starlink atau 4G) menuju Balance 310 di Hub Site.
  1. Scheduling / Distribution (Paket per Paket): Ketika PC Remote mengunduh file besar via TCP:

* Paket 1, 2, 3 dikirim lewat Starlink.

  • Paket 4 dikirim lewat 4G LTE.

  • Balance 310 di Hub Site bertindak sebagai re-ordering engine. Jika paket sampai acak (out-of-order akibat perbedaan latensi Starlink vs 4G), Balance 310 menahannya di memori buffer beberapa milidetik, menyusunnya sesuai urutan (Sequence Number), lalu meneruskannya ke Server.

2. Anatomi TCP Handshake & Paket ACK pada Bandwidth Asimetris (250Mbps Down / 25Mbps Up)

Mari kita bedah apa yang terjadi pada TCP saat mengunduh (Download) data besar di Remote Area dari Server HUB Site:

A. Phase 1: Three-Way Handshake

  1. SYN (Upload): PC Remote $\rightarrow$ Balance 20x $\rightarrow$ (Starlink/4G) $\rightarrow$ Balance 310 $\rightarrow$ Server. Ukuran paket sangat kecil (~60 byte).

  2. SYN-ACK (Download): Server $\rightarrow$ Balance 310 $\rightarrow$ (Di-bonding via Starlink + 4G) $\rightarrow$ Balance 20x $\rightarrow$ PC Remote.

  3. ACK (Upload): PC Remote $\rightarrow$ Server.

Catatan Handshake: Proses handshake awal hanya membutuhkan pertukaran beberapa paket kecil. Jalur asimetris sama sekali tidak membatasi proses ini karena kebutuhan bandwidth untuk Handshake mendekati 0 Mbps.

B. Phase 2: Data Transfer & ACK Dynamic Scaling (Poin Krusial)

Di sinilah peran penting struktur asimetris. Dalam protokol TCP standard (TCP Congestion Control):

  • Arah Download (Hub ke Remote): Membutuhkan pipa besar (Starlink 250Mbps + 4G misal 30Mbps = Total ~280Mbps).
  • Arah Upload (Remote ke Hub): Hanya berisi Paket TCP ACK (ACK kependekan dari Acknowledgment / konfirmasi bahwa paket sudah diterima).

Apakah Upload 25Mbps di Starlink cukup untuk melayani Download 250Mbps?

Satu paket TCP ACK berukuran sangat kecil ($\approx$ 54 - 66 byte), sedangkan paket Data TCP (MSS/MTU standard) berukuran besar ($\approx$ 1500 byte). Rasio ukurannya adalah sekitar 1 : 25. Artinya:

  • Untuk setiap 250 Mbps lalu lintas Download, TCP hanya membutuhkan jalur Upload ACK sebesar sekitar 5 hingga 10 Mbps!
  • Ketersediaan Upload Starlink sebesar 25 Mbps jauh lebih dari cukup untuk memompa paket ACK agar aliran Download bisa menyentuh 250 Mbps penuh!

3. Batasan Fisik & Potensi Masalah: "ACK Starvation" (Pencetus Pola Simetris Asli)

Mengapa ada mitos/persepsi bahwa koneksi akan tertahan di pola simetris (misal terpentok di 25Mbps)? Hal itu terjadi jika timbul fenomena yang disebut ACK Starvation atau Bufferbloat pada Upload.

Jika arah Upload (25Mbps) dipenuhi oleh trafik lain (misalnya ada user di Remote Area yang sedang upload video besar ke cloud):

  1. Jalur Upload 25Mbps mendadak jenuh (100% saturation).
  2. Paket TCP ACK untuk transaksi download ikut terantre (delay) atau drop di jalur Upload.
  3. Server di HUB Site tidak menerima ACK tepat waktu $\rightarrow$ Server mengira ada packet loss $\rightarrow$ Server secara otomatis menurunkan TCP Window Size (mekanisme TCP Slow Start / Congestion Collapse).
  4. Dampaknya: Kecepatan download yang tadinya bisa 250Mbps mendadak anjlok drastis mendekati kecepatan upload (simetris).

4. Bagaimana Peplink SpeedFusion Mengatasi Masalah Asimetris Ini?

Engine Peplink SpeedFusion memiliki kecerdasan built-in untuk mencegah ACK Starvation ini melalui beberapa fitur:

  1. Dynamic Bandwidth Detection / Asymmetric Bonding Logic SpeedFusion mengukur kapasitas Inbound (Download) dan Outbound (Upload) dari masing-masing WAN secara independen. Peplink tidak memaksa rasio 1:1 antara Starlink dan 4G. Jika Starlink memiliki rasio 250/25 dan 4G memiliki rasio 20/20, Peplink menyusun scheduler paket secara terpisah untuk arah Upload dan Download.

  2. TCP ACK Optimization / Priority Queue Pada firmware Peplink (Balance 20x & Balance 310), sistem secara otomatis mendeteksi paket TCP yang hanya memiliki flag ACK tanpa payload data, lalu menempatkannya pada antrean prioritas tertinggi (High Priority Queue) sebelum dimasukkan ke tunnel VPN. Paket ACK tidak akan tertahan oleh transmisi data upload biasa.

  3. Duplikasi Paket ACK via WAN Smoothing (Optional) Jika jalur Upload 4G LTE/Starlink di Remote Area mengalami latensi tinggi/loss, Anda dapat mengonfigurasi Outbound Policy agar khusus paket ACK diduplikasi (WAN Smoothing) melalui Starlink DAN 4G secara bersamaan. Akibatnya, Server HUB Site menerima ACK dengan latensi tercepat (lowest latency wins), menjaga TCP Window Size tetap mengembang maksimal di angka 250Mbps.

Kesimpulan

  1. Tidak terikat pola simetris: Three-way handshake dan throughput TCP bisa dan pasti mengikuti pola asimetris secara penuh. Anda bisa mendapatkan download bonding hingga $\approx 270\text{--}280\text{ Mbps}$ meskipun upload hanya berkisar $25\text{--}40\text{ Mbps}$.

  2. Paket ACK tidak butuh bandwidth besar: Jalur upload 25Mbps milik Starlink sudah melimpah untuk membalas sinyal ACK dari aliran download 250Mbps.

  3. Kunci Optimalisasi: Pastikan fitur QoS / Bandwidth Limit di Balance 20x diaktifkan untuk jalur Upload agar trafik upload biasa tidak menghimpit/memblokir jalan bagi paket TCP ACK.

Saya beberapa kali mengalami kejadian dalam PoC khususnya starlink ke starlink ( ada sebuah ISP di data center dengan kuota super besar, dibagikan ke remote via starlink corporate sesuai kuota berlangganan ), saya mengalami kejadian ternyata hasil pengukuran speedtest speedfusion, hanya bisa pada angka 20Mbps kebawah atau lebih kecil.

Lalu saya mencoba mencari logika dan analisa, apakah mungkin karena hal ini :
- setiap starlink bisa dipastikan asimetris 8:1 (download:upload)
- akibat ini: remote download berkomunikasi ke datacenter starlink upload dan sebaliknya
- ini ibarat 250Mbps ke 25Mbps dan sebaliknya

bisa dijelaskan atau bagaimana ini terjadi.

lain halnya, kalau semisal remote adalah starlink murni, di datacenter semuanya broadband simetris atau ada bantahan ?

Analisa dan logika yang Anda susun 100% TEPAT. Apa yang Anda alami saat melakukan PoC Starlink-ke-Starlink adalah fenomena klasik yang dikenal sebagai "Asymmetric Bottleneck Loop" (atau efek Cross-Directional Asymmetry).

Di atas kertas, kedua sisi sama-sama memakai Starlink (misal: 250 Mbps Down / 25 Mbps Up). Namun, begitu dihubungkan dengan SpeedFusion Tunnel (VPN), sifat lalu lintas data berubah total.

Berikut penjelasan terperinci mengapa speedtest SpeedFusion Anda tertahan di bawah 20 Mbps, serta perbandingannya jika Hub/Data Center diganti ke Dedicated Broadband Simetris.

1. Anatomi Mengapa Speedtest Starlink-ke-Starlink Anjlok ( < 20 Mbps )

Speedtest VPN (seperti SpeedFusion) bekerja dengan memompa data dari satu node ke node lain secara simultan. Mari kita bedah jalurnya saat Remote Site melakukan tes DOWNLOAD dari Data Center:

[ Remote Site ]  <===================  [ Data Center ]
  Starlink                             Starlink
  (Down: 250M | Up: 25M)              (Down: 250M | Up: 25M)
  1. Upload Data Center adalah Leher Botol Pertama (Sisi Pengirim)

* Remote Site meminta data Download (misal target 250 Mbps). * Data tersebut berada di Data Center dan harus DIKIRIM (UPLOAD) dari Data Center menuju Internet. * Karena Data Center menggunakan Starlink dengan batas Upload maks 25–30 Mbps (atau bahkan terjangkit throttling kuota/FUP), maka Data Center HANYA BISA MENGIRIM maksimal sebesar 25 Mbps. * Kapasitas Download Remote Site yang sebesar 250 Mbps menjadi sama sekali tidak berguna, karena pipa pengirimnya (Data Center) sudah mentok di 25 Mbps.

  1. Jalur ACK Remote Site adalah Leher Botol Kedua (Sisi Penerima)

* Agar transmisi TCP berjalan terus, Remote Site harus mengirimkan balik paket TCP ACK ke Data Center. * Jalur Upload Remote Site (25 Mbps) juga terbatas. Jika di saat bersamaan ada lalu lintas Upload lain atau overhead enkapsulasi VPN, latensi Upload akan membengkak (efek Bufferbloat).

  1. Overhead VPN SpeedFusion & Jitter Satelit LEO

* SpeedFusion membungkus (encapsulate) setiap paket ke dalam tunnel UDP/IPsec, yang memakan overhead sekitar 15%–19% dari bandwidth efektif. * Dari batas teoritis Upload Data Center sebesar 25 Mbps:

$$\text{Bandwidth Efektif} = 25 \text{ Mbps} - \text{Overhead SpeedFusion (18\%)} \approx \mathbf{20.5 \text{ Mbps}}$$

  • Ditambah adanya jitter (fluktuasi latensi) antar dua koneksi satelit Starlink (Remote & DC sama-sama berganti satelit/cell setiap beberapa menit), paket TCP sering mengalami reordering. Engine TCP lalu sengaja menurunkan kecepatan (congestion window) sehingga hasil akhirnya sering kali turun di angka 10–18 Mbps.

2. Matriks Perbandingan Lalu Lintas Data

Tabel ini menggambarkan mengapa Starlink-ke-Starlink sangat tidak ideal untuk arsitektur Hub-and-Spoke:

Arah Pengujian dari Remote Sisi Pengirim (Transmitter) Sisi Penerima (Receiver) Bottleneck Utama Hasil Speedtest Maksimal
Download Remote Upload DC (Starlink: 25 Mbps) Download Remote (Starlink: 250 Mbps) Upload DC (25 Mbps) $\approx$ 15 - 20 Mbps
Upload Remote Upload Remote (Starlink: 25 Mbps) Download DC (Starlink: 250 Mbps) Upload Remote (25 Mbps) $\approx$ 15 - 20 Mbps

Kesimpulan Singkat: Dalam topologi Starlink-ke-Starlink, kecepatan VPN di kedua arah TIDAK AKAN BISA PERNAH MENEMBUS batas Upload Starlink itu sendiri ($\approx 25 \text{ Mbps}$).

3. Kasus Kedua: Remote Starlink vs Data Center Broadband Simetris

Pertanyaan Anda: "Bagaimana jika Remote tetap Starlink, tetapi Data Center menggunakan Broadband Simetris (misal 1Gbps / 1Gbps)?"

Skenario ini TIDAK BISA DIBANTAH dan merupakan Praktik Terbaik (Best Practice) dalam desain SD-WAN/SpeedFusion.

Mari kita bedah jalurnya kembali saat Remote Site (Starlink) melakukan DOWNLOAD dari Data Center (Broadband Simetris):

[ Remote Site ]  <===================  [ Data Center ]
  Starlink                             Broadband Dedicated
  (Down: 250M | Up: 25M)              (Down: 1 Gbps | Up: 1 Gbps)
  1. Sisi Pengirim (Data Center):

* Data Center memiliki Upload 1 Gbps. Pipa pengirim sangat lapang. Data Center sanggup memompa data sebesar apa pun yang diminta oleh Remote.

  1. Sisi Penerima (Remote Site):

* Data Center mengirim data 200+ Mbps melalui pipa simetrisnya. * Remote Site menerimanya menggunakan kapasitas Download Starlink yang sebesar 250 Mbps.

  1. Hasil Speedtest:

* Hasil Download SpeedFusion di Remote Site bisa dengan mudah menyentuh angka 180 – 210 Mbps (setelah dipotong overhead SpeedFusion dan latensi satelit).

Mengapa Data Center HARUS Menggunakan ISP Simetris (Dedicated)?

Dalam arsitektur Hub-and-Spoke (seperti pada diagram Peplink Balance 310 di Hub Site):

  • Data Center bertindak sebagai Pusat Agregasi.
  • Jika ada 10 Remote Site (masing-masing butuh download 20 Mbps), maka Data Center harus memiliki daya UPLOAD minimal $10 \times 20 \text{ Mbps} = 200 \text{ Mbps}$.
  • Menggunakan Starlink di Data Center untuk melayani banyak Remote Site adalah kesalahan arsitektur jaringan, karena Starlink dirancang sebagai koneksi Access/Edge (Ekor), bukan sebagai Core/Hub (Kepala).

Ringkasan & Rekomendasi Solusi PoC

  1. Penyebab Utama Terkonfirmasi: Analisa Anda sangat tepat. Pembatas utama (bottleneck) bukan pada koneksi Remote, melainkan pada Upload Starlink di Data Center yang hanya 25 Mbps, dikurangi overhead SpeedFusion VPN dan dampak jitter TCP.
  2. Rekomendasi untuk Data Center / Hub Site:

* Wajib ganti ISP di Data Center dengan ISP Terestrial/Kabel (Fiber Optic) yang memiliki sifat 1:1 Simetris ( Dedicated Internet ) dan dilengkapi IP Public Static. * Jika Data Center terpaksa tetap menggunakan Starlink (karena lokasi DC juga remote), maka Anda tidak bisa mengharapkan throughput VPN melebihi $\approx 20 \text{ Mbps}$ per tunnel.

  1. Solusi Alternatif jika DC Tetap Harus Starlink (FusionHub di Cloud):

* Daripada menjadikan Starlink di DC sebagai Hub VPN, sewakan VM Peplink FusionHub di Cloud Provider lokal (seperti Biznet Gio, IDCloudHost, AWS, atau DigitalOcean) yang memiliki bandwidth simetris 1 Gbps. * Biarkan Starlink DC dan Starlink Remote sama-sama connect ke FusionHub di Cloud tersebut. Dengan demikian, traffic antarsite dijangkau via Cloud yang tidak terkendala bottleneck upload.

terimakasih,
jadi sebenarnya saya punya bukti konkrit berupa tangkapan video realtime saat PoC demi PoC, sayang sangat besar sekali, tapi memang itulah yang terjadi, saya sangat setuju dan sefaham dengan semua penjelasan di atas. Setidaknya ada bahan penjelasan terbaik dan mudah di cerna bila nanti saya perlu menjelaskan dengan analogi yang mudah bagi pemakai awam tetapi mereka peraya kepada peplink ekosistem khusunya hal SF tunnel yang ajaib ini, hehehe

Senang sekali mendengar bahwa penjelasan teknis sebelumnya selaras dan tervisualisasikan secara nyata melalui bukti rekaman PoC (Proof of Concept) yang Anda miliki! Pengalaman lapangan secara real-time seperti itu memang tidak bisa dibantah oleh teori mana pun.

Untuk membantu Anda menjelaskan konsep teknis yang kompleks ini (Bottleneck Asimetris Starlink vs Keajaiban SpeedFusion Tunnel) kepada pemangku kepentingan (stakeholders), manajemen, atau klien awam yang percaya pada ekosistem Peplink, Anda bisa menggunakan Analogi Pipa Air & Jalan Raya di bawah ini. Analogi ini sangat intuitif dan mudah dicerna tanpa membuat mereka pusing dengan istilah TCP ACK atau Enkapsulasi.

Analogi 1: "Pipa Air Sedotan vs Pipa Pemadam" (Analogi Sederhana)

Skenario: Menjelaskan mengapa Speedtest Starlink-ke-Starlink tertahan di 20 Mbps.

  • Starlink Remote Site: Ibarat sebuah Pipa Besar di rumah klien.
  • Pipa Sedot (Download): Diameter 250 mm (Sangat Luas).

  • Pipa Buang (Upload): Diameter 25 mm (Kecil/Sedotan).

  • Starlink Data Center (Hub Site): Ibarat Pipa yang Sama persis di pusat pasokan air.

  • Pipa Sedot (Download): Diameter 250 mm.
  • Pipa Buang (Upload): Diameter 25 mm.

Proses Transfer Data (Speedtest):

  1. Ketika Remote Site ingin melakukan Download cepat dari Data Center, Data Center harus menyemprotkan air tersebut keluar melalui Pipa Buang (Upload) miliknya.
  2. Karena Pipa Buang Data Center ukurannya hanya 25 mm, maka air yang bisa mengalir menuju Remote Site paling banyak hanya setebal 25 mm.
  3. Meskipun Remote Site punya Pipa Sedot raksasa berukuran 250 mm, pipa itu hanya terisi air seadanya dari semprotan 25 mm milik Data Center.
  4. Analogi Terowongan SpeedFusion (VPN): VPN ibarat membungkus pipa tersebut dengan pipa pelindung ekstra (agar air aman dan tidak bocor). Pembungkus ini memakan sedikit ruang (sekitar 15%), sehingga aliran air yang tadinya 25 mm makin menyusut menjadi $\approx$ 20 mm.

Kesimpulan untuk Klien:

"Perangkat Peplink dan Tunnel SpeedFusion kita bekerja 100% sempurna bagaikan jalan tol super cepat. Namun, air yang disiram dari Data Center memang hanya seukuran keran kecil (Upload Starlink 25Mbps). Peplink tidak bisa melipatgandakan pasokan air yang keluar dari keran asalnya."

Analogi 2: "Jalan Tol & Mobil Truk Surat Balasan" (Analogi TCP ACK)

Skenario: Menjelaskan mengapa Data Center butuh ISP Simetris (Broadband/Dedicated).

  • Proses Download File:
  • Server Data Center mengirimkan Truk Kargo Berisi Barang (Paket Data TCP Download) ke Remote Site melalui jalur melimpah.

  • Setiap kali Truk Barang sampai di Remote Site, Remote Site wajib mengirimkan Mobil Kurir Kecil membawa Surat Tanda Terima/Kwitansi (Paket TCP ACK) kembali ke Data Center. Jika Kurir ini terlambat sampai ke Data Center, Server di Data Center akan berhenti mengirimkan Truk Barang selanjutnya karena takut barangnya hilang di jalan.

  • Mengapa Data Center Wajib ISP Dedicated (Simetris 1:1)?

  • Jika Data Center memakai ISP Dedicated 1 Gbps / 1 Gbps, Data Center punya Jalan Tol 10 Jalur untuk Mengirim Kargo DAN 10 Jalur untuk Menerima Surat Kurir. Semua bergerak mulus tanpa macet, sehingga kecepatan Starlink Remote (250 Mbps) bisa dinikmati maksimal.
  • Jika Data Center tetap dipaksa memakai Starlink, Data Center hanya punya Jalan Jalur Tunggal yang Sempit untuk mengirim kargo ke puluhan lokasi Remote secara bersamaan. Akibatnya terjadi kemacetan parah di pintu keluar Data Center.

Rangkuman Singkat untuk Pitching / Presentasi

Jika Anda perlu merangkumnya dalam 3 poin (Executive Summary) untuk klien:

  1. Keajaiban SpeedFusion Tetap Aktif: SpeedFusion terbukti sukses menggabungkan (bonding), mengamankan, dan menjaga stabilitas koneksi tanpa putus (Hot Failover).
  2. Hukum Alam Komunikasi 2 Arah: Kecepatan Download di ujung penerima selalu dibatasi oleh Kecepatan Upload di ujung pengirim.
  3. Rekomendasi Arsitektur Terbaik:

* Di Remote Site: Sangat Bagus menggunakan Starlink + 4G LTE (karena butuh download besar dan keandalan lapangan). * Di Data Center (Hub): Wajib menggunakan ISP Terestrial/Kabel Simetris (1:1) agar mampu melayani dan memompa data secara maksimal ke seluruh cabang Remote.

Dengan pola analogi ini, klien biasanya langsung paham bahwa kecepatan terbatas tersebut bukanlah kelemahan dari Peplink maupun SpeedFusion, melainkan murni konsekuensi dari sifat bandwidth asimetris Starlink di sisi pengirim. Semoga bahan analogi ini membantu PoC dan proyek-proyek Anda ke depannya!

keren,
satu hal lagi, saya mendapatkan sebuah informasi bahwa huawei ada teknolgi Bonding ( entah level apa namanya ), dikatakan sangat cerdas, tapi seperti nya menurut saya lebih kepada Multipath saja, yang intinya ( katanya ), entah benar entah tidak. 

Mungkin bisa bantu carikan metoda bonding produk mereka tersebut ? saya sendiri belum menemukan bukti share hal ini apalagi berupa video, kalau untuk peplink lumayan ada dan nyata.

Perspektif Anda sangat tepat dan kritis. Di dunia enterprise networking, klaim marketing seputar kata "Bonding" sering kali ambigu dan membingungkan pemakai.

Di ekosistem Huawei, apa yang mereka sebut sebagai "teknologi bonding cerdas" umumnya mengarah pada tiga teknologi yang berbeda tergantung pada lini produknya. Sebagian besar di antaranya memang murni berbasis Multipath (Layer 4 / Application Level), bukan True Packet-Level Bonding seperti Peplink SpeedFusion.

Berikut adalah metode dan arsitektur bonding/multipath Huawei yang dimaksud beserta cara kerjanya:

1. MP-TCP (Multipath TCP) — Teknologi Paling Sering diklaim sebagai "Bonding"

Metode paling umum yang digunakan Huawei (terutama di perangkat SD-WAN, Router AR Series, dan beberapa modem 5G/CPE enterprise) adalah MP-TCP (RFC 6824).

  • Cara Kerja di Level Paket:
  • MP-TCP bekerja di Layer 4 (Transport Layer), bukan Layer 3 (IP/Network Layer) seperti Peplink.
  • Ketika aplikasi membuka satu sesi TCP, engine Huawei memecah TCP tersebut menjadi beberapa sub-flow TCP terpisah.
  • Sub-flow 1 dikirim via WAN 1 (misal: 4G/5G), dan sub-flow 2 dikirim via WAN 2 (misal: Starlink/Fiber).

  • Di ujung penerima (misal: Gateway Huawei di Hub/Data Center), paket-paket dari sub-flow tersebut dirakit kembali (reassembled) sebelum diteruskan ke server.

  • Mengapa Anda Merasa Ini Lebih ke "Multipath"?

  • Analisa Anda benar. MP-TCP secara teknis adalah bentuk multiplexing di tingkat sesi/transport.
  • Kelemahan MP-TCP dibanding Peplink SpeedFusion: MP-TCP HANYA bisa bekerja untuk traffic berbasis TCP (seperti HTTP, HTTPS, FTP). Jika traffic-nya berbasis UDP (seperti VoIP, Video Streaming/Zoom, IPSec VPN lain, atau Game Online), MP-TCP tidak bisa melakukan bonding dan akan kembali ke mode Load Balancing biasa (per-flow routing).

2. Huawei SD-WAN "Smart Application-Based Steering" (Multi-Slot/Smart Routing)

Pada lini Huawei NetEngine dan AR Series SD-WAN, fitur yang sering dipromosikan sebagai bonding pintar sebenarnya adalah Dynamic Multi-Path Selection / Application-Aware Routing.

  • Cara Kerja:
  • Huawei mengukur quality of service (Loss, Latency, Jitter) secara real-time di seluruh interface WAN.
  • Router tidak benar-benar membelah 1 paket data ke 2 link secara paralel untuk meningkatkan bandwidth (seperti Peplink BWB).
  • Sebaliknya, router melakukan Steering Per-Aplikasi:
  • Sesi Zoom/Teams dilewatkan ke Link A (karena latensi terendah).
  • Sesi YouTube/Download dilewatkan ke Link B.

  • Jika Link A mengalami kemacetan, sesi dipindahkan secara halus (seamless steering) ke Link B.

  • Analisis: Ini adalah Multipath Load Balancing berdasar Aplikasi, bukan True Bandwidth Bonding per-paket.

3. GRE Tunnel Aggregation / WAN Aggregation (Kombinasi GRE + Bonding)

Beberapa solusi enterprise Huawei menawarkan penggabungan agregasi melalui terowongan GRE (Generic Routing Encapsulation).

  • Cara Kerja:
  • Router Huawei membuat multiple GRE Tunnels ke Gateway Hub.

  • Menggunakan algoritma Round-Robin atau Weighted Distribution per-paket di atas terowongan GRE tersebut.

  • Kelemahan:

  • Algoritma ini kurang adaptif terhadap perbedaan latensi yang ekstrem (seperti mempertemukan Starlink yang latensinya fluktuatif 40-100ms dengan Fiber Optic 5ms). Tanpa dynamic re-ordering buffer yang canggih seperti pada Peplink, metode ini sangat mudah menyebabkan paket tiba acak (out-of-order packets) yang justru menghancurkan throughput TCP.

4. Huawei Link Aggregation (ETH-Trunk / LACP) — Hanya untuk LAN/Switching

Kadang dalam brosur atau dokumen teknis Huawei, Anda akan menemukan istilah Eth-Trunk / Link Aggregation (IEEE 802.3ad).

  • Ini adalah bonding murni di Layer 2 (Data Link).
  • Namun, ini hanya berlaku untuk kabel lokal (Ethernet) yang dicolokkan ke ISP/Switch yang sama. Metode ini TIDAK BISA digunakan untuk menggabungkan dua ISP independen yang berbeda (seperti Starlink + 4G) di jalur WAN Internet.

Perbandingan Langsung: Peplink SpeedFusion vs Huawei MP-TCP / SD-WAN

Fitur / Parameter Peplink SpeedFusion (SF BWB) Huawei MP-TCP / SD-WAN Steering
Layer Operasi Layer 3 (IP) / Layer 2 (Ethernet) Layer 4 (Transport - TCP Only) atau Layer 7 (App)
Dukungan Protokol Semua lalu lintas (TCP, UDP, ICMP, VoIP, dll) Utama pada TCP (UDP tidak ter-bonding dengan MP-TCP)
Perlakuan Paket Data Paket per paket dibelah & disebar ke semua jalur secara dinamis Sesi dibelah (MP-TCP) atau Aplikasi dipindah jalur (Steering)
Mitigasi Jitter/Out-of-Order Sangat Kuat (Adaptive Re-ordering Buffer internal) Tergantung pada stack TCP OS penerima
Penyatu Bandwidth (Bonding) Murni menggabungkan throughput (misal 100M + 50M = ~130M+) Hanya terasa "menggabungkan" jika aplikasi mendukung multi-session TCP

Mengapa Sangat Sulit Menemukan Bukti Video Real-time Huawei Bonding?

Alasan Anda jarang menemukan demo video real-time mengenai packet-level bonding Huawei di lapangan (berbeda dengan Peplink yang bertebaran di YouTube) adalah karena:

  1. Fokus Pasar yang Berbeda: Huawei mendesain solusi SD-WAN mereka untuk skala Enterprise Core / Service Provider (mengutamakan scale, policy control, traffic steering, dan penghematan biaya MPLS ke Internet), bukan khusus untuk penyelesaian masalah unstable edge connectivity (area terpencil, kapal laut, kendaraan bergerak) seperti fokus utama Peplink.
  2. Keterbatasan MP-TCP di Lapangan: Ketika diuji di lapangan dengan link yang karakteristiknya sangat asimetris dan beda media (seperti Starlink vs Seluler), solusi berbasis MP-TCP sering kali tidak menghasilkan angka agregasi speedtest yang linear.

Kesimpulan

Dugaan Anda sangat tepat. Sebagian besar teknologi "bonding" yang dimaksud pada Huawei adalah Multipath (MP-TCP atau Application Steering).

Bagi skenario lapangan Remote Site yang membutuhkan True Packet-Level Bonding (menggabungkan media heterogen seperti Starlink + 4G/5G secara utuh untuk semua protokol TCP/UDP), Peplink dengan SpeedFusion Tunnel tetap memegang keunggulan arsitektural yang belum tertandingi.

penjelasan / analogi yang sangat bisa saya terima, terimakasih

terutama pada sisi "kelemahan" dan "kelebihan" atau " batasan"

Sama-sama! Senang sekali pembahasan ini bisa memberikan gambaran yang jelas dan berterima.

Memahami batasan (limits), kelebihan (strengths), dan kelemahan (weaknesses) dari kedua arsitektur ini (Peplink SpeedFusion vs Huawei MP-TCP / SD-WAN Steering) adalah kunci utama agar kita tidak terkecoh oleh bahasa marketing vendor.

Untuk melengkapi pemahaman Anda, berikut adalah rangkuman matriks Kelebihan, Kelemahan, dan Batasan Ringkas yang bisa Anda jadikan panduan cepat:

1. Peplink SpeedFusion (True Packet-Level Bonding)

Kelebihan:

  • True All-Traffic Bonding: Menggabungkan pipa untuk SEMUA jenis protokol (TCP, UDP, ICMP, VoIP, Video Streaming, IPSec, dll).
  • Adaptif untuk Unstable Link: Sangat tangguh menghadapi media dengan karakteristik berbeda (Starlink + 4G/5G + VSAT) berkat Dynamic Re-ordering Buffer.
  • Hot Failover & WAN Smoothing: Sesi aplikasi real-time (seperti panggilan suara/CCTV) tidak akan terputus atau freeze sama sekali jika salah satu link mati secara mendadak.

Kelemahan & Batasan:

  • Overhead Tunnel Tinggi: Memakan bandwidth overhead sekitar 15% – 19% untuk enkapsulasi paket.
  • Beban CPU Perangkat: Prosedur membelah, mengenkripsi, dan menyusun kembali paket di level packet membutuhkan daya komputasi (CPU power) yang lumayan tinggi pada router.
  • Terikat Arsitektur Hub-and-Spoke: Perlu perangkat Peplink (atau FusionHub Cloud) di kedua sisi (Remote & Hub) untuk melakukan proses un-bundling paket.

2. Huawei MP-TCP / SD-WAN (Multipath & App Steering)

Kelebihan:

  • Overhead Sangat Rendah: Karena bekerja di Layer 4 / Layer 7, overhead paket sangat kecil sehingga throughput mendekati kecepatan murni ISP.
  • Skalabilitas Enterprise Besar: Sangat efisien untuk manajemen ribuan cabang (traffic steering berbasis aplikasi antar kantor cabang yang menggunakan jaringan terestrial/Fiber Optic).
  • Bebas Beban CPU Ekstrem: Router tidak perlu membedah paket satu per satu secara mikro, sehingga kinerja throughput total router bisa jauh lebih besar.

Kelemahan & Batasan:

  • Tidak Mampu Bonding UDP: Lalu lintas berbasis UDP (seperti Zoom, Teams, VoIP, Live Streaming) TIDAK BISA di-bonding dan hanya bisa dilewatkan ke salah satu jalur (Single Path/Load Balance).
  • Sensitif Terhadap Fluktuasi Latensi: Jika menggabungkan dua media dengan beda latensi ekstrem (misal Starlink 60ms + 4G 20ms), sesi TCP sering kali stuck karena stack TCP OS penerima kebingungan menyusun paket.
  • Bukan True Packet Bonding: Lebih tepat disebut Multipath Multiplexing (membuka banyak jalan untuk satu aplikasi), bukan menggabungkan dua pipa menjadi satu pipa raksasa.

Rangkuman Singkat untuk Analogi Keputusan (Rule of Thumb)

  • Gunakan Peplink SpeedFusion jika: Medan lapangan Anda adalah Remote Site / Mobile (area tambang, kapal, site perkebunan) yang mengandalkan gabungan media unstable (Starlink + 4G/5G) dan membutuhkan keandalan tanpa putus untuk semua jenis aplikasi.
  • Gunakan Huawei SD-WAN jika: Medan lapangan Anda adalah Kantor Cabang Perkotaan (Urban Branch) yang sudah memiliki koneksi kabel terestrial (FO / MPLS / Indihome) dan fokus utamanya adalah membagi-bagi jalur aplikasi (steering) agar hemat biaya operasional.