pseudowire ला स्पर्श करण्यापूर्वी प्रत्येक कस्टमर एजला कोणता फ्रेम मिळावा हे ठरवा। सोप्या प्रकरणात CE A सेवा सीमांकित करणारा एक टॅग पाठवतो आणि CE B टॅगशिवाय फ्रेमची अपेक्षा करतो, आणि हा फरक प्रोव्हायडर एजवरच सोडवला जातो। टॅग स्थानिक धोरण आहे, ग्राहकाच्या Ethernet कराराचा भाग नाही, आणि pseudowire मूळ फ्रेमऐवजी सहमत फ्रेम वाहून नेतो। कोणत्याही कॉन्फिगरेशनपूर्वी दोन्ही दिशा लिहून घ्या।

आधी फ्रेम करार लिहा

पुढील दिशा एक टॅग काढते आणि परतीची दिशा तो पुन्हा जोडते। जर तुम्ही त्यापैकी फक्त एकच लिहाल, तर तुम्ही एका दिशेने कार्यरत मार्ग तपासाल आणि सर्किट निरोगी घोषित कराल।

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

pseudowire मोडवर सहमत व्हा

RFC 4448 raw आणि tagged pseudowire मोडमध्ये फरक करतो आणि सेवा सीमांकित करणारे टॅग कसे हाताळले जातात हे सांगतो। raw मोड अजूनही ग्राहक फ्रेमशी संबंधित टॅग वाहू शकतो, म्हणून फरक टॅगच्या सेवा-भूमिकेबद्दल आहे, केवळ 802.1Q हेडरच्या उपस्थितीबद्दल नाही। मोड tagged वि untagged म्हणून वाचणे हे हे काम चुकीच्या पद्धतीने व्याप्ती ठरवण्याचे सर्वात सामान्य साधन आहे। कोणती क्रिया हवी आहेत हे ठरवण्यापूर्वी साथीदारासोबत मोडवर सहमत व्हा।

नंतर प्रत्यक्ष pseudowire प्रकार आणि साथीदाराचे पॅरामीटर तपासा। स्थानिक VLAN अटॅचमेंट आणि दूरस्थ पोर्ट अटॅचमेंटसाठी समर्थित interworking व्यवस्था आवश्यक आहे, आणि दोन स्थानिक रीराइट विधाने जाहीर केलेले सर्किट प्रकार जुळतात हे सिद्ध करत नाहीत।

जर control word आणि MTU च्या अपेक्षा वेगळ्या असतील, तर तुमच्याकडे वाटाघाटीची समस्या आहे जी कोणताही रीराइट दुरुस्त करणार नाही। दोन्हींची पुष्टी डिझाइन दस्तऐवजाऐवजी साथीदाराच्या सुरू असलेल्या कॉन्फिगरेशनवरून करा।

स्थानिक टॅग क्रिया लागू करा

Juniper ची VLAN CCC रीराइट मार्गदर्शिका pop, push आणि swap क्रिया प्लॅटफॉर्म-विशिष्ट निर्बंधांसह दस्तऐवजीकृत करते। आधीच कॉन्फिगर केलेल्या सुसंगत tagged युनिटसाठी उदाहरण दिशा ingress वर input-vlan-map pop आणि egress वर output-vlan-map push आहे। त्या ओळी क्रिया दाखवतात, पूर्ण इंटरफेस किंवा सर्किट कॉन्फिगरेशन नाही। एकाच डिव्हाइस कुटुंबाचे उदाहरण सर्वत्र लागू करण्याऐवजी अचूक प्लॅटफॉर्म आणि रिलीझची पुष्टी करा।

युनिटच्या समर्थित VLAN आणि encapsulation सेटिंग्जनी अजूनही इच्छित टॅग आणि वर्गीकरण परिभाषित केले पाहिजे। चुकीचे फ्रेम वर्गीकृत करणाऱ्या युनिटवरील रीराइट विधान समस्या दुरुस्त करत नाही, स्थानांतरित करते।

सेवेसाठी आवश्यक असलेले कोणतेही अंतर्गत ग्राहक टॅग जपून ठेवा। स्टॅक केलेल्या टॅगमध्ये, काहीही काढण्यापूर्वी तुम्ही कोणते बाह्य टॅग बदलत आहात ते ठरवा।

आकाराचे बजेट करा, केवळ टॅगचे नाही

आकार बजेटमध्ये ठेवलेले टॅग, प्रत्यक्ष MPLS स्टॅक आणि control word समाविष्ट करा। RFC 8469 Ethernet pseudowire साठी control word ची शिफारस करतो, आणि ही शिफारस फ्रेम बजेट बदलते, तुमचा प्लॅटफॉर्म ते डीफॉल्टनुसार सक्षम करो किंवा न करो। MTU विसंगती सुसंगत करा, तिच्या इशाऱ्याला दुरुस्ती म्हणून दाबण्याऐवजी। दाबलेला इशारा म्हणजे तारीख पुसून टाकलेली नियोजित खंड।

दोन्ही प्रोव्हायडर एजवर तेच बजेट तपासा, कारण एका बाजूने टॅग आणि दुसऱ्याने control word जोडणे पूर्वी ठीक असलेला पेलोड तोडण्यासाठी पुरेसे आहे।

जर संख्या जुळत नसतील, तर योजना बदला, लॉगिंग पातळी नाही।

ते फ्रेम दर फ्रेम स्वीकारा

स्वीकृतीसाठी, प्रत्येक कस्टमर अटॅचमेंटवर अपेक्षित फ्रेम दोन्ही दिशांनी तपासा। नंतर सेवेला खरोखर आवश्यक असलेला अनुप्रयोग आणि नियंत्रण रहदारी मंजूर चाचणी योजनेनुसार चालवा, कारण ping निरोगी पोहोचणाऱ्या tagged फ्रेमपेक्षा खूपच कमी सिद्ध करतो। ingress आणि egress चा फ्रेम करार सर्किटच्या कॉन्फिगरेशनसह नोंदवा। हाच नोंद अगला बदल पुनरावलोकनयोग्य बनवतो।

मोड, टॅग क्रिया, MTU बजेट आणि चाचणी निकाल एकाच ठिकाणी ठेवा, कारण त्यांना अर्थ केवळ एकत्र असतो। ते तीन तिकिटांत विभागल्यास पुढील अभियंत्याला तीच मर्यादा पुन्हा सापडेल याची हमी मिळते।

सर्किट तेव्हा पूर्ण होते जेव्हा दोन्ही दिशा तुम्ही सुरुवातीला लिहिलेल्या कराराशी जुळतात, तेव्हा नाही जेव्हा पहिली दिशा पास होते।

संबंधित लेख