BGP সেশন চালু, গ্রাহকের পথ ভাঙা: DMVPN-এর উপর MPLS

পিয়ারিং সপ্তাহ ধরে চালু, প্রিফিক্সের গণনা ঠিক দেখাচ্ছে, তবুও একজন গ্রাহকের ট্র্যাফিক এখনও দীর্ঘ পথে ঘুরছে বা পৌঁছাচ্ছেই না। একই সূচক দিয়ে দুটি ভিন্ন বিষয়ের বিচার হচ্ছে। একটি BGP সেশন জানায় যে দুই পিয়ার TCP সংযোগের উপর দিয়ে বার্তা বিনিময় করতে পারে; ওভারলে ওই নির্দিষ্ট গ্রাহকের জন্য লেবেলযুক্ত প্যাকেট বহন করতে পারবে কি না, সে বিষয়ে এটি কিছুই বলে না।

এই ফাঁকটি MPLS-ওভার-DMVPN নকশায় সবচেয়ে সহজে চোখে পড়ে, যেখানে হাব পথ ও সরাসরি স্পোক পথ পিয়ারিংয়ের সাথে সম্পর্কহীন কারণেই ভিন্নভাবে আচরণ করতে পারে।

সেশনটি আসলে কী প্রমাণ করে

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

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

চারটি প্রক্রিয়া, একটি নয়

MPLS-ওভার-DMVPN নিয়ে Cisco-র নথি অংশগুলো পরিষ্কারভাবে আলাদা করে। MP-BGP প্রোভাইডার এজ ডিভাইসগুলোর মধ্যে গ্রাহক ওভারলে লেবেল বিতরণ করে। MPLS সেই লেবেল ব্যবহার করে প্যাকেটের ফরওয়ার্ডিং প্রসঙ্গ নির্বাচন করে। NHRP একটি ওভারলে ঠিকানাকে সেই ট্রান্সপোর্ট প্রান্তের সাথে ম্যাপ করে যা ডাইনামিক টানেলের দরকার। IPsec যেখানে প্রযোজ্য সেখানে পিয়ার পথ রক্ষা করে।

চারটির যেকোনোটি ঠিক থাকতে পারে আর অন্যটি ভুল, এবং এই সমন্বয়ই ট্র্যাফিক বহন করে। রুট বিনিময় সম্পূর্ণ হতে পারে অথচ একটি VRF-এর লেবেল বাইন্ডিং অনুপস্থিত, অথবা NHRP ম্যাপিং পুরোনো ট্রান্সপোর্ট ঠিকানায় নির্দেশ করছে, অথবা টানেল আছে কিন্তু কোনো পলিসি ভেতরের প্যাকেট অনুমোদন করে না। এই অবস্থাগুলোর কোনোটিই সেশন নামিয়ে দেয় না।

হাব পথের সাথে শর্টকাট পথ তুলনা করুন, একবারে একটি চলক

উৎস হোস্ট, গন্তব্য হোস্ট ও VRF স্থির রাখুন, তারপর একই প্রবাহ দুইবার অনুসরণ করুন। হাব পথে পরবর্তী হপ, দূরবর্তী গ্রাহক প্রসঙ্গ চিহ্নিত করা সার্ভিস লেবেল, এবং ব্যবহৃত ওভারলে-থেকে-ট্রান্সপোর্ট ম্যাপিং লিখুন। অভীষ্ট সরাসরি পথেও একই তিনটি জিনিস লিখুন। দুই তালিকার পার্থক্যই ত্রুটি, অথবা ত্রুটির অনুপস্থিতি।

তুলনার সময় প্রবাহ অপরিবর্তিত রাখুন। পর্যবেক্ষণের মাঝে উৎস হোস্ট, VRF বা গন্তব্য বদলালে দুটি সম্পর্কহীন কাহিনি তৈরি হয়, আর এই অনুশীলনটি ভুল হওয়ার সবচেয়ে সাধারণ উপায় সেটিই।

লুপব্যাক পরীক্ষা আলাদা কুঠুরিতে রাখুন

রাউটারের লুপব্যাক থেকে পাঠানো পিং একটি উপকারী পরীক্ষা, এবং এটি হোস্ট প্রবাহের চেয়ে ভিন্ন একটি ক্ষেত্র যাচাই করে। উৎস ঠিকানাটি রাউটারের নিজের, এর রাউটিং প্রসঙ্গ VRF-এর বদলে গ্লোবাল হতে পারে, এবং উত্তরের পথ গ্রাহক প্রিফিক্স যে পথে যেত তার থেকে আলাদা হতে পারে। তাই লুপব্যাক উত্তর দিচ্ছে এবং এই অ্যাপ্লিকেশনটি শর্টকাট দিয়ে চলছে এই দুটি পৃথক ফলাফল, এবং কেবল দ্বিতীয়টিই গ্রাহককে বর্ণনা করে।

দুটিই পরীক্ষা করুন, তারপর নোটে আলাদাভাবে চিহ্নিত করুন। যখন তারা মিলে না, তখন নকশাটি কোথায় সরে যায় সে সম্পর্কে নির্দিষ্ট কিছু জানলেন, যা একটি সবুজ টিক চিহ্ন কখনও বলতে পারবে না।

সংস্করণ-দাবি ও ত্রুটি-দাবির নিজস্ব প্রমাণ দরকার

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

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