MX के IPsec समाप्त कर सकने से पहले क्या मेल खाना चाहिए
कॉन्फ़िगरेशन स्वीकारने वाला commit केवल पार्सर सिद्ध करता है, पथ नहीं। प्लेटफ़ॉर्म टपल के पाँच भाग तय करते हैं कि सेवा वास्तव में चलती है या नहीं।
कॉन्फ़िगरेशन साफ़ commit होता है, इंटरफ़ेस ऊपर आते हैं, और टनल फिर भी बनने से इंकार करता है। लॉग में कोई पंक्ति यह नहीं कहती कि प्लेटफ़ॉर्म यह नहीं कर सकता; वह बस यह नहीं करता। Junos पर IPsec एक सेवा है जिसे केवल चेसिस, सेवा हार्डवेयर या सॉफ़्टवेयर पथ, और रिलीज़ का एक विशिष्ट संयोजन निष्पादित कर सकता है, और एक सुविधा पृष्ठ सॉफ़्टवेयर की क्षमता बताता है, आपके उपकरण की नहीं। टपल को भाग-भाग कर जाँचना होगा, क्योंकि commit का परिणाम केवल पार्सर सिद्ध करता है।
पैकेट वास्तव में कहाँ जाता है
IPsec के लिए चुना गया ट्रैफ़िक उस घटक तक पहुँचना चाहिए जो उसे एन्क्रिप्ट करता है। सेवा मॉड्यूल वाले प्लेटफ़ॉर्म पर, चुना गया प्रवाह उसी मॉड्यूल की ओर निर्देशित होता है और फिर अग्रेषण पथ पर लौट आता है। यदि मॉड्यूल नहीं है, क्षमता कम है या इंटरफ़ेस से बँधा नहीं है, तो कॉन्फ़िगरेशन मौजूद है और कोई पैकेट संसाधित नहीं होता। commit के आउटपुट में कुछ भी उस स्थिति को स्वस्थ स्थिति से अलग नहीं करता।
सॉफ़्टवेयर में होस्ट किए गए कार्यान्वयन काम को रूटिंग इंजन पर या इनलाइन हार्डवेयर में रखते हैं, संसाधन सीमाएँ बहुत अलग होती हैं। कॉन्फ़िगरेशन में दिखने वाला टनल आपको यह नहीं बताता कि इनमें से कौन-सा पथ वास्तव में उसे ले जा रहा है।
टपल के पाँच भाग
कोई भी सिफ़ारिश पढ़ने से पहले संयोजन लिख लें, क्योंकि एक भाग बाकी को अमान्य कर सकता है। तीन साल पहले सेवा को सहारा देने वाला भाग संख्या इस चेसिस में लगे कार्ड और रिलीज़ के बारे में कुछ नहीं कहता। नीचे की पंक्तियों को जाँच-सूची की तरह पढ़ें, फिर वे मान भरें जो कॉन्फ़िगरेशन आपको नहीं दिखा सकता।
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
पता परिवार और कार्यभार वे दो पंक्तियाँ हैं जिन्हें लोग छोड़ देते हैं, और दोनों जाँचने में सस्ती और बाद में पता चलने पर महँगी हैं। टपल को उपकरण से पढ़ें, स्प्रेडशीट से नहीं, क्योंकि कॉन्फ़िगरेशन वह बताता है जो आपने माँगा, वह नहीं जो लगा है। अधिकांश भाग दो कमांड उठाते हैं: show chassis hardware वास्तव में लगे कार्ड का नाम बताता है, और show version सटीक रिलीज़ देता है। कोई भी इस पर निर्भर नहीं है कि कॉन्फ़िगरेशन सही है, और यही मूल बात है।
show chassis hardware
show versionरिलीज़ द्वार असली द्वार हैं
रिलीज़ का विवरण औपचारिकता नहीं है। Juniper का IPsec अवलोकन मल्टीसर्विस कार्ड के लिए AES-GCM समर्थन को Junos 17.3R1 पर तिथि करता है, और FIPS मोड 17.4R1 से शुरू होता है। इसलिए एक ही सुविधा की दो सीमाएँ हैं, यह इस पर निर्भर करता है कि प्लेटफ़ॉर्म कैसे संचालित होता है, और आप जिस मोड में चलाते हैं वह तय करता है कौन-सी लागू होती है। सुविधा सूची जाँचने से पहले मोड जाँचें।
रिलीज़ नोट्स बिल्कुल लगे संस्करण के लिए पढ़ें, दस्तावेज़ित नवीनतम के लिए नहीं। बाद के build में आई क्षमता को पहले में मौजूद नहीं माना जा सकता, और एक कार्ड के लिए लिखा कथन दूसरे पर नहीं जाता। रिलीज़ नोट की पंक्ति को डिज़ाइन रिकॉर्ड में कॉपी करें ताकि दावा अपना स्रोत साथ रखे, क्योंकि किसी प्लेटफ़ॉर्म परिवार के लिए लिखा समर्थन कथन उस मोड के बारे में कथन नहीं है जिसमें आप चलाते हैं या उस कार्ड के बारे में जो आपके पास है।
क्षमता कार्यभार है, शीर्षक नहीं
मापने की शर्तों के बिना शीर्षक में दिया थ्रूपुट आँकड़ा विपणन संख्या है। छोटे पैकेट प्रति बिट बड़े पैकेट से कहीं अधिक महँगे होते हैं, समवर्ती एसोसिएशन स्मृति लेते हैं, और कार्ड साझा करने वाली हर दूसरी सेवा शेष को घटाती है।
अपेक्षित ट्रैफ़िक से अनुमान लगाएँ: सामान्य और सबसे बुरे पैकेट आकार, साथियों की संख्या, और क्या वह कार्ड NAT या कोई अन्य सेवा भी समाप्त करता है। फिर उस दिन के लिए गुंजाइश छोड़ें जब कोई पथ डिज़ाइन की मान्यता से अधिक भार उठाए। निष्क्रिय हार्डवेयर मान लेने वाली क्षमता योजना एक इच्छा है, योजना नहीं। यदि यह संख्या व्यावसायिक तर्क के लिए महत्वपूर्ण है, तो इसे एक बार उपकरण पर प्रतिनिधि भार के तहत मापें और वह माप डिज़ाइन के साथ रखें।
डिज़ाइन से पहले रिकॉर्ड लिखें
डिज़ाइन को जिन क्षमताओं की आवश्यकता है, उनमें से प्रत्येक के लिए प्लेटफ़ॉर्म संदर्भ, रिलीज़ से मेल खाता दस्तावेज़ और कोई भी अनसुलझा प्रतिबंध एक ही जगह रखें। जहाँ टपल की कोई पंक्ति विफल हो, वहाँ किसी पुरानी खरीद सूची के इर्द-गिर्द डिज़ाइन फिर से बनाने के बजाय किसी अलग स्वीकृत गेटवे से तुलना करें। रिकॉर्ड में लिखा होना चाहिए कि कौन-सा ठीक सिस्टम यह काम करता है और किन सीमाओं में।
उसके बाद ही साथी की जाँच करें, क्योंकि दूर के छोर के साथ प्रोटोकॉल अनुकूलता अगला प्रश्न है और स्थानीय समर्थन का विकल्प कभी नहीं है। सहमत साथी भी ऐसे चेसिस की मदद नहीं कर सकता जो कभी एक भी पैकेट एन्क्रिप्ट नहीं करता।