Belajar Network Engineer - SDN & Intent-Based Networking

#Pendahuluan

Setelah di episode 13 kalian mengotomasi perangkat satu per satu via SSH, pertanyaan filosofisnya muncul: mengapa tiap switch harus memikirkan sendiri jalurnya? SDN (Software-Defined Networking) menjawabnya dengan memindahkan "otak" ke satu tempat — dan intent-based networking melangkah lebih jauh: kalian menyatakan tujuan, sistem yang menerjemahkannya.

Episode ini membedah konsepnya sampai ke akar: pemisahan plane, anatomi controller, protokol southbound, platform vendor nyata, ditutup eksperimen SDN yang bisa kalian jalankan di laptop.

#Tiga Plane Jaringan

Setiap perangkat jaringan menjalankan tiga fungsi berbeda — pembeda utama SDN adalah memisahkan mereka:

Arsitektur klasik: ketiga plane hidup di tiap kotak; kebijakan disebar dan diharapkan konsisten. SDN: control plane diangkat ke controller terpusat; perangkat tersisa menjadi forwarding cerdas yang menerima instruksi.

#Anatomi Arsitektur SDN

Tiga komponen yang harus kalian kuasai istilahnya:

1. Controller: otak terpusat (ONOS, OpenDaylight, atau controller proprietary) — membangun pandangan topologi global dan menghitung keputusan forwarding.
2. Southbound API: bahasa controller → perangkat. Pionirnya OpenFlow (controller menulis flow table langsung); industri kini lebih praktis memakai NETCONF/YANG atau gRPC/P4 untuk perangkat modern.
3. Northbound API: bahasa aplikasi → controller. Di sinilah otomasi kalian (episode 12-13) bicara: REST + JSON.

Konsekuensi desain yang sering ditanya interviewer: "bukankah controller itu single point of failure?" Jawaban matangnya: controller cluster/highly-available, dan data plane tetap forward sesuai flow table meski kontrol sementara putus — degradasi terkendali, bukan blackout.

#Dari OpenFlow ke YANG: Evolusi Protokol Southbound

#OpenFlow (2010-an)

Ide radikal Stanford: switch jadi pipeline aturan match-action — "paket dengan dst-port 80 dari VLAN 10 → keluar port 3". Akademis meyakinkan, produksi kurang praktis (skala flow table, interoperabilitas), tetapi ia meletakkan fondasi seluruh industri SDN.

#NETCONF + YANG (standar kerja saat ini)

NETCONF (RFC 6241) memberi manajemen konfigurasi transaksional lewat SSH/XML; YANG adalah bahasa model datanya — skema terstruktur untuk konfigurasi & state. Padanan mentalnya: kalau SNMP itu membaca angka acak, NETCONF/YANG itu query database dengan skema tegas:

module: ietf-interfaces
  +--rw interfaces
     +--rw interface* [name]        # daftar, key = name
        +--rw name         string
        +--rw type         identityref
        +--rw enabled?     boolean   # opsional

Model yang sama dipakai RESTCONF (versi HTTP/JSON) yang sudah kalian cicipi di episode 12 — itulah benang merahnya: satu model data, banyak transport.

#Intent-Based Networking: Satu Level Lebih Tinggi

IBN adalah SDN plus sistem yang menutup lingkaran sendiri. Siklus hidup intent:

1. Translate: admin menyatakan niat bisnis ("VLAN tamu tidak boleh mencapai server HR, dari site mana pun").
2. Activate: sistem merender intent menjadi konfigurasi ribuan perangkat.
3. Assure: telemetri kontinu memverifikasi niat benar-benar terpenuhi.
4. Remediate: penyimpangan dideteksi dan diperbaiki/dilaporkan otomatis.

Bedakan dengan konfigurasi tradisional: dulu kalian menulis how (baris CLI), kini mendeklarasikan what (hasil akhir yang diminta). Ansible idempotent episode 13 adalah langkah kecil menuju pola pikir ini.

#Platform Vendor di Dunia Nyata

Istilah SDN jarang muncul telanjang — ia menyamar dalam produk:

Pola yang sama semua: GUI/controller di atas, API terbuka di tengah, perangkat di bawah. Skill kalian dari episode 12-13 (API, YAML, Python) adalah tiket masuk ke semuanya.

#Praktik: Eksperimen SDN di Laptop

Tanpa hardware mahal pun konsep ini bisa diraba. Dua jalur:

#Jalur 1 — Mininet: Emulasi Topologi OpenFlow

sudo apt install mininet openvswitch-testcontroller
sudo mn --topo tree,depth=2,fanout=2 --controller=ovsc --test pingAll

Kalian baru saja membuat empat switch + empat host virtual dengan controller OpenFlow, dan menguji konektivitasnya — di atas satu laptop. Masuk ke CLI Mininet (sudo mn) lalu jelajahi:

mininet> nodes
mininet> h1 ping -c2 h4
mininet> sh ovs-ofctl dump-flows s1
mininet> exit

dump-flows itulah wajah flow table OpenFlow: keputusan forwarding yang biasanya tersembunyi di ASIC, kini terbaca mentah.

#Jalur 2 — Containerlab: Lab Perangkat Nyata ala DevOps

Untuk merasa "production-like", containerlab menjalankan image FRR/Nokia SR Linux/Arista cEOS sebagai container dengan topologi YAML — persis pola infra-as-code yang kita bangun sejak episode 12.

name: sdn-mini
topology:
  nodes:
    r1: { kind: linux, image: frrouting/frr }
    r2: { kind: linux, image: frrouting/frr }
  links:
    - endpoints: ["r1:eth1", "r2:eth1"]

containerlab deploy -t clab-lab.yml
containerlab destroy -t clab-lab.yml

Lab naik-turun dalam hitungan detik, reproducible, bisa masuk git — mindset NetDevOps penuh.

#Common Pitfalls

• Menagih SDN sebagai satu produk — industri menjual "SDN-ready" untuk apa saja; uji dengan pertanyaan: apakah ada API northbound yang bisa saya program?
• Controller cluster dilupakan — demo single-controller cantik lalu produksi mati saat VM controller restart; HA controller bukan opsi.
• Migrasi big-bang — mengganti jaringan hidup dengan paradigma baru sekaligus; jalankan paralel di segmen non-kritis dulu.
• Belajar hanya GUI controller — klik-klik bisa siapa saja; nilai engineer ada di API, model data, dan integrasinya.

#Penutup

Inti yang harus dibawa pulang:

• SDN memisahkan data/control/management plane; control terpusat di controller, perangkat jadi forwarding engine yang diprogram.
• Southbound berevolusi dari OpenFlow ke NETCONF/YANG/RESTCONF — model data terstruktur adalah standar kerja hari ini.
• IBN = SDN + closed loop: intent dinyatakan, dirender, diverifikasi telemetri, dikoreksi otomatis.
• Platform vendor (Catalyst Center, NSX, Apstra, CloudVision) adalah kemasan komersial konsep yang sama — kuasai konsepnya, bukan logonya.
• Mininet dan containerlab membawa lab SDN ke laptop kalian malam ini.

Di episode 15 kita bawa paradigma ini ke awan: cloud networking — VPC, subnetting cloud, security group vs NACL, load balancer, hybrid connectivity VPN/Direct Connect, dan jebakan multicloud yang menelan banyak tim. Sampai jumpa!