Junos کی برآمدی پالیسی: نام مطابقت کی شرط نہیں

کسی نے ایک پالیسی کا نام EXPORT-STATIC رکھا، اسے منسلک کیا، اور اب سوچ رہا ہے کہ VPN روٹنگ انسٹینس سے آنے والا سابقہ دور سرے تک کیوں نہیں پہنچتا۔ نام کا انتخاب پر کوئی اثر نہیں۔ پالیسی ایک تعریف اور ایک منسلکہ ہے، اور یہ کیا برآمد کرتی ہے یہ اس کی مطابقت کی شرائط، ترتیب شدہ شرائط اور اسے استعمال کرنے والا سیاق و سباق طے کرتے ہیں۔ ان تینوں کو اسی ترتیب سے پڑھیں، اور معمہ عام طور پر ایک ایسی شرط پر سمٹ جاتا ہے جو کبھی مطابقت نہیں رکھتی تھی۔

نام ایک لیبل ہے، شرط نہیں

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

غیر متوقع برآمدی نتیجے کو تعریف پڑھنے کی درخواست سمجھیں، منسلکہ ٹوٹنے کا ثبوت نہیں۔ تعریف پڑھیں اور اسے لیبل کی مخالفت کرنے دیں۔

شرائط سے پہلے منسلکہ تلاش کریں

درست تعریف غلط جگہ منسلک ہو تو دوسری ادلا بدلی بدل دیتی ہے۔ مقرر کریں کہ کون سا روٹنگ انسٹینس، پروٹوکول اور پڑوسی یا گروپ واقعی پالیسی کا حوالہ دیتے ہیں، کیونکہ ایک BGP گروپ کے تحت منسلک پالیسی دوسرے پر اثر نہیں ڈالتی، اور انسٹینس سے منسلک پالیسی اندر کے ہر پروٹوکول پر لازماً لاگو نہیں ہوتی۔ Junos ان سطحوں کو الگ کرتا ہے، اور جب نیت انسٹینس سطح پر ظاہر کی گئی ہو تو گروپ سطح پر برآمد نہ ہونا عام ہے۔

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

شرائط ترتیب سے جانچی جاتی ہیں، اور پہلا فیصلہ جیت جاتا ہے

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

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

ایک مثال جو صرف سٹیٹک راستے برآمد کرتی ہے، منسلکہ گروپ پر ہے:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

OSPF سے سیکھا گیا اور سٹیٹک راستے کے طور پر ترتیب نہ دیا گیا سابقہ مطابقت میں ناکام ہو کر گر جاتا ہے، پالیسی کا نام جو بھی ہو۔

کارروائیاں نقل بدلتی ہیں، اصل راستہ نہیں

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

قبول اور رد حتمی فیصلے ہیں؛ صفات کی تبدیلیاں لازماً ایسی نہیں ہوتیں۔ یہ نہ سمجھیں کہ community مقرر کرنے سے پالیسی ختم ہو جاتی ہے، کیونکہ جانچ ان شرائط تک جا سکتی ہے جن پر آپ نے غور نہیں کیا۔

اعلان شدہ منظر کا توقع سے موازنہ کریں

اصل پیر پر پروٹوکول کے مخصوص منظر کا استعمال کریں، مثلاً show route advertising-protocol bgp 192.0.2.1، اور اسے درست روٹنگ انسٹینس سیاق میں پڑھیں۔ VRF میں موجود راستہ لازماً برآمدی پالیسی سے نہیں گزرا، اور اعلان شدہ آؤٹ پٹ میں نظر آنے والا راستہ لازماً دور کے فریق نے قبول نہیں کیا۔ یہ تین الگ حالتیں ہیں اور وہ الگ الگ طریقوں سے ناکام ہوتی ہیں۔

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