MPLS VPN में IPv6: तीन विकल्प, एक नहीं एड्रेस फ़ैमिली
ग्राहक का VPN रूट, PE-से-PE BGP सत्र और कोर ट्रांसपोर्ट अलग-अलग निर्णय हैं। एक सत्र एक फ़ैमिली में चल सकता है और दूसरी ढो सकता है।
डिज़ाइन समीक्षा में “IPv6 BGP पर IPv6 L3VPN चलाएँ” कहिए, और उस एक वाक्य में तीन अलग निर्णय छिपे हैं। कौन-से प्रीफ़िक्स ग्राहक की VPN के हैं, कौन-से पते प्रोवाइडर किनारों के बीच रूटिंग सत्र ढोते हैं और कौन-सा कोर लेबल वाला पैकेट आगे बढ़ाता है — ये स्वतंत्र चुनाव हैं। ये सभी IPv6 हो सकते हैं, मिश्रित भी हो सकते हैं, और मिश्रण जान-बूझकर मान्य है। इन तीनों को अलग करना ही किसी अस्पष्ट आवश्यकता को ऐसी चीज़ में बदलता है जिस पर प्लेटफ़ॉर्म को परखा जा सके।
तीनों काम अलग कीजिए
पहला काम ग्राहक रूट है: वे IPv6 प्रीफ़िक्स जो एक VPN रूटिंग संदर्भ के हैं और हर दूसरे संदर्भ से बाहर रहने चाहिए। दूसरा प्रोवाइडर किनारे के राउटरों के बीच रूटिंग कनेक्शन है, जो वे प्रीफ़िक्स बदलते हैं। तीसरा वह ट्रांसपोर्ट है जो लेबल वाला ग्राहक पैकेट कोर से होकर दूर के किनारे तक ले जाता है। इनमें से सिर्फ़ एक का नाम लेना अभी डिज़ाइन नहीं है।
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
हर काम की अपनी एड्रेस फ़ैमिली, अपनी विफलता-शैलियाँ और अक्सर अपनी टीम होती है। तालिका इसलिए उपयोगी है क्योंकि डिज़ाइन दस्तावेज़ का एक वाक्य तीनों पंक्तियों को एक में दबा देने की प्रवृत्ति रखता है।
रूट की फ़ैमिली VPN-IPv6 है, IPv6 unicast नहीं
RFC 4659 BGP/MPLS IPv6 VPN फ़ैमिली को परिभाषित करता है, और उसमें सदस्यता IPv6 शब्द के संकेत से अधिक विशिष्ट है। वहाँ रूट एक रूट डिस्टिंग्विशर है जो IPv6 प्रीफ़िक्स से जुड़ा है और AFI 2 तथा SAFI 128 के अंतर्गत एनकोड होता है। साधारण IPv6 unicast दूसरी फ़ैमिली है, इसलिए looking glass में प्रीफ़िक्स जैसा दिखने वाला विज्ञापन शायद वही वस्तु ही न हो। फ़ैमिली को ग़लत पढ़ना इस डिज़ाइन के बिगड़ने का पहला रास्ता है।
फ़र्क़ किनारे पर चुभता है, जहाँ रूट को कुछ भी करने से पहले सही VPN संदर्भ में उतरना होता है। प्रीफ़िक्स मिलना साबित करता है कि अदला-बदली हुई और इंस्टॉलेशन के बारे में कुछ नहीं कहता। वही अंतराल वह क्लासिक रिपोर्ट बनाता है जिसमें सत्र चालू है और ग्राहक अब भी अंधेरे में है।
सत्र VPN से भिन्न फ़ैमिली में चल सकता है
दो किनारों के बीच BGP कनेक्शन को VPN की अपनी फ़ैमिली इस्तेमाल करने के लिए कोई बाध्य नहीं करता। विनिर्देश IPv4 या IPv6 सत्र की अनुमति देता है, और IPv6 VPN ट्रांसपोर्ट स्वयं दोनों कोर प्रकारों पर परिभाषित है। इसलिए IPv6 सत्र उस चीज़ की फ़ैमिली के बारे में कुछ नहीं कहता जो वह ढोता है, और डेटा प्लेन भी नहीं चुनता। तीन स्वतंत्र बिट, और डिज़ाइन को तीनों अलग-अलग रखने चाहिए।
यह मुक्त करता है और साथ ही आसानी से ग़लत पढ़ा जाता है। IPv6 ग्राहक रूट IPv4 पते वाले सत्र पर चल सकते हैं, और IPv4 रूट IPv6 सत्र पर, बशर्ते प्लेटफ़ॉर्म इस संयोजन का समर्थन करे और अगला हॉप हल हो। जो नहीं होना चाहिए वह यह है कि सत्र पेलोड का संकेत दे, डिज़ाइन दस्तावेज़ में या बाद में सेवा साबित करने वाली निगरानी में।
IPv4 कोर पर अगले हॉप का अपना एनकोडिंग है
जब VPN के नीचे का कोर IPv4 है, तो रूट ऐसे अगले हॉप के साथ नहीं दिखता जिसे इनग्रेस किनारा सीधे इस्तेमाल कर सके। वह IPv4-मैप्ड IPv6 रूप में आता है, और नीचे का ट्रांसपोर्ट IPv4 होने पर विनिर्देश ईग्रेस किनारे को इसी तरह व्यक्त करता है। फिर इनग्रेस राउटर को उस मैप्ड पते को ऐसी चीज़ में बदलना होता है जिस तक वह वाकई कोर से होकर पहुँच सके, और समाधान वही कदम है जो चुपचाप विफल होता है।
इसे डिवाइसों के बीच नक़ल करने वाली स्ट्रिंग नहीं, फ़ॉरवर्डिंग की निर्भरता की तरह पढ़िए। जिस प्लेटफ़ॉर्म को आप वाकई चलाते हैं उस पर तीन बातें पक्की कीजिए: घोषित अगला हॉप काम लायक पथ में हल होता है, लेबल स्टैक स्वीकार होता है, और गंतव्य इच्छित VPN संदर्भ में उतरता है। इनमें से कोई एक भी विफल हो तो सत्र स्वस्थ दिखता है और कुछ फ़ॉरवर्ड नहीं करता, इसलिए यह जाँच स्वीकृति परीक्षण में होनी चाहिए, किसी बाद की घटना में नहीं।
आवश्यकता को चार पंक्तियों में लिखिए
परीक्षण के योग्य आवश्यकता चार चीज़ों के नाम लेती है: VPN फ़ैमिली, सत्र ट्रांसपोर्ट, अगले हॉप का एनकोडिंग और कोर की व्यवस्था। फिर एक ग्राहक प्रीफ़िक्स का नाम लेती है जिसे शुरू से अंत तक पीछा करना है: अदला-बदली, इंस्टॉलेशन, लेबल समाधान और वापसी पथ के ज़रिए। “IPv6 BGP का समर्थन करता है” चारों में से किसी को नहीं ढकता और छिपा देता है कि असंगति असल में कहाँ है।
VPN-IPv6 अदला-बदली के बिना स्वस्थ सत्र अधूरा है, और काम करती फ़ॉरवर्डिंग के बिना मिला VPN रूट भी उतना ही अधूरा है। इन्हें अलग स्वीकृति पंक्तियों के रूप में रखना अगली समस्या-निवारण बातचीत को छोटा करता है, क्योंकि विफल पंक्ति पहले ही लिखी जा चुकी है।