Bir Günün Rutini: Küresel BGP Tablosu

 (articles.foletta.org)
2 puan yazan GN⁺ 2024-11-27 | 1 yorum | WhatsApp'ta paylaş
  • Tam BGP tablosuna sahip bir peer’den bir gün boyunca alınan 464.673 BGP UPDATE üzerinden, küresel yönlendirme tablosunun uzun vadeli büyüme eğilimi değil kısa zaman ölçekli dalgalanmaları gözlemlendi
  • Peering’in hemen ardından tüm path’ler ve NLRI’ler yaklaşık 5 saniye içinde toplu halde geldi; başlangıç path’lerine bağlı route sayısı 949.483 idi
  • Sonraki UPDATE’ler 30 saniyelik Route Advertisement Interval birimleriyle gruplanarak geldi; IPv4 için her 30 saniyede yaklaşık 50, IPv6 için yaklaşık 47 path update’i gözlemlendi
  • IPv4’te hem path sayısı hem de adres alanı değişimlerinde yaklaşık 40 dakikalık periyot korelasyonu görüldü, ancak nedeni yanıtlanmamış bir soru olarak kaldı
  • Aşırı AS path prepending, rezerve path attribute 255 ve belirli NLRI’lerin şiddetli flapping’i, küresel BGP operasyonunun karmaşıklığını ve dayanıklılığını aynı anda gösteriyor

Günlük BGP tablosu gözlemi

  • Küresel BGP tablosu analizleri genellikle yönlendirme tablosunun büyümesi veya IPv6 benimsenmesi gibi aylar/yıllar ölçeğindeki eğilimlere odaklanır
  • Bu analiz, bir router’ın sürekli değişen internet BGP update’lerini doğrudan aldığı durumda, bir gün içinde ne tür kısa vadeli dalgalanmalar ortaya çıktığını inceliyor
  • Gözlem konusu üç kola ayrılıyor
    • Gün içindeki tipik UPDATE akışı
    • Sıra dışı path attribute’lar
    • Sık değişen flappy path’ler

Veri toplama ve bgpsee

  • Router debug çıktısını doğrudan parse etmek yerine, geçmişte yapılmaya başlanıp yarım kalmış bir BGP daemon’u çalışır duruma getirilerek bgpsee kullanıldı
  • bgpsee, CLI için çok iş parçacıklı bir BGP peering aracıdır; başka router’larla peering kurduktan sonra BGP mesajlarını parse edip JSON olarak çıktı verir
    • İşlenen mesajlar OPEN, KEEPALIVE ve UPDATE mesajlarıdır
    • UPDATE; NLRI, withdrawn routes, ORIGIN, AS_PATH, NEXT_HOP, AS4_PATH gibi path attribute’lar içerebilir
  • Veri seti 6 Ocak 2024 ile 7 Ocak 2024 arasında toplandı ve tam BGP tablosuna sahip bir peer’den alınan 464.673 BGP UPDATE’ten oluşuyor

Başlangıçtaki tam aktarım ve path sayısı

  • BGP peering ilk kez ayağa kaldırıldığında, router’ın BGP tablosundaki tüm path’ler ve ilgili NLRI’ler büyük UPDATE kümeleri halinde gönderilir
  • Bu ilk küme, peering başladıktan sonraki yaklaşık 5 saniye içinde alındı
  • Sonrasında yalnızca değişen path’ler veya artık path’i kalmayan withdrawn routes için UPDATE’ler gelir
  • İlk küme ile sonraki UPDATE’ler yapısal olarak aynıdır; fark, alındıkları zaman ve kapsamdadır
  • Burada önemli ayrım path ile route arasındadır
    • Path, path attribute kombinasyonu ve ona bağlı NLRI’leri olan tek bir BGP UPDATE birimidir
    • Tek bir path’e bir route da bin route da bağlanabilir
    • İlk kümedeki tüm path’lere bağlı route sayısı 949.483 idi

30 saniyelik UPDATE akışı

  • İlk tam aktarım sonrasındaki UPDATE’ler gerçek zamanlı bir stream gibi gelmez; Route Advertisement Interval zamanlayıcısına göre gruplanarak gönderilir
  • Bu peering’de Route Advertisement Interval 30 saniye idi
  • Gözlemlenen ortalama UPDATE sayıları şöyleydi
    • IPv4: Her 30 saniyede yaklaşık 50 path update’i
    • IPv6: Her 30 saniyede yaklaşık 47 path update’i
  • Ortalamalar benzerdi ancak dalgalanma genişliği IPv4’te daha büyüktü
    • IPv4 standart sapması: 64,3
    • IPv6 standart sapması: 43
  • Basit UPDATE sayısı yerine, her 30 saniyede değişen toplam IP adres alanı miktarı da hesaplandı
    • Her UPDATE içindeki IP adreslerinin sayısı toplanıp ardından log2() uygulandı
    • Örnek olarak /22, /23, /24 değerlerinin ayrı ayrı adres sayısına dönüştürülüp toplandıktan sonra log alınması yöntemi kullanıldı
  • IPv4 adres alanı bazında, ortalama olarak her 30 saniyede yaklaşık 2^16 adres, yani yaklaşık bir /16, küresel yönlendirme tablosunda path değiştiriyor
  • %95 aralığında değişen IPv4 adres alanı yaklaşık 2^20.75 ile 2^13.85 arasındaydı
    • Kabaca /11 ile /18 arasına karşılık gelir

IPv4 update’lerinde 40 dakikalık periyot

  • Hem path sayısı değişiminde hem de IP adres alanı değişiminde IPv4 UPDATE’leri döngüsel davranış gösterdi
  • Periyodu doğrulamak için otokorelasyon fonksiyonu (ACF) kullanıldı
    • UPDATE’ler 1 dakikalık aralıklarla gruplandı ve 1 lag, 1 dakika anlamına geliyor
    • Geçerli andaki path sayısı ile geçmişteki her lag’e ait path sayısı arasındaki korelasyon hesaplandı
  • İlk yaklaşık 7 lag’de güçlü korelasyon görüldü
    • Bu, path değişimlerinin dünya geneline yayılırken başka path değişimleri oluşturabilmesiyle örtüşüyor
  • Lag 40 ve 41’de de güçlü korelasyon görüldü; yaklaşık 40 dakikalık periyoda sahip bir davranış doğrulandı
  • Bu 40 dakikalık periyodun nedeni yanıtlanmamış bir soru olarak kaldı

Aşırı AS path prepending örnekleri

  • Ağ yöneticileri, trafiğin kendi ASN’lerine giriş şeklini ayarlamak için çeşitli yöntemler kullanabilir
    • Daha uzun network prefix’leri kullanmak iyi ölçeklenmez ve BGP açısından da tercih edilir değildir
    • MED attribute non-transitive olduğu için birden fazla AS ile peering yaparken sınırlamaları vardır
    • Genellikle belirli bir peer için kendi AS’ini birden çok kez başa ekleyen AS path prepending ile path tercih edilirliği düşürülür
  • Veri setindeki en uzun IPv4 AS path uzunluğu 105 idi
    • Prepending olmayan en uzun path uzunluğunun 14 olduğu düşünüldüğünde bu büyük bir değer
    • Bu IPv4 path, Endonezya’daki AS149381 “Dinas Komunikasi dan Informatika Kabupaten Tulungagung” tarafından originate edildi
    • İlgili NLRI 103.179.250.0/24, 6 Ocak 2024 06:31:18’de AS path uzunluğu 105 olarak göründü; yaklaşık 6,84 saat sonra, 13:21:35’te uzunluk 4 olarak update edildi
  • IPv6’da en uzun AS path uzunluğu 599’a ulaştı
    • AS path, bir veya daha fazla AS set ya da AS sequence’ten oluşur
    • Her AS sequence’in maksimum uzunluğu 255 olduğu için bu path’te üç AS sequence gerekiyordu
  • En uzun IPv6 path’te prepending’i originator değil, Ukraynalı ISP AS8772 NetAssist LLC yaptı
    • Hedef, Endonezya’daki AS203868, Rifqi Arief Pamungkas’a giden path’ti
    • AS8772, bu path’i daha az tercih edilir hale getirmek için prepending yapmıştı
  • En uzun ilk 50 path’in tüm konumlarındaki ASN sayılarına bakıldığında, IPv4 ile IPv6 arasındaki büyük farkın belirli ASN’lerin tekrarlı kullanımıyla bağlantılı olduğu görülüyor

Path attribute’larda görülen rezerve değer 255

  • Her BGP UPDATE, ağ katmanı erişilebilirlik bilgisi ve path attribute’lardan oluşur
    • Örnekler AS_PATH, NEXT_HOP vb.’dir
  • RFC4271 Section 5, BGP attribute türlerini şöyle ayırır
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • IPv4 path’lerinin tamamında attribute sayısına bakıldığında, well-known mandatory attribute’lar olan ORIGIN, NEXT_HOP ve AS_PATH tüm UPDATE’lerde bulunur ve aynı sayıda görünür
  • AGGREGATOR gibi yaygın attribute’lar ile AS_PATHLIMIT, ATTR_SET gibi daha az yaygın attribute’lar da gözlemlendi
  • Bazı AS’ler UPDATE’e attribute 255 ekler
  • routeviews.org üzerinden bazı AS’lerin hâlâ path’lerini bu attribute’u ekleyerek duyurduğu doğrulanabildi ve raw byte değerleri de gözlemlendi
    • AS265999, AS10429 ve AS52564’te attribute 255 görünüyor
    • Üç ISP’nin raw byte değerleri birbirine benzer bir yapıya sahip
  • Hangi vendor’ın geliştirme için ayrılmış attribute’u kullandığı ve bunu ne için kullandığı doğrulanamadı

En şiddetli flapping yapan NLRI

  • Gün boyunca path’i değişen veya tamamen withdraw edilen route’lar arasında, UPDATE’lerde en çok yer alan üst NLRI’ler sayıldı
  • En aktif 10 NLRI ve UPDATE’lerde yer alma sayıları şöyle
    • 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 o gün en şiddetli dalgalanan örnekti ve bu adres alanı EpicUp’a ait
  • Toplam 30 saniyelik blok sayısı 2.879 idi ve bu route, farklı bir path veya withdrawn route biçiminde 2.637 blokta göründü
    • Görünme oranı: {p:93}
    • Gerçek oran %92,8 idi

Flapping path’in gösterdiği peering çeşitliliği

  • 140.99.244.0/23’ün flapping biçimini görmek için, bu ağa giden tüm path’lerdeki ASN’lerin node, AS çiftlerinin edge olduğu bir grafik kullanıldı
  • Ana path, NTT AS2914 ve Lumen/Level3 AS3356 üzerinden geçen merkezi path gibi görünüyor
  • Path, bu tier 1 ISP’ler ile diğer ISP’ler arasında hareket ediyor
    • Örnekler arasında Arelion AS1299 ve PCCW AS3419 bulunuyor
  • Yalnızca bu verilerle flapping’in kesin nedenini belirlemek neredeyse imkânsız
    • Olası nedenler olarak kötü bağlantı, elektrik kesintisi, router crash’i gibi durumlar anılıyor
  • Aynı zamanda bu örnek, modern küresel ağların peering çeşitliliğini ve 33 yıllık yönlendirme protokolünün dayanıklılığını gösteriyor

Daha fazla soru bırakan veri seti

  • Bu veri setinde incelenebilecek çok fazla konu olduğundan, analiz bazı örneklere odaklandı
  • Küresel BGP tablosundaki UPDATE’ler; siyasi istikrarsızlık, deprem veya yangın gibi doğal olaylar, ağ yöneticilerinin hataları gibi gerçek dünya olaylarını yansıtabilir
  • İnternet peering’inin ekonomisi ve farklı yetkinliklere sahip operatörlerin insani unsurları da küçük BGP UPDATE’lerinin içinde birlikte yer alır
  • Küresel BGP çoğu zaman çalışır ve gerçek dünyadaki birçok değişimi küçük update stream’leri halinde dizüstü bilgisayara kadar taşır

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-27
Hacker News yorumları

  • 25 yıl önce küçük bir ISP'de çalışıyordum; başta yalnızca tek bir üst ISP'miz olduğu için multihome yapılandırmasını üstlendim
    Avi Freedman'ın yazdığı bir öğreticiden öğrendim; bu sayede ARIN'den bir /20 alıp rotaları iki peer'e duyurabildik
    Nasıl çalıştığını öğrenmek gerçekten ilginçti; öğrendikçe internetin bir şekilde çalışıyor olması gerçeği daha da şaşırtıcı gelmeye başladı
    (1) http://avi.freedman.net/
    Avi

    • Teşekkürler! İnsan vücuduna benzer şekilde, interneti inceledikçe bazen bozulması değil, en başta çalışıyor olması insanı şaşırtıyor
      Özellikle video/telefon gibi şeylerde bu daha da geçerli; içeriğin faydalı olmasına sevindim
      avi.net'te o dönemdeki öğreticilere ve eski Boardwatch yazılarına bazı bağlantıları bir araya koydum
      Motivasyonum tamamen o dönemdeki kaynaklara duyduğum hayal kırıklığıydı; ama iyi yazılarla insanlara yardımcı olunca “T1 satın alabilir misiniz?” ya da “büyük küresel ağımızı işletir misiniz?” gibi ödüllerin geri dönebildiği de kısa sürede görüldü
      Bu yüzden hâlâ kafa karıştırıcı ve sinir bozucu konularda yazı yazmayı önermeye devam ediyorum
    • Kentik'te Avi ile birlikte çalıştım; zeki ve iyi bir insandı, bu yazıları insanlara yardımcı olmak için yazdığını güzel bir anı olarak hatırlıyordu
    • Biraz konu dışı ama HN'de bazen yorumların sonunda böyle tek bir kelimenin yeni satırda kaldığını görüyorum
      Yorumun kesilip kesilmediğini, yoksa kopyala/yapıştırın mı yanlış yapıldığını merak ediyorum
      Başkalarının da bunu görüp görmediğini, üretilmiş yorumların ya da belirli bir aracın kullanımının izi olup olmayacağını da merak ediyorum
      Bunu çoğunlukla HN'de gördüm, Reddit'te de bir kez görmüş olabilirim; ama basit tesadüf ya da hata demek için beklediğimden daha sık oluyor

  • Güzel yazı, ancak EpicUp'ın 140.99.244.0/23 prefix flap'leri route dampening kapsamına girmeliydi
    Genelde ISP'ler, tek bir prefix'in dünya çapındaki BGP değişimlerinin büyük bir bölümünü oluşturmasını önlemek için tüm peer'ler üzerinde peer bazında veya prefix bazında hız sınırı uygular
    Yazarın zincirleme etki olarak gördüğü güncellemeler arasındaki korelasyon çok ikna edici değil
    Başka otonom sistem prefix'lerine giden rotalara, özellikle de kararsız rotalara dayanarak kendi duyurularını değiştirmek epey kaba bir tasarım
    40 dakikalık bir periyodiklik olduğunu da düşünmüyorum. En azından 8 yıl önce BGP ile derinlemesine uğraşırken böyle bir şey yoktu; veri kümesi tesadüfen öyle görünmüş ya da yazarın BGP feed'i aldığı ağın özelliklerinden kaynaklanmış gibi geliyor
    Gerçek verilerde hangi AS'lerin ve prefix'lerin değiştiğine bakınca bunlar sağa sola dağılmış durumda ve büyük bir kalıp neredeyse yok
    Herhangi bir günde hat sorunu ya da yapılandırma hatası nedeniyle gürültü çıkaran birkaç ISP oluyor; yeni bir servisi ilk kez ayağa kaldırırken prefix'lerin girip çıkması ya da olağan draining bakım çalışmaları nedeniyle rotaların değişmesi de buna karışıyor
    Kansas'taki küçük bir ISP'de bir kepçenin fiber kabloyu koparmasının Perth'teki bir router'da görünmesi büyüleyici olduğu kadar biraz ürkütücü de; aynı zamanda sayısız elle yazılmış politika sayesinde dünya çapındaki güncelleme sıklığı 10 Hz'in altında tutuluyor

    • Günümüz ağlarında route dampening büyük ölçüde modası geçmiş durumda
      Birçok yapılandırma ciddi biçimde yanlış ayarlanmıştı ve eskisi gibi çoğu router'ın CPU açısından aşırı kısıtlı olduğu bir dönem de değil
      Tabii tamamen ortadan kalkmış değil; BGP Battleships'i (https://blog.benjojo.co.uk/post/bgp-battleships) yaptığımda 3356 o sırada route dampening uyguladığı için oyunu bir süre durdurmam gerekmişti

  • BGP öğrenmek istiyorsanız, özellikle peering durumlarının günlük operasyonlarını anlamak istiyorsanız University of Oregon'ın Network Startup Resource Center video serisi iyi
    https://learn.nsrc.org/bgp

  • Hızlıca baktığım kadarıyla 0xff ayrılmış BGP attribute'u büyük olasılıkla Huawei'ye özgü bir davranış
    bgp.tools'ta görünen 0xff'lerin çoğu yazıdakine benzer bir biçimi izliyor ve bunlardan bazı ağların Huawei ekipman kullandığı görülüyor

  • Bu yazıdan BGP hakkında bilmediğim epey şey öğrendim; özellikle de böyle kaotik biçimde işliyor olması en ilginç kısımdı
    Daha derine inen devam yazılarını da okumak isterim

  • Eskiden Borneo civarında saha ofisleri olan büyük bir ABD müşterisi için uydu-mikrodalga hibrit ağı tasarlayıp yapılandırmıştım
    Jakarta'da kiralık hat devriyle uğraştığım işi unutamıyorum
    Bu konuda hiç deneyimim olmadığı için arayınca, bizim OSPF/UBNT ağımızı müşterinin IGRP/Cisco kurumsal WAN'ına bağlarken BGP kullanıldığını öğrendim
    Tata tarafındaki kişilerden router'a BGP yapılandırması yapmalarını isteyince “Kendinizi AT&T mi sanıyorsunuz?” diye tepki verdiler
    Yıldırımlı bir sezon boyunca AirFiber'ların çoğu bozulana kadar biz de biraz öyle hissediyorduk

  • [1]'deki BGP rotalarını içeren MRT dosyasından veri çıkarıp Neo4j'ye aktarmak ve keşfetmek için bir Python betiği yazdım
    Bu dosyada aşırı derecede tekrar eden yaklaşık 56 milyon rota vardı; Neo4j bu tür verileri “merge” ederek işlemek için iyi
    [1] https://data.ris.ripe.net/rrc00/

  • Sıradan birinin BGP verilerine doğrudan erişmesinin en kolay yolu nedir? Bir ISP'de tanıdığım yok ama benzer bir analiz denemek istiyorum

  • Zaman içinde hem rota hem de IP alanı değişimlerinde IPv4 güncellemelerinde bir tür döngüsel davranış görülüyorsa, bu internette de gelgit gibi bir şey olduğu anlamına mı gelir?

  • Temel internet altyapısının güvenliğini ve emniyetini Rust ile yeniden gerçekleştirerek ele alan Memory Safety girişimi keşke BGP sunucusu implementasyonunu da üstlense
    [1] https://www.memorysafety.org/