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 framework সেবার শ্রেণি ও তাদের ফরওয়ার্ডিং মডেল ব্যাখ্যা করে, যা সঠিক প্রশ্ন করার জন্য প্রয়োজনীয় শব্দভাণ্ডার। ছয়টি উত্তর ও ব্যর্থ পরীক্ষাটি একই সভায় নিয়ে আসুন, আর সিদ্ধান্তটি লেবেল নিয়ে থাকবে না।