🥇VxLAN מפעל. חלק 3

שלום, הבר. אני מסיים סדרת מאמרים, מוקדש להשקת הקורס "מהנדס רשת" מאת OTUS, באמצעות טכנולוגיית VxLAN EVPN לניתוב בתוך המרקם ושימוש בחומת אש להגבלת גישה בין שירותים פנימיים

חלקים קודמים של הסדרה ניתן למצוא בקישורים הבאים:

היום נמשיך ללמוד את היגיון הניתוב בתוך מארג ה-VxLAN. בחלק הקודם, הסתכלנו על ניתוב תוך-בד בתוך VRF יחיד. עם זאת, ייתכן שיש מספר עצום של שירותי לקוח ברשת, ואת כולם חייבים להיות מופצים ל-VRFs שונים כדי להבדיל את הגישה ביניהם. בנוסף להפרדת הרשת, ייתכן שעסק יצטרך לחבר חומת אש כדי להגביל את הגישה בין שירותים אלה. כן, זה לא יכול להיקרא הפתרון הטוב ביותר, אבל המציאות המודרנית דורשת "פתרונות מודרניים".

הבה נשקול שתי אפשרויות לניתוב בין VRFs:

ניתוב מבלי לעזוב את מארג VxLAN;
ניתוב על ציוד חיצוני.

נתחיל בהיגיון הניתוב בין VRFs. יש מספר מסוים של VRFs. כדי לנתב בין VRF, צריך לבחור מכשיר ברשת שיידע על כל ה-VRF (או חלקים שביניהם יש צורך בניתוב). מכשיר כזה יכול להיות, למשל, אחד ממתגי Leaf (או כולם בבת אחת) . טופולוגיה זו תיראה כך:

מהם החסרונות של טופולוגיה זו?

זה נכון, כל ליף צריך לדעת על כל ה-VRFs (וכל המידע שיש בהם) ברשת, מה שמוביל לאובדן זיכרון ולעומס רשת מוגבר. אחרי הכל, לעתים קרובות כל מתג Leaf לא צריך לדעת על כל מה שיש ברשת.

עם זאת, בואו נשקול שיטה זו ביתר פירוט, שכן עבור רשתות קטנות אפשרות זו מתאימה למדי (אם אין דרישות עסקיות ספציפיות)

בשלב זה, ייתכן שתהיה לך שאלה כיצד להעביר מידע מ-VRF ל-VRF, כי הנקודה של הטכנולוגיה הזו היא בדיוק שצריך להגביל את הפצת המידע.

והתשובה טמונה בפונקציות כמו ייצוא וייבוא של מידע ניתוב (הגדרת טכנולוגיה זו נחשבה ב שני חלקים מהמחזור). הרשה לי לחזור בקצרה:

בעת הגדרת VRF ב-AF, עליך לציין route-target לייבוא וייצוא מידע ניתוב. אתה יכול לציין זאת באופן אוטומטי. אז הערך יכלול את ASN BGP ו-L3 VNI המשויכים ל-VRF. זה נוח כאשר יש לך רק ASN אחד במפעל שלך:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

עם זאת, אם יש לך יותר מ-ASN אחד ואתה צריך להעביר מסלולים ביניהם, אז תצורה ידנית תהיה אפשרות נוחה יותר וניתנת להרחבה route-target. ההמלצה להגדרה ידנית היא המספר הראשון, השתמש במספר שנוח לך, למשל, 9999.
השני צריך להיות שווה ל-VNI עבור אותו VRF.

בואו נגדיר את זה בצורה הבאה:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

איך זה נראה בטבלת הניתוב:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

הבה נבחן את האפשרות השנייה לניתוב בין VRFs - באמצעות ציוד חיצוני, למשל Firewall.

ישנן מספר אפשרויות לעבודה באמצעות מכשיר חיצוני:

המכשיר יודע מה זה VxLAN ואנחנו יכולים להוסיף אותו לחלק מהבד;
המכשיר לא יודע דבר על VxLAN.

לא נתעכב על האפשרות הראשונה, מכיוון שהלוגיקה תהיה כמעט זהה לזה שמוצג לעיל - אנו מביאים את כל ה-VRFs ל-Firewall ומגדירים ניתוב בין VRFs עליו.

בואו נשקול את האפשרות השנייה, כאשר חומת האש שלנו לא יודעת דבר על VxLAN (עכשיו, כמובן, מופיע ציוד עם תמיכה ב-VxLAN. לדוגמה, Checkpoint הכריזה על תמיכתה בגרסה R81. ניתן לקרוא על כך כאןעם זאת, כל זה בשלב הבדיקה ואין אמון ביציבות הפעולה).

בעת חיבור התקן חיצוני, אנו מקבלים את הדיאגרמה הבאה:

כפי שניתן לראות מהתרשים, צוואר בקבוק מופיע בממשק עם חומת האש. יש לקחת זאת בחשבון בעתיד בעת תכנון הרשת ואופטימיזציה של תעבורת הרשת.

עם זאת, בואו נחזור לבעיה המקורית של ניתוב בין VRFs. כתוצאה מהוספת חומת האש, אנו מגיעים למסקנה שחומת האש חייבת לדעת על כל ה-VRFs. לשם כך, יש להגדיר את כל ה-VRFs גם ב-Border Leafs, ויש לחבר את חומת האש לכל VRF עם קישור נפרד.

כתוצאה מכך, הסכימה עם חומת אש:

כלומר, בחומת האש צריך להגדיר ממשק לכל VRF שנמצא ברשת. באופן כללי, ההיגיון לא נראה מסובך והדבר היחיד שאני לא אוהב כאן הוא המספר העצום של ממשקים על חומת האש, אבל כאן הגיע הזמן לחשוב על אוטומציה.

בסדר גמור. חיברנו את חומת האש והוספנו אותה לכל ה-VRFs. אבל איך אנחנו יכולים כעת לאלץ תנועה מכל עלה לעבור דרך חומת האש הזו?

ב-Leaf המחובר לחומת האש, לא יתעוררו בעיות, מכיוון שכל המסלולים הם מקומיים:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

עם זאת, מה לגבי Leafs מרוחקים? איך להעביר להם את המסלול החיצוני המוגדר כברירת מחדל?

זה נכון, דרך EVPN route-type 5, כמו כל קידומת אחרת על מרקם VxLAN. עם זאת, זה לא כל כך פשוט (אם אנחנו מדברים על סיסקו, מכיוון שלא בדקתי עם ספקים אחרים)

יש לפרסם את מסלול ברירת המחדל מהעלה שאליו מחוברת חומת האש. עם זאת, כדי לשדר את המסלול, ליף חייב להכיר אותו בעצמו. וכאן נוצרת בעיה מסוימת (אולי רק אצלי), המסלול חייב להיות רשום סטטי ב-VRF שבו רוצים לפרסם מסלול כזה:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

לאחר מכן, בתצורת BGP, הגדר את המסלול הזה ב-AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

עם זאת, זה לא הכל. כך מסלול ברירת המחדל לא ייכלל במשפחה l2vpn evpn. בנוסף לכך, עליך להגדיר חלוקה מחדש:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

אנו מציינים אילו קידומות ייכנסו ל-BGP באמצעות הפצה מחדש

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

עכשיו הקידומת 0.0.0.0/0 נופל לתוך EVPN מסלול מסוג 5 ומועבר לשאר עלה:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

בטבלת BGP אנו יכולים גם לראות את המסלול המתקבל מסוג 5 עם מסלול ברירת המחדל דרך 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

בכך מסתיימת סדרת המאמרים המוקדשים ל-EVPN. בעתיד, אנסה לשקול את פעולת VxLAN בשילוב עם Multicast, שכן שיטה זו נחשבת לניתנת להרחבה (כרגע אמירה שנויה במחלוקת)

אם עדיין יש לך שאלות/הצעות בנושא, שקול כל פונקציונליות של EVPN - כתוב, נשקול זאת עוד יותר.

מקור: www.habr.com

מפעל VxLAN. חלק 3

הוספת תגובה ביטול תגובה