Skip to main content

EVPN Part 1: Vì Sao Cần EVPN & Kiến Trúc Fabric

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 1/7 trong loạt EVPN: bắt đầu từ đây, chưa cần biết gì về EVPN. Không có cấu hình trong phần này, chỉ có khái niệm và analogy. Đọc xong, phần sau nói tiếp về hai loại VRF mà EVPN dùng để vừa bridge vừa route.

Nếu từng nghe "EVPN" và thấy nó như một mớ chữ viết tắt đáng sợ (MP-BGP, VTEP, VNI, RD, RT, IRB) thì tài liệu này viết cho người đọc ở đúng vạch xuất phát đó. Nguyên tắc xuyên suốt cả loạt bài: hiểu khái niệm trước, cấu hình sau. Không một dòng CLI nào xuất hiện ở đây. Lý do rất thực tế: rất nhiều người học EVPN bằng cách copy-paste config mẫu, dán vào thiết bị, nó không chạy, và họ không biết vì sao, bởi họ chưa từng hiểu tại sao từng dòng config đó tồn tại. Tài liệu này đi ngược lại: hiểu bản chất trước, để khi nhìn vào một dòng config ở phần sau, có thể nói ngay nó đang giải quyết vấn đề gì.

Lộ trình 7 phần​

Bảng này cho biết mỗi phần trả lời câu hỏi gì, để chọn đúng điểm vào thay vì đọc lần lượt từ đầu khi chỉ cần một mảng kiến thức cụ thể.

PhầnCâu hỏi phần đó trả lờiDạng nội dung
1. Vì sao cần EVPN & Fabric (phần này)Bài toán nào sinh ra EVPN, underlay và overlay là gì, RD/RT làm gìKhái niệm, không CLI
2. MAC VRF & IP VRFVì sao cần tới hai loại VRF, một VLAN kéo dài qua fabric layer 3 bằng cách nào mà không sinh loop, gói tin đi giữa hai VLAN qua từng bước ra saoKhái niệm, không CLI
3. Route Types & MAC/IPNăm loại route EVPN mang thông tin gì, một địa chỉ MAC được học rồi quảng bá qua fabric theo luồng nàoKhái niệm, không CLI
4. Inter-VNI & Multi-HomingĐịnh tuyến giữa hai subnet khác VNI theo mô hình nào, nối một server tới nhiều leaf ra sao mà không tạo loopKhái niệm, không CLI
5. Cấu hình & TroubleshootingBa lớp cấu hình EVPN viết thành lệnh thật thế nào, gõ gì để kiểm tra, bốn sự cố hay gặp nhất xử lý ra saoCLI song song 4 vendor
6. Routing Table nội bộTrên một thiết bị đang chạy, bgp.evpn.0, evpn.0 và inet.0 khác nhau chỗ nào, vrf-import chặn route ở bước nàoCLI Junos
7. Multi-Site RT & Route Leak (sắp đăng)Nhiều site chia sẻ chung một VLAN qua RT pattern nào, leak route giữa các VRF tenant sao cho không tạo loopCLI Junos

Bốn phần đầu là khái niệm thuần, nên đọc tuần tự vì phần sau liên tục dùng lại khái niệm phần trước. Phần 5 ghép toàn bộ khái niệm đó thành cấu hình thật trên bốn nền tảng. Phần 6 và 7 là góc nhìn vận hành production, và vì các khái niệm ở mức đó được từng vendor hiện thực rất khác nhau, hai phần cuối trình bày theo Junos thay vì song song bốn vendor như Phần 5.

Mục lục​

1. Giới thiệu & cách tiếp cận học EVPN​

EVPN là viết tắt của Ethernet VPN, một giao thức control-plane chạy trên nền BGP, dùng để cho các switch trong một data center biết "địa chỉ MAC/IP này đang nằm ở thiết bị nào". Nghe có vẻ đơn giản, nhưng mảnh ghép còn thiếu đó mới giải được một bài toán rất cụ thể mà Mục 2 sẽ trình bày: làm sao kéo dài một VLAN qua hàng chục, hàng trăm switch mà không biến toàn bộ mạng thành một vùng loop khổng lồ.

Ba câu hỏi cốt lõi mà riêng Phần 1 này trả lời:

  1. Vì sao data center buộc phải chuyển từ mô hình 3 tầng truyền thống sang leaf-spine, và vì sao sự chuyển đổi đó lại "làm mất" khả năng stretch VLAN theo cách cũ (Mục 2)?
  2. EVPN dùng đúng cơ chế gì (route, không phải flood) để một VLAN vẫn "stretch" được qua một hạ tầng đã thuần layer 3 (Mục 3, 5)?
  3. Vì sao cần tới hai loại VRF khác nhau (MAC VRF và IP VRF) chỉ để làm một việc tưởng như đơn giản: định tuyến giữa hai VLAN (Mục 7, 8)?

Loạt bài này dựa trên tinh thần giảng dạy của Tony Bourke (Packet Pushers): dạy EVPN không dùng bất kỳ dòng cấu hình nào. Lý do không phải để làm màu, mà vì trình tự học sai (cấu hình trước, khái niệm sau) là nguyên nhân phổ biến khiến kỹ sư mạng sợ EVPN. Cụ thể hơn chuyện copy-paste vừa nói ở trên: khi một block cấu hình BGP address-family dán vào switch mà không hoạt động, thì không có cách nào biết phải sửa ở đâu nếu chưa từng hiểu tại sao cần address-family đó, tại sao phải khai báo VTEP theo cách đó.

Phạm vi cụ thể ở đây là MP-BGP EVPN over VXLAN, tổ hợp công nghệ phổ biến nhất trong data center hiện đại, và ngày càng được dùng cả ở mạng campus. Ở campus, use case điển hình là multi-tenancy: tách nhiều business unit ra khỏi nhau về mặt logic dù dùng chung hạ tầng vật lý. Trong mô hình campus truyền thống, vị trí của một người vừa là địa điểm vừa là danh tính: địa chỉ IP của một người gắn chặt với tầng nhà, khu vực wifi họ đang đứng. Với EVPN, danh tính (thông qua NAC, Network Access Control) tách rời được khỏi vị trí vật lý: một người có thể ở bất kỳ tòa nhà, tầng nào, nhưng vẫn nhận đúng một chính sách bảo mật, vì "segment" của họ không còn bị trói vào một dây cáp cụ thể mà có thể trải rộng trên nhiều thiết bị.

💡 Hình dung như thế này: học EVPN cũng giống dân mạng lần đầu học Python. Nhìn từ ngoài có vẻ đáng sợ, nhưng khi bắt tay vào thì phần lớn khái niệm đã quen thuộc từ networking truyền thống (VLAN, routing, BGP), chỉ là được lắp ráp lại theo một cách mới.

2. Tại sao cần EVPN?​

Bài toán của data center truyền thống​

Muốn hiểu EVPN giải quyết gì, phải bắt đầu từ bài toán đã sinh ra nó. Mạng data center truyền thống (phổ biến từ khoảng 2006–2008) có cấu trúc 3 tầng: core → aggregation → access. Default gateway của các VLAN đặt ở tầng aggregation, chạy giao thức dự phòng cổng gateway đầu tiên (FHRP: First Hop Redundancy Protocol) như HSRP/VRRP: một thiết bị active, một thiết bị standby. Ranh giới layer 3 (nơi bắt đầu routing) nằm ngay tại tầng aggregation; mọi thứ bên dưới nó là thuần layer 2 (switching, không routing).

Lý do phải giữ một vùng layer 2 lớn như vậy: để hỗ trợ vMotion, tính năng di chuyển một máy ảo (VM) đang chạy từ hypervisor vật lý này sang hypervisor khác mà không tắt máy. Có một điểm hay bị hiểu nhầm ở đây: từ VMware vSphere 6.0 (khoảng 2015), VMware đã bỏ yêu cầu bắt buộc bản thân VM phải nằm trong cùng một vùng layer 2, nhưng vẫn yêu cầu các VMkernel interface (địa chỉ IP quản lý của từng hypervisor, dùng để truyền dữ liệu vMotion) phải nằm cùng subnet. Quan trọng hơn: dù VMkernel có được nới lỏng, layer 2 segment mà VM đang chạy vẫn phải tồn tại trên mọi hypervisor mà VM có thể di chuyển tới, vì khi VM chuyển tới nơi mới, traffic từ Internet/nơi khác gửi đến vẫn phải tìm đúng đường tới nó, nghĩa là default gateway phục vụ subnet đó phải reach được VM ở vị trí mới.

Cách làm truyền thống để đạt được điều này: bật VLAN đó trên toàn bộ switch tầng access, trunk (802.1Q) xuống mọi hypervisor có thể chứa VM đó. Kết quả: layer 2 domain trải rộng khắp hạ tầng, đánh đổi lấy một vùng broadcast/loop khổng lồ.

Vấn đề thứ hai của mô hình 3 tầng: tầng core/aggregation thường chỉ có 2 thiết bị (để chạy FHRP active/standby). Mất một thiết bị là mất 50% capacity và toàn bộ dự phòng, nên buộc phải dùng chassis switch (nhiều fabric module, line card, supervisor, nguồn dự phòng bên trong một khung máy) để đạt độ sẵn sàng cao. Chassis switch thì đắt, và càng lớn càng khó mở rộng thêm.

Traditional 3-Tier Data CenterCore-1Core-2Agg-1HSRP activeAgg-2HSRP standbyLayer 3 boundaryLayer 2 broadcast domain: VLAN 10 trunked to every access switchAccess-1Access-2Access-3Hypervisor 1Hypervisor 2Hypervisor 3Default gateway lives at Aggregation: one device active, the other idle

Leaf-Spine: câu trả lời về mặt topology​

Xu hướng chuyển dịch là sang leaf-spine topology: dùng nhiều switch top-of-rack/end-of-row nhỏ gọn, rẻ hơn nhiều so với chassis, và khi cần thêm băng thông chỉ cần mua thêm leaf/spine thay vì nâng cấp một khung máy khổng lồ.

Traditional 3-Tier vs Leaf-SpineTraditional (Core/Agg/Access)Core / Aggregation (L3)Access Switch (L2 only)Hypervisors (VM, same VLAN)Only 2 core devices: losing 1 costs 50% capacityLeaf-SpineSpine1Spine2Leaf1Leaf2Leaf3every link is Layer 3Need more bandwidth: just add a leaf or spineProblem: leaf-spine is pure Layer 3, but vMotion needs Layer 2EVPN answers that question: it stretches a Layer 2 segmentacross ALL leaves, while the leaf-spine links stay entirely Layer 3.The default gateway also moves onto the leaf as an Anycast Gateway:the same gateway IP exists identically on every leaf.This is exactly why EVPN exists. Section 3 shows how it gets built.

Nhưng chuyển sang leaf-spine đặt ra một câu hỏi hóc búa: nếu mọi kết nối leaf–spine đều là layer 3 thuần túy (routing, không trunk VLAN), thì vMotion, thứ vốn cần layer 2, sẽ hoạt động thế nào? Đây chính xác là bài toán mà EVPN sinh ra để giải quyết: stretch (kéo dài) một layer 2 segment qua tất cả các leaf, trong khi bản thân hạ tầng vật lý bên dưới (leaf–spine) vẫn thuần layer 3, với routing protocol xử lý failover, tính khả dụng, ECMP (cân bằng tải đa đường) như bất kỳ mạng layer 3 nào khác.

Một hệ quả tự nhiên khi default gateway giờ đặt ngay tại leaf: Anycast Gateway, cùng một địa chỉ IP gateway (và cùng MAC) tồn tại giống hệt nhau trên mọi leaf trong fabric. VM ở bất kỳ leaf nào cũng thấy "gateway của tôi ở ngay đây", giúp giảm hiện tượng traffic phải đi vòng (trombone/hairpin) chỉ để tới đúng gateway vật lý duy nhất. Có cơ chế phía sau (sẽ nói ở các phần sau) ngăn vấn đề "tôi là Spartacus", tức nhiều thiết bị cùng khai báo một IP mà không gây xung đột ARP.

Về đại khái, cơ chế này gọi là ARP suppression: thay vì để ARP request bị flood ra khắp fabric như một VLAN truyền thống vẫn làm, leaf nhận request tự trả lời thay cho gateway (vì gateway ở leaf nào cũng giống hệt nhau). Request bị triệt tiêu ngay tại chỗ, không đi xa hơn. Cách leaf tra đúng thông tin để trả lời sẽ rõ hơn khi học route Type 2 ở phần sau.

Vì sao không dùng công nghệ khác đã có sẵn?​

Trước EVPN đã có vài nỗ lực khác để giải bài toán tương tự: FabricPath (Cisco), Brocade VCS (dựa trên TRILL), shortest path bridging. Một số nơi quy mô lớn vẫn còn dùng, nhưng nhìn chung EVPN đã thắng thế và là cách làm phổ biến nhất hiện nay. Công nghệ gần giống nhất về mặt topology là Cisco ACI, cũng layer 3, cũng dựa trên VXLAN, cũng có một routing protocol bên dưới. Khác biệt nằm ở chỗ EVPN là chuẩn công nghiệp mở (RFC, đa vendor), còn ACI là sản phẩm độc quyền của Cisco. Vì phần lớn triển khai thực tế chỉ dùng một vendor cho toàn bộ fabric (không ai xây EVPN đa vendor trong cùng một fabric), khác biệt này ít khi là yếu tố quyết định. Lợi ích lớn nhất của EVPN nằm ở chỗ khái niệm giống nhau trên mọi vendor: học EVPN một lần, áp dụng được cho Cisco, Arista, Juniper, và hiểu ACI cũng dễ hơn hẳn.

3. Xây dựng topology EVPN: Underlay & Overlay​

Để dựng một mạng EVPN, cần ba lớp: topology (đã nói ở Mục 2: leaf-spine), underlay, và overlay. Đây là hai thuật ngữ sẽ xuất hiện xuyên suốt toàn bộ tài liệu, nên cần định nghĩa rõ ngay từ đầu:

  • Underlay: một mạng layer 3 thuần túy, đơn giản, chỉ có một nhiệm vụ, là đảm bảo mọi thiết bị trong fabric ping được lẫn nhau qua địa chỉ loopback. Không có khái niệm VLAN, VRF, hay tenant nào ở đây.
  • Overlay: các "đường hầm" (tunnel) chạy bên trên underlay, mang traffic thật của VM/tenant. Overlay dùng underlay chỉ để hai đầu tunnel tìm thấy nhau. Bản thân overlay không quan tâm underlay dùng giao thức gì.
Underlay vs OverlayOverlay (MP-BGP EVPN)VXLAN tunnels carry real VM traffic: leaf only, sourced from Loopback1 (VTEP)"I need to reach VTEP 2.2.2.2": it never cares if the underlay is OSPF or BGPUnderlay (OSPF / IS-IS / BGP)One job only: every Loopback0 must reach every other Loopback0It knows nothing about the VLANs, VRFs or tenants above itConcrete example: 2 leaves, 1 spine, on the underlay shown aboveSpineLeaf1Lo0=10.0.0.1Leaf2Lo0=10.0.0.2VXLAN tunnel: Lo1 10.1.1.1 ↔ Lo1 10.1.1.2 (VTEP)The overlay borrows the underlay just so two VTEPs can find each other

Underlay: mọi loopback phải thấy nhau​

Quy ước ngành (RFC không bắt buộc, nhưng gần như mọi triển khai đều làm vậy) là dùng hai loopback trên mỗi thiết bị:

  • Loopback0: dùng cho routing protocol underlay, chạy trên mọi thiết bị (cả leaf lẫn spine).
  • Loopback1: dùng làm địa chỉ VTEP (Virtual Tunnel Endpoint), điểm cuối của tunnel VXLAN. Chỉ leaf mới cần, vì spine không terminate tunnel (tunnel luôn đi từ leaf tới leaf, băng qua spine chỉ như một trạm trung chuyển layer 3 thuần túy).

Mục tiêu duy nhất của underlay: mọi Loopback0 phải reach được mọi Loopback0 khác. Không hơn, không kém. Giao thức nào cũng dùng được miễn đạt mục tiêu này, kể cả RIP (đã có người thử cho vui, nhưng không khuyến khích vì RIP không hỗ trợ ECMP). Lựa chọn phổ biến trong thực tế: OSPF, IS-IS (ít gặp hơn), iBGP hoặc eBGP.

Nếu dùng OSPF/IS-IS, có thể dùng IP unnumbered (tùy vendor hỗ trợ). Nếu dùng BGP (cả iBGP lẫn eBGP), bắt buộc phải đánh số point-to-point, thường dùng /31 cho mỗi liên kết leaf–spine.

💡 Lời khuyên khi mới học: dùng OSPF một area 0 duy nhất, không cầu kỳ làm underlay. Lý do là giữ ranh giới thật rõ ràng: nhìn vào OSPF là biết đang xem underlay, nhìn vào BGP là biết đang xem overlay/EVPN. Có tin đồn ngưỡng ~100 leaf là giới hạn của OSPF underlay, nhưng chưa có test cụ thể nào chứng minh con số này; thực tế đã có người scale vượt xa mốc đó.

Underlay khá tĩnh, routing table gần như không đổi theo thời gian. Mọi sự sôi động, mọi "phép màu" của EVPN, đều nằm ở overlay.

Overlay: MP-BGP mang theo địa chỉ MAC​

Overlay luôn luôn là MP-BGP (Multiprotocol BGP) với address family tên là evpn. "MP" (multiprotocol) là vì BGP nguyên gốc chỉ hỗ trợ IPv4; phần mở rộng multiprotocol mới cho phép mang thêm các loại thông tin khác, ở đây là MAC address và VNI.

Đây là điểm khác biệt cốt lõi so với BGP truyền thống: BGP thông thường chỉ route IP prefix (network). BGP EVPN route thêm cả MAC address và host IP (/32 hoặc /128): EVPN "route" địa chỉ MAC giống hệt cách BGP thường route một network.

Nhưng vì sao lại chọn đúng BGP cho việc này, thay vì một link-state protocol quen thuộc hơn (OSPF, IS-IS) hay một cơ chế tự chế nào khác? Ba lý do gắn chặt với chính bản chất của BGP:

  1. BGP vốn đã là một policy language (sẽ thấy rõ ở Mục 4 với RD/RT). Cơ chế import/export theo Route Target gần như khớp hoàn hảo với nhu cầu multi-tenant: mỗi tenant chỉ nhận đúng route của mình, không cần dựng thêm một lớp policy riêng biệt nào khác.
  2. BGP đã được chứng minh scale tới hàng trăm nghìn, hàng triệu route trên Internet toàn cầu. Một fabric data center, dù lớn tới đâu, vẫn nhỏ hơn nhiều so với global routing table, nên BGP dư sức xử lý.
  3. BGP là soft-state, không cần hội tụ tức thời, và đây là điểm dễ bị bỏ qua nhất. Khi một link vật lý đứt, đó là việc của underlay (OSPF/IS-IS/BGP underlay) xử lý failover trong mili-giây; overlay chỉ cần phản ứng khi có sự kiện liên quan tới MAC/IP (host di chuyển, host mới xuất hiện), mà những sự kiện này xảy ra chậm hơn nhiều so với link flap. Overlay không cần một giao thức hội tụ nhanh như link-state; dùng BGP cho việc "chậm mà chắc" này là vừa đủ, không thừa không thiếu.
  • Nếu dùng iBGP: các spine đóng vai trò Route Reflector, giúp mỗi leaf chỉ cần peer với spine thay vì phải full-mesh với tất cả leaf khác.
  • Nếu dùng eBGP: spine dùng chung một AS, mỗi cặp leaf (thường triển khai MLAG/vPC) có AS riêng, giúp nhận diện leaf nguồn của một route qua as-path.

Sự khác biệt này không phải "chọn cho gọn". Nó bắt nguồn trực tiếp từ cách mỗi biến thể BGP chống loop, và đáng hiểu kỹ vì đây là chỗ rất nhiều người học EVPN chỉ nhớ luật mà không hiểu vì sao.

Với iBGP: mọi speaker chia sẻ chung một AS number nên iBGP không dùng AS_PATH để chống loop, thay vào đó nó dựa vào luật iBGP split-horizon: một route học được từ một iBGP peer thì không được re-advertise cho một iBGP peer khác. Luật này ngăn loop rất tốt, nhưng có tác dụng phụ: nếu để leaf tự peer trực tiếp với nhau, mỗi leaf sẽ phải full-mesh với mọi leaf còn lại (vì không leaf nào được re-advertise route hộ leaf khác). Route Reflector tồn tại chính để phá luật đó một cách có kiểm soát: spine (đóng vai trò RR) được phép nhận route từ một leaf rồi phản xạ (reflect) sang mọi leaf khác, giải quyết đúng vấn đề mà split-horizon gây ra; đổi lại, loop được ngăn bằng cơ chế khác (route-reflector cluster-list/originator-id) chứ không phải AS_PATH.

Với eBGP: ngược lại, AS_PATH chính là cơ chế chống loop: một router eBGP mặc định sẽ từ chối bất kỳ route nào đã chứa ASN của chính nó trong AS_PATH. Đây là lý do vì sao mỗi leaf (hoặc mỗi cặp leaf MLAG) bắt buộc phải có AS riêng biệt: nếu hai leaf dùng chung một AS, một route mà leaf này gửi lên có thể đi vòng qua fabric và quay trở lại đúng leaf kia (khác thiết bị vật lý nhưng cùng AS). Router sẽ tưởng đây là loop và âm thầm loại bỏ route, dù topology vẫn hợp lệ.

Ngược lại, các spine lại cố tình dùng chung một AS thay vì mỗi spine một AS riêng cho "an toàn". Hai lý do:

  1. Trong một fabric Clos 3-tầng chuẩn, route không bao giờ đi từ spine quay ngược lại chính spine đó, nên spine dùng chung AS không tạo ra loop giả nào cả.
  2. Quan trọng hơn, nó giúp ECMP hoạt động ngay lập tức mà không cần cấu hình thêm: nếu leaf B nhận cùng một prefix qua cả Spine1 lẫn Spine2, và hai spine dùng chung AS, thì AS_PATH của hai route đó giống hệt nhau về nội dung, không chỉ giống độ dài, nên hầu hết implementation BGP sẽ tự động ECMP giữa hai path như vậy. Nếu mỗi spine có AS riêng, AS_PATH tuy vẫn cùng độ dài nhưng khác nội dung (khác ASN ở giữa), và nhiều vendor mặc định sẽ không ECMP giữa các path có AS_PATH khác nội dung; phải bật thêm một flag riêng (ví dụ "bestpath as-path multipath-relax" trên một số nền tảng) mới ECMP được. Dùng chung AS ở spine giúp tránh hẳn việc phải nhớ bật flag đó.

Tóm gọn một câu: iBGP chống loop bằng luật split-horizon nên cần Route Reflector để phá luật đó có kiểm soát; eBGP chống loop bằng AS_PATH nên cần AS riêng ở leaf để không tự loại bỏ route của chính mình, và cần AS chung ở spine để ECMP không cần cấu hình thêm.

Overlay BGP: Two Ways to Prevent LoopsiBGP: split-horizon + Route ReflectoreBGP: AS_PATH loop detectionSpine = RRAS 65000Leaf-1AS 65000Leaf-2AS 65000RR re-advertises what split-horizon forbidsSpine-1AS 65000Spine-2AS 65000Leaf-1AS 65001Leaf-2AS 65002Same spine AS = identical AS_PATH = ECMP works

Bảng routing sẽ lớn dần khi fabric mở rộng, nhưng phần cứng hiện đại xử lý control-plane khá tốt. Giới hạn nằm ở forwarding table (TCAM/CAM): một leaf không nhất thiết phải cài route vào phần cứng trừ khi có segment liên quan cục bộ, giúp tiết kiệm tài nguyên đáng kể.

Ở quy mô lớn, cấu hình thủ công gần như chắc chắn sẽ sai sót (một IP point-to-point gõ nhầm là đủ khó tìm khi mọi leaf trông giống hệt nhau), nên triển khai EVPN gần như bắt buộc phải dùng automation (Ansible, Arista CloudVision, Cisco DCNM...), không cấu hình tay. Cùng với đó, cần đầu tư đào tạo đội ngũ vận hành: thiếu hiểu biết của đội vận hành là nguyên nhân phổ biến khiến một triển khai EVPN thất bại trong thực tế.

Cuối cùng, một đặc điểm quan trọng của tunnel VXLAN: nó stateless. Không cần đàm phán thiết lập tunnel như VPN concentrator truyền thống, không cần giữ kết nối. Encap/decap diễn ra tự động theo traffic, và mỗi leaf chỉ cần một cấu hình tunnel duy nhất, không phải cấu hình riêng cho từng segment.

💡 Hình dung như thế này: khác hẳn hình ảnh "VPN concentrator" cũ (phải bấm mã token, khó bảo trì). Tunnel VXLAN giống một cánh cửa tự động: chỉ hiện ra khi có người bước tới, biến mất ngay khi không ai dùng, không cần ai đứng canh giữ nó mở.

4. VRF cơ bản: Route Distinguisher & Route Target​

Phần này là nơi rất nhiều người học EVPN bị "khựng" lại, không phải vì nó khó mà vì nó thường bị lướt qua quá nhanh trong tài liệu, trong khi 90% lỗi cấu hình EVPN thực tế lại xảy ra đúng ở đây.

VRF (Virtual Route Forwarding instance) là khái niệm nhiều kỹ sư mạng đã quen: một bảng định tuyến (routing table) độc lập, tách biệt khỏi bảng định tuyến mặc định. Interface được gán vào một VRF cụ thể; nó chỉ trao đổi route với các interface khác cùng VRF. Hệ quả hữu ích nhất: hai VRF khác nhau có thể overlap địa chỉ IP mà không xung đột: VRF Red có thể có 10.1.1.1, VRF Blue cũng có 10.1.1.1, và chúng sống trong hai không gian địa chỉ tách biệt.

Vấn đề: một liên kết, nhiều VRF cần trao đổi route​

Vấn đề nảy sinh khi cần trao đổi route của nhiều VRF khác nhau qua cùng một kết nối vật lý/BGP session, điều mà routing protocol thông thường không có cách nào phân biệt được, vì bản thân BGP không có khái niệm "VRF" khi đóng gói một route để gửi đi. Đây là lý do cần hai công cụ: Route Distinguisher (RD) và Route Target (RT), hai khái niệm trông giống hệt nhau về mặt cú pháp nhưng vai trò khác nhau hẳn, và chính điều đó gây nhầm lẫn.

Route Distinguisher vs Route TargetVRF Red — 10.1.1.1Export RT: 10:10RD: Loopback:1 (unique)VRF Blue — 10.1.1.1Export RT: 20:20RD: Loopback:2 (unique)BGP table chung (bgp.evpn.0)RD keeps the two 10.1.1.1 routes apartImport RT 10:10 on a remote Leafroute is placed into VRF RedRT does NOT match 20:20, Blue route ignoredImport RT 20:20 on a remote Leafroute is placed into VRF BlueRT does NOT match 10:10, Red route ignored

Route Distinguisher (RD) — chỉ để làm route "độc nhất"​

RD được gắn thêm vào mỗi route trước khi nó đi vào bảng BGP chung (thường ghép từ địa chỉ loopback + một số hậu tố, ví dụ 10.0.0.1:1), với một mục đích duy nhất: đảm bảo route không bị trùng/đè lẫn nhau khi nhiều VRF cùng đẩy route vào một bảng BGP chung để trao đổi qua các peering session. RD không quyết định gì khác. Nó không ảnh hưởng route có được chấp nhận hay không, không quyết định route sẽ rơi vào VRF nào ở phía nhận. Thiết bị nhận thấy RD chỉ đơn giản "ghi nhận" nó tồn tại.

RD hầu như không cần khớp giữa các thiết bị, trên thực tế gần như luôn khác nhau, và nhờ vậy còn có thể dùng để nhận diện route đến từ leaf nào (hữu ích khi debug, nhất là lúc dùng iBGP và không có AS number riêng để phân biệt).

Về mặt kỹ thuật, RD có ba dạng encoding khác nhau (RFC 4364 §4.2), phân biệt bằng 2 byte Type ở đầu: Type 0 (ASN 2-byte : số tuỳ ý 4-byte, ví dụ 65001:100), Type 1 (địa chỉ IPv4 4-byte : số tuỳ ý 2-byte, ví dụ 10.0.0.1:1, dạng phổ biến nhất trong EVPN vì thường ghép thẳng từ Loopback0), và Type 2 (ASN 4-byte : số tuỳ ý 2-byte, dùng khi ASN đã ở dạng 4-byte). Định dạng cụ thể không quan trọng bằng việc nhớ nguyên tắc cốt lõi: RD không cần khớp giữa hai đầu, khác hẳn RT.

Route Target (RT) — quyết định route đi vào đâu​

RT mới là phần quyết định hành vi. Nó hoạt động theo cặp export/import:

  • Export: khi một VRF/forwarding-space announce một route ra ngoài, nó gắn kèm một RT, giống như dán một cái nhãn lên route đó.
  • Import: thiết bị nhận route sẽ soi RT trên route, so khớp với danh sách RT mà nó chấp nhận nhập vào, rồi mới quyết định đẩy route đó vào đúng VRF cục bộ nào.

Khác với RD, RT bắt buộc phải khớp chính xác giữa bên export và bên import thì route mới đi đúng chỗ.

RD Makes Routes Unique, RT Decides Where They LandVRF Red10.1.1.0/24VRF Blue10.1.1.0/24bgp.evpn.0RD 10.0.0.1:1 + prefixRD 10.0.0.2:1 + prefixTwo entries, no longer identicalLeaf importstarget:65000:1Leaf importstarget:65000:21. add RD2. match RTRD only prevents collisions in the shared BGP table; RT alone decides the destination VRF

RD gần như không bao giờ gây lỗi (kể cả khi thiếu, hệ thống vẫn chạy dù có thể gặp hành vi lạ). Ngược lại, RT chính là nơi phần lớn lỗi cấu hình EVPN xảy ra, và cũng là trọng tâm chính khi troubleshoot. Ghi nhớ nguyên tắc này ngay từ bây giờ, vì RT sẽ quay lại ở hầu như mọi phần còn lại của loạt bài, đặc biệt là ở các phần sau khi nói về multi-site.

Nguồn tham khảo​

Nguồn gốc: Loạt video "Intro To EVPN With Tony Bourke" (Part 1–10), kênh Packet Pushers. Phần này tương ứng bốn video đầu:

  • Part 1: Welcome!
  • Part 2: Why EVPN? What's The Point?
  • Part 3: Building EVPN Topologies, Underlays & Overlays
  • Part 4: Understanding EVPN VRFs Part 1 — VRF Basics

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

  • Mục 3: sơ đồ AS cho eBGP underlay (spine dùng chung AS, mỗi leaf/cặp MLAG có AS riêng) khớp với khuyến nghị chính thức tại RFC 7938 §5.2.1 ("EBGP Configuration Guidelines and Example ASN Scheme") — RFC quy định rõ: một ASN chung cho toàn bộ Tier 1 (spine), một ASN riêng cho mỗi cluster Tier 2, và một ASN riêng cho mỗi Tier 3 (ToR/leaf). Phần giải thích "vì sao" (AS_PATH loop-detection của eBGP, và lý do ECMP hoạt động mượt hơn khi spine dùng chung AS) là suy luận thêm dựa trên tính chất chuẩn của BGP (RFC 4271), không phải trích trực tiếp câu chữ của RFC 7938 hay video gốc.
  • MAC-VRF/IP-VRF định danh theo Route Target/Route Distinguisher — RFC 7432.

Tiếp theo: Phần 2: Hai Loại VRF — MAC VRF & IP VRF. Phần 1 đã dựng xong fabric và cơ chế policy (RD/RT) chạy trên nó; phần sau trả lời câu hỏi còn lại: EVPN đặt cái gì bên trong fabric đó để một VLAN kéo dài được, và để hai VLAN khác subnet nói chuyện được với nhau.