নামযুক্ত বনাম সংখ্যাযুক্ত DMVPN হাব: FQDN কী বদলায়

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

দুটি ঠিকানা, দুটি কাজ

একটি ঘোষিত উদাহরণে hub.example.net স্পোককে বলে ট্রান্সপোর্ট ট্রাফিক কোথায় পাঠাতে হবে, এবং 10.90.0.1 টানেলের ভিতরের NHS চিহ্নিত করে। ডিসকভারি প্রথমটির ওপর কাজ করে; রেজিস্ট্রেশন ও রাউটিং দ্বিতীয়টির ওপর। নামের পরিবর্তন এন্ডপয়েন্টের পথে প্রভাব ফেলে, আর প্রোটোকল ঠিকানার পরিবর্তন ওভারল সম্পর্কটিকেই প্রভাবিত করে।

ভূমিকাগুলো আলাদা রাখাই নামযুক্ত ফর্মটিকে ডিবাগযোগ্য করে তোলে। কোনো স্পোক রেজিস্ট্রেশন করতে ব্যর্থ হলে আপনি দুটি ভিন্ন প্রশ্ন করতে পারেন: নামটি কি আমার প্রত্যাশিত ঠিকানায় রিজলভ হয়েছে, এবং সেই ঠিকানা কি কনফিগারেশনের দাবি করা প্রোটোকল ঠিকানার সঙ্গে মিলেছে? কোনো উত্তরই অন্যটিকে বোঝায় না।

দুটি কনফিগারেশন ফর্ম তুলনা করুন

একটি ফর্ম নামের পাশাপাশি NHS প্রোটোকল ঠিকানা স্পষ্টভাবে কনফিগার করে। অন্যটি স্পোককে রেজিস্ট্রেশন উত্তরের থেকে সেই প্রোটোকল ঠিকানা শিখতে দেয়। দুটিই নথিভুক্ত, এবং সফল হলে দুটিই একই ধরনের NHS সম্পর্কে শেষ হয়।

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

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

স্থির হাবের সঙ্গে DNS ক্যাশ তুলনা করুন

কেউ কনফিগারেশন সম্পাদনা করলে স্থির হাব ঠিকানা বদলায়। নামযুক্ত হাব বদলায় যখন DNS বদলায়, এবং DNS উত্তরগুলো তাদের আয়ুষ্কাল পর্যন্ত ক্যাশে থাকে। নথিতে বলা হয় ক্যাশে করা তথ্য মেয়াদ শেষ হওয়া পর্যন্ত ব্যবহারযোগ্য থাকে, এবং পরবর্তী কোয়েরি তখন নতুন ঠিকানা ফিরিয়ে দিতে পারে।

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

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

কী একই থাকে তা তুলনা করুন

পিয়ার প্রমাণীকরণ নড়ে না। ট্রান্সপোর্ট এন্ডপয়েন্ট খোঁজা হোস্টনাম কনফিগার করা IKE পরিচয় বা পিয়ার যাচাই করা প্রমাণীকরণ নীতিকে প্রতিস্থাপন করে না। পরিচয় ভুল হলে সফল DNS রিজলিউশন আপনাকে কেবল প্রত্যাখ্যাত টানেলে দ্রুততর পৌঁছে দেয়।

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

একটি তুলনা যা আপনি যাচাই করতে পারেন

Cisco সেশন ও NHS সম্পর্কের জন্য আলাদা পর্যবেক্ষণ নথিভুক্ত করে। পিয়ার ও সেশন অবস্থা পড়তে show dmvpn ব্যবহার করুন, আর NHS রেজিস্ট্রেশন ভিউ পড়তে show ip nhrp nhs ব্যবহার করুন। রিজলভড ট্রান্সপোর্ট ঠিকানা, ওভারলে পিয়ার ও রেজিস্ট্রেশন অবস্থা সেই ক্রমে তুলনা করুন।

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