Endpoint Learning dan Traffic Forwarding di Network

Endpoint Learning

Endpoint learning adalah proses dimana suatu network device (misal switch atau router) mengenali dan melakukan mapping terhadap suatu endpoint yang biasanya direpresentasikan sebagai MAC+zero or more IP yang terhubung ke dirinya, sehingga network device tersebut dapat melakukan traffic forwarding sesuai dengan “learned endpoint”. Umumnya informasi endpoint direpresentasikan dalam MAC address table untuk L2 forwarding alias komunikasi dalam satu subnet, Routing table untuk forwarding related routed traffic alias beda subnet, dan ARP table untuk mapping informasi L2 L3. Switch melakukan forwarding traffic (switching) berdasarkan MAC address (switch working on L2), sedangkan router melakukan routing berdasarkan Routing table dan ARP. Lalu ada juga spesies lain yaitu L3 switch, device yang bisa melakukan switching & routing, maka untuk forwarding decisionnya bisa menggunakan ketiga table tersebut (sesuai dengan jenis traffic yang lewat).

Suatu device ketika pertama kali up, MAC address table, routing table, dan ARP table kosong. Table tersebut akan terisi informasi seiring berjalannya waktu. Pada umumnya ARP table dan Routing table akan terbentuk bedasarkan control plane. Contohnya ARP table akan terupdate secara otomatis ketika ada traffic ARP, GARP, ND..etc.. sedangkan routing table terbentuk dari konfigurasi routing, dynamic routing (misal router tersebut running OSPF, BGP atau apa gitu). Sedangkan MAC address table terbentuk dari data plane alias traffic yang saat itu lewat. Misalnya suatu switch ketika pertama kali hidup maka MAC addressya kosong, ketika ada traffic masuk via port 1 dengan MAC AAAA.AAAA.AAAA, sedangkan di MAC table tidak ada info tersebut, maka switch akan memasukan informasi bahwa MAC AAAA.AAAA.AAAA ini learned from port 1.

Contoh MAC address table, berisi informasi ada MAC address apa aja, kedetek dari interface, VLAN mana, dan aging
Contoh ARP table, berisi informasi ada IP apa aja, MAC addressnya apa, learned dari interface mana, dan aging
Contoh routing table, berisi informasi kalau mau ke suatu IP/subnet maka lewat mana (via nexthop suatu IP atau interface)

Btw yang aku jelasin diatas itu versi umum yang terjadi di network. Ada hal-hal yang sifatnya proprietary sehingga hanya ada di perangkat network tertentu, misal fitur data plane endpoint learning di Cisco ACI. Di versi normalnya, data plane learning cuma learn MAC address aja, sedangkan di Cisco ACI data-plane learning juga learn IP address. Efeknya tanpa traffic tipe control plane seperti ARP, GARP..etc sekalipun, ACI mampu mengetahui lokasi suatu IP, contoh casenya ketika ada silent host (endpoint yg ga kirim ARP atau advertisement apa-apa gitu) maka ACI tetep mampu mengenali endpoint tersebut via data plane learning. Selain itu, suatu IP juga bisa saja langsung konek tanpa perlu kirim ARP terlebih dahulu. So far keren kan fitur ini? Cuma sebenernya sesuaikan saja dengan kebutuhan, karena fitur ini bakal ketemu issue juga jika ada deployment cluster atau load balancing dengan metode Direct Return Server (DRS) atau Checkpoint ClusterXL. What’s next? Di ACI akhirnya muncul fitur L4-L7 Virtual IP yang intinya bakal disable data-plane learning untuk spesifik suatu IP alias IP tersebut akan dilearn seperti network pada umumnya (via control plane untuk L3 information), atau disable data plane learning di level BD. Terkait materi ACI nanti kapan-kapan aku bikin tulisan terpisah aja. Berikut contoh case yang perlu “touch” fitur data plane learning di ACI (Referensi: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk168181)

Btw worth to read mengenai maksudnya Control Plane, Data Plane, dan Management Plane: https://networkdirection.net/articles/network-theory/controlanddataplane/

Sederhananya control plane adalah traffic yg menuju atau dari host tersebut, contohnya ada ARP broadcast, OSPF neighborship, BGP neighborship, STP..etc.. traffic ini diproses oleh CPU lalu hasil dari prosesnya menghasilkan informasi yang dapat digunakan oleh data plane melakukan forwarding traffic, misal hasil BGP peering, tergeneratelah routing table dimana routes tersebut dapat diinstall oleh control plane ke data plane. Nah data plane ini adalah traffic yang sifatnya “lewat”, misal dari endpoint A mau ping router X dimana trafficnya melewati router Y, maka traffic dari endpoint A ini lewat data planenya router Y menuju router X. Untuk speed yang kenceng, biasanya data plane ini dalam bentuk hardware/ASIC. Tapi bisa juga dalam bentuk software kalau modelnya virtual (misal virtual switch, virtual router..etc). (Referensi pengunaan ASIC untuk data-plane forwarding: https://www.youtube.com/watch?v=Ti3t9OAZL3g)

Well, sampai titik ini semoga bisa tergambar bagaimana proses data flowing through a device. Device perlu build forwarding information, untuk build forwarding information bisa berdasarkan data-plane maupun control plane. Tambahan sedikit, sebenernya selain dari data-plane/control-plane, kita bisa juga define forwarding rule direct ke forwarding table, misalnya untuk hardware yang support flow programming via openflow, kita bisa define flow if match criteria (misal source IP, mac, port, protocol..etc) then do action (bisa redirect, set next hop, mirror, permit/deny..etc), and this function only available in hardware with flow programming capability 😁.

Traffic Forwarding

Well, sekarang kita coba lihat bagaimana teori yang dijelaskan diatas bekerja dengan contoh case. Kita gunakan topologi berikut:

Terdapat 4 server, server1-3 berada di VLAN 10, sedangkan server4 berada di VLAN 20. Terhubung ke router1 sebagai gatewaynya melalui switch1. Lalu ada PC user yang akan akses server-server tersebut. Berikut topologinya
Topologi untuk contoh case

1. Case 1 – komunikasi 1 subnet -> dari server1 (10.10.10.101/24) ke server2 (10.10.10.102/24)

Case normal dan umum. Asumsi semua table di server, switch dan router masih kosong. Di case ini akan dijelaskan secara detail sebagai referensi untuk case-case setelahnya. Untuk case berikutnya akan dijelaskan secara ringkas saja.

Proses yang akan terjadi di case ini sebagai berikut:

  • server1 (10.10.10.101/24) akan mengirimkan traffic ke server2 (10.10.10.102/24). IP tujuan ternyata satu subnet dengan  source IP sehingga komunikasi hanya perlu di layer 2 alias antar MAC address saja tanpa perlu proses routing.
  • server1 akan melakukan lookup ke ARP table, jika ada record di ARP table untuk IP 10.10.10.102, maka server1 akan langsung mengirimkan traffic ke destination IP 10.10.10.102 beserta destination MAC addressnya. Berhubung ARP table masih kosong maka server1 akan mengirimkan ARP request untuk mencari tahu IP 10.10.10.102 itu MACnya yang mana. ARP request bersifat broadcast (destination MAC ffff.ffff.ffff) sehingga akan dikirimkan ke satu broadcast domain.
Gambar diatas menunjukkan ARP table di server1 yang pada awalnya kosong, maksudnya isinya hanya informasi IP lokal milik server1 itu sendiri saja.

**note: umumnya ketika suatu IP ‘baru saja up’ di suatu endpoint, maka endpoint tersebut akan mengirimkan GARP (Gratuitous ARP) ke broadcast domain yang isinya seperti ini (misal server1 baru saja up) “gaes, perkenalkan aku 0000.0000.aaaa, IPku 10.10.10.101, kalian ada yang lagi pake IP 10.10.10.101 ga? Kalau ada bales yak”. GARP ini fungsinya untuk mencari tau suatu IP apakah sudah ada yang menggunakan di network, jika sudah ada yang menggunakan maka akan mentrigger kondisi duplicate IP. Selain itu GARP juga akan mentrigger ARP table update jika di endpoint lain ada ARP record terkait IP tersebut. Misal di server3 eksisting sudah ada ARP record 10.10.10.101 mapped ke MAC address 0000.0000.abcd, maka akan diupdate recordnya menjadi 10.10.10.101 map ke MAC address 0000.0000.aaaa.

  • Traffic ARP yang dikirim oleh server1 masuk ke switch1 misal melalui port fa0/1 (misal), maka switch akan meregister MAC address tersebut ke MAC address table jika belum ada record MAC untuk MAC server1 ini (0000.0000.aaaa).
Kondisi awal, MAC address table di switch1 masih kosong.
Kondisi setelah traffic ARP dari server1 masuk ke switch1 via port fa0/1, switch menambahkan record MAC address server1 (0000.0000.aaaa) learned via fa0/1
  • traffic ARP memiliki destination MAC address FFFF.FFFF.FFFF, yang berarti switch akan memforward traffic tersebut secara broadcast (layer 2 broadcast domain – dalam hal ini VLAN), sehingga traffic akan dikeluarkan switch di semua interface yang berada dalam broadcast domain yang sama kecuali ingress interface.
  • traffic sampai di semua endpoint yang terhubung ke switch1 dalam broadcast domain yang sama (server2, server3, dan router1). Dalam case ini server4 tidak dikirimkan broadcast ARP oleh switch1 karena berada pada VLAN yang berbeda (VLAN 20). Server3 (10.10.10.103) dan router1 (10.10.10.1) akan drop traffic ARP tersebut karena IP di ARP request tersebut tidak sesuai dengan IP server3 maupun router1. Sedangkan server2 akan membalas ARP request tersebut karena IP pada ARP request cocok dengan IP server2.
  • Server2 membalas ARP request, dan mengupdate/menambahkan informasi IP server1 ke ARP table (ip: 10.10.10.101 mac: 0000.0000.aaaa)
ARP table di server2 sebelum mendapatkan kiriman ARP dari server1

ARP table di server2 setelah mendapatkan & memproses ARP request dari server1, informasi mengenai IP server1 ditambahkan di ARP table sehingga jika kedepannya server2 akan berkomunikasi dengan server1 maka bisa langsung kirim traffic tanpa perlu generate ARP request lagi. Namun record di ARP table memiliki masa aktif (aging timer), jika masa aktif tersebut sudah habis maka record ARP akan dihapus. Contohnya pada router Cisco default ARP aging timer adalah 4 jam, sedangkan pada Microsoft Windows ARP aging timer adalah 10-20 menit. Biasanya aging timer di sisi endpoint lebih cepat daripada aging timer di sisi network device.

  • Balasan ARP request dari server2 sampai di switch1 melalui port fa0/2 (misal), maka switch1 akan mengupdate MAC address tablenya dengan menambahkan informasi MAC server2. ARP request reply ini memiliki destination MAC address specific, yaitu MAC address requesternya (server1 alias 0000.0000.aaaa). Switch1 meneruskan traffic ARP reply tersebut ke destination MAC address (0000.0000.aaa), record tersebut sudah ada di MAC address table, yaitu learned via port fa0/1, maka switch akan meneruskan traffic tersebut via port fa0/1. Nah disini sudah mulai terlihat bahwa MAC address table ini digunakan untuk proses forwarding traffic.

Kondisi MAC address di switch1. Sekarang switch1 sudah learn bahwa ada MAC address 0000.0000.aaaa di port fa0/1 dan 0000.0000.bbbb di port fa0/2. Switch tidak tahu itu perangkat apa, IPnya apa..dll.. yang jadi sudut pandang switch (untuk proses switching) hanya sebatas “ada MAC address apa, learned via port mana”. Ketika proses switching dan switch tidak menemukan informasi mengenai suatu MAC ketika lookup ke MAC address table, maka switch akan membroadcast traffic tersebut ke seluruh port dalam satu broadcast domain. Dahulu kala ketika ukuran MAC address table masih terbatas, hal ini sering dimanfaatkan oleh hacker untuk melakukan MAC flooding attack, yaitu flooding informasi untuk mengisi MAC address table hingga penuh, ketika MAC address table penuh dan MAC address lookup tidak menemukan record MAC untuk suatu traffic, maka traffic tersebut akan dibroadcast ke dalam satu broadcast domain sehingga trafficnya dapat didump oleh hacker. Beruntunglah saat ini kebanyakan switch sudah memiliki ukuran MAC address yang cukup besar. Contohnya untuk switch LAN class, misal Cisco 2960 mampu menampung hingga 16K MAC address, lalu untuk switch Data Center class, misal Arista 7280R3K mampu menampung hingga 384K MAC address.

  • Traffic balasan ARP sampai di server1, isi balasannya adalah informasi bahwa ada IP 10.10.10.102 MAC addressnya 0000.0000.bbbb. lalu server1 melakukan update ARP table menjadi seperti berikut:
Informasi ARP mengenai IP 10.10.10.102 ditambahkan di ARP table.
  • Sampai titik ini server1 sudah bisa mengirimkan traffic ke server2. Untuk komunikasi 2 IP dalam 1 subnet yang sama, yang menjadi acuan utama hanya destination MAC address saja, proses yang terjadi hanya switching saja.

2. Case 2a – komunikasi beda subnet, dari server1 (10.10.10.101/24) ke server4 (20.20.20.101/24)

Komunikasi beda subnet akan melibatkan proses routing. Secara OSI layer maka akan sampai pada proses di Layer 3, sedangkan untuk switching hanya sampai Layer 2 saja. Berikut proses yang terjadi secara umum:

  • server1 (10.10.10.101/24) akan mengirimkan traffic ke server4 (20.20.20.101/24). IP tujuan beda subnet dengan source IP sehingga server1 akan mengirimkan traffic ke gateway sesuai dengan routing table. Di komputer umum biasanya hanya akan ada 1 route saja yaitu default route (dst: 0.0.0.0/0 via bla). Jika di routing table terdapat banyak opsi route, maka akan berlaku aturan longest match prefix rule. Silahkan dapat baca-baca mengenai proses routing table lookup dan longest match prefix rule (referensi: https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/ref/statement/longest-match-next-hop-edit-static-routing-options.html)
  • Gateway berada di satu subnet yang sama, sehingga server1 akan mengirim data ke gateway melalui proses switching seperti pada case nomor 1. Jika informasi IP:MAC address gateway ini belum ada di ARP table server1, maka server1 akan mengirimkan ARP request seperti di case nomor 1. Jika informasi IP:MAC sudah ada, maka server1 bisa langsung kirim trafficnya saja ke gateway.
  • Traffic sampai ke gateway (router1), router akan melihat destination IP (20.20.20.101/24) dan melakukan lookup dari routing table terhadap IP tersebut. Terdapat 2 kondisi yaitu:
    • Jika IP merupakan bagian dari subnet yang terhubung langsung dengan salah satu IP local alias “directly connected”, maka router hanya perlu meneruskan traffic tersebut ke destination IP berdasarkan informasi di ARP table.
    • Jika IP merupakan remote IP alias tidak “directly connected”, maka router akan meneruskan traffic tersebut ke nexthop/gateway sesuai dengan hasil lookup ke routing table. Jika proses lookup dari routing table tidak mendapatkan hasil, maka router akan mengirimkan pesan “destination host unreachable” ke pengirim.
  • Dalam case ini, IP 20.20.20.101/24 ternyata directly connected di VLAN 20, maka router tinggal meneruskan ke server4 saja melalui interface VLAN 20.

3. Case 2b – komunikasi beda subnet, dari user (192.168.1.100/24) ke server1 (10.10.10.101/24)

Yang ini casenya sama dengan case nomor 2a.

4. Case 3 – IP duplicate, server1 dan server2 menggunakan IP sama

Kondisi ini mungkin terjadi, namun seharusnya jarang terjadi karena kalaupun terjadi maka akan menghasilkan kondisi intermittent. Contoh casenya disini misal server1 dan server2 menggunakan IP sama, misalnya menggunakan IP 10.10.10.100/24.

Dalam sudut pandang switch (Layer 2), tidak akan ada masalah, karena switch hanya melihat MAC address saja, sehingga MAC address table di switch tetap mapping MAC address server1 dan server2 seperti berikut:

Problem yang terjadi adalah di ARP table, contohnya ARP table di sisi router atau endpoint lain dalam satu broadcast domain seperti server3. Dalam ARP table, yang menjadi index adalah IP address, sehingga hanya akan ada 1 record untuk 1 IP address dalam 1 waktu, dalam case ini IP 10.10.10.100 akan dimap ke salah satu MAC address antara server1 atau server2?

10.10.10.100 mapped ke MAC address server1 (0000.0000.aaaa)
10.10.10.100 mapped ke MAC address server1 (0000.0000.bbbb)

Kita ambil contoh dari sudut pandang router (contoh 2 gambar di atas), hanya akan ada 1 record ARP untuk IP 10.10.10.100 dimap ke 1 MAC address dalam 1 waktu, misal saat ini IP 10.10.10.100 ternyata termap ke MAC address server1 (0000.0000.aaaa), maka ketika ada traffic dengan destination 10.10.10.100 maka akan diteruskan oleh router ke server1, sehingga server2 tidak akan dikenali dari sudut pandang router. Record di ARP table memiliki aging timer, ketika aging timer di ARP table router1 untuk record IP 10.10.10.100:0000.0000.aaaa habis, maka record akan dihapus dan ketika ada traffic lagi terkait IP 10.10.10.100 maka record akan muncul kembali melalui learning ARP, GARP..etc, dan bisa saja record yang baru ini mengarah ke server2. Sehingga kondisi yang terjadi adalah dalam satu waktu traffic hanya akan diarahkan ke salah satu server, yaitu server yang terakhir mentrigger ARP table update untuk router1.

Kondisi intermittent akan semakin terasa jika ARP table dapat melakukan update secara aggressive, misalnya pada Cisco ACI dengan fitur data-plane endpoint learning, maka mappingan antara IP dan MAC akan terupdate secara terus menerus sehingga traffic untuk IP tersebut tidak stabil dan meningkatkan utilisasi router untuk melakukan update ARP table. Umumnya untuk mengantisipasi hal ini terjadi ada beberapa pendekatan, yaitu:

  • Di sudut padang endpoint, ketika apply konfigurasi IP address, maka endpoint tersebut akan mengirimkan GARP yang fungsinya untuk mengecek apakah di network saat ini IP tersebut sudah ada yang pakai atau belum. Jika ada yang membalas GARP, berarti IP tersebut sudah ada yang pakai, selanjutnya akan mentrigger kondisi/alert duplicate IP.
  • Di sudut pandang network device, misalnya pada router, biasanya terdapat fitur duplicate IP detection, rogue IP detection, ARP inspection rate limit..dan lain-lain.. intinya fitur yang digunakan untuk mengontrol update ARP table, misal melakukan limit update ARP dari suatu interface maksimal 10 update per second, jika melebihi threshold yang diset maka  akan trigger freeze ARP update untuk IP tersebut atau trigger notification bahwa ada IP yang ganti-ganti MAC secara cepat.

Kesimpulannya, 1 IP address multiple MAC yang aktif secara bersamaan (active-active) tidak best practice secara network karena akan menimbulkan issue di ARP table. Jika memang terpaksanya ada kondisi seperti ini, maka perlu action tambahan, misalnya pada scenario Direct Return Server (load balancer mode DRS), endpoint perlu diset supaya tidak mengirimkan traffic yang memicu ARP table update, atau di sisi router diset untuk discard ARP update untuk IP tertentu.

5. Case 4 – endpoint ganti IP, IP server1 ganti dari 10.10.10.101/24 menjadi 10.10.10.100/24

Ini adalah case normal dan umum. Proses yang terjadi mirip dengan ketika set IP baru atau endpoint baru terhubung ke network. Contohnya server1 yang awalnya menggunakan IP 10.10.10.101/24 diganti IPnya menjadi 10.10.10.100/24. Setelah konfigurasi IP diapply, maka server1 akan menggenerate GARP untuk mengencek apakah IP 10.10.10.100 eksisting sudah ada yang pakai sekaligus untuk mentrigger ARP update untuk endpoint lain yang eksisting sudah ada record terkait IP 10.10.10.100. Case ini akan run well dan secara proses tidak ada issue.

6. Case 5 – endpoint ganti MAC, IP server1 dipindahkan ke server2

Mirip dengan case nomor 4, setelah konfigurasi IP diapply, maka akan trigger GARP dan proses berjalan seperti case nomor 4.

7. Case 6 – MAC duplicate, server1 dan server2 memiliki MAC yang sama, beda IP

Kalau ini case yang “sangat jarang” terjadi dan seharusnya “tidak terjadi”, karena pada dasarnya MAC address itu unik dan dari pabrikan tidak akan ada MAC address yang duplicate. Jika memang terjadi hal ini, maka hanya akan akan issue jika kedua MAC address tersebut berada dalam satu broadcast domain yang sama. Issue yang terjadi adalah di MAC address table. MAC address table akan melakukan update secara terus menerus, karena MAC address table terbentuk dari traffic yang lewat alias traffic data-plane. Kondisi yang akan terjadi adalah intermittent. Contohnya di case ini misal server1 dan server2 memiliki MAC address yang sama (misal 0000.0000.1234). Ketika server1 mengirim traffic ke server3, lalu server3 membalas traffic tersebut ke server1, bisa saja trafficnya malah nyasar ke server2 karena tejadi update record MAC address table 0000.0000.1234 yang awalnya learned from Fa0/0 tiba-tiba berubah menjadi learned from Fa0/1.

8. Case 7 – MAC & IP duplicate, server1 dan server2 memiliki MAC & IP yang sama

Case ini mirip dengan case nomor 6, secara ARP table tidak masalah, issue terjadi di MAC address table. Sebenarnya kalau kedua MAC learned dari suatu interface yang sama, misalnya sama-sama learned dari interface Fa0/1 (misal Fa0/1 terhubung ke hub, lalu endpoint yang duplicate terhubung ke Hub), seharusnya tidak bermasalah karena MAC address table tidak akan ada update, jika kedua MAC address yang sama tersebut learned dari lebih dari 1 port, maka akan menjadi issue di MAC address table seperti pada case nomor 6.

Komen dimari gann....