Đánh dấu DSCP hay lời hứa QoS của nhà cung cấp? Cả hai đều không phải hợp đồng

Một thứ gì đó được đánh dấu, một hàng đợi được cấu hình, rồi ai đó hỏi thiết kế thực sự bảo đảm chất lượng nào. Câu trả lời trung thực là bạn đã mô tả hai nửa của một hợp đồng gặp nhau tại một ranh giới. Cho đến khi bạn có thể gọi tên lớp mà nhà cung cấp chấp nhận và cách xử lý mà họ áp dụng, cấu hình cục bộ chỉ là ý định, không phải lời hứa. Cả hai nửa đều quan trọng, và không nửa nào suy ra được từ nửa kia.

local match → queue and marking → provider classifier
  → provider treatment → destination

Nơi một đánh dấu đúng có thể chết lặng lẽ

Bắt đầu bằng việc ghi lại, cho từng khối lượng công việc, điều kiện khớp cục bộ, mọi đánh dấu xảy ra bên trong đường hầm, giá trị mà nhà cung cấp chấp nhận và lớp dịch vụ mà giá trị đó chọn. Bốn cột, và các lỗi thường sống giữa cột thứ hai và thứ ba.

Hành vi đánh dấu từ tiêu đề trong ra tiêu đề ngoài là vấn đề kinh điển. Một gói trong đường đi mã hóa hoặc đường hầm mang tiêu đề trong mà bộ phân loại của bạn thấy và tiêu đề ngoài mà thiết bị của nhà cung cấp thấy, và việc sao chép cái này sang cái kia là quyết định cấu hình, không phải thuộc tính tự động. Chỉ đánh dấu tiêu đề trong và nhà cung cấp sẽ phân loại tiêu đề ngoài, thường là mặc định, vì vậy một luồng được đánh dấu đúng có thể đến nhầm lớp mà không có một dòng cấu hình sai nào phía bạn.

Một lớp được đặt tên cục bộ cũng có thể trống vì điều kiện khớp của nó không bao giờ kích hoạt trên gói thật. Cổng dịch chuyển, ứng dụng dùng nhiều luồng, và một khớp trên cổng quen thuộc mà nhà sản xuất đã ngừng dùng hai bản phát hành trước tạo ra một hàng đợi có bộ đếm bằng không và một chính sách trông hoàn hảo trong cấu hình đang chạy.

Hãy quyết định rõ ràng nơi nào đánh dấu được tin cậy. Nâng mọi thứ chia sẻ một đường hầm cũng nâng các lần truyền khối cùng với các cuộc gọi, và một nhà cung cấp chấp nhận đánh dấu của bạn mà không kiểm chứng là đang trao cho bạn cách tự làm hại mình. Nếu hợp đồng cho phép cổng đánh dấu lại khi bàn giao, hãy nói rõ bằng văn bản, vì đó chính là điểm mà giả định của hai nhóm thường khác nhau.

Bộ lập lịch thực sự chia cái gì

Chính sách cục bộ có ngữ nghĩa riêng, và từ gây hiểu nhầm nhiều nhất là “remaining”. Trên các nền tảng mà hướng dẫn lập lịch IOS XE mô tả, bandwidth remaining percent đặt một trọng số vượt mức, không phải một bước trong chuỗi mà mỗi lớp lấy một phần từ những gì lớp trước để lại. Các phần trăm chưa được gán được phân bổ cho các hàng đợi đủ điều kiện chưa cấu hình thay vì được giữ riêng cho lớp cuối cùng trong tệp.

Sự khác biệt đó quan trọng vì mô hình tư duy tuần tự tạo ra những dự đoán không bao giờ khớp với bộ đếm. Các kỹ sư sắp xếp lại các lớp để thay đổi kết quả, không thấy khác biệt và kết luận nền tảng bị hỏng, trong khi cấu hình chưa bao giờ có nghĩa như họ giả định.

Bộ định hình cha là bất ngờ phổ biến khác. Định hình một hàng đợi được kiểm soát xuống tốc độ dịch vụ khả dụng thường là có chủ ý, vì nó chuyển điểm tắc nghẽn sang thiết bị mà bạn quản trị thay vì sang một hàng đợi thượng nguồn mà bạn không quản trị. Bỏ bộ định hình vì định hình thêm độ trễ có thể di chuyển mất mát thay vì loại bỏ nó, và việc hạch toán chi phí phụ hoặc bộ cảnh sát của nhà cung cấp có thể làm tốc độ hiệu dụng thấp hơn giao diện gợi ý.

Bộ đếm cho biết nửa nào đã thất bại

So sánh bốn con số theo hướng bị ảnh hưởng: những gì được đề nghị, những gì lớp khớp, những gì vào hàng đợi hoặc bị bỏ, và những gì dịch vụ thực sự giao. Giữ mô tả khối lượng công việc và phiên bản chính sách bên cạnh quan sát, vì ảnh chụp màn hình bộ đếm mà không có chúng thì không thể tái tạo.

Các nhánh là những vấn đề khác nhau với những chủ sở hữu khác nhau. Một lớp cục bộ không khớp gì là lỗi phân loại phía bạn. Một lớp khớp, vào hàng đợi và bỏ trong khi nhà cung cấp báo giao sạch chỉ vào bộ lập lịch hoặc bộ định hình của chính bạn. Một lớp trông đúng cục bộ trong khi mất mát xuất hiện bên kia bàn giao chỉ vào ánh xạ của nhà mạng và ranh giới đo được trong hợp đồng. Không cái nào trong ba cái được sửa bằng cách chỉnh cái khác, vì vậy các con số phải được thu thập cùng nhau.

RFC 2475 đóng khung phân loại và điều kiện hóa như công việc thực hiện bên trong các miền quản trị, và chính vì thế một đánh dấu không thể đặt trước hàng đợi từ đầu đến cuối. Hướng dẫn lập lịch IOS XE là tài liệu tham chiếu cho hành vi trọng số vượt mức mô tả ở trên, và các so sánh nền tảng của nó đáng đọc trước khi chuyển một tốc độ tính toán giữa các mô hình.

Viết hợp đồng ở một chỗ

Đặt khớp cục bộ, ranh giới tin cậy, lớp của nhà cung cấp và mức dịch vụ đo được vào một tài liệu mà cả hai bên ký. Khi đó một thay đổi phần trăm có bối cảnh, và một khiếu nại chất lượng có chủ sở hữu.

Thay đổi một phần trăm cục bộ không thể sửa chữa bảo đảm của hàng đợi khác, và không sơ đồ đánh dấu nào sống sót qua một ánh xạ mà nhà cung cấp không tôn trọng. So sánh hai nửa, gọi tên ranh giới, và chỉ khi đó mới trích dẫn một con số.