🥇VxLAN מפעל. חלק 1

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

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

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

כל הדוגמאות יבוצעו על Cisco Nexus 9000v, המורכב בטופולוגיה של Spine-Leaf. לא נתעכב על הקמת רשת Underlay במאמר זה.

רשת תשתית
BGP-הצצה עבור l2vpn evpn של משפחת כתובת
הגדרת NVE
דיכוי-ארפ

רשת תשתית

הטופולוגיה שבה נעשה שימוש היא כדלקמן:

בואו נגדיר כתובת בכל המכשירים:

Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102

Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21

Host-1 - 192.168.10.10
Host-2 - 192.168.10.20

בואו נבדוק שיש קישוריות IP בין כל המכשירים:

Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0                      ! Leaf-11 доступен чеерз два Spine
    *via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0                      ! Leaf-12 доступен чеерз два Spine
    *via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
    *via 10.255.1.22, Lo0, [0/0], 00:02:20, local
    *via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
    *via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
    *via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intra

בואו נבדוק שדומיין ה-VPC נוצר ושני המתגים עברו את בדיקת העקביות וההגדרות בשני הצמתים זהות:

Leaf11# show vpc 

vPC domain id                     : 1
Peer status                       : peer adjacency formed ok
vPC keep-alive status             : peer is alive
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : primary
Number of vPCs configured         : 0
Peer Gateway                      : Disabled
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Disabled
Delay-restore status              : Timer is off.(timeout = 30s)
Delay-restore SVI status          : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router    : Disabled

vPC status
----------------------------------------------------------------------------
Id    Port          Status Consistency Reason                Active vlans
--    ------------  ------ ----------- ------                ---------------
5     Po5           up     success     success               1

BGP הצצה

לבסוף, אתה יכול לעבור להגדרת רשת ה-Overlay.

כחלק מהמאמר, יש צורך לארגן רשת בין מארחים, כפי שמוצג בתרשים שלהלן:

כדי להגדיר רשת שכבת-על, עליך להפעיל BGP במתגי השדרה והעלה עם תמיכה במשפחת l2vpn evpn:

feature bgp
nv overlay evpn

לאחר מכן, עליך להגדיר הצצה BGP בין Leaf ו-Spine. כדי לפשט את ההגדרה ולייעל את הפצת מידע הניתוב, אנו מגדירים את Spine כשרת Route-Reflector. נכתוב את כל Leaf בתצורה באמצעות תבניות כדי לייעל את ההגדרה.

אז ההגדרות בעמוד השדרה נראות כך:

router bgp 65001
  template peer LEAF 
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.255.1.11
    inherit peer LEAF
  neighbor 10.255.1.12
    inherit peer LEAF
  neighbor 10.255.1.21
    inherit peer LEAF

ההגדרה במתג Leaf נראית דומה:

router bgp 65001
  template peer SPINE
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.1.101
    inherit peer SPINE
  neighbor 10.255.1.102
    inherit peer SPINE

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

Spine1# sh bgp l2vpn evpn summary
<.....>
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.1.11     4 65001       7       8        6    0    0 00:01:45 0
10.255.1.12     4 65001       7       7        6    0    0 00:01:16 0
10.255.1.21     4 65001       7       7        6    0    0 00:01:01 0

כפי שאתה יכול לראות, לא היו בעיות עם BGP. בואו נעבור להגדרת VxLAN. תצורה נוספת תתבצע רק בצד העלה של המתגים. עמוד השדרה פועל רק בתור הליבה של הרשת ומעורב רק בהעברת תעבורה. כל עבודת האנקפסולציה וקביעת הנתיב מתרחשת רק על מתגי עלה.

הגדרת NVE

NVE - ממשק וירטואלי ברשת

לפני תחילת ההגדרה, בואו נציג כמה מינוחים:

VTEP - Vitual Tunnel End Point, המכשיר בו מתחילה או מסתיימת מנהרת VxLAN. VTEP אינו בהכרח כל התקן רשת. שרת התומך בטכנולוגיית VxLAN יכול לשמש גם כשרת. בטופולוגיה שלנו, כל מתגי העלים הם VTEP.

VNI - Virtual Network Index - מזהה רשת בתוך VxLAN. ניתן לצייר אנלוגיה עם VLAN. עם זאת, ישנם כמה הבדלים. בעת שימוש במארג, רשתות VLAN הופכות ייחודיות רק בתוך מתג Leaf אחד ואינן מועברות על פני הרשת. אבל לכל VLAN יכול להיות משויך אליו מספר VNI, שכבר מועבר דרך הרשת. איך זה נראה וכיצד ניתן להשתמש בו יידונו בהמשך.

בואו נפעיל את התכונה לטכנולוגיית VxLAN לעבוד ואת היכולת לשייך מספרי VLAN למספר VNI:

feature nv overlay
feature vn-segment-vlan-based

בואו נגדיר את ממשק NVE, שאחראי על תפעול VxLAN. ממשק זה אחראי לקפסול מסגרות בכותרות VxLAN. אתה יכול לצייר אנלוגיה עם ממשק המנהרה עבור GRE:

interface nve1
  no shutdown
  host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
  source-interface loopback0    ! интерфейс  с которого отправляем пакеты loopback0

על המתג Leaf-21 הכל נוצר ללא בעיות. עם זאת, אם נבדוק את הפלט של הפקודה show nve peers, אז הוא יהיה ריק. כאן אתה צריך לחזור לתצורת VPC. אנו רואים ש-Leaf-11 ו-Leaf-12 עובדים בזוגות ומאוחדים על ידי תחום VPC. זה נותן לנו את המצב הבא:

Host-2 שולח פריים אחד לכיוון Leaf-21 כך שהוא משדר אותו דרך הרשת לכיוון Host-1. עם זאת, Leaf-21 רואה שכתובת ה-MAC של Host-1 נגישה דרך שני VTEP בו-זמנית. מה על Leaf-21 לעשות במקרה זה? אחרי הכל, זה אומר שעלולה להופיע לולאה ברשת.

כדי לפתור את המצב הזה, אנחנו צריכים את Leaf-11 ו-Leaf-12 שיפעלו גם כמכשיר אחד בתוך המפעל. הפתרון די פשוט. בממשק Loopback שממנו אנו בונים את המנהרה, הוסף כתובת משנית. הכתובת המשנית חייבת להיות זהה בשני ה-VTEPs.

interface loopback0
 ip add 10.255.1.10/32 secondary

לפיכך, מנקודת המבט של VTEPs אחרים, אנו מקבלים את הטופולוגיה הבאה:

כלומר, כעת תיבנה המנהרה בין כתובת ה-IP של Leaf-21 לבין ה-IP הווירטואלי בין שני Leaf-11 ל-Leaf-12. כעת לא יהיו בעיות ללמוד את כתובת ה-MAC משני מכשירים ותעבורה יכולה לעבור מ-VTEP אחד לאחר. מי משני ה-VTEPs יעבד את התעבורה נקבע באמצעות טבלת הניתוב בעמוד השדרה:

Spine1# sh ip route
<.....>
10.255.1.10/32, ubest/mbest: 2/0
    *via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
    *via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
    *via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
    *via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra

כפי שניתן לראות לעיל, הכתובת 10.255.1.10 זמינה באופן מיידי דרך שני Next-hops.

בשלב זה עסקנו בקישוריות הבסיסית. בואו נעבור להגדרת ממשק NVE:
בואו נפעיל מיד את Vlan 10 ונשייך אותו ל-VNI 10000 בכל עלה עבור המארחים. בואו נגדיר מנהרה L2 בין המארחים

vlan 10                 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
  vn-segment 10000      ! Ассоциируем VLAN с номер VNI 

interface nve1
  member vni 10000      ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
    ingress-replication protocol bgp    ! указываем, что для распространения информации о хосте используем BGP

עכשיו בואו נבדוק nve עמיתים ואת הטבלה עבור BGP EVPN:

Leaf21# sh nve peers
Interface Peer-IP          State LearnType Uptime   Router-Mac
--------- ---------------  ----- --------- -------- -----------------
nve1      10.255.1.10      Up    CP        00:00:41 n/a                 ! Видим что peer доступен с secondary адреса

Leaf11# sh bgp l2vpn evpn

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)        ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88                                   ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
                      10.255.1.10                       100      32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
                      10.255.1.20                       100          0 i
* i                   10.255.1.20                       100          0 i

Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

למעלה אנו רואים רק מסלולים מסוג EVPN מסלול 3. סוג זה של מסלול מדבר על עמית(Leaf), אבל איפה המארחים שלנו?
העניין הוא שמידע על מארחי ה-MAC מועבר דרך EVPN מסלול מסוג 2

על מנת לראות את המארחים שלנו, עליך להגדיר EVPN מסלול מסוג 2:

evpn
  vni 10000 l2
    route-target import auto   ! в рамках данной статьи используем автоматический номер для route-target
    route-target export auto

בואו נבצע פינג מ-Host-2 ל-Host-1:

Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 ms

ולמטה אנו יכולים לראות שמסלול מסוג 2 עם כתובת MAC מארח הופיע בטבלת BGP - 5001.0007.0007 ו-5001.0008.0007

Leaf11# sh bgp l2vpn evpn
<......>

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216                      !  evpn route-type 2 и mac адрес хоста 1
                      10.255.1.10                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216                      ! evpn route-type 2 и mac адрес хоста 2
* i                   10.255.1.20                       100          0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
                      10.255.1.10                       100      32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

לאחר מכן, תוכל לראות מידע מפורט על Update, שבו קיבלת מידע על ה-MAC Host. להלן לא כל פלט הפקודה.

Leaf21# sh bgp l2vpn evpn 5001.0007.0007

BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777        !  отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
 version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW

  Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
  AS-Path: NONE, path sourced internal to AS
    10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102)    ! с кем именно строим VxLAN тоннель
      Origin IGP, MED not set, localpref 100, weight 0
      Received label 10000         ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
      Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8        ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
      Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>

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

דיכוי-ARP

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

בעיה זו היא תעבורת BUM(Broadcast, Unknown Unicast, Multicast). במאמר זה נשקול את האפשרות להתמודד עם תעבורת שידור.
מחולל השידור העיקרי ברשתות Ethernet הוא המארחים עצמם באמצעות פרוטוקול ARP.

Nexus מיישמת את המנגנון הבא כדי להילחם בבקשות ARP - suppress-arp.
תכונה זו פועלת באופן הבא:

Host-1 שולח בקשת APR לכתובת השידור של הרשת שלו.
הבקשה מגיעה למתג Leaf ובמקום להעביר בקשה זו הלאה למארג לכיוון Host-2, Leaf מגיבה בעצמה ומציינת את ה-IP וה-MAC הנדרשים.

לפיכך, בקשת השידור לא הגיעה למפעל. אבל איך זה יכול לעבוד אם ליף יודע רק את כתובת ה-MAC?

הכל די פשוט, EVPN מסלול מסוג 2, בנוסף לכתובת MAC, יכול לשדר שילוב MAC/IP. כדי לעשות זאת, עליך להגדיר כתובת IP ב-VLAN on Leaf. נשאלת השאלה איזה IP אני צריך להגדיר? ב-nexus אפשר ליצור כתובת מבוזרת (אותה) בכל המתגים:

feature interface-vlan

fabric forwarding anycast-gateway-mac 0001.0001.0001    ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами

interface Vlan10
  no shutdown
  ip address 192.168.10.254/24          ! на всех Leaf задаем одинаковый IP
  fabric forwarding mode anycast-gateway    ! говорим использовать Virtual mac

לפיכך, מנקודת מבטם של המארחים, הרשת תיראה כך:

בוא נבדוק את BGP l2route evpn

Leaf11# sh bgp l2vpn evpn
<......>

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
                      10.255.1.21                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.10                       100          0 i
* i                   10.255.1.10                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i

<......>

Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i                   10.255.1.20                       100          0 i

<......>

מפלט הפקודה ניתן לראות שב-EVPN route-type 2, בנוסף ל-MAC, אנו רואים כעת גם את כתובת ה-IP המארח.

נחזור להגדיר suppress-arp. הגדרה זו מופעלת עבור כל VNI בנפרד:

interface nve1
  member vni 10000   
    suppress-arp

ואז מתעוררת מורכבות מסוימת:

כדי שתכונה זו תפעל, נדרש מקום בזיכרון TCAM. הנה דוגמה להגדרות עבור suppress-arp:

hardware access-list tcam region arp-ether 256

הגדרה זו תדרוש רחבה כפולה. כלומר, אם אתה מגדיר 256, אז אתה צריך לשחרר את 512 ב-TCAM. הגדרת TCAM היא מעבר לתחום של מאמר זה, שכן הגדרת TCAM תלויה רק במשימה שהוקצתה לך ועשויה להיות שונה מרשת אחת לאחרת.

יישום suppress-arp חייב להיעשות בכל מתגי העלים. עם זאת, מורכבות יכולה להתעורר בעת קביעת תצורה על זוגות עלים השוכנים בתחום VPC. אם TCAM ישתנה, העקביות בין זוגות תישבר וצומת אחד עשוי לצאת מפעילות. בנוסף, ייתכן שיידרש אתחול המכשיר כדי להחיל את הגדרת השינוי ב-TCAM.

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

בכך מסתיים החלק הראשון של הסדרה. בחלק הבא נסתכל על ניתוב דרך מארג VxLAN עם הפרדה של רשתות ל-VRFs שונים.

ועכשיו אני מזמינה את כולם סמינר מקוון חינם, שבתוכו אספר לכם בהרחבה על הקורס. 20 המשתתפים הראשונים שיירשמו לסמינר מקוון זה יקבלו תעודת הנחה בדוא"ל תוך 1-2 ימים לאחר השידור.

מקור: www.habr.com

מפעל VxLAN. חלק 1

רשת תשתית

BGP הצצה

הגדרת NVE

דיכוי-ARP

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