DMVPN WAN ফেলওভার: রুট পলিসি নাকি টানেল বন্ধ করা?

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

সিদ্ধান্ত আসে কনফিগের আগে

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

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

উত্তরটি লিখে রাখুন, কারণ কনফিগটাই সহজ অংশ।

রুট পলিসি আসলে কী বদলায়

পলিসি-ভিত্তিক রাউটিংয়ে একটি ট্র্যাক করা অবজেক্ট পরবর্তী হপ নিয়ন্ত্রণ করতে পারে। রুট-ম্যাপ এন্ট্রি একটি প্রার্থী পরবর্তী হপ এবং সেটি ব্যবহারের জন্য চালু থাকতে হবে এমন ট্র্যাক করা অবজেক্টের নাম দেয়, আর সেই ট্র্যাকিং অবস্থা আসে IP SLA প্রোব থেকে। অবজেক্টটি নেমে গেলে এন্ট্রি মেলানো বন্ধ করে এবং প্যাকেটটি পরের এন্ট্রি বা সাধারণ রাউটিং টেবিল দিয়ে মূল্যায়িত হয়।

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

সিনট্যাক্স প্ল্যাটফর্ম ও রিলিজভেদে আলাদা, তাই আপনি আসলে যে সংস্করণ চালান তার গাইড দেখুন।

টানেল বন্ধ করলে কী বদলায়

ইন্টারফেস বন্ধ করা প্রশাসনিক অবস্থা বদলায়। এর উপর নির্ভর করা প্রতিটি টানেল, রুট ও সেশন একসঙ্গেই নেমে যায়, যা ঠিক তখনই চান যখন টানেলটিকেই হারিয়ে যেতে হবে। EEM অ্যাপলেটও এভাবেই একটি WAN সমস্যাকে অসম্পর্কিত সেবা-সহ বিভ্রাটে পরিণত করে।

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

হার্ডকোড করা পুনরুদ্ধার কমান্ড অন্য কেউ করা রক্ষণাবেক্ষণ-বন্ধকেও অগ্রাহ্য করতে পারে।

প্রোবকে আপনার ভাবা পথেই চলতে দিন

যে প্রোব বর্তমান সেরা রুট অনুসরণ করে, সে বাকি সবকিছুর সঙ্গে ব্যাকআপ WAN-এ চলে যায় এবং তারপর প্রাথমিকটিকে সুস্থ বলে জানায়, কারণ সে আর এটি ব্যবহার করছে না।

প্রোবটিকে আপনি যে পথ পরীক্ষা করছেন তার ইন্টারফেস বা সোর্স ঠিকানায় পিন করুন। এটি কী লক্ষ্য করে তাও যাচাই করুন, কারণ ISP-র পরবর্তী হপে পৌঁছানো টানেলটি যে সেবার জন্য বিদ্যমান তাতে পৌঁছানোর চেয়ে কম প্রমাণ করে। আপ ও ডাউন বিলম্ব সচেতনভাবে ঠিক করুন: ছোট ডাউন বিলম্ব দ্রুত প্রতিক্রিয়া দেয় ও ফ্ল্যাপ করে, আর দীর্ঘটি ক্ষণিক ঝাঁকুনি কাটিয়ে যায় ও আসল ব্যর্থতা ঢেকে দেয়। Cisco-র IOS XE ট্র্যাকিং ও পলিসি-রাউটিং গাইড সমর্থিত সমন্বয়গুলো নথিভুক্ত করে, আর আপনার প্ল্যাটফর্মের ফিচার সেট ঠিক করে দেয় এর কোনগুলো আপনি ব্যবহার করতে পারবেন।

দুটি বিলম্বের মানই ট্র্যাক করা অবজেক্টের পাশে লিখে রাখুন, নইলে কেন এটি এমন আচরণ করল কেউ জানবে না।

পুনরুদ্ধারের সিদ্ধান্ত নিন, তারপর যাচাই করুন

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

ফেলওভার কাজ করলেও অ্যাপ্লিকেশন যদি ভাঙতেই থাকে, সমস্যাটি রাউটিং স্তরের উপরে এবং কোনো পরিমাণ ট্র্যাকিংই তা ঠিক করবে না।

ওই জানালার প্রমাণ সংরক্ষণ করুন, কারণ পরের পরিবর্তন এর সঙ্গে তুলনা করা হবে।