EVPN Part 2: Route Types & Cách Học MAC/IP
Phần 2/6 trong loạt EVPN — đọc sau Phần 1: Vì Sao Cần EVPN & Mental Model. 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à 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 1) và Type 1 (hoàn toàn mới) thực sự làm 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 — 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 một việc — 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, thực sự đóng gói và gửi packet, dựa hoàn toàn 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ên 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. Ở đây, hãy nhìn con số cụ thể để 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 chính 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. Ba loại quan trọng nhất cần nắm trước — Type 2, Type 3, Type 5 — sẽ được giải thích ở đây; Type 1 (và Type 4 liên quan) được nói kỹ hơn ở Mục 3, vì nó phức tạp hơn và xứng đáng một mục riêng.
Type 2 — "MAC/IP Advertisement" (quan trọng nhất)
Type 2 là loại route bạn sẽ 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 1, Mục 9 đã 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, bạn sẽ thấy đủ cả hai RT và Sequence Number nằm 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, 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 1, Mục 7. Ở đâ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.
Tóm tắt 5 loại route
| Type | Trả lời câu hỏi gì | Dùng cho |
|---|---|---|
| Type 2 | "Host cụ thể ở đâu?" | L2 forwarding, ARP suppression |
| Type 3 | "VTEP nào có VNI nào?" | Xây ingress-replication list cho BUM |
| Type 5 | "Subnet này ở đâu?" | Inter-VNI routing, exit ra ngoài |
| Type 1 | "Tôi đang multi-homed" | Fast convergence + aliasing (Mục 3) |
| Type 4 | "Ai là Designated Forwarder cho ESI này?" | Bầu DF (xem phần sau) |
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 — gọi là 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
Hãy hình dung tình huống: 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 3), 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) — 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ó thể nhận cũng được.
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 đó — nghĩa là gói tin vừa đi ra từ một VTEP khác cũng đang phục vụ cùng server — Leaf2 hiểu ngay gói tin này chắc chắn server đã nhận 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 thực sự được nhét 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ế
Hãy ghép mọi khái niệm ở trên lại thành một kịch bản hoàn chỉnh, 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 chính 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?
Hãy thử làm một phép tính đơn giản: 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 cần lưu ý: 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.