प्रति-VRF लेबल या प्रति-प्रीफ़िक्स? असली क्षमता बिल

दो डिज़ाइन एक ही प्रोवाइडर कोर में एक ही ग्राहक प्रीफ़िक्स का विज्ञापन करते हैं। एक हर प्रीफ़िक्स के लिए एक लेबल आवंटित करता है, दूसरा पूरे VRF के लिए एक ही लेबल आवंटित करता है, और दूसरा हर स्लाइड पर सस्ता दिखता है। लेबल की गिनती वास्तविक है, पर यह वह बजट नहीं है जो आम तौर पर पहले ख़त्म होता है। दोनों में से चुनने का अर्थ है चार संसाधन गिनना, एक नहीं, और उनमें लेबल सबसे छोटा है।

चुनाव इस पर भी निर्भर करता है कि लेबल हटाने के बाद एग्रेस राउटर को पैकेट के साथ क्या करना है। निर्णय को उस कार्यात्मक अंतर से चलना चाहिए, लेबल के अंकगणित से नहीं।

हर आवंटन वास्तव में क्या बचाता है

प्रति-प्रीफ़िक्स आवंटन लेबल में फ़ॉरवर्डिंग जानकारी रखता है। एग्रेस राउटर गंतव्य खोज के बिना पैकेट सीधे सही एडजेसेंसी पर भेज सकता है, इसीलिए यह बड़े VRF रूट सेट के लिए अच्छी तरह स्केल करता है और इसीलिए यह हर VRF में हर विज्ञापित प्रीफ़िक्स के लिए एक लेबल खर्च करता है। प्रति-VRF आवंटन, जैसे Junos vrf-table-label, हर रूटिंग इंस्टेंस के लिए एक लेबल का विज्ञापन करता है और VRF तालिका चुनने के लिए उस लेबल का उपयोग करता है; इसके बाद राउटर तालिका के अंदर IP खोज करता है।

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

लेबल बहीखाता छोटा है

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

चुनने से पहले सेवा और ट्रांसपोर्ट दोनों के लेबल गिनें। प्रति-VRF डिज़ाइन को लूपबैक और पथ के हर हॉप के लिए अभी भी ट्रांसपोर्ट लेबल चाहिए, और उसे अभी भी एडजेसेंसी स्टेट चाहिए। अगर डिज़ाइन ब्रीफ़ केवल सेवा लेबल गिनता है, तो बचत गलत बहीखाते पर मापी जा रही है।

रूट फ़ीड लेबल से पहले मेमोरी का खर्च करते हैं

हर प्राप्त पथ कंट्रोल-प्लेन मेमोरी, अपडेट प्रोसेसिंग और कन्वर्जेंस समय खर्च करता है, चाहे VRF एक लेबल उपयोग करे या दस हज़ार। VRF के अंदर पूरा इंटरनेट फ़ीड BGP पथ, RIB, FIB प्रविष्टियों और उनके पीछे की उथल-पुथल के कारण महँगा है, तालिका के सामने वाले लेबल के कारण नहीं। यही फ़ीड उस किरायेदार के अंदर रूट लीक या नीति की गलती के प्रभाव का दायरा भी बढ़ाता है।

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

प्रति-VRF लेबलिंग कब सही डिफ़ॉल्ट है

यह अच्छा डिफ़ॉल्ट है जब प्लेटफ़ॉर्म इसे समर्थित के रूप में दस्तावेज़ित करता है, जब VRF रूट की संख्या बड़ी है, और जब एग्रेस खोज लागत ट्रैफ़िक प्रोफ़ाइल के लिए स्वीकार्य है। यह तब भी स्वाभाविक फ़िट है जब परिचालन सरलता फ़ॉरवर्डिंग से आख़िरी माइक्रोसेकंड निकालने से ज़्यादा मायने रखती है, क्योंकि प्रति किरायेदार एक लेबल प्रति प्रीफ़िक्स लेबल की तुलना में समझाना और ऑडिट करना आसान है।

यह गलत डिफ़ॉल्ट है जब प्लेटफ़ॉर्म का दस्तावेज़ीकरण इस सुविधा को विशिष्ट हार्डवेयर या रिलीज़ बाधाओं से बाँधता है, या जब डिज़ाइन एग्रेस पर प्रति-प्रीफ़िक्स फ़ॉरवर्डिंग निर्णयों पर निर्भर करती है। व्यवहार मान लेने से पहले प्लेटफ़ॉर्म का अपना statement संदर्भ पढ़ें; Junos कमांड दस्तावेज़ित है, पर उसके आसपास की हार्डवेयर और रिलीज़ सीमाएँ ही तैनाती तय करती हैं।

ऐसा बजट जिसका आप बचाव कर सकें

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

फिर स्थिर अवस्था के साथ विफलता मोड पर भी सहमति बनाएँ। क्या होता है जब फ़ीड आधा बढ़ जाता है, जब किरायेदार दूसरा VRF जोड़ता है, या जब प्लेटफ़ॉर्म को तालिका का आकार बदलने के लिए रीबूट चाहिए? उन सवालों को झेलने वाला बजट केवल काग़ज़ पर चलने वाली लेबल गिनती से ज़्यादा मूल्यवान है।

एग्रेस क्रिया और प्लेटफ़ॉर्म सीमाओं से आवंटन चुनें, फिर रूट फ़ीड को स्पष्ट सेवा निर्णय बनाएँ। लेबल डिज़ाइन का दृश्य हिस्सा है; रूट वह हिस्सा हैं जिसका भुगतान हर दिन करना पड़ता है।