
Mục lục bài viết 10 phần
EVPN multihoming không chỉ là bài toán “rút một dây và còn ping”. Một thiết kế đạt yêu cầu phải ngăn loop và duplicate, phân phối lưu lượng đúng vai trò Designated Forwarder (DF), giữ reachability khi một PE hoặc attachment circuit hỏng, rồi hội tụ mà không để MAC/IP state cũ gây blackhole. Test plan cần nối được từng sự kiện control plane với packet loss và service restoration ở data plane.
Bài viết giúp bạn
- Câu hỏi kỹ thuật cần trả lời
- Topology và điều kiện đo
- Biến số phải khóa trước khi chạy
Câu hỏi kỹ thuật cần trả lời
#Ethernet VPN (EVPN) dùng BGP để quảng bá reachability MAC/IP và trạng thái Ethernet Segment. Với một CE nối đa đường tới nhiều Provider Edge (PE), bài kiểm thử phải trả lời bốn câu hỏi: PE nào được phép chuyển Broadcast, Unknown Unicast và Multicast (BUM) về segment; lưu lượng unicast được phân phối qua các PE ra sao; trạng thái được rút nhanh thế nào khi link hoặc PE hỏng; và có loop, duplicate hoặc blackhole trong quá trình hội tụ hay không.
RFC 7432 định nghĩa EVPN và các cơ chế như Ethernet Auto-Discovery route, MAC/IP Advertisement route, aliasing và mass withdrawal. RFC 8584 bổ sung DF Election Extended Community và các thuật toán lựa chọn DF. Tuy nhiên, RFC không thay cho tiêu chí dịch vụ: cùng một control-plane convergence vẫn có thể tạo thời gian gián đoạn khác nhau do FIB programming, ARP/ND, hashing hoặc state của thiết bị biên.
Topology và điều kiện đo
#Topology tối thiểu gồm CE-A dual-homed tới PE-1/PE-2 trên cùng Ethernet Segment Identifier (ESI), CE-B hoặc endpoint phía xa sau PE-3, một hoặc hai route reflector, và bộ phát/thu lưu lượng đặt hai phía. Nếu triển khai VXLAN EVPN, ghi rõ vai trò VTEP, VNI, underlay và replication method; nếu MPLS EVPN, ghi rõ label stack và transport.
Chạy riêng hai profile. Với all-active, phát nhiều flow hai chiều để quan sát load distribution và aliasing. Với single-active, giữ cùng traffic profile nhưng kiểm rằng chỉ PE đúng vai trò chuyển tiếp tới segment. Lưu lượng nên gồm known unicast, unknown unicast, broadcast ARP/ND, multicast nếu có, cùng gói kích thước nhỏ/lớn và tốc độ đủ làm lộ microburst.

Biến số phải khóa trước khi chạy
#Không so sánh hai lần chạy nếu khác ESI, redundancy mode, DF algorithm, route-target, encapsulation, hashing key hoặc timer. Ghi lại phiên bản phần mềm, line card, số lượng MAC/host route, số flow, entropy, MTU, BFD nếu dùng và thời gian đồng bộ clock. Với VXLAN, khóa cả ingress replication hay multicast underlay; với MPLS, khóa transport label và ECMP path.
Đặc biệt tách ba mốc: thời điểm lỗi vật lý hoặc injected fault; thời điểm BGP EVPN route thay đổi; thời điểm data plane trở lại pass. Nếu chỉ đọc log BGP, nhóm kiểm thử có thể kết luận sớm trong khi traffic vẫn mất do FIB hoặc neighbor state chưa hoàn tất.
- Biến số: Redundancy mode · Giá trị cần ghi: all-active/single-active · Vì sao ảnh hưởng: Quy định đường hợp lệ và hành vi DF
- Biến số: DF algorithm · Giá trị cần ghi: service-carving/modulus/HRW nếu hỗ trợ · Vì sao ảnh hưởng: Ảnh hưởng phân bố VLAN/VNI và churn
- Biến số: Traffic entropy · Giá trị cần ghi: 5-tuple, số flow · Vì sao ảnh hưởng: Quyết định mức sử dụng các PE
- Biến số: Route scale · Giá trị cần ghi: MAC/IP, A-D per ES/EVI · Vì sao ảnh hưởng: Tác động thời gian rút route/FIB
- Biến số: Timers · Giá trị cần ghi: BGP, hold-down, BFD, ES · Vì sao ảnh hưởng: Tác động detection và convergence
- Biến số: Failure method · Giá trị cần ghi: link down, process, reload, isolate · Vì sao ảnh hưởng: Tạo các tín hiệu lỗi khác nhau
KPI và bằng chứng đầu ra
#KPI chính là packet loss theo burst và tổng số gói, service restoration time, duplicate packet, out-of-order, throughput, latency/jitter trước–trong–sau lỗi. Với BUM, thêm số bản sao nhận ở CE và tỷ lệ sai khác so với baseline. Với control plane, đo thời gian DF state đổi, A-D route hoặc MAC/IP route bị rút/đổi next hop, và thời gian FIB được lập trình.
Bộ bằng chứng tối thiểu gồm PCAP có timestamp đồng bộ ở ingress/egress, BGP EVPN RIB trước/sau lỗi, bảng ESI/DF, forwarding table, interface counter và event log. Một ca chỉ “ping không rớt” không đủ chứng minh split-horizon, aliasing hoặc mass withdrawal đúng ở traffic profile thực tế.
Ma trận ca kiểm thử
#Đặt pass/fail định lượng trước khi chạy: ví dụ restoration không vượt ngưỡng dịch vụ, duplicate bằng 0 cho flow không cho phép nhân bản, và không còn route/FIB stale sau thời gian ổn định. Con số cụ thể phải đến từ SLA và topology của hệ thống, không lấy mặc định từ phòng lab khác.
- Ca: EVPN-01 · Sự kiện: Baseline ổn định · Traffic: known unicast đa flow · Kỳ vọng: Không loss; phân bố hợp chính sách · Bằng chứng bắt buộc: PCAP, per-link counter, RIB/FIB
- Ca: EVPN-02 · Sự kiện: Down một member CE–PE · Traffic: unicast + BUM · Kỳ vọng: Không loop/duplicate; phục hồi trong SLA · Bằng chứng bắt buộc: Link event, traffic timeline, DF state
- Ca: EVPN-03 · Sự kiện: PE tiến trình BGP dừng · Traffic: bidirectional · Kỳ vọng: Route rút/chuyển; không blackhole kéo dài · Bằng chứng bắt buộc: BGP update, FIB, PCAP
- Ca: EVPN-04 · Sự kiện: PE mất nguồn/isolate · Traffic: mixed traffic · Kỳ vọng: Mass withdrawal có hiệu lực · Bằng chứng bắt buộc: A-D route, loss burst, restoration
- Ca: EVPN-05 · Sự kiện: RR mất kết nối · Traffic: steady + MAC move · Kỳ vọng: Data plane ổn định theo thiết kế · Bằng chứng bắt buộc: RR/PE RIB, traffic continuity
- Ca: EVPN-06 · Sự kiện: Khôi phục PE · Traffic: nhiều VLAN/VNI · Kỳ vọng: DF ổn định, không churn diện rộng · Bằng chứng bắt buộc: DF per EVI, duplicate/loss
- Ca: EVPN-07 · Sự kiện: MAC move hợp lệ · Traffic: unicast · Kỳ vọng: Sequence tăng; đường cũ bị loại · Bằng chứng bắt buộc: MAC Mobility EC, FIB, PCAP
- Ca: EVPN-08 · Sự kiện: ESI/config sai có chủ đích · Traffic: BUM · Kỳ vọng: Fail-closed hoặc alarm rõ · Bằng chứng bắt buộc: Alarm, route state, absence of loop
Test plan DF election và split-horizon
#Khởi đầu bằng snapshot DF theo từng Ethernet Tag/EVI. Đối chiếu PE được chọn với thuật toán và preference cấu hình. Sau đó down attachment circuit trên DF hiện tại, đánh dấu thời điểm lỗi, theo dõi route update và kiểm PE còn lại bắt đầu chuyển BUM. Khi link trở lại, quan sát có “double-forwarding window” hay churn giữa các EVI không.
Để kiểm split-horizon, phát BUM từ core về segment và đồng thời capture trên cả attachment circuit. Một frame không được quay lại core qua PE khác hoặc xuất hiện thành bản sao ngoài kỳ vọng. Lặp với unknown unicast và multicast; chỉ nhìn counter tổng có thể che giấu duplicate ngắn.
Bổ sung ca BUM xuất phát từ CE vào một PE và kiểm PE khác không đưa bản sao từ core trở lại cùng Ethernet Segment. Đây là kiểm chứng split-horizon trực tiếp; ca BUM từ core về CE chủ yếu kiểm DF và duplicate suppression. Với all-active, DF không phải cổng duy nhất cho mọi known-unicast flow.
Test plan aliasing, mass withdrawal và lỗi PE
#Aliasing cho phép PE phía xa dùng các PE quảng bá cùng Ethernet Segment làm next hop tới MAC ở segment. Tạo đủ flow để quan sát hashing, rồi rút riêng một MAC/IP route và so với rút A-D per ES. Khi một PE mất đột ngột, kỳ vọng mass withdrawal loại đường liên quan nhanh hơn việc chờ rút từng MAC route; hãy đo bằng packet timeline thay vì chỉ xác nhận route biến mất.
Lặp lỗi theo ba cách: interface shutdown có tín hiệu rõ, cô lập control plane nhưng giữ data link, và mất PE hoàn toàn. Ba ca này không tương đương. Ca control-plane isolation đặc biệt quan trọng để tìm trạng thái half-alive, nơi một PE còn chuyển tiếp nhưng peer hoặc RR đã nhìn khác.

Runbook thực thi và phân tích
#Khi phân tích, chia gián đoạn thành detection time, control-plane propagation, FIB programming và endpoint relearning. Cách tách này giúp xác định nên tối ưu timer, signaling hay data plane, thay vì quy mọi mất gói cho “BGP chậm”.
- Đồng bộ clock và xác nhận timestamp PCAP giữa các điểm đo.
- Lưu cấu hình, phiên bản, topology, RIB/FIB và DF baseline.
- Chạy traffic tối thiểu 5–10 phút để lấy phân bố latency, jitter, packet loss nền.
- Inject đúng một lỗi; không thay đổi timer hoặc traffic cùng lúc.
- Thu capture, BGP update, state DF/ESI, counter và log theo cùng timeline.
- Chờ trạng thái ổn định, khôi phục lỗi và đo cả quá trình reversion.
- Lặp đủ số lần để báo median, percentile và worst case; không chỉ chọn lần đẹp nhất.
- So kết quả với pass/fail đã duyệt; đánh dấu mọi khác biệt giữa control plane và dịch vụ.
Giới hạn kết luận
#Kết quả chỉ có hiệu lực với mode, encapsulation, scale, timer, phần cứng và phiên bản đã đo. Không suy rộng từ một VLAN sang hàng nghìn EVI, từ link-down sang power-loss, hoặc từ lab route reflector đơn sang production nhiều cluster. Thuật toán DF đúng tiêu chuẩn cũng không tự chứng minh SLA ứng dụng.
Nếu thiết bị có cơ chế tối ưu riêng, ghi tên tính năng và phiên bản, nhưng giữ tiêu chí đánh giá vendor-neutral: packet path hợp lệ, không loop/duplicate, route/FIB nhất quán và restoration trong ngưỡng. Mọi tuyên bố về tốc độ hội tụ phải kèm điều kiện đo.
Khái niệm cần nhớ
#- Ethernet Segment (ES): Tập liên kết từ CE tới một hoặc nhiều PE được nhận diện bởi ESI.
- DF: PE được chọn để chuyển một số loại traffic giữa EVPN core và segment.
- Aliasing: Dùng nhiều PE cùng quảng bá segment làm next hop tới MAC phía sau segment.
- Mass withdrawal: Rút reachability của nhiều MAC qua việc rút route liên quan Ethernet Segment.
- Split-horizon: Cơ chế ngăn frame quay lại segment và tạo loop.
- MAC Mobility: Cơ chế phân biệt và ưu tiên vị trí MAC mới khi endpoint di chuyển.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
