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 ढाँचा सेवा श्रेणियाँ और उनके फ़ॉरवर्डिंग मॉडल बताता है, जो सही सवाल पूछने के लिए ज़रूरी शब्दावली है। छह जवाब और असफल परीक्षण एक ही बैठक में लाएँ, और निर्णय लेबल के बारे में नहीं रहेगा।