साइटभित्र एउटै iESI, साइटहरूबीच अद्वितीय: Junos जोडाइ

दुई गेटवे जोडीहरूले दुई डेटा केन्द्रहरूलाई सेवा दिन्छन्, र डिजाइनलाई कति interconnect ESI मान चाहिन्छ भनी कसैले निर्णय गर्नुपर्छ। उत्तर प्रत्येक गेटवे समूहको लागि एक हो, प्रत्येक fabric को लागि एक होइन र प्रत्येक गेटवेको लागि एक होइन। यसलाई गलत गरेमा कन्फिगर गरिएको देखिने र गलत forwarder छान्ने fabric बन्छ, वा अलग रहनुपर्ने दुई साइटहरू मिलाइन्छ। नियम र यसका अपवादहरू गेटवे सूचीको छेउमा लेख्न लायक छन्।

दुई दायरा, दुई नियम

साइटभित्र, अतिरिक्त interconnect गेटवेहरू एउटा multihomed अन्त्य बिन्दुको रूपमा काम गर्छन्, त्यसैले तिनीहरू एउटै interconnect ESI साझा गर्छन्। तिनीहरूका peers ले दुई स्वतन्त्र सदस्यको सट्टा एउटा तार्किक सदस्य देख्नुपर्छ। साझा मानको सम्पूर्ण अर्थ यही हो।

साइटहरूबीच, प्रत्येक गेटवे समूहले आफ्नै मान पाउँछ। एउटै पहिचानकर्ता साझा गर्ने दुई डेटा केन्द्र नियन्त्रण तहमा एउटा multihomed समूह बन्छन्, जुन सामान्यतया WAN भरिको जोडाइ डिजाइनको उद्देश्य होइन। एउटै समूहका दुई साइटहरूले एकअर्काको असफलता मोड पनि उत्तराधिकारमा पाउँछन्।

साइटभित्र: समूहका लागि एउटा पहिचान

जोडीलाई दुवै peer मा एउटै मान दिनुहोस्, एउटै सेवा सन्दर्भमा, र यसलाई च्याट थ्रेडमा होइन, नेटवर्कको पहिचानकर्ता सूचीमा अभिलेख गर्नुहोस्। दुई सदस्यबीचको असमझदारी त्यो असफलता मोड हो जसले एक सदस्यको समूह र स्पष्ट अलार्म बिना छोड्छ। काम गर्ने सत्रमा विश्वास गर्नुअघि दुवै सदस्यको तुलना गर्नुहोस्।

समर्थित मोडेल 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 परिवर्तनको रूपमा, जो त्यही हो, पुनरावलोकन गर्न सकिन्छ। परिणामहरू नै पहिचानकर्ताले रेखाचित्रले भनेको कुरा गर्छ भन्ने एकमात्र प्रमाण हुन्।