VPN জুড়ে PIM-SM: BSR, RP ম্যাপিং ও RPF পথ যাচাই

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

টানেল নয়, রিসিভার দিয়ে শুরু করুন

যে রিসিভার কখনো গ্রুপটি চায়নি, সে কোনো রাউটারে অবস্থা তৈরি করে না, তাই অন্য কিছু দেখার আগে যাচাই করুন যে রিসিভারের দিকের সেগমেন্টে জয়েনটি বিদ্যমান। Cisco-ধাঁচের প্ল্যাটফর্মে লাস্ট-হপ রাউটারে show ip igmp groups যে ইন্টারফেস গ্রুপগুলো শুনেছে তার পাশে জয়েন করা গ্রুপগুলো ছাপে। যখন ওই আউটপুটে গ্রুপটি নেই, তখন টানেল একটি বিভ্রান্তি: অনুরোধটি অ্যাক্সেস সুইচে, হোস্ট সকেটে বা querier-বিহীন কোনো VLAN-এ মারা গেছে।

আমি যেসব অনুপস্থিত জয়েন দেখেছি তার অধিকাংশের কারণ দুটি সাধারণ ব্যাপার: হোস্ট ও রাউটারের মধ্যে IGMP সংস্করণের অমিল, এবং এমন সুইচে পড়া querier নির্বাচন যা রাউটিং করে না। তৃতীয়টি আরও সূক্ষ্ম: গ্রুপে জয়েন হয়েছে কিন্তু ভুল VLAN-এ, কারণ হোস্টে দুটি নেটওয়ার্ক কার্ড আর অ্যাপ্লিকেশনটি ভুল কার্ডে বাঁধা পড়েছে। IPv6 রিসিভারদের MLD নিয়ে সমতুল্য সমস্যা হয়, যেখানে show ipv6 mld groups একই প্রশ্নের উত্তর দেয়। এগুলোর কোনোটিই টানেলে হাত দিয়ে ঠিক হয় না, আর ঠিক এ কারণেই ক্রমটি গুরুত্বপূর্ণ।

জয়েনটি দৃশ্যমান হওয়ার পর যাচাই করুন যে রিসিভারের দিকের ইন্টারফেস এবং rendezvous point-এর দিকে যাওয়া ইন্টারফেস—দুটিতেই PIM সক্রিয়। IGMP সদস্যপদ আছে কিন্তু আপস্ট্রিম ইন্টারফেসে PIM নেই এমন রাউটার গ্রুপটি স্থানীয় টেবিলে ধরে রাখবে এবং কোথাও কিছু পাঠাবে না।

BSR সেটটি কি অপর প্রান্তে পৌঁছায়?

Bootstrap Router বার্তাগুলো একটি PIM ডোমেইনের ভেতরে হপ ধরে হপ এগোয়, আর টানেল জুড়ে ভাঙে ঠিক এই দিকটিই। প্রার্থী RP-রা তাদের বিজ্ঞাপন নির্বাচিত BSR-এ ইউনিকাস্টে পাঠায়, তাই RP থেকে BSR পর্যন্ত অংশ চালু টানেলে সাধারণত অপরিবর্তিত থাকে। বিপরীত দিকে Bootstrap বার্তার প্রবাহ নির্ভর করে প্রতিটি মধ্যবর্তী ইন্টারফেসে PIM সক্রিয় থাকা এবং কোনো কিছু সীমান্তে বার্তাগুলো না থামানোর উপর। RFC 5059 সেই বিতরণ এবং প্রশাসনিক পরিধির সীমানা নির্ধারণ করে, যা এটি কেটে ফেলতে পারে।

ip pim bsr-border বিবৃতি, প্রোটোকল 103 ফিল্টার করা একটি ACL, বা মাল্টিকাস্ট বহন করতে অক্ষম নীতি-ভিত্তিক IPsec টানেল—প্রত্যেকটিই প্রবাহ কেটে দেবে অথচ ইউনিকাস্ট অক্ষত থাকবে। এই সমন্বয়ই ব্যর্থতাকে RP-এর সমস্যা দেখায় যখন আসলে এটি পৌঁছানোর সমস্যা, আর এ কারণেই আমি RP কনফিগারেশনের আগে BSR অবস্থা পড়ি।

অপর প্রান্তের রাউটারে show ip pim bsr-router নির্বাচিত BSR এবং শেখা RP সেটের নাম দেয়; আউটপুট খালি হলে অপর প্রান্ত নিজের ডোমেইনে বসে থাকে এবং কোনো RP কনফিগারেশনই দুটিকে মিলিয়ে দেবে না। টানেলের দুই পাশে show ip pim rp mapping-এ গ্রুপ রেঞ্জ ও RP ঠিকানা তুলনা করুন। যে ম্যাপিং কেবল স্থানীয়ভাবে আছে তা ভুল জায়গায় শেষ হওয়া একটি শেয়ার্ড ট্রি তৈরি করে, আর রিসিভার চিরকাল অপেক্ষা করে।

টানেলের দুই পাশে RP ম্যাপিং মিলিয়ে নিন

স্ট্যাটিক RP, BSR ও anycast-RP একই প্রশ্নের তিনটি উত্তর, আর টানেল জুড়ে এগুলো মেশানো এমন একটি ডোমেইন বানানোর নির্ভরযোগ্য উপায় যা কখনো একত্র হয় না। যদি হেড এন্ড BSR ব্যবহার করে আর ব্র্যাঞ্চ ভিন্ন ঠিকানায় নির্দেশ করা একটি স্ট্যাটিক ip pim rp-address ব্যবহার করে, ব্র্যাঞ্চ তার শেয়ার্ড ট্রি এমন RP-এর দিকে গড়ে তোলে যে জানে না রিসিভারটি আছে। ম্যাপিংকে গ্রুপ রেঞ্জ ও ঠিকানা—দুটিতেই মিলতে হবে, কারণ বেশি নির্দিষ্ট রেঞ্জ বিস্তৃত রেঞ্জের উপর জেতে।

Anycast-RP আছে ঠিক এই জন্য যে দুটি সাইট একটি RP ঠিকানা ভাগ করতে পারে, আর এখানে এর নাম নেওয়া দরকার কারণ এটি বদলে দেয় “একই RP” বলতে কী বোঝায়। একটি ঠিকানা বিজ্ঞাপন করা দুটি RP নকশা অনুযায়ীই সামঞ্জস্যপূর্ণ; একই রেঞ্জের জন্য ভিন্ন ভিন্ন ঠিকানা বিজ্ঞাপন করা দুটি RP নয়, প্রতিটি সাইট নিজে যতই সুস্থ দেখাক।

232.0.0.0/8-এর ভেতরে সোর্স-নির্দিষ্ট মাল্টিকাস্টের জন্য RP-কে কখনো জিজ্ঞাসা করা হয় না, তাই ফাঁকা RP ম্যাপিং স্বয়ংক্রিয়ভাবে ত্রুটি নয়। যে RP কখনো দরকার হয়নি তার পেছনে ছোটার আগে ঠিক করুন অ্যাপ্লিকেশনটি কোন সার্ভিস মডেল ব্যবহার করে।

উৎসের দিকে RPF লুকআপ পড়ুন

PIM ইউনিকাস্ট পথ উল্টে দিয়ে ট্রি গড়ে, তাই আসল যাচাই হলো উৎসের দিকে ফেরার রুট, বা শেয়ার্ড ট্রির ক্ষেত্রে RP-এর দিকে ফেরার রুট। যে জয়েন এমন ইন্টারফেসে আসে যা রাউটার আপস্ট্রিম মনে করে না, তা বাদ পড়ে, আর কারণটি টানেল ব্যর্থতা নয়, RPF ব্যর্থতা হিসেবে লগ হয়। টানেলের উপর ডিফল্ট রুট আর WAN-এর উপর বেশি নির্দিষ্ট রুট থাকা ব্র্যাঞ্চ রাউটারে RPF ইন্টারফেস সহজেই WAN হতে পারে, যদিও উৎস কেবল টানেল দিয়েই পৌঁছায়। জয়েন নিঃশব্দে বাদ পড়ার এটাই একক সর্বাধিক সাধারণ কারণ।

show ip rpf 192.0.2.10 নির্বাচিত ইন্টারফেস, পরের হপ এবং যে রুট সিদ্ধান্তটি তৈরি করেছে তা ছাপে, আর সাধারণত অমিলটি দেখার জন্য এটাই যথেষ্ট। ip mroute 192.0.2.0 255.255.255.0 tunnel0-এর মতো স্ট্যাটিক মাল্টিকাস্ট রুট ওই প্রিফিক্সের জন্য ইউনিকাস্ট লুকআপকে অতিক্রম করে, এবং যখন মাল্টিকাস্ট টপোলজি সত্যিই ইউনিকাস্ট টপোলজি থেকে আলাদা তখন এটি বৈধ সমাধান। এটিকে নথিভুক্ত করার মতো কনফিগারেশন হিসেবে দেখুন, ঘটনার সময় প্রয়োগ করে ভুলে যাওয়া প্যাচ হিসেবে নয়।

পিং নয়, কমান্ড দিয়ে জয়েন নিশ্চিত করুন

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

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

বাস্তব ইনকামিং ইন্টারফেস ও খালি নয় এমন আউটগোয়িং তালিকাসহ একটি পূর্ণ (S,G) এন্ট্রি বোঝায় কন্ট্রোল প্লেন তার কাজ শেষ করেছে। যে এন্ট্রির ইনকামিং ইন্টারফেস Null পড়া হয়, বা RPF failed লেবেলযুক্ত কাউন্টার যা ক্রমেই বাড়ছে, তা টানেলের দিকে নয়, আগের অংশের দিকে ইঙ্গিত করে।

পাঁচটি কমান্ডই ঠিক দেখালেও রিসিভার যদি এখনো কিছু না দেখে, তবে বাকি সন্দেহভাজন হলো টানেলের নিজের নীতি: একটি ক্রিপ্টো ACL বা ফায়ারওয়াল নিয়ম যা ইউনিকাস্ট রাউটিং প্রোটোকল অনুমোদন করে কিন্তু PIM, IGMP বা গ্রুপ ট্রাফিক নিজে নয়। নীতি-ভিত্তিক IPsec টানেলে মাল্টিকাস্ট আদৌ বহন করা হয় না, তাই উত্তর হলো GRE বা VTI নকশা, আরেকটি ফিল্টার ব্যতিক্রম নয়। কিছু বদলানোর আগে লিখে রাখুন পাঁচটি প্রোবের কোনটি ব্যর্থ হয়েছে, তারপর কেবল সেই স্তরটি বদলান।