Sehari dalam Kehidupan: Tabel BGP Global

 (articles.foletta.org)
2 poin oleh GN⁺ 2024-11-27 | 1 komentar | Bagikan ke WhatsApp
  • Melalui 464.673 BGP UPDATE yang diterima selama satu hari dari peer yang memiliki tabel BGP penuh, diamati perubahan tabel routing global dalam satuan waktu singkat, bukan tren pertumbuhan jangka panjang
  • Tepat setelah peering, seluruh path dan NLRI masuk sekaligus dalam sekitar 5 detik, dan jumlah route yang terhubung ke path awal adalah 949.483
  • Setelah itu, UPDATE masuk dalam kelompok berdasarkan Route Advertisement Interval 30 detik; untuk IPv4 teramati sekitar 50 pembaruan path setiap 30 detik, dan untuk IPv6 sekitar 47
  • Pada IPv4, baik perubahan jumlah path maupun ruang alamat menunjukkan korelasi dengan siklus sekitar 40 menit, tetapi penyebabnya masih menjadi pertanyaan yang belum terjawab
  • AS path prepending yang berlebihan, path attribute 255 yang dicadangkan, serta flapping parah pada NLRI tertentu menunjukkan kompleksitas sekaligus ketahanan operasi BGP global

Pengamatan tabel BGP dalam satu hari

  • Analisis tabel BGP global biasanya berfokus pada tren berskala bulan atau tahun, seperti pertumbuhan tabel routing atau adopsi IPv6
  • Analisis ini melihat perubahan jangka pendek apa yang muncul selama satu hari ketika router menerima langsung update BGP internet yang terus berubah
  • Objek pengamatan dibagi menjadi tiga bagian
    • Alur UPDATE umum selama satu hari
    • path attribute yang tidak biasa
    • flappy path yang sering berubah

Pengumpulan data dan bgpsee

  • Alih-alih mem-parsing output debug router secara langsung, digunakan bgpsee, sebuah daemon BGP yang dulu sempat dibuat tetapi belum selesai, lalu dirapikan hingga bisa berfungsi
  • bgpsee adalah alat peering BGP multithread untuk CLI; setelah melakukan peering dengan router lain, ia mem-parsing pesan BGP dan mengeluarkannya sebagai JSON
    • Yang diproses adalah pesan OPEN, KEEPALIVE, dan UPDATE
    • UPDATE dapat mencakup path attribute seperti NLRI, withdrawn routes, ORIGIN, AS_PATH, NEXT_HOP, dan AS4_PATH
  • Dataset dikumpulkan dari 6 Januari 2024 hingga 7 Januari 2024, dan terdiri dari 464.673 BGP UPDATE yang diterima dari peer dengan tabel BGP penuh

Pengiriman penuh awal dan jumlah route

  • Saat peering BGP pertama kali dinaikkan, semua path di tabel BGP router beserta NLRI terkait dikirim sebagai kelompok UPDATE besar
  • Kelompok awal ini diterima dalam sekitar 5 detik setelah peering dimulai
  • Setelah itu, yang masuk hanya UPDATE untuk path yang berubah atau withdrawn routes yang tidak lagi memiliki path
  • Kelompok awal dan UPDATE setelahnya memiliki struktur yang sama; perbedaannya ada pada waktu penerimaan dan cakupannya
  • Pembedaan penting di sini adalah antara path dan route
    • Path adalah satu unit BGP UPDATE yang memiliki kombinasi path attribute dan NLRI yang terhubung dengannya
    • Satu path dapat terhubung ke satu atau seribu route
    • Jumlah route yang terhubung ke semua path dalam kelompok awal adalah 949.483

Alur UPDATE per 30 detik

  • UPDATE setelah pengiriman penuh awal tidak datang seperti stream real-time, melainkan dikirim berkelompok sesuai timer Route Advertisement Interval
  • Pada peering ini, Route Advertisement Interval adalah 30 detik
  • Rata-rata jumlah UPDATE yang diamati adalah sebagai berikut
    • IPv4: sekitar 50 pembaruan path setiap 30 detik
    • IPv6: sekitar 47 pembaruan path setiap 30 detik
  • Walaupun rata-ratanya mirip, rentang variasi IPv4 lebih besar
    • Simpangan baku IPv4: 64,3
    • Simpangan baku IPv6: 43
  • Alih-alih sekadar jumlah UPDATE, total ruang alamat IP yang berubah setiap 30 detik juga dihitung
    • Semua jumlah alamat IP yang termasuk dalam setiap UPDATE dijumlahkan, lalu log2() diterapkan
    • Contohnya adalah mengonversi /22, /23, dan /24 masing-masing menjadi jumlah alamat, menjumlahkannya, lalu mengambil logaritmanya
  • Berdasarkan ruang alamat IPv4, rata-rata sekitar 2^16 alamat, atau kira-kira /16, berpindah path di tabel routing global setiap 30 detik
  • Pada interval 95%, ruang alamat IPv4 yang berubah berada di kisaran sekitar 2^20.75 hingga 2^13.85
    • Kira-kira setara dengan rentang /11 hingga /18

Siklus 40 menit pada update IPv4

  • Baik dalam perubahan jumlah path maupun perubahan ruang alamat IP, UPDATE IPv4 menunjukkan perilaku siklis
  • Untuk memastikan periodenya, digunakan fungsi autokorelasi (ACF)
    • UPDATE dikelompokkan dalam interval 1 menit, dan 1 lag berarti 1 menit
    • Korelasi antara jumlah path pada titik waktu saat ini dan jumlah path pada tiap lag di masa lalu dihitung
  • Korelasi kuat muncul pada sekitar 7 lag pertama
    • Ini selaras dengan fakta bahwa perubahan path dapat menyebar ke seluruh dunia dan memicu perubahan path lain
  • Korelasi kuat juga muncul pada lag 40 dan 41, sehingga perilaku dengan siklus sekitar 40 menit terkonfirmasi
  • Penyebab siklus 40 menit ini tetap menjadi pertanyaan yang belum terjawab

Kasus AS path prepending berlebihan

  • Administrator jaringan dapat menggunakan berbagai cara untuk mengatur bagaimana trafik masuk ke ASN mereka
    • Menggunakan prefiks jaringan yang lebih panjang tidak memiliki skalabilitas yang baik dan juga tidak disukai dari sudut pandang BGP
    • MED attribute bersifat non-transitive, sehingga memiliki keterbatasan saat melakukan peering dengan banyak AS
    • Umumnya, preferensi path diturunkan melalui AS path prepending, yaitu menambahkan AS sendiri berulang kali di depan untuk peer tertentu
  • Dalam dataset, panjang AS path IPv4 terpanjang adalah 105
    • Ini nilai yang besar, mengingat panjang path terpanjang tanpa prepending adalah 14
    • Path IPv4 ini berasal dari AS149381 “Dinas Komunikasi dan Informatika Kabupaten Tulungagung” di Indonesia
    • NLRI 103.179.250.0/24 tersebut terlihat dengan panjang AS path 105 pada 6 Januari 2024 pukul 06:31:18, lalu diperbarui menjadi panjang 4 sekitar 6,84 jam kemudian, pada 13:21:35
  • Pada IPv6, panjang AS path terpanjang mencapai 599
    • AS path terdiri dari satu atau lebih AS set atau AS sequence
    • Karena panjang maksimum setiap AS sequence adalah 255, path ini membutuhkan tiga AS sequence
  • Pada path IPv6 terpanjang, yang melakukan prepending bukan originator, melainkan ISP Ukraina AS8772 NetAssist LLC
    • Tujuannya adalah path menuju AS203868 di Indonesia, Rifqi Arief Pamungkas
    • Bentuknya adalah AS8772 melakukan prepending agar path tersebut menjadi kurang dipilih
  • Jika melihat jumlah ASN di semua posisi pada 50 path terpanjang teratas, perbedaan besar antara IPv4 dan IPv6 terkait dengan penggunaan berulang ASN tertentu

Nilai cadangan 255 yang terlihat pada path attribute

  • Setiap BGP UPDATE terdiri dari informasi keterjangkauan lapisan jaringan dan path attribute
    • Contohnya AS_PATH, NEXT_HOP, dan sebagainya
  • RFC4271 Section 5 membagi jenis BGP attribute sebagai berikut
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • Jika melihat jumlah attribute di seluruh path IPv4, attribute well-known mandatory seperti ORIGIN, NEXT_HOP, dan AS_PATH ada di semua UPDATE dan muncul dengan jumlah yang sama
  • Attribute umum seperti AGGREGATOR serta attribute yang lebih jarang seperti AS_PATHLIMIT dan ATTR_SET juga diamati
  • Beberapa AS menambahkan attribute 255 pada UPDATE
    • Nilai ini adalah attribute yang reserved for development
    • Saat itu bgpsee tidak menyimpan nilai path attribute yang jarang seperti ini
  • Melalui routeviews.org, dapat dikonfirmasi bahwa beberapa AS masih mengiklankan path dengan menambahkan attribute ini, dan nilai raw byte-nya juga teramati
    • Attribute 255 terlihat pada AS265999, AS10429, dan AS52564
    • Nilai raw byte dari ketiga ISP tersebut memiliki struktur yang mirip satu sama lain
  • Belum terkonfirmasi vendor mana yang menggunakan attribute cadangan untuk pengembangan ini dan untuk apa penggunaannya

NLRI yang paling parah mengalami flapping

  • Dari route yang path-nya berubah atau sepenuhnya ditarik selama satu hari, dihitung NLRI teratas yang paling sering termasuk dalam UPDATE
  • 10 active NLRI teratas dan jumlah kemunculannya dalam UPDATE adalah sebagai berikut
    • 140.99.244.0/23: 2.596
    • 107.154.97.0/24: 2.583
    • 45.172.92.0/22: 2.494
    • 151.236.111.0/24: 2.312
    • 205.164.85.0/24: 2.189
    • 41.209.0.0/18: 2.069
    • 143.255.204.0/22: 2.048
    • 176.124.58.0/24: 1.584
    • 187.1.11.0/24: 1.582
    • 187.1.13.0/24: 1.580
  • 140.99.244.0/23 adalah kasus dengan perubahan paling parah pada hari itu, dan ruang alamat tersebut dimiliki oleh EpicUp
  • Total blok 30 detik berjumlah 2.879, dan route ini muncul dalam 2.637 blok sebagai path lain atau withdrawn route
    • Rasio kemunculan: {p:93}
    • Rasio sebenarnya adalah 92,8%

Keragaman peering yang ditunjukkan oleh path flapping

  • Untuk melihat cara 140.99.244.0/23 mengalami flapping, digunakan graf dengan ASN dari semua path menuju jaringan tersebut sebagai node dan pasangan AS sebagai edge
  • Path utama tampak sebagai jalur pusat yang melewati NTT AS2914 dan Lumen/Level3 AS3356
  • Path berpindah antara ISP tier 1 ini dan ISP lain
    • Contohnya mencakup Arelion AS1299 dan PCCW AS3419
  • Dengan data ini saja, hampir mustahil mengidentifikasi penyebab pasti flapping
    • Kemungkinan penyebab yang disebutkan mencakup link buruk, pemadaman listrik, atau crash router
  • Pada saat yang sama, kasus ini menunjukkan keragaman peering dalam jaringan global modern serta ketahanan protokol routing yang sudah berusia 33 tahun

Dataset yang menyisakan lebih banyak pertanyaan

  • Dataset ini memiliki terlalu banyak topik yang bisa ditelaah, sehingga analisis berfokus pada beberapa kasus saja
  • UPDATE pada tabel BGP global dapat mencerminkan peristiwa dunia nyata seperti ketidakstabilan politik, fenomena alam seperti gempa bumi atau kebakaran, serta kesalahan administrator jaringan
  • Ekonomi peering internet dan unsur manusia dari para operator dengan kemampuan berbeda-beda juga ikut terkandung dalam BGP UPDATE kecil
  • BGP global berfungsi hampir sepanjang waktu, dan mengantarkan banyak perubahan dunia nyata hingga ke laptop sebagai stream update kecil

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-27
Komentar di Hacker News

  • 25 tahun lalu saya bekerja di sebuah ISP kecil, dan awalnya kami hanya punya satu ISP upstream, jadi saya kebagian menangani konfigurasi multihome
    Saya belajar dari tutorial yang ditulis Avi Freedman, dan berkat itu kami bisa mendapatkan /20 dari ARIN lalu mengiklankan rute ke dua peer
    Mempelajari cara kerjanya benar-benar menarik, dan makin banyak tahu, makin menakjubkan bahwa internet entah bagaimana bisa tetap berjalan
    (1) http://avi.freedman.net/
    Avi

    • Terima kasih! Mirip dengan tubuh manusia, makin dipelajari, internet juga jadi terasa menakjubkan bukan karena kadang rusak, melainkan karena bisa bekerja sama sekali
      Terutama untuk hal seperti video/telepon, dan saya senang kontennya membantu
      Di avi.net saya mengumpulkan sebagian tautan ke tutorial masa itu dan tulisan lama di Boardwatch
      Motivasinya murni karena frustrasi terhadap materi yang ada saat itu, tetapi saya juga segera melihat bahwa membantu orang lewat tulisan bagus bisa berbuah imbalan seperti “bisa beli T1?” atau “mau mengoperasikan jaringan global besar kami?”
      Karena itu sampai sekarang saya terus menganjurkan orang untuk menulis tentang topik yang membingungkan dan membuat frustrasi
    • Saya pernah bekerja dengan Avi di Kentik; dia orang yang cerdas dan baik, dan punya kenangan baik tentang menulis artikel-artikel ini untuk membantu orang
    • Sedikit menyimpang, tapi di HN saya kadang melihat komentar yang di akhirnya menyisakan satu kata saja di baris baru seperti ini
      Saya penasaran apakah komentarnya terpotong, atau ada kesalahan saat copy/paste
      Saya juga penasaran apakah orang lain pernah melihatnya, dan apakah itu bisa jadi jejak komentar yang dihasilkan otomatis atau penggunaan alat tertentu
      Saya terutama melihatnya di HN dan sepertinya sekali di Reddit juga; untuk dianggap sekadar kebetulan atau kesalahan, kemunculannya terasa lebih sering dari yang saya kira

  • Artikelnya bagus, tetapi prefix 140.99.244.0/23 milik EpicUp yang flapping seharusnya menjadi sasaran route dampening
    Biasanya ISP menerapkan rate limit per peer atau per prefix untuk semua peer, agar satu prefix tidak menjadi bagian besar dari perubahan BGP global
    Korelasi di antara update yang dilihat penulis sebagai efek berantai kurang meyakinkan
    Mengubah iklan sendiri berdasarkan rute menuju prefix autonomous system lain, terutama rute yang tidak stabil, adalah desain yang cukup kasar
    Saya juga tidak melihat adanya periodisitas 40 menit. Setidaknya saat saya mendalami BGP 8 tahun lalu, hal seperti itu tidak ada; rasanya dataset-nya kebetulan tampak begitu atau disebabkan karakteristik jaringan tempat penulis menerima feed BGP
    Jika melihat AS dan prefix mana yang berubah pada data nyata, semuanya tersebar di sana-sini dan nyaris tidak ada pola besar
    Pada hari mana pun, ada beberapa ISP yang berisik karena masalah sirkuit atau salah konfigurasi; ada prefix yang keluar-masuk saat layanan baru pertama kali dinaikkan; dan ada perubahan rute karena maintenance draining biasa
    Fakta bahwa insiden backhoe memutus kabel fiber di ISP kecil di Kansas bisa terlihat di router di Perth itu memikat sekaligus agak menakutkan, dan pada saat yang sama berkat begitu banyak kebijakan manual, frekuensi update global tetap terjaga di bawah 10Hz

    • Di jaringan masa kini, route dampening sebagian besar sudah tidak populer
      Banyak konfigurasi dulu sangat keliru, dan router sekarang juga tidak lagi setertekan CPU seperti dulu
      Tentu saja bukan berarti hilang sepenuhnya; ketika saya membuat BGP Battleships(https://blog.benjojo.co.uk/post/bgp-battleships), 3356 saat itu menjalankan route dampening sehingga kami harus berhenti bermain sebentar

  • Jika ingin belajar BGP, terutama operasi sehari-hari dalam situasi peering, seri video Network Startup Resource Center dari University of Oregon bagus
    https://learn.nsrc.org/bgp

  • Dari pencarian cepat, atribut BGP reserved 0xff kemungkinan besar adalah perilaku khas Huawei
    Sebagian besar 0xff yang terlihat di bgp.tools mengikuti format yang sama seperti di artikel, dan sebagian jaringan tersebut tampaknya memakai perangkat Huawei

  • Dari artikel ini saya belajar cukup banyak hal tentang BGP yang sebelumnya tidak saya ketahui, dan yang paling menarik adalah bagaimana ia berjalan dengan begitu kacau
    Saya juga ingin membaca tulisan lanjutan yang menggali lebih dalam

  • Dulu saya pernah merancang dan mengonfigurasi jaringan hibrida satelit-microwave untuk pelanggan besar AS yang memiliki kantor lapangan di sekitar Borneo
    Saya tidak bisa melupakan pekerjaan handoff leased line di Jakarta
    Karena sama sekali tidak punya pengalaman seperti ini, saya mencari-cari dan menemukan bahwa BGP digunakan saat menghubungkan jaringan OSPF/UBNT kami dengan WAN korporat IGRP/Cisco milik pelanggan
    Saat kami meminta orang-orang Tata menyiapkan BGP di router, reaksinya kira-kira, “memangnya kalian AT&T?”
    Sampai sebagian besar AirFiber kami tumbang selama satu musim badai petir, kami pun sempat merasa sedikit seperti itu

  • Saya membuat skrip Python untuk mengekstrak data dari file MRT berisi rute BGP di [1], mengimpornya ke Neo4j, lalu menjelajahinya
    File ini berisi sekitar 56 juta rute dengan duplikasi yang sangat banyak, dan Neo4j bagus untuk menangani data seperti ini dengan “menggabungkannya”
    [1] https://data.ris.ripe.net/rrc00/

  • Apa cara termudah bagi orang biasa untuk mengakses data BGP secara langsung? Saya tidak punya kenalan di ISP, tetapi ingin mencoba analisis serupa

  • Jika seiring waktu terlihat perilaku siklis pada update IPv4, baik dari perubahan rute maupun ruang IP, apakah itu berarti internet juga punya semacam pasang surut?

  • Semoga inisiatif Memory Safety, yang menangani keamanan dan keselamatan infrastruktur internet inti dengan mengimplementasikannya ulang di Rust, juga mengambil implementasi server BGP
    [1] https://www.memorysafety.org/