EVPN Part 3: Route Types & Cách Học MAC/IP
Loạt EVPN (7 phần): 1. Vì sao cần EVPN & Fabric · 2. MAC VRF & IP VRF · 3. Route Types & MAC/IP · 4. Inter-VNI & Multi-Homing · 5. Cấu hình & Troubleshooting · 6. Routing Table nội bộ · 7. Multi-Site RT & Route Leak (sắp đăng)
Phần 3/7 trong loạt EVPN: đọc sau Phần 2: Hai Loại VRF — MAC VRF & IP VRF. Từ đây bắt đầu đi vào cơ chế cụ thể: kiến trúc control plane/data plane, các loại route EVPN, và luồng học MAC/IP thực tế. Vẫn chưa cần cấu hình.
Phần 1 đã trả lời câu hỏi "vì sao cần EVPN" và dựng xong fabric; Phần 2 giới thiệu MAC VRF (Type 2 route) ở mức tổng quan. Phần này đào sâu hơn vào cơ chế: EVPN thực chất có 5 loại route khác nhau (đánh số Type 1 đến Type 5), mỗi loại trả lời một câu hỏi riêng biệt. Hiểu rõ route nào làm gì là nền tảng để đọc được show route table bgp.evpn.0 sau này mà không bị choáng ngợp bởi một rừng route lạ mắt.
Hai câu hỏi cốt lõi mà phần này trả lời:
- EVPN có đúng 5 loại route, mỗi loại trả lời một câu hỏi riêng. Vậy Type 2 (đã lướt qua ở Phần 2) và Type 1 (khái niệm mới) làm đúng việc gì, và chúng khác nhau ở điểm nào (Mục 2, 3)?
- Ghép toàn bộ route type đó lại thành một luồng thực tế (từ lúc một VM khởi động tới lúc VM khác ping được nó mà không hề flood) thì trông như thế nào, và vì sao chính luồng đó lại là nền tảng của ARP Suppression, cơ chế mà Phần 1 đã treo lại như một lời hứa (Mục 4, 5)?
Mục lục
- 1. Kiến trúc EVPN + VXLAN
- 2. EVPN Route Types — Tổng quan
- 3. Type 1 — Ethernet Auto-Discovery (Chi tiết)
- 4. Luồng học MAC/IP thực tế
- 5. ARP Suppression
1. Kiến trúc EVPN + VXLAN
Trước khi vào chi tiết route type, cần một bức tranh tổng thể: EVPN luôn được chia làm hai tầng tách biệt, và việc phân biệt rạch ròi hai tầng này là chìa khóa để không bị rối khi troubleshoot sau này.
- Control plane (EVPN/BGP): chạy trên CPU của switch, chỉ làm đúng một việc là trả lời câu hỏi "địa chỉ MAC/IP này đang ở VTEP nào, VNI nào?". Control plane không tự nó chuyển bất kỳ gói tin thật nào.
- Data plane (VXLAN): chạy trên ASIC (phần cứng chuyên dụng) để đạt tốc độ đường truyền, đóng gói và gửi packet thật, chỉ dựa vào thông tin mà control plane đã học được.
Route Reflector — vì sao không để mọi Leaf tự peer với nhau?
Phần 1, Mục 3 đã giải thích gốc rễ kỹ thuật của vấn đề này: luật iBGP split-horizon cấm một router re-advertise route học được từ một iBGP peer cho một iBGP peer khác. Nếu để leaf tự peer trực tiếp với nhau, không leaf nào được phép "chuyển tiếp hộ" route của leaf khác, và mỗi leaf buộc phải tự full-mesh với toàn bộ leaf còn lại.
Con số cụ thể cho thấy "buộc phải" không phải cách nói cường điệu: 10 leaf full-mesh cần 45 session (10×9/2), nhưng 100 leaf đã cần tới 4.950 session. Không thiết bị nào chịu nổi số session đó, về cả CPU lẫn công sức vận hành.
Giải pháp: dùng Route Reflector (RR), thường đặt tại spine. Vai trò của RR là được phép "phá luật" split-horizon một cách có kiểm soát (bù lại, loop được ngăn bằng cơ chế khác: route-reflector cluster-list/originator-id, như Phần 1 đã nói). Mỗi leaf chỉ cần một session BGP duy nhất tới RR; RR nhận route từ một leaf rồi "phản chiếu" (reflect) đến toàn bộ leaf còn lại. Với cách này, 100 leaf chỉ cần 100 session: mỗi leaf một session tới RR, thay vì gần 5.000 session full-mesh.
2. EVPN Route Types — Tổng quan
EVPN có 5 loại route khác nhau, gọi là Type 1 đến Type 5. Mỗi loại mang một thông tin riêng và trả lời một câu hỏi khác nhau. Mục này đi qua cả năm loại, nhưng cố ý không theo thứ tự số, nên cần nói rõ trình tự để tránh bị lạc: Type 2, Type 3, Type 5 được giải thích trước vì chúng có mặt trong mọi fabric EVPN, kể cả fabric đơn giản nhất chỉ một server nối vào một leaf. Type 4 và Type 1 đi sau, vì cả hai chỉ xuất hiện khi một thiết bị được nối tới nhiều leaf cùng lúc. Riêng Type 1 có nhiều cơ chế con nên được tách thành một mục riêng ngay sau đây.
Type 2 — "MAC/IP Advertisement" (quan trọng nhất)
Type 2 là loại route gặp nhiều nhất khi debug EVPN. Nó trả lời câu hỏi đơn giản nhất và cũng quan trọng nhất: "Host có MAC=X (và IP=Y) đang nằm ở VTEP nào?"
Type 2 được gửi khi: có VM/host mới kết nối vào leaf, khi VM gửi ARP lần đầu (leaf học được cặp MAC+IP), hoặc khi VM di chuyển sang leaf khác (vMotion). Route mang theo: địa chỉ MAC, địa chỉ IP (tùy chọn: có thể chỉ có MAC), địa chỉ VTEP nơi host cư trú, VNI, và Route Target.
Khi một leaf khác nhận Type 2 route này, nó biết ngay: "muốn gửi cho MAC này, phải gửi VXLAN tới VTEP đó", rồi cài thông tin vào MAC table và ARP cache cục bộ. Từ đó, không cần flood nữa mỗi khi có ai muốn liên lạc với host đó.
Route Type 2 thực ra mang nhiều hơn những gì vừa liệt kê ở trên. Phần 2, Mục 4 đã hé lộ nó còn kèm một Sequence Number (để phân biệt "host vừa vMotion sang leaf khác" với "hai leaf đang tranh chấp cùng một MAC") và hai Route Target cùng lúc: một khớp Layer 2 VNI để cài vào MAC VRF (đúng thứ đang nói ở đây), một khớp Layer 3 VNI để mọi leaf trong tenant, kể cả leaf không host VLAN đó, vẫn cài được host route /32 vào IP VRF của mình.
Mục này tạm gác chi tiết đó sang một bên để tập trung đúng vào câu hỏi cốt lõi của Type 2 ("host này ở VTEP nào"). Nhưng khi đọc show route table bgp.evpn.0 ở phần cấu hình sau, cả hai RT và Sequence Number đều hiện ra ngay trong route thật.
Type 3 — "Inclusive Multicast Ethernet Tag" (xây dựng danh sách BUM)
Trước khi giải thích Type 3, cần định nghĩa một thuật ngữ sẽ gặp thường xuyên: BUM traffic, viết tắt của Broadcast, Unknown-unicast, Multicast. Đây là loại traffic mà switch phải flood ra nhiều nơi vì không biết đích chính xác (ví dụ: ARP request là broadcast, hoặc một frame gửi tới MAC chưa từng học được).
Trong mạng LAN truyền thống, flood đơn giản là "gửi ra mọi port trừ port vào". Nhưng trong EVPN, các leaf không nối trực tiếp layer 2 với nhau. Vậy khi cần flood BUM traffic của một VNI, một leaf phải biết chính xác những leaf nào khác đang có VNI đó để gửi bản sao tới đúng chúng, thay vì gửi mù tới tất cả leaf trong toàn fabric (kể cả những leaf không hề có VNI đó). Type 3 chính là cơ chế xây dựng danh sách này, gọi là ingress-replication list.
Type 3 được gửi khi một leaf bật một VNI lên (có ít nhất một VM tham gia VNI đó), mang theo: VNI và địa chỉ VTEP của leaf đó ("tôi đang có VNI này"). Khi leaf khác nhận Type 3, nó ghi nhớ: "leaf đó cũng có VNI này, nếu cần flood BUM trong VNI này thì gửi thêm một bản sao đến VTEP đó."
Type 5 — "IP Prefix Route" (routing giữa các VNI)
Type 5 quảng bá một IP subnet (ví dụ /24, /16) thay vì một host cụ thể, khác hẳn Type 2 vốn chỉ quảng bá từng host /32. Dùng khi: một VM trong VNI này cần đến VNI khác, cần ra Internet, hoặc kết nối liên data-center (DCI: Datacenter Interconnect).
Type 5 sẽ được trình bày chi tiết ở phần sau, vì nó gắn chặt với khái niệm Layer 3 VNI/Symmetric IRB đã học ở Phần 2, Mục 3. Ở đây chỉ cần nhớ một điểm khác biệt cốt lõi: Type 2 route từng host /32, Type 5 route cả một subnet.
Type 4 — "Ethernet Segment Route" (bầu Designated Forwarder)
Type 4 cũng chỉ xuất hiện khi có multi-homing, và vấn đề nó giải quyết rất cụ thể: nếu một server được nối tới hai leaf cùng lúc, và cả hai leaf đều flood BUM traffic xuống server, server sẽ nhận hai bản sao trùng nhau của cùng một gói. Để tránh chuyện đó, tại một thời điểm chỉ đúng một leaf trong nhóm được phép flood BUM xuống server. Leaf giữ quyền đó gọi là Designated Forwarder (DF).
Type 4 mang theo ESI cùng danh sách các leaf đang tham gia Ethernet Segment đó, để nhóm leaf tự chạy thuật toán bầu chọn và thống nhất ai là DF, không cần một thiết bị trung tâm nào đứng ra điều phối. Thuật toán bầu DF cùng định nghĩa đầy đủ của ESI nằm ở Phần 4; ở đây chỉ cần nhớ Type 4 tồn tại để trả lời đúng một câu hỏi: trong nhóm leaf cùng phục vụ một server, ai được quyền flood.
Tóm tắt 5 loại route
Bảng dưới xếp lại theo thứ tự số, kèm cột cuối cho biết đọc chi tiết từng loại ở đâu trong loạt bài, để không phải đi tìm:
| Type | Trả lời câu hỏi gì | Dùng cho | Đọc chi tiết ở |
|---|---|---|---|
| Type 1 | "Tôi đang multi-homed" | Fast convergence + aliasing | Mục 3 ngay dưới đây |
| Type 2 | "Host cụ thể ở đâu?" | L2 forwarding, ARP suppression | Mục này + Phần 2, Mục 4 |
| Type 3 | "VTEP nào có VNI nào?" | Xây ingress-replication list cho BUM | Mục này |
| Type 4 | "Ai là Designated Forwarder cho ESI này?" | Bầu DF khi có multi-homing | Mục này + Phần 4, Mục 3 |
| Type 5 | "Subnet này ở đâu?" | Inter-VNI routing, exit ra ngoài | Phần 4, Mục 1 |
3. Type 1 — Ethernet Auto-Discovery (Chi tiết)
Type 1 chỉ thực sự cần thiết khi một thiết bị (server, switch) được nối tới nhiều hơn một leaf cùng lúc, tức multi-homing (nói kỹ ở phần sau). Type 1 có hai subtype, phân biệt qua giá trị Ethernet Tag, mỗi subtype giải quyết một vấn đề khác nhau:
| Subtype | Ethernet Tag | Mục đích |
|---|---|---|
| Per-ES | 0xFFFFFFFF | Fast convergence (rút toàn bộ route cùng lúc khi 1 leaf down) |
| Per-EVI | 0 (VLAN-based service, phổ biến nhất trong EVPN-VXLAN) hoặc VLAN ID (VLAN-aware bundle) | Aliasing (load balancing active-active) |
Subtype 1: Per-ES — Fast Convergence
Xét một server kết nối active-active tới cả Leaf1 và Leaf2 qua ESI (Ethernet Segment Identifier: định danh cho "nhóm link cùng nối tới một thiết bị", sẽ định nghĩa kỹ hơn ở Phần 4), và trên server đó có tới 500 VM. Nếu Leaf1 đột ngột down mà không có Type 1, hệ thống phải gửi 500 lần BGP WITHDRAW riêng lẻ (một cho mỗi MAC học qua Type 2). Việc đó mất vài giây, và trong lúc đó traffic bị drop.
Với Type 1 Per-ES: khi Leaf1 hoạt động, nó gửi một route duy nhất {ESI: ..., Ethernet Tag: 0xFFFFFFFF} nghĩa là "ESI này reachable qua tôi". Khi Leaf1 down, BGP session sập, kéo theo một lần withdraw duy nhất cho route này: các leaf khác lập tức hiểu "toàn bộ MAC học qua Leaf1 trên ESI này giờ không còn hợp lệ" mà không cần chờ 500 withdraw riêng lẻ. Một route thay cho hàng trăm/nghìn withdraw → hội tụ (convergence) nhanh hơn rất nhiều.
Subtype 2: Per-EVI — Aliasing
Vấn đề khác: server active-active gửi frame ra ngoài, nhưng do cơ chế LACP chọn link, ban đầu traffic chỉ đi qua Leaf1. EVPN chỉ học được MAC của server đó từ Leaf1 (vì chỉ Leaf1 nhìn thấy traffic), nên Type 2 route chỉ ghi "MAC=Server ở VTEP1". Hệ quả: mọi leaf khác trong fabric muốn gửi cho server này đều gửi tới Leaf1, dù Leaf2 đang rảnh và cũng có thể nhận.
Type 1 Per-EVI giải quyết việc này: cả Leaf1 và Leaf2 cùng gửi Type 1 Per-EVI với cùng một ESI. Leaf khác nhận thấy: "Type 2 nói MAC này ở Leaf1, nhưng Type 1 nói ESI này cũng reachable qua Leaf2", tức là dù chỉ học MAC từ một leaf, tôi biết leaf kia cũng nhận được → có thể load-balance traffic luân phiên giữa cả hai.
Split Horizon — dùng Local Bias để tránh loop
Với topology active-active như trên, BUM traffic từ một VTEP xa gửi đến Leaf1, Leaf1 flood ra ESI tới server, server lại forward lên Leaf2 (vì cùng nối tới server). Nếu Leaf2 forward gói đó ngược lại vào fabric, sẽ tạo loop.
Split horizon giải quyết việc này bằng cơ chế gọi là Local Bias: Leaf2 nhìn vào source IP của tunnel VXLAN (chính là địa chỉ VTEP nơi gói tin xuất phát, ở đây là VTEP của Leaf1), rồi so với danh sách các VTEP đang cùng chia sẻ ESI với mình (danh sách này Leaf2 tự xây được từ các route Type 1/Type 4 đã học trước đó). Vì VTEP nguồn (Leaf1) nằm trong chính danh sách đó, Leaf2 biết gói tin vừa đi ra từ một VTEP khác cũng đang phục vụ cùng server. Leaf2 kết luận server chắc chắn đã nhận gói này rồi, nên drop, không forward ngược ra fabric.
Một điểm dễ nhầm: khác với EVPN chạy trên MPLS (nơi ESI được nhét thẳng vào một trường label riêng trong gói tin), VXLAN header không hề mang theo ESI: toàn bộ quyết định drop/forward chỉ dựa vào việc so khớp địa chỉ VTEP nguồn với danh sách cục bộ, chứ không phải so khớp một giá trị ESI nằm ngay trong gói tin.
4. Luồng học MAC/IP thực tế
Ghép mọi khái niệm ở trên lại sẽ được một kịch bản hoàn chỉnh, đi qua từng bước một.
Bối cảnh: VM-A (MAC=AA, IP=10.1.1.10, VLAN 100) vừa khởi động trên Leaf1 (VTEP 10.0.0.1); VM-B (MAC=BB, IP=10.1.1.20, VLAN 100) đã có sẵn trên Leaf2 (VTEP 10.0.0.2); VNI 1000 map với VLAN 100; Route Reflector là Spine-01.
Giai đoạn 1: VM-A gửi GARP. Khi khởi động, VM-A tự động gửi một GARP (Gratuitous ARP: một dạng ARP "tự quảng cáo", VM chủ động thông báo "tôi là 10.1.1.10, MAC của tôi là AA" mà không cần ai hỏi trước). Leaf1 nhận GARP này, học được cặp MAC+IP+port, và tạo một BGP Type 2 route: {MAC=AA, IP=10.1.1.10, VTEP=10.0.0.1, VNI=1000}.
Giai đoạn 2: Leaf1 gửi Type 2 tới Route Reflector. Route được gửi qua BGP UPDATE, mang kèm Route Distinguisher, MAC, IP, VNI (đóng vai trò label), next-hop, và Route Target.
Giai đoạn 3: Route Reflector phản chiếu tới mọi Leaf. Spine nhận route và gửi tiếp tới Leaf2, Leaf3, Leaf4... Leaf2 thấy RT khớp với VNI 1000 cục bộ, nên cài route vào MAC table (AA → VTEP 10.0.0.1, VNI 1000) và ARP cache (10.1.1.10 → MAC AA), chuẩn bị sẵn cho ARP suppression ở Mục 5.
Giai đoạn 4: VM-B ping VM-A lần đầu. VM-B gửi ARP hỏi "ai có IP 10.1.1.10?". Leaf2 tra ARP cache, đã thấy sẵn 10.1.1.10 → MAC AA (học được từ EVPN ở Giai đoạn 3!), nên proxy-reply ngay lập tức, không hề flood ARP ra ngoài. VM-B nhận reply, học 10.1.1.10 → MAC AA, gửi ICMP. Leaf2 tra MAC table, thấy AA → VTEP 10.0.0.1, đóng gói VXLAN và gửi qua underlay tới Leaf1. Kết quả: ping thành công mà không có bất kỳ gói BUM flood nào trên fabric.
5. ARP Suppression — Tính năng quan trọng nhất
Phần 1, Mục 2 đã nhắc tới cơ chế này như một lời hứa còn treo lại: "leaf nhận request tự trả lời thay cho gateway... Cách leaf tra đúng thông tin để trả lời sẽ rõ hơn khi học route Type 2 ở phần sau." Mục 4 vừa rồi là câu trả lời đầy đủ cho lời hứa đó: Giai đoạn 4 ở trên là ví dụ sống của ARP Suppression đang hoạt động, chỉ là chưa được gọi tên. Mục này gọi tên chính thức và đào sâu thêm.
Vì sao ARP Suppression quan trọng đến vậy?
Thử một phép tính: một data center có 10.000 VM, mỗi VM gửi ARP request trung bình 1 lần mỗi 5 phút (do ARP cache timeout tự nhiên của hệ điều hành). Không có ARP Suppression, mỗi ARP request đó phải flood đến toàn bộ VTEP khác trong fabric: với 200 VTEP, một ARP request duy nhất tạo ra 199 gói BUM. Nhân lên: 2.000 ARP/phút × 199 = gần 400.000 gói/phút chỉ riêng cho ARP, chưa kể unknown-unicast và multicast khác cộng dồn vào.
Với ARP Suppression: leaf cục bộ trả lời thay cho host đích (dựa vào thông tin đã học qua Type 2 route, như đã thấy ở Mục 4). ARP request không bao giờ rời khỏi leaf switch. Về lý thuyết, lượng BUM traffic riêng cho ARP giảm về gần như 0.
ARP Suppression table
Trên thiết bị, bảng này thường xem được qua lệnh tương tự show evpn arp-table, với các cột IP, MAC, VTEP, VNI, và Source (phân biệt route học từ EVPN hay từ ARP cục bộ). Khi có VM hỏi ARP cho một IP đã có trong bảng, leaf tra thấy VTEP tương ứng và proxy-reply ngay lập tức bằng đúng MAC đã ghi nhớ: traffic không bao giờ phải flood ra khỏi leaf.
💡 Điều kiện tiên quyết: ARP Suppression chỉ hoạt động sau khi EVPN đã học được cặp MAC+IP qua Type 2 route (xem lại Mục 4). Nếu Type 2 route chỉ có MAC mà chưa có IP (host chưa từng gửi ARP), ARP Suppression chưa thể áp dụng cho địa chỉ đó.
Cơ chế nền tảng của ARP Suppression (piggyback địa chỉ IP vào Type 2 route để xây bảng Proxy-ARP/ND) đã có sẵn trong chuẩn gốc RFC 7432; các khía cạnh vận hành chi tiết hơn (edge case, cờ propagate...) được làm rõ thêm sau này ở RFC 9161.
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):
- Cơ chế nền tảng của ARP Suppression (piggyback IP vào Type 2 MAC/IP Advertisement route) — RFC 7432 §10.2.
- Khía cạnh vận hành chi tiết hơn của ARP/ND Proxy (edge case, duplicate-IP detection...) — RFC 9161.
- Type 1 Per-EVI, Ethernet Tag ID thực chất là
0(VLAN-based service) hoặc VLAN ID (VLAN-aware bundle), không phải VNI — VNI nằm ở một trường label riêng — RFC 7432 §6.1/§6.3, RFC 8365 §5.1.3. - Split-horizon cho EVPN chạy trên VXLAN dùng cơ chế Local Bias — so khớp source VTEP IP của tunnel với danh sách NVE cùng Ethernet Segment, không phải nhét ESI vào gói tin (VXLAN header không mang trường ESI; đó là cơ chế của EVPN-MPLS) — RFC 8365 §8.3.1.
Tiếp theo: Phần 4: Routing Giữa Các VNI & Multi-Homing. Phần 4 lấy đúng hai khái niệm còn để ngỏ ở đây làm điểm xuất phát: Type 5 được mổ chi tiết tới từng trường trong route, và ESI cuối cùng cũng có định nghĩa đầy đủ thay vì chỉ là một cái tên dùng tạm như ở Mục 3 và Mục 4 trên.