دو سائٹس، ایک ٹنل اور ایک دور دراز پریفکس جو کچھ دیر جواب دیتا ہے اور پھر خاموش ہو جاتا ہے۔ پہلا ردِعمل اسے روٹنگ لوپ کہنا ہے، اور کبھی کبھی یہ بالکل ایسا ہی ہوتا ہے۔ لیکن لوپ اور غیر مستحکم روٹ ایک ہی شکایت پیدا کرتے ہیں اور انہیں متضاد مرمت درکار ہے: ایک کبھی ختم نہ ہونے والا فارورڈنگ فیصلہ ہے، دوسرا ایسا پریفکس جو بار بار ٹیبل چھوڑتا ہے۔ تین مشاہدے انہیں الگ کرتے ہیں، اور فلیٹر کو چھونے یا ٹنل دوبارہ شروع کرنے سے پہلے آپ تینوں گیٹ وے کی کمانڈ لائن سے جمع کر سکتے ہیں۔

لوپ ہاپ بہ ہاپ طے ہوتا ہے۔ سائٹ 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 آپ کو نہیں دکھاتا، اور یہ اسی وقت ہوتا ہے جب ایک سائٹ کا فائر وال دوسرے کی طرف سے پروبز کا جواب دے۔

پریفکس کے مالک کی مرمت کریں، پھر دونوں سمتوں کی تصدیق کریں

طے کریں کہ کون سی سائٹ منزل بناتی ہے اور کون سے ٹرانزٹ راستے اجازت یافتہ ہیں، پھر اسی مالک پر اعلان یا مستقل روٹ بدلیں۔ وصول کرنے والی سائٹ کو درست کرنا پرکشش اور عام طور پر غلط ہے: یہ ایک پریفکس کے لیے لوپ چھپا دیتا ہے اور اگلے کے لیے برا اعلان اپنی جگہ چھوڑ دیتا ہے۔ روٹ ٹیگ، تقسیمی فہرستیں اور split-horizon قواعد اسے ماخذ پر روکنے کے لیے ہیں، اور یہ ایک ہی پریفکس سے ملنے والے فلٹر سے سستے ہیں۔

تبدیلی کے بعد جانے اور واپس آنے کی سمت الگ الگ جانچیں، کیونکہ علامت میں کوئی نظر آنے والی بہتری کے بغیر لوپ کو بلیک ہول سے بدلا جا سکتا ہے۔ دونوں سروں سے ip route get چلائیں، ایسے ہوسٹ سے ٹریفک بھیجیں جو گیٹ وے نہ ہو، اور فلیپنگ کو مرمت نہ سمجھنے کے لیے ip monitor route کو کم از کم ایک ہولڈ ٹائمر تک چلنے دیں۔

کچھ بھی بدلنے سے پہلے یہ پانچ نکات کی تصدیق کریں: پریفکس مستحکم ہے یا کھول رہا ہے، دونوں سروں پر اگلا ہاپ ٹنل کی طرف اشارہ کرتا ہے، ہاپ گنتی دہرائی جاتی ہے یا نہیں، ایک ہی سائٹ پریفکس کی مالک ہے، اور آپ کے پاس ایسا انتظامی راستہ ہے جو تبدیلی برداشت کرے۔ اگر پانچ میں سے کوئی ایک نامعلوم ہو، تو باقی چار اندازے ہیں۔

متعلقہ مضامین