Tweet
vPC Data Plane – Luồng lưu lượng trong miền vPC
Khi giao tiếp với các mạng bên ngoài, miền vPC (vPC domain) luôn ưu tiên forward traffic qua các cổng local (local vPC member ports).
Peer-link chỉ được sử dụng trong các tình huống bắt buộc, chứ không phải là đường chuyển tiếp mặc định.
👉 Đây là nguyên tắc nền tảng của vPC:
Peer-link không phải uplink chính – nó là đường hỗ trợ (supporting path).
Luồng traffic chuẩn (Regular Traffic Path)
Trong kịch bản chuẩn khi hệ thống hoạt động bình thường:
• Traffic từ Core 1 / Core 2 đi xuống Aggregation qua Layer 3 Port-Channel
• Tại Aggregation (cặp Nexus chạy vPC), traffic được switch L2 qua vPC member ports
• Traffic đi tiếp xuống Access Switch rồi tới endpoint
• Chiều ngược lại (return traffic) đi đúng cùng hướng, không vòng qua peer-link
Điểm mấu chốt:
👉 Mỗi vPC peer luôn cố gắng forward traffic ra cổng local của chính nó.
Khi nào traffic mới đi qua vPC Peer-Link?
Một vPC peer chỉ forward traffic qua peer-link khi:
• Không còn vPC member port local nào đang active cho vPC đó
• Ví dụ: toàn bộ vPC member ports trên switch A down → traffic được gửi sang switch B qua peer-link để thoát ra vPC
👉 Đây là cơ chế failover data plane, không phải forwarding thường xuyên.
vPC và FHRP – Peer-Gateway làm thay đổi hành vi forward
Trong thực tế, Aggregation chạy vPC gần như luôn kết hợp FHRP, ví dụ:
• HSRP
• GLBP
• VRRP Hành vi FHRP truyền thống
• Chỉ Active router forward traffic cho virtual MAC
• Standby router drop frame, chỉ chờ takeover Khi kết hợp với vPC + peer-gateway
Cisco nâng cấp hành vi forwarding như sau:
• Cả Active và Standby FHRP đều được phép forward traffic
• Frame gửi tới FHRP virtual MAC có thể được xử lý local, không cần đi peer-link
• Chỉ thiết bị FHRP primary mới trả lời ARP, còn secondary chỉ forward data plane
👉 Peer-gateway giúp:
• Giảm traffic đi peer-link
• Tránh hairpin forwarding
• Tối ưu latency & bandwidth
• Phù hợp thiết kế active-active thật sự
Các nguyên tắc & giới hạn quan trọng khi triển khai vPC
1. Ghép cặp phần cứng
• Nexus 9200 chỉ ghép với Nexus 9200
• Nexus 9300 chỉ ghép với Nexus 9300
❌ Không mix 9200 + 9300
2. Peer-link bắt buộc tốc độ cao
• Peer-link tối thiểu 10Gbps
• Cisco khuyến nghị ít nhất 2×10G chạy dedicated
👉 Không bao giờ dùng 1 link duy nhất
3. Keepalive không được chạy trên peer-link
• vPC keepalive phải chạy qua hạ tầng L3 riêng
• Mục tiêu: tránh split-brain khi peer-link gặp sự cố
4. Một switch = một vPC domain
• Không có chuyện 1 switch tham gia nhiều vPC domain
• Thiết kế phải rõ ràng từ đầu
5. vPC bản chất là Layer 2
• vPC là L2 Port-Channel
• Không hỗ trợ L3 Port-Channel truyền thống
• Từ NX-OS 7.0(3)I5(1):
– Hỗ trợ L3 over vPC
– Chỉ cho unicast
– Không phải full L3 như nhiều người lầm tưởng
6. Static routing tới FHRP virtual IP
• vPC cho phép static route trỏ vào FHRP address
• Nhờ cơ chế peer-gateway + FHRP enhancement
7. vPC làm L2 link cho routing adjacency
• Có thể dùng vPC như L2 transit giữa 2 router ngoài
• Lưu ý: các routing restriction của vPC vẫn áp dụng
Câu hỏi ôn tập (Content Review)
❓ Hai mục đích của vPC peer-link là gì? (Chọn 2)
✅ Cisco Fabric Services
→ Đồng bộ MAC, ARP, IGMP, trạng thái port, consistency
✅ IGMP snooping information exchange
→ Đồng bộ multicast state giữa hai vPC peers
❌ keepalive OOB messages
❌ traffic duplication
❌ Layer 3 MAC address exchange
❌ communication giữa member và domain
❓ Giao thức control-plane dùng để học & đồng bộ MAC trong vPC?
✅ Cisco Fabric Services (CFS)
❌ Rapid-PVST
❌ PVST
❌ HSRP
Tổng kết góc nhìn CCIE
vPC không chỉ là dual-homing L2, mà là:
• Thiết kế data plane local-first
• Peer-link = last-resort path
• Control-plane dựa vào CFS, không phải STP
• Kết hợp peer-gateway + FHRP để đạt active-active thực sự
👉 Hiểu đúng data-plane behavior là chìa khóa để:
• Troubleshoot loop
• Phân tích asymmetric traffic
• Thiết kế DC fabric chuẩn chỉnh
Attached Files