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

লুপ হপ ধরে ধরে নির্ধারিত হয়। সাইট A গন্তব্যের জন্য B-কে পরবর্তী হপ নির্বাচন করে, B একই গন্তব্যের জন্য A-কে নির্বাচন করে, আর প্যাকেটটি দুটি রাউন্ড ট্রিপ পরে TTL-এ শেষ হয়। ফ্ল্যাপিং অবশ্য নির্ধারিত হয় রাউটিং প্রোটোকল দিয়ে: প্রিফিক্স প্রত্যাহার হয়, আবার বসানো হয়, বা বিকল্প পরবর্তী হপ দিয়ে প্রতিস্থাপিত হয়, ফলে কিছু প্যাকেটের কোনো রুটই থাকে না, আবার কিছু প্যাকেট পুরোপুরি ভালো রুট অনুসরণ করে।

যে তিনটি পরীক্ষা প্রশ্নটির মীমাংসা করে

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

ObservationRouting loopRoute flapping
Prefix in the tableInstalled, same next hop throughoutWithdrawn and reinstalled, or next hop alternates
Hop countReaches zero at the same two gatewaysExpires only while the prefix is missing
Failure shapeConsistent loss for that prefix from every sourceBursts, often after a link or peer event
Where the fix belongsThe site that owns the prefix, plus filters on the transit pathAdvertisement, hold timers, or the flapping link

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

পরীক্ষা এক: প্রিফিক্সটি স্থির, নাকি ছটফট করছে

কার্নেলকে জিজ্ঞাসা করুন সে কী বসিয়েছে, কনফিগারেশন ফাইল কী প্রতিশ্রুতি দেয় তা নয়। লিনাক্স গেটওয়েতে ip route get 10.20.30.40 ঠিক সেই লুকআপই চালায় যা ফরওয়ার্ডিং পথ চালায়, নীতিমালার টেবিলসহ, আর ip route show 10.20.30.0/24 দেখায় এন্ট্রিটি নিজেই। ip monitor route প্রতিটি পরিবর্তন ঘটার সাথে সাথে প্রবাহিত করে, যা প্রিফিক্সের আসা-যাওয়া দেখার দ্রুততম উপায়।

FRR বা BIRD চালানো রাউটারে আকর্ষণীয় জিনিসটি ফরওয়ার্ডিং টেবিল নয়। show ip bgp 10.20.30.0/24 নির্বাচিত পথ আর তার আপটাইম ফেরত দেয়; কয়েক মিনিট পরপর রিসেট হওয়া আপটাইম হলো এমন ফ্ল্যাপিং যা আপনি নাম দিতে পারেন, লুপ নয়। show ip bgp summary প্রতিবেশীর অবস্থা আর প্রিফিক্সের সংখ্যা দেখায়, তাই বারবার পড়ে যাওয়া প্রতিবেশী ফরওয়ার্ডিং পথ থেকে দোষ সরিয়ে নেয়।

কিছু বদলানোর আগে উত্তরটি লিখে রাখুন। পিং ব্যর্থ হওয়ার সময় দশ মিনিট স্থির থাকা, আর দশ মিনিটে চারবার অদৃশ্য হওয়া ভিন্ন পরবর্তী পদক্ষেপে নিয়ে যায়। দ্বিতীয়টি স্ট্যাটিক রুটের সব তত্ত্বকে অপ্রাসঙ্গিক করে দেয়।

পরীক্ষা দুই: পরবর্তী হপটি কি আগমনী টানেলের দিকে ফিরে যায়

লুপের জন্য দুটি গেটওয়ের একমত হওয়া দরকার। যে সাইট প্যাকেটটি গ্রহণ করে, সেখানে দেখুন প্যাকেটটি বেরোতে কোন রুট ব্যবহার করবে: প্রকৃত সোর্স ঠিকানা দিয়ে ip route get 10.20.30.40 from 10.10.5.20, কারণ কোনো নীতিমালার নিয়ম মূল টেবিলের চেয়ে ভিন্ন উত্তর দিতে পারে। তারপর যে সাইট পাঠিয়েছে সেখানে লুকআপটি পুনরাবৃত্তি করুন। প্রতিটি পক্ষ যদি একই প্রিফিক্সের জন্য অন্যটিকে পরবর্তী হপ হিসেবে বেছে নেয়, তবে লুপটি প্রমাণিত এবং কোনো ক্যাপচার কিছুই যোগ করবে না।

কারণ প্রায় সবসময়ই এমন একটি বিজ্ঞাপন যা টানেল পার হওয়া উচিত ছিল না। টানেলে পুনর্বিতরণ করা একটি ডিফল্ট রুট, দূরবর্তী সাইটের নিজের সাবনেট ঢেকে দেওয়া একটি অ্যাগ্রিগেট, বা সাবধানতার জন্য পিয়ারের দিকে দেখানো একটি স্ট্যাটিক রুট — সবই একই পারস্পরিক পরবর্তী হপ তৈরি করে। টানেল পুরোপুরি প্রতিষ্ঠিত হয়েও ট্রাফিক বৃত্তে বহন করতে পারে; strongSwan-এর ফরওয়ার্ডিং নোট সেই প্রয়োজনের রাউটিং দিকটি বর্ণনা করে।

WireGuard আলাদা নোট দাবি করে, কারণ দোষ দেওয়ার মতো কোনো বিজ্ঞাপন নেই। wg show প্রতিটি পিয়ারের AllowedIPs তালিকাভুক্ত করে, আর কার্নেল কোনো পিয়ারের জন্য গন্তব্য গ্রহণ করে কেবল তখনই যখন এটি সেই পরিসরের ভিতরে পড়ে। সেখানে লুপ মানে ওভারল্যাপ করা AllowedIPs পরিসর বা ইন্টারফেসের ওপার দিয়ে ফিরে দেখানো স্ট্যাটিক রুট, তাই মেরামত ওই দুটি জায়গাতেই, আর কোথাও নয়।

পরীক্ষা তিন: তারার দিকে নয়, হপ গণনার দিকে তাকান

traceroute -n -I 10.20.30.40 আর mtr -n -r -c 20 10.20.30.40 দুটিই পথ দেখায়, আর ICMP মোড প্রায়ই এমন ফিল্টারিং পার হয়ে যায় যা UDP প্রোব গিলে ফেলে। লুপ দেখতে হয় একই দুটি গেটওয়ে ঠিকানার সংক্ষিপ্ত পুনরাবৃত্ত ক্রমের মতো, প্রতিবার TTL বাড়তে থাকে। আর ড্রপ দেখতে হয় শেষ যে গেটওয়ে উত্তর দিয়েছে তার পরে তারার মতো, আর একটি নীরব হপ কোনো কিছুর প্রমাণ নয়।

পথ অস্পষ্ট হলে তারের উপর TTL পড়ুন। দুটি গেটওয়েতে tcpdump -ni any -vv icmp প্রতিটি প্যাকেটের TTL আর প্রতিটি সময়-অতিক্রান্ত উত্তরের সোর্স ঠিকানা দেখায়। যদি কোনো প্যাকেট দূরবর্তী সাইটে পৌঁছায় এমন TTL নিয়ে যা পথে থাকা সম্ভাব্য হপ সংখ্যার চেয়ে কম, তবে কিছু জিনিস হপ যোগ করছে যা traceroute আপনাকে দেখাচ্ছে না, আর এটি ঘটে যখন এক সাইটের ফায়ারওয়াল অন্য সাইটের হয়ে প্রোবের উত্তর দেয়।

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

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

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

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

সম্পর্কিত নিবন্ধ