MPLS VPN मा IPv6: एउटा होइन, तीनवटा विकल्प
ग्राहकको VPN रुट, PE-बीचको BGP सत्र र कोर यातायात छुट्टाछुट्टै निर्णय हुन्। एउटा सत्र एक फ्यामिलीमा चल्न सक्छ र अर्को बोक्न सक्छ।
डिजाइन समीक्षामा “IPv6 BGP माथि IPv6 L3VPN चलाऊ” भन्नुहोस्, त्यो एउटै वाक्यभित्र तीनवटा छुट्टाछुट्टै निर्णय लुकेका छन्। कुन प्रिफिक्स ग्राहकको VPN का हुन्, कुन ठेगानाले प्रदायकका किनाराबीचको रुटिङ सत्र बोक्छन् र कुन कोरले लेबल भएको प्याकेट सार्छ भन्ने स्वतन्त्र छनोट हुन्। सबै IPv6 हुन सक्छन्, मिसिएका हुन सक्छन्, र मिसाउन जानाजान अनुमति छ। यी तीनलाई छुट्याउनु नै अस्पष्ट आवश्यकतालाई प्लेटफर्ममा जाँच्न सकिने कुरामा बदल्छ।
तीन काम छुट्याउनुहोस्
पहिलो काम ग्राहक रुट हो: एउटा VPN रुटिङ सन्दर्भमा पर्ने र हरेक अर्को सन्दर्भबाट बाहिर रहनुपर्ने IPv6 प्रिफिक्सहरू। दोस्रो त्यी प्रिफिक्स साटासाट गर्ने प्रदायकका किनारा राउटरबीचको रुटिङ जडान हो। तेस्रो लेबल भएको ग्राहक प्याकेटलाई कोर हुँदै टाढाको किनारासम्म पुर्याउने यातायात हो। तिनमध्ये एउटाको मात्र नाम लिनु अझै डिजाइन होइन।
| 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 रुट पनि त्यत्तिकै अपूरो छ। यिनलाई छुट्टाछुट्टै स्वीकृति लहरका रूपमा राख्नुले अर्को समस्या पहिचानको कुराकानी छोटो बनाउँछ, किनकि असफल हुने लहर पहिले नै लेखिएको छ।