Menambahkan jalur jaringan kedua memang bisa membuat jaringan lebih tahan terhadap putusnya satu link. Tetapi ada konsekuensinya: dua jalur Ethernet yang saling terhubung dapat membentuk loop. Karena itu, jaringan dengan koneksi redundant membutuhkan mekanisme untuk mengendalikan jalur tersebut. Dua teknologi yang sering ditemui adalah RSTP dan ERPS. Keduanya sama-sama berhubungan dengan redundansi jaringan, tetapi dirancang dengan pendekatan yang berbeda. RSTP menggunakan konsep spanning tree untuk menentukan jalur forwarding dan menjaga agar tidak terjadi loop. ERPS dirancang khusus untuk proteksi pada topologi Ethernet ring. Jadi pertanyaannya bukan “Mana yang lebih cepat, ERPS atau RSTP?” — pertanyaan yang lebih tepat adalah “Dengan topologi dan kebutuhan recovery seperti ini, mekanisme mana yang paling masuk akal?”
Kenapa Redundansi Bisa Menimbulkan Masalah?
Bayangkan ada empat switch yang awalnya terhubung seperti ini:
Sekilas, desain seperti ini terlihat bagus. Kalau satu kabel putus, masih ada jalur lain.
Masalahnya muncul karena Ethernet secara default tidak dirancang untuk membiarkan frame berputar terus-menerus dalam jaringan yang memiliki loop Layer 2. Frame broadcast atau frame tertentu dapat beredar melalui beberapa jalur. Akibatnya bisa terjadi: broadcast storm, MAC address table instability, trafik yang tidak terkendali, dan pada kondisi tertentu, performa jaringan turun drastis.
Karena itu, redundant link membutuhkan mekanisme pengendalian loop. Di sinilah RSTP dan ERPS mulai relevan.
RSTP: Redundansi dengan Konsep Spanning Tree
RSTP (Rapid Spanning Tree Protocol) adalah mekanisme yang menggunakan konsep spanning tree untuk mencegah loop pada jaringan Ethernet. Standarnya dikenal sebagai IEEE 802.1w. RSTP jauh lebih cepat dibanding Legacy STP (802.1D) karena menggunakan mekanisme handshake Proposal-Agreement pada port point-to-point secara langsung, tanpa harus menunggu timer Forward Delay (2 × 15 detik).
Prinsip sederhananya seperti ini:
Ada lebih dari satu jalur antara switch. RSTP akan memilih jalur yang digunakan untuk forwarding dan membuat jalur redundant tidak melakukan forwarding dalam kondisi normal. Jalur tersebut tetap tersedia sebagai jalur alternatif. Jika jalur utama mengalami kegagalan, mekanisme RSTP dapat melakukan reconvergence sehingga jalur alternatif digunakan.
Jadi konsep sederhananya — Normal:
Salah satu jalur redundant tidak forwarding.
Ketika terjadi kegagalan:
Jalur alternatif dapat digunakan.
Yang penting, RSTP tidak sekadar “mematikan port”. Secara teknis ada konsep port role dan port state. Jalur alternatif dapat memiliki role seperti Alternate dan tidak berada dalam kondisi forwarding pada keadaan normal. Untuk kebutuhan desain, pemahaman sederhananya cukup: RSTP menjaga agar hanya jalur yang diperlukan yang melakukan forwarding, sementara jalur redundant tetap tersedia sebagai alternatif.
Pembahasan lebih mendalam tentang mekanisme RSTP tersedia di panduan RSTP untuk jaringan industri.
ERPS: Redundansi yang Memang Dirancang untuk Ring
ERPS (Ethernet Ring Protection Switching) didefinisikan dalam ITU-T G.8032. Berbeda dengan RSTP yang menggunakan konsep spanning tree, ERPS dirancang secara khusus untuk jaringan Ethernet berbentuk ring.
Contohnya:
Dalam kondisi normal, salah satu bagian ring dikendalikan agar tidak membentuk loop forwarding. Bagian tersebut disebut RPL — Ring Protection Link. Port yang memblokir trafik pada kondisi normal berada di bawah kendali RPL Owner Node, sedangkan ujung sebelahnya terhubung ke RPL Neighbor Node. Pemahaman ini penting saat konfigurasi di GUI/CLI switch.
Secara sederhana:
Ketika terjadi kegagalan pada bagian ring yang aktif:
Jalur ring digunakan.
ERPS menggunakan mekanisme komunikasi R-APS (Ring-Automatic Protection Switching) untuk mengoordinasikan perubahan kondisi proteksi tersebut. Jadi bukan sekadar “port langsung dibuka”. Lebih tepat dikatakan: RPL berada dalam kondisi blocked pada keadaan normal. Ketika terjadi failure, mekanisme R-APS mengoordinasikan perubahan protection state sehingga trafik dapat menggunakan jalur ring yang tersedia. Ini penting karena implementasi recovery tetap dipengaruhi oleh desain, perangkat, konfigurasi, firmware, jenis failure, dan kondisi jaringan.
Untuk detail implementasi ERPS G.8032, lihat panduan ERPS G.8032.
ERPS vs RSTP: Apa Bedanya?
Secara sederhana, perbedaan keduanya dapat dilihat seperti ini.
| Aspek | RSTP | ERPS |
|---|---|---|
| Standard | IEEE 802.1w | ITU-T G.8032 |
| Konsep utama | Spanning Tree | Ring Protection |
| Topologi | Fleksibel: tree, star, mesh dengan redundant link | Ethernet ring |
| Loop prevention | Spanning tree | RPL / ring protection mechanism |
| Jalur redundant | Dikelola sebagai bagian dari spanning tree | Bagian dari mekanisme proteksi ring |
| Cocok untuk | Jaringan dengan topologi beragam | Jaringan yang memang dibangun sebagai ring |
| Interoperability | Perlu verifikasi antar-vendor | Perlu verifikasi implementasi G.8032 antar-vendor |
| Recovery | Bergantung topologi dan implementasi | Bergantung ring, node, implementasi dan failure |
| Kompleksitas desain | Relatif familiar | Lebih spesifik untuk ring |
Ada satu hal yang sering salah dipahami: sama-sama mendukung redundancy tidak berarti keduanya bisa dipertukarkan begitu saja. Topologi jaringan tetap menjadi pertimbangan pertama.
Jadi, Kapan Memilih RSTP?
RSTP biasanya lebih masuk akal ketika jaringan tidak dibangun sebagai satu ring utama.
Misalnya:
Atau jaringan dengan kombinasi beberapa switch dan redundant link yang tidak mengikuti struktur ring sederhana.
RSTP juga menarik ketika: topologi relatif fleksibel, jaringan memiliki beberapa jalur redundant, struktur jaringan berubah-ubah, engineer sudah familiar dengan spanning tree, dan kebutuhan recovery dapat dipenuhi oleh mekanisme yang digunakan.
Yang perlu diingat: jangan menentukan kebutuhan recovery hanya berdasarkan nama protokol. Waktu recovery dipengaruhi oleh banyak faktor, termasuk topologi, jumlah perangkat, implementasi hardware, firmware, konfigurasi timer, dan jenis failure. Karena itu, untuk aplikasi yang kritis, angka recovery sebaiknya divalidasi dengan pengujian nyata pada perangkat yang akan digunakan.
Kapan ERPS Lebih Masuk Akal?
ERPS menjadi kandidat yang kuat ketika ring memang merupakan bagian penting dari arsitektur jaringan.
Contohnya:
Model seperti ini umum digunakan ketika jaringan harus membentang melewati beberapa area. Misalnya: backbone fiber antar-panel, jaringan outdoor, area produksi yang memanjang, koneksi antar-building, jaringan utilitas, atau jaringan industri yang memang dirancang berbentuk ring.
Dalam kondisi seperti ini, pendekatan ring protection memang lebih relevan untuk dievaluasi dibanding sekadar menggunakan spanning tree tanpa melihat karakteristik topologinya.
Tetapi sekali lagi: ERPS bukan otomatis lebih baik hanya karena jaringannya industri. Kalau topologinya bukan ring, ERPS belum tentu menjadi pilihan yang tepat.
Cara Memilih: Jangan Mulai dari Fitur, Mulai dari Topologi
Daripada bertanya “Switch ini punya ERPS atau RSTP?”, mulailah dari pertanyaan berikut.
1. Apakah jaringan memiliki redundant path? Kalau tidak, tidak ada masalah loop redundancy yang perlu diselesaikan oleh RSTP atau ERPS pada bagian tersebut. Kalau ya, lanjutkan.
2. Apakah redundant path membentuk ring? Kalau tidak, RSTP bisa menjadi kandidat yang lebih natural. Kalau ya, ERPS layak dievaluasi.
3. Seberapa besar gangguan yang masih dapat diterima aplikasi? Jangan gunakan istilah “zero data loss” secara sembarangan. Redundansi jaringan tidak otomatis berarti zero packet loss. Jika aplikasi OT benar-benar membutuhkan recovery tanpa kehilangan satu paket pun (true zero-recovery time), teknologinya berada di standar IEC 62439-3 (PRP/HSR), bukan ERPS maupun RSTP. Pertanyaan yang lebih berguna adalah: berapa lama aplikasi masih dapat mentoleransi gangguan komunikasi ketika satu link gagal? CCTV, PLC, SCADA, voice, dan aplikasi lainnya bisa memiliki toleransi yang berbeda.
4. Apakah perangkat berasal dari beberapa vendor? Kalau iya, jangan berhenti pada kalimat “Sama-sama support G.8032.” Dukungan terhadap standar yang sama tidak otomatis menjamin interoperabilitas penuh pada semua implementasi. Periksa: versi standar, fitur yang digunakan, mode konfigurasi, terminologi vendor, dan hasil interoperability test jika tersedia.
Contoh: Jaringan 6 Switch Berbentuk Ring
Misalnya ada enam switch yang ditempatkan sepanjang area produksi.
Secara fisik, jaringan memang membentuk ring. Dalam kondisi seperti ini, ERPS G.8032 layak menjadi kandidat utama untuk dievaluasi karena mekanisme proteksinya memang dirancang untuk Ethernet ring.
Sebaliknya, jika desainnya seperti ini:
maka RSTP bisa menjadi pendekatan yang lebih natural karena struktur jaringannya tidak bergantung pada satu ring Ethernet.
Perbedaannya bukan sekadar soal “mana protokol yang lebih hebat”. Arsitektur fisik jaringan sudah memberi petunjuk awal mengenai teknologi yang relevan.
Bagaimana dengan RSTP + ERPS Sekaligus?
Dalam jaringan yang lebih besar, keduanya bisa saja digunakan pada bagian yang berbeda.
Misalnya:
ERPS dapat digunakan pada backbone yang berbentuk ring, sementara RSTP digunakan pada segmen access yang memiliki kebutuhan redundancy berbeda.
Tetapi desain seperti ini membutuhkan boundary yang jelas. Jangan mencampurkan mekanisme loop prevention secara sembarangan sehingga masing-masing protokol tidak lagi memiliki domain yang jelas. Dalam desain multi-protocol, engineer perlu memahami: siapa yang mengendalikan loop, di mana boundary protokol berada, bagaimana failure ditangani, dan bagaimana traffic berpindah ketika terjadi gangguan.
Checklist Sebelum Memilih ERPS atau RSTP
Sebelum memasukkan fitur redundancy ke dalam BOQ, periksa minimal tujuh hal berikut:
- Physical topology — Apakah jaringan tree, star, mesh, atau ring?
- Application impact — Apa dampaknya jika koneksi terputus selama proses recovery?
- Redundant path — Apakah benar-benar diperlukan jalur kedua?
- Node count — Berapa banyak switch yang berada dalam domain redundancy?
- Multi-vendor — Apakah seluruh perangkat berasal dari vendor yang sama?
- Scalability — Apakah desain ini masih masuk akal ketika jumlah switch bertambah?
- Failure testing — Apakah recovery sudah diuji dengan kondisi nyata? Untuk ERPS G.8032, pastikan Hold-off Timer dan Guard Timer dikonfigurasi untuk mencegah flapping saat terjadi gangguan link fisik yang bersifat sementara.
Contoh pengujian: Normal → putuskan link utama → amati traffic → ukur interruption → pulihkan link → amati reconvergence. Untuk jaringan kritis, hasil pengujian jauh lebih berharga daripada sekadar membaca angka pada datasheet.
ERPS atau RSTP? Gunakan Matrix Ini
| Kondisi jaringan | Kandidat awal |
|---|---|
| Jaringan kecil dengan topologi sederhana | RSTP |
| Redundant link tetapi bukan ring | RSTP |
| Topologi tree dengan beberapa redundant path | RSTP |
| Backbone fiber berbentuk ring | ERPS |
| Ring antar-panel/area produksi | ERPS |
| Ring outdoor atau antar-area | ERPS |
| Infrastruktur kritis berbentuk ring | ERPS, lalu validasi recovery |
| Multi-vendor | Keduanya perlu interoperability check |
| Topologi kompleks | Evaluasi berdasarkan domain dan boundary |
Perhatikan kata “kandidat”. Bukan berarti setiap jaringan ring wajib memakai ERPS atau setiap jaringan non-ring wajib memakai RSTP. Desain jaringan tetap harus mempertimbangkan requirement aplikasi, perangkat yang digunakan, dan hasil pengujian.
Kesimpulan
ERPS dan RSTP sama-sama dapat digunakan dalam desain redundansi Ethernet, tetapi keduanya berangkat dari pendekatan yang berbeda. RSTP menggunakan konsep spanning tree dan cocok dievaluasi pada jaringan dengan topologi yang relatif fleksibel. ERPS dirancang khusus untuk proteksi Ethernet ring sehingga menjadi kandidat yang kuat ketika ring merupakan bagian penting dari arsitektur jaringan.
Jadi, jangan memulai desain dari pertanyaan “Switch mana yang punya ERPS?” Mulailah dari “Seperti apa topologi jaringan yang kita bangun, dan berapa lama aplikasi boleh terganggu ketika terjadi failure?” Setelah itu baru tentukan mekanisme redundancy yang sesuai.
Karena pada akhirnya: topologi menentukan teknologi. Bukan sebaliknya.
FAQ
Apakah ERPS lebih cepat daripada RSTP?
Tidak bisa digeneralisasi hanya berdasarkan nama protokol. Recovery dipengaruhi topologi, implementasi perangkat, firmware, konfigurasi, jenis failure, dan faktor lainnya. Secara teoritis, ERPS memberikan kepastian reconvergence di bawah 50 ms karena topologinya terikat pada satu ring, sedangkan reconvergence RSTP bervariasi bergantung pada kedalaman (diameter) dan kompleksitas pohon jaringan. Untuk jaringan kritis, recovery sebaiknya diuji pada perangkat yang akan digunakan.
Apakah ERPS hanya bisa digunakan pada fiber?
Tidak semata-mata karena media fisiknya. ERPS adalah mekanisme proteksi untuk Ethernet ring. Yang menjadi pertimbangan utama adalah arsitektur ring dan dukungan perangkat terhadap G.8032.
Apakah RSTP bisa digunakan pada jaringan industri?
Bisa. RSTP merupakan salah satu mekanisme yang dapat digunakan untuk mengendalikan loop dan menyediakan jalur redundant pada jaringan Ethernet, termasuk lingkungan industri.
Apakah semua switch yang mendukung G.8032 pasti kompatibel?
Tidak otomatis. Implementasi fitur dan konfigurasi antar-vendor perlu diverifikasi. Untuk proyek multi-vendor, interoperability testing sangat disarankan.
Apakah redundancy berarti jaringan tidak akan mengalami packet loss?
Tidak. Redundancy dirancang untuk meningkatkan availability dan menyediakan jalur alternatif ketika terjadi failure. Gangguan komunikasi selama proses recovery tetap mungkin terjadi dan harus divalidasi melalui pengujian.
Referensi
- IEEE 802.1w — Rapid Reconfiguration of Spanning Tree.
- ITU-T G.8032 — Ethernet Ring Protection Switching.
- Dokumentasi vendor mengenai implementasi RSTP dan ERPS.
- Dokumentasi perangkat yang digunakan pada proyek untuk validasi interoperability dan recovery.
CTA
Sedang merancang jaringan industrial Ethernet dengan redundant link? Sebelum menentukan switch, lebih aman memetakan dulu topologi, kebutuhan recovery, jumlah node, media transmisi, dan interoperabilitas perangkat. Kalau Anda punya diagram jaringan atau BOQ, kita bisa membahasnya dari sisi desain dan menentukan apakah RSTP, ERPS, atau kombinasi keduanya lebih masuk akal untuk arsitektur tersebut. Anda juga bisa mulai dari panduan lengkap industrial switch kami.
