SDWAN Hub And Spoke

[dangquangminh]

Cisco SD-WAN Hub-and-Spoke Topology


(Phân tích chuyên sâu + góc nhìn thiết kế thực chiến)

1. Bài toán thực tế: Khi Full-Mesh trở thành vấn đề


Trong kiến trúc Cisco SD-WAN, hành vi mặc định của hệ thống là:

Tất cả các vEdge routers sẽ thiết lập full-mesh topology với nhau trong cùng một service VPN.

Điều này có nghĩa:

• Mọi site đều có thể giao tiếp trực tiếp với nhau
• vSmart sẽ quảng bá toàn bộ prefix đến tất cả các vEdge
• IPSec tunnels được thiết lập giữa mọi cặp TLOC

👉 Nghe có vẻ lý tưởng… nhưng trong thực tế:

• Số lượng tunnel tăng theo cấp số nhân
• Tốn tài nguyên CPU / memory (đặc biệt với branch router thấp cấp)
• Khó kiểm soát traffic flow (compliance, security, segmentation)

---

2. Cơ chế hoạt động của Full Mesh (Hiểu sâu bản chất)

2.1 Control Plane – OMP


vSmart đóng vai trò:

• Thu thập route từ tất cả vEdge
• Redistribute toàn bộ route đến tất cả site

Ví dụ từ lab:

• vEdge1 học route của site 3 và site 4 qua OMP

Điều này dẫn đến:
→ Tất cả site đều biết route của nhau

---

2.2 Data Plane – IPSec Tunnels


Mỗi vEdge sẽ:

• Tạo tunnel tới tất cả TLOC của các vEdge khác
• Nếu có nhiều WAN (biz-internet, public-internet) → số tunnel tăng mạnh

Ví dụ:

• 3 routers + 2 WAN links → mỗi router có 8 IPSec tunnels

👉 Đây chính là điểm “nổ scale” trong SD-WAN

---

3. Giải pháp: Hub-and-Spoke Topology

3.1 Ý tưởng cốt lõi


Thay vì full-mesh:

• Hub ↔ tất cả Spokes
• Spoke ❌ Spoke (bị chặn)

Kết quả:

• Traffic phải đi qua Hub
• Giảm số lượng tunnels
• Kiểm soát traffic tốt hơn

---

3.2 Ứng dụng thực tế


Hub-and-Spoke thường dùng khi:

• Data center làm trung tâm (Hub)
• Branch chỉ cần truy cập DC, không cần giao tiếp ngang
• Yêu cầu:
  • Security inspection (Firewall tại Hub)
  • Logging / Compliance
  • Centralized services

---

4. Cách triển khai (Centralized Policy trên vManage)

Bước 1: Tạo Site List


Phân nhóm:

• HUB: site 2
• SPOKES: site 3, site 4

---

Bước 2: Tạo VPN List

• Áp dụng cho VPN 10 (service VPN)

---

Bước 3: Tạo Topology Policy


Chọn:

• Topology → Hub-and-Spoke
• Gán:
  • Hub site
  • Spoke sites

---

Bước 4: Activate Policy

• Push policy xuống vSmart
• vSmart sẽ điều chỉnh việc quảng bá route

---

5. Điều gì thực sự thay đổi? (Điểm quan trọng nhất)

5.1 Control Plane thay đổi


Sau khi áp policy:

• Hub:
  • Vẫn nhận route từ tất cả spoke
• Spoke:
  • Chỉ nhận route của Hub
  • Không nhận route từ spoke khác

👉 Đây là điểm mấu chốt:

vSmart ngừng quảng bá route spoke-to-spoke

---

5.2 Data Plane thay đổi

• Spoke:
  • Chỉ tạo IPSec tunnel với Hub
• Hub:
  • Vẫn có tunnel đến tất cả spoke

👉 Kết quả:

• Giảm số tunnel đáng kể
• Giảm overhead

---

5.3 Behavior thực tế (Lab verification)

• Hub ping spoke: ✅ OK
• Spoke ping spoke: ❌ FAIL

👉 Traffic buộc phải đi qua Hub

---

6. Insight quan trọng (CCIE-level)

6.1 Hub-and-Spoke KHÔNG phải Data Plane policy


Nhiều người hiểu sai:

❌ Không phải firewall rule
❌ Không phải ACL

👉 Đây là:

Control-plane manipulation (OMP route advertisement)

---

6.2 Tunnel vẫn tồn tại một phần


Điểm thú vị:

• Hub vẫn giữ full tunnels
• Spoke giảm tunnels

👉 Không phải “xóa hết tunnel”, mà là:

giảm selective connectivity

---

6.3 Trade-off


Ưu điểm:

• Scale tốt hơn
• Control tốt hơn
• Central security

Nhược điểm:

• Tăng latency (spoke → spoke phải qua hub)
• Hub trở thành bottleneck

---

7. Khi nào nên dùng?

NÊN dùng:

• Enterprise có DC trung tâm
• Branch chỉ truy cập ứng dụng nội bộ
• Có firewall / IDS tại hub

---

KHÔNG nên dùng:

• Site cần giao tiếp trực tiếp (VoIP, video, east-west traffic)
• Low latency requirement

---

8. Kết luận


Hub-and-Spoke trong SD-WAN không chỉ là topology, mà là:

Một kỹ thuật điều khiển control-plane để tối ưu scale và kiểm soát traffic

Tóm lại:

• Default: Full Mesh → linh hoạt nhưng không scale
• Hub-Spoke: kiểm soát tốt → phù hợp enterprise thực tế

---

Nếu bạn đang triển khai SD-WAN thực tế, câu hỏi quan trọng không phải là:

👉 “Dùng Hub hay Full Mesh?”

Mà là:

“Ứng dụng của bạn cần traffic pattern như thế nào?”