AWS VGW میں سب نیٹ روٹ ایک ہی VPN ٹنل کیوں منتخب نہیں کر سکتا

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

دو پرتیں کھیل میں ہیں: VPC روٹ جو بتاتا ہے کون سا گیٹ وے، اور گیٹ وے کی اپنی ٹنل کا انتخاب۔ دونوں کو ملانا ایسی تدوین بناتا ہے جو روٹ ٹیبل میں درست دکھتی ہے اور ایک بھی پیکٹ نہیں ہلاتی۔

ایک جیسی دکھنے والی دو پرتیں

سب نیٹ روٹ ایک ہی سوال کا جواب دیتا ہے: اس منزل کے لیے کون سا اٹیچمنٹ؟ اس کا ہدف مجازی نجی گیٹ وے ہے، اور اس کا میٹرک صرف اسی ٹیبل کے دوسرے راستوں سے مقابلہ کرتا ہے۔ اس اندراج میں کچھ بھی ٹنل ایک کو ٹنل دو سے یا کنکشن A کو کنکشن B سے الگ نہیں کرتا۔ زیادہ مخصوص سابقہ ایک اور منزل کا میل ہے، باریک تر راستے کا انتخاب نہیں۔

گیٹ وے اگلے سوال کا جواب دیتا ہے: اس سابقے کے لیے رکھی گئی ٹنلوں میں سے کون اب ٹریفک لے جا رہی ہے۔ یہ فیصلہ ٹنل کی صحت اور گاہک گیٹ وے سے ملنے والی BGP خصوصیات سے آتا ہے، اور وہ کبھی سب نیٹ روٹ ٹیبل میں ظاہر نہیں ہوتا۔

VGW دراصل کیا موازنہ کرتا ہے

صحت پہلے آتی ہے۔ بند ٹنل، یا نہ اٹھا ہوا BGP سیشن، کسی بھی خصوصیت کو دیکھے جانے سے پہلے ہار جاتا ہے۔ اسی لیے پہلے سے ناکام کنکشن پر راستہ آگے جوڑنے سے کچھ نہیں بدلتا۔

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

آگے جوڑنا، اور جب وہ کچھ نہیں کرتا

آگے جوڑنا گاہک گیٹ وے کے باہر جانے والے اعلانات میں ہوتا ہے، AWS کے اندر نہیں۔ آپ اپنا ASN دو یا تین بار اس سابقے میں شامل کرتے ہیں جس سے AWS کو بچنا ہے، اور پھر AWS اس کنکشن کے لیے لمبا راستہ دیکھتا ہے۔ بنیادی کنکشن بغیر آگے جوڑے اعلان رکھتا ہے۔ اگر دونوں کنکشن ایک ہی ASN سے یکساں تعداد میں آگے جوڑ کر اعلان کریں، تو آپ نے کوئی ترجیح ظاہر نہیں کی۔

تبدیلی کے بعد AWS کی طرف موصول ہونے والا راستہ جانچیں۔ جو آگے جوڑنا گاہک کے آلے سے کبھی نکلا ہی نہیں، وہ AWS کے نظر انداز کیے گئے جوڑنے جیسا ہی دکھتا ہے۔

جامد راستے پوری دلیل کو نظر انداز کرتے ہیں

اگر کنکشن جامد روٹنگ استعمال کرتا ہے تو لمبا کرنے کے لیے کوئی AS_PATH نہیں۔ AWS جامد VPN راستوں کو اسی سابقے کے لیے BGP سے سیکھے گئے راستوں پر ترجیح دینے والا دستاویزی کرتا ہے، اس لیے مخلوط ڈیزائن مکمل طور پر متحرک کی طرح برتاؤ نہیں کرتا۔ پہلے روٹنگ کی قسم طے کریں، پھر اس کے لیے موجود ترجیح کا طریقہ کار منتخب کریں۔

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

ٹرانزٹ گیٹ وے الگ جواب کیوں ہے

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

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

سیٹ کرنے کے بعد کیا جانچنا ہے

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

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