Junos L2VPN: पहले ग्राहक के अटैचमेंट अनुबंध को सही करें
pseudowire स्थानीय अटैचमेंट से शुरू होता है। सिग्नलिंग छूने से पहले फ़्रेम, लॉजिकल यूनिट, एनकैप्सुलेशन और सेवा बाइंडिंग मिलाएँ।
किसी pseudowire को छूने से पहले एक ग्राहक फ़्रेम को PE तक ले जाइए और देखिए कि उसे कहाँ उतरना चाहिए। फ़िज़िकल पोर्ट उसे एक लॉजिकल यूनिट में वर्गीकृत करता है, वह यूनिट एक एनकैप्सुलेशन रखती है, और यूनिट किसी सेवा से बँधी है। तीन अलग निर्णय, ग़लत होने के तीन अलग रास्ते। सिग्नलिंग गड़बड़ी के रूप में एस्केलेट किए गए ज़्यादातर मामले असल में एक फ़्रेम हैं जो ऐसी यूनिट में वर्गीकृत है जिसे किसी ने उस सेवा के लिए कॉन्फ़िगर नहीं किया। इसलिए अटैचमेंट से शुरू कीजिए और बाहर की ओर बढ़िए।
फ़्रेम अनुबंध लिख लीजिए
कोई भी कॉन्फ़िगरेशन चुनने से पहले अनुबंध दर्ज कीजिए: बिना टैग, एक सेवा टैग, या स्टैक। वह MTU जोड़िए जो ग्राहक भेजेगा और हर दिशा में अपेक्षित टैग व्यवहार, क्योंकि ये बातचीत से तय गुण हैं, स्थानीय पसंद नहीं। यूनिट नंबर सिर्फ़ एक पहचानकर्ता है और यह नहीं बताता कि इंटरफ़ेस कौन-से फ़्रेम स्वीकार करेगा।
इसे सेवा नोट में लिखिए, टिकट की टिप्पणी में नहीं। जो छह महीने बाद इसे डीबग करेगा वह नोट पढ़ेगा। टिकट वह नहीं पढ़ेगा।
एनकैप्सुलेशन को अनुबंध से मिलाइए
एक टैग वाली सेवा आम तौर पर VLAN सर्किट एनकैप्सुलेशन इस्तेमाल करती है, जैसे vlan-ccc, जबकि बिना टैग फ़्रेम को सादा Ethernet सर्किट रूप चाहिए और स्टैक को वह विस्तारित रूप चाहिए जो दो टैग समझता है। ऐसे प्लेटफ़ॉर्म पर जो प्रति-यूनिट सेवा एनकैप्सुलेशन का समर्थन करता है, एक फ़िज़िकल इंटरफ़ेस एक साथ कई की मेज़बानी कर सकता है, जो सुविधाजनक है और यही वह रास्ता भी है जिससे फ़्रेम ग़लत यूनिट में पहुँचता है। जहाँ आपके प्लेटफ़ॉर्म की गाइड family ccc, इसे पूरे अटैचमेंट के हिस्से के रूप में कॉन्फ़िगर कीजिए, न कि राउटेड इंटरफ़ेस पर जोड़िए। एनकैप्सुलेशन गाइड बताती है कि कौन-से अटैचमेंट प्रकार कौन-सी शर्तें लगाते हैं।
सावधानी के तौर पर हर इंटरफ़ेस पर family कथन न जोड़िए। जो कॉन्फ़िगरेशन एक सर्किट को चलाता है, अगले को ऐसे फ़्रेम स्वीकार करने पर मजबूर कर सकता है जो उसका ग्राहक कभी नहीं भेजता।
अटैचमेंट को सही सेवा से बाँधिए
BGP से सिग्नल किया गया लेयर 2 VPN, LDP से सिग्नल किया गया सर्किट और दूसरी समर्थित सेवाएँ, हर एक का अपना इंटरफ़ेस बाइंडिंग और सिग्नलिंग कॉन्फ़िगरेशन है, और वे एक-दूसरे के बदले नहीं हैं। एक के अटैचमेंट तरीके को दूसरे की सिग्नलिंग के साथ मिलाने से ऐसा सर्किट बनता है जो पीयर की रिपोर्ट करता है और कभी फ़्रेम नहीं ले जाता।
दूर के सिरे की तुलना नज़दीक के सिरे से कीजिए, न कि किसी एक को अलग-थलग देखिए: पीयर पता, सेवा पहचानकर्ता, एनकैप्सुलेशन सहमति, control word अपेक्षा और आकार बजट। नीचे की MPLS परत पूरी तरह स्वस्थ हो सकती है जबकि अटैचमेंट गायब हो या कहीं और वर्गीकृत हो, इसीलिए सिर्फ़ नीचली परत देखने वाला परीक्षण यहाँ कुछ साबित नहीं करता।
फ़्रेम से जाँचिए, स्थिति से नहीं
स्थानीय इंटरफ़ेस के काउंटर पढ़िए जब ग्राहक ट्रैफ़िक भेज रहा हो, फिर सेवा की स्थिति, और फिर पुष्टि कीजिए कि आने वाला फ़्रेम वही तय किया गया फ़्रेम है, उसके टैग सहित। मरम्मत किया गया अटैचमेंट वह फ़्रेम पहुँचाता है; अकेले स्थिति का बदलना कुछ साबित नहीं करता।
जहाँ आपको कैप्चर करने का अधिकार हो, फ़्रेम को दोनों दिशाओं में देखिए। टैग की असमानता स्थिति के दृश्य में छूट जाना आसान है और कैप्चर में स्पष्ट होती है। यही असमानता उन शिकायतों को भी समझाती है जो एक दिशा में काम करती हैं और दूसरी में विफल होती हैं।
फिर इसे लिख लीजिए
सेवा नोट में चार मान दर्ज कीजिए: अनुबंध, एनकैप्सुलेशन, यूनिट और सेवा बाइंडिंग। यही चार वे हैं जो नए इंजीनियर को चाहिए और जो कॉन्फ़िगरेशन समीक्षा शायद ही स्पष्ट कहती है।
जब सर्किट छह महीने बाद टूटेगा, वह नोट चौथाई घंटे के काम और चल रहे कॉन्फ़िगरेशन से पूरा डिज़ाइन दोबारा निकालने के बीच का अंतर होगा। अंतिम सत्यापन की तारीख़ जोड़िए, ताकि नोट यह भी बताए कि वह कितना पुराना हो गया है।