OSPF اور EIGRP کے بیشتر مباحث فرض کرتے ہیں کہ سرنگ پہلے ہی پروٹوکول لے جا سکتی ہے، اور ASA پر پہلے جانچنے والا حصہ یہی مفروضہ ہے۔ موازنہ صرف اس وقت دلچسپ ہوتا ہے جب امیج، VTI کی قسم اور multicast راستہ تصدیق ہو جائے۔ یہ ترتیب غلط ہوئی تو آپ ایسی سرنگ پر ٹائمر ٹیون کرنے میں دوپہر گنوا دیں گے جو کبھی ہمسائیگی نہیں بنائے گی۔ میں ایسے ہر ڈیزائن کی شروعات ریلیز نوٹس اور چلتی کنفیگریشن سے کرتا ہوں، پروٹوکول کی ترجیح سے نہیں۔

پروٹوکول سے پہلے ریلیز فیصلہ کرتا ہے

ASA 9.24 کے لیے Cisco کی VTI گائیڈ ایک قابلِ استعمال دستاویزی بنیاد ہے: یہ سٹیٹک اور ڈائنامک VTI بیان کرتی ہے اور سٹیٹک روٹنگ، BGP، OSPF اور EIGRP کی فہرست دیتی ہے۔ اس کی فیچر ہسٹری VTI پر OSPFv2 اور EIGRP کی حمایت کو 9.19(1) پر رکھتی ہے۔ اس سے پرانی ہر چیز الگ بات ہے۔

چنانچہ پہلے دو سوال بور اور فیصلہ کن ہیں:

CheckWhat decides it
Image and releaseWhether the feature history lists OSPFv2 or EIGRP on VTI for the version you run
VTI typeStatic or dynamic, and which routing context the platform permits
Multicast on the tunnelWhether it is enabled, and whether the group limits are respected

یہ کہنا کہ ASA VTI استعمال نہیں کر سکتا یا IGP نہیں لے جا سکتا، کچھ پرانی امیجز کے لیے درست تھا اور آج کا سپورٹ میٹرکس نہیں ہے۔ اسی طرح 9.24 گائیڈ ہر ڈیوائس کو اپ گریڈ کرنے کی ہدایت نہیں ہے۔ یہ بتاتی ہے کہ وہ ریلیز کیا سپورٹ کرتی ہے، اور آپ کی تعینات ریلیز کو خود جواب دینا ہوگا۔

unicast کا گزرنا یہ معنی نہیں رکھتا کہ IGP بنے گا

وہی گائیڈ نوٹ کرتی ہے کہ unicast بطور ڈیفالٹ گزرتا ہے اور VTI پر OSPFv2 یا EIGRP کے لیے multicast فعال کرنا ہوتا ہے، multicast گروپس پر دستاویزی حدود کے ساتھ۔ وہی ایک جملہ اس ڈیزائن میں میرے دیکھے بیشتر ناکام ہمسائیگی کے تعلقات کی وضاحت کرتا ہے۔ سرنگ کے آر پار چلنے والا ping، یا سبز IPsec حالت، صرف unicast راستہ ثابت کرتا ہے۔ پروٹوکول کی دریافت کو multicast راستہ درکار ہے، اور دونوں الگ الگ کنفیگر ہوتے ہیں۔

hello یا hold ٹائمر چھونے سے پہلے سرنگ انٹرفیس کنفیگریشن میں وہ multicast سیٹنگ دیکھیں۔ اگر سیٹنگ نہ ہو تو ہمسائیگی سست نہیں، ناممکن ہے۔

ایک ہی سرنگ پر OSPF اور EIGRP ساتھ ساتھ

سرنگ پر ہی دونوں پروٹوکول ویسے ہی دکھتے ہیں جیسے اور کہیں۔ OSPF کو مطابق نیٹ ورک قسم، علاقہ، تصدیق اور پڑوسی پیرامیٹرز درکار ہیں؛ EIGRP کو اپنا AS نمبر اور اس کے ساتھ جانے والی انٹرفیس سطح کی سیٹنگز درکار ہیں۔

جال یہ ہے کہ کسی دوسرے سرنگ ماڈل سے پڑوسی بیانات کاپی کیے جائیں۔ بغیر VTI والے ڈیزائن میں سٹیٹک پڑوسیوں کے بارے میں مشورہ multicast سے بچنے کے لیے تھا، اور وہ ایسی VTI پر منتقل نہیں ہوتا جس سے توقع ہے کہ پروٹوکول کو قدرتی طور پر لے جائے۔ معاون انٹرفیس رویہ کنفیگر کریں، پھر پروٹوکول کو اپنی ہمسائیگی خود بنانے دیں۔

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

پڑوسی نصب شدہ راستوں کے برابر نہیں ہوتے

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

show ospf neighbor اور show eigrp neighbors آپ کو بتاتے ہیں کہ سیشن زندہ ہے۔ show route آپ کو بتاتا ہے کہ برانچ پریفکس پہنچا یا نہیں، اور یہ الگ سوالات ہیں۔

ایپلیکیشن راستہ پھر تیسرا سوال ہے۔ ہمسائیگی کا رشتہ رسائی تقسیم کرتا ہے؛ یہ فائر وال سے اجازت نہیں دیتا اور یہ ثابت نہیں کرتا کہ ٹریفک سلیکٹر اور فلٹرنگ قواعد متفق ہیں۔ راستہ یعنی پالیسی سمجھنے کے بجائے منظور شدہ ٹیسٹ سے اجازت یافتہ بہاؤ اور اس کا جوابی راستہ تصدیق کریں۔

مکمل موازنہ کیا ریکارڈ کرے

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

اگر ان چار میں سے کوئی بھی نہ ہو تو آپ کے پاس ڈیزائن نہیں، ترجیح ہے۔ پہلے غائب حقیقت درست کریں؛ پروٹوکول کا انتخاب آسان حصہ ہے۔

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