EVPN فائر وال پالیسی: مرکزی گیٹ وے بمقابلہ تقسیم شدہ IRB
مرکزی گیٹ وے کرایہ داروں کی ٹریفک فائر وال سے گزارتے ہیں، تقسیم شدہ IRB ایسا نہیں کرتا۔ موازنہ کریں کہ کون کہاں جانچتا ہے اور تیز راستے کو کیا درکار ہے۔
دو EVPN ڈیزائن کرایہ دار کے گیٹ وے کو مختلف جگہوں پر رکھتے ہیں، اور فائر وال ہر ایک میں مختلف ٹریفک دیکھتا ہے۔ مرکزی گیٹ وے کے ساتھ، ذیلی نیٹوں کے درمیان ٹریفک فائر وال تک پہنچتی ہے کیونکہ روٹنگ وہیں ہوتی ہے۔ تقسیم شدہ IRB کے ساتھ، leaf سوئچ مقامی طور پر روٹنگ کرتے ہیں اور فائر وال کچھ نہیں دیکھتا جب تک آپ اسے جان بوجھ کر شامل نہ کریں۔ کوئی ماڈل غلط نہیں۔ غلط یہ ہے کہ سرحد پر فائر وال لگا کر یہ سمجھا جائے کہ fabric ٹریفک اس تک پہنچا دے گا۔
دو ماڈل، دو مختلف جانچ کے مقامات
پہلے ان بہاؤں کے نام لیں جنہیں جانچ درکار ہے، کیونکہ دونوں ماڈل انہیں مختلف طریقے سے برتتے ہیں۔
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
ایک ہی ذیلی نیٹ کے اندر ٹریفک وہ قطار ہے جسے لوگ بھول جاتے ہیں۔ ایک VLAN پر دو میزبان بریجنگ کے ذریعے بات کرتے ہیں، اور اس راستے میں کوئی روٹ شدہ فائر وال نہیں ہوتا جب تک کوئی الگ لیئر 2 جانچ کا ڈیزائن اسے نہ روکے۔ یہ دونوں ماڈل میں درست ہے، اس لیے یہ ڈیزائن کی خلا ہے، ان کے درمیان موازنہ نہیں۔
باقی تین قطاریں وہ جگہ ہیں جہاں ماڈل واقعی الگ ہوتے ہیں۔
مرکزی گیٹ وے: سادہ جانچ، حقیقی ٹرانزٹ لاگت
کرایہ دار کے VLAN کو لیئر 2 سروسز کے طور پر رکھیں اور ان کے روٹنگ گیٹ وے فائر وال پر رکھیں۔ ذیلی نیٹوں کے درمیان ٹریفک پھر اس گیٹ وے تک جاتی اور واپس آتی ہے، ممکنہ طور پر اس وقت بھی جب دونوں میزبان ایک ہی leaf پر ہوں۔ جانچ کا مقام واضح ہے، اور یہی اس ڈیزائن کی پوری دلیل ہے۔ لاگت فائر وال پر ٹرانزٹ بوجھ اور ایک مرکزی صلاحیت و دستیابی کا انحصار ہے جو اب آپ کو انجینئر کرنا ہے۔
تبدیلی کو ان کرایہ دار گیٹ ویز تک محدود رکھیں جن کا آپ ارادہ رکھتے ہیں۔ ہر VLAN پتہ ہٹانا بہت وسیع ہے جب انتظام، underlay اور پلیٹ فارم انٹرفیس کے الگ فرائض ہوں۔ دوسرا فعال گیٹ وے بھی جانچیں، کیونکہ جو اب بھی فائر وال کے گرد روٹنگ کرتا ہے وہ ڈیزائن کو خاموشی سے بے کار کر دیتا ہے۔
یہ ماڈل آڈیٹر کو سمجھانا آسان ہے۔ تاہم چلانا خودبخود سستا نہیں۔
تقسیم شدہ IRB: تیز راستہ، بطور طے شدہ کوئی جانچ نہیں
تقسیم شدہ anycast گیٹ ویز کے ساتھ، ہر leaf کرایہ دار کی ٹریفک مقامی طور پر روٹ کرتا ہے، اور RFC 9135 بیان کرتا ہے کہ یہ مرکزی گیٹ وے کے ذریعے واپسی سے کیوں بچتا ہے۔ فائدہ حقیقی ہے، اور اس کا براہ راست نتیجہ ہے: جانچ کا اندازہ اس بات سے نہیں لگایا جا سکتا کہ فائر وال کہاں منسلک ہے۔ سرحدی leaf سے منسلک فائر وال بیرونی ٹریفک اور وہ سب دیکھتا ہے جو آپ واضح طور پر اس کی طرف موڑتے ہیں۔
سروس کو اس طریقہ کار سے شامل کریں جسے پلیٹ فارم واقعی سپورٹ کرتا ہے: پالیسی پر مبنی ری ڈائریکشن، سروس نوڈ، یا فائر وال کے ذریعے کنٹرول شدہ VRF کے درمیان روٹنگ۔ مطلوبہ ٹریفک کو اس کے اصل داخلے کے مقام پر ملائیں۔ میزبانوں کی طرف کے انٹرفیس پر لکھی گئی پالیسی overlay سے آنے والے پیکٹ کو نہیں ڈھانپتی۔
مطلوبہ طے شدہ کے بجائے نصب شدہ راستے پڑھیں۔ براہ راست درآمد کردہ زیادہ مخصوص کرایہ دار سابقہ اس طے شدہ راستے کو بائی پاس کر سکتا ہے جو فائر وال کی طرف اشارہ کرتا ہے، اور ترتیب میں کچھ بھی غلط نظر نہیں آئے گا۔
توازن روٹنگ کی خصوصیت ہے، جانچ کی ضمانت نہیں
ہم آہنگ IRB بیان کرتا ہے کہ داخلے اور اخراج کے provider edge نوڈ ایک بہاؤ کے لیے روٹنگ اور بریجنگ کیسے سنبھالتے ہیں۔ یہ نہیں بتاتا کہ دونوں سمتیں ایک ہی stateful ڈیوائس تک پہنچتی ہیں یا نہیں۔ ECMP، anycast اور فائر وال کی اعلی دستیابی سب اس پر اثر ڈالتے ہیں کہ کون سا نوڈ واپسی ٹریفک دیکھتا ہے، اور کلسٹر کا معاون حالت ماڈل فیصلہ کرتا ہے کہ یہ قابل قبول ہے یا نہیں۔
آپ کے لیے اہم ہر بہاؤ کے لیے واپسی راستے کی واضح طور پر پیروی کریں۔ NAT اس کام کا عالمگیر متبادل نہیں، اور اس پر انحصار کرنے والے ڈیزائن عموماً خلا تعمیر کے دوران نہیں بلکہ failover کے دوران پاتے ہیں۔
ڈیزائن منظور کرنے سے پہلے ایک لازمی بہاؤ اور ایک جان بوجھ کر خارج کردہ بہاؤ دونوں سمتوں میں چل کر دیکھیں۔
کیسے منتخب کریں، اور کسی بھی صورت میں کیا جانچیں
مرکزی گیٹ وے منتخب کریں جب جانچ کی کوریج ٹرانزٹ صلاحیت سے زیادہ اہم ہو اور آپ مرکزی انحصار برداشت کر سکیں۔ تقسیم شدہ IRB منتخب کریں جب مقامی روٹنگ اصل مسئلہ ہو، اور فرض کرنے کے بجائے واضح سروس داخلے کے لیے بجٹ رکھیں۔
پھر وہ روٹنگ جانچیں جو آپ نے واقعی نصب کی، کیونکہ دونوں ڈیزائن سب سے زیادہ وہیں مختلف ہوتے ہیں:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixجانچ میں سروس نوڈ کی ناکامی اور بحالی شامل کریں۔ جو فال بیک راستہ خاموشی سے جانچ کو بائی پاس کرتا ہے وہ منصوبہ بند fail-open پالیسی سے مختلف فیصلہ ہے، اور عموماً دونوں میں سے صرف ایک مقصود ہوتا ہے۔ مکمل ڈیزائن بتاتا ہے کہ ہر ٹریفک طبقہ کہاں روٹ ہوتا ہے، کہاں جانچا جاتا ہے، اور جب وہ جانچ کا راستہ دستیاب نہ ہو تو کیا ہوتا ہے۔