DMVPN مرحلہ 3: دونوں سمتوں میں شارٹ کٹ پڑھنا
ایک سیدھا ping DMVPN مرحلہ 3 کے شارٹ کٹ کو ثابت نہیں کرتا۔ آگے اور واپسی کے راستے چلیں، پھر NHRP، روٹ اور IPsec کی حالت الگ الگ پڑھیں۔
آپ ایک ping کو spoke سے spoke جاتے دیکھتے ہیں، وہ hub کے ذریعے لمبا راستہ لیتا ہے، اور دوسرا سیدھا جاتا ہے۔ اس لمحے شارٹ کٹ کو کام کرتا ہوا قرار دینا پرکشش ہے۔ یہ نتیجہ آدھا درست ہے۔ آگے کا راستہ شارٹ کٹ ہو سکتا ہے جبکہ واپسی کا راستہ اب بھی hub سے گزر رہا ہو، اور ہر سمت کو ثابت کرنے والی حالت الگ حالت ہے۔ دونوں سمتیں چلیں اور ڈیزائن کو صحت مند ماننے سے پہلے تین جدولیں پڑھیں۔
اسی پیکٹ راستے سے شروع کریں جو آپ واقعی دیکھ سکتے ہیں
ایسے spoke سے شروع کریں جس کی منزل سیدھی ہونی چاہیے۔ پہلے پیکٹ کا پیچھا کریں: یہ spoke کے روٹ کے ساتھ hub کی طرف جاتا ہے، کیونکہ ابھی کوئی شارٹ کٹ نہیں۔ hub اسے آگے بھیجتا ہے اور مرحلہ 3 کے ڈیزائن میں ماخذ کو ایک ری ڈائریکٹ بھی بھیجتا ہے کہ بہتر راستہ موجود ہے۔
وہ ری ڈائریکٹ محرک ہے، ثبوت نہیں۔ یہ کہتا ہے کہ hub نے ایسی ٹریفک دیکھی جو بہتر بنائی جا سکتی ہے۔ یہ نہیں کہتا کہ ماخذ نے شارٹ کٹ بنایا، منزل نے حل کا جواب دیا، یا واپسی کا راستہ اسے استعمال کرتا ہے۔
اس لیے پہلا مفید مشاہدہ پہلے اور بعد ہے: hub کے ذریعے پہلا بہاؤ، بعد کا بہاؤ سیدھا۔
تین حالتیں جو ایک ہی سرنگ جیسی لگتی ہیں
شارٹ کٹ حالت کے تین حصوں پر منحصر ہے، اور ہر ایک کی اپنی عمر اور اپنا حکم ہے۔
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
NHRP کیش اندراج overlay پتے کو NBMA ٹرانسپورٹ پتے سے جوڑتا ہے۔ روٹ یا شارٹ کٹ طے کرتا ہے کہ ایک اندرونی منزل کہاں بھیجی جاتی ہے۔ IPsec انجمن اس سے پیدا ہونے والی ٹریفک کی حفاظت کرتی ہے۔ غائب جواب تینوں میں سے کسی سے بھی آ سکتا ہے، اور احکام بتاتے ہیں کہ کون سا غائب ہے۔
انہیں اسی ترتیب میں پڑھیں، کیونکہ غائب نقشہ بندی باقی دو کو دلچسپی کے قابل نہیں رکھتی۔
درخواست اور جواب الگ الگ چلیں
spoke A سے حل طلب کریں اور دیکھیں کیا واپس آتا ہے۔ درخواست تعاون یافتہ NHRP فارورڈنگ راستے سے جاتی ہے، اور منزل hub کے ذریعے نہیں بلکہ سیدھا جواب دے سکتی ہے۔ یہ عدم توازن معمول ہے، اور اسی لیے جواب تبادلے کا دلچسپ نصف ہے۔
اب کردار بدلیں۔ B سے A کی طرف بھیجیں اور وہی تین مطالعے دہرائیں۔ جو ڈیزائن ایک سمت میں شارٹ کٹ کرتا ہے اور دوسری میں نہیں، وہ متوازی نہیں، اور عدم توازن عام طور پر ایک طرف غائب سابقہ یا ایسے حل سے آتا ہے جسے کبھی جواب نہ ملا۔
درخواست hub سے گزری اس لیے ساتھی کے جواب کو hub عبور کرنا لازم نہیں۔ اسے خطا نہ پڑھیں اور ایسی روٹنگ خرابی کے پیچھے نہ بھاگیں جو موجود نہیں۔
hub کا ری ڈائریکٹ پڑھیں، صرف اس کا روٹ نہیں
hub کی روٹ جدول بتاتی ہے کہ hub پیکٹ کہاں بھیجے گا۔ ری ڈائریکٹ بتاتا ہے کہ hub نے ماخذ سے اس بارے میں کیا کرنے کو کہا۔ یہ الگ حقائق ہیں، اور درست روٹ رکھنے والا مگر ری ڈائریکٹ نہ بھیجنے والا hub ہر بہاؤ کو غیر معینہ مدت تک لمبے راستے پر رکھے گا۔ hub کے NHRP واقعات جانچیں اور تصدیق کریں کہ آپ کی دلچسپی کی ٹریفک کے لیے ری ڈائریکٹ بن رہے ہیں۔
مرحلہ 3 خلاصے کے معنی بھی بدلتا ہے۔ شارٹ کٹ رویے کے ساتھ spokes کو مرحلہ 2 ڈیزائن کی توقع کردہ مخصوص دور دراز روٹوں کا پورا مجموعہ درکار نہیں، اس لیے spoke پر خلاصہ شدہ روٹ خود بخود غائب نیٹ ورک نہیں ہے۔ خلاصے کو خرابی کے طور پر پڑھنے سے پہلے مرحلہ اور روٹنگ پالیسی کی تصدیق کریں۔
یہی ایک غلط فہمی کسی بھی اور چیز سے زیادہ DMVPN ٹکٹ بناتی ہے۔
نتیجے کو غائب شے کے طور پر درج کریں
مجاز ایپلیکیشن بہاؤ اور اس کے جواب کے ساتھ ختم کریں، اور ہر سمت کے لیے نوٹ کریں کہ سیدھا راستہ استعمال ہوا یا نہیں۔ پھر نتیجہ اس شے کے طور پر لکھیں جو غائب تھی: نقشہ بندی، فارورڈنگ شارٹ کٹ، حفاظتی انجمن یا ایپلیکیشن جواب۔
روٹنگ ہمسائیگی اور مشترکہ حفاظتی انجمن صحت کا ثبوت ہیں، راستے کا ثبوت نہیں۔ دونوں کامل ہو سکتے ہیں جبکہ ہر پیکٹ اب بھی لمبا چکر لگاتا ہے۔ پہلے فارورڈنگ فیصلہ جانچیں، پھر وہ انجمن جو اسے اٹھاتی ہے۔ ترتیب اہم ہے، کیونکہ انجمن بہرحال بنتی ہے۔
یہ عادت اگلے ٹکٹ پر کام آتی ہے۔ «سرنگ اوپر ہے مگر سست» «B کے پاس A کے میزبان کے لیے شارٹ کٹ نہیں» بن جاتا ہے، اور دوسرا بیان پانچ منٹ کی درستی ہے۔ حکم کا آؤٹ پٹ نتیجے کے ساتھ رکھیں، اور فروش کی مرحلہ 3 رہنما اس کے پہلو میں رکھیں۔