एक दिन की दिनचर्या: ग्लोबल BGP टेबल

 (articles.foletta.org)
2 पॉइंट द्वारा GN⁺ 2024-11-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक दिन के दौरान पूरे BGP टेबल वाले peer से मिले 464,673 BGP UPDATE के जरिए, दीर्घकालिक growth trend नहीं बल्कि global routing table के छोटे समय-अंतराल वाले उतार-चढ़ाव देखे गए
  • peering के तुरंत बाद पूरे routes और NLRI लगभग 5 सेकंड के भीतर एक साथ आए, और शुरुआती path से जुड़े routes की संख्या 949,483 थी
  • इसके बाद UPDATE, 30-second Route Advertisement Interval के हिसाब से समूहों में आए; IPv4 में हर 30 सेकंड पर लगभग 50 और IPv6 में लगभग 47 path updates देखे गए
  • IPv4 में path count और address space change, दोनों में लगभग 40-minute cycle का correlation दिखा, लेकिन इसका कारण अनुत्तरित सवाल बना रहा
  • अत्यधिक AS path prepending, reserved path attribute 255, और कुछ NLRI का गंभीर flapping, global BGP operations की जटिलता और resilience दोनों को दिखाते हैं

एक दिन की BGP टेबल ऑब्ज़र्वेशन

  • global BGP table analysis आमतौर पर routing table growth या IPv6 adoption जैसे कई महीनों·कई वर्षों के trends पर केंद्रित होता है
  • यह analysis देखता है कि जब router लगातार बदलते हुए internet BGP updates सीधे प्राप्त करता है, तो एक दिन के दौरान कौन से short-term changes दिखाई देते हैं
  • ऑब्ज़र्वेशन को तीन हिस्सों में बांटा गया
    • एक दिन के दौरान सामान्य UPDATE flow
    • असामान्य path attribute
    • बार-बार बदलने वाले flappy path

डेटा संग्रह और bgpsee

  • router debug output को सीधे parse करने के बजाय, पहले अधूरा छोड़ा गया BGP daemon फिर से काम करने लायक बनाया गया और bgpsee का उपयोग किया गया
  • bgpsee, CLI के लिए एक multithreaded BGP peering tool है, जो दूसरे router के साथ peering करने के बाद BGP messages को parse करके JSON में output देता है
    • यह OPEN, KEEPALIVE और UPDATE messages को process करता है
    • UPDATE में NLRI, withdrawn routes, ORIGIN, AS_PATH, NEXT_HOP, AS4_PATH जैसे path attribute शामिल हो सकते हैं
  • dataset 6 जनवरी 2024 से 7 जनवरी 2024 तक collect किया गया था, और इसमें पूरे BGP table वाले peer से मिले 464,673 BGP UPDATE शामिल हैं

शुरुआती full transfer और path count

  • जब BGP peering पहली बार शुरू होती है, तो router की BGP table में मौजूद सभी paths और उनसे जुड़े NLRI एक बड़े UPDATE bundle के रूप में भेजे जाते हैं
  • यह शुरुआती bundle peering शुरू होने के लगभग 5 सेकंड के भीतर प्राप्त हुआ
  • इसके बाद केवल बदले हुए paths या जिनका path अब नहीं रहा, ऐसे withdrawn routes के UPDATE ही आए
  • यह शुरुआती bundle और बाद के UPDATE संरचनात्मक रूप से एक जैसे हैं; फर्क केवल receive time और scope में है
  • यहाँ महत्वपूर्ण अंतर path और route का है
    • path, path attribute के संयोजन और उससे जुड़े NLRI वाला एक BGP UPDATE unit है
    • एक path से एक या हजार route जुड़े हो सकते हैं
    • पूरे शुरुआती bundle के paths से जुड़े routes की संख्या 949,483 थी

30-सेकंड UPDATE flow

  • शुरुआती full transfer के बाद UPDATE real-time stream की तरह नहीं आए, बल्कि Route Advertisement Interval timer के अनुसार समूहों में भेजे गए
  • इस peering में Route Advertisement Interval 30 सेकंड था
  • observed average UPDATE count इस प्रकार था
    • IPv4: हर 30 सेकंड पर लगभग 50 path updates
    • IPv6: हर 30 सेकंड पर लगभग 47 path updates
  • average समान था, लेकिन variation IPv4 में अधिक था
    • IPv4 standard deviation: 64.3
    • IPv6 standard deviation: 43
  • केवल UPDATE count के बजाय, हर 30 सेकंड में बदले हुए कुल IP address space की मात्रा भी calculate की गई
    • हर UPDATE में शामिल IP address count को जोड़कर उस पर log2() लागू किया गया
    • उदाहरण के लिए /22, /23, /24 को उनके address count में बदलकर जोड़ा गया, फिर उसका log लिया गया
  • IPv4 address space के आधार पर, औसतन हर 30 सेकंड में लगभग 2^16 addresses, यानी लगभग /16, global routing table में path बदलते थे
  • 95% interval में बदला हुआ IPv4 address space लगभग 2^20.75 से 2^13.85 के बीच था
    • यह मोटे तौर पर /11 से /18 के बराबर है

IPv4 updates का 40-मिनट cycle

  • path count में बदलाव और IP address space में बदलाव, दोनों में IPv4 UPDATE ने cyclic behavior दिखाया
  • cycle की पुष्टि के लिए autocorrelation function (ACF) का इस्तेमाल किया गया
    • UPDATE को 1-minute interval में group किया गया, और 1 lag का अर्थ 1 minute था
    • current point के path count और पिछले lag के path count के बीच correlation calculate किया गया
  • शुरुआती लगभग 7 lag में strong correlation दिखाई दिया
    • यह इस बात से मेल खाता है कि path changes दुनिया भर में propagate होकर दूसरे path changes पैदा कर सकते हैं
  • lag 40 और 41 पर भी strong correlation दिखा, जिससे लगभग 40-minute cycle की पुष्टि हुई
  • इस 40-minute cycle का कारण अनुत्तरित प्रश्न बना रहा

AS path prepending की अत्यधिक मिसालें

  • network administrators traffic को अपने ASN में किस तरह प्रवेश करना चाहिए, इसे नियंत्रित करने के लिए कई तरीके इस्तेमाल कर सकते हैं
    • अधिक लंबे network prefix का उपयोग scalable नहीं होता और BGP के नज़रिए से भी वांछनीय नहीं है
    • MED attribute non-transitive है, इसलिए कई AS के साथ peering में इसकी सीमाएँ हैं
    • आम तौर पर, किसी खास peer के लिए अपने AS को कई बार आगे जोड़कर AS path prepending किया जाता है ताकि path preference कम हो जाए
  • dataset में सबसे लंबी IPv4 AS path length 105 थी
    • prepending के बिना सबसे लंबी path length 14 थी, इसे देखते हुए यह बहुत बड़ा मान है
    • यह IPv4 path इंडोनेशिया के AS149381 “Dinas Komunikasi dan Informatika Kabupaten Tulungagung” से originate हुआ था
    • संबंधित NLRI 103.179.250.0/24 6 जनवरी 2024 को 06:31:18 पर AS path length 105 के साथ दिखा, और लगभग 6.84 घंटे बाद 13:21:35 पर length 4 के साथ update हुआ
  • IPv6 में सबसे लंबी AS path length 599 तक पहुँची
    • AS path एक या अधिक AS set या AS sequence से मिलकर बनती है
    • हर AS sequence की अधिकतम length 255 होती है, इसलिए इस path में तीन AS sequence की ज़रूरत पड़ी
  • सबसे लंबी IPv6 path में prepending originator ने नहीं, बल्कि यूक्रेन के ISP AS8772 NetAssist LLC ने किया
    • target इंडोनेशिया के AS203868, Rifqi Arief Pamungkas, की ओर जाने वाला path था
    • AS8772 ने उस path को कम preferred बनाने के लिए prepending किया था
  • शीर्ष 50 सबसे लंबी paths के सभी positions पर मौजूद ASN की संख्या देखने पर, IPv4 और IPv6 के बीच का बड़ा अंतर कुछ विशेष ASN की repeated usage से जुड़ा दिखता है

Path attribute में दिखा reserved value 255

  • हर BGP UPDATE, network layer reachability information और path attribute से बना होता है
    • उदाहरण के लिए AS_PATH, NEXT_HOP आदि
  • RFC4271 Section 5 BGP attribute types को इस तरह बांटता है
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • पूरे IPv4 path set में attribute count देखने पर well-known mandatory attributes ORIGIN, NEXT_HOP, और AS_PATH सभी UPDATE में मौजूद थे और समान संख्या में दिखे
  • AGGREGATOR जैसे सामान्य attributes और AS_PATHLIMIT, ATTR_SET जैसे कम सामान्य attributes भी देखे गए
  • कुछ AS ने UPDATE में attribute 255 जोड़ा
    • यह reserved for development attribute है
    • उस समय bgpsee ऐसे दुर्लभ path attribute के values को store नहीं करता था
  • routeviews.org के जरिए यह पुष्टि की जा सकी कि कुछ AS अब भी इस attribute को जोड़कर route announce कर रहे थे, और raw byte values भी देखे गए
    • AS265999, AS10429, AS52564 में attribute 255 दिखाई दिया
    • इन तीनों ISP के raw byte values की संरचना एक-दूसरे से मिलती-जुलती थी
  • कौन सा vendor development के लिए reserved attribute का उपयोग कर रहा है और किस उद्देश्य से कर रहा है, यह स्पष्ट नहीं हो सका

सबसे ज्यादा flapping करने वाला NLRI

  • दिन भर में जिन routes का path बदला या जिन्हें पूरी तरह withdraw किया गया, उनमें UPDATE में सबसे अधिक बार शामिल top NLRI को गिना गया
  • top 10 active NLRI और उनके UPDATE inclusion counts इस प्रकार थे
    • 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 उस दिन सबसे अधिक उतार-चढ़ाव वाला उदाहरण था, और यह address space EpicUp के स्वामित्व में है
  • पूरे 2,879 30-second blocks थे, और यह route अलग path या withdrawn route के रूप में 2,637 blocks में दिखाई दिया
    • दिखाई देने का अनुपात: {p:93}
    • वास्तविक अनुपात 92.8% था

Flapping path ने दिखाई peering diversity

  • 140.99.244.0/23 के flapping pattern को देखने के लिए, उस network तक जाने वाले सभी path के ASN को node और AS pairs को edge मानकर graph इस्तेमाल किया गया
  • मुख्य paths NTT AS2914 और Lumen/Level3 AS3356 से गुजरने वाले central paths जैसे दिखे
  • path इन tier 1 ISP और दूसरे ISP के बीच move करते रहे
    • उदाहरण के तौर पर Arelion AS1299, PCCW AS3419 शामिल थे
  • केवल इस data से flapping के सटीक कारण की पहचान करना लगभग असंभव है
    • संभावित कारणों में खराब link, power outage, router crash जैसी स्थितियाँ शामिल हैं
  • साथ ही, यह मामला आधुनिक global network की peering diversity और 33 साल पुराने routing protocol की resilience भी दिखाता है

और भी कई सवाल छोड़ता dataset

  • इस dataset में देखने लायक विषय इतने अधिक हैं कि analysis केवल कुछ उदाहरणों पर केंद्रित रहा
  • global BGP table के UPDATE में राजनीतिक अस्थिरता, भूकंप या आग जैसी प्राकृतिक घटनाएँ, और network administrator की गलतियाँ जैसी वास्तविक दुनिया की घटनाएँ भी परिलक्षित हो सकती हैं
  • internet peering की economics और अलग-अलग क्षमताओं वाले operators का मानवीय पहलू भी छोटे BGP UPDATE के भीतर साथ मौजूद रहता है
  • global BGP अधिकांश समय काम करता रहता है और वास्तविक दुनिया के कई बदलावों को छोटे update stream के रूप में laptop तक पहुँचाता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-27
Hacker News की राय

  • 25 साल पहले मैं एक छोटे ISP में काम करता था, और शुरुआत में हमारे पास सिर्फ एक upstream ISP था, इसलिए multihome configuration की जिम्मेदारी मुझे मिली
    Avi Freedman का लिखा tutorial देखकर सीखा, और उसी की बदौलत ARIN से /20 लेकर दो peers को routes advertise कर पाया
    यह सीखना वाकई दिलचस्प था कि यह कैसे काम करता है, और जितना समझा, उतना ही यह बात और हैरान करने लगी कि internet किसी तरह चल भी रहा है
    (1) http://avi.freedman.net/
    Avi

    • धन्यवाद! मानव शरीर की तरह internet को भी जितना पढ़ते हैं, उतना ही यह देखकर हैरानी होती है कि यह कभी-कभी टूटने के बजाय असल में चलता कैसे है
      खासकर video/phone जैसी चीजों में, और खुशी है कि content मददगार रहा
      avi.net पर उस दौर के tutorials और पुराने Boardwatch लेखों के कुछ links इकट्ठा कर रखे हैं
      प्रेरणा पूरी तरह उस समय उपलब्ध material से हुई झुंझलाहट थी, लेकिन यह भी जल्दी दिख गया कि अच्छे लेख लिखकर लोगों की मदद करने पर “क्या आप T1 खरीद सकते हैं?” या “क्या आप हमारा बड़ा global network चला देंगे?” जैसे rewards मिल सकते हैं
      इसलिए मैं आज भी लोगों को उन विषयों पर लिखने के लिए कहता रहता हूं जो confusing और frustrate करने वाले लगते हैं
    • Kentik में Avi के साथ काम किया था; वे बहुत smart और अच्छे इंसान थे, और लोगों की मदद के लिए उन्होंने ये लेख लिखे थे—यह उनकी अच्छी याद के तौर पर मेरे पास है
    • थोड़ी अलग बात है, लेकिन HN पर कभी-कभी comment के अंत में इस तरह सिर्फ एक शब्द नई line में रह जाता है
      सोचता हूं कि comment कट गया था या copy/paste गलत हो गया था
      यह भी जानना चाहता हूं कि क्या दूसरों ने भी ऐसा देखा है, और क्या यह generated comments या किसी खास tool के इस्तेमाल का संकेत हो सकता है
      यह मुझे ज्यादातर HN पर दिखा है और शायद Reddit पर भी एक बार देखा है, लेकिन simple coincidence या गलती मानने के लिए यह उम्मीद से ज्यादा बार दिखता है

  • लेख अच्छा है, लेकिन EpicUp के 140.99.244.0/23 prefix flapping पर route dampening लागू होना चाहिए था
    आमतौर पर ISP सभी peers के लिए per-peer या per-prefix rate limits लगाते हैं, ताकि कोई एक prefix दुनिया भर के BGP changes का बड़ा हिस्सा न बन जाए
    लेखक ने cascade effect के रूप में जिन updates के बीच correlation देखा है, वह बहुत convincing नहीं है
    किसी दूसरे autonomous system prefix तक जाने वाले routes, खासकर unstable routes, के आधार पर अपनी advertisements बदलना काफी crude design है
    मुझे 40-minute periodicity भी नहीं लगती। कम से कम 8 साल पहले जब मैं BGP को गहराई से देखता था, तब ऐसा कुछ नहीं था, और लगता है dataset संयोग से ऐसा दिखा या लेखक को BGP feed देने वाले network की characteristics की वजह से ऐसा लगा
    असली data में देखें कि कौन-से AS और prefixes बदलते हैं, तो वे इधर-उधर बिखरे होते हैं और कोई बड़ा pattern लगभग नहीं दिखता
    किसी भी दिन line issue या configuration mistake की वजह से कुछ noisy ISPs होते हैं, नए service को पहली बार live करते समय prefixes अंदर-बाहर होते रहते हैं, या routine draining maintenance से routes बदलते हैं—ये सब मिला-जुला होता है
    Kansas के किसी छोटे ISP में backhoe द्वारा fiber काट देने की घटना Perth के router पर दिखती है, यह fascinating भी है और थोड़ा डरावना भी; साथ ही, बहुत सारी manual policies की बदौलत global update frequency 10Hz से कम बनी रहती है

    • आजकल के networks में route dampening ज्यादातर fashion से बाहर हो चुका है
      कई configurations बहुत खराब तरह से misconfigure थे, और पुराने समय की तरह ज्यादातर routers CPU के लिए बेहद constrained भी नहीं रहे
      हालांकि यह पूरी तरह खत्म नहीं हुआ है; जब मैंने BGP Battleships(https://blog.benjojo.co.uk/post/bgp-battleships) किया था, तब 3356 उस समय route dampening कर रहा था, इसलिए थोड़ी देर के लिए खेल रोकना पड़ा

  • अगर आप BGP सीखना चाहते हैं, खासकर peering scenarios की रोजमर्रा की operations समझना चाहते हैं, तो University of Oregon की Network Startup Resource Center video series अच्छी है
    https://learn.nsrc.org/bgp

  • जल्दी search करने पर लगता है कि 0xff reserved BGP attribute शायद Huawei-specific behavior है
    bgp.tools पर दिखने वाले ज्यादातर 0xff लेख में दिए format जैसे ही हैं, और उनमें से कुछ networks Huawei equipment इस्तेमाल करते दिखते हैं

  • इस लेख से मैंने BGP के बारे में काफी कुछ सीखा जो पहले नहीं जानता था, और खासकर यह कि यह सब इतना chaotic तरीके से चलता है—यह सबसे दिलचस्प लगा
    इस पर और गहराई में जाने वाला follow-up article भी पढ़ना चाहूंगा

  • पहले मैंने Borneo क्षेत्र में field offices वाले एक बड़े अमेरिकी customer के लिए satellite-microwave hybrid network design और configure किया था
    Jakarta में leased line handoff पर काम करने की घटना अब भी याद है
    इस तरह का कोई अनुभव नहीं था, इसलिए search किया तो पता चला कि हमारे OSPF/UBNT network और customer के IGRP/Cisco enterprise WAN को जोड़ने के लिए BGP इस्तेमाल होता है
    जब Tata वालों से router पर BGP configuration करने को कहा, तो उनका reaction था, “क्या तुम्हें लगता है तुम AT&T हो?”
    बिजली गिरने के एक season में हमारे ज्यादातर AirFiber units खराब होने से पहले तक हमें भी थोड़ा वैसा ही महसूस हो रहा था

  • [1] के BGP routes वाले MRT file से data निकालकर Neo4j में import करके explore करने के लिए मैंने Python script बनाई
    इस file में बेहद ज्यादा duplicates वाले करीब 5.6 करोड़ routes थे, और Neo4j ऐसे data को “merge” करके handle करने के लिए अच्छा है
    [1] https://data.ris.ripe.net/rrc00/

  • किसी आम व्यक्ति के लिए BGP data तक सीधे पहुंचने का सबसे आसान तरीका क्या है? ISP में कोई जान-पहचान नहीं है, लेकिन इसी तरह का analysis करके देखना चाहता हूं

  • अगर समय के साथ routes और IP space changes दोनों में IPv4 updates का कोई cyclical behavior दिखता है, तो क्या इसका मतलब है कि internet में भी tides जैसी कोई चीज है?

  • critical internet infrastructure की security और safety को Rust में reimplement करके संभालने वाली Memory Safety initiative अगर BGP server implementation भी संभाल ले तो अच्छा होगा
    [1] https://www.memorysafety.org/