OSPF সর্বোচ্চ মেট্রিক: শাখাটি না সরিয়ে শাখা ট্রানজিট নিরুৎসাহিত করা

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

আপনি চান একটি পছন্দ, রাউটিং প্রোটোকলে প্রকাশ করা, যা শাখাটিকে সম্পূর্ণ পৌঁছানোযোগ্য রাখে এবং এর মধ্য দিয়ে যাওয়া যেকোনো কিছুর জন্য এটিকে দুর্বল পছন্দ করে তোলে। রাউটারগুলি যে ক্রমে সমস্যাটি দেখে সেই ক্রমেই হাঁটুন।

যে পথটি এড়াতে চান, সেখান থেকেই শুরু করুন

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

তারপর বিকল্প পথটি খুঁজুন। অফিস দুটির মধ্যে যদি একমাত্র রুট শাখার মধ্য দিয়ে যায়, তবে কোনও মেট্রিক ট্রাফিককে সেখান থেকে সরাতে পারবে না, কারণ ট্রাফিকের যাওয়ার জায়গা নেই। অতিরিক্ততা এই নকশার একটি খুঁটিনাটি নয়; এটি পূর্বশর্ত। কাগজে-কলমে থাকা দ্বিতীয় পথ গণ্য হয় না।

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

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

সর্বোচ্চ মেট্রিক কী ঘোষণা করে

RFC 6987 এমন একটি রাউটার বর্ণনা করে যা তার নন-স্টাব লিঙ্কগুলি সর্বোচ্চ লিঙ্ক মেট্রিক দিয়ে ঘোষণা করে, যা 0xffff হিসেবে সংজ্ঞায়িত। রাউটারটি এখনও নিজেকে ও নিজের লিঙ্কগুলিকে বর্ণনা করে; শুধু সেগুলিকে পরিসরের শীর্ষে দাম দেয়, তাই অন্য প্রতিটি রাউটার এর মধ্য দিয়ে যাওয়া পথকে ব্যয়বহুল হিসাবে গণনা করে।

এটি router-LSA পরিবর্তন, টপোলজি অপসারণ নয়। পার্থক্যটি গুরুত্বপূর্ণ: router-LSA ফ্লাশ করা টপোলজি তথ্যটিকেই প্রত্যাহার করে, যা রাউটার ও তার পিছনের প্রিফিক্সে পৌঁছানোর জন্য প্রয়োজনীয় সম্পর্কগুলিও প্রত্যাহার করতে পারে। বিজ্ঞাপনটি রেখে তার দাম বাড়ানো সেই সম্পর্কগুলি সংরক্ষণ করে। এই কৌশল ও অপসারণের মধ্যে পুরো পার্থক্য এটাই।

RFC 6987 প্রক্রিয়াটির এলাকার ধরন বা মনোনীত-রাউটার নির্বাচনের সঙ্গেও কোনও সম্পর্ক নেই। একটি স্টাব এলাকা এলাকার সীমানায় লিঙ্ক-স্টেট বিজ্ঞাপনের একটি শ্রেণি ব্লক করে, আর একটি স্টাব রাউটার নিজের লিঙ্কগুলির দাম নির্ধারণ করে। একই রকম শব্দ, অসংযুক্ত যন্ত্রকৌশল।

কেন পৌঁছানোযোগ্যতা টেকে, কিন্তু ট্রানজিট টেকে না

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

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

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

শেষ-পথের সমস্যা

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

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

শর্তটি যদি পছন্দ নয় বরং কঠোর নিষেধ হয়, তবে শুধু মেট্রিক নকশা তা দেবে না। আপনার দরকার অভিপ্রায়ের সঙ্গে মেলে এমন ফরওয়ার্ডিং বলবৎকরণ, সাথে ট্রাফিক যখন-তখন পৌঁছে যাওয়ার ক্ষেত্রের জন্য নির্ধারিত আচরণ। একটি পথকে ব্যবহারযোগ্য বলে ঘোষণা করে তারপর ট্রাফিক ফেলে দেওয়া একটি ব্ল্যাক হোল তৈরি করে, যার রোগনির্ণয় রাউটিং লুপের চেয়েও কঠিন।

OSPFv3-এর জন্য RFC R-বিটকে ট্রানজিট অংশগ্রহণ বাদ দেওয়ার ভিন্ন উপায় হিসেবে আলোচনা করে। ধরে নেবেন না যে এটি সর্বোচ্চ-মেট্রিক কৌশলের মতো একই শেষ-পথ আচরণ উত্তরাধিকারে পায়, এবং দুটি ঠিকানা পরিবারের মধ্যে সেটিংস কপি করবেন না যেন তারা একই বৈশিষ্ট্য।

স্বাভাবিক ও ব্যর্থ অবস্থায় এটি প্রমাণ করুন

দুবার পরীক্ষা করুন: একবার দুটি পথই উপলব্ধ থাকলে এবং একবার পছন্দের পথটি সরিয়ে। প্রথম পরীক্ষা দেখায় পছন্দটি কাজ করছে, আর দ্বিতীয়টি দেখায় পছন্দ রক্ষা করা না গেলে নেটওয়ার্ক কী করে। দ্বিতীয় পরীক্ষাটি বাদ দিলে গুরুত্বপূর্ণ অর্ধেকটি অপরীক্ষিত থেকে যায়।

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

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

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