luận văn môn báo hiệu và điểu khiển kết nối đề tài tìm hiểu về QOS

Chương này bắt đầu với một số khái niệm xếp hàng bên trong các router Cisco, trong đó có sự phân biệt giữa hàng đợi cứng và hàng đợi mềm, và nơi hàng đợi mềm có thể được sử dụng.. Bên tr

- 0 0 0 -

MÔN

BÁO HIỆU VÀ ĐIỀU KHIỂN KẾT NỐI

ĐỀ TÀI: TÌM HIỂU VỀ QOS

Nguyễn Văn Tuấn Nguyễn Hoàng Sơn Vương Thị Hằng

HÀ NỘI - THÁNG 10/2014

Mục lục:

Phần 1: Quản lý tắc nghẽn 4

1.1 Khái niệm hàng đợi router Cisco 5

1.1.1 Hàng đợi cứng và hàng đợi mềm 8

1.1.2 Hàng đợi trong giao diện Versus Subinterfaces và Virtual Circuits (VCs) 13

1.1.3 Tóm tắt các khái niệm về hàng đợi 15

1.2 Các khái niệm cơ chế lập lịch: FIFO, PQ, CQ, và MDRR 16

1.2.1 Hàng đợi FIFO (FIFO Queuing) 16

1.2.2 Hàng đợi ưu tiên (Priority Queuing) 18

1.2.3 Hàng đợi tùy biến (Custom Queuing) 19

1.3 Khái niệm và cấu hình: WFQ, CBWFQ, và LLQ 20

1.3.1 Hàng đợi cân bằng trọng số - Weighted Fair Queuing (WFQ) 20

1.3.1.1 Phân loại WFQ (WFQ Classification) 21

1.3.1.2 Lập lịch WFQ : Tác động thực 22

1.3.1.3 Lập lịch WFQ: Tiến trình 22

1.3.1.4 WFQ: Chính sách bỏ gói, số lượng và chiều dài hàng đợi 24

1.3.1.6 Tóm tắt WFQ 26

1.3.2 Hàng đợi cân bằng trọng số theo lớp - Class-Based WFQ (CBWFQ) 27

1.3.2.1 Cấu hình CBWFQ 29

1.3.2.2 Tóm tắt CBWFQ 39

1.3.3 Low Latency Queuing (LLQ) 40

1.3.3.1 Cấu hình LLQ 41

1.3.3.2 LLQ với nhiều hơn một hàng đợi ưu tiên 45

1.3.3.3 LLQ và lệnh bandwidth remaining percent 46

1.3.4 So sánh WFQ, CBWFQ, và LLQ 48

Phần 2: Traffic Policing and Shaping 50

2.1 Khái niệm Traffic Policing và Traffic Shaping: 51

2.1.1 Shaping và Policing sử dụng khi nào và ở đâu 51

2.1.2 Policing sử dụng khi nào và ở đâu 52

2.1.3 Traffic Shaping sử dụng khi nào và ở đâu 54

2.2 Shaping hoạt động như thế nào 57

2.2.1 Traffic Shaping with No Excess Burst 61

2.2.2 Traffic Shaping with Excess Burst 62

2.2.3 Traffic-Shaping thích ứng 63

2.2.4 Shape sử dụng ở đâu: Interfaces, Subinterfaces và VCs 65

2.2.5 Queuing và Traffic Shaping 67

2.3 Policing hoạt động như thế nào? 70

2.3.1 CB Policing: Single-Rate, Two-Color (1 Bucket) 71

2.3.2 CB Policing: Dual Token Bucket (Single-Rate) 72

2.3.3 CB Policing: Dual Token Bucket (Dual Rate) 73

2.3.4 Policing but Not Discarding 75

2.4 Cấu hình Shaping 76

2.4.1 Cấu hình Class-Based Shaping 76

2.4.2 Thiết lập Bc để tính Tc 79

2.4.3 Tuning Shaping for Voice Using LLQ and a Small Tc 81

2.4.4 Miscellaneous CB Shaping Configuration: Adaptive Shaping 85

2.4.5 Cấu hình Miscellaneous CB Shaping: Phần trăm Shaping 86

2.5 Cấu hình Policing 87

2.5.1 Cấu hình Class Based Policing 87

2.5.2 Cấu hình Dual-Rate Policing 93

2.5.3 Multi-action Policing 93

2.5.4 Policing by Percentage 94

2.5.5 CB Policing mặc đinh Bc và Be 95

2.5.6 Tóm tắt cấu hình CB Policing 95

Phần 3: Tránh tắc nghẽn bằng chính sách loại bỏ gói 104

3.1 Tổng quan về tránh tắc nghẽn 105

3.1.1 Phản ứng của TCP và UDP với việc mất gói tin 105

3.1.2 Các khái niệm về “Tail Drop, Global Synchronization, and TCP Starvation” 108

3.2 Loại bỏ gói sớm (RED) 110

3.3 Weighted RED (WRED) 113

3.3.1 Làm thế nào để WRED biết được trọng số của gói tin 114

3.3.2 WRED and Queuing 117

3.3.3 Cấu hình WRED 119

3.3.4 Tóm tắt WRED 131

3.4 Sự thông báo tắc nghẽn một cách rõ ràng (Explicit Congestion Notification-ECN) 131

3.4.1 Các khái niệm về ECN 131

3.4.2 Cấu hình ECN 135

Phần 1: Quản lý tắc nghẽn

Các nội dung sẽ được đề cập trong phần này:

 Liệt kê và giải thích các thuật toán xếp hàng khác nhau

 Giải thích thành phần của hệ thống hàng đợi cứng và hàng đợi mềm trong router Cisco và sự ảnh hướng của chúng đến việc điều hướng và tắc nghẽn

 Mô tả lợi ích và hạn chế của việc sử dụng WFQ để thực hiện QoS

 Giải thích mục đích và các tính năng của Class-Based WFQ (CBWFQ)

 Giải thích mục đích và tính năng của Low Latency Queuing (LLQ)

 Xác định các câu lệnh trong Cisco IOS yêu cầu để cấu hình và giám sát LLQ

Hầu hết mọi người hiểu các khái niệm cơ bản của hàng đợi, bởi vì hầu hết chúng ta đểu đã từng xếp hàng mỗi ngày: xếp hàng để trả tiền cho cửa hàng tạp hóa, xếp hàng đợi đợi một nhân viên giao dịch ngân hàng, xếp hàng để vào một chuyến đi tại một công viên giải trí … Vì vậy, hầu hết các khái niệm về xếp hàng bên trong chương này đều trực quan và dễ hiểu

Chương này bắt đầu với một số khái niệm xếp hàng bên trong các router Cisco, trong

đó có sự phân biệt giữa hàng đợi cứng và hàng đợi mềm, và nơi hàng đợi mềm có thể được sử dụng Sau đó, phần thứ hai và thứ ba trong ba phần chính trong chương này bao gồm chi tiết cụ thể về một số cơ chế xếp hàng có sẵn bên trong các router Cisco

Ghi chú:

Tail drop: “Hủy bỏ gói cuối hàng đợi”

Jitter: Độ biến thiên trễ

Loss: Việc mất gói

Traffic shaping: Định hướng lưu lượng, điều hòa lưu lượng

FIFO: First in first out

Hàng đợi ảnh hướng đến tất cả 4 đặc điểm QoS là băng thông trực tiếp, trễ, độ biến thiên trễ và mất gói (directlybandwidth, delay, jitter, and packet loss) Nhiều người khi nghe thuật ngữ “QoS” sẽ nghĩ ngay đến hàng đợi tuy nhiên QoS bao gồm nhiều khái niệm và tính năng hơn là chỉ mình hàng đợi Hàng đợi chắc chắn là công

cụ QoS thường được triển khai và quan trọng nhất

Chương này bắt đầu bằng việc giải thích các khái niệm cốt lõi về hàng đợi Sau đó, hầu hết các kỹ thuật hàng đợi được kiểm chứng, bao gồm các khái niệm bổ sung cụ thể với từng kỹ thuật , cấu hình , giám sát và xử lý sự cố

1.1 Khái niệm hàng đợi router Cisco

Hầu hết mọi người đã hiểu nhiều khái niệm liên quan đến việc xếp hàng Đầu tiên, phần này sẽ giải thích những điều cơ bản, định nghĩa một vài thuật ngữ Sau đó một vài bản IOS chi tiết cụ thể sẽ được đưa ra để kiểm chứng

IOS lưu trữ các gói tin trong bộ nhớ khi xử lý các gói tin Khi các bộ định tuyến đã

xử lý tất cả công việc yêu cầu ngoại trừ việc gửi các gói tin qua đường ra, nếu giao diện (interface) đường ra (outgoing) hiện đang bận, bộ định tuyến chỉ cần giữ các gói tin trong bộ nhớ đợi cho đến khi giao diện được thông suôt Để quản lý các gói tin chờ

để được đi qua giao diện, IOS tạo một hàng đợi Một hàng đợi chỉ tổ chức các gói tin đang đợi để thoát ra khỏi giao diện, nó chính là hàng loạt các con trỏ được trỏ tới bộ nhớ đệm nơi lưu trữ tạm thời các gói tin đang đợi để thoát ra khỏi giao diện

Kiểu hàng đợi được sử dụng nhiều nhất là hàng đợi đơn, với cơ chế lập lịch first-in, first-out (FIFO) Điều đó có nghĩa là gì ? Khi IOS quyết định đưa gói tin kế tiếp từ hàng đợi, những gói tin vẫn còn trong hàng đợi, nó sẽ lấy gói tin đến sớm hơn các gói tin khác trong hàng đợi Hình 1-1 cho thấy một bộ định tuyến với giao diện được sử dụng hàng đợi FIFO đơn

Hình 1-1 Hàng đợi FIFO đơn

Mặc dù một hàng đợi đơn FIFO dường như không cung cấp tất cả tính năng QoS nhưng nó thực sự ảnh hưởng đến việc bỏ gói (drop), trễ (delay) và biến thiên trễ (jitter) Vì chỉ có một hàng đợi, bộ định tuyến không cần phải phân loại lưu lượng để đặt nó vào trong các hàng đợi khác nhau.Vì chỉ có một hàng đợi, bộ định tuyến không cần phải lo lắng về việc làm thế nào để quyết định lấy gói tin tiếp theo từ hàng đợi nào, chỉ có một lựa chọn Và vì chỉ có một hàng đợi logic FIFO, bộ định tuyến không cần sắp xếp lại gói tin bên trong hàng đợi

Tuy nhiên, kích thước của hàng đợi ra phụ thuộc vào delay, jitter, và loss Vì hàng đợi

có kích thước hữu hạn nên nó có thể đầy Nếu nó bị lấp đầy và các gói tin khác cần được đưa vào hàng đợi thì tail drop sẽ là nguyên nhân khiến gói tin bị loại bỏ Một giải pháp được đưa ra là tăng chiều dài hàng đợi Tuy nhiên với việc tăng chiều dài hàng đợi sẽ đồng nghĩa với việc tăng độ trễ trung bình vì gói tin có thể đứng đợi sau một số lượng lớn các gói tin khác Trong hầu hết trường hợp khi độ trễ trung bình tăng, độ biến thiên trễ trung bình cũng tăng theo Danh sách sau đây tóm tắt các khái niệm cơ bản liên quan đến chiều dài hàng đợi:

 Với một hàng đợi dài hơn, tail drop sẽ xảy ra ít hơn so với hàng đợi ngắn hơn, nhưng độ trễ trung bình tăng, với độ biến thiên trễ trung binh thường là tăng như vậy

 Với một hàng đợi ngắn hơn, tail drop tăng so với hàng đợi dài hơn, nhưng độ trễ trung bình giảm, với độ biến thiên trễ trung bình thường giảm theo

Để đánh giá đúng nhất khái niệm hàng đợi, ta cần phải xem xét hệ thống xếp hàng có

ít nhất 2 hàng đợi Hãy xem xét hình 1-2 với minh họa 2 hàng đợi FIFO đầu ra:

Hình 1-2 Hàng đợi kép đầu ra FIFO

Hình 1-2 minh họa cho câu hỏi được trả lời bởi các kĩ thuật xếp hàng Bước 1, bước phân loại, hoạt động như kĩ thuật phân loại và đánh dấu, ngoại trừ kết quả của việc đặt một gói tin trong hàng đợi , như trái ngược với đánh dấu một gói tin Vì thế ở bước 1, tiêu đề gói tin được kiểm tra tùy thuộc vào các giá trị phù hợp, các gói tin được đặt vào hàng đợi thích hợp Trước khi đặt các gói tin trong hàng đợi, các bộ định tuyến phải đảm bảo rằng không gian hàng đợi có sẵn , như thể hiện ở bước 2 trong hình 1-2 Nếu không có không gian có sẵn , các gói tin sẽ bị loại bỏ Bên trong mỗi hàng đợi, các gói dữ liệu có thể được sắp xếp lại ( bước 3): Tuy nhiên , trong ví dụ này , mỗi hàng đợi đều sử dụng FIFO logic , vì vậy các gói tin sẽ không bao giờ được sắp xếp lại trong hàng đợi Cuối cùng, hệ thống hàng đợi phải lựa chọn lấy những gói tiếp theo để truyền từ một trong hai hàng đợi 1 hoặc 2 (Bước 4) Hệ thống lập lịch đưa ra quyết định ở bước 4

Mặc dù phần phân loại của mỗi kĩ thuật xếp hàng là tương đối rõ ràng, tuy nhiên hãy xem xét hai điểm sau khi nghĩ về việc phân loại bởi một kỹ thuật xếp hàng Đầu tiên, với một chiến lược QoS với mục đích phân loại và đánh dấu xuất hiện tại gần biên lối vào của mạng, các kĩ thuật xếp hàng có thể sắp xếp các gói tin đã được

đánh dấu Vì vậy, công cụ xếp hàng có thể phân loại các dựa trên các trường được đánh dấu Thứ hai, đối với từng loại lưu lượng truy cập mà ta muốn cung cấp xử lý xếp hàng khác nhau, ta cần có một hàng đợi khác nhau Ví dụ, ta có thể muốn phân loại lưu lượng thành sáu lớp cho xếp hàng , do đó, mỗi lớp có thể được xử lý khác nhau trong các hàng đợi khác nhau Nếu kĩ thuật xếp hàng chỉ hỗ trợ bốn hàng đợi khác nhau, ta có thể cần phải xem xét một kĩ thuật xếp hàng khác để hỗ trợ chính sách QoS

Bên trong mỗi hàng đợi , các phương pháp xếp hàng sử dụng hàng đợi FIFO Một điều thú vị cho hàng đợi xảy ra sau khi các gói dữ liệu đã được sắp xếp, khi router quyết định hàng đợi nào sẽ lấy những gói tin tiếp theo Lập lịch xếp hàng mô tả các quá trình của thiết bị, trong trường hợp này một bộ định tuyến, lựa chọn mà hàng đợi sẽ phục vụ tiếp theo Quá trình này còn được gọi là một thuật toán dịch vụ hoặc một thuật toán dịch vụ hàng đợi Các tiến trình lập lịch có quyền sử dụng lượng băng thông hoặc một tỷ lệ phần trăm băng thông đường truyền cho một hàng đợi cụ thể Lập lịch có thể luôn phục vụ một hàng đợi đầu tiên, có nghĩa là các gói tin trong hàng đợi này sẽ có trễ và jitter rất thấp

Một dẫn giải cuối cùng về các khái niệm cốt lõi của hàng đợi : Kích thước của mỗi gói tin không ảnh hưởng đến độ dài của hàng đợi hoặc có bao nhiêu gói tin nó có thể giữ Một hàng đợi có độ dài 10 giữ mười gói 1500 byte dễ dàng như nó giữ mười gói 64 byte Hàng đợi thực sự không giữ các gói tin vào chúng, thay vào đó nó chỉ giữ con trỏ đến các gói tin và nội dung được tổ chức tại vùng đệm

Bảng 1-2 tóm tắt các khái niệm quan trọng của hàng đợi Bảng này dùng để so sánh các kĩ thuật xếp hàng được giới thiệu trong chương

Bảng 1-1 Các khái niệm chính khi so sánh các kỹ thuật xếp hàng

Tính năng Định nghĩa

Đặc điểm QoS

bị ảnh hưởng

Phân loại Khả năng để kiểm soát các gói dữ liệu để xác định

hàng đợi các gói tin nên được đặt Nhiều tùy chọn có sẵn

None

Chính sách

bỏ gói

Khi hàng đợi đã được xác định, chính sách bỏ gói xác

định các quy tắc mà các bộ định tuyến lựa chọn để bỏ các gói tin Tail drop, modified tail drop, WRED (Weighted Random Early Detect), and ECN (Explicit Congestion Notification) là những tùy chọn chính

Bảng 1-1 Các khái niệm chính khi so sánh các kỹ thuật xếp hàng

Băng thông, trễ, jitter và mất gói

Số lượng tối

đa hàng đợi

Số lượng tối đa của hàng đợi khác nhau là các kỹ thuật

hỗ trợ việc xếp hàng, là số lượng tối đa của phân loại lưu lượng truy cập có thể được điểu khiển bằng phương pháp xếp hàng khác nhau

ra ngoài giao diện Thay vào đó, các bộ định tuyến di chuyển các gói tin từ giao diện hàng đợi mềm đến một hàng đợi FIFO nhỏ trên mỗi giao diện Cisco gọi điều này là phân tán, hàng đợi cuối cùng này hoặc là Transmit Queue (TX Queue) hoặc Transmit Ring (TX Ring), tùy thuộc vào mô hình của bộ định tuyến Những hàng đợi FIFO này gọi là hàng đợi cứng

Mục đích của hàng đợi cứng là để điều chỉnh việc sử dụng liên kết đến 100 phần trăm khi các gói tin đang đợi để thoát khỏi một giao diện Hàng đợi cứng giữ gói tin gửi đi để giao diện không phải dựa vào bộ vi xử lý trong các bộ định tuyến để bắt đầu gửi các gói tin tới Hàng đợi cứng có thể được truy cập trực tiếp bởi các mạch tích hợp ứng dụng riêng biệt (ASICs) kết hợp với một giao diện, vì vậy ngay cả khi bộ vi

xử lý đang bận, giao diện có thể bắt đầu gửi các gói tin tiếp theo mà không cần chờ đợi việc xử lý tại CPU Bởi vì các nguồn tài nguyên hạn chế nhất trong một router thường là băng thông trên các giao diện, đặc biệt là giao diện WAN, nên bộ định tuyến cần gửi các gói tin tiếp theo ngay lập tức khi giao diện kết thúc gửi các gói tin cuối cùng Hàng đợi cứng cung cấp một thành phần quan trọng để đạt được mục tiêu

đó

Tuy nhiên, sự tồn tại của hàng đợi phần cứng làm ảnh hưởng đến xếp hàng đến mức độ nào Hình 1-3 mô tả hàng đợi cứng, cùng với một hàng đợi mềm FIFO đơn

Hình 1-3 Hàng đợi mềm FIFO đơn với một hàng đợi cứng đơn

Hai ví dụ khác nhau được trình bày trong Hình 1-3 Trong phần đầu của hình, kịch bản bắt đầu với không có gói tin trong hàng đợi mềm và không có các gói tin trong hàng đợi cứng Sau đó, bốn gói tin đến Với một hàng đợi cứng có chỗ cho bốn gói, tất cả bốn gói được đặt vào hàng đợi phần cứng

Trong ví dụ thứ hai, bất kỳ gói dữ liệu mới đến sẽ được đặt vào hàng đợi mềm Giả sử rằng hàng đợi mềm và hàng đợi cứng rỗng trước khi bảy gói thể hiện trong hình đến, bốn gói đầu tiên sẽ được đưa vào hàng đợi cứng và ba gói còn lại trong hàng đợi mềm Vì vậy, bất kỳ gói dữ liệu mới nào đến sẽ được đặt ở cuối hàng đợi mềm Tất cả các kỹ thuật xếp hàng trong IOS tạo và quản lý giao diện hàng đợi mềm, chứ không phải giao diện hàng đợi cứng Mỗi giao diện sử dụng một TX Queue (hoặc TX Ring), và hàng đợi cứng là một hàng đợi FIFO, không bị ảnh hưởng bởi cấu hình hàng đợi trên giao diện

Trong hình 1- 3 , các gói dữ liệu được gửi theo thứ tự mà chúng đã được gửi nếu hàng đợi cứng không tồn tại Tuy nhiên trong một số trường hợp hàng đợi cứng ảnh hương lên kết quả của việc lập lịch của hàng đợi mềm Ví dụ , hãy xem xét hình 1-4 , nơi xếp hàng được cấu hình với hai hàng đợi phần mềm Trong kịch bản này, sáu gói tin đến nơi, đánh số theo thứ tự mà chúng đến Hàng đợi mềm cấu hình chỉ rõ rằng hai gói đầu tiên (1 và 2) nên được đặt vào hàng đợi 2 , và bốn gói tiếp theo (đánh số từ

3 đến 6) nên được đặt vào hàng đợi 1

Hình 1-4 Khả năng tác động của hàng đợi cứng lên hàng đợi mềm 1

Nhiều người cho rằng các bộ định tuyến hoạt động như thể hiện trong phần trên của hình 1-4, với việc lập lịch xác định thứ tự mà các gói tin thoát khỏi giao diện Trong thực tế, IOS hoạt động như thể hiện trong nửa dưới của hình 1-4 Trong nửa đầu của hình, nếu tất cả sáu gói tin đã đến ngay lập tức, tất cả sáu gói sẽ được đặt vào hàng đợi mềm thích hợp Nếu lịch trình của kỹ thuật xếp hàng luôn phục vụ gói dữ liệu từ hàng đợi 1, và chỉ phục vụ hàng đợi 2 nếu hàng đợi 1 rỗng , thứ tự các gói dữ liệu đi sẽ khác với thứ tự đến.Trong thực tế, các gói dữ liệu từ 3 đến 6 sẽ thoát ra theo thứ tự, và sau đó các gói 1 và 2 sẽ được gửi đi Cuối cùng, thứ tự sẽ chỉ phụ thuộc vào

sự logic của tiến trình lập lịch của kỹ thuật xếp hàng

Tuy nhiên trong ví dụ này các gói dữ liệu sẽ thực sự thoát khỏi giao diện theo thứ tự mà các gói tin đã nhận được vì sự tồn tại của hàng đợi cứng Như đã đề cập trước đó, khi các bộ định tuyến xác định các giao diện đầu ra cho một gói tin, nó sẽ kiểm tra hàng đợi cứng cho giao diện đó Nếu không gian có sẵn, các gói dữ liệu được đặt trong hàng đợi phần cứng, và không có hàng đợi đầu ra được thực hiện cho gói tin

đó Trong ví dụ này , bởi vì kịch bản giả định rằng không có các gói khác đang đợi để thoát khỏi S0/0 giao diện R1 trước khi sáu gói tin đến , hai gói đầu tiên được đặt trong hàng đợi phần cứng Khi gói tin thứ 3 đến, hàng đợi cứng S0/0 đầy, vì vậy các gói từ 3 đến 6 được đặt vào trong một giao diện hàng đợi mềm, dựa trên cấu hình hàng đợi cho giao diện S0/0 của R1 Việc phân loại xếp hàng logic đặt gói 3 đến 6 vào hàng đợi 1

Các bộ định tuyến lấy các gói theo thứ tự từ TX Queue và di chuyển các gói tin theo thứ tự 3, 4, 5 và 6 từ hàng đợi 1 vào hàng đợi phần cứng Thực tế trình tự gói tin rời khỏi S0 giống như khi chúng đến

IOS tự động cố gắng để giảm thiểu tác động của hàng đợi cứng với các kỹ thuật hàng đợi IOS IOS duy trì mục tiêu ban đầu là luôn có một gói tin trong hàng đợi cứng, sẵn sàng cho giao diện gửi ngay lập tức khi nó hoàn tất việc gửi các gói tin trước đó Khi bất kỳ kỹ thuật hàng đợi mềm được kích hoạt trên một giao diện, những bản IOS thấp thường giảm kích thước của hàng đợi cứng đến một giá trị nhỏ, thường chiều dài là 2 Giá trị càng nhỏ thì tác động của TX Queue lên các phương pháp xếp hàng càng nhỏ

Ví dụ 1-1 liệt kê một số lệnh cho phép ta kiểm tra kích thước của hàng đợi cứng, và thay đổi kích thước ( Hãy ghi nhớ những cái tên khác cho hàng đợi cứng là

TX Ring và TX Queue )

VD 1-1 Chiều dài TX Queue: Tìm kiếm và thay đổi chiều dài

Dùng lệnh “tx-ring-limit 5” trong mod interface

Dùng lệnh show controllers serial 0/0 để hiển thị danh sách kích thước của

TX Queue hoặc TX Ring Trong phần đánh dấu đỏ, cụm từ " tx_limited = 1 (2) " có

nghĩa là TX Ring (Hàng đợi cứng) nắm giữ 2 gói và 1 là chiều dài tự động được giới

hạn

Ở hình thứ 2 chiều dài của TX ring được định nghĩa một cách rõ ràng với lệnh

tx-ring-limit 5 Dùng lại lệnh show controllers serial 0/0, ta thấy " tx_limited = 1

(5) " có nghĩa chiều dài của TX ring là 5

Danh sách sau đây tóm tắt những điểm chính về hàng đợi cứng liên quan đến ảnh

hưởng của các hàng đợi mềm:

 Hàng đợi cứng luôn thực hiện việc lập lịch FIFO và không thể thay đổi

 Hàng đợi cứng sử dụng một hàng đợi duy nhất trên mỗi giao diện

 IOS rút ngắn giao diện hàng đợi cứng tự động khi một hàng đợi mềm được cấu

hình

 Chiều dài hàng đợi cứng có thể được cấu hình các giá trị khác nhau

1.1.2 Hàng đợi trong giao diện Versus Subinterfaces và Virtual

Circuits (VCs)

Kỹ thuật xếp hàng trên IOS tạo và quản lý hàng đợi mềm kết hợp với một giao diện và sau đó các gói tin được đưa vào hàng đợi cứng liên kết với giao diện đó IOS cũng hỗ trợ xếp hàng trên subinterface của Frame Relay và từng FramRelay VCs (ATM VCs) khi điều hòa lưu lượng (traffic shaping) được kích hoạt Hàng đợi shaping queue được tạo ra bởi tính năng traffic-shaping, hướng gói tin vào hàng đợi đầu ra giao diện sau đó đi vào hàng đợi cứng Cũng giống như các hàng đợi mềm, hàng đợi shaping queue và hàng đợi trên mỗi VC của ATM có thể được quản lý bằng các kỹ thuật xếp hàng IOS

Sự tương tác giữa hàng đợi shaping queue liên kết với một subinterface hoặc

VC, và hàng đợi mềm kết hợp với một giao diện vật lý là không rõ ràng Vì vậy, trước khi chuyển sang các kỹ thuật hàng đợi khác nhau, hãy xem xét các trường hợp có thể xảy ra trên subinterface, VCs và giao diện vật lý để kích hoạt hàng đợi trong một bộ định tuyến một cách tối ưu nhất

Hình 1-5 mô tả sự tương tác giữa các loại hàng đợi R1 có nhiều mạch ảo cố định Frame Relay (PVC) cùng thoát khỏi S0/0 giao diện vật lý của nó Con số này cho thấy hàng đợi kết hợp với hai PVC, một hàng đợi mềm và một hàng đợi cứng cho giao diện vật lý

Hình 1-5 Hàng đợi Shaping Queues, hàng đợi mềm và hàng đợi cứng

Trong ví dụ này, mỗi subinterface sử dụng một hàng đợi shaping queue FIFO duy nhất; một hàng đợi mềm duy nhất được liên kết với giao diện vật lý Thoạt nhìn

có vẻ đơn giản: một gói tin đến, quyết định chuyển tiếp và thoát tại subinterface S0/0.1 Nó được đặt vào trong hàng đợi shaping queue subinterface 0/0.1 và sau đó vào hàng đợi mềm giao diện vật lý tiếp đến là vào hàng đợi cứng Cuối cùng nó thoát

ra khỏi giao diện

Trong một số trường hợp, các gói dữ liệu được chuyển trực tiếp từ hàng đợi shaping queue sang hàng đợi cứng Các gói tin thậm chí còn không được đặt vào trong hàng đợi mềm nếu hàng đợi cứng chưa đầy! Nếu không có tắc nghẽn xảy ra trên giao diện, các gói tin sẽ không đi vào hàng đợi cứng Nếu không có tắc nghẽn xảy ra trong hàng đợi cứng, các gói tin sẽ không đi vào hàng đợi mềm và các kỹ thuật xếp hàng kích hoạt trên giao diện không ảnh hưởng đến các gói tin khi rời khỏi giao diện

Trong một số trường hợp, IOS không đặt các gói tin vào trong hàng đợi shaping queue khi chúng đến, nhưng thay vào đó các gói tin được đặt vào hàng đợi mềm hoặc TX Queue Khi các tính năng shaping biết rằng một gói tin mới đến không vượt quá tốc độ cho phép thì không có cần thiết phải làm chậm các gói tin Trong trường hợp đó, một kỹ thuật xếp hàng sử dụng để quản lý hàng đợi shaping queue cũng sẽ không ảnh hướng lên gói cụ thể

Traffic shaping có thể gây ra việc các gói tin được đưa vào hàng đợi shaping queue trên subinterface ngay cả khi không có tắc nghẽn trên các giao diện vật lý Traffic shaping được kích hoạt trên một subinterface hoặc VC sẽ làm chậm dòng chảy của lưu lượng rời khỏi subinterface hoặc VC Trong thực tế, traffic shaping trên subinterface tạo ra tắc nghẽn giữa các hàng đợi shaping queue và hàng đợi mềm giao diện vật lý Trên một giao diện vật lý, các gói tin chỉ có thể rời khỏi giao diện với tốc

độ clock rate đã được cấu hình sẵn; tương tự các gói tin chỉ có thể rời khỏi hàng đợi shaping queue với tốc độ của traffic-shaping

Ví dụ, VC kết hợp với subinterface S0/0.1 sử dụng một tốc độ thông tin cam kết (CIR) 64 kbps và S0/0 sử dụng một mạch T/1 Nếu không có traffic shaping, lưu lượng lớn hơn 64 kbps có thể được gửi cho PVC và các yếu tố duy nhất hạn chế sẽ là tốc độ truy cập (T/1) Các mạng Frame Relay có thể loại bỏ một số các lưu lượng vì các bộ định tuyến có thể gửi nhiều hơn (lên đến 1,5 Mbps) trên VC, vượt quá lưu lượng cam kết (64- kbps CIR ) Vì vậy, traffic shaping có thể được kích hoạt trên subinterface hoặc VC, hạn chế tốc độ chung cho PVC này đến 64 kbps, để tránh mất khung bên trong mạng Frame Relay Nếu lưu lượng trên subinterface vượt quá 64 kbps trong một khoảng thời gian, traffic shaping làm chậm việc gửi lưu lượng dư thừa bằng cách đặt các gói tin vào hàng đợi shaping queue liên kết với các subinterface và điều chỉnh tốc độ trong hàng đợi shaping queue bằng shaped rate

Hình 1-6 cho thấy một phiên bản cập nhật của hình 1-5 ; cái này thì PVC hiện đang vượt quá tỷ lệ hình , và PVC khác không được vượt quá tỷ lệ hình Trong hình 1-6, các gói tin đến và được chuyển ra khỏi một trong hai subinterface Lưu lượng cho subinterface 0/0.1 vượt quá tốc độ shaping và các gói cho subinterface 0/0.2 thì không Vì vậy, IOS đặt một số gói vào hàng đợi shaping queue cho subinterface 0/0.1, bởi vì traffic shaping sẽ làm chậm gói tin bởi hàng đợi Trên subinterface 0/0.2 IOS không xếp hàng các gói tin vì tốc độ shaping không vượt quá mức cho phép

Hình 1-6 Shaping kích hoạt trên một VC và không kích hoạt trên VC còn lại

1.1.3 Tóm tắt các khái niệm về hàng đợi

Các kỹ thuật xếp hàng sẽ được so sánh dựa trên sáu điểm chung được liệt kê

trong phần này Hình 1-7 chỉ ra những điểm này trong cùng một chuỗi cho mỗi điểm được liệt kê trong phần tiếp theo trên mỗi kỹ thuật xếp hàng

Hình 1-7 Sáu điểm so sánh cho kỹ thuật hàng đợi trong IOS

Việc lập lịch (Scheduling) được sự chú ý nhất khi các kỹ sư mạng chọn kỹ thuật xếp hàng nào để sử dụng cho một ứng dụng cụ thể Tuy nhiên, các thành phần khác trong quá trình xếp hàng cũng quan trọng không kém Ví dụ, nếu phần phân loại (classification) của một kỹ thuật xếp hàng có thể không phân loại lưu lượng theo quy định của chính sách QoS cho mạng thì hoặc là chính sách phải được thay đổi hoặc kỹ thuật khác phải được sử dụng Một trong những ví dụ là PQ và CQ rằng không thể tận dụng lợi thế trực tiếp từ network-based application recognition ( NBAR ) nhưng CBWFQ và LLQ có thể Ngoài ra, một số kỹ thuật xếp hàng cho phép tạo chính sách

bỏ gói cho mỗi hàng đợi trở nên đặc biệt quan trọng khi thoại và video cạnh tranh với lưu lượng truy cập dữ liệu trong một mạng hội tụ

1.2 Các khái niệm cơ chế lập lịch: FIFO, PQ, CQ, và MDRR

Lập lịch liên quan đến một kĩ thuật xếp hàng logic sử dụng để chọn hàng đợi

mà từ đó nó sẽ lấy gói tin kế tiếp Trong phần này ta sẽ nghiên cứu 3 cơ chế lập lịch là FIFO, PQ và CQ Ở phần sau sẽ là 3 kĩ thuật hàng đợi phổ biến nhất là WFQ , CBWFQ và LLQ

1.2.1 Hàng đợi FIFO (FIFO Queuing)

Lý do đầu tiên mà một bộ định tuyến cần hàng đợi mềm là để giữ một gói tin trong khi chờ giao diện xử lý xong gói tin trước đó Hàng đợi FIFO cung cấp một phương tiện để tổ chức các gói tin trong khi chúng đang chờ để thoát khỏi một giao diện

Hàng đợi FIFO không cần hai tính năng thú vị nhất của các công cụ xếp hàng khác, cụ thể là phân loại và lập lịch Hàng đợi FIFO sử dụng một hàng đợi mềm duy nhất cho giao diện Bởi vì chỉ có một hàng đợi, không cần thiết phải phân loại để quyết định việc xếp hàng và không cần phải lập lịch để chọn các hàng đợi để từ đó các lấy gói tin tiếp theo Chỉ có một phần thực sự thú vị của hàng đợi FIFO là chiều dài hàng đợi đó là việc cấu hình và làm thế nào chiều dài hàng đợi ảnh hưởng đến trễ và mất gói

Hàng đợi FIFO sử dụng tail drop để quyết định khi nào bỏ hoặc sắp xếp các gói tin Nếu ta cấu hình một hàng đợi FIFO dài hơn thì sẽ có nhiều hơn các gói tin có thể

có trong hàng đợi, có nghĩa là sẽ các gói tin ít bị hủy hơn Tuy nhiên, với một hàng đợi dài hơn, các gói dữ liệu có thể gặp nhiều chậm trễ và jitter Với một hàng đợi ngắn hơn, ít thời gian trễ , nhưng hàng đợi FIFO đơn bị lấp đầy nhanh hơn, nó sẽ gây ra nhiều tail drop Những sự thật này là đúng cho bất kỳ phương pháp xếp hàng nào, bao gồm cả FIFO

Hình 1-8 phác thảo đơn giản hàng đợi FIFO R1 sử dụng hàng đợi FIFO trên giao diện kết nối với R2 Chỉ một quyết định được yêu cầu khi cấu hình hàng đợi FIFO là liệu có nên thay đổi độ dài của hàng đợi

Hình 1-8 Hàng đợi FIFO đơn giản

Hãy nhớ xem xét hai bước khi cấu hình hàng đợi FIFO Đầu tiên , cấu hình hàng đợi FIFO thực sự đòi hỏi phải tắt tất cả các loại hàng đợi Cisco IOS sử dụng WFQ là phương pháp xếp hàng mặc định trên giao diện serial chạy ở tốc độ E1 và

chậm hơn Tuy nhiên, IOS không cung cấp một lệnh để kích hoạt hàng đợi FIFO Để cho phép hàng đợi FIFO hoạt động, trước tiên ta vô hiệu hóa WFQ bằng cách sử dụng lệnh no fair-queue Nếu các kỹ thuật xếp hàng khác đã được cấu hình một cách rõ ràng , ta phải vô hiệu hóa trước Chỉ cần bằng cách loại bỏ tất cả cấu hình hàng đợi khác từ một giao diện, bạn đã kích hoạt FIFO !

Các bước cấu hình FIFO thứ hai mà ta phải xem xét là để ghi đè lên chiều dài hàng

đợi mặc định Để làm như vậy, sử dụng lệnh hold-queue x out để thiết lập lại chiều

dài của hàng đợi

Ví dụ 1-2 Cấu hình hàng đợi FIFO

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation HDLC, loopback not set

Keepalive set (10 sec)

CRC checking enabled

Last input never, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 5 interface resets

0 output buffer failures, 0 output buffers swapped out

Last input never, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/50 (size/max)

-

Ví dụ 1-2 cho thấy hàng đợi FIFO được cấu hình bằng cách loại bỏ các cấu

hình WFQ mặc định với lệnh no fair-queue Lệnh show interface hiển thị các thực tế

là hàng đợi FIFO được sử dụng, và hàng đợi đầu ra có tối đa 40 chỗ Sau khi cấu hình

hàng đợi đầu ra giữ 50 gói với lệnh hold-queue 50 out, dùng lênh show interface

hàng đợi được sử dụng vẫn là FIFO nhưng với kích thước hàng đợi tối đa là 50 Hàng đợi FIFO khá là cơ bản, nhưng nó cung cấp một chức năng hữu ích đó là tổ chức xếp hàng cho các gói tin cho đến khi giao diện không còn bận

1.2.2 Hàng đợi ưu tiên (Priority Queuing)

Tính năng đặc biệt nhất của hàng đợi ưu tiên là hệ thống lập lịch Lập lịch lưu lượng PQ để hàng đợi ưu tiên cao hơn luôn luôn nhận được phục vụ dẫn đến các tác dụng phụ là hàng đợi ưu tiên thấp hơn không được dùng đến Với tối đa là bốn hàng đợi là cao, trung bình , bình thường và thấp, PQ có thể hoàn thành việc lập lịch có thể

dễ dàng thể hiện, như trong hình 1-9

Hình 1-9 Quá trình lập lịch cho hàng đợi PQ

Như đã thấy trong hình 1-9 , nếu hàng đợi cao luôn luôn có một gói tin đang chờ, lập lịch sẽ luôn lấy các gói trong hàng đợi cao Nếu hàng đợi cao không có gói

tin đang chờ, nhưng hàng đợi trung bình lại có, một gói tin được lấy từ hàng đợi trung bình và sau đó quá trình này lại bắt đầu tại hàng đợi cao Hàng đợi thấp chỉ được phục

vụ nếu hàng đợi cao, trung bình và bình thường không có bất kỳ gói tin nào đang chờ

Lập lịch PQ có một số lợi ích và hạn chế rõ ràng Các gói tin trong hàng đợi cao có thể yêu cầu dùng 100% băng thông liên kết với trễ và jitter nhỏ Tuy nhiên các hàng đợi thấp bị ảnh hưởng Khi liên kết bị ách tắc, các ứng dụng người dùng có thể ngừng làm việc nếu các gói tin của họ được đặt vào hàng đợi ưu tiên thấp hơn

Thực tế, hàng đợi PQ có mức ưu tiên thấp hơn là sự lựa chọn khá phổ biến cho việc tạo hàng đợi ngày nay Ngoài ra, phương pháp LLQ có xu hướng là một lựa chọn tốt hơn, vì lập lịch của LLQ có khả năng để phục vụ các gói ưu tiên cao đầu tiên và ngăn chặn việc các hàng đợi có ưu tiên thấp hơn không được hoạt động

1.2.3 Hàng đợi tùy biến (Custom Queuing)

Trong lịch sử, hàng đợi tùy biến (CQ) là kỹ thuật hàng đợi phát triển sau PQ được đưa vào IOS CQ giải quyết những hạn chế lớn nhất của PQ bằng cách cung cấp một kỹ thuật xếp hàng phục vụ tất cả các hàng đợi, ngay cả trong thời gian bị tắc nghẽn Nó có 16 hàng đợi sẵn, đó là rất nhiều đối với hầu hết các ứng dụng Phần nhược điểm của CQ so với PQ là lập lịch của CQ không có một tùy chọn để luôn phục

vụ một hàng đợi đầu tiên như hàng đợi cao của PQ, do vậy CQ không phải là công cụ tốt nhất để chống trễ và độ nhạy jitter

Như với hầu hết các kỹ thuật xếp hàng, phần thú vị nhất của kỹ thuật này là lập lịch Lập lịch của CQ dành một tỷ lệ băng thông liên kết tổng thể cho mỗi hàng đợi Hình 1-10 mô tả lập lịch của CQ

Hình 1-10 Lập lịch logic cho hàng đợi CQ

Lập lịch CQ sử dụng cơ chế round-robin trên mỗi hàng đợi, bắt đầu với hàng đợi 1 CQ lấy gói tin từ hàng đợi cho đến khi tổng số byte theo quy định cho hàng đợi

đã được đáp ứng hoặc vượt quá Sau khi hàng đợi đã được phục vụ cho nhiều byte hoặc hàng đợi không còn bất kỳ gói dữ liệu nào, CQ sẽ chuyển sang hàng đợi tiếp theo và lặp đi lặp lại quá trình này

CQ không cấu hình tỷ lệ phần trăm băng thông liên kết chính xác, nhưng nó cấu hình số byte được lấy từ mỗi hàng đợi khi mỗi round-robin vượt qua hàng đợi Giả sử một kỹ sư cấu hình CQ sử dụng năm hàng đợi Các kỹ sư chỉ định 10.000 byte cho mỗi hàng đợi Với cấu hình này, các kỹ sư đã dành 20 phần trăm băng thông liên kết cho mỗi hàng đợi (Nếu mỗi hàng đợi gửi 10.000 byte, tổng cộng là 50.000 byte được gửi đi mỗi chu kỳ thì mỗi hàng đợi đã gửi 20 phần trăm tổng số byte) Nếu thay vào đó các kỹ sư đã giao số lượng byte 5.000 byte cho 2 hàng đợi đầu tiên, 10.000 cho

2 hàng đợi tiếp theo, và 20.000 cho hàng đợi thứ năm, tổng số byte gửi đi sẽ là 50.000 byte Vì vậy hàng đợi 1 và 2 sẽ nhận được 5.000/50.000 hay 10% băng thông liên kết Hàng đợi 3 và 4 sẽ nhận được 10000/50000 hoặc 20% của băng thông, và xếp hàng 5

sẽ nhận được 20000/50000 hoặc 40% Về cơ bản đảm lập lịch cho hàng đợi CQ bảo băng thông tối thiểu cho mỗi hàng đợi và cho phép hàng đợi có nhiều băng thông khi đúng điều kiện Hãy tưởng tượng rằng 5 hàng đợi đã được cấu hình với số lượng byte 5.000 , 5.000 , 10.000 , 10.000, và 20.000 cho hàng đợi từ 1 đến 5 tương ứng Nếu tất

cả 5 hàng đợi có rất nhiều gói tin để gửi, tỷ lệ phần trăm băng thông cho mỗi hàng đợi

là 10%, 10%, 20%, 20% và 40% như được mô tả trước đó Tuy nhiên, giả sử rằng hàng đợi 4 không có lưu lượng truy cập trong một khoảng thời gian ngắn Trong thời gian đó , lập lịch của hàng đợi CQ cố gắng để phục vụ hàng đợi 4, nó thông báo rằng không có gói tin nào đang chờ đợi Lập lịch CQ di chuyển ngay lập tức vào hàng đợi tiếp theo Qua khoảng thời gian này chỉ hàng đợi từ 1, 2, 3, 5 có gói tin đang chờ Trong trường hợp này , các hàng đợi sẽ nhận được 12,5%, 12,5%, 25%, 0% và 50% băng thông liên kết tương ứng (Số lượng byte mỗi chu kỳ/ 40.000) Cũng lưu ý rằng hàng đợi chưa được cấu hình sẽ được tự động bỏ qua

Không giống như PQ, CQ không đặt tên cho hàng đợi, hàng đợi sẽ được tính từ

1 đến 16 Không có hàng đợi nào được ưu tiên hơn hơn bằng cách dùng lập lịch, trừ việc chọn số byte dịch vụ cho mỗi hàng đợi Vì vậy, trong ví dụ trước, hàng đợi 5 với 20.000 byte dịch vụ trên mỗi lượt, có thể được coi là hàng đợi "tốt nhất" với cấu hình này Các mô hình lưu lượng sẽ thay đổi theo thời gian dài ngắn khác nhau Vì vậy việc lựa chọn những con số thực tế đòi hỏi phải phân tích và dự đoán lưu lượng truy cập tốt

1.3 Khái niệm và cấu hình: WFQ, CBWFQ, và LLQ

Trong phần này, ta sẽ nói về các khái niệm và cấu hình cho ba kỹ thuật xếp hàng phổ phổ biến nhất trong các bộ định tuyến của Cisco CBWFQ sử dụng lập lịch tương tự như CQ và MDRR, đặt băng thông liên kết cho mỗi hàng đợi LLQ kết hợp các tính năng đặt phòng băng thông của CBWFQ với một hàng đợi ưu tiên cao PQ, được gọi là hàng đợi trễ thấp (Low Latency Queue) , cho phép lưu lượng truy cập bị trễ ở trong hàng đợi ngắn nhất có thể Nhưng trước tiên, phần này bắt đầu với WFQ,

sử dụng một cách lập lịch hoàn toàn khác nhau

1.3.1 Hàng đợi cân bằng trọng số - Weighted Fair Queuing (WFQ)

WFQ khác với PQ và CQ ở nhiều điểm khác nhau Sự khác biệt đầu tiên và rõ ràng nhất là WFQ không cho phép tùy chọn phân loại (classification) phải được cấu

hình! WFQ phân loại các gói tin dựa trên luồng (flow) Một luồng bao gồm tất cả các gói có cùng một địa chỉ IP nguồn và cùng cổng nguồn và cổng đích Một sự khác biệt lớn nữa của WFQ so với PQ và CQ là lập lịch, lập lịch chia làm 3 mức đó là low-volume, higher-precedence flows over large-volume, lower-precedence flows Cũng

vì WFQ dựa trên dòng và mỗi dòng sử dụng một hàng đợi khác nhau nên số lượng hàng đợi trở nên khá lớn, lên đến tối đa là 4096 hàng đợi trên mỗi giao diện

1.3.1.1 Phân loại WFQ (WFQ Classification)

Trong một gói tin IP, dòng được xác định bởi ít nhất năm các mục :

 Địa chỉ IP nguồn

 Địa chỉ IP đích

 Giao thức lớp giao vận (TCP hoặc UDP) được định nghĩa bởi trường header trong Giao thức IP

 Địa chỉ cổng nguồn TCP hay UDP

 Địa chỉ cổng đích TCP hay UDP

Thuật ngữ "dòng chảy" có thể có một vài ý nghĩa khác nhau Ví dụ, hãy tưởng tượng một máy tính được tải về một trang web Người dùng thấy trang xuất hiện, đọc các trang trong 10 giây và nhấn một nút Một trang web thứ hai xuất hiện, người dùng đọc trang trong 10 giây và nhấn nút khác Tất cả các trang và các đối tượng đến từ một máy chủ web duy nhất, và tất cả các trang và các đối tượng đã được nạp bằng cách sử dụng một kết nối TCP duy nhất giữa máy tính và máy chủ Có bao nhiêu sự kết hợp của nguồn / đích , địa chỉ / cổng và giao thức lớp giao vận khác nhau được sử dụng?

Có bao nhiêu dòng khác nhau? Từ một quan điểm thông thường, chỉ có một dòng chảy tồn tại trong ví dụ này , bởi vì chỉ có một kết nối TCP được sử dụng Từ quan điểm của WFQ , không có dòng xuất hiện hoặc ba dòng tồn tại và thậm chí có thể nhiều hơn nữa

Hầu hết mọi người đều cho rằng chỉ có một dòng TCP duy nhất tồn tại miễn là

có thể duy trì kết nối TCP, bởi vì các gói tin trong kết nối luôn có cùng một địa chỉ nguồn, cổng nguồn, địa chỉ đích, và cổng đích Tuy nhiên, WFQ xem xét một dòng chỉ tồn tại nếu gói dữ liệu từ dòng đó cần được xếp hàng Ví dụ, khi người dùng đang đọc các trang web trong 10 giây, các bộ định tuyến hoàn thành việc gửi tất cả các gói tin từ máy chủ web khi đó hàng đợi cho dòng đó là rỗng Bởi vì các bộ định tuyến trung gian không có gói tin trong hàng đợi cho dòng chảy đó nên WFQ loại bỏ các dòng Tương tự như vậy , ngay cả khi chuyển đối tượng khác nhau trong một trang web, nếu hàng đợi của dòng WFQ rỗng thì nó loại bỏ các hàng đợi bởi vì nó không còn cần thiết

1.3.1.2 Lập lịch WFQ : Tác động thực

Cisco công bố thông tin về cách lập lịch WFQ hoạt động Tuy nhiên, ngay cả với một sự hiểu biết về cách lập lịch làm việc, các mục tiêu thực sự đằng sau việc lập lịch không rõ ràng Phần này phản ánh những gì WFQ cung cấp, và các phần sau đây

mô tả cách WFQ hoàn thành nhiệm vụ Cơ chế lập lịch cho WFQ có hai mục tiêu chính

Đầu tiên là cung cấp một sự công bằng giữa các dòng hiện đang tồn tại Để cung cấp sự công bằng, WFQ cho mỗi dòng lượng băng thông như nhau Nếu 10 dòng tồn tại trong một giao diện và băng thông là 128 kbps thì mỗi dòng có băng thông là 12,8 kbps Nếu 100 dòng tồn tại, mỗi dòng được 1,28 kbps Giả sử với link liên kết 128Kbps với 10 dòng Nếu dòng 1 cần 5 kbps mà WFQ cho phép 12,8 kbps cho mỗi dòng, hàng đợi kết hợp với dòng 1 có thể không bao giờ có nhiều hơn một vài gói trong nó bởi vì các gói sẽ đi ra nhanh chóng Nếu dòng 2 cần 30 kbps mà WFQ chỉ cung cấp cho hàng đợi này 12,8 kbps nên gói tin sẽ trở lại trong hàng đợi dòng 2 Các gói tin ở hàng đợi sẽ chịu trễ, jitter và có thể bị mất nếu hàng đợi đầy Tất nhiên, nếu dòng 1 chỉ cần 5 kbps, lập lịch WFQ sẽ cho phép các luồng khác sử dụng lượng băng thông mở rộng

Mục tiêu thứ hai của lập lịch WFQ là cung cấp băng thông nhiều hơn cho dòng với giá trị IP precedence cao hơn Ví dụ với 10 dòng trong một liên kết 128-kbps, nếu

5 dòng sử dụng precedence 0 và 5 dòng sử dụng precedence 1, WFQ muốn cung cấp cho dòng precedence 1 băng thông gấp đôi dòng có precedence 0 Do đó, 5 dòng precedence 0 sẽ nhận được khoảng 8,5 kbps mỗi dòng và 5 dòng có precedence 1 sẽ nhận được khoảng 17 kbps mỗi dòng Trong thực tế, WFQ cung cấp việc chia sẻ băng thông dựa trên tỷ lệ ưu tiên của mỗi dòng chảy cộng với một Nói cách khác, dòng có precedence 7 có băng thông cao hơn 8 lần so với dòng có precedence 0, bởi vì (7+1)/(0+1)=8 Nếu bạn so sánh precedence 3 với precedence 0, tỷ lệ này là khoảng (3+1)/(0+1) =4

Vậy mục đích của WFQ là gì ? Bỏ qua việc ưu tiên, câu trả lời ngắn gọn là dòng chảy khối lượng bé hơn nhận được dịch vụ tốt hơn và các dòng chảy khối lượng cao hơn nhận được dịch vụ kém hơn Dòng có ưu tiên cao hơn nhận được dịch vụ tốt hơn so với dòng có ưu tiên thấp hơn Nếu dòng có khối lượng thấp hơn được cho giá trị precedence cao hơn thì các giá trị băng thông/trễ / jitter / loss sẽ được cải thiện hơn nhiều Trong một mạng, những nơi có nhạy cảm trễ nhiều thì nơi đó dòng có khối lượng thấp hơn vì vậy WFQ là một giải pháp tuyệt vời Chỉ cần 1 lệnh để kích hoạt

nó và nó đã được kích hoạt mặc định! WFQ thuận lợi cho dòng chảy khối lượng thấp hơn, có thể là các dòng chảy quan trọng hơn như Telnet và Systems Network Architecture (SNA) đóng gói trong IP

1.3.1.3 Lập lịch WFQ: Tiến trình

WFQ cho mỗi dòng một tỷ lệ phần trăm trọng lượng của băng thông liên kết Tuy nhiên, WFQ không ấn định trước hàng đợi như các kỹ thuật xếp hàng dựa trên lớp (class-based) vì WFQ tự động tạo ra hàng đợi để giữ các gói trong mỗi dòng Mỗi dòng có thể có giá trị ưu tiên khác nhau, tỷ lệ băng thông liên kết cho mỗi dòng chảy

sẽ thay đổi và nó sẽ thay đổi rất nhanh vì các gói tin đến và đi thường xuyên Trong

thời gian ngắn, WFQ chỉ có thể không được thực hiện bằng cách chỉ định một tỷ lệ phần trăm băng thông hoặc một số byte cho mỗi hàng đợi

Cơ chế lập lịch WFQ thực sự là rất đơn giản Khi hàng đợi cứng giải phóng một chỗ trống, WFQ có thể di chuyển một gói tin đến đó, giống như bất kỳ công cụ hàng đợi khác Lập lịch WFQ lấy gói tin với các số thứ tự (SN) thấp nhất trong số tất

cả các hàng đợi và di chuyển nó vào hàng đợi cứng Các SN (sequence number) được chỉ định khi các gói tin được đặt vào một hàng đợi

Hình 1-11 WFQ: Gán số thứ tự SN và hàng đợi phục vụ

WFQ tính toán SN trước khi thêm một gói tin đến hàng đợi cụ thể là trước khi quyết bỏ gói ( Drop Decision) Lập lịch xem xét cả chiều dài gói và mức ưu tiên khi tính toán SN Công thức để tính toán SN cho một gói tin như sau:

Previous_SN +(weight * new_packet_length)

Trong đó "weight" được tính như sau:

𝒘𝒆𝒊𝒈𝒉𝒕 = 𝟑𝟐, 𝟑𝟖𝟒

(𝑰𝑷 𝑷𝒓𝒆𝒄𝒆𝒅𝒆𝒏𝒄𝒆 + 𝟏)

Công thức trên bao gồm:

+ Chiều dài của gói tin mới (new_packet_length): Bằng cách xem xét chiều

dài gói tin, kết quả tính toán SN sẽ cho một số cao hơn cho các gói tin lớn hơn

và một số thấp hơn cho các gói tin nhỏ hơn

+ Số SN trước đó (Previous_SN): Bằng cách bao gồm các SN của gói tin trước đặt vào hàng đợi, công thức sẽ gán một số lớn cho các gói tin trong hàng đợi

đó

+ Trọng lượng của dòng (weight): Lập lịch WFQ sẽ gửi gói tin với số SN thấp nhất và WFQ muốn cung cấp thêm băng thông cho các dòng ưu tiên cao Vì vậy, các giá trị trọng lượng là tỉ lệ nghịch với giá trị ưu tiên

Bảng 1-2 liệt kê các giá trị trọng lượng được sử dụng bởi WFQ trong IOS 12,0

(5)T/12,1

1.3.1.4 WFQ: Chính sách bỏ gói, số lượng và chiều dài hàng đợi

WFQ sử dụng chính sách tail-drop với một chút thay đổi cho việc lựa chọn khi

bỏ các gói tin Quyết định này dựa trên một số yếu tố, một trong số đó là SN của gói tin

WFQ đặt một giới hạn tuyệt đối về số lượng các gói tin được xếp hàng trong tất

cả các hàng đợi, giá trị này được gọi là giới hạn hold-queue Nếu một gói tin mới đến

và giới hạn hold-queue đã đạt được thì gói tin đó sẽ bị hủy Đó là một phần của quyết định không dựa trên một hàng đợi duy nhất, nhưng trên toàn bộ hệ thống hàng đợi WFQ cho giao diện

Các quyết định tiếp theo được dựa trên một hàng đợi riêng lẻ Nếu một gói tin cần được đặt vào một hàng đợi và ngưỡng Congestive Discard Threshold (CDT) đã đạt được, các gói dữ liệu có thể được bỏ đi CDT gần giống như chiều dài hàng đợi tối

đa cho mỗi hàng đợi của dòng Để đánh giá đúng cách CDT được sử dụng, ta xem xét hình 1-12

Hình 1-12 WFQ Modified Tail Drop và Congestive Discard Threshold

Kích thước hold-queue giới hạn tổng số gói tin trong tất cả các hàng đợi lưu lượng Tuy nhiên, CDT giới hạn số lượng các gói tin trong mỗi hàng đợi Nếu gói tin CDT đang nằm trong một hàng đợi, WFQ xẽ xem xét loại bỏ các gói tin mới Thông thường, các gói dữ liệu mới được loại bỏ Tuy nhiên nếu một gói tin với một số SN lớn hơn đã được xếp hàng trong một hàng đợi khác, WFQ đành phải loại bỏ các gói tin có SN lớn hơn! Trong thời gian ngắn, WFQ có thể loại bỏ một gói tin trong luồng khác khi hàng đợi cho luồng đó đã vượt quá CDT nhưng vẫn có số thứ tự thấp hơn Ta

có thể cấu hình CDT đến một giá trị từ 1 đến 4096

Cuối cùng, WFQ có thể được cấu hình cho tối đa là 4096 hàng đợi, nhưng giá trị thực tế chỉ bao gồm cấp số mũ của 2 từ 16 đến 4096 IOS hạn chế các giá trị vì WFQ thực hiện một thuật toán băm để phân loại lưu lượng truy cập và các thuật toán băm chỉ hoạt động khi số lượng hàng đợi là một trong những giá trị hợp lệ

1.3.1.5 Cấu hình WFQ

Mặc dù WFQ đòi hỏi một chút kiểm tra sâu hơn để hiểu tất cả các khái niệm cơ bản nhưng cấu hình lại thực sự đơn giản IOS sử dụng WFQ theo mặc định trên tất cả các cổng serial với băng thông đặt ở tốc độ T/1 và E/1 và thấp hơn Không thể thiết lập các thông số WFQ cho một hàng đợi riêng lẻ, cấu hình WFQ chỉ dài một hoặc hai dòng

hold-queue length out Thay đổi chiều dài của hold-queue

Bảng 1-4 Lệnh kiểm tra cho WFQ

show queueing [custom | fair | priority |

random-detect [interface atm-subinterface [vc

[[vpi/] vci]]]]

Liệt kê cấu hình và thông tin thống

kê về kỹ thuật xếp hàng trên một giao diện

1.3.1.6 Tóm tắt WFQ

WFQ hoạt động tốt cho các mạng nơi có nhạy cảm trễ cao, đòi hỏi băng thông

ít hơn so với lưu lượng trung bình Nơi có lưu lượng với độ ưu tiên cao, với khối lượng thấp… Điều tốt nhất là không đòi hỏi cấu hình WFQ phân loại Kết quả là WFQ được cấu hình mặc định là sự lựa chọn hàng đầu, đặc biệt là khi tính chất lưu lượng không thể đoán trước và khó khăn trong việc xác định điều kiện

WFQ làm việc kém cho lưu lượng thoại và video tương tác bởi vì cả hai đều cần độ trễ và jitter thấp WFQ không cung cấp một hàng đợi ưu tiên để giảm thiểu trễ

và jitter Ngoài ra trễ có thể tăng khi quá nhiều dòng đồng thời được đưa vào, do WFQ chia băng thông cho tất cả các dòng, có thể làm cho lưu lượng thoại hoặc video không

có đủ băng thông Bảng 1-5 tóm tắt một số tính năng chính của WFQ

Bảng 1-5 Chức năng và tính năng của WFQ

Chiều dài hàng đợi tối

đa Ngưỡng CDT (Congestive Discard Threshold) cho mỗi hàng đợi tối đa 4096, với một giới hạn tổng thể dựa trên hold-queue

1.3.2 Hàng đợi cân bằng trọng số theo lớp - Class-Based WFQ

Để hiểu rõ về CBWFQ ta hãy xem hình 1-13:

Hình 1-13 Tóm tắt các tính năng chính của CBWFQ

Bắt đầu từ trái sang phải trong hình, CBWFQ phân loại các gói tin bằng cách

sử dụng cùng một tập hợp chính xác các trường đánh dấu theo CB sử dụng để phân loại gói tin Hơn nữa CBWFQ còn sử dụng các lệnh cấu hình tương tự, tất cả đều là một phần của lệnh Modular QoS CLI (MQC) Và không giống như WFQ, sử dụng phân loại dựa theo dòng, CBWFQ không phân loại dựa theo dòng

CBWFQ hỗ trợ hai loại chính sách bỏ gói cụ thể là tail-drop và WRED WRED là để loại bỏ các gói trước khi hàng đợi thực sự lấp đầy, với mục đích làm cho một số các kết nối TCP giảm các gói tin bị mất và làm chậm gửi các gói tin Bởi có một vài kết nối TCP chậm lại, hàng đợi có thể không đầy và giảm ùn tắc

Ta có thể bật WRED trên hàng đợi bất kỳ trong số 64 hàng đợi sẵn có với CBWFQ Tuy nhiên, WRED là một lựa chọn tốt đối với một số hàng đợi này và lại xấu đối với hàng đợi khác Ví dụ, trong VoIP ta không thực sự muốn bỏ bất kỳ gói tin nào bởi vì nếu bỏ gói tin chất lượng thoại sẽ giảm xuống rất nhiều Trái lại với các gói tin dữ liệu WRED là một lựa chọn tốt

CBWFQ hỗ trợ 64 hàng đợi, với chiều dài hàng đợi mặc định khác nhau tùy thuộc vào mô hình của router và số lượng bộ nhớ cài đặt Tất cả 64 hàng đợi có thể

được cấu hình, nhưng một lớp hàng đợi được gọi là lớp mặc định được tự động cấu hình Nếu phân loại cấu hình không phù hợp với một gói tin, IOS đặt gói tin vào các lớp mặc định Ta được phép thay đổi các chi tiết cấu hình liên quan đến lớp mặc định này, nhưng không thể xóa nó

Hiện nay, CBWFQ có thể sử dụng FIFO hoặc WFQ bên trong lớp hàng đợi mặc định Với điều chỉnh dòng theo WFQ trong lớp hàng đợi mặc định, khi CBWFQ quyết định lấy một hoặc nhiều hơn các gói tin từ hàng đợi, nó lấy gói tin với các số thứ tự (SN) tốt nhất giống như WFQ

Hình 1-14 Cấu hình ví dụ mạng sử dụng CBWFQ

CBWFQ cung cấp một lợi thế lớn bằng cách cho phép WFQ sẽ được sử dụng trong hàng đợi lớp mặc định WFQ thực sự là một lựa chọn mặc định rất tốt cho xếp hàng, vì nó xử lý dòng có khối lượng thấp và các gói có độ ưu tiên cao tốt Như vậy với CBWFQ nếu ta biết về lưu lượng truy cập, ta có thể phân loại nó và bảo lưu lượng băng thông cần thiết cho các lớp Đối với các lưu lượng không thể mô tả, ta để nó mặc định vào hàng đợi lớp mặc định Tại đó các gói tin sẽ nhận được băng thông một cách công bằng vì mặc định sử dụng WFQ Khả năng dự trữ băng thông cho một số gói và công bằng trong việc gán phần còn lại của băng thông với WFQ, làm cho CBWFQ một công cụ xếp hàng rất mạnh mẽ

Bảng 1-6 Chức năng và tính năng của CBWFQ

Experimental, QoS group, and RTP port numbers

Chính sách bỏ gói

(Drop policy)

Tail drop hoặc WRED, cấu hình trên mỗi hàng đợi

Bảng 1-6 Chức năng và tính năng của CBWFQ

Bảng 1-7 Lệnh tham khảo cho CBWFQ

class-map class-map-name Cấu hình tên class-map

specific classification parameters match access-group {access-group | name

access-group- name}

Access control list (ACL)

match source-address mac address Địa chỉ MAC nguồn

match ip precedence ip-precedence-value

[ip-precedence-value ip-precedence-value

ip-precedence-value]

IP precedence

match mpls experimental number MPLS Experimental

match cos cos-value [cos-value cos-value

cos-value]

CoS

match destination-address mac address Địa chỉ MAC đích

match input-interface interface-name Giao diện đầu vào

match ip dscp ip-dscp-value [ip-dscp-value

ip-dscp-value ip-dscp-value ip-dscp-value

ip-dscp-value ip-dscp-value ip-dscp-value]

IP DSCP

match ip rtp starting-number

port-range

RTP's UDP port number range

match qos-group qos-group-value Nhóm QoS

match protocol protocol-name Kiểu giao thức NBAR

Bảng 1-7 Lệnh tham khảo cho CBWFQ

match protocol citrix [app

application-name-string]

NBAR Citrix applications

match protocol http [url url-string | host

hostname-string | mime MIME-type]

Tên host và chuỗi URL

policy-map policy-map-name Cấu hình tên policy-map

bandwidth {bandwidth-kbps | percent

percent}

Thiết lập băng thông theo kbps hoặc theo phần trăm Phải sử dụng cùng một chuẩn trong một policy-map

bandwidth {remaining percent percent} Cấu hình băng thông còn lại cho một

class Dùng khi tính lệnh tính băng thông phải được cấu hình rõ ràng số liệu

queue-limit queue-limit Thiết lập số gói tin tối đa trong hàng đợi

cho 1 class

fair-queue [queue-limit queue-value] Kích hoạt WFQ trong một class (Chỉ

dùng được trong class-default) random-detect dscp dscpvalue min-

threshold max- threshold

[mark-probability-denominator]

Kích hoạt DSCP- dựa trên WRED trong một class

random-detect precedence precedence

min-threshold max- min-threshold

mark-prob-denominator

Kích hoạt precedence-based WRED trong một class

max-reserved-bandwidth percent Định nghĩa phần trăm băng thông đường

truyền có thể dự trữ cho hàng đợi CBWFQ bên cạnh class-default

Bảng 1-8 Lệnh kiểm tra việc cấu hình CBWFQ

show policy-map policy-map-name Hiển thị tất cả thông tin cấu hình về

MQC-based QoS show policy-map interface-spec [input |

output] [class class-name]

Liệt kê tất cả thông tin thống kê hoạt động của các kỹ thuật MQC-based QoS

Ví dụ một chính sách QoS đơn giản đã được đưa ra, trong đó bao gồm những điều sau đây

 Tất cả các lưu lượng VoIP được đặt trong một hàng đợi

 Tất cả các lưu lượng khác được đặt trong hàng đợi khác

 Cung cấp cho lưu lượng VoIP 50% băng thông

 WFQ và WRED nên được sử dụng vào lưu lượng không phải VoIP Dùng topo hình 1.19 và cấu hình trên R3 như ví dụ sau:

Ví dụ 1-3 CBWFQ, VoIP trong một hàng đợi và lưu lượng khác một hàng đợi

interface Serial0/0.1 point-to-point

description point-point subint global DLCI 103, connected via PVC to DLCI 101 (

R1)

ip address 192.168.2.253 255.255.255.0

frame-relay interface-dlci 101

! Portions omitted for brevity

R3#show policy-map int s 0/0

Serial0/0

Service-policy output: queue-voip

Class-map: voip-rtp (match-all)

136435 packets, 8731840 bytes

30 second offered rate 51000 bps, drop rate 0 bps

Match: ip rtp 16384 16383

Weighted Fair Queueing

Output Queue: Conversation 265

Bandwidth 50 (%) Max Threshold 64 (packets)

(pkts matched/bytes matched) 48550/3107200

(depth/total drops/no-buffer drops) 14/0/0

Class-map: class-default (match-any)

1958 packets, 1122560 bytes

30 second offered rate 59000 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 15/0/0

R3#show policy-map int s 0/0 output class class-default Serial0/0

Service-policy output: queue-voip

Class-map: class-default (match-any)

2217 packets, 1417985 bytes

30 second offered rate 71000 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 10/0/0

R3#show policy-map

Policy Map queue-voip

Class voip-rtp

Weighted Fair Queueing

Bandwidth 50 (%) Max Threshold 64 (packets)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing Max Threshold 64 (packets)

R3#show interface s 0/0

Serial0/0 is up, line protocol is up

Hardware is PowerQUICC Serial

Description: connected to FRS port S0 Single PVC to R1

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 255/255, txload 9/255, rxload 8/255

Encapsulation FRAME-RELAY, loopback not set

Keepalive set (10 sec)

LMI enq sent 132, LMI stat recvd 132, LMI upd recvd 0, DTE LMI up

LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0

LMI DLCI 1023 LMI type is CISCO frame relay DTE

FR SVC disabled, LAPF state down

Broadcast queue 0/64, broadcasts sent/dropped 307/0, interface broadcasts 285

Last input 00:00:02, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:22:02

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 16/1000/64/0 (size/max total/threshold/drops)

Conversations 4/8/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec

30 second input rate 52000 bits/sec, 102 packets/sec

30 second output rate 59000 bits/sec, 101 packets/sec

126301 packets input, 8141304 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

126197 packets output, 8550371 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 output buffer failures, 0 output buffers swapped out

Weighted Fair Queueing

Bandwidth 50 (%) Max Threshold 64 (packets)

S0/0

Lệnh show policy-map interface serial 0/0 liệt kê các thông tin thống kê về

CBWFQ Nó liệt kê một kệ thông tin cho mỗi lớp, danh sách các cấu hình match và tỷ

lệ phần trăm băng thông Tỷ lệ cung cấp lưu lượng truy cập đã được phân loại thành từng hàng đợi được liệt kê, cùng với thống kê số gói bị hủy Những giá trị này rất hữu ích khi kiểm tra cấu hình để quyết định xem các giá trị cấu hình nên được thay đổi Cũng lưu ý rằng trong lớp mặc định, đầu ra nói lên lưu lượng dựa trên WFQ được sử dụng trong hàng đợi

Lệnh show policy-map chỉ liệt kê một bản tóm tắt của các chính sách cấu hình

Điều đặc biệt là class-default của đoạn đó có sử dụng Weighted Fair Queuing và sau

đó có dòng" flow based." Trong trường hợp này, đoạn lệnh nói rằng trong hàng đợi lớp mặc định, lưu lượng dựa trên WFQ được áp dụng cho từng dòng Để so sánh, ở phần cuối của ví dụ cấu hình đã được thay đổi để vô hiệu hóa WFQ trong hàng đợi lớp

mặc định Lệnh show policy-map không còn liệt kê Flow-Based WFQ class-default

Một thiết kế tốt QoS đòi hỏi việc đánh dấu các gói gần với nguồn của gói tin

Ví dụ 1-5 thực hiện việc xếp hàng tương tự như ví dụ trên, nhưng CBWFQ dựa trên các gói tin đã được đánh dấu trước khi đến cổng S0/0 của R3 Trong một mạng thực

tế, các gói dữ liệu có thể được đánh dấu vào một trong các thiết bị chuyển mạch mạng LAN hoặc trong một điện thoại IP hoặc các máy tính trong mạng

Ví dụ này cho thấy các gói dữ liệu được đánh dấu khi vào cổng E0/0 của R3,

Ví dụ 1-5 cho thấy cấu hình sửa đổi dựa trên các tiêu chí sau:

 Tất cả các lưu lượng VoIP đã được đánh dấu với DSCP EF và được đặt trong một hàng đợi

 Tất cả các lưu lượng khác đã được đánh dấu với DSCP BE và đặt trong một hàng đợi khác

 Cung cấp cho các lưu lượng VoIP 58 kbps băng thông liên kết

Sử dụng WRED và WFQ trên lưu lượng không phải VoIP

R3#show policy-map interface serial 0/0

Serial0/0

Service-policy output: queue-on-dscp

Class-map: dscp-ef (match-all)

8654 packets, 553856 bytes

30 second offered rate 51000 bps, drop rate 0 bps

Match: ip dscp ef

Weighted Fair Queueing

Output Queue: Conversation 41

Bandwidth 58 (kbps) Max Threshold 30 (packets)

(pkts matched/bytes matched) 8442/540288

(depth/total drops/no-buffer drops) 8/0/0

Class-map: class-default (match-any)

673 packets, 779357 bytes

30 second offered rate 71000 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

(total queued/total drops/no-buffer drops) 14/0/0

Weighted Fair Queueing

Bandwidth 58 (kbps) Max Threshold 30 (packets)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing

exponential weight 9

dscp min-threshold max-threshold mark-probability

Lệnh policy-map voip-and-be đánh dấu các gói khi chúng đi vào E0/0 match,

đánh dấu các gói VoIP với DSCP EF và match, đánh dấu tất cả các gói khác DSCP

BE Lệnh class-map match-all dscp-ef tạo ra một lớp, match với tất cả lưu lượng DSCP EF policy-map queue-on-dscp đề cập đến class dscp-ef để match tất cả lưu lượng VoIP, cho lưu lượng thoại 58 kbps với các lệnh bandwidth 58 Trong lớp đó thêm lệnh queue-limit 30, thay đổi kích thước hàng đợi tối đa đến 30 CBWFQ sử dụng tail-drop trong mỗi lớp theo mặc định, do đó dưới lệnh class-default , lệnh random-detect dscp-based được sử dụng để kích hoạt WRED trong lớp mặc định Ngoài ra, tất nhiên, lệnh service-policy kích hoạt các chính sách dịch vụ trên giao

diện

Một trong những lợi thế lớn của phân loại và đánh dấu là sau khi các gói được đánh dấu, cấu hình của các công cụ cung cấp hành vi của mỗi hop (Per-Hop Behavior PHB) đơn giản Một ưu điểm khác là sau khi gói tin đã được đánh dấu, các thiết bị khác có thể thực hiện match đơn giản, chỉ cần tìm kiếm DSCP hoặc IP precedence Nếu các chính sách QoS áp dụng PHBs chỉ cho các gói tin đi ra giao diện WAN và áp dụng cho các gói vào và ra các giao diện mạng LAN, phân loại, đánh dấu và xếp hàng

có thể được thực hiện với một cấu hình duy nhất Ví dụ 1-6 cho thấy một cấu hình tương tự như ví dụ trên, nhưng với cả hai việc đánh dấu và xếp hàng cùng thực hiện cho các gói tin đi ra khỏi cổng S0/0 của R3

description connected to SW2, where Server1 is connected

! No service policy on E0/0!

!

interface serial0/0

clock rate 128000

bandwidth 128

service-policy output mark-and-queue

Hai lớp được sử dụng trong ví dụ này: voip-rtp, match tất cả lưu lượng VoIP trên các

cổng UDP; và lớp mặc định, match với tất cả các gói khác Bên trong policy-map mark-and-queue, mỗi lớp bao gồm một lệnh set để thiết lập giá trị DSCP Lớp voip- rtp có lệnh bandwidth với băng thông dự trữ; lớp mặc định tự động được 25% băng thông Lệnh service-policy output mark-and-queue kích hoạt chính sách cho gói tin

đi ra khỏi cổng S0/0 của R3 Trong ví dụ này, ta thấy được lợi ích của việc phân loại

và đánh dấu với một cấu hình ngắn hơn và chỉ một bước phân loại trong bộ định tuyến này

Ví dụ 1-6 Sử dụng lệnh Bandwidth khi dùng và không dùng lựa chọn Percent

R3(config-pmap-c)#bandwidth percent 25

!

R3(config-pmap-c)#int s 0/1

R3(config-if)#bandwidth 64

R3(config-if)#service-policy output explicit-bw

I/f Serial0/1 class class1 requested bandwidth 64 (kbps), available only 48 (kbps)

R3(config-if)#service-policy output percent-bw

Service-policy output: percent-bw

Class-map: class3 (match-all)

Class-map: class4 (match-all)

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Ví dụ này cho thấy một vài điểm quan trọng về các tùy chọn của lệnh

bandwidth trên các lớp Đầu tiên, bên trong một policy map duy nhất, bạn không thể

sử dụng lệnh bandwidth với cả 2 kiểu băng thông quy định rõ ràng và băng thông theo phần trăm Trong cả hai policy maps explicit-bw và percent-bw, khi một kiểu lệnh bandwidth được sử dụng, kiểu khác sẽ bị từ chối

Các vấn đề khác liên quan đến các thiết lập lệnh bandwidth: IOS cho phép dùng bao nhiêu băng thông có sẵn trên giao diện Trong ví dụ này, dưới interface serial 0/1, lệnh bandwidth 64 quy định 64 kbps băng thông Khi lệnh service-policy output explicit-bw được áp dụng, IOS từ chối nó Đó là bởi vì CBWFQ mặc định thiết lập max-reserved-bandwidth 75% trên mỗi giao diện, có nghĩa là theo mặc định

policy map không thể dùng nhiều hơn 75% trên tổng băng thông của giao diện Trong trường hợp này, 48 kbps là 75% băng thông của giao diện cấu hình 64-kbps, và policy

map explicit-bw đã cố gắng dành 64 kbps bên trong lớp class1, vì vậy lệnh policy đã bị từ chối

service-Tuy nhiên, lệnh service-policy output percent-bw đã không từ chối Bởi vì nó

chỉ sử dụng tỷ lệ phần trăm, mỗi lớp trong policy này đã cấu hình 25% băng thông nên

chúng sẽ nhận được băng thông là 16 kbps Ở cuối ví dụ ta dùng lệnhshow map sẽ nhìn thấy các tỷ lệ phần trăm cũng như tính toán 16 kbps cho mỗi hàng đợi

policy-1.3.2.2 Tóm tắt CBWFQ

CBWFQ kết hợp một số tính năng tốt nhất của các kỹ thuật hàng đợi khác nhau thành một kỹ thuật duy nhất Giống như CQ, CBWFQ có thể dự trữ một lượng đảm bảo băng thông cho mỗi hàng đợi, và đã giải quyết được nhược điểm của lập lịch CQ CBWFQ có thể sử dụng WFQ là hàng đợi mặc định cho lưu lượng không được phân loại bên trong lớp class-default Ngoài ra, trong tất cả các kỹ thuật xếp hàng, CBWFQ

có sự đa dạng lớn nhất trong việc sử dụng lệnh match trực tiếp để phân loại gói tin Tuy nhiên, CBWFQ cũng có một số nhược điểm Hầu hết các nhược điểm là không đáng kể, nhưng một trong những nhược điểm là thiếu tính năng giống như PQ Nhạy cảm trễ và jitter với lưu lượng vẫn còn xảy ra, ngay cả CBWFQ cấp đủ đủ băng thông,

bởi vì chế độ lập lịch của CBWFQ có thể vẫn phục vụ hàng đợi khác khi một gói tin VoIP hoặc video đang chờ trong hàng đợi Các tính năng tiếp theo được đề cập là Low Latency Queuing (LLQ) sẽ khắc phục vấn đề này

1.3.3 Low Latency Queuing (LLQ)

Chúng ta có thể xem xét và lựu chọn kỹ thuật hàng đợi LLQ nếu chúng ta cần

hỗ trợ QoS tốt cho các ứng dụng nhạy cảm với độ trễ và jitter như VoiP Bởi vì LLQ

là một kỹ thuật được mở rộng từ kỹ thuật hàng đợi cân bằng trọng số theo lớp CBWFQ, nó bổ sung cho mạng đang sử dụng CBWFQ để phục vụ cho các lớp ứng dụng khác nhau bằng cách thêm vào một lớp khác và chỉ định các hàng đợi trong lớp

đó là các hàng đợi ưu tiên Các hàng đợi ưu tiên này cho phép các ứng dụng như Voice có thể nhận được ưu tiên trong hàng đợi và gửi đi đầu tiên, do đó nó không bị trễ và Jitter xảy ra đối với các gói tin Voice Nếu ta đang sử dụng CBWFQ và sử

dụng lệnh priority kích hoạt trong một trong một lớp thì ta đã chuyển sang sử dụng

LLQ và một lớp với các lệnh priority là "LLQ" hoặc "PQ."

Vậy làm thế nào LLQ có thể đảm bảo băng thông cho các hàng đợi khác? Theo logic mà nói thì không bao giờ cho phép những hàng đợi này được phục vụ? Để ngăn chặn LLQ với cùng một vấn đề như PQ, nơi các gói tin trong hàng đợi ưu tiên cao