سیاست دیوار آتش در 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 برنامه‌ریزی‌شده است و معمولاً فقط یکی از آن دو موردنظر است. طراحی نهایی نام می‌برد که هر کلاس ترافیک کجا مسیریابی می‌شود، کجا بازرسی می‌شود و وقتی آن مسیر بازرسی در دسترس نیست چه اتفاقی می‌افتد.