MX کے IPsec ختم کرنے سے پہلے کیا کیا ہم آہنگ ہونا چاہیے
کنفیگریشن کو قبول کرنے والا commit صرف پارسر کو ثابت کرتا ہے، راستہ نہیں۔ پلیٹ فارم کے tuple کے پانچ حصے طے کرتے ہیں کہ سروس واقعی چلتی ہے یا نہیں۔
کنفیگریشن صاف commit ہوتی ہے، انٹرفیس اوپر آتے ہیں، اور ٹنل پھر بھی قائم ہونے سے انکار کرتی ہے۔ لاگ میں کوئی سطر یہ نہیں کہتی کہ پلیٹ فارم یہ نہیں کر سکتا؛ وہ بس یہ نہیں کرتا۔ Junos میں IPsec ایک سروس ہے جسے صرف چیسیس، سروس ہارڈویئر یا سافٹ ویئر راستے، اور ریلیز کا ایک مخصوص امتزاج انجام دے سکتا ہے، اور فیچر صفحہ سافٹ ویئر کی صلاحیت بیان کرتا ہے، آپ کے آلات کی نہیں۔ tuple کو حصہ بہ حصہ جانچنا ہوگا، کیونکہ commit کا نتیجہ صرف پارسر کو ثابت کرتا ہے۔
پیکٹ دراصل کہاں جاتا ہے
IPsec کے لیے منتخب کردہ ٹریفک کو اس جزو تک پہنچنا ہوگا جو اسے خفیہ کرتا ہے۔ سروس ماڈیول والے پلیٹ فارمز پر منتخب فلو اسی ماڈیول کی طرف بھیجا جاتا ہے اور پھر فارورڈنگ راستے پر واپس آتا ہے۔ اگر ماڈیول نہ ہو، اس کی گنجائش کم ہو یا انٹرفیس سے منسلک نہ ہو، تو کنفیگریشن موجود ہے اور کوئی پیکٹ پروسیس نہیں ہوتا۔ commit کی آؤٹ پٹ میں کوئی چیز اس حالت کو صحت مند حالت سے الگ نہیں کرتی۔
سافٹ ویئر میں میزبانی کرنے والے نفاذ کام کو راؤٹنگ انجن پر یا ان لائن ہارڈویئر میں رکھتے ہیں، وسائل کی حدیں بہت مختلف ہیں۔ کنفیگریشن میں نظر آنے والی ٹنل آپ کو یہ نہیں بتاتی کہ ان راستوں میں سے کون سا واقعی اسے لے کر جا رہا ہے۔
tuple کے پانچ حصے
کوئی بھی سفارش پڑھنے سے پہلے امتزاج لکھ لیں، کیونکہ ایک حصہ باقی سب کو بے کار کر سکتا ہے۔ پرزے کا نمبر جو تین سال پہلے کسی سروس کو سہارا دیتا تھا، اس چیسیس میں موجود کارڈ اور ریلیز کے بارے میں کچھ نہیں کہتا۔ نیچے دی گئی سطریں چیک لسٹ کے طور پر پڑھیں، پھر وہ اقدار بھریں جو کنفیگریشن آپ کو نہیں دکھا سکتی۔
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
پتہ خاندان اور کام کا بوجھ وہ دو سطریں ہیں جنہیں لوگ چھوڑ دیتے ہیں، اور دونوں جانچنے میں سستے اور بعد میں دریافت کرنے میں مہنگے ہیں۔ tuple کو ڈیوائس سے پڑھیں، اسپریڈ شیٹ سے نہیں، کیونکہ کنفیگریشن وہ بتاتی ہے جو آپ نے مانگا، وہ نہیں جو نصب ہے۔ زیادہ تر حصہ دو کمانڈز اٹھاتی ہیں: show chassis hardware واقعی نصب کارڈ کا نام لیتی ہے، اور show version درست ریلیز دیتی ہے۔ کوئی بھی اس بات پر منحصر نہیں کہ کنفیگریشن درست ہے، اور یہی اصل بات ہے۔
show chassis hardware
show versionریلیز گیٹس حقیقی گیٹس ہیں
ریلیز کی تفصیل رسمی بات نہیں۔ Juniper کا IPsec جائزہ ملٹی سروس کارڈز کے لیے AES-GCM سپورٹ کو Junos 17.3R1 پر تاریخ دیتا ہے، جبکہ FIPS موڈ 17.4R1 سے شروع ہوتا ہے۔ اس لیے اسی فیچر کی دو حدیں ہیں انحصار اس بات پر کہ پلیٹ فارم کیسے چلایا جاتا ہے، اور جو موڈ آپ چلاتے ہیں وہ طے کرتا ہے کہ کون سی لاگو ہوتی ہے۔ فیچر فہرست جانچنے سے پہلے موڈ جانچیں۔
ریلیز نوٹس بالکل نصب شدہ ورژن کے لیے پڑھیں، دستاویزی طور پر موجود جدید ترین کے لیے نہیں۔ بعد کے build میں آنے والی صلاحیت کو پہلے میں موجود نہیں فرض کیا جا سکتا، اور ایک کارڈ کے لیے لکھا گیا بیان دوسرے پر منتقل نہیں ہوتا۔ ریلیز نوٹ کی سطر ڈیزائن ریکارڈ میں نقل کریں تاکہ دعوی اپنا ماخذ ساتھ رکھے، کیونکہ پلیٹ فارم خاندان کے لیے لکھا گیا سپورٹ بیان اس موڈ کے بارے میں بیان نہیں جو آپ چلاتے ہیں یا اس کارڈ کے بارے میں جو آپ کے پاس ہے۔
گنجائش کام کا بوجھ ہے، سرخی نہیں
سرخی میں تھروپٹ کا عدد اس کی پیمائشی شرائط کے بغیر مارکیٹنگ عدد ہے۔ چھوٹے پیکٹ فی بٹ بڑے پیکٹوں سے کہیں زیادہ مہنگے ہوتے ہیں، بیک وقت ایسوسی ایشنز میموری کھاتی ہیں، اور کارڈ شیئر کرنے والی ہر دوسری سروس باقی کو کم کرتی ہے۔
متوقع ٹریفک سے اندازہ لگائیں: عام اور بدترین پیکٹ سائز، ساتھیوں کی تعداد، اور یہ کہ کیا وہ کارڈ NAT یا کوئی اور سروس بھی ختم کرتا ہے۔ پھر اس دن کے لیے گنجائش چھوڑیں جب ایک راستہ ڈیزائن کے مفروضے سے زیادہ بوجھ اٹھائے گا۔ وہ گنجائش کا منصوبہ جو ہارڈویئر کو بے کار فرض کرے ایک آرزو ہے، منصوبہ نہیں۔ اگر یہ عدد کاروباری جواز کے لیے اہم ہے تو اسے ایک بار ڈیوائس پر نمائندہ بوجھ کے تحت ناپیں اور وہ پیمائش ڈیزائن کے ساتھ رکھیں۔
ڈیزائن سے پہلے ریکارڈ لکھیں
ڈیزائن کو درکار ہر صلاحیت کے لیے پلیٹ فارم کا حوالہ، ریلیز سے مطابق دستاویزات اور کوئی بھی حل نہ شدہ پابندی ایک ہی جگہ رکھیں۔ جہاں tuple کی کوئی سطر پوری نہ ہو، وہاں کسی الگ منظور شدہ گیٹ وے سے موازنہ کریں، بجائے اس کے کہ ڈیزائن کو کسی فرسودہ خریداری کی فہرست کے گرد دوبارہ بنائیں۔ ریکارڈ میں لکھا ہونا چاہیے کہ کون سا عین نظام یہ کام کرتا ہے اور کن حدود میں۔
صرف اس کے بعد ساتھی کا جائزہ لیں، کیونکہ دور دراز سرے کے ساتھ پروٹوکول مطابقت اگلا سوال ہے اور کبھی مقامی معاونت کا متبادل نہیں بنتی۔ جو ساتھی تجاویز پر متفق ہو وہ بھی ایسے چیسیس کی مدد نہیں کر سکتا جو کبھی کوئی پیکٹ خفیہ نہیں کرتا۔