VPN साइटों पर राउटिंग लूप को रूट फ़्लैपिंग से कैसे अलग पहचानें
राउटिंग लूप और फ़्लैपिंग रूट एक ही तरह की रुक-रुक कर होने वाली हानि पैदा करते हैं। गेटवे पर तीन जाँचें कुछ भी बदलने से पहले दोनों में फ़र्क़ करती हैं।
दो साइटें, एक टनल और एक दूरस्थ प्रीफ़िक्स जो कुछ समय जवाब देता है और फिर चुप हो जाता है। पहली प्रतिक्रिया इसे राउटिंग लूप कहना है, और कभी-कभी वह बिल्कुल यही होता है। लेकिन लूप और फ़्लैपिंग रूट एक ही शिकायत पैदा करते हैं, और उन्हें उलटी मरम्मत चाहिए: एक ऐसा फ़ॉरवर्डिंग निर्णय है जो कभी खत्म नहीं होता, दूसरा ऐसा प्रीफ़िक्स है जो बार-बार टेबल छोड़ता है। तीन अवलोकन इन्हें अलग करते हैं, और फ़िल्टर छूने या टनल फिर से शुरू करने से पहले आप तीनों गेटवे की कमांड लाइन से इकट्ठा कर सकते हैं।
लूप हॉप दर हॉप तय होता है। साइट A गंतव्य के लिए B को अगला हॉप चुनती है, B उसी गंतव्य के लिए A को चुनती है, और पैकेट दो चक्करों के बाद TTL पर समाप्त हो जाता है। फ़्लैपिंग को इसके बजाय राउटिंग प्रोटोकॉल तय करता है: प्रीफ़िक्स वापस लिया जाता है, फिर से स्थापित किया जाता है या वैकल्पिक अगले हॉप से बदला जाता है, इसलिए कुछ पैकेट के पास कोई रूट ही नहीं होता जबकि अन्य पूरी तरह अच्छे रूट पर चलते हैं।
वे तीन जाँचें जो सवाल तय करती हैं
पहला फ़ैसला लेने के लिए आपको पैकेट कैप्चर की ज़रूरत नहीं है। आपको दोनों सिरों पर प्रीफ़िक्स की स्थिति, हर पक्ष द्वारा चुना गया अगला हॉप, और ऐसी हॉप गिनती चाहिए जो या तो दोहराई जाए या न हो। अगर ट्रैफ़िक नाकाम होते समय प्रीफ़िक्स उसी अगले हॉप के साथ स्थापित रहता है, तो लूप फ़ॉरवर्डिंग पथ में रहता है। अगर प्रीफ़िक्स गायब होकर लौटता है, तो खराबी फ़ॉरवर्डिंग से ऊपर है और मरम्मत राउटिंग प्रोटोकॉल की है, स्थिर रूट की नहीं।
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
शुरू करने से पहले एक चेतावनी। अगर आप इसे उस टनल से पढ़ रहे हैं जो लूप कर रही है, तो रूट बदलते ही आपका सत्र मर जाएगा। ऐसा कंसोल या प्रबंधन पथ खोलें जो उस प्रीफ़िक्स पर निर्भर न हो जिसे आप ठीक करने जा रहे हैं।
जाँच एक: प्रीफ़िक्स स्थिर है या हिल रहा है
कर्नेल से पूछें कि उसने क्या स्थापित किया, यह नहीं कि कॉन्फ़िगरेशन फ़ाइल क्या वादा करती है। लिनक्स गेटवे पर ip route get 10.20.30.40 वही खोज चलाता है जो फ़ॉरवर्डिंग पथ चलाता है, नीति तालिकाओं सहित, जबकि ip route show 10.20.30.0/24 प्रविष्टि को स्वयं दिखाता है। ip monitor route हर बदलाव को होते ही प्रसारित करता है, जो प्रीफ़िक्स को आते-जाते देखने का सबसे तेज़ तरीका है।
FRR या BIRD चलाने वाले राउटर पर दिलचस्प चीज़ फ़ॉरवर्डिंग टेबल नहीं है। show ip bgp 10.20.30.0/24 चुना गया पथ और उसका अपटाइम लौटाता है; हर कुछ मिनट में रीसेट होता अपटाइम वह फ़्लैपिंग है जिसे आप नाम दे सकते हैं, लूप नहीं। show ip bgp summary पड़ोसी की स्थिति और प्रीफ़िक्स की गिनती दिखाता है, इसलिए बार-बार गिरने वाला साथी फ़ॉरवर्डिंग पथ से दोष हटा देता है।
कुछ भी बदलने से पहले जवाब लिख लें। पिंग नाकाम होते समय दस मिनट स्थिर रहना, और दस मिनट में चार बार गायब होना, अलग-अलग अगले कदमों की ओर ले जाते हैं। दूसरा स्थिर रूट के हर सिद्धांत को अप्रासंगिक बना देता है।
जाँच दो: क्या अगला हॉप आगमन टनल की ओर वापस इशारा करता है
लूप के लिए दो गेटवे का सहमत होना ज़रूरी है। पैकेट पाने वाली साइट पर देखें कि पैकेट बाहर जाने के लिए कौन-सा रूट इस्तेमाल करेगा: असली स्रोत पते के साथ ip route get 10.20.30.40 from 10.10.5.20, क्योंकि कोई नीति नियम मुख्य तालिका से अलग जवाब दे सकता है। फिर जिस साइट ने इसे भेजा उस पर खोज दोहराएँ। अगर हर पक्ष उसी प्रीफ़िक्स के लिए दूसरे को अगला हॉप चुनता है, तो लूप साबित है और कोई कैप्चर कुछ नहीं जोड़ेगा।
कारण लगभग हमेशा ऐसी घोषणा होती है जिसे टनल पार नहीं करनी चाहिए थी। टनल में पुनर्वितरित डिफ़ॉल्ट रूट, दूरस्थ साइट के अपने सबनेट को ढकने वाला एग्रीगेट, या सावधानीवश साथी की ओर इशारा करता स्थिर रूट — सब वही आपसी अगला हॉप बनाते हैं। टनल पूरी तरह स्थापित होकर भी ट्रैफ़िक को गोल घुमा सकती है; strongSwan के फ़ॉरवर्डिंग नोट उस आवश्यकता का राउटिंग पक्ष बताते हैं।
WireGuard अपना अलग नोट हक़ से कहता है, क्योंकि दोष देने के लिए कोई घोषणा नहीं है। wg show हर साथी के AllowedIPs सूचीबद्ध करता है, और कर्नेल किसी साथी के लिए गंतव्य तभी स्वीकार करता है जब वह उस सीमा के भीतर आता है। वहाँ लूप का मतलब है ओवरलैप करती AllowedIPs सीमा या इंटरफ़ेस के पार वापस इशारा करता स्थिर रूट, इसलिए मरम्मत बस उन्हीं दो जगहों पर रहती है।
जाँच तीन: हॉप गिनती पढ़ें, तारे नहीं
traceroute -n -I 10.20.30.40 और mtr -n -r -c 20 10.20.30.40 दोनों पथ दिखाते हैं, और ICMP मोड अक्सर उस फ़िल्टरिंग से बच जाता है जो UDP प्रोब खा जाती है। लूप उन्हीं दो गेटवे पतों के छोटे दोहराए जाने वाले क्रम जैसा दिखता है, जिसमें हर बार TTL ऊपर चढ़ता है। गिरावट आखिरी जवाब देने वाले गेटवे के बाद तारों जैसी दिखती है, और एक अकेला खामोश हॉप किसी बात का सबूत नहीं है।
जब पथ अस्पष्ट हो, तो तार पर TTL पढ़ें। दोनों गेटवे पर tcpdump -ni any -vv icmp हर पैकेट का TTL और हर समय-समाप्ति जवाब का स्रोत पता दिखाता है। अगर कोई पैकेट दूरस्थ साइट पर उस हॉप संख्या से कम TTL के साथ पहुँचता है जो पथ में हो सकती है, तो कुछ हॉप जोड़ रहा है जो traceroute आपको नहीं दिखाता, और ऐसा तब होता है जब एक साइट का फ़ायरवॉल दूसरे की ओर से प्रोब का जवाब देता है।
प्रीफ़िक्स के मालिक को ठीक करें, फिर दोनों दिशाएँ सत्यापित करें
तय करें कि कौन-सी साइट गंतव्य पैदा करती है और कौन-से ट्रांज़िट पथ अनुमत हैं, फिर उसी मालिक पर घोषणा या स्थिर रूट बदलें। प्राप्त करने वाली साइट को सुधारना लुभावना और आम तौर पर ग़लत है: यह एक प्रीफ़िक्स के लिए लूप छिपा देता है और अगले के लिए खराब घोषणा जगह पर छोड़ देता है। रूट टैग, वितरण सूचियाँ और split-horizon नियम इसे स्रोत पर रोकने के लिए हैं, और वे एक ही प्रीफ़िक्स से मेल खाने वाले फ़िल्टर से सस्ते हैं।
बदलाव के बाद आगे और वापसी की दिशा अलग-अलग जाँचें, क्योंकि लूप को ब्लैक होल से बदला जा सकता है बिना लक्षण में कोई दिखने वाला सुधार हुए। दोनों सिरों से ip route get चलाएँ, ऐसे होस्ट से ट्रैफ़िक भेजें जो गेटवे न हो, और ip monitor route को कम से कम एक होल्ड टाइमर तक चलने दें ताकि फ़्लैपिंग को मरम्मत न समझा जाए।
कुछ भी बदलने से पहले इन पाँच बिंदुओं की पुष्टि करें: प्रीफ़िक्स स्थिर है या हिल रहा है, दोनों सिरों पर अगला हॉप एक टनल की ओर इशारा करता है, हॉप गिनती दोहराई जाती है या नहीं, एक ही साइट प्रीफ़िक्स की मालिक है, और आपके पास ऐसा प्रबंधन पथ है जो बदलाव को झेल लेता है। अगर पाँच में से कोई एक अज्ञात है, तो बाकी चार अनुमान हैं।