Skip to main content

EVPN Part 3: Routing Giữa Các VNI & Multi-Homing

Phần 3/6 trong loạt EVPN — đọc sau Phần 2: Route Types & Cách Học MAC/IP. Phần này đi sâu vào Type 5, việc kéo dài VLAN qua nhiều site, hai mô hình routing giữa các VNI (Asymmetric/Symmetric IRB), và multi-homing bằng ESI.

Ở Phần 1, Mục 7, bạn đã đi qua một luồng gói tin hoàn chỉnh theo mô hình Symmetric IRB. Phần này đặt mô hình đó bên cạnh mô hình còn lại — Asymmetric IRB — để thấy rõ vì sao ngành đã chọn Symmetric làm mặc định, đồng thời trả lời một câu hỏi còn treo lơ lửng: nếu một server cần nối tới hai leaf cùng lúc để tránh single-point-of-failure, EVPN xử lý việc đó thế nào? Đó là chủ đề của multi-homing/ESI ở Mục 4.

Ba câu hỏi cốt lõi mà phần này trả lời — và cũng là ba câu hỏi khép lại toàn bộ mảng "khái niệm" của loạt bài, trước khi Phần 4 trở lại với CLI thật:

  1. Type 5 (đã lướt qua ở Phần 2) hoạt động chi tiết ra sao, và nó phối hợp với Type 2 lẫn L2 Stretch như thế nào khi cần kéo dài một VLAN qua nhiều site (Mục 1, 2)?
  2. Giữa hai mô hình routing liên-VNI — Asymmetric và Symmetric IRB — sự đánh đổi cụ thể là gì, và vì sao gần như mọi triển khai hiện đại chọn Symmetric (Mục 3)?
  3. ESI — khái niệm đã xuất hiện thoáng qua ở Type 1 (Phần 2) — thực chất định nghĩa thế nào, và nó giải quyết bài toán gì khi một server cần nối tới nhiều leaf cùng lúc (Mục 4)?

Mục lục​

1. Type 5 — IP Prefix Route (Chi tiết)​

Phần 2 đã giới thiệu Type 5 ở mức tổng quan: nó quảng bá cả một subnet (/24, /16...) thay vì một host /32 như Type 2. Một điểm cần lưu ý ngay: Type 5 không nằm trong chuẩn EVPN gốc (RFC 7432, vốn chỉ định nghĩa Type 1–4) — nó được chuẩn hóa riêng, muộn hơn, ở RFC 9136 (2021), chính vì nhu cầu tách bạch việc quảng bá IP prefix ra khỏi route MAC/IP.

Cấu trúc route và trường GW IP​

Type 5 route mang các trường: Route Distinguisher, IP Prefix (subnet cần quảng bá), GW IP (Gateway IP — sẽ giải thích ngay dưới đây), L3 VNI (VNI để đóng gói traffic), và Route Target.

Trường GW IP là phần dễ gây nhầm lẫn nhất, vì hành vi của nó phụ thuộc vào một cấu hình gọi là advertise direct-nexthop (sẽ thấy trong CLI thật ở phần sau):

  • Không có advertise direct-nexthop: GW IP đóng vai trò một Overlay Index — một địa chỉ IP trung gian mà leaf nhận route phải tự tra tiếp qua một Type 2 route khớp đúng IP đó mới suy ra được VTEP đích thật sự (gọi là recursive resolution, vì phải "route" qua route). Địa chỉ này thường là một IRB/gateway nằm ngay trong fabric, nhưng cũng có thể là router ngoài trong trường hợp DCI — điểm mấu chốt không phải "trong hay ngoài fabric", mà là GW IP tự nó không đủ để forward, luôn cần thêm một bước tra cứu.
  • Có advertise direct-nexthop (cách làm này còn gọi là Pure Type 5): GW IP bắt buộc là 0.0.0.0 — không phải "IP của chính VTEP" như đôi khi bị hiểu nhầm. Thay vào đó, route mang kèm một thuộc tính riêng gọi là router's MAC extended community (đi cùng next-hop BGP chính là VTEP gốc phát ra route), nên leaf nhận route có đủ thông tin để gửi thẳng VXLAN tới VTEP đó mà không cần recursive resolution qua Type 2 nào cả — đơn giản hơn và phổ biến hơn trong một data center thuần EVPN.

Type 5 /24 vs Type 2 /32 — ai thắng khi trùng match?​

Vì hai loại route có thể tồn tại đồng thời cho cùng một dải địa chỉ, cần biết cái nào được ưu tiên. Nguyên tắc longest-prefix-match truyền thống vẫn áp dụng: Type 2 luôn cụ thể hơn (một địa chỉ /32 duy nhất), Type 5 chỉ là một subnet tổng quát hơn (/24). Nếu một leaf nhận cả 10.1.1.10/32 (qua Type 2) lẫn 10.1.1.0/24 (qua Type 5), lookup cho 10.1.1.10 sẽ match Type 2 (dài hơn, cụ thể hơn); lookup cho một IP khác trong cùng subnet như 10.1.1.99 (chưa có Type 2 host route riêng) sẽ rơi vào Type 5.

Type 5 dùng cho DCI (Datacenter Interconnect)​

Khi hai data-center riêng biệt (DC-1 với subnet 10.1.0.0/16, DC-2 với 10.2.0.0/16) cần thông nhau qua WAN, mỗi Border Leaf (leaf biên, có kết nối ra ngoài fabric) học route từ WAN qua eBGP thông thường, rồi quảng bá lại vào EVPN fabric dưới dạng Type 5. Các leaf nội bộ nhận Type 5 này, biết "muốn đến 10.2.0.0/16 thì gửi VXLAN tới Border Leaf", và Border Leaf sẽ forward tiếp ra WAN.

Type 5 for DCI (Datacenter Interconnect)DC-1 (10.1.0.0/16)Leaf-IntBorder LeafBorder Leaf nhận Type-5:10.2.0.0/16 via WAN (eBGP)→ re-advertise vào EVPN fabricLeaf-Int học được route này→ gửi VXLAN tới Border Leafkhi cần đến 10.2.0.0/16DC-2 (10.2.0.0/16)Border LeafLeaf-IntWAN / DCI linkMỗi Border Leaf vừa là "cửa vào" EVPN fabric, vừa là "cửa ra" tới WAN

2. L2 Stretch — Extend VLAN qua nhiều site​

L2 Stretch (còn gọi là L2 Extension hay DCI L2) nghĩa là kéo dài cùng một VLAN qua nhiều site vật lý khác nhau — host ở site A và site B vẫn nằm chung một subnet, chung một broadcast domain, dù về mặt vật lý chúng cách xa nhau qua một kết nối WAN.

Cách EVPN model hóa việc này: DCI link được xem như một Ethernet Segment (ESI) — đúng khái niệm đã lướt qua ở Phần 2, Mục 3, sẽ được định nghĩa đầy đủ ở Mục 4 dưới đây. Mọi leaf trong cùng một site chia sẻ chung một ESI, để site đối diện biết được "có bao nhiêu đường vào site này".

L2 Stretch: Same VLAN Across Two SitesSite A — ESI=0x0011...Leaf-A1Leaf-A2VM-A10.1.1.10VLAN 100, cùng subnet 10.1.1.0/242 Leaf cùng gửi Type-1 Per-EVI→ Site B thấy 2 đường vào Site ASite B — ESI=0x0033...Leaf-B1Leaf-B2VM-B10.1.1.20DCI (VXLAN, VNI 1000 extended)VM-A và VM-B nói chuyện qua ARP thuần L2 — như thể chung một switch

Type 1 đóng ba vai trò trong L2 Stretch, và cả ba đều là hệ quả trực tiếp của việc "có ESI dùng chung giữa nhiều leaf" mà bạn đã học ở Phần 2:

  1. Aliasing — nếu VM-B gửi cho VM-A, Type 2 chỉ nói "MAC=VM-A qua Leaf-A1", nhưng Type 1 Per-EVI cho biết ESI đó cũng reachable qua Leaf-A2 → Site B có thể load-balance traffic trên cả hai đường DCI.
  2. Fast convergence — nếu Leaf-A1 down, một Type 1 Per-ES withdraw duy nhất báo ngay cho Site B biết "mất đường qua Leaf-A1", chuyển hết traffic sang Leaf-A2 mà không cần chờ MAC aging timeout.
  3. Split horizon — ngăn BUM traffic bị bounce qua lại vô tận giữa hai site, dùng đúng cơ chế Local Bias (so khớp source VTEP IP với danh sách NVE cùng ES) đã giải thích ở Phần 2.

So sánh L2 Stretch với Type-5 DCI​

L2 Stretch (Type 1 + Type 2)DCI qua Type 5
LayerL2 — cùng subnet, cùng VLANL3 — khác subnet, cần routing
Giao tiếpQua ARP, không cần gatewayCần gateway/routing
BUM trafficCó, flood qua DCIKhông có (chỉ routing)
Dùng khiVM migration, ứng dụng phụ thuộc L2Routing liên DC, microservice
Khả năng mở rộngKém hơn (BUM đi qua WAN)Tốt hơn

3. Inter-VXLAN Routing — Asymmetric vs Symmetric IRB​

Phần 1, Mục 7 đã trình bày chi tiết Symmetric IRB qua một luồng gói tin cụ thể. Mục này đặt nó cạnh mô hình còn lại — Asymmetric IRB — để bạn thấy rõ sự đánh đổi giữa hai lựa chọn. Cả hai đều thuộc IRB (Integrated Routing and Bridging — tích hợp routing và bridging vào một cơ chế duy nhất), được chuẩn hóa chính thức ở RFC 9135.

Bài toán chung của cả hai mô hình: VM-A ở VNI 1000 (10.1.1.0/24) muốn nói chuyện với VM-X ở VNI 2000 (10.2.2.0/24) — khác subnet, chắc chắn cần định tuyến (routing) qua một gateway.

Model 1: Asymmetric IRB (đi cùng Anycast Gateway toàn diện)​

Trong Asymmetric IRB, mọi leaf đều có SVI/IRB cho tất cả VNI — không chỉ VNI mà nó đang host cục bộ. Nghĩa là Leaf1 có cả irb.1000 lẫn irb.2000, dù có thể không có VM nào của VNI 2000 nằm trên Leaf1.

Asymmetric IRB — Routing Happens at Ingress LeafLeaf1 — có irb.1000 VÀ irb.2000VM-A (VNI1000)① route LOCAL tại Leaf1 (có irb.2000!)② Encap VNI đích = 2000 (L2 VNI)Leaf2③ VNI=2000 → chỉ cầnbridge (không route lại)Forward thẳng tới VM-XNhược điểm: Leaf1 phải lưu MAC table cho TẤT CẢ VNI, kể cả không host VM nào ở đó

Với dữ liệu VM-A gửi cho VM-X (ở Leaf2, VNI 2000): Leaf1 nhận packet tại irb.1000 (địa chỉ Anycast MAC giống hệt trên mọi leaf), và vì Leaf1 cũng có irb.2000 cục bộ, nó route ngay tại chỗ (routing "local", ngay tại leaf tiếp nhận — đây là ý nghĩa của "asymmetric": việc lookup diễn ra bất đối xứng, chỉ một phía). Sau khi route xong, Leaf1 tra bảng EVPN để biết MAC của VM-X nằm ở VTEP nào, rồi đóng gói VXLAN với VNI đích chính là Layer 2 VNI của VNI 2000 (không phải một VNI L3 riêng). Leaf2 nhận, chỉ cần bridge thuần túy layer 2 — không cần route lại.

Ưu điểm: đơn giản, không cần Layer 3 VNI riêng. Nhược điểm: mỗi leaf phải lưu MAC table cho toàn bộ VM trong toàn bộ VNI (kể cả VNI nó không host VM nào) — không mở rộng tốt khi số lượng VNI lên tới hàng nghìn.

Model 2: Symmetric IRB (dùng L3 VNI riêng) — mô hình đã học ở Phần 1​

Khác với Asymmetric, ở Symmetric IRB mỗi leaf chỉ có IRB cho VNI nó thực sự host cục bộ. Leaf1 chỉ có irb.1000, không có irb.2000 — nên khi cần route sang VNI 2000, Leaf1 không thể tự route local được nữa. Đây chính xác là lý do cần một Layer 3 VNI riêng (đã học ở Phần 1): Leaf1 dùng route Type 5 (10.2.2.0/24 tại VTEP của Leaf2, L3 VNI 50000) để biết cần gửi gói tới đâu, đóng gói với VNI = Layer 3 VNI (không phải L2 VNI đích), và Leaf2 khi nhận sẽ route lại một lần nữa trong VRF của nó trước khi bridge ra irb.2000 tới VM-X — đây là ý nghĩa của "symmetric": cả hai đầu (ingress lẫn egress leaf) đều thực hiện một bước route giống nhau, đối xứng.

Ưu điểm: mỗi leaf chỉ cần MAC table cho VM cục bộ — mở rộng tốt hơn nhiều. Nhược điểm: phức tạp hơn, cần cấu hình Layer 3 VNI riêng cho mỗi VRF tenant.

So sánh trực diện hai mô hình​

Asymmetric IRBSymmetric IRB
IRB trên mỗi leafTất cả VNI (Anycast GW toàn diện)Chỉ VNI cục bộ
Routing diễn ra ởIngress leaf (một lần)Cả ingress lẫn egress leaf (hai lần)
VNI dùng trong tunnelL2 VNI đíchL3 VNI (VRF VNI)
MAC table cần lưuToàn bộ VM từ xaChỉ VM cục bộ
Khả năng mở rộngKém hơnTốt hơn
Phổ biến ởData center nhỏ/vừaData center lớn

Trong thực tế triển khai hiện đại (kể cả trên Junos, sẽ thấy ở phần sau), Symmetric IRB gần như luôn là lựa chọn mặc định, vì lợi thế về khả năng mở rộng thường quan trọng hơn độ đơn giản của Asymmetric.

4. EVPN Multi-Homing (ESI)​

Phần 2, Mục 3 đã dùng ESI xuyên suốt phần giải thích Type 1 — fast convergence, aliasing, split horizon — nhưng luôn nói "sẽ định nghĩa kỹ hơn ở Phần 3". Mục này chính là lời hứa đó: quay lại từ đầu bài toán ESI thực sự giải quyết là gì, trước khi ráp nó vào đúng những cơ chế Type 1 đã dùng.

Vấn đề cần giải quyết: một điểm lỗi duy nhất (SPOF)​

Nếu một server chỉ nối tới đúng một leaf, leaf đó (hoặc link nối tới nó) chết là server mất mạng hoàn toàn — một single point of failure kinh điển. Giải pháp tự nhiên: nối server tới hai leaf khác nhau cùng lúc. Nhưng làm vậy đặt ra một câu hỏi mới: hai leaf đó phải phối hợp với nhau thế nào để không gửi trùng lặp traffic, không tạo loop? Đây chính là vấn đề mà multi-homing giải quyết, và công cụ trung tâm là ESI.

ESI là gì?​

ESI (Ethernet Segment Identifier) là một định danh 10 byte, dùng để đánh dấu "nhóm các link cùng nối tới một thiết bị đầu cuối" — thường lấy từ LACP system ID hoặc cấu hình thủ công. Khi cả Leaf1 và Leaf2 cùng khai báo chung một ESI cho link nối tới cùng một server, chúng "biết" nhau: "chúng ta đang cùng phục vụ một thiết bị, cần phối hợp."

Single-Active vs Active-Active​

Có hai chế độ vận hành khi multi-home:

  • Single-Active: một leaf đóng vai trò primary (forward traffic), leaf còn lại là standby thuần túy. Đơn giản, không phải lo về loop, nhưng không tận dụng được cả hai đường cùng lúc.
  • Active-Active (RFC gọi chính thức là All-Active, nhưng "active-active" là cách gọi phổ biến trong tài liệu vendor — kể cả Junos CLI dùng keyword all-active): cả hai leaf đều forward traffic đồng thời (server dùng LACP/bond gộp hai link vật lý thành một logic). Tận dụng 100% băng thông cả hai đường, và khi một leaf down, traffic chuyển ngay sang leaf còn lại mà không cần chờ gì cả.

Designated Forwarder (DF) — ai được phép flood BUM?​

Active-Active tạo ra một vấn đề mới: nếu BUM traffic cần flood tới server, và cả hai leaf đều forward, server sẽ nhận hai bản sao trùng nhau của cùng một gói. Giải pháp: chỉ định đúng một leaf trong nhóm ESI được phép flood BUM tới server tại một thời điểm — leaf đó gọi là Designated Forwarder (DF).

Designated Forwarder Election (Active-Active)Server (LACP bond)ESI=0x0011...Leaf1 — DFUnicast: forward ✓BUM: forward tới server ✓Leaf2 — non-DFUnicast: forward ✓BUM: KHÔNG forward tới serverNếu Leaf1 (DF) down:Leaf2 tự bầu thành DF mới → tiếp tục forward BUM cho server

Việc bầu DF thực chất là một route riêng: Type 4 (Ethernet Segment Route) — mang thông tin về ESI và danh sách leaf đang tham gia, dùng để chạy thuật toán bầu chọn. Thuật toán mặc định trong chuẩn gốc RFC 7432 gọi là "service carving", dựa trên phép chia lấy dư (modulo) giữa số lượng PE tham gia ESI và giá trị VLAN. Thuật toán này có một số hạn chế về hiệu quả khi số lượng PE lớn hoặc cần ưu tiên theo trạng thái attachment circuit — các thuật toán DF mở rộng, linh hoạt hơn (như HRW — Highest Random Weight) được chuẩn hóa sau này ở RFC 8584.

Nhìn lại chặng đường Phần 1–3, trước khi sang cấu hình thật​

Ba phần vừa qua, dù đọc riêng lẻ có thể thấy như ba chủ đề khác nhau, thực chất là một mạch lập luận liền mạch — mỗi phần chỉ tồn tại để trả lời đúng một câu hỏi mà phần trước đó để ngỏ:

  • Phần 1 trả lời "vì sao cần EVPN": leaf-spine buộc phải thuần layer 3, nhưng vMotion cần layer 2 — EVPN là câu trả lời cho mâu thuẫn đó, bằng cách dùng route (MP-BGP) thay cho flood để "stretch" một VLAN qua hạ tầng layer 3.
  • Phần 2 mở khóa câu hỏi "route đó trông như thế nào": 5 loại route type, mỗi loại trả lời một câu hỏi riêng (ai ở đâu, VNI nào có mặt ở VTEP nào, ai đang multi-homed), rồi ráp lại thành một luồng học MAC/IP hoàn chỉnh — và luồng đó chính là cơ chế đứng sau ARP Suppression mà Phần 1 đã hứa hẹn.
  • Phần 3 khép lại mảng khái niệm bằng hai câu hỏi còn sót: định tuyến giữa các VNI khác subnet thế nào (Asymmetric/Symmetric IRB, và cả trường hợp mở rộng ra ngoài fabric qua Type 5/DCI), và một thiết bị vật lý có thể nối tới nhiều leaf cùng lúc ra sao mà không tạo loop hay duplicate traffic (ESI/multi-homing) — cả hai đều là hệ quả trực tiếp của những khái niệm nền tảng (Route Target, VTEP, split-horizon) đã đặt ra từ Phần 1.

Nói cách khác: không có khái niệm nào trong ba phần này đứng một mình. RT từ Phần 1 quay lại ở khắp Phần 2 và Phần 3; ESI được Type 1 dùng ở Phần 2 rồi mới được định nghĩa đầy đủ ở Phần 3; ARP Suppression được Phần 1 nêu tên rồi Phần 2 mới giải thích được vì sao nó hoạt động. Đây chính là lý do nên đọc cả ba phần liền mạch, thay vì tra cứu rời rạc từng mục khi cần.

Từ đây, bạn đã có đủ nền tảng khái niệm để đọc một output CLI thật (show route table bgp.evpn.0, show evpn database...) mà không bị choáng ngợp — bạn sẽ nhận ra ngay từng trường trong route đang nói về loại nào trong 5 route type, đang phục vụ MAC VRF hay IP VRF, và vì sao nó tồn tại. Đó chính xác là nội dung của Phần 4.

Tiếp theo: Cấu Hình, Kiểm Tra & Xử Lý Sự Cố (đang note lại, sẽ đăng dần theo tuần)

Nguồn tham khảo​

Đính chính/bổ sung kỹ thuật (từ fact-check, không có trong nội dung gốc):

  • Type 5 (IP Prefix Route) được chuẩn hóa ở RFC 9136 (2021) — không nằm trong RFC 7432 gốc như thường bị hiểu nhầm.
  • Asymmetric/Symmetric IRB được định nghĩa chính thức ở RFC 9135 (2021).
  • Thuật toán DF election mặc định ("service carving") nằm trong RFC 7432; các thuật toán mở rộng (bao gồm HRW) được chuẩn hóa ở RFC 8584.
  • GW IP khi dùng làm Overlay Index cần recursive resolution qua Type 2 route; khi không dùng (chế độ advertise direct-nexthop/Pure Type 5) GW IP bắt buộc là 0.0.0.0, forward dựa vào router's MAC extended community — RFC 9136, Juniper — Understanding EVPN Pure Type 5 Routes.
  • Split-horizon cho EVPN-VXLAN dùng cơ chế Local Bias (so khớp source VTEP IP với danh sách NVE cùng ES), không phải nhét ESI vào gói tin như EVPN-MPLS — RFC 8365 §8.3.1.
  • RFC 7432 §3 gọi chế độ multi-homing "cả hai leaf cùng forward" là All-Active Redundancy Mode; "Active-Active" là cách gọi phổ biến theo tài liệu vendor (kể cả Junos CLI keyword all-active) — RFC 7432 §3.