एक ही साइट के भीतर एक ही iESI, साइटों के बीच अद्वितीय: Junos सिलाई

दो गेटवे जोड़ियाँ दो डेटा सेंटरों की सेवा करती हैं, और किसी को तय करना है कि डिज़ाइन को कितने interconnect ESI मान चाहिए। उत्तर प्रति गेटवे समूह एक है, प्रति fabric एक नहीं और प्रति गेटवे एक नहीं। ऐसा गलत करने पर ऐसा fabric बनता है जो कॉन्फ़िगर दिखता है और गलत forwarder चुनता है, या ऐसी दो साइटें जुड़ जाती हैं जिन्हें अलग रहना था। नियम और उसके अपवाद गेटवे सूची के बगल में लिखने योग्य हैं।

दो दायरे, दो नियम

साइट के भीतर, अतिरिक्त 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 परिवर्तन के रूप में, जो वह है, समीक्षित किया जा सकता है, न कि स्ट्रिंग के सौंदर्य संपादन के रूप में। परिणाम ही एकमात्र प्रमाण हैं कि पहचानकर्ता वही करता है जो रेखाचित्र कहता है।