आपका L2VPN अभी बनाए RSVP-TE LSP को क्यों नज़रअंदाज़ करता है

दो इंजीनियर एक ही रखरखाव विंडो से यह मानकर निकल सकते हैं कि नया पथ सेवा में है, और दोनों अलग-अलग कारणों से गलत हो सकते हैं। एक ने LSP बनाया और मान लिया कि सेवा उसका पीछा करेगी। दूसरे ने सेवा को अकेला छोड़ दिया और मान लिया कि कुछ नहीं बदला। pseudowire केवल उसी परिवहन का उपयोग करता है जिसमें उसके पीयर का पता उस क्षण हल होता है, इसलिए असली सवाल यह है कि वह समाधान अभी क्या पैदा करता है, और दोनों डिज़ाइन इसका अलग-अलग जवाब देते हैं।

एक लेबल सेवा का नाम देता है, दूसरा पैकेट हिलाता है

pseudowire लेबल, जिसे लक्षित LDP द्वारा सिग्नल किया जाता है और RFC 4447 में वर्णित है, प्राप्त करने वाले प्रदाता किनारे को बताता है कि कौन-सा अटैचमेंट सर्किट फ़्रेम प्राप्त करेगा। फ़्रेम वहाँ कैसे पहुँचा, इस पर यह कुछ नहीं कहता। इसके नीचे का लेबल परिवहन का है, और वह स्टैक उसी से बनता है जिसने पीयर लूपबैक के लिए पहुँच की घोषणा की, चाहे LDP हो, RSVP-TE हो या सेगमेंट-रूटेड पथ। चूँकि दोनों परतों को अलग-अलग प्रोटोकॉल सिग्नल करते हैं, एक स्वस्थ हो सकती है जबकि दूसरी पुरानी हो। यही अलगाव पूरी उलझन का स्रोत है।

सीधे कहना उचित है: pseudowire LSP नहीं चुनता। यह फ़्रेम परिवहन को सौंपता है, और परिवहन उसे दिए गए गंतव्य पते से निर्णय लेता है।

यही कारण है कि नए LSP पर एक साफ़ ping इतना कम साबित करता है। LSP चालू, लेबल वाला और दूसरी सेवाएँ ढो रहा हो सकता है, जबकि आपका pseudowire अभी भी किसी दूसरे अगले हॉप से हल हो रहा हो। जब तक आप बाइंडिंग नहीं पढ़ते, ये दोनों तथ्य असंबंधित हैं।

विकल्प A: pseudowire को चुने हुए परिवहन पर पिन करें

पिन करने का अर्थ सेवा के परिवहन समाधान को नियतात्मक बनाना है। प्लेटफ़ॉर्म के अनुसार यह टनल-चयन नीति, सेवा पर स्पष्ट परिवहन एंडपॉइंट, या पीयर पते के लिए अगले हॉप को फिर से लिखने वाली रूट नीति का रूप लेता है। तीनों अंदर से एक ही काम करते हैं: वे एक गंतव्य के समाधान को किसी विशेष LSP पर थोपते हैं। यही परिणाम को बाद में ऑडिट-योग्य बनाता है।

कीमत दायरा है। पीयर पते पर मेल खाने वाली नीति उस पीयर की ओर इशारा करने वाली हर सेवा को प्रभावित करती है, केवल उस pseudowire को नहीं जो आपके मन में था।

फ़ॉलबैक परिवर्तन विंडो से पहले निर्णय मांगता है, उसके दौरान नहीं। यदि पिन किया गया LSP गिर जाए, तो आप या तो सेवा को किसी अन्य स्वीकृत पथ पर चलने देते हैं या उसे रुकने देते हैं। जो नीति चुपचाप ऐसे पथ पर लौट जाती है जो विलंब या असंबद्धता की शर्त तोड़ता है, उसने एक साफ़ व्यवधान को किसी को भी समझाने में कहीं अधिक कठिन चीज़ में बदल दिया है।

विकल्प B: IGP को चुनने दें और देखें क्या होता है

सेवा को अकेला छोड़ना वैध डिज़ाइन है, और अक्सर बेहतर। pseudowire पीयर लूपबैक की ओर किसी भी अन्य ट्रैफ़िक जैसा ही समाधान अपनाता है, इसलिए यह IGP अभिसरण, प्रीफ़िक्स दमन और वह अतिरेक विरासत में पाता है जो कोर पहले से देता है। कम नीतियों का अर्थ है कम जगह जहाँ पुरानी मेल छिप सके। सौदा यह है कि अब आप नियंत्रित नहीं करते कि सेवा कौन-सा पथ लेती है, केवल यह कि कोई पथ मौजूद है।

समान-लागत मल्टीपाथ इस सौदे को पहली नज़र में दिखने से अधिक तीखा करता है। हैशिंग प्रति फ़्लो है, इसलिए एक pseudowire के भीतर दो बातचीत अलग-अलग बाहरी लेबल पर निकल सकती हैं।

किसी पर भी भरोसा करने से पहले स्थापित फ़ॉरवर्डिंग पढ़ें

सेवा से नहीं, पीयर पते से शुरू करें। Junos पर show route 203.0.113.1 detail चुना गया अगला हॉप और लेबल संक्रिया छापता है, और show route table mpls.0 आने वाले लेबल को उस संक्रिया से मैप करता है। IOS XR पर show mpls l2transport vc 100 detail थोपे गए स्टैक के साथ pseudowire की स्थिति देता है।

पुष्टि करें कि परिवहन वास्तव में कौन-सा LSP उपयोग करता है, वह नहीं जो आपका डिज़ाइन दस्तावेज़ नाम देता है। IOS XR पर traceroute mpls ipv4 203.0.113.1/32 लेबल-स्विच्ड पथ पर चलता है और उसके साथ लेबल और आउटगोइंग इंटरफ़ेस सूचीबद्ध करता है, जो पथ को स्वयं देखने के सबसे करीब है। फिर दूर के प्रदाता किनारे से अभ्यास दोहराएँ, क्योंकि वापसी दिशा स्वतंत्र रूप से हल होती है और आंशिक नीति रोलआउट के बाद असममिति सामान्य है। एक दिशा में सही और दूसरी में गलत पथ समान रूप से गलत पथ से बुरा है, क्योंकि आपके आधे परीक्षण पास होंगे।

साक्ष्य सेवा रिकॉर्ड के साथ रखें: पीयर पता, अगला हॉप, बाहरी लेबल और वह तारीख जब आपने जाँचा। रूट नीतियाँ बुरी तरह पुरानी होती हैं, और किसी को याद नहीं रहता कि दो तिमाही पहले कौन-सी लागू थी।

पसंद से नहीं, विफलता के तरीके से चुनें

पिन करना उन सेवाओं के लिए उपयुक्त है जिनमें ऐसी शर्त है जिसे IGP व्यक्त नहीं कर सकता, और उन टीमों के लिए जो हर बदलाव में नीति बनाए रख सकते हैं। IGP पर छोड़ना उन सेवाओं के लिए उपयुक्त है जिन्हें लूप में इंसान के बिना किसी भी एकल विफलता से बचना है।

निर्णायक सवाल यह है कि गलत पथ आपको कितना महँगा पड़ता है। यदि गलत LSP पर सेवा बस थोड़ी खराब चलती है, तो IGP को निर्णय लेने दें और मेहनत निगरानी में लगाएँ। यदि गलत पथ अनुबंध, ऑडिट निष्कर्ष या असंबद्धता की आवश्यकता तोड़ता है, तो उसे पिन करें और फ़ॉलबैक लिखें। फिर फ़ॉलबैक का परीक्षण करें, क्योंकि बिना परीक्षण वाला फ़ॉलबैक एक अनुमान है, योजना नहीं। किसी भी तरह, कोर में किसी भी बदलाव के बाद स्थापित बाइंडिंग फिर से पढ़ें, और ऊपर आए pseudowire को केवल इसका प्रमाण मानें कि सिग्नलिंग काम करती है।