Niềm tin này nghe như số học: năm spoke, mỗi cái được định hình ở 5 Mbit/s, vậy hub chỉ mang tối đa 25 Mbit/s. Nửa đầu đúng và kết luận thì không. Chính sách theo từng tunnel được áp dụng một lần cho mỗi tunnel, không phải một lần cho mỗi hub, và uplink dùng chung mà cả năm tunnel đi qua không bao giờ xuất hiện trong phép tính đó. Tắc nghẽn trên uplink vẫn y nguyên như cũ.

Niềm tin này đến từ đâu

Sự nhầm lẫn dễ hiểu, vì thông tin nhóm NHRP cho phép một định nghĩa chính sách áp dụng cho cả một tập spoke. Điều đó đọc như một ngân sách chung trong tệp cấu hình. Ý nghĩa thực sự là mỗi spoke nhận được phiên bản riêng của định nghĩa đó.

Vậy 5 Mbit/s mỗi spoke là mức trần cho mỗi tunnel, và số mức trần bằng số tunnel.

Một phiên bản chính sách kiểm soát điều gì

Hướng dẫn của Cisco về QoS theo từng tunnel trong DMVPN trên IOS XE mô tả chính sách đầu ra của hub được chọn qua thông tin nhóm NHRP và áp dụng riêng cho từng spoke. Từ câu đó rút ra hai giới hạn, và cả hai đều bị bỏ qua. Tốc độ thuộc về một spoke chứ không phải một cái xô dùng chung, và tính năng này điều khiển lưu lượng từ hub đến spoke, không phải ngược lại.

Hãy lập kế hoạch hướng gửi của spoke một cách độc lập. Không có gì trong chính sách đầu ra của hub giới hạn những gì một chi nhánh tải lên.

Đặt giới hạn tổng ở nút cổ chai dùng chung

Phần tổng phải được định hình ở nơi nó thực sự cạnh tranh: trên giao diện vật lý mà mọi tunnel chia sẻ. Cisco ghi nhận một shaper class-default trên giao diện vật lý là chính sách vật lý đồng thời được hỗ trợ cho tính năng này, đây là một phát biểu hẹp hơn mọi phân cấp bạn có thể gõ. Hãy giả định chính sách vật lý thứ hai tùy ý bạn nghĩ ra không được hỗ trợ cho đến khi có người chứng minh ngược lại.

Sau đó quyết định điều gì xảy ra khi mọi spoke bận cùng lúc. Lưu lượng nào được chấp nhận, lớp nào được ưu tiên và hàng đợi nào giữ sự cạnh tranh. Mức trần mỗi spoke không trả lời câu nào trong số đó, vì mỗi spoke được xét riêng.

Khớp đơn vị định hình và kế toán chi phí phụ với việc bàn giao thực tế. Chi phí phụ của đóng gói mà bạn để ngoài phép tính tốc độ sẽ hiện ra như một liên kết bão hòa trước con số đã cấu hình.

Các bộ đếm nói dối theo một cách cụ thể

Hãy đọc bộ đếm ở lớp bạn đang định hình. Cùng một hướng dẫn Cisco cảnh báo rằng bộ đếm chính sách của giao diện chính có thể không chính xác trong cách bố trí này. Đó là lưu ý về bộ đếm, không phải bằng chứng rằng một lớp đang khớp hay đang loại bỏ. Hãy tách nó khỏi kết quả ứng dụng, thứ duy nhất người dùng trải nghiệm.

Sao chép một ví dụ traffic-shape cũ bên cạnh một bản đồ chính sách không liên quan không chứng minh rằng hai tốc độ kiểm soát cùng những gói tin.

Hãy kiểm tra phần tổng, không chỉ mức trần

Bắt đầu với một spoke bận và xác nhận nó đạt mức trần của mình. Sau đó cung cấp lưu lượng từ tất cả cùng lúc theo một kế hoạch đã được phê duyệt, và quan sát giao diện vật lý bên cạnh các con số theo từng tunnel. Nếu mỗi spoke ngồi ở mức trần của nó trong khi uplink kín và độ trễ tăng, chính sách theo spoke đang hoạt động đúng như thiết kế và ngân sách vẫn sai.

Cách khắc phục ở thời điểm đó là một quyết định về dung lượng hoặc chấp nhận. Việc chỉnh lại các con số theo spoke chỉ thay đổi chi nhánh nào phàn nàn trước.

Bài viết liên quan