Skip to main content

EVPN Part 2: Hai Loại VRF — MAC VRF & IP VRF

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 2/7 trong loạt EVPN: đọc sau Phần 1: Vì Sao Cần EVPN & Kiến Trúc Fabric. Vẫn chưa có một dòng cấu hình nào, chỉ khái niệm và analogy. Đây là phần giải thích cơ chế lõi nhất của EVPN, nên đọc chậm.

Phần 1 đã dựng xong một fabric leaf-spine thuần layer 3, cho mọi VTEP thấy nhau qua underlay, và trao cho BGP một cơ chế policy (RD/RT) để phân loại route. Nhưng tới đây vẫn còn một khoảng trống: fabric đó chưa chở gì cả. Phần này lấp đúng khoảng trống ấy bằng hai loại "không gian chuyển tiếp" mà EVPN đặt lên trên fabric, và đi theo một gói tin thật qua từng bước để thấy chúng phối hợp ra sao.

Ba câu hỏi cốt lõi mà phần này trả lời:

  1. 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, và vì sao làm vậy lại không sinh loop (Mục 1, 2)?
  2. 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 1, 3)?
  3. Một host mới xuất hiện trong fabric thì route nào được sinh ra, và vì sao chỉ một route lại cài được vào hai bảng forwarding khác nhau (Mục 4)?

Mục lục​

1. MAC VRF / Layer 2 VNI​

EVPN dùng ba loại "không gian chuyển tiếp" (forwarding space) riêng biệt trên mỗi thiết bị: một VRF tenant tổng (nói ở Mục 7), một MAC VRF cho mỗi VLAN cần kéo dài (mục này), và một IP VRF để routing giữa các VLAN đó (Mục 7). Mục này tập trung vào MAC VRF.

MAC VRF là một forwarding space chỉ chứa địa chỉ MAC: về bản chất, nó là một bảng bridging (bridging table). Trên thiết bị vật lý, MAC VRF được hiện thực bằng một VLAN cục bộ: mỗi VXLAN segment (gọi là VNI: VXLAN Network Identifier) có quan hệ 1-1 với một VLAN local trên switch. MAC VRF còn được gọi là Layer 2 VNI; xét ở data-plane, nó hoạt động y hệt một VLAN được kéo dài qua nhiều switch (stretched VLAN).

Học MAC theo kiểu cũ vs kiểu EVPN​

Cách học MAC address truyền thống là flood & learn: switch chưa biết MAC nằm ở đâu thì flood ra mọi port, ai trả lời thì switch ghi nhớ. Với EVPN, cách học này vẫn tồn tại nhưng chỉ ở phạm vi local (leaf vẫn flood ra các port cùng VLAN theo kiểu truyền thống khi cần). Vấn đề là: các leaf trong một fabric EVPN không nối trực tiếp layer 2 với nhau, chúng chỉ nối qua underlay layer 3. Flood truyền thống không thể băng qua layer 3 được. EVPN can thiệp đúng ở chỗ này: thay vì flood, nó dùng route để phổ biến thông tin MAC.

Type 2 Route: Learning a Remote MACLeaf1 (VTEP 1.1.1.1)VLAN 101 learns:MAC 00:...:01(local flood/learn)generateEVPN Type 2 RouteMAC: 00:...:01RT: 101:101 (= VNI 1001)Next-hop (VTEP): 1.1.1.1sent via MP-BGPLeaf2 (VTEP 2.2.2.2)RT matches VLAN 101→ into the MAC table00:...:01 via vxlan1Then the data plane, when Leaf2 must reach that MACHost on Leaf2Leaf2 tra MAC table→ next-hop VTEP 1.1.1.1Encap VXLANVNI=1001, dst=1.1.1.1The packet crosses the underlay to Leaf1Leaf1: decap → xem VNI 1001pushed into VLAN 101, then out the right port

Khi một leaf học được một MAC address cục bộ, nó sinh ra một EVPN Type 2 route và gửi qua MP-BGP. Route này chứa:

  • Route Distinguisher và Route Target (RT tương ứng với VLAN/VNI, ví dụ 101:101 khớp VLAN 101, hoặc dùng thẳng VNI như 1001:2001, con số cụ thể không quan trọng miễn hai đầu khớp nhau).
  • Địa chỉ MAC vừa học được.
  • Địa chỉ VTEP nơi MAC đó đang cư trú.

Leaf nhận route sẽ soi RT, khớp với cấu hình cục bộ, và biết cần cài MAC đó vào bảng forwarding của đúng VLAN, với next-hop là cổng logic VXLAN trỏ về VTEP nguồn. Nếu một leaf nhận route nhưng không có VLAN/RT tương ứng cấu hình cục bộ, route đó vẫn tồn tại trong RIB (BGP table) nhưng không được cài vào phần cứng (TCAM), tiết kiệm tài nguyên forwarding cho những segment mà leaf đó không cần quan tâm.

💡 Hình dung như thế này: Route Target đóng vai trò tương tự một thẻ tag 802.1Q khi trunk hai switch vật lý, báo cho switch nhận biết frame này thuộc VLAN nào. Khác biệt duy nhất: 802.1Q tag là một phần của data plane (gắn trực tiếp vào từng frame vật lý), còn RT hoạt động ở control plane (gắn vào route BGP, không đụng tới frame thật).

Một câu hỏi tự nhiên hay bị bỏ sót: nếu MAC chỉ được học sau khi leaf nhìn thấy traffic từ host đó, vậy điều gì xảy ra với gói tin đầu tiên gửi tới một host còn "im lặng" (chưa từng gửi gì, nên chưa leaf nào học được MAC của nó)? Câu trả lời nằm ở traffic BUM (Broadcast, Unknown-unicast, Multicast). EVPN có hẳn một loại route riêng cho nó, Type 3, Inclusive Multicast Ethernet Tag route, để các leaf biết cần replicate loại traffic này tới đúng những leaf nào đang có cùng VLAN, thay vì mù quáng flood ra toàn mạng như flood truyền thống. Route Type 3 sẽ được nói kỹ ở phần sau.

MAC VRF chỉ là một nửa câu chuyện — vậy nửa còn lại là gì?​

Đến đây, MAC VRF (Layer 2 VNI) đã đủ để giải quyết đúng một việc: hai host cùng VLAN, tức cùng subnet, gửi được cho nhau qua route thay vì flood. Nhưng MAC VRF về bản chất vẫn chỉ là một bảng bridging: nó chỉ biết MAC, không biết gì về IP, và không định tuyến được. Vậy khi Host A ở VLAN 101 muốn nói chuyện với Host B ở VLAN 102 (khác subnet, bắt buộc cần routing, không chỉ bridging), MAC VRF một mình là không đủ.

Đây chính xác là lý do EVPN cần thêm một forwarding space thứ hai, IP VRF (Layer 3 VNI): nơi duy nhất trong toàn bộ tenant biết cách đi giữa các VLAN, thay vì chỉ đi bên trong một VLAN. IP VRF sẽ được trình bày đầy đủ (kèm packet walkthrough) ở Mục 7. Nhưng để không rời Mục 5 với cảm giác "vẫn chưa rõ hai cái này khác nhau ở đâu", hãy nhìn thẳng vào cấu trúc bên dưới trước.

MAC VRF vs IP VRF — Same VLAN vs Cross-VLAN TrafficTenant VRF ("kirk")IP VRF — L3 VNI 90000Routes between VLANs inside one tenant1 per tenant, present on EVERY leaf (symmetric)different VLAN: via the IP VRF firstMAC VRF — VLAN 101 (L2 VNI 10101)Host A1Host A2same VLAN: MAC VRF onlyonly leaves hosting VLAN 101 need this MAC VRFMAC VRF — VLAN 102 (L2 VNI 10102)Host B1only leaves hosting VLAN 102 need this MAC VRFMAC VRF: many, only where the VLAN lives · IP VRF: exactly one, required on every leaf

Đi theo đúng hai luồng trong sơ đồ trên để thấy rõ khác biệt:

  • Host A1 → Host A2 (cùng VLAN 101, cùng subnet): đây thuần túy là bridging. Leaf tra MAC table trong đúng MAC VRF của VLAN 101, thấy Host A2, forward thẳng, gói tin không bao giờ chạm tới IP VRF. Với luồng này, IP VRF có tồn tại hay không cũng không quan trọng.
  • Host A1 → Host B1 (khác VLAN, khác subnet): Host A1 gửi gói tin tới default gateway của VLAN 101 trước (packet đi vào MAC VRF 101, nhưng đích đến là một subnet khác nên MAC VRF không đủ thông tin để forward tiếp). Gói tin được đẩy lên IP VRF (nơi duy nhất biết "muốn tới subnet của VLAN 102 thì đi đâu"), rồi từ IP VRF mới được đẩy xuống đúng MAC VRF của VLAN 102 để bridge nốt chặng cuối tới Host B1.

Nguyên tắc cần nhớ: MAC VRF không bao giờ nói chuyện trực tiếp với một MAC VRF khác. Mọi traffic đi giữa hai VLAN, dù trên cùng một leaf hay khác leaf, đều bắt buộc phải "ghé qua" IP VRF. Chính vì vậy mô hình này mang tên Integrated Routing and Bridging: bridging (MAC VRF) và routing (IP VRF) là hai cơ chế tách biệt, nhưng được tích hợp trong cùng một thiết bị, cùng một tenant.

Bảng dưới đặt hai forwarding space cạnh nhau theo từng tiêu chí:

Tiêu chíMAC VRF (Layer 2 VNI)IP VRF (Layer 3 VNI)
Vai tròBảng bridging — forward theo MAC, trong cùng một VLANBảng routing — forward giữa các VLAN khác nhau, trong cùng một tenant
Số lượng mỗi tenantNhiều — một MAC VRF cho mỗi VLAN cần stretchĐúng một — dùng chung cho mọi VLAN thuộc tenant đó
Tồn tại trên leaf nàoChỉ leaf đang host VLAN đó mới cần cóMọi leaf trong tenant, kể cả leaf không host VLAN nào của tenant (tính chất "symmetric" — xem Mục 7)
Route populateEVPN Type 2 (phần MAC) + Type 3 (BUM)EVPN Type 2 (phần host route /32, xem Mục 8) — về sau còn có Type 5 cho route theo prefix, nói ở phần sau của loạt bài

💡 Hình dung như thế này: MAC VRF giống sổ địa chỉ nội bộ của từng tòa nhà trong một khu đô thị: chỉ nhân viên phụ trách tòa đó mới cần giữ một bản, và họ chỉ biết giao thư trong nội bộ tòa nhà mình. IP VRF giống bản đồ quy hoạch toàn khu đặt ở một trạm trung chuyển trung tâm: bất kỳ thư nào đi giữa hai tòa nhà khác nhau đều phải ghé qua trạm này trước, dù người gửi và người nhận không hề hay biết có bước trung chuyển đó.

2. Stretched VLAN & Spanning Tree​

Nghe tới việc "kéo dài một VLAN qua hàng chục switch", phản xạ tự nhiên của bất kỳ ai từng học networking là nghĩ ngay đến rủi ro loop. Câu trả lời thẳng thắn: về bản chất, việc này không hẳn an toàn hơn theo nghĩa tuyệt đối, nhưng cách EVPN thực hiện nó tránh được vấn đề loop nhờ một nguyên tắc rất quen thuộc.

Nhắc lại nguyên tắc nền tảng của Ethernet: không bao giờ để tồn tại nhiều hơn một đường đi giữa hai địa chỉ MAC. Nếu có, sẽ sinh loop, và loop gây đủ loại vấn đề (bão broadcast, MAC table flap...). Spanning Tree ra đời chính để ngăn nhiều hơn một path tồn tại. LAG (link aggregation) cho phép nhiều path vật lý nhưng gộp lại thành một path logic duy nhất, về bản chất là "đánh lừa Ethernet" (Ethernet chỉ thấy một link), chứ không phải đánh lừa Spanning Tree.

EVPN áp dụng đúng nguyên lý đó: tạo ra nhiều path vật lý/logic cho traffic đi qua fabric, nhưng đảm bảo không bao giờ tồn tại nhiều hơn một logical path, giống hệt cách LAG hoạt động, chỉ khác ở quy mô.

Một cách nhìn khác, chính xác hơn về mặt kỹ thuật: giữa hai leaf bất kỳ trong fabric, thực chất chỉ tồn tại đúng một hop layer 2 logic duy nhất, vì bên dưới leaf không hề bridge trực tiếp với leaf khác, chúng chỉ route (layer 3) với nhau qua underlay. Loop layer 2 theo định nghĩa cần có nhiều hơn một đường layer 2 giữa hai điểm, mà ở đây vốn dĩ không hề có "đường layer 2" nào giữa hai leaf để mà loop, chỉ có nhiều đường layer 3 (ECMP) cùng dẫn tới đúng một VTEP đích.

Đó là lý do sâu xa hơn khiến EVPN loop-free ngay từ trong thiết kế, không chỉ đơn thuần "giống LAG", dù phép ví von với LAG vẫn giúp dễ hình dung ở mức khái niệm.

Spanning Tree vẫn chạy trong một mạng EVPN, nhưng chỉ đóng vai trò dự phòng, đề phòng ai đó lỡ cắm nhầm một switch vào switch, tạo loop cục bộ. Trong một mạng EVPN thiết kế đúng, về lý thuyết Spanning Tree không bao giờ cần hành động (không block gì cả), nhưng vẫn đứng đó canh gác.

Có một quy tắc tuyệt đối: BPDU (gói tin của Spanning Tree) không bao giờ được đóng gói và gửi qua tunnel VXLAN. Đây là một dạng split-horizon: switch vẫn gửi BPDU ra các port local trên VLAN đó theo kiểu truyền thống, nhưng không bao giờ gửi BPDU ra interface VXLAN. Nhờ vậy, Spanning Tree hoàn toàn không "nhìn thấy" fabric EVPN, nó chỉ thấy các port truy cập cục bộ.

BPDU Never Crosses the VXLAN TunnelLeaf1Host A (access)Host B (access)BPDU stays local: normalPortFast + BPDU Guard on host portsVXLAN interface (VTEP)carries only real MAC/IP traffic✕BPDU NEVER crosses hereLeaf2Host C (access)Host D (access)BPDU stays local: normalPortFast + BPDU Guard on host portsVXLAN interface (VTEP)carries only real MAC/IP traffic✕BPDU NEVER crosses hereReal MAC/IP traffic still rides the VXLAN tunnelSplit-horizon: Spanning Tree sees only local access ports, never the EVPN fabric in between

Thực hành phổ biến: các port hướng host được cấu hình kiểu PortFast (một "lời hứa" rằng sẽ không có switch nào khác được cắm vào port đó) kèm BPDU Guard. Nếu một port PortFast bất ngờ nhận được BPDU (dấu hiệu ai đó lỡ cắm một switch vào), port đó lập tức bị error-disable, đảm bảo topology vẫn loop-free. Tất nhiên, nếu vô tình nối hai port đều được cấu hình PortFast lại với nhau (cả hai đều "tưởng" mình đang nói chuyện với host), loop vẫn có thể xảy ra. Quy tắc này chỉ ngăn được lỗi thường gặp, không phải mọi lỗi cấu hình.

3. IP VRF / Layer 3 VNI với Symmetric IRB​

Đây là phần khiến nhiều người học EVPN "rối" nhất, nhưng một khi ghép được với các khái niệm đã học ở các mục trước, nó sẽ trở nên rất tự nhiên. Hãy đọc chậm phần này.

Best practice (không bắt buộc theo spec, nhưng gần như ai cũng làm): luôn tạo một VRF riêng cho EVPN (gọi nó là gì cũng được, ví dụ "kirk") thay vì dùng VRF mặc định (default VRF nên để dành riêng cho underlay). Nguyên tắc này giống hệt quy ước "không dùng VLAN 1 cho traffic thật" mà nhiều kỹ sư mạng đã quen: không phải bắt buộc về mặt kỹ thuật, nhưng tránh được rất nhiều rắc rối vận hành về sau.

VRF "kirk" đại diện cho một tenant. Ngay cả khi chỉ có một tenant duy nhất (không multi-tenant), vẫn nên tạo VRF này: mọi interface, default gateway, và bảng định tuyến của EVPN sẽ nằm trong đó. Có thể tạo nhiều VRF tenant khác nhau nếu cần tách biệt traffic theo compliance hay tổ chức.

Bên trong một tenant VRF có hai loại forwarding space khác nhau, và phân biệt được hai loại này chính là chìa khóa để hiểu toàn bộ phần này:

  • Có thể có nhiều MAC VRF (Layer 2 VNI), một MAC VRF cho mỗi VLAN cần kéo dài (đã học ở Mục 5).
  • Chỉ có một IP VRF duy nhất (Layer 3 VNI) cho mỗi tenant VRF, dùng để routing giữa các MAC VRF/VLAN bên trong cùng tenant đó.

Symmetric IRB là gì?​

IRB (Integrated Routing and Bridging) là tên gọi chung cho việc tích hợp cả routing (layer 3) lẫn bridging (layer 2) vào cùng một cơ chế, thay vì tách thành hai hệ thống riêng biệt. Layer 3 VNI/IP VRF chính là phần "routing" trong IRB.

Trên switch vật lý, phần "routing" đó được hiện thực bằng một SVI (Switch Virtual Interface), một interface ảo layer 3 gắn với đúng một VLAN cụ thể. Gói tin đi vào VLAN đó ở layer 2; khi cần đi tiếp sang layer 3 (routing sang VLAN khác), nó phải đi qua đúng SVI của VLAN mình. Chính SVI này đóng vai trò default gateway mà mọi host trong VLAN đó trỏ tới. Như sẽ thấy ngay dưới đây, trong EVPN nó tồn tại dưới dạng Anycast Gateway: cùng một SVI, cùng một địa chỉ IP/MAC, có mặt giống hệt nhau trên mọi leaf.

Mô hình được trình bày ở đây là Symmetric IRB, mô hình phổ biến nhất trong thực tế (có một mô hình khác gọi là Asymmetric IRB, không cần IP VRF riêng, nhưng ít được dùng; sẽ so sánh kỹ ở phần sau). "Symmetric" nghĩa là: mọi leaf trong topology đều phải có Layer 3 VNI này, đối xứng trên toàn bộ thiết bị, bất kể leaf đó có đang host VLAN nào hay không.

Một điểm dễ gây nhầm lẫn: trên switch vật lý, mọi VNI, kể cả Layer 3 VNI, đều phải map vào một VLAN cục bộ, dù VLAN đó có thể không chứa host nào cả. Lý do nằm ở chính bản chất VXLAN: nó vốn dĩ là một cơ chế encapsulation ở Layer 2, nên muốn "vay mượn" nó để làm routing (Layer 3), thiết bị vẫn cần một VLAN "giả" làm chỗ gắn SVI/IRB đại diện cho VRF. Đó là lý do hầu hết switch, dù Cisco hay Juniper, đều bắt cấu hình thêm một VLAN riêng chỉ để phục vụ Layer 3 VNI, dù VLAN đó không liên quan gì đến VLAN "thật" nào của tenant.

Nhưng VLAN cục bộ này, kể cả VLAN giả phục vụ Layer 3 VNI, không cần đồng nhất giữa các leaf (VD: Layer 3 VNI 90000 của tenant có thể map vào VLAN 999 trên leaf 1 nhưng lại là VLAN 888 trên leaf 2; vẫn cùng một Layer 3 VNI, chỉ khác số VLAN dùng để hiện thực nó cục bộ trên từng switch). Ngược lại, VNI (VXLAN segment ID) bắt buộc phải globally significant trên toàn fabric: con số VNI phải giống nhau tuyệt đối ở mọi nơi, chính vì VNI mới là thứ EVPN control-plane dùng để nhận diện route, còn VLAN chỉ là chi tiết hiện thực nội bộ của từng thiết bị.

Lý do cần toàn bộ cơ chế "phức tạp" này: chính vì đã stretch layer 2 (để phục vụ vMotion, như đã nói ở Mục 2), nên khi cần route giữa hai layer 2 segment khác nhau, thay vì dựng hẳn một hệ thống routing tách biệt bên ngoài EVPN (phức tạp hơn nhiều), EVPN tích hợp luôn phần routing vào cùng cơ chế.

Đi theo một gói tin thật, từng bước​

Đây là phần quan trọng nhất của cả Phần 2. Hiểu được luồng dưới đây là đã nắm được phần lõi khó nhất của EVPN.

Giả sử Host 1 (10.1.1.11, VLAN 101) muốn gửi packet tới Host 2 (10.1.2.50, VLAN 102), khác subnet nên chắc chắn cần routing:

Symmetric IRB: Host1 to Host2 (different subnets)Host110.1.1.11 / VLAN101Host210.1.2.50 / VLAN102Leaf1 (VTEP 1.1.1.1)① SVI Anycast GW 10.1.1.1② Layer 2 VNI lacks the IP infoup to the Layer 3 VNI (IP VRF)③ Tra host route trong L3 VNI10.1.2.50/32 → VTEP 3.3.3.3④ Encap VXLAN (L3 VNI)src=1.1.1.1, dst=3.3.3.3Leaf3 (VTEP 3.3.3.3)⑤ Decap, read the target VNIVNI maps to local VLAN 102⑥ Tra MAC table VLAN 102look up the MAC of 10.1.2.50⑦ Forward ra port → Host2The packet crosses the underlay (VXLAN, VNI = Layer 3 VNI)
  1. Host 1 gửi packet tới default gateway, một SVI anycast (ví dụ 10.1.1.1 cho VLAN 101) tồn tại giống hệt nhau trên mọi leaf.
  2. Leaf1 nhận packet tại SVI: vì Layer 2 VNI (MAC VRF) chỉ chứa thông tin MAC, không đủ để routing theo IP, packet được đẩy lên Layer 3 VNI (IP VRF).
  3. Trong Layer 3 VNI đã có sẵn các host route dạng /32, ví dụ 10.1.2.50/32 nằm ở VTEP 3.3.3.3.
  4. Nhờ route này, Leaf1 biết chính xác cần gửi gói tin tới VTEP nào, không cần routing hop-by-hop qua nhiều thiết bị trung gian như một mạng layer 3 truyền thống, nên hiệu quả hơn nhiều.
  5. Gói tin được đóng gói VXLAN (source là VTEP của Leaf1, destination là VTEP của Leaf3) và gửi qua underlay.
  6. Leaf3 nhận, giải gói (decapsulate), dựa vào VNI đích trong header để biết ánh xạ vào VLAN cục bộ nào (VLAN 102).
  7. Sau khi vào đúng VLAN, Leaf3 tra MAC address table cục bộ để forward gói tin ra đúng port vật lý tới Host 2.

Một chi tiết hay bị bỏ qua ở bước ④: khi encapsulate, Leaf1 không chỉ gắn VNI = Layer 3 VNI mà còn viết lại địa chỉ MAC bên trong frame: source MAC giờ là router-MAC của chính Leaf1 (đại diện cho SVI vừa route gói tin), còn destination MAC là router-MAC của Leaf3, thứ mà Leaf1 đã học được từ trước qua EVPN Router's MAC extended community gắn kèm route Type 2 của Leaf3 (xem Mục 8).

Nhờ vậy, khi Leaf3 decap ở bước ⑤, nó nhận ra ngay đây là traffic được route tới chính mình (dst MAC khớp router-MAC cục bộ) chứ không phải traffic bridge thông thường, nên biết cần tiếp tục tra IP đích và bridge sang đúng VLAN 102, thay vì chỉ đơn thuần forward theo MAC gốc của Host 1 (MAC đó vốn dĩ Leaf3 còn chưa từng biết tới).

Lưu ý quan trọng: việc forwarding ở data plane luôn dựa vào ánh xạ VNI → VLAN cục bộ trên từng switch. Route target chỉ có vai trò populate đúng route vào đúng forwarding-space ở control plane, còn việc chuyển gói tin thực tế dựa vào VNI đích nằm ngay trong header VXLAN của gói tin.

Layer 3 VNI forwarding table phải đồng nhất thông tin trên mọi thiết bị trong fabric. Không giống Layer 2 VNI (nơi không phải leaf nào cũng cần có mọi VLAN), mọi leaf đều bắt buộc phải có Layer 3 VNI của tenant đó, kể cả khi leaf đó không host bất kỳ VLAN nào của tenant.

💡 Hình dung như thế này: toàn bộ cơ chế này giống một cỗ máy Rube Goldberg: rất nhiều bộ phận nhỏ phải vận hành đồng bộ (SVI, Layer 2 VNI, Layer 3 VNI, VXLAN encap/decap) chỉ để cuối cùng làm một việc rất đơn giản: đưa một gói tin từ điểm A đến điểm B.

4. Populate route trong Layer 3 VNI & Type 2 Sequence Number​

Thay vì "flood and learn" như layer 2 truyền thống, EVPN dùng cơ chế có thể gọi là "flood and route" hoặc "flood and announce".

Khi một host mới kết nối vào switch và được học tại local, switch sinh ra một EVPN Type 2 route chứa cả IP lẫn MAC address của host đó (ví dụ IP 10.1.1.11, MAC 00:00:00:00:00:11), cùng với một Sequence Number.

Sequence Number tồn tại để phục vụ đúng một tình huống: vMotion. Khi host di chuyển sang một leaf khác, leaf mới sẽ generate lại route (cùng MAC/IP) nhưng tăng Sequence Number lên. Nhờ đó các thiết bị khác trong fabric biết đây là bản cập nhật vị trí mới (host vừa di chuyển), chứ không phải một xung đột/duplicate cần cảnh báo.

Cơ chế này có quy tắc xử lý cụ thể (RFC 7432 §15.2, MAC Mobility Extended Community): lần đầu một MAC được advertise, route đi kèm không có MAC Mobility extended community (ngầm hiểu sequence = 0). Khi có tranh chấp (hai leaf cùng advertise một MAC), thiết bị nhận luôn chọn route có Sequence Number cao hơn; nếu bằng nhau mới xét tiếp tiêu chí phụ.

Quan trọng hơn: nếu một MAC "di chuyển" quá nhanh, mặc định ngưỡng là 5 lần trong 180 giây, thiết bị sẽ kết luận đây không phải vMotion thật, mà là tình huống duplicate MAC (ví dụ hai host bị cấu hình trùng MAC, hoặc có loop ở đâu đó khiến MAC "nhảy" liên tục), và sẽ dừng cập nhật/dấy cảnh báo thay vì tiếp tục di chuyển MAC đó qua lại vô hạn.

Type 2 Sequence Number During vMotionLeaf-1 advertisesMAC aa:bbseq = 0 (implicit)VM moves to Leaf-2Leaf-2 re-advertisesseq = 1Fabric compareshigher seq winsMAC now at Leaf-2More than 5 moves within 180 streated as duplicate MAC, updates stopSequence Number separates a real vMotion from two hosts fighting over one MAC

Một chi tiết dễ bị đơn giản hóa quá mức: route Type 2 này thực chất mang theo hai Route Target cùng lúc, không phải một. Một RT khớp với Layer 2 VNI/VLAN cục bộ (để các leaf khác đang cùng VLAN đó cài MAC vào MAC-VRF), RT còn lại khớp với Layer 3 VNI của tenant (để mọi leaf trong cùng tenant VRF, kể cả leaf không host VLAN 101, vẫn cài được host route /32 vào IP-VRF của mình, đúng như đã nói ở Mục 7).

Route còn kèm một thuộc tính riêng gọi là EVPN Router's MAC extended community, mang theo MAC vật lý thật của VTEP nguồn. Nhờ đó leaf nhận biết chính xác MAC nào cần dùng để đóng gói lại traffic khi route (chứ không bridge) traffic đó ở data plane. Việc "một route tách vào hai forwarding space" mô tả ngay dưới đây dựa trên chính thuộc tính này.

Giá trị VNI nằm trong khoảng từ 1 đến 16.777.215 (2²⁴−1, vì VNI là một trường 24-bit theo RFC 7348), con số đủ lớn để không bao giờ cạn kiệt dù mạng có scale lớn tới đâu.

Từ một Type 2 route (chứa cả MAC + IP), thông tin được tách và cài đặt vào hai forwarding space khác nhau trên thiết bị nhận:

  • Phần host route (IP /32) được cài vào Layer 3 VNI (IP VRF).
  • Phần MAC route được cài vào Layer 2 VNI (MAC VRF).
One Type 2 Route Lands In Two Forwarding SpacesEVPN Type 2 routeMAC aa:bb + IP 10.1.1.11/32carries RT of L2 VNI and RT of L3 VNIMAC VRF (L2 VNI 1000)installs MAC aa:bbonly on leaves holding VLAN 101IP VRF (L3 VNI 50000)installs host route /32on every leaf of the tenantRT matches L2 VNIRT matches L3 VNIOne route, two destinations: the Router MAC extended community is what makes this split possible

Nếu có nhiều tenant, mỗi tenant có Layer 3 VNI/IP VRF riêng để route giữa các layer 2 segment bên trong tenant đó. Các forwarding space này không cấu hình y hệt VRF truyền thống trên switch: VLAN được đối xử như một MAC VRF, còn IP VRF là một forwarding space riêng ở tầng layer 3.

5. Yêu cầu phần cứng cho EVPN​

VTEP là một tính năng phần cứng. Cần switch hỗ trợ mới triển khai được ở quy mô lớn, vì việc encapsulate/decapsulate VXLAN diễn ra ở tốc độ đường truyền (line-rate) trên ASIC, không thể xử lý bằng phần mềm nếu muốn hiệu năng thực tế.

Switch hiện đại (trong khoảng 5 năm gần đây, tính từ thời điểm loạt bài gốc được ghi lại) hầu hết đều route được VXLAN. Thế hệ switch VXLAN đời đầu chỉ có thể bridge: nghĩa là chỉ encapsulate HOẶC decapsulate một packet, không làm được cả hai cùng lúc, trừ khi packet được recirculate qua ASIC pipeline hai lần (làm giảm băng thông đáng kể).

Các nền tảng/chip được nhắc tới có khả năng route VXLAN: Nexus 9000 (dòng EX/FX/FX2/FX3), chip Broadcom Trident 2+/3/4, Tomahawk, và Jericho. Về kinh nghiệm thực tế: switch có tốc độ 25Gbps hoặc 100Gbps trở lên gần như chắc chắn route được VXLAN; nếu switch chỉ ở mức 10Gbps hoặc 40Gbps, nên kiểm tra kỹ datasheet trước khi giả định nó hỗ trợ.

6. Tự học EVPN & lời khuyên labbing​

Loạt bài này dừng ở mức nền tảng: hiểu cách các loại VRF hoạt động, cách MAC/IP được học và forward. Bước tiếp theo tự nhiên là phần sau, nơi các route type (Type 1, 2, 3, 5) và cơ chế học MAC/IP được trình bày chi tiết hơn nhiều so với những gì đã tóm lược ở đây. Xa hơn nữa là troubleshooting, tức đưa một mạng không hoạt động về trạng thái hoạt động được. Việc đó đòi hỏi hiểu rõ toàn bộ thành phần đang tham gia: route được announce ra sao, đi tới đâu, theo dõi được cả gói tin control-plane lẫn data-plane.

Gợi ý để tự lab: dùng Arista vEOS, tải miễn phí, không gây khó dễ, tài liệu và support đầy đủ; command line của Arista cũng khá giống Cisco nên người quen Cisco không mất nhiều công để chuyển sang. Cumulus VX cũng là một lựa chọn dễ dựng lab. Đây không phải khuyến nghị thiên vị vendor, chỉ là con đường ít trở ngại nhất để nhanh chóng có một lab EVPN, xem được routing table, VRF, hiểu mapping và hình dung route target trông ra sao.

Về thứ tự học: nên hiểu khái niệm trước, rồi mới bắt tay vào lab. Lab trước khi hiểu khái niệm chỉ dẫn tới việc gõ lệnh theo mẫu mà không biết vì sao.

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 sáu video sau:

  • Part 5: Understanding EVPN VRFs Part 2 — MAC VRF / L2VNI
  • Part 6: Stretched VLANs & Spanning Tree
  • Part 7: Understanding EVPN VRFs — IP VRF / L3VNI With Symmetric IRB
  • Part 8: EVPN Hardware Requirements
  • Part 9: Populating L3VNI Routes + Type 2 Sequence Numbers
  • Part 10: Self Learning & Labbing Recommendations

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

  • Giá trị VNI tối đa chính xác là 16.777.215 (2²⁴−1), không phải 16.777.214 như được nhắc trong video — VNI là một trường 24-bit theo RFC 7348 §5.
  • Symmetric IRB, mô hình được trình bày ở Mục 3, được chuẩn hoá chính thức ở RFC 9135 (10/2021) — video gốc trình bày như một design pattern chung, không trích RFC cụ thể.
  • Mục 4: video gốc mô tả Type 2 route như chỉ mang một Route Target theo Layer 2 VNI. Theo RFC 9135 và tài liệu Juniper về Symmetric IRB, route Type 2 thực chất mang hai Route Target (một cho MAC-VRF/L2 VNI, một cho IP-VRF/L3 VNI) cùng EVPN Router's MAC extended community — đây là cơ chế thực sự cho phép một route cài được vào cả hai forwarding space. Bài viết đã bổ sung chi tiết này vào Mục 4. (Juniper — Symmetric IRB with EVPN Type 2)
  • IP-VRF thực hiện lookup đối xứng trên cả MAC lẫn IP — RFC 9135, Juniper — Symmetric IRB with EVPN Type 2 Routes.
  • EVPN Type 5 (IP Prefix route) — RFC 9136.
  • Layer 3 VNI vẫn cần map vào một VLAN cục bộ (không chứa host) để gắn SVI/IRB cho VRF, vì VXLAN vốn là cơ chế Layer 2 — Cisco Community: VXLAN BGP EVPN – Why VLAN for L3 VNI?, Juniper — VXLAN and Layer 3 Logical Interfaces.
  • VNI phải giống nhau trên mọi leaf (globally significant), VLAN gán cho nó thì không — networklessons.com: VXLAN MP-BGP EVPN L3 VNI.

Tiếp theo: Phần 3: Route Types & Cách Học MAC/IP.