EIGRP প্রতিবেশী নাকি DMVPN ট্রানজিট? আগে ভূমিকা যাচাই করুন

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

ধাপ 1: দুটি ভূমিকা আঁকুন

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

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

ধাপ 2: মাঝের ডিভাইস কী টার্মিনেট করে দেখুন

যদি মাঝের রাউটারই টানেল টার্মিনেট করে এবং spoke-দের সঙ্গে EIGRP সংলগ্নতা গড়ার কথা থাকে, তবে উত্তর সম্পূর্ণ বদলে যায়। ওই ডিভাইসের সমর্থিত overlay রাউটিং আচরণ দরকার, আর তাকে ট্রানজিট বললেও প্রতিবেশীর শর্ত মুছে যায় না। রাউটিং কনফিগারেশনের আগে টানেল কনফিগারেশন পড়ুন। ওই উত্তরই পরের প্রতিটি পরীক্ষা নির্ধারণ করে।

তাহলে প্রথম আসল প্রশ্ন কোন প্রোটোকল টিউন করবেন তা নয়। প্রশ্ন হলো বক্সটি hub, spoke, নিছক underlay হপ, নাকি এমন Layer 2 সার্ভিস যা প্রান্তবিন্দুর মধ্যে ফ্রেম বহন করে।

ধাপ 3: প্রতিবেশীর কন্ট্রোল প্লেন যাচাই করুন

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

RFC 7868 EIGRP-কে মাল্টিকাস্ট কন্ট্রোল বিনিময়সহ একটি IP প্রোটোকল হিসেবে বর্ণনা করে, তাই প্রতিবেশী সম্পর্ক এমন কিছু নয় যা কোনো মধ্যবর্তী রাউটার প্যাকেট গন্তব্যের দিকে রাউট করে প্রক্সি করতে পারে। হয় কন্ট্রোল বিনিময় পিয়ারে পৌঁছায়, নয় সংলগ্নতা তৈরি হয় না।

ধাপ 4: ট্রান্সপোর্ট কন্ট্রোল বিনিময় পৌঁছাচ্ছে কি না যাচাই করুন

এরপর, overlay সত্যিই কি ইচ্ছাকৃত প্রান্তবিন্দুর মধ্যে কন্ট্রোল ট্রাফিক বহন করছে তা যাচাই করুন. পিয়ারের NHRP ম্যাপিং ও তাতে পৌঁছানো বাইরের রুট দেখুন, তারপর টানেল ইন্টারফেস আপ আছে ও ট্রাফিক পার করছে কি না নিশ্চিত করুন। সফল underlay ping প্রমাণ করে বাইরের পথ আছে; এটি প্রমাণ করে না যে overlay কন্ট্রোল বিনিময় পৌঁছেছে।

স্বচ্ছ Layer 2 সার্ভিস, পয়েন্ট-টু-পয়েন্ট টানেল ও মাল্টিপয়েন্ট DMVPN ক্লাউড মাল্টিকাস্ট আলাদাভাবে পৌঁছায়। তিনটিই একই আচরণ করে ধরে নেওয়ার বদলে যে মডেলটি সত্যিই মোতায়েন হয়েছে তার সমর্থিত ইন্টারফেস, NHRP ও মাল্টিকাস্ট মডেল অনুসরণ করুন।

ধাপ 5: অংশ নিতে না পারলে সীমানাটি পুনরায় নকশা করুন

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

চিত্রে প্রতিটি ডিভাইসের ভূমিকা লিখে রাখুন এবং তা কনফিগারেশনের সঙ্গে সংরক্ষণ করুন। RFC 7868-এ প্রোটোকল বিনিময়ের সংজ্ঞাই সেই ভিত্তি যে কেন ট্রানজিট ফরওয়ার্ডিং দিয়ে প্রতিবেশী সম্পর্ক অনুকরণ করা যায় না।

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