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 चौकट सेवा श्रेणी आणि त्यांची फॉरवर्डिंग मॉडेल मांडते, जी योग्य प्रश्न विचारण्यासाठी आवश्यक शब्दसंग्रह आहे. सहा उत्तरे आणि अयशस्वी चाचणी एकाच बैठकीत आणा, आणि निर्णय लेबलांबद्दल राहणार नाही.