OTV थप्नु अघि, तपाईंलाई चाहिने Ethernet सम्झौता लेख्नुहोस्

एउटा workload दोस्रो डेटा केन्द्रमा सर्छ र पहिलोबाट राम्ररी जवाफ दिइरहेको सेवामा समय सीमा नाघ्न थाल्छ। कसैले OTV प्रस्ताव गर्छ, किनकि विद्यमान Layer 2 VPN «broadcast गर्दैन»। त्यो निष्कर्ष सामान्यतया हतारको हुन्छ। सेवा श्रेणी र तपाईंले किनेको ठोस सम्झौता दुई फरक प्रश्न हुन्, र समय सीमा नाघ्ने कारण अझै कुनै एउटामा जोडिएको छैन।

तुलना सुरु गर्ने लक्षण

उत्पादन तुलना गर्नु अघि अनुप्रयोगलाई वास्तवमै के चाहिन्छ लेख्नुहोस्। साइटको संख्या, VLAN दायरा, ठेगाना सिकाइ, flooding सहनशीलता र असफलताको व्यवहार आवश्यकता वर्णन गर्छन्। «Layer 2» र «OTV» संरचना वर्णन गर्छन्, र तीमध्ये कुनै पनि आफैंमा आवश्यकता होइन। एउटै पानामा पाँच गुण कुनै पनि विक्रेता तुलनाभन्दा लामो समय टिक्नेछन्।

त्यसपछि हालको सेवाले ती पाँच गुण पहिले नै पूरा गर्छ कि जाँच्नुहोस्। प्रदायकले व्यवस्थापन गर्ने Layer 2 VPN मा multipoint फर्वार्डिङ र नियन्त्रण तहको सिकाइ हुन सक्छ, जसलाई इनभ्वाइसमा एक झलक हेर्दा उल्लेख गरिएको थिएन।

यदि हालको सेवाले ती पूरा गर्छ भने, समय सीमा नाघ्ने अरू कतै छ: MTU समस्या, राउटिङ असमानता, साइटहरूबीच फरक फायरवाल नियम। overlay बदल्दा त्यो कारण यथावत् रहन्थ्यो र एक माइग्रेसन थपिन्थ्यो।

लेबलले तपाईंलाई के भन्दैन

Layer 2 VPN एक श्रेणी हो, उत्पादन होइन। पोइन्ट-टु-पोइन्ट VPWS र multipoint VPLS फरक तरिकाले फर्वार्ड गर्छन्, र श्रेणीमा नियन्त्रण तहको सिकाइ र लूप व्यवस्थापन भएका सेवा तथा सरल सेवा दुवै पर्छन्। प्रत्येक Layer 2 VPN ले ठ्याक्कै दुई साइट जोड्छ र सबै थोक flood गर्छ भन्ने मान्यता गलत तुलना बनाउने तरिका हो। सम्झौतामा लेखिएको नामले त्यसको पछाडिको फर्वार्डिङ तालिकाबारे केही भन्दैन।

हालको सेवाले कुन फर्वार्डिङ मोडेल लागू गर्छ र अनुप्रयोगलाई कुन चाहिन्छ भनी सोध्नुहोस्। hub-and-spoke आवश्यकता र full-mesh आवश्यकता दुवैलाई Layer 2 भनिए पनि फरक डिजाइन दिन्छन्।

OTV ले आफ्नो सीमा कहाँ तान्छ

OTV IP ट्रान्सपोर्टमाथि चल्छ, नियन्त्रण तहको MAC पहुँच र परिभाषित edge भूमिकासहित। स्थानीय spanning-tree जानकारी स्थानीय रहन्छ, ट्रान्सपोर्टभरि एउटै अनियन्त्रित डोमेनका रूपमा विस्तार हुँदैन। यो साधारण ब्रिज गरिएको विस्तारभन्दा वास्तविक फरक हो, र मानिसहरू यसतर्फ फर्कनुको कारण यही हो।

सीमा लाभजत्तिकै महत्त्वपूर्ण छ। अज्ञात unicast, broadcast र multicast को व्यवस्थापन प्लेटफर्म र त्यसको कन्फिगरेसनमा निर्भर हुन्छ, र edge जोडीले समर्थित multihoming संयन्त्रमार्फत सहकार्य गर्नुपर्छ। एउटै VLAN फर्वार्ड गर्ने दुई स्वतन्त्र उपकरण एउटै डिजाइन होइनन्, र तिनले फरक विफलता अवस्था उत्पन्न गर्छन्।

Flooding घट्छ, हट्दैन

केही अनावश्यक flooding दबाउनु कुनै पनि broadcast वा multicast फ्रेम कहिल्यै विस्तार पार गर्दैन भन्ने ग्यारेन्टीजत्तिकै होइन। एउटा साइटमा सुरु भएको आँधीले अझै ट्रान्सपोर्ट खान सक्छ, र एउटा ट्राफिक वर्ग फिल्टर गर्ने प्लेटफर्म सुविधाले अरूलाई फिल्टर गर्दैन। कुनै पनि overlayप्रति हुने अधिकांश निराशा यही फरकबाट आउँछ।

त्यसैले प्रश्न OTV ले broadcast आँधी रोक्छ कि भन्ने होइन। प्रश्न यो हो कि कुन ट्राफिक वर्ग पार हुन्छन्, कुन अवस्थामा, र पार हुँदा गति केले सीमित गर्छ।

त्यहाँ हुँदा underlay पुष्टि गर्नुहोस्: समर्थित डेलिभरी, प्याकेट आकार, राउटिङ र छानिएको रिलिजले चाहिने छिमेकीपन। यीमध्ये केही पनि overlayसँग निःशुल्क आउँदैन, र 1500 बाइट फ्रेम अटाउने टनेल स्वतः तपाईंको ट्याग गरिएका फ्रेम अटाउने टनेल होइन।

लेखित रूपमा माग्नुपर्ने सम्झौता

तपाईंले जुनसुकै सेवा छान्नुभए पनि, त्यही छ उत्तर माग्नुहोस्: पोइन्ट-टु-पोइन्ट वा multipoint दायरा, ग्राहक फ्रेम र ट्यागको व्यवस्थापन, MAC सिकाइ मोडेल, flooding सीमा, पुनःप्राप्ति व्यवहार र छेउदेखि छेउसम्मको अधिकतम फ्रेम आकार। एउटै नामका दुई सेवा ती प्रत्येकमा फरक हुन सक्छन्। उत्तरहरू लेखित रूपमा लिनुहोस्, किनकि सेवा कन्फिगर गर्ने इन्जिनियर प्रश्नको जवाफ दिने व्यक्ति नहुन सक्छन्।

हालको सेवाले स्पष्ट रूपमा पूरा गर्न नसक्ने आवश्यकताका लागि मात्र परिवर्तन छान्नुहोस्। VLAN अझ विस्तार गर्दा अनुप्रयोग र Ethernet का निर्भरताहरू पनि सँगै विस्तार हुन्छन्; नयाँ overlay नामले ती हटाउँदैन।

RFC 4664 ढाँचा ले सेवा श्रेणी र तिनका फर्वार्डिङ मोडेल प्रस्तुत गर्छ, जो सही प्रश्न सोध्न आवश्यक शब्दावली हो। छ उत्तर र असफल परीक्षण एउटै बैठकमा ल्याउनुहोस्, र निर्णय लेबलबारे रहनेछैन।