Junos L2VPN: आधी ग्राहकाचा अटॅचमेंट करार बरोबर करा

pseudowire ला स्पर्श करण्यापूर्वी एक ग्राहक फ्रेम PE पर्यंत न्या आणि तो कुठे उतरायला हवा ते पहा। फिजिकल पोर्ट तो एका लॉजिकल युनिटमध्ये वर्गीकृत करतो, ती युनिट एन्कॅप्सुलेशन घेऊन जाते, आणि युनिट एका सेवेशी बांधलेली असते। तीन वेगळे निर्णय, चूक करण्याचे तीन वेगळे मार्ग। सिग्नलिंग बिघाड म्हणून एस्कलेट केलेली बहुतेक प्रकरणे प्रत्यक्षात अशा युनिटमध्ये वर्गीकृत फ्रेम असतात जी कोणीही त्या सेवेसाठी कॉन्फिगर केली नव्हती। म्हणून अटॅचमेंटपासून सुरुवात करा आणि बाहेरच्या दिशेने जा।

फ्रेम करार लिहून ठेवा

कोणतेही कॉन्फिगरेशन निवडण्यापूर्वी करार नोंदवा: टॅग नसलेला, एक सेवा टॅग, किंवा स्टॅक। ग्राहक पाठवणार तो MTU आणि प्रत्येक दिशेने अपेक्षित टॅग हाताळणी जोडा, कारण हे वाटाघाटीने ठरलेले गुणधर्म आहेत, स्थानिक पसंती नाही। युनिट क्रमांक फक्त ओळखकर्ता आहे आणि इंटरफेस कोणते फ्रेम स्वीकारेल हे सांगत नाही।

हे सेवा नोंदीत लिहा, तिकिटाच्या टिप्पणीत नाही। सहा महिन्यांनी हे डीबग करणारी व्यक्ती नोंद वाचेल। तिकीट ती वाचणार नाही।

एन्कॅप्सुलेशन कराराशी जुळवा

एका टॅगची सेवा सामान्यतः VLAN सर्किट एन्कॅप्सुलेशन वापरते, उदाहरणार्थ vlan-ccc, तर टॅग नसलेल्या फ्रेमना साधे Ethernet सर्किट स्वरूप लागते आणि स्टॅकला दोन टॅग समजणारे विस्तारित स्वरूप लागते। प्रति-युनिट सेवा एन्कॅप्सुलेशनला आधार देणाऱ्या प्लॅटफॉर्मवर एक फिजिकल इंटरफेस एकाच वेळी अनेकांचे आयोजन करू शकतो, जे सोयीचे आहे आणि फ्रेम चुकीच्या युनिटमध्ये पोहोचण्याचा मार्गही तोच आहे। जिथे तुमच्या प्लॅटफॉर्मची मार्गदर्शिका family ccc, ते संपूर्ण अटॅचमेंटचा भाग म्हणून कॉन्फिगर करा, राउटेड इंटरफेसवर स्क्रू करू नका। एन्कॅप्सुलेशन मार्गदर्शिका कोणत्या अटॅचमेंट प्रकारांवर कोणत्या अटी लादतात ते सूचीबद्ध करते।

सावधानता म्हणून प्रत्येक इंटरफेसवर family विधान जोडू नका। जे कॉन्फिगरेशन एक सर्किट चालवते ते पुढच्याला अशी फ्रेम स्वीकारायला भाग पाडू शकते जी त्याचा ग्राहक कधीही पाठवत नाही।

अटॅचमेंट योग्य सेवेशी बांधा

BGP ने सिग्नल केलेले लेयर 2 VPN, LDP ने सिग्नल केलेले सर्किट आणि इतर समर्थित सेवा यांपैकी प्रत्येकाचे स्वतःचे इंटरफेस बाइंडिंग आणि सिग्नलिंग कॉन्फिगरेशन आहे, आणि ते एकमेकांच्या जागी वापरता येत नाहीत। एकाची अटॅचमेंट शैली दुसऱ्याच्या सिग्नलिंगशी मिसळल्यास असे सर्किट तयार होते जे पीअरची नोंद करते आणि कधीही फ्रेम नेते नाही।

दूरचे टोक जवळच्या टोकाशी तुलना करा, कोणतेही एक वेगळे पाहू नका: पीअर पत्ता, सेवा ओळखकर्ता, एन्कॅप्सुलेशन सहमती, control word अपेक्षा आणि आकार अंदाजपत्रक। खालचा MPLS थर पूर्णपणे निरोगी असू शकतो तर अटॅचमेंट गायब असेल किंवा दुसरीकडे वर्गीकृत असेल, म्हणूनच फक्त खालचा थर पाहणारी चाचणी इथे काहीही सिद्ध करत नाही।

फ्रेमने तपासा, स्थितीने नाही

ग्राहक ट्रॅफिक पाठवत असताना स्थानिक इंटरफेसचे काउंटर वाचा, नंतर सेवेची स्थिती, आणि नंतर पुष्टी करा की येणारी फ्रेम हीच ठरलेली फ्रेम आहे, तिच्या टॅगसह। दुरुस्त केलेले अटॅचमेंट ती फ्रेम पोहोचवते; फक्त स्थिती बदलणे काहीही सिद्ध करत नाही।

जिथे तुम्हाला कॅप्चरचा अधिकार असेल, फ्रेम दोन्ही दिशांनी पहा। टॅगची असमानता स्थितीच्या दृश्यात सुटणे सोपे आहे आणि कॅप्चरमध्ये स्पष्ट असते। हीच असमानता एका दिशेने चालणाऱ्या आणि दुसऱ्या दिशेने अयशस्वी होणाऱ्या तक्रारींचेही स्पष्टीकरण देते।

मग ते लिहून ठेवा

सेवा नोंदीत चार मूल्ये नोंदवा: करार, एन्कॅप्सुलेशन, युनिट आणि सेवा बाइंडिंग। हीच चार नव्या अभियंत्याला लागतात आणि कॉन्फिगरेशन पुनरावलोकन क्वचितच स्पष्ट सांगते।

सर्किट सहा महिन्यांनी तुटल्यावर ती नोंद पाव तासाचे काम आणि चालू कॉन्फिगरेशनमधून संपूर्ण रचना पुन्हा काढणे यातील फरक ठरेल। शेवटच्या पडताळणीची तारीख जोडा, म्हणजे नोंद ती किती जुनी झाली हेही सांगेल।