DMVPN ফেজ 3: উভয় দিকে শর্টকাট পড়া

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

আপনি যা সত্যিই দেখতে পান সেই প্যাকেট পথ দিয়ে শুরু করুন

এমন spoke থেকে শুরু করুন যার গন্তব্য সরাসরি হওয়ার কথা। প্রথম প্যাকেটটি অনুসরণ করুন: এটি hub-এর দিকে spoke-এর রুট অনুসরণ করে, কারণ এখনও কোনো শর্টকাট নেই। hub এটি ফরওয়ার্ড করে এবং ফেজ 3 ডিজাইনে উৎসের কাছে একটি রিডাইরেক্টও পাঠায় যে আরও ভালো পথ আছে।

সেই রিডাইরেক্ট হলো ট্রিগার, প্রমাণ নয়। এটি বলে যে hub এমন ট্রাফিক দেখেছে যা অপ্টিমাইজ করা যায়। এটি বলে না যে উৎস শর্টকাট তৈরি করেছে, গন্তব্য রেজোলিউশনের উত্তর দিয়েছে, বা রিপ্লাই পথ সেটি ব্যবহার করছে।

তাই প্রথম কার্যকর পর্যবেক্ষণ হলো আগে ও পরে: প্রথম ফ্লো hub দিয়ে, পরের ফ্লো সরাসরি।

তিনটি অবস্থা যা একটি টানেলের মতো দেখায়

শর্টকাট তিনটি অবস্থার অংশের উপর নির্ভর করে, আর প্রতিটির নিজস্ব আয়ুষ্কাল ও নিজস্ব কমান্ড আছে।

একটি NHRP ক্যাশ এন্ট্রি একটি overlay ঠিকানাকে NBMA ট্রান্সপোর্ট ঠিকানার সঙ্গে মেলায়। একটি রুট বা শর্টকাট ঠিক করে একটি অভ্যন্তরীণ গন্তব্য কোথায় ফরওয়ার্ড হবে। একটি IPsec অ্যাসোসিয়েশন যে ট্রাফিক তৈরি হয় তা সুরক্ষিত করে। অনুপস্থিত উত্তর তিনটির যেকোনো একটি থেকে আসতে পারে, আর কমান্ডগুলো বলে দেয় কোনটি অনুপস্থিত।

সেই ক্রমেই সেগুলো পড়ুন, কারণ একটি অনুপস্থিত ম্যাপিং বাকি দুটিকে অর্থহীন করে দেয়।

অনুরোধ ও উত্তর আলাদাভাবে হেঁটে দেখুন

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

এখন ভূমিকা উল্টে দিন। B থেকে A-তে পাঠান এবং একই তিনটি পাঠ পুনরাবৃত্তি করুন। যে ডিজাইন এক দিকে শর্টকাট করে আর অন্য দিকে করে না, সেটি প্রতিসম নয়, আর অসমতা সাধারণত এক পাশে অনুপস্থিত প্রিফিক্স বা এমন রেজোলিউশন থেকে আসে যা কখনও উত্তর পায়নি।

অনুরোধ hub দিয়ে গেছে বলেই পিয়ারের উত্তরকে hub পেরোতে হবে না। এটি ভুল পড়বেন না এবং এমন রাউটিং ত্রুটির পেছনে ছুটবেন না যা নেই।

hub-এর রিডাইরেক্ট পড়ুন, শুধু তার রুট নয়

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

ফেজ 3 সারসংক্ষেপের অর্থও বদলে দেয়। শর্টকাট আচরণে spokes-এর ফেজ 2 ডিজাইনে প্রত্যাশিত নির্দিষ্ট দূরবর্তী রুটের সম্পূর্ণ সেট দরকার হয় না, তাই spoke-এ সারসংক্ষিপ্ত রুট স্বয়ংক্রিয়ভাবে অনুপস্থিত নেটওয়ার্ক নয়। সারসংক্ষেপকে ত্রুটি হিসেবে পড়ার আগে ফেজ ও রাউটিং নীতি নিশ্চিত করুন।

এই একটি ভুল বোঝাবুঝি অন্য যেকোনো কিছুর চেয়ে বেশি DMVPN টিকিট তৈরি করে।

সিদ্ধান্তটি অনুপস্থিত বস্তু হিসেবে লিখে রাখুন

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

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

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