
Mục lục bài viết 9 phần
Một VRF có bảng route đúng chưa đủ chứng minh L3VPN được cô lập. Test plan cần kiểm tra Route Distinguisher, import/export Route Target, MP-BGP, label forwarding và các đường âm tính giữa tenant; đặc biệt khi có shared service hoặc route leak có chủ đích.
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 kiểm soát
Câu hỏi kỹ thuật cần trả lời
#RFC 4364 dùng Route Distinguisher để làm prefix VPNv4/VPNv6 duy nhất, còn Route Target extended community điều khiển VRF nào import route. RD không phải policy cô lập. Một prefix mang RT sai có thể được nhập vào VRF không mong muốn dù RD vẫn hợp lệ.
Mục tiêu kiểm thử gồm ba lớp: control plane chỉ phân phối/import đúng route; dataplane gắn và xử lý label đúng; traffic hợp lệ đi được trong khi traffic giữa tenant bị chặn. Shared service cần kiểm tra cả chiều đi và chiều về, tránh asymmetric route hoặc leak rộng hơn dự kiến.
Topology và điều kiện đo
#Dùng hai PE, ít nhất hai P hoặc core path, route reflector nếu production có, hai CE cho mỗi tenant và một VRF shared service. Traffic generator mô phỏng prefix/flow của tenant A, tenant B và shared service. Thu MP-BGP RIB, VRF RIB/FIB, label table, interface counter và capture ở CE/PE.
Chạy baseline khi mọi RT đúng. Sau đó thêm negative prefix không được phép, đổi một export RT và gây failover PE/core có kiểm soát. Đồng bộ thời gian giữa generator, PE và collector để gắn BGP update với packet loss/convergence.

Biến số phải kiểm soát
#Khóa RD/RT, address family, route policy, next-hop behavior, add-path, graceful restart, BFD, label mode và maximum-prefix. Ghi rõ CE-PE dùng static, OSPF, BGP hay giao thức khác. Nếu có RT-Constrain theo RFC 4684, xác nhận peer và policy hỗ trợ trước khi diễn giải số route nhận.
Traffic profile cần nhiều flow hai chiều, prefix trùng giữa tenant và cả frame size nhỏ/lớn. Prefix trùng là bài test quan trọng vì VPN phải giữ context VRF; nhưng địa chỉ trùng không tự chứng minh cách NAT/firewall/shared service sẽ xử lý đúng.
KPI và bằng chứng đầu ra
#KPI gồm route import accuracy, route propagation time, VRF convergence, packet loss duration, latency p99, unexpected reachability và label-path correctness. “Route có trong BGP” không đồng nghĩa route đã vào VRF FIB hoặc traffic được chuyển tiếp.
Lưu BGP update/withdraw timeline, RT community, VRF RIB/FIB snapshot, MPLS label stack và tx/rx sequence. Với negative test, bằng chứng đạt là không có route/traffic ngoài policy; timeout của application một mình không cho biết bị drop ở đâu.
- Kịch bản: A ↔ A · Expected control plane: import đúng RT-A · Expected traffic: pass · Bằng chứng: VPN route, label, tx/rx
- Kịch bản: A → B · Expected control plane: không import RT-B · Expected traffic: fail có chủ đích · Bằng chứng: absence trong VRF + capture
- Kịch bản: A → shared · Expected control plane: import RT-shared theo policy · Expected traffic: pass đúng dịch vụ · Bằng chứng: route/ACL/session
- Kịch bản: B → shared · Expected control plane: policy độc lập · Expected traffic: pass/fail theo ma trận · Bằng chứng: bidirectional evidence
- Kịch bản: RT sai · Expected control plane: route bị từ chối · Expected traffic: không có reachability · Bằng chứng: policy hit + RIB/FIB
- Kịch bản: PE failover · Expected control plane: route hội tụ đường dự phòng · Expected traffic: loss trong ngân sách · Bằng chứng: update/FIB/packet timeline
Ma trận Route Target và quyết định
#Lập ma trận VRF × RT thay vì chỉ danh sách cấu hình. Mỗi ô nêu import, export, service được phép và owner. Shared service thường cần nhiều RT hoặc route leaking có kiểm soát; không dùng một RT chung cho mọi tenant chỉ để “dễ vận hành”.
Thử cả lỗi cấu hình có khả năng xảy ra: copy nhầm RT, policy match rộng, prefix-list rỗng, community bị strip và rollback chưa hoàn chỉnh. Pass/fail cần bao gồm alert khi thay đổi tạo unexpected route, không chỉ kết quả connectivity sau cùng.
Test plan từng bước
#- Chụp RD/RT, policy, MP-BGP peer và VRF RIB/FIB baseline.
- Quảng bá prefix tenant A/B, gồm một dải địa chỉ trùng.
- Xác minh import/export và traffic nội bộ từng tenant.
- Phát traffic A↔B; xác minh không có unexpected reachability.
- Bật shared service theo ma trận, kiểm tra hai chiều và stateful path.
- Chèn RT sai/prefix ngoài allowlist trong lab; kiểm tra reject và alert.
- Fail PE hoặc core path; đo convergence và label path mới.
- Withdraw route, xác minh stale entry không còn trong RIB/FIB.
- Rollback, so cấu hình và traffic với baseline.
Checklist thay đổi và rollback
#- Có ma trận VRF–RT được owner phê duyệt.
- Kiểm tra cả import và export ở mọi PE liên quan.
- Có negative flow giữa từng cặp tenant.
- Shared service kiểm tra route chiều về và firewall state.
- Alert cho unexpected prefix/RT hoặc maximum-prefix.
- Có out-of-band management và lệnh rollback.
- Lưu RIB/FIB/label trước và sau thay đổi.
- Xác nhận stale route được withdraw hoàn toàn.

Giới hạn của kết luận
#Kết quả phụ thuộc implementation, scale route, RR topology, label mode, CE-PE protocol và policy. Lab hai PE không chứng minh control plane ở hàng trăm PE hoặc nhiều AS. MPLS L3VPN cô lập routing nhưng không tự thay thế firewall, identity policy hay mã hóa.
Một lần ping A→B thất bại không chứng minh mọi giao thức bị cô lập; ngược lại route leak có chủ đích không phải lỗi nếu đúng ma trận. Báo cáo phải nêu rõ prefix, port/protocol, chiều traffic và điểm quan sát.
Khái niệm cần nhớ
#- VRF: Bảng routing/forwarding độc lập trên thiết bị.
- RD: Làm route VPNv4/VPNv6 duy nhất; không quyết định import.
- Route Target: Extended community dùng cho policy import/export VPN route.
- MP-BGP: BGP đa giao thức mang VPN route và thuộc tính liên quan.
- Route leak: Chia sẻ route giữa các miền vốn tách biệt, có chủ đích hoặc do lỗi.
- RT-Constrain: Cơ chế hạn chế phân phối VPN route theo RT quan tâm.
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ảo4 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.
