L3VPN हस्तान्तरण: निजी मार्गहरू, पूर्वनिर्धारित, वा पूर्ण तालिका?

तपाईंको सर्किट चालु छ, VRF कन्फिगर भइसकेको छ, र प्रदायकले बाँकी डिजाइन निर्धारण गर्ने छोटो प्रश्न सोध्छ: ग्राहक किनाराले के प्राप्त गर्नुपर्छ? तीन उत्तर सामान्य छन् र तीमध्ये कुनै पनि लेबल स्ट्याक हुनुको तथ्यबाट आउँदैन। ती ट्राफिक शाखाबाट कहाँबाट बाहिरिन्छ भन्ने सेवा निर्णय हुन्।

हस्तान्तरण क्रमैसँग हेर्नु यसलाई ठीकसँग गर्ने सबैभन्दा सस्तो तरिका हो। कुनै कुरासँग नमिल्ने ट्राफिकलाई के हुन्छ भन्नेबाट तपाईं सुरु गर्नुहुन्छ, त्यसपछि निजी प्रिफिक्स र तिनको असफलताको व्यवहार लेख्नुहुन्छ, र त्यसपछि मात्र कति ठूलो फिड बोक्न तयार हुनुहुन्छ भन्ने कुरा गर्नुहुन्छ।

कसैले योजना नगरेको ट्राफिकबाट सुरु गर्नुहोस्

कुनै पनि प्रिफिक्स सूची आउनुअघि एउटा प्रश्न सोध्नुहोस्: प्याकेट कुनै पनि निजी मार्गसँग नमिल्दा त्यो कहाँ जानुपर्छ? आफ्नै इन्टरनेट सर्किट भएको शाखाले सामान्यतया स्थानीय पूर्वनिर्धारित राख्छ, त्यसैले सामान्य वेब ट्राफिक स्थानीय फायरवालबाट बाहिरिन्छ र प्रदायकलाई कहिल्यै छुँदैन। त्यो डिजाइनमा VPN ले केवल दूरका निजी साइटहरू बोक्छ, र थप विशिष्ट प्रिफिक्सहरूले छनोट गर्छन्।

केन्द्रीय निकास प्रयोग गर्न खोजिएको शाखा विपरीत अवस्था हो। त्यहाँ पूर्वनिर्धारित सेवाभित्र देखाउँछ, र प्रदायक वा केन्द्रीय साइटले अग्रसरण, फिर्ता राउटिङ र कुनै पनि अनुवादको स्वामित्व राख्छ। त्यो मालिक नभई "VPN मा पूर्वनिर्धारित" भन्नु नामहरू समाधान गर्ने तर केहीमा नपुग्ने शाखा दिन्छ।

दुई डिजाइन राउटिङ असफलता कस्तो देखिन्छ भन्नेमा फरक छन्, त्यसैले अनुमान गर्नु महँगो हुन्छ। स्थानीय पूर्वनिर्धारितसँग, हराएको निजी मार्गले त्यो ट्राफिक इन्टरनेटमा पठाउँछ, जहाँ फायरवालले त्यसलाई फाल्छ वा, अझ नराम्रो, तपाईंले नचाहेको कुनैले जवाफ दिन्छ। केन्द्रीय पूर्वनिर्धारितसँग, त्यही क्षतिले इन्टरनेट पहुँच पूर्ण रूपमा हटाउँछ र टिकट "सम्पूर्ण शाखा ठप्प छ" भनेर आउँछ। कुनै पनि असफलता आफैंमा गलत होइन, तर तपाईंले बेचेको सेवासँग एउटा मात्र मिल्छ, र केवल BGP कन्फिगरेसनले कुन बनाउनुभयो भनेर बताउँदैन।

निजी प्रिफिक्सहरू तिनको असफलता अवस्थासँगै लेख्नुहोस्

शाखाले पुग्नुपर्ने प्रिफिक्सहरू सूचीबद्ध गर्नुहोस् र तीमध्ये कुन संक्षेपित छन् नोट गर्नुहोस्। एक बिट धेरै फराकिलो समग्रीकरणले अज्ञात गन्तव्यहरूलाई VPN मा तान्छ, र दूरको पक्षले तिनको साँच्चै स्वामित्व लिई अग्रसरित गरेमा मात्र त्यो ठीक हुन्छ।

त्यसपछि निजी सेवा असफल हुँदा अभिप्रेत व्यवहार वर्णन गर्नुहोस्। राखिएको खारेज मार्गले ट्राफिकलाई अनधिकृत बाटोबाट पर राख्छ र सफा, अपेक्षित अवरोध दिन्छ। तैरिने पूर्वनिर्धारितले ब्याकअप बाटोमा सरेर उपलब्धता कायम राख्न सक्छ, तर त्यो ब्याकअप बाटोलाई त्यो ट्राफिक बोक्न अनुमति भएमा मात्र।

उपलब्धता र अनुमति दिइएको ब्याकअपलाई हस्तान्तरण कागजातमा दुई अलग आवश्यकताका रूपमा राख्नुहोस्। तिनलाई गाभ्ने टोलीहरू अन्ततः सहमत नीति लागू भयो कि भएन जाँच्नुको सट्टा शाखा खस्नुपर्थ्यो कि भनेर बहस गर्छन्।

CE ले वास्तवमा के स्थापना गर्यो जाँच्नुहोस्

कन्फिगरेसन अभिप्राय र अग्रसरण अवस्था पर्याप्त पटक फरक पर्ने हुँदा प्रमाणीकरण घटना समीक्षामा नभई हस्तान्तरणमै पर्छ। IOS-XE ग्राहक किनारमा तलका तीन आदेशले तीन फरक प्रश्नको जवाफ दिन्छन्: के प्रस्ताव गरियो, के स्वीकार गरियो र वास्तवमा के प्रयोग भइरहेको छ।

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

तीनैवटा हस्तान्तरणको दिन चलाउनुहोस्, महिनापछि होइन, जब कसैलाई के सहमति भयो अझै सम्झना छ। पहिलो आउटपुट soft-reconfiguration inbound वा भण्डारण गरिएको route refresh मा निर्भर छ; दुवैमध्ये केही नभए CE ले के अस्वीकार गर्यो देखाउन सक्दैन। दोस्रोले नीतिपछि स्वीकारिएका र उत्तम मार्गहरू देखाउँछ। तेस्रोले पूर्वनिर्धारित वास्तवमा कहाँ जान्छ भन्ने बताउँछ, र त्यो सम्पूर्ण हस्तान्तरणको सबैभन्दा उपयोगी लाइन हो।

साइट दोहोरो जडान भएको भए दोस्रो CE मा पनि त्यही जाँचहरू चलाउनुहोस्। दुई किनारबीचको असममित स्वीकृति "एउटा सर्भरबाट चल्छ तर अर्कोबाट चल्दैन" को सामान्य कारण हो, र सममित देखिने कन्फिगरेसन diff मा त्यो देखिँदैन।

ठूलो फिड अनुमान नगरी योग्यता निर्धारण गर्नुहोस्

कहिलेकाहीँ ग्राहकलाई VRF भित्र इन्टरनेट मार्ग जानकारी साँच्चै चाहिन्छ — नीति राउटिङका लागि वा प्रिफिक्सअनुसार निर्देशन गर्ने केन्द्रीय निकासका लागि। त्यो घोषणा गर्नुपर्ने, सीमा तोक्नुपर्ने र मूल्य निर्धारण गर्नुपर्ने आवश्यकता हो, लुकेको पूर्वनिर्धारित होइन। त्यससँगै RIB र FIB का लागि स्मृति, अद्यावधिकका लागि CPU, फिल्टर मर्मत र बन्ने तालिकाको मालिक आउँछ।

क्षमताका तर्कहरू दुवै दिशामा गलत हुन्छन्। पूर्ण तालिका VRF भित्र निषेधित छैन, र त्यो निःशुल्क पनि छैन। त्यस्तै, पुरानो मार्ग संख्याबाट आजको लागत अनुमान गर्न सकिँदैन, र सानो लेबल विनियोजनले मार्ग भण्डारणको लागत हटाउँदैन।

BGP/MPLS IP VPN विशिष्टताले VPN सेवाकै छेउमा इन्टरनेट पहुँचका धेरै व्यवस्थाहरूको चर्चा गर्छ र प्रत्येक ग्राहकका लागि पूर्ण तालिका वा पूर्वनिर्धारित अनिवार्य भनी घोषणा गर्दैन, र "मानक अभ्यास" भन्ने दाबी आउँदा देखाउनुपर्ने खण्ड त्यही हो: RFC 4364।

हस्तान्तरण बन्द गर्न घोषित समूह, प्राप्त समूह र छानिएको समूहलाई सहमत निकास नीतिको छेउमा अभिलेख गर्नुहोस्, र एउटा निजी गन्तव्य, एउटा अभिप्रेत सार्वजनिक गन्तव्य र एउटा मार्ग हराउने अवस्था परीक्षण गर्नुहोस्। ती तीन परीक्षणको हस्ताक्षरित अभिलेखले अधिकांश सञ्जालहरूले के गर्छन् भन्ने कुनै पनि भनाइभन्दा बढी विवाद मिलाउँछ।