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 या संग्रहीत रूट रिफ़्रेश पर निर्भर है; इनमें से किसी के बिना CE आपको नहीं दिखा सकता कि उसने क्या अस्वीकार किया। दूसरा नीति के बाद स्वीकृत और सर्वोत्तम मार्ग दिखाता है। तीसरा बताता है कि डिफ़ॉल्ट वास्तव में कहाँ जाता है, और यह पूरे हैंडऑफ की सबसे उपयोगी पंक्ति है।

अगर साइट दोहरे कनेक्शन वाली है तो दूसरे CE पर वही जाँच चलाएँ। दो किनारों के बीच असममित स्वीकृति "एक सर्वर से काम करता है और दूसरे से नहीं" का आम कारण है, और सममित दिखने वाले कॉन्फ़िगरेशन अंतर में यह अदृश्य है।

बड़े फ़ीड को मानने के बजाय उसे योग्य बनाएँ

कभी-कभी ग्राहक को VRF के भीतर इंटरनेट मार्ग की जानकारी वास्तव में चाहिए होती है, नीति-आधारित रूटिंग के लिए या ऐसे केंद्रीय एग्ज़िट के लिए जो प्रीफ़िक्स के अनुसार निर्देशित करता है। यह घोषित, सीमित और मूल्यांकित करने वाली आवश्यकता है, छिपा हुआ डिफ़ॉल्ट नहीं। इसके साथ RIB और FIB के लिए मेमोरी, अपडेट के लिए CPU, फ़िल्टर रखरखाव और परिणामी तालिका का एक मालिक आता है।

क्षमता की दलीलें दोनों दिशाओं में ग़लत होती हैं। पूरी तालिका VRF के भीतर मना नहीं है, और वह मुफ़्त भी नहीं है। इसी तरह, आप पुरानी रूट संख्या से आज की लागत नहीं निकाल सकते, और छोटा लेबल आवंटन रूट संग्रहीत करने की लागत नहीं हटाता।

BGP/MPLS IP VPN विनिर्देश VPN सेवा के साथ-साथ इंटरनेट-पहुँच की कई व्यवस्थाओं पर चर्चा करता है और हर ग्राहक के लिए पूरी तालिका या डिफ़ॉल्ट अनिवार्य घोषित नहीं करता, और "मानक अभ्यास" का कोई दावा आने पर यही वह भाग है जिसे दिखाना चाहिए: RFC 4364।

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