সাইটের ভেতরে একই iESI, সাইটের মধ্যে স্বতন্ত্র: Junos সংযোগ

দুই জোড়া গেটওয়ে দুইটি ডেটা সেন্টার পরিবেশন করে, এবং ডিজাইনের কতগুলো interconnect ESI মান দরকার তা কাউকে সিদ্ধান্ত নিতে হবে। উত্তর হলো প্রতি গেটওয়ে গ্রুপে একটি, প্রতি fabric-এ একটি নয় এবং প্রতি গেটওয়েতে একটি নয়। এটি ভুল করলে এমন fabric তৈরি হয় যা কনফিগার করা দেখায় এবং ভুল forwarder নির্বাচন করে, অথবা দুটি সাইটকে একত্র করে যা আলাদা থাকার কথা ছিল। নিয়মটি এবং তার ব্যতিক্রমগুলো গেটওয়ে তালিকার পাশে লিখে রাখার যোগ্য।

দুই পরিধি, দুই নিয়ম

সাইটের ভেতরে, অপ্রধান interconnect গেটওয়েগুলো একটি multihomed প্রান্তবিন্দু হিসেবে কাজ করে, তাই তারা একটি interconnect ESI ভাগ করে। তাদের peer-দের দুইটি স্বতন্ত্র সদস্যের বদলে একটি যৌক্তিক সদস্য দেখতে হবে। ভাগ করা মানের পুরো অর্থ এটাই।

সাইটের মধ্যে, প্রতিটি গেটওয়ে গ্রুপ নিজের মান পায়। যে দুইটি ডেটা সেন্টার একটি শনাক্তকারী ভাগ করে তারা কন্ট্রোল প্লেনে একটি multihomed গ্রুপে পরিণত হয়, যা WAN জুড়ে stitching ডিজাইন সাধারণত বোঝায় না। একটি গ্রুপের দুইটি সাইট একে অপরের ব্যর্থতার ধরনও উত্তরাধিকারে পায়।

সাইটের ভেতরে: গ্রুপের জন্য একটি পরিচয়

জোড়াকে দুই peer-এ একই মান দিন, একই সেবা প্রসঙ্গে, এবং তা চ্যাট থ্রেডে নয়, নেটওয়ার্কের শনাক্তকারী ইনভেন্টরিতে লিপিবদ্ধ করুন। দুই সদস্যের মধ্যে অমিল হলো সেই ব্যর্থতার ধরন যা এক সদস্যের গ্রুপ এবং কোনো স্পষ্ট অ্যালার্ম তৈরি করে। কাজ করা সেশন বিশ্বাস করার আগে দুই সদস্যকে তুলনা করুন।

সমর্থিত মডেল হলো all-active। একই রেফারেন্স এই stitching পরিচয়ের জন্য single-active পরিচালনা, স্বয়ংক্রিয়ভাবে উদ্ভূত LACP শনাক্তকারী এবং source-bmac অপশন বাদ দেয়, তাই এর একটি ধরে নেওয়া ডিজাইন শনাক্তকারী বাছাই করার আগেই পুনর্বিবেচনা দরকার। এই সীমাবদ্ধতা ডিজাইনের ইনপুট, পাদটীকা নয়।

সাইটের মধ্যে: ভিন্ন মান, অথবা ইচ্ছাকৃত একীকরণ

প্রতি সাইটে অনন্য মান দুই গেটওয়ে গ্রুপকে আলাদা রাখে। যদি উদ্দেশ্য সত্যিই একটি multihomed গ্রুপ সাইট জুড়ে প্রসারিত করা হয়, তবে তা ভিন্ন স্থাপত্য যার নিজস্ব বিলম্ব, ব্যর্থতা ও ফরওয়ার্ডিং পরিণতি আছে, এবং এটি শনাক্তকারীর পছন্দ হিসেবে নয়, স্থাপত্য হিসেবে সিদ্ধান্ত হওয়া উচিত। রক্ষণাবেক্ষণ উইন্ডোর আগে সেই সিদ্ধান্ত লিখিতভাবে চান।

উদ্দেশ্য অনুযায়ী পার্থক্যটি পরিকল্পনায় লিখুন, যাতে পরে কাজ করা সাইট টেমপ্লেট কপি করা প্রকৌশলী তার শনাক্তকারীও সাথে না নেন।

peer বিবৃতিটি পরিচয়ের অংশ

গ্রুপের প্রতিটি গেটওয়ে loopback ঠিকানা দিয়ে তার স্থানীয় peer-দের তালিকা করে, এবং সেই সম্পর্কটি পৃথক 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 পরিবর্তন হিসেবে, যা তা-ই, পর্যালোচনা করা যাবে। ফলাফলই একমাত্র প্রমাণ যে শনাক্তকারী নকশায় যা বলা আছে তা করে।