BGP प्रोसेसिंग बग के कारण इंटरनेट रूटिंग में अस्थिरता

 (blog.benjojo.co.uk)
1 पॉइंट द्वारा GN⁺ 2025-05-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • BGP message processing bug के कारण 20 मई 2025 को बड़े पैमाने पर रूटिंग अस्थिरता और कुछ नेटवर्क में इंटरनेट कनेक्टिविटी टूटने की घटना हुई
  • समस्या की जड़ गलत BGP Prefix-SID Attribute थी, जिसने प्रमुख BGP implementations, खासकर JunOS और Arista EOS, में असामान्य प्रतिक्रिया उत्पन्न की
  • Hutchison और Starcloud सहित कुछ transit carriers ने कारण बनने वाले message को relay किया, जिससे असर और फैला
  • इस घटना के कारण लगभग 100 से अधिक नेटवर्क में बड़े पैमाने पर BGP session resets और अस्थिरता देखी गई
  • इस मामले ने vendors के बीच BGP error tolerance handling की कमियों और सुधार की आवश्यकता को उजागर किया

May 27 2025

BGP प्रोसेसिंग बग के कारण वैश्विक इंटरनेट रूटिंग अस्थिरता

20 मई 2025, मंगलवार को सुबह 7 बजे (UTC), एक BGP message के फैलने के बाद इंटरनेट ट्रैफिक संभालने में व्यापक रूप से इस्तेमाल होने वाले दो प्रमुख BGP implementations में अप्रत्याशित व्यवहार देखा गया

इसके कारण कई ‘इंटरनेट कनेक्शन BGP sessions’ अपने-आप समाप्त हो गए, जिससे कम से कम रूटिंग अस्थिरता और सबसे खराब स्थिति में कुछ नेटवर्क में अस्थायी कनेक्टिविटी टूटने की समस्या हुई

समस्या वाला BGP message

  • bgp.tools से एकत्र किए गए sessions के विश्लेषण से पता चला कि इस घटना का कारण बना BGP Update message ऊपर से सामान्य दिखता था, लेकिन उसके अंदर 0x00 से भरा हुआ एक corrupted BGP Prefix-SID Attribute शामिल था
  • अधिकांश BGP implementations (IOS-XR, Nokia SR-OS) ने RFC7606(BGP error tolerance) के अनुसार इसे सही तरह से फ़िल्टर किया, लेकिन JunOS और Arista EOS के बीच interoperation में समस्या हुई
    • JunOS corrupted message को बनाए रखकर आगे भेजता है, और Arista EOS उस message को प्राप्त करते ही BGP session reset कर देता है
  • जिन environments में Juniper hardware (JunOS) का व्यापक उपयोग है और वह Arista EOS से जुड़ा है, वहाँ अधिकतम लगभग 10 मिनट तक इंटरनेट एक्सेस बाधित होने की संभावना थी

समस्या वाले message का प्रेषक

  • उस अवधि के bgp.tools archive के विश्लेषण से कई AS origins जुड़े हुए दिखाई देते हैं

  • इससे संकेत मिलता है कि Prefix बनाने वाले नेटवर्क ने नहीं, बल्कि मार्ग के बीच के transit carrier ने गलत Attribute जोड़ा था

  • घटना से जुड़े प्रमुख AS इस प्रकार हैं

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • bgp.tools डेटा के आधार पर, वास्तव में Attribute जोड़ने वाला पक्ष Starcloud(AS135338) या Hutchison(AS9304) होने की संभावना अधिक है

  • जिन representative Prefixes में यह Attribute फैला, उनमें 156.230.0.0/16, 138.113.116.0/24 आदि शामिल हैं

  • Hutchison/AS9304 कई internet exchanges (IX) से जुड़ा था, और bird का उपयोग करने वाले route servers तक भी यह message पहुँचा

  • Bird, BGP SID को support नहीं करता, इसलिए उसने बिना फ़िल्टर किए इस message को अनेक IX तक भेज दिया, जिससे नेटवर्क-स्तरीय अव्यवस्था और बढ़ गई

BGP Prefix-SID क्या है?

  • BGP Prefix-SID Attribute आम तौर पर केवल internal BGP sessions में उपयोग होना चाहिए, और इसका इस्तेमाल एक ही नेटवर्क के भीतर गंतव्य तक जाने वाला path परिभाषित करने के लिए होता है (RFC8669)
  • यह Attribute global routing table तक कैसे लीक हुआ, इसका एक संभावित कारण यह हो सकता है कि external BGP session को internal session की तरह configure किया गया हो

प्रभावित पक्ष

  • सटीक पीड़ितों की पहचान करना कठिन है, लेकिन शुरुआती BGP message के बाद भारी churn दिखाने वाले लगभग 100 नेटवर्क में समस्या देखी गई
  • सामान्य दिनों में bgp.tools का route collector प्रति सेकंड 20,000 से 30,000 messages इकट्ठा करता है, लेकिन घटना के समय 10 सेकंड के औसत में 150,000 से अधिक दर्ज किए गए
  • यह आँकड़ा इस बात का संकेत है कि व्यापक इंटरनेट paths में गंभीर बाधा आई थी

vendor की ज़िम्मेदारी और संकेत

  • मूल कारण पूरी तरह स्पष्ट नहीं है, लेकिन error message का इंटरनेट स्तर पर फैल जाना इस बात का प्रमाण है कि BGP error handling की मौजूदा समस्याएँ वास्तविक जोखिम हैं
  • अन्य vendors ने समस्या वाले Attribute को फ़िल्टर कर दिया, लेकिन Juniper ने इसे परोक्ष रूप से अनुमति दी और Arista devices तक पहुँचने दिया, जिससे BGP error tolerance code की कमी के कारण session reset हुए
  • JunOS के आधिकारिक दस्तावेज़ भी यह स्पष्ट करते हैं कि “यह पूरे message की जाँच नहीं करता”
  • इस डिज़ाइन के कारण JunOS remote session reset के जोखिम को तो कम करता है, लेकिन अन्य peers या customers तक समस्या वाला message पहुँचाने की संभावना बनी रहती है

निष्कर्ष

  • यह घटना भले ही कम समय की रही हो, लेकिन यह संकेत देती है कि बड़े पैमाने पर होने पर इसका असर कहीं अधिक गंभीर हो सकता है

  • जैसे-जैसे सेवाएँ IP-केंद्रित होती जा रही हैं, इंटरनेट outage का प्रभाव सिर्फ उपभोक्ताओं के email एक्सेस न कर पाने तक सीमित नहीं रहेगा, बल्कि TV broadcast failure, emergency service calls का बाधित होना जैसी समस्याओं तक फैल सकता है

  • इससे वास्तविक रूप से मानव जीवन की हानि तक होने की संभावना है, इसलिए vendors के लिए मजबूत BGP error tolerance implementation की आवश्यकता पर ज़ोर दिया गया है

  • bgp.tools डेटा विश्लेषण में सहयोग करने के इच्छुक network operators की भागीदारी की जानकारी दी गई है (लिंक प्रदान किया गया है)

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

1 टिप्पणियां

 
GN⁺ 2025-05-29
Hacker News राय

  • आम तौर पर "receive करते समय उदार रहो, emit करते समय सटीक रहो" वाला सिद्धांत standard approach माना जाता है

    • टूटे हुए message को drop/filter करने, सिर्फ attribute को ignore करके forward करने, या connection को ही तोड़ देने(Arista की तरह) जैसे विकल्प मौजूद हैं

    • मुझे चौथा विकल्प(Arista वाला तरीका) सच में स्वीकार करना मुश्किल व्यवहार लगता है

    • तीसरा विकल्प(Juniper) भी आदर्श नहीं है, लेकिन उसे घातक समस्या नहीं कहूँगा

    • संपादन: दोबारा पढ़ने पर पता चला कि Arista चौथा नहीं बल्कि दूसरा था(connection terminate)

    • उसने बस connection को invalid मानकर बंद कर दिया, जो user experience के लिहाज़ से बहुत अच्छा फैसला नहीं है, लेकिन स्वीकार्य स्तर का लगता है

    • RFC 7606(Improved Error Handling for BGP UPDATE Messages) पहले से मौजूद है, और इसमें broken message को कैसे handle करना है यह स्पष्ट रूप से लिखा है

      • सबसे आम तरीका 'treat-as-withdraw' है
      • अगर broken message को बस ignore कर दिया जाए, तो पुरानी state बनी रह सकती है जबकि वास्तव में वह अब valid नहीं होती

    • "उदारता से स्वीकार करो और सटीकता से भेजो" वाला सिद्धांत वही है जिसे "robustness principle" या "Postel's law" कहा जाता है

      • यह सिद्धांत 1980~90 के दशक के शुरुआती internet से आया था
      • लेकिन अब industry में व्यापक रूप से माना जाता है कि यह सोच गलत थी
      • इसी सिद्धांत की वजह से protocol ossification और अनगिनत security issues पैदा हुए

    • BGP के behavior का फायदा उठाकर, local device जिन attributes को नहीं जानता उन्हें भी ज्यों का त्यों pass through कर सकता है, और इसी वजह से पूरे network में तरह-तरह की समस्याएँ हुई हैं

      • अब हम ऐसे "feature" के नुकसान सामने आते देख रहे हैं

    • लेखक ने भी अपने लेख में यही बात उठाई है

      • यह "feature" ऐसा बनाता है कि system जिस data को समझता नहीं, उसे भी बिना सोचे-समझे आगे भेज दे, और यह हैरान करने वाली हद तक बुरा विचार लगता है
      • लेकिन इसी feature की वजह से Large Communities जैसी नई capabilities तेज़ी से फैल सकीं, और नए BGP features अपनाना संभव हुआ

    • मैं इस approach से सहमत नहीं हूँ

      • मेरे हिसाब से क्या accept करना है और क्या emit करना है, दोनों में सख्ती और स्पष्टता ज़्यादा बेहतर है

  • CVE-2023-4481 bug को पूरे network में patch करने के लिए पागलों की तरह भागदौड़ करनी पड़ी थी, यह बात अभी भी याद है

    • इस तरह के bugs आगे भी संभालना दुःस्वप्न जैसा रहेगा
    • BGP के design और implementation की प्रकृति देखते हुए, ऐसे behaviors को ठीक करने में काफ़ी लंबा समय लगने की चिंता है

  • मैंने पहले telecom equipment vendor में BGP features विकसित किए थे(काफ़ी पुरानी बात है)

    • आज भी मुझे BGP बहुत complex लगता है

    • लोग लगातार नए features जोड़ते रहते हैं, और vendors standards या drafts के हिसाब से बार-बार implementation करते रहते हैं

    • BGP के शायद कभी retire न होने वाले स्वभाव की वजह से लगता है कि ऐसे bugs बार-बार लौटते रहेंगे

      • पहले AT&T जैसे carriers और Juniper, Cisco जैसे vendors MPLS, VPN से जुड़े features के लिए BGP को ज़बरदस्ती इस्तेमाल करवाते थे, और system गहरी complexity में फँस जाता था
        • यह बहुत ज़्यादा complex था, लेकिन कुछ लोगों ने इससे बहुत पैसा कमाया

  • HGC Global Communications Limited(Hutchison Global Communications Limited से नाम बदला गया, संक्षेप में HGC) हांगकांग का एक internet service provider है

  • लगता है कि अगर कई hardware vendors इन मामलों पर BGP standards को बेहतर तरीके से align करें, तो यह काफ़ी ज़्यादा stable हो सकता है

    • असली समस्या क्या यह है कि हर vendor customer lock-in बनाए रखने के लिए standardization से बचता है, यह जानने की जिज्ञासा है
    • वैसे मेरी BGP समझ बहुत गहरी नहीं है, यह पहले ही बता दूँ

  • शायद सिर्फ मैं ही ऐसा हूँ, लेकिन मैंने BGP का नाम भी तब तक नहीं सुना था जब तक यह न सुना कि उसने कोई समस्या पैदा की है

    • यह TCP/IP की तरह internet के लिए जरूरी protocol है, लेकिन TCP/IP के बारे में school, career, books वगैरह में बहुत पढ़ाया गया, जबकि BGP कभी सामने नहीं आया
    • घर पर TCP/IP के साथ practice और learning की जा सकती है, लेकिन BGP को "घर पर खेलकर" कैसे सीखा जाए, इसका मुझे बिल्कुल अंदाज़ा नहीं

      • अगर घर पर BGP practice करने का कोई तरीका है, तो जानना चाहूँगा

      • BGP implementation वाले असली routers(सस्ते विकल्पों में Mikrotik जैसे उपकरण), या open source implementations खरीदकर यह किया जा सकता है

        • लेख में bird और बेहद लोकप्रिय FRR(Free Range Routing) का ज़िक्र है
        • दो Docker containers चलाकर BGP session बनाइए और static routes वगैरह propagate करके देखिए
        • अगर tutorial चाहिए, तो इस लिंक पर guide अच्छी तरह समझाई गई है और free software के आधार पर follow की जा सकती है

      • DN42 routing technologies सीखने-समझने का playground है

        • लेकिन इसमें समय का निवेश ज़रूरी है, इसलिए इसे casually आज़माना आसान नहीं
        • मैं खुद networking काफ़ी करता हूँ, फिर भी WAN routing अब भी उलझाऊ लगती है
        • GNS3 किसी भी networking technology को hands-on सीखने का सबसे आसान तरीका है
        • DN42 wiki

      • मेरे undergraduate networking course में BGP नहीं पढ़ाया गया था, लेकिन graduate class में BGP पढ़ा था

        • हमने कई AS simulate करने वाला एक Python package इस्तेमाल किया था, लेकिन उसका सही नाम याद नहीं है

      • जिस undergraduate networking class में मैं था, वहाँ BGP का बस बोर्ड पर हल्का-सा ज़िक्र हुआ था

        • BGP lab के लिए, लेखक की तरह network simulator इस्तेमाल किया जा सकता है
        • हमारी class में gini नाम का simulator इस्तेमाल हुआ था, जो professor के graduate student ने बनाया था
        • लेखक का इस्तेमाल किया हुआ gns3, cisco-focused ns3 जैसा लगता है
        • ns3 में सीखने को बहुत कुछ था, इसलिए वह कठिन लगा
        • gini का interface थोड़ा आसान है, लेकिन performance कमज़ोर है
        • gini project जानकारी
        • gns3 official docs

      • ऐसा लगता है कि BGP की सही मायने में "practice" तभी होती है जब आप internet traffic से जुड़े बड़े network को manage करें

        • घर पर छेड़छाड़ करने के लिए network simulator ही एकमात्र व्यावहारिक तरीका है

  • पहले भी कई vendors के पास main post जैसी bugs रही हैं

  • हमारे IOS XR chassis equipment पर भी ऐसा ही packet आया था

    • उसी समय BGP route advertisements भी बहुत ज़्यादा थे

    • ठीक-ठीक नहीं पता कि upstream equipment क्या था

    • इससे यह सवाल उठा कि क्या BGP protocol की सही तरह fuzz testing होती भी है

    • शायद यह इतना critical protocol है कि लोग जानबूझकर outage पैदा करके test करने की हिम्मत नहीं करते

    • BGP fuzzer लिखना आसान हो सकता है, लेकिन crash diagnosis बहुत मुश्किल हो सकती है

      • (पोस्ट लेखक)
        • हाँ, यही तो वह बिंदु है जिसे मैंने अपनी posting में वास्तव में किया था
        • संबंधित पोस्ट

  • यह सोचने पर मजबूर करता है कि internet backbone जितना विशाल और accidental complexity से भरा कोई और system कभी रहा भी है या नहीं

  • ऐसे bugs के प्रभाव को देखते हुए लगा था कि interoperability test suite चलाने वाला कोई consortium ज़रूर होगा, इसलिए यह चौंकाने वाला है

    • या शायद वाकई है, लेकिन यह issue test coverage से छूट गया
    • ऐसा तो obvious लगता है कि सभी संभावित packet errors को auto-generate करके coverage बढ़ाने के लिए fuzzer या machines से तरह-तरह के test cases बनाए जाएँ
    • चाहे run time कई दिन ही क्यों न लगे
    • main post के लेखक ने वास्तव में fuzzer बनाया और इस्तेमाल किया, और कई बार मिलती-जुलती समस्याएँ देखीं
    • यह अजीब लगता है कि vendors ऐसे महत्वपूर्ण research में सक्रिय रुचि नहीं दिखाते