Bài 88: So sánh quản lý mạng truyền thống vs Controller-based networking

💡 Liên hệ thực tế

Ở Bài 87, anh Nam đã dùng Ansible để đẩy cấu hình NTP cho 40 switch cùng lúc — nhưng đó vẫn là cách "gửi lệnh CLI hàng loạt", mỗi switch vẫn tự mình quyết định mọi thứ về routing, MAC table, STP... hoàn toàn độc lập với nhau.

Giờ hãy tưởng tượng chị Lan quản lý một chuỗi 15 chi nhánh, mỗi chi nhánh có 1 switch Layer 3 tự chạy OSPF riêng để học đường đi. Khi cần đổi chính sách định tuyến, chị Lan (hoặc anh Nam) vẫn phải touch từng switch một — dù dùng Ansible hay gõ tay, bản chất là 15 "bộ não" độc lập vẫn phải được thuyết phục riêng lẻ.

Controller-based networking đặt câu hỏi khác hẳn: nếu gom "bộ não" ra khỏi từng switch, đưa về một nơi tập trung duy nhất, thì sao? Khi đó, thay vì thuyết phục 15 bộ não, chị Lan chỉ cần nói chuyện với đúng 1 bộ não trung tâm — bộ não đó sẽ tự quyết định và ra lệnh ngược lại cho toàn bộ 15 switch.

---

📘 Kiến thức cốt lõi

1. Ba mặt phẳng hoạt động của một thiết bị mạng

Mọi thiết bị mạng (switch, router) đều vận hành dựa trên 3 "mặt phẳng" (plane) chức năng:

🎯 Data plane không tự "nghĩ" — nó chỉ tra bảng và chuyển tiếp. Control plane mới là phần "nghĩ", quyết định bảng đó chứa gì. Nếu không có Control plane, Data plane vẫn hoạt động được ở mức tối thiểu (ví dụ switch vẫn flood frame khi chưa học MAC), nhưng sẽ rất kém hiệu quả ở quy mô lớn.

2. Mô hình mạng truyền thống: Control plane phân tán

Trong mô hình truyền thống mà khóa học đã học xuyên suốt từ đầu (OSPF, STP, EIGRP...), mỗi thiết bị tự chạy Control plane của riêng mình. Mỗi router tự tính toán bảng định tuyến, mỗi switch tự học bảng MAC và tự chạy STP để chặn vòng lặp — độc lập với các thiết bị khác, chỉ trao đổi thông tin qua các gói tin giao thức (OSPF Hello, BPDU...).

📎 Đây chính là mô hình distributed control plane (control plane phân tán): "bộ não" nằm rải rác trên từng thiết bị, không có nơi nào nhìn thấy toàn cảnh mạng cùng một lúc.

Mô hình này đã chứng minh được độ ổn định qua hàng chục năm, nhưng có hai giới hạn khi mạng mở rộng:

• Muốn thay đổi chính sách áp dụng cho toàn mạng, phải touch từng thiết bị (bằng CLI hoặc automation như Bài 87).
• Không có nơi nào có "cái nhìn toàn cục" về trạng thái thực tế của cả hệ thống tại một thời điểm — muốn biết, phải hỏi lại từng thiết bị.

3. Mô hình Controller-based networking: Control plane tập trung

Controller-based networking tách rời Control plane ra khỏi từng thiết bị, gom vào một controller trung tâm. Lúc này:

• Controller đảm nhiệm gần như toàn bộ Control plane — có cái nhìn toàn cục về mạng, tự tính toán và ra quyết định.
• Thiết bị mạng (switch/router) chỉ còn giữ lại Data plane — nhận lệnh từ controller và chuyển tiếp dữ liệu theo đúng bảng mà controller đã tính sẵn.

⚠️ Controller-based networking không loại bỏ Data plane hay xóa bỏ kiến thức routing/switching truyền thống — nó chỉ chuyển phần "ra quyết định" (Control plane) lên một lớp tập trung. Thiết bị vật lý vẫn phải hiểu và thực thi đúng những gì controller yêu cầu.

4. Northbound API và Southbound API

Controller không hoạt động một mình — nó cần giao tiếp theo hai hướng:

• Southbound API (giao tiếp "xuống"): kênh giao tiếp giữa controller và các thiết bị mạng vật lý bên dưới, dùng để đẩy cấu hình và thu thập trạng thái. Ví dụ: NETCONF, RESTCONF, OpenFlow — các giao thức đã học ở Bài 87.
• Northbound API (giao tiếp "lên"): kênh giao tiếp giữa controller và các ứng dụng/phần mềm quản lý ở lớp trên, thường ở dạng REST API. Đây là cách các ứng dụng nghiệp vụ (dashboard, hệ thống ticketing, phần mềm giám sát riêng của doanh nghiệp) "nói chuyện" với controller mà không cần biết chi tiết bên dưới controller đang dùng giao thức gì để điều khiển thiết bị.

📎 Cách nhớ đơn giản: Southbound đi xuống thiết bị, Northbound đi lên ứng dụng. Controller đóng vai trò lớp trung gian phiên dịch giữa hai hướng này.

5. Ví dụ về sản phẩm controller

Cisco cung cấp controller cho các loại hạ tầng khác nhau, ví dụ Cisco DNA Center (nay gọi là Catalyst Center) cho mạng campus có dây và không dây. Bài 89 sẽ đi sâu vào khái niệm SDN (Software-Defined Networking) và cách Cisco DNA Center vận hành cụ thể — bài này chỉ dừng ở mức hiểu vì sao mô hình controller-based ra đời và khác gì so với mô hình truyền thống.

---

💬 Hỏi & Đáp nhanh

❓ Controller-based networking có thay thế được kiến thức OSPF, STP, VLAN đã học ở các bài trước không?

✅ Không. Controller vẫn cần hiểu và vận dụng đúng các khái niệm đó để tính toán ra quyết định — chỉ là nơi ra quyết định chuyển từ từng thiết bị sang một controller tập trung. Thiết bị vật lý (Data plane) vẫn phải forward đúng theo các nguyên lý switching/routing đã học.

❓ Nếu controller gặp sự cố thì cả mạng có ngừng hoạt động ngay không?

✅ Tùy kiến trúc triển khai. Vì controller nắm phần lớn Control plane, hầu hết thiết kế controller-based đều yêu cầu triển khai controller ở chế độ dự phòng cao (High Availability) để tránh trở thành điểm lỗi trung tâm (single point of failure) của toàn mạng.

❓ Southbound API và Northbound API, cái nào dùng để kỹ sư mạng viết script tương tác với controller?

✅ Thường là Northbound API (dạng REST API) — kỹ sư mạng hoặc ứng dụng nghiệp vụ gọi Northbound API để yêu cầu controller thực hiện thay đổi; controller sau đó tự dùng Southbound API (NETCONF, RESTCONF, OpenFlow...) để đẩy cấu hình xuống thiết bị.

---

📝 Bài tập đánh giá

Câu 1: Trong mô hình controller-based networking, control plane được xử lý ở đâu?

• A. Vẫn phân tán trên từng thiết bị như mô hình truyền thống
• B. Tập trung tại controller, thiết bị chỉ còn thực hiện Data plane
• C. Chuyển hoàn toàn sang Management plane của thiết bị
• D. Không còn tồn tại trong mô hình controller-based

Câu 2: Southbound API trong kiến trúc controller-based dùng để làm gì?

• A. Kết nối controller với các ứng dụng quản lý ở lớp trên
• B. Kết nối controller với các thiết bị mạng vật lý bên dưới để đẩy cấu hình và thu thập trạng thái
• C. Kết nối hai controller với nhau trong mô hình đa controller
• D. Kết nối thiết bị mạng trực tiếp với ứng dụng, không qua controller

👉 Đáp án:

Câu 1: B — Đặc trưng cốt lõi của controller-based networking là tách Control plane ra khỏi từng thiết bị và tập trung tại controller; thiết bị vật lý chỉ còn giữ lại Data plane để forward dữ liệu theo chỉ dẫn từ controller.

Câu 2: B — Southbound API là kênh giao tiếp giữa controller và thiết bị mạng bên dưới (ví dụ NETCONF, RESTCONF, OpenFlow); Northbound API mới là kênh giữa controller và các ứng dụng ở lớp trên.

📚 Bài viết thuộc khóa học CCNA của VNExperts

🧭 Điều hướng