साइटच्या आत तोच iESI, साइट्समध्ये अद्वितीय: Junos शिवणकाम

दोन गेटवे जोड्या दोन डेटा सेंटरना सेवा देतात, आणि डिझाइनला किती interconnect ESI मूल्ये लागतील हे कोणीतरी ठरवावे लागते। उत्तर प्रत्येक गेटवे गटासाठी एक आहे, प्रत्येक fabric साठी एक नाही आणि प्रत्येक गेटवेसाठी एक नाही। हे चुकीचे केल्यास कॉन्फिगर केलेले दिसणारे आणि चुकीचे forwarder निवडणारे fabric तयार होते, किंवा वेगळी राहायला हवी होती अशी दोन साइट्स एकत्र होतात। नियम आणि त्याचे अपवाद गेटवे यादीच्या शेजारी लिहून ठेवण्यासारखे आहेत।

दोन व्याप्ती, दोन नियम

साइटच्या आत, अतिरिक्त interconnect गेटवे एक multihomed टोकबिंदू म्हणून काम करतात, म्हणून ते एकच interconnect ESI सामायिक करतात। त्यांच्या peers ना दोन स्वतंत्र सदस्यांऐवजी एक तार्किक सदस्य दिसला पाहिजे। सामायिक मूल्याचा संपूर्ण अर्थ हाच आहे।

साइट्समध्ये, प्रत्येक गेटवे गटाला स्वतःचे मूल्य मिळते। एकच ओळखकर्ता सामायिक करणारे दोन डेटा सेंटर नियंत्रण स्तरावर एक multihomed गट बनतात, जे सामान्यतः WAN वरून शिवणकाम डिझाइनचा हेतू नसतो। एका गटातील दोन साइट्स एकमेकांचे बिघाड मोड देखील वारसा घेतात।

साइटच्या आत: गटासाठी एक ओळख

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

समर्थित मॉडेल all-active आहे। तोच संदर्भ या शिवणकाम ओळखीसाठी single-active कार्य, स्वयंचलितपणे मिळवलेले LACP ओळखकर्ते आणि source-bmac पर्याय वगळतो, म्हणून त्यापैकी एक गृहीत धरलेल्या डिझाइनचा ओळखकर्ता निवडण्यापूर्वीच पुनर्विचार करावा लागेल। ही मर्यादा डिझाइन इनपुट आहे, तळटीप नाही।

साइट्समध्ये: वेगळी मूल्ये, किंवा हेतुपूर्वक विलीनीकरण

प्रत्येक साइटसाठी अद्वितीय मूल्य दोन गेटवे गट वेगळे ठेवते। हेतू खरोखर एक multihomed गट साइट्समध्ये विस्तारण्याचा असल्यास, तो स्वतःच्या विलंब, बिघाड आणि अग्रेषण परिणामांसह दुसरा आर्किटेक्चर आहे, आणि तो ओळखकर्त्याची निवड म्हणून नाही तर आर्किटेक्चर म्हणून ठरवला पाहिजे। देखभाल विंडोपूर्वी तो निर्णय लेखी मागा।

इच्छित फरक योजनेत लिहा, जेणेकरून नंतर कार्यरत साइट टेम्पलेट कॉपी करणारा अभियंता त्याचा ओळखकर्ताही सोबत आणणार नाही।

peer विधान ओळखीचा भाग आहे

गटातील प्रत्येक गेटवे आपल्या स्थानिक peers ची loopback पत्त्यानुसार यादी करतो, आणि ते नाते वैयक्तिक MAC-VRF च्या आत नाही तर जागतिक EVPN स्तरावर राहते। ते चुकीच्या श्रेणीक्रमात ठेवणे हा commit होणारे पण गट कधीही तयार न करणारे कॉन्फिगरेशन तयार करण्याचा सामान्य मार्ग आहे। संदर्भ श्रेणीक्रम एकदा वाचा, नंतर त्याला धरून राहा।

विधानाचे नावही बदलले। Juniper ने 24.2R1 मध्ये interconnect peer-gateways विधानाचे नाव बदलले आणि 24.4R1 मध्ये डेटा सेंटर interconnect साठी interconnect-विशिष्ट स्वरूप पुनर्संचयित केले। त्यामुळे मध्यस्थ आवृत्तीतून घेतलेला स्निपेट तैनात आवृत्ती स्वीकारत नाही असे नाव वापरू शकतो, किंवा उलटही। स्निपेट कोणत्या आवृत्तीतून आला ते स्निपेटच्या शेजारी नोंदवा।

iESI सामायिक करणे काय करत नाही

ते तुमच्यासाठी route target, VNI किंवा स्थानिक EVPN इन्स्टन्स परिभाषित करत नाही। ते दोन्ही बाजूंनी जुळले पाहिजेत असे स्वतंत्र कॉन्फिगरेशन राहतात, आणि जुळणारा ओळखकर्ता, route target जुळत नसताना, तयार होणारा पण काहीही वाहून न नेणारा गट तयार करतो। त्या सेटिंग्जच्या दोन्ही बाजूंची एकाच पासमध्ये तुलना करा।

ते peer पोहोचक्षमता किंवा designated forwarder निवडही सिद्ध करत नाही। सामान्य स्थितीत unicast आणि आवश्यक broadcast व multicast वर्तनाची चाचणी करा, नंतर एक गेटवे काढून पुन्हा करा जेणेकरून उरलेला सदस्य गट एकटाच वाहेल।

तोच दुसरा रन गट खरा असल्याचे सिद्ध करतो।

निरीक्षण केलेले सदस्यत्व आणि सेवा संदर्भ चाचणी निकालांसोबत ठेवा। नंतरचा ओळखकर्ता बदल नंतर स्ट्रिंगचा सौंदर्य बदल म्हणून नाही तर multihoming बदल म्हणून, जो तो आहे, पुनरावलोकन करता येईल। ओळखकर्ता आकृती सांगते ते करतो याचा एकमेव पुरावा निकाल आहेत।