מדיניות חומת אש ב-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 מתוכננת, ובדרך כלל רק אחד מהשניים מיועד. העיצוב המוגמר נוקב היכן מנותבת כל מחלקת תעבורה, היכן היא נבדקת, ומה קורה כשמסלול הבדיקה הזה אינו זמין.