Belajar MetalLB - Peering & Network Design

#Pendahuluan

BGP mode di episode 6 berhenti pada satu peer sederhana. Di dunia nyata, jarang ada cluster dengan satu router saja. Peering & network design menentukan apakah mode BGP kalian akan stabil dan mudah dirawat — atau menjadi sumber sakit kepala di kemudian hari. Episode 13 membahas desain jaringan secara menyeluruh: banyak peer, routerID, subnet yang di-advertise, penempatan pool, dan firewall.

Desain yang baik membuat penambahan Service hanya menambah IP ke pool — tanpa menyentuh router sama sekali. Desain yang buruk membuat setiap Service baru memerlukan koordinasi dengan tim jaringan. Tujuan episode ini: membangun pola pikir desain yang benar sejak awal.

#Konfigurasi Peer Ganda

#Dua Router, Dua Peer

Cluster produksi biasanya punya lebih dari satu router atau switch L3 untuk redundancy. MetalLB bisa melakukan peering dengan banyak router sekaligus — setiap peer adalah resource BGPPeer terpisah:

apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: core-a
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64512
  peerAddress: 192.168.1.1
---
apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: core-b
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64512
  peerAddress: 192.168.1.2

Dengan dua peer ini, route yang diiklankan MetalLB mencapai jaringan lewat dua jalur. Jika satu router mati, sesi peering ke router itu terputus tetapi route tetap tersedia lewat router lain.

#Verifikasi Semua Peer

Periksa bahwa kedua sesi establish:

kubectl get bgppeer
kubectl describe bgppeer core-a

kubectl get bgppeer menampilkan semua peer dalam satu daftar. Status masing-masing bisa dilihat lewat kubectl describe bgppeer core-a — cari kondisi yang menunjukkan sesi BGP sudah Established.

#routerID: Identitas Node di BGP

#Mengapa routerID Diperlukan

BGP mengidentifikasi sesi dengan router ID. Jika tidak dikonfigurasi, MetalLB memakai alamat IP dari salah satu interface node — yang bisa berubah dan menimbulkan kebingungan. Menetapkan routerID eksplisit membuat identitas setiap node stabil dan bisa diprediksi:

apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: core-b
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64512
  peerAddress: 192.168.1.2
  routerID: 192.168.0.10

routerID: 192.168.0.10 memberi node identitas tetap di mata router. Pastikan routerID bersifat unik di seluruh cluster dan jaringan — routerID yang bentrok bisa menyebabkan sesi BGP tidak stabil.

#Perencanaan Subnet yang Di-Advertise

#Pemilihan Subnet untuk Pool

Salah satu keputusan desain terbesar: subnet mana yang dipakai untuk IP Service, dan apakah IP tersebut di-advertise ke seluruh jaringan atau hanya segmen tertentu. Rekomendasi umum:

• Pilih blok IP khusus yang tidak berkonflik dengan subnet infrastruktur.
• Idealnya blok tersebut belum di-advertise sebagai subnet utuh oleh perangkat lain.
• Dokumentasikan pemetaan antara pool dan fungsinya di konfigurasi.

#Agregasi dan Propagasi

Ingat aggregationLength dari episode 8: dengan agregasi, satu subnet seperti 192.168.20.0/24 diiklankan sebagai satu route, bukan per-IP. Ini mengurangi ukuran tabel routing router dan menyederhanakan kebijakan network team.

kubectl get bgpadvertisement -o wide

kubectl get bgpadvertisement -o wide menampilkan advertisement beserta opsi agregasi. Sebelum mengubah desain, selalu konsultasikan subnet yang di-advertise dengan tim jaringan — route yang bocor bisa memengaruhi seluruh jaringan.

#Penempatan Pool IP dan Subnetting

#Pool Per Segmen Jaringan

Jika cluster menembus beberapa segmen jaringan, buat pool terpisah per segmen. Contoh: segmen 10.0.10.0/24 untuk internal dan 10.0.20.0/24 untuk publik:

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: segmen-internal
  namespace: metallb-system
spec:
  addresses:
    - 10.0.10.200-10.0.10.240
---
apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: segmen-publik
  namespace: metallb-system
spec:
  addresses:
    - 10.0.20.200-10.0.20.240

Dengan pemisahan ini, Service internal dan publik bisa di-announce ke segmen yang berbeda — misalnya lewat nodeSelectors dan interfaces dari episode 8. Struktur ini jauh lebih mudah dirawat daripada satu pool raksasa yang mencakup semuanya.

#Konsistensi dengan Topologi

Penempatan pool harus mencerminkan topologi fisik: IP yang di-announce lewat Layer 2 harus berada dalam subnet yang bisa dijangkau ARP; IP yang di-advertise lewat BGP harus masuk dalam blok yang diizinkan diterima oleh router. Melanggar aturan ini adalah sumber masalah "IP tidak bisa diakses" yang paling umum.

#Komunikasi dengan Firewall

#Port yang Harus Terbuka

BGP menggunakan TCP port 179. Peering BGP membutuhkan komunikasi langsung antara setiap node dan router peer pada port ini. Periksa firewall di antara keduanya:

nc -zv 192.168.1.1 179

nc -zv 192.168.1.1 179 menguji apakah port 179 pada router peer bisa dijangkau dari node. Jika tidak, firewall memblokir peering — salah satu penyebab tersembunyi kenapa sesi BGP tidak pernah establish.

#Kebijakan Firewall yang Disarankan

• Izinkan TCP 179 dari semua IP node menuju IP router peer (dan sebaliknya).
• Batasi akses ke port 7472 (metrics) hanya untuk Prometheus server.
• Gunakan password BGP (MD5) jika router mendukungnya, dan daftarkan alamat IP node yang boleh menjadi peer.

kubectl get bgppeer
kubectl logs -n metallb-system -l component=speaker --tail=30 | grep -i bgp

kubectl logs -n metallb-system -l component=speaker --tail=30 | grep -i bgp menampilkan baris log terkait peering — cara cepat melihat apakah sesi establish atau tertahan di status Connect. Ini langkah diagnosis pertama yang akan kita pakai lagi di episode 19.

#Penutup

Episode 13 menuntaskan peering dan desain jaringan: peer ganda untuk redundancy, routerID yang stabil, perencanaan subnet yang di-advertise, penempatan pool per segmen, dan komunikasi firewall untuk port BGP.

Inti yang harus dibawa pulang:

• Buat satu BGPPeer per router agar jalur redundancy tersedia.
• routerID eksplisit membuat identitas node stabil di mata router.
• Pilih blok IP khusus dan rencanakan agregasi prefix sebelum propagate.
• Pisahkan pool per segmen jaringan agar announcement terkontrol.
• Pastikan TCP 179 terbuka antara semua node dan router peer.
• kubectl get bgppeer dan log speaker adalah cek cepat status peering.

Di episode 14 selanjutnya kita akan membahas security & access control — permission RBAC controller dan speaker, pengerasan namespace, pembatasan akses ke port management dan health check, serta proteksi konfigurasi MetalLB dari perubahan yang tidak sah.