Quản lý nghẽn và tránh nghẽn. [Lưu trữ] - WiMAX and Wi-Fi Professional

View Full Version : Quản lý nghẽn và tránh nghẽn.

Ryta

17-04-2010, 07:01

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="themeData" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"> <m:smallfrac m:val="off"> <m:dispdef> <m:lmargin m:val="0"> <m:rmargin m:val="0"> <m:defjc m:val="centerGroup"> <m:wrapindent m:val="1440"> <m:intlim m:val="subSup"> <m:narylim m:val="undOvr"> </m:narylim></m:intlim> </m:wrapindent><style>  </style> </m:defjc></m:rmargin></m:lmargin></m:dispdef></m:smallfrac>

Quản lý nghẽn và tránh nghẽn<o:p></o:p>

<o:p> </o:p>

( tác giả : Đặng Quang Minh)

Cơ chế quản lý nghẽn, còn được gọi là cơ chế hàng đợi (queuing), muốn chỉ đến cách thức mà một router hay một switch quản lý một gói tin hay một frame khi dữ liệu đó đang chờ để đi ra một cổng. Với router, quá trình chờ đợi thường diễn ra khi tiến trình đẩy gói tin IP đã hoàn tất. Vì vậy, cơ chế hàng đợi thường chỉ được xem xét là hàng đợi ra. Các LAN switch thường hỗ trợ cả hàng đợi vào và hàng đợi ra, trong đó hàng đợi vào thường được dùng để nhận frame đang được truyền ra ngõ ra của switch.

Công cụ tránh nghẽn muốn chỉ đến thuật toán được dùng khi quyết định có hay không và khi nào thì gói tin nên bị loại bỏ khi một hệ thống hàng đợi đã bị quá tải.

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

Các router Cisco có thể được cấu hình để thực hiện đưa vào hàng đợi những gói tin đang chờ thoát ra khỏi một cổng. Ví dụ, nếu một router nhận mức lưu lượng 5Mbps mỗi giây trong vài giây liên tiếp và tất cả các lưu lượng đó cần đi ra một cổng T1 (1.544Mps), router sẽ không thể truyền tất cả các lưu lượng đó. Vì vậy, router sẽ đặt tất cả các gói tin vào một trong những hàng đợi phần mềm. Những hàng đợi này có thể cấu hình và thông qua đó, người quản trị có thể can thiệp những gói tin nào có thể kế tiếp rời khỏi cổng, những gói tin nào có thể loại bỏ.

Hàng đợi phần cứng và hàng đợi phần mềm

Khái niệm này dễ bị bỏ qua khi ta nói đến các chi tiết bên dưới của hàng đợi cứng và hàng đợi mềm trong một cổng vật lý của router. Các hàng đợi được tạo ra trên một cổng của router bằng các công cụ hàng đợi là hàng đợi mềm vì các hàng đợi này được hiện thực bằng phần mềm. Tuy nhiên, khi cơ chế hàng đợi xử lý đến gói tin kế tiếp trong hàng đợi mềm, gói tin này không được di chuyển trực tiếp ra cổng vật lý.

Thay vào đó, router sẽ di chuyển gói tin từ hàng đợi mềm sang một hàng đợi nhỏ bằng phần cứng FIFO. Cisco gọi các hàng đợi riêng biệt cuối cùng này là hàng đợi truyền (transmit queue - TX queue) hoặc vòng tròn hoặc vòng tròn truyền (TX ring) tùy thuộc vào kiểu router. Tổng quát, các hàng đợi này được gọi là các hàng đợi phần cứng.

Các hàng đợi phần cứng có các đặc điểm sau đây:

- Khi một cổng hoàn tất việc gửi một gói tin, gói tin kế tiếp từ hàng đợi cứng có thể được mã hóa và gửi ra cổng mà không cần ngắt CPU bằng phần mềm, giúp đảm bảo sử dụng đầy đủ băng thông của cổng.

- Luôn luôn dùng cơ chế FIFO.

- Không thể bị ảnh hưởng bởi các công cụ hàng đợi QoS.

- IOS tự động giảm kích thước của hàng đợi phần cứng đến một chiều dài nhỏ hơn khi một công cụ hàng đợi được dùng.

- Các hàng đợi phần cứng có chiều dài ngắn có ý nghĩa là các gói tin có thể kiểm soát bằng các phần mềm hàng đợi, cho phép các hàng đợi mềm kiểm soát chặt chẽ hơn lưu lượng đi ra khỏi cổng. Chức năng duy nhất của hàng đợi phần cứng mà ta có thể thao tác là chiều dài của hàng đợi. Hình dưới đây mô tả chiều dài hiện thời của hàng đợi và làm thế nào để thay đổi chiều dài.

Ví dụ bắt đầu bằng kiểu hàng đợi FIFO trên một cổng. Trong ví dụ này, hàng đợi mặc định có chiều dài là 16 bytes.

R3# show controllers serial 0/0
Interface Serial0/0

tx_limited=0(16)
! lines omitted for brevity
! Next, the TX ring is set to length 1.
! (The smallest recommended value is 2.)
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# int s 0/0
R3(config-if)# tx-ring-limit1
R3(config-if)# ^Z

Các cơ chế hàng đợi trên cổng và trên sub-interface

Các công cụ hàng đợi của IOS có thể tạo và quản lý các hàng đợi mềm kết hợp trong một cổng vật lý và sau đó các gói tin chảy vào hàng đợi phần cứng. Thêm vào đó, các hàng đợi phần mềm có thể được dùng kết hợp với công cụ định dạng lưu lượng shaping. Các công cụ định dạng lưu lượng (shaping) có thể làm chậm gói tin để đảm bảo rằng một nhóm các gói tin không vượt quá tốc độ định nghĩa. Khi làm chậm gói tin, chức năng định dạng lưu lượng sẽ xếp hàng các gói, mặc định theo kiểu FIFO. Tùy thuộc vào kiểu công cụ định hình lưu lượng được dùng, các hàng đợi khác nhau có thể được cấu hình để quản lý độ trễ của các gói tin gây ra bởi công cụ shaping.
<o:p> </o:p>
So sánh các công cụ hàng đợi:

Cisco IOS cung cấp nhiều công cụ hàng đợi. Bảng dưới đây sẽ tóm tắt các đặc điểm chính của các công cụ hàng đợi khác nhau.

Khi ta khảo sát các cơ chế hàng đợi, ta cần xem xét cách thức phân loại mà cơ chế hàng đợi này dùng, chính sách loại bỏ gói tin khi tất cả các hàng đợi đều đã đầy, phần định thời được dùng để giải phóng gói tin. Ta cũng cần phân tích số hàng đợi tối đa được hỗ trợ trong mỗi cơ chế và chiều dài tối đa của mỗi hàng đợi.

Các công cụ hàng đợi FIFO, PQ, CQ, WFQ, CBWFQ, và LLQHàng đợi FIFO:

Nguyên nhân chủ yếu cho việc dùng giải pháp hàng đợi là một router cần giữ một gói tin trong bộ nhớ khi cổng ra của router đang bận gửi một gói tin khác. Cơ chế FIFO đơn giản sẽ cung cấp một hàng đợi mềm để lưu tạm gói tin khi gói tin đang chờ đi ra khỏi một cổng. Các gói tin được định thời để rời khỏi cổng dựa trên thời điểm mà nó đến cổng ra của router. Bởi vì router mặc định dùng WFQ trên cổng serial với băng thông nhỏ hơn mức E1 (2.048Mbps), do đó để cấu hình FIFO, ta chỉ cần tắt WFQ hoặc bất kỳ các cơ chế hàng đợi nào đang dùng trên cổng.

Cài đặt duy nhất cho cơ chế hàng đợi FIFO là gán chiều dài hàng đợi dùng lệnh hold-queue x out trong đó x là chiều dài tối đa của hàng đợi. Ví dụ dưới đây sẽ mô tả cách cấu hình và cách xem hàng đợi FIFO.

! Dưới đây cấu hình FIFO bằng cách tắt WFQ

R3# conf t
R3(config)# interface s0/0
R3(config-if)# no fair-queue
R3(config-if)#exit

Khi hiển thị thông số của cổng, hàng đợi được dùng là FIFO, chiều dài tối đa là 40.

R3#show int s0/0
Serial0/0 is up, line protocol is up
! lines omitted for brevity
Queueing strategy: fifo
Output queue: 0/40 (size/max)

Ryta

22-04-2010, 10:25

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="Edit-Time-Data" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_editdata.mso"><link rel="themeData" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"> <m:smallfrac m:val="off"> <m:dispdef> <m:lmargin m:val="0"> <m:rmargin m:val="0"> <m:defjc m:val="centerGroup"> <m:wrapindent m:val="1440"> <m:intlim m:val="subSup"> <m:narylim m:val="undOvr"> </m:narylim></m:intlim> </m:wrapindent><style>  </style> Hàng đợi ưu tiên (Priority Queuing):

Điểm khác biệt lớn nhất của PQ là trong phần định thời của nó. PQ định thời lưu lượng sao cho các hàng đợi mức cao luôn luôn được phục vụ trước. PQ dùng bốn hàng đợi, có tên là cao, vừa, bình thường và thấp.
Cơ chế định thời của PQ có vài ưu điểm và nhược điểm rõ ràng. Các gói tin trong hàng đợi ưu tiên cao sẽ nhận mức dịch vụ tuyệt vời. Loại lưu lượng này có thể chiếm 100% băng thông của kết nối và có độ trễ tối thiểu. Tuy nhiên, khi cổng của router đã trở nên bị nghẽn, các hàng đợi có độ ưu tiên thấp hơn sẽ chịu hiện tượng hàng đợi chết, không có băng thông với thời gian delay tăng cao.

Mặc dù phần định thời là phần hay nhất của PQ, cơ chế PQ cũng còn nhiều đặc tính khác. PQ phân loại các gói tin vào bốn hàng đợi thông qua các cách phân loại bao gồm tham chiếu đến IP ACLs. Tuy nhiên, PQ hỗ trợ các tuỳ chọn phân loại ít hơn các cơ chế hàng đợi CBWFQ và LLQ.

PQ dùng cơ chế loại bỏ cuối hàng tail-drop, vì vậy khi một gói tin mới đến một hàng đợi và hàng đợi này bị đầy, gói tin mới sẽ bị loại bỏ. Chiều dài của hàng đợi có thể cấu hình đến các mức khác nhau, với gía trị mặc định là 20, 40, 60, 80 tương ứng với các hàng đợi cao, vừa, bình thường và thấp.
<o:p> </o:p>
Custom Queuing:

Kiểu hàng đợi CQ giải quyết trở ngại lớn nhất của PQ bằng cách cung cấp một băng thông tối thiểu đến từng hàng đợi vì vậy CQ tránh được hiện tượng hàng đợi bị chết. CQ có 15 hàng đợi, mặc định cho 16 nhóm lưu lượng khác nhau. Cũng có một hàng đợi ẩn dành cho các lưu lượng quan trọng gọi là hàng đợi hệ thống system queue. Ta không thể cấu hình để thay đổi hay để tắt hàng đợi hệ thống system queue.

Khía cạnh tiêu cực của cơ chế CQ khi so sánh với PQ là việc thiếu một hàng đợi có độ ưu tiên cao luôn luôn được phục vụ trước các hàng đợi khác. CQ không có cách nào để đảm bảo một dịch vụ có độ trễ thấp cho một loại lưu lượng nào đó. Bộ phận định thời của CQ dành ra một phần đáng kể của băng thông cho từng hàng đợi, nhưng thay vì cấu hình tỉ lệ phần trăm thực sự, CQ chỉ ước lượng tỉ lệ phần trăm dùng một thuật toán đơn giản.

Bytecount: số bytes tối đa mà router xử lý cho từng hàng đợi.
Counter: là số bytes mà router đã xử lý cho một hàng đợi.

Cơ chế định thời của CQ thực hiện theo kiểu xoay vòng round-robin trên mỗi hàng đợi, bắt đầu với hàng đợi 1. CQ sẽ nhận gói tin từ hàng đợi, cho đến khi nào đạt được hoặc vượt quá tổng số bytes chỉ định cho một hàng đợi. Chỉ số này gọi là byte-count. Sau khi hàng đợi đã được phục vụ (xử lý) cho một số bytes xác định, hoặc khi hàng đợi không còn gói tin nào, CQ sẽ chuyển sang hàng đợi kế tiếp và tiếp tục lặp lại tiến trình.

CQ không có hàng đợi nào có độ ưu tiên ngầm định mà đơn giản chỉ có tỉ lệ băng thông ngầm định. Thật ra, nếu có một hàng đợi có thể được cấu hình với số byte count chiếm 60% băng thông kết nối, và nếu 90% các loại lưu lượng đi vào hàng đợi đó, bạn có thể cho rằng hàng đợi đó là loại ưu tiên thấp. Có nghĩa là lúc này loạI lưu lượng nêu trên sẽ phải chờ các loại lưu lượng kia được xử lý trước.

Bảng dưới đây hiển thị hai ví dụ trong đó băng thông được gán đến từng hàng đợi. Chú ý rằng nếu vài hàng đợi trong số tổng cộng 16 hàng đợi không được cấu hình, các hàng đợi này đơn giản sẽ bị bỏ qua.

Tỉ lệ phần trăm băng thông trong bảng trên được tính như sau:
Số byte count cho một hàng đợi X/ Tổng sổ byte count cho tất cả các hàng đợi.

Giống như trong PQ, phần định thời là phần thú vị nhất trong cơ chế CQ. CQ dùng cùng cơ chế phân loại và dùng cơ chế loại bỏ gói tin ở cuối hàng taildrop. Bởi vì không có hàng đợi nào tốt hơn hàng đợi nào, mặc định CQ dùng hàng đợi có chiều dài 20 gói tin.

Hàng đợi theo trọng số (Weighted Fair Queuing - WFQ):

WFQ khác với PQ và CQ ở vài điểm. Sự khác biệt lớn nhất là WFQ không cho phép người quản trị can thiệp vào quá trình phân loại lưu lượng. WFQ tự động phân loại các gói tin dựa trên thông tin về dòng lưu lượng, trong đó từng dòng sẽ được đặt trong một hàng đợi riêng lẽ. Một dòng được định nghĩa bao gồm tất cả các gói tin có cùng giá trị như:

- Địa chỉ IP nguồn.
- Địa chỉ IP đích.
- Giao thức lớp transport.
- Địa chỉ cổng nguồn TCP hay UDP.
- Địa chỉ cổng đích TCP/UDP
- Giá trị độ ưu tiên của gói tin IPP (IP Precedence).

Bởi vì WFQ phân các gói tin vào các dòng lưu lượng khác nhau và sau đó đưa các dòng này vào trong những hàng đợi khác nhau, router sẽ có số hàng đợi khác nhau. Số hàng đợi này nhiều hơn bất kỳ các công cụ hàng đợi khác (tức là các công cụ hàng đợi không xử lý theo dòng lưu lượng). Cơ chế định thời của WFQ dùng các thuật toán hoàn toàn khác với các thuật toán của các công cụ hàng đợi khác ở điểm nó có thể quản lý một số lượng lớn các hàng đợi. Tuy nhiên, mục đích tổng thể của WFQ là rất dễ hiểu và được tóm tắt như sau:

- Các dòng có cùng độ ưu tiên IPP của gói tin IP sẽ được cấp cùng một mức băng thông, bất chấp có bao nhiêu byte trong mỗi dòng lưu lượng.
- Đối với những dòng có những giá trị IPP khác nhau, các dòng có độ ưu tiên IPP cao hơn sẽ được cấp một lượng băng thông cao hơn.
- Kết quả là WFQ sẽ ưu tiên cho những dòng có dung lượng nhỏ và có độ ưu tiên cao.

Giả sử, nếu WFQ đang quản lý mười hàng đợi với các giá trị IPP bằng nhau trên một cổng 128 kbps, mỗi dòng lưu lượng sẽ nhận được khoảng băng thông bình quân 12.8 kbps. Các hàng đợi sẽ làm cho những dòng lưu lượng lớn hơn 12.8 kbps, nghĩa là bị trễ (delay) nhiều hơn. Các dòng có băng thông nhỏ hơn 12.8 kbps sẽ truyền đi nhanh hơn và trong trường hợp các hàng đợi là trống thì WFQ sẽ cấp phần băng thông dư cho những hàng đợi khác. Kết quả là các dòng lưu lượng thấp sẽ đi qua, còn dòng lưu lượng cao sẽ bị ảnh hưởng.

Mục đích thứ hai của WFQ là cung cấp đủ băng thông cho các dòng lưu lượng có độ ưu tiên IPP cao. Để làm điều này, các dòng được gán trọng số dựa theo giá trị IPP + 1. Nói cách khác, các dòng có độ ưu tiên IPP bằng 7 sẽ có băng thông nhiều hơn tám lần so với dòng có độ ưu tiên IPP bằng 0, bởi vì (7+1)/(0+1)=8. Một ví dụ khác, nếu so sánh dòng có độ ưu tiên 3 với độ ưu tiên 0, tỉ lệ băng thông được cấp phát là (3+1)/(0+1)=4.

Tiến trình định thời WFQ

Để đạt được mục đích cấp phát băng thông, WFQ dùng bộ định thời khá đơn giản. Bộ định thời sẽ lấy gói tin có chỉ số tuần tự thấp nhất sequence number SN (còn gọi là thời gian hoàn thành finish time) khi nó cần chuyển gói tin kế tiếp đến hàng đợi phần cứng.

Cơ chế WFQ sẽ gán mỗi gói tin một chỉ số tuần tự SN khi gói tin đi vào hàng đợi WFQ. Tiến trình gán chỉ số tuần tự SN cũng là một phần quan trọng trong cơ chế định thời của WFQ. Bộ định thời WFQ sẽ tính toán chỉ số tuần tự SN dựa trên nhiều thông số của dòng lưu lượng, bao gồm cả chiều dài và độ ưu tiên IPP của gói tin.

Công thức tính chỉ số tuần tự SN của một gói tin trong một dòng lưu lượng là như sau:
SN= chỉ số SN trước đó + (trọng số weight * chiều dài gói tin mới).

Trong đó trọng số được tính như sau:
Weight = 32384 / (IP_Precedence + 1)

Công thức trên có tham chiếu đến chiều dài của gói tin mới, trọng số của dòng lưu lượng và giá trị SN trước đó.

Bằng cách xem xét chiều dài gói tin, việc tính toán chỉ số tuần tự SN có thể dẫn đến một chỉ số SN rất cao cho những gói tin có kích thước lớn và chỉ số tuần tự SN thấp hơn cho những gói tin có kích thước nhỏ hơn. Với việc bao gồm luôn chỉ số tuần tự SN của gói tin trước đó trong hàng đợi, công thức này sẽ tính ra chỉ số SN lớn hơn cho những gói tin trong hàng đợi đã có một số lượng lớn gói tin.

Bằng cách gán trọng số (IPP+1), các gói tin các độ ưu tiên IPP cao sẽ có kết quả SN thấp hơn.

Hình dưới đây sẽ mô tả hai gói tin được gán hai chỉ số tuần tự như thế nào. Tính toán chỉ số tuần tự SN của một gói tin thì dễ dàng. Tuy nhiên gói tin đầu tiên trong một dòng lưu lượng nào đó thì không có chỉ số tuần tự SN của gói tin trước đó để dùng trong công thức tính toán trên. Công thức mô tả rằng chỉ số tuần tự SN của gói tin cuối cùng được đưa vào hàng đợi cứng thì được dùng như là chỉ số tuần tự SN cho dòng mới theo sau.

Sau khi các chỉ số tuần tự SN đã được gán, còn lại, công việc chọn gói tin nào để giải phóng của bộ định thời trở nên đơn giản. Nó sẽ lấy gói tin có chỉ số SN thấp nhất giữa tất cả các hàng đợi.</m:defjc></m:rmargin></m:lmargin></m:dispdef></m:smallfrac>

Ryta

22-04-2010, 10:27

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="themeData" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"> <m:smallfrac m:val="off"> <m:dispdef> <m:lmargin m:val="0"> <m:rmargin m:val="0"> <m:defjc m:val="centerGroup"> <m:wrapindent m:val="1440"> <m:intlim m:val="subSup"> <m:narylim m:val="undOvr"> </m:narylim></m:intlim> </m:wrapindent><style>  </style> Chính sách loại bỏ gói tin của WFQ, số hàng đợi và chiều dài hàng đợi:

Trong hoạt động của router, mặc dù đã đưa các lưu lượng vào các hàng đợi tương ứng, nhưng nếu lưu lượng đi qua router vẫn tiếp tục tăng cao, bắt buộc router sẽ phải tiến hành việc loại bỏ bớt gói tin để giảm bớt nghẽn. WFQ dùng tiến trình hai bước gọi là loại bỏ cuối hàng có bổ sung (modified tail drop) để chọn lựa khi nào thì loại bỏ gói tin. Theo tên gọi, tiến trình này khác vớI tiến trình loạI bỏ cuốI hàng thông thường.

Đầu tiên, WFQ sẽ xem xét giới hạn tuyệt đối của tất cả các gói tin trong hàng đợi giữa tất cả các hàng đợi, giới hạn này gọi là hold-queue limit. Nếu một gói tin đến hàng đợi và giới hạn hold-queue đã tới, gói tin sẽ bị loại bỏ. Quyết định đó không dựa trên một hàng duy nhất nhưng trên toàn hệ thống hàng đợi của WFQ. Nói cách khác, giới hạn hold-queue này là một chỉ số toàn cục, được tính toán tổng thể giữa các hàng đợi WFQ.

Thứ hai là WFQ sẽ xem xét chiều dài của một hàng đợi mà trong đó những gói tin sẽ được đưa vào. Trước khi đưa một gói tin vào hàng đợi, mức ngưỡng congestive discard threshold (CDT) sẽ được kiểm tra với chiều dài thực sự của hàng đợi đó. Nếu hàng đợi là dài hơn CDT, một gói tin sẽ bị loại bỏ, nhưng có thể không phải là những gói tin mới đến. Gói tin có chỉ số tuần tự cao nhất trong tất cả các hàng đợi của WFQ sẽ bị loại bỏ.

Những gói tin vừa đến sẽ đi qua tiến trình này, nhưng trong một nhánh của thuật toán, gói tin mới đến sẽ không bị loại bỏ, thay vào đó, một gói tin khác trong một hàng đợi khác sẽ bị loại bỏ. Một cách cơ bản, nếu gói mới đến cần phải đi vào một hàng đợi đã vượt quá CDT, WFQ sẽ loại bỏ gói tin có chỉ số tuần tự cao nhất từ bất kỳ hàng đợi nào. Giá trị CDT phải gán bằng bội số của 2. IOS sẽ không chấp nhận bất kỳ giá trị nào khác.

Các kiểu hàng đợi WFQ:

WFQ có thể được cấu hình dùng tối đa 4096 hàng đợi, gọi là dynamic queue trong kết quả của lệnh show. Mỗi khi có một dòng lưu lượng, router sẽ tạo ra một dynamic queue để truyền dòng lưu lượng trên. Khi xử lý xong một dòng lưu lượng, hàng đợi đó sẽ bị huỷ. Một điều thú vị là các giá trị có thể cấu hình được là bội số của 2, nằm trong khoảng từ 16 đến 4096. IOS giới hạn các giá trị này bởi vì WFQ thực hiện một thuật toán hash để phân loại traffic và thuật toán hash chỉ hoạt động khi số hàng đợi là một trong những giá trị này.

Thêm vào đó, WFQ giữ tám hàng đợi ẩn cho các lưu lượng được tạo ra bởi router. WFQ dùng một mức trọng số rất thấp cho các hàng đợi này để ưu tiên cho các các lưu lượng của hệ thống. Ngoài ra, có một vài hàng đợi trong số 4096 hàng đợi có thể được dùng bởi Resource Reservation Protocols (RSVP) để giữ băng thông. RSVP dùng các báo hiệu để giữ phần băng thông tối thiểu cho những dòng lưu lượng đặc biệt trong một hệ thống mạng, dựa chủ yếu vào các công cụ hàng đợi để thực sự hiện thực được tính năng giữ băng thông. WFQ, CBWFQ, và LLQ hỗ trợ RSVP.

Cấu hình WFQ:

WFQ yêu cầu rất ít cấu hình, thật ra nó được bật ở chế độ mặc định trên những cổng có băng thông từ mức E1 trở xuống. Vì vậy, với cấu hình mặc định, WFQ không yêu cầu lệnh cấu hình gì thêm. Bảng dưới đây liệt kê các lệnh liên quan đến WFQ. Điểm đặc biệt là, lệnh fair-queue cho phép gán giá trị CDT, số hàng đợi và số hàng RSVP. Còn lệnh hold-queue chỉ ra số gói tin cho phép trong tất cả các hàng đợi trên cổng.

Ví dụ dưới đây mô tả một cấu hình cơ bản cùng với cách dùng lệnh show. Để cấu hình WFQ, lệnh fair-queue sẽ được dùng và không cần thêm thông số nào; lệnh hold-queue cũng không cần thiết. Trong ví dụ này, giá trị ngưỡng CDT sẽ được gán bằng 100, số hàng đợi bằng 64, số hàng đợi RSVP là 10 và giới hạn kích thước hàng đợi holdqueue là 500.

R3# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# int s 0/0
R3(config-if)# fair-queue 100 64 10
R3(config-if)# hold-queue 500 out
R3(config-if)# ^Z

Kết quả dưới đây không phản ánh các thuật ngữ WFQ tiêu biểu trong một vài trường hợp. Chỉ số max total là kích thước hàng đợi holdqueue, “threshold” là CDT và “size” là số gói tin thực sự trong hàng đợi ở thời điểm đó.

R3# show interface serial 0/0
Serial0/0 is up, line protocol is up
!lines omitted for brevity
Queueing strategy: weighted fair
Output queue: 95/500/100/12474 (size/max total/threshold/drops)
Conversations 5/6/64 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec

Dưới đây là các chi tiết cấu hình cho VoIP flow, với các thống kê cho kích thước hàng đợi và các trọng số. Trọng số được liệt kê là 5397, là kết quả các phép tính (32,384 / ((IPP of 5) + 1)).

R3# sh queue s 0/0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 13567
Queueing strategy: weighted fair
Output queue: 125/500/100/13567 (size/max total/threshold/drops)
Conversations 5/7/64 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 61/5397/654/0/0
Conversation 61, linktype: ip, length: 64
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0134, ttl: 253,
TOS: 184 prot: 17, source port 16638, destination port 19476
! lines omitted for brevity

Lệnh show thú vị nhất cho WFQ là lệnh show queue. Trong kết quả của lệnh này, sẽ có phần tóm tắt trước, theo sau là một kết quả của từng dòng. Chi tiết của từng dòng và thống kê được hiển thị như trên.

Khi một dòng lưu lượng đã truyền xong, hàng đợi cho dòng đó sẽ bị hủy. Dưới đây là một ví dụ khác của lệnh show queue s0/0

R3#sh queue s 0/0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 13567
Queueing strategy: weighted fair
Output queue: 125/500/100/13567 (size/max total/threshold/drops)
Conversations 5/7/64 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 61/5397/654/0/0
Conversation 61, linktype: ip, length: 64
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0134, ttl: 253,
TOS: 184 prot: 17, source port 16638, destination port 19476

(depth/weight/total drops/no-buffer drops/interleaves) 61/5397/653/0/0
Conversation 15, linktype: ip, length: 64
source: 192.168.3.254, destination: 192.168.2.251, id: 0x013B, ttl: 253,
TOS: 184 prot: 17, source port 16772, destination port 19232

(depth/weight/total drops/no-buffer drops/interleaves) 1/10794/15/0/0
Conversation 34, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0x00A5, ttl: 127,
TOS: 88 prot: 6, source port 80, destination port 1068

(depth/weight/total drops/no-buffer drops/interleaves) 1/10794/15/0/0
Conversation 33, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0x00A7, ttl: 127,
TOS: 72 prot: 6, source port 80, destination port 1067

(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/12/0/0
Conversation 29, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0x00A1, ttl: 127,
TOS: 0 prot: 6, source port 1353, destination port 1065
<o:p> </o:p>
Class-Based WFQ và Low-Latency Queuing (LLQ):

Cisco tạo ra CBWFQ và LLQ, sử dụng các khái niệm từ PQ, CQ và WFQ và có thêm vào vài đặc điểm khác. CBWFQ dành riêng băng thông cho từng hàng đợi và dùng khái niệm WFQ cho các gói tin trong lớp mặc định. LLQ thêm vào trong CBWFQ khái niệm hàng đợi ưu tiên, nhưng không giống như PQ, LLQ ngăn các hàng đợi có độ ưu tiên cao khỏi việc bị rơi vào trạng thái chết. Thêm vào đó, cả CBWFQ và LLQ đều dùng cú pháp tổng quát của MQC khi cấu hình, có nghĩa là nó có các tuỳ chọn phân loại mạnh, bao gồm cả NBAR. CBWFQ và LLQ dùng cấu hình tương tự nhau, sự khác nhau nằm ở chổ câu lệnh bandwidth hay câu lệnh priority được dùng.

Bởi vì các hai công cụ đều dùng MQC, cả hai sẽ dùng class-map để phân loại và dùng policy map để tạo ra một tập hợp các nhóm lưu lượng để dùng trên một cổng. Các lớp định nghĩa trong policy map sẽ dùng một hàng đợi. Kết quả là, thuật ngữ hàng đợi và class thường thường dùng qua lại khi làm việc với LLQ và CBWFQ. Nghĩa là, ta có thể ám chỉ đến một lớp lưu lượng nào đó bằng cả thuật ngữ queue hay class.

CBWFQ và LLQ hỗ trợ 64 hàng đợi hoặc classes. Chiều dài hàng đợi tối đa có thể thay đổi, với giá trị tối đa và chiều dài mặc định thay đổi dựa theo kiểu của router và tổng số bộ nhớ được dùng. Cả hai đều có một hàng đợi đặc biệt gọi là hàng đợi mặc định. Hàng đợi này tồn tại ngay cả khi nó không được cấu hình. Nếu một gói tin không thuộc về nhóm nào được cấu hình trong một policy map, IOS sẽ đặt gói tin và hàng mặc định. CBWFQ có thể được cấu hình cho nhóm mặc định.</m:defjc></m:rmargin></m:lmargin></m:dispdef></m:smallfrac>

Ryta

22-04-2010, 10:29

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="Edit-Time-Data" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_editdata.mso"><link rel="themeData" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"> <m:smallfrac m:val="off"> <m:dispdef> <m:lmargin m:val="0"> <m:rmargin m:val="0"> <m:defjc m:val="centerGroup"> <m:wrapindent m:val="1440"> <m:intlim m:val="subSup"> <m:narylim m:val="undOvr"> </m:narylim></m:intlim> </m:wrapindent><style>  </style> Các đặc điểm cơ bản và cách cấu hình CBWFQ:

Bộ phận định thời CBWFQ đảm bảo một tỉ lệ tối thiểu của băng thông đến từng hàng đợi. Nếu tất cả các hàng đợi có một số lượng lớn gói tin, mỗi hàng đợi sẽ nhận phần trăm băng thông ngầm định bởi cấu hình. Tuy nhiên, nếu một vài hàng đợi là trống và các hàng đợi này không có nhu cầu băng thông trong một khoảng thời gian ngắn, băng thông được cấp phát tương ứng với các nhóm lưu lượng khác.
Các lệnh tham khảo cho CBWFQ:
Dưới đây là một cấu hình CBWFQ đơn giản dùng hàng đợi cho class-default. Cấu hình được tạo ra trên R3 dùng các yêu cầu sau:

- Tất cả các gói VoIP sẽ được đặt trên một hàng đợi.
- Tất cả các loại lưu lượng khác sẽ đặt trong hàng đợi khác.
- VoIP sẽ có 50% băng thông.
- WFQ sẽ dùng cho những lưu lượng không phải là VoIP
Lệnh class map sẽ lựa ra các gói tin UDP/RTP và các cổng RTP.

class-map match-all voip-rtp
match ip rtp 16384 16383

Kế tiếp, lệnh policy-map dùng lệnh băng thông bandwidth để giữ 64Kbps cho lớp lưu lượng voip-rtp này. Lớp mặc định sẽ nhận một vài phần băng thông còn lại.

policy-map queue-voip
class voip-rtp
bandwidth 64
class class-default
fair-queue

Lệnh bandwidth 128 cấu hình ở cổng được dùng như mức cơ bản cho giới hạn tổng số băng thông có thể được cấp phát trong chính sách policy map queue-voip. Lệnh load-interval sẽ gán các bộ đếm được cập nhật như thế nào. Ngoài ra, chú ý rằng lệnh policy map được áp dụng cho lưu lượng theo chiều ra, lưu lượng theo chiều vào không được áp dụng chính sách này.

interface Serial0/0
encapsulation frame-relay
load-interval 30
bandwidth 128
service-policy output queue-voip

Lệnh dưới đây liệt kê các thống kê, phần băng thông dành riêng, kích thước tối đa của hàng đợi (chỉ ra như max threshold) và một lưu ý WFQ được dùng trong hàng đợi lớp mặc định.

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 64 (kbps) 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
! This command just lists the configuration in a concise manner.

R3# show policy-map
Policy Map queue-voip
Class voip-rtp
Weighted Fair Queueing
Bandwidth 64 (kbps) Max Threshold 64 (packets)
Class class-default
Weighted Fair Queueing
Flow based Fair Queueing Max Threshold 64 (packets)
<o:p> </o:p>
Định nghĩa và giới hạn băng thông trong cơ chế CBWFQ:

Cisco IOS kiểm tra một chính sách CBWFQ để đảm bảo rằng nó không cấp quá nhiều băng thông. IOS bắt đầu thực hiện việc kiểm tra ngay khi câu lệnh service-policy output được nhập vào. Nếu chính sách policy map định nghĩa quá nhiều băng thông cho cổng đó, lệnh service policy sẽ bị từ chối. IOS định nghĩa băng thông cho phép dựa trên hai lệnh: lệnh bandwidth và lệnh max-reserved-bandwidth (viết tắt là int-bw và max-res). Các phần băng thông còn lại là dành cho các lưu lượng của hệ thống như các hàng đợi của hệ thống. Nói cách khác, với giá trị max-res bằng 75 (75%) trên một cổng có băng thông là int-bw 256, một policy map có thể cấp đến 192 kbps với các lệnh băng thông của nó.

Ví dụ dưới đây mô tả một chính sách trong đó có một nhóm lưu lượng được cấp đến 64 kbps băng thông. Lệnh service-policy bị IOS từ chối trên những IOS có băng thông gán bằng 64kbps. Giá trị max-res được gán mặc định bằng 75, vì vậy chỉ có 75% của 64kbps tức là 48 kbps là có sẵn. Chú ý rằng giá trị 48 kbps được đề cập trong thông điệp lỗi.

[I]R3(config-cmap)# policy-map explicit-bw
R3(config-pmap)# class class1
R3(config-pmap-c)# bandwidth 64
R3(config-pmap-c)# int s0/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)

Để khắc phục vấn đề trên, ta có thể chú ý đến các chi tiết và đảm bảo rằng câu lệnh bandwidth được cấu hình để chỉ ra mức băng thông không được vượt quá giá trị max-res * int-bw. Hoặc nếu không, max-res có thể được định nghĩa đến một giá trị cao hơn 100. Tuy nhiên, Cisco không khuyến cáo tác vụ thay đổi giá trị max-res này.

Băng thông cũng có thể được định nghĩa như là tỉ lệ phần trăm dùng câu lệnh bandwidth percent hoặc bandwidth remaining percent. Khi chia băng thông theo tỉ lệ phần trăm, ta có thể đảm bảo băng thông không bị cấp vượt quá mức. Hai tùy chọn theo tỉ lệ phần trăm trong câu lệnh bandwidth có tác dụng khác nhau. Hình dưới đây mô tả các khái niệm này.
Lệnh bandwidth percent bw-percent gán băng thông cho một lớp lưu lượng theo tỉ lệ phần trăm của thông số int-bw. Ví dụ trong hình trên, nếu lệnh bandwidth percent 50 đã được dùng thay cho câu lệnh bandwidth 64, lớp lưu lượng voip-rtp sẽ dùng 50% * 128 kbps, tức là 64 Kbps. IOS sẽ kiểm tra tất cả các câu lệnh bandwidth percent trong một policy map để đảm bảo rằng băng thông không vượt quá giá trị max-res cho cổng. Nói cách khác, nếu dùng giá trị mặc định cho thông số max-res, tất cả các câu lệnh bandwidth percent trong một policy map sẽ không thể có tổng lớn hơn 75.

Lệnh bandwidth remaining percent bw-percent gán băng thông dành cho một nhóm trên tỉ lệ phần trăm của phần băng thông còn lại. Thông số phần băng thông còn lại remaining bandwidth sẽ là 75%*128kbps, hoặc là 96 kbps. Khi này, lệnh bandwidth remaining percent 50 sẽ cấp một phần băng thông là 48Kbps cho một nhóm lưu lượng nào đó. Lệnh bandwidth remaining percent đặc biệt rất hữu ích khi dùng với LLQ. Lý do là phần băng thông còn lại bị thay đổi khi dùng với LLQ.

Chú ý rằng trong một policy map, chỉ có một trong ba biến thể của câu lệnh bandwidth có thể được dùng. Bảng dưới đây tóm tắt ba phương thức được dùng để cấp băng thông dùng CBWFQ.
Cơ chế hàng đợi có độ trễ thấp LLQ (Low-Latency Queuing)

Nếu chỉ căn cứ theo tên gọi, cơ chế hàng đợi LLQ có vẻ như là công cụ hàng đợi tốt nhất có thể. Những loại gói tin nào không muốn bị ảnh hưởng bởi độ trễ? Đối với những ứng dụng cần độ trễ thấp, LLQ là chọn lựa tốt. LLQ tìm kiếm và hành động giống như CBWFQ trên hầu hết mọi phương diện, ngoài trừ yếu tố là LLQ cho phép một số hàng đợi hoạt động như các hàng đợi có độ trễ thấp. LLQ định thời các hàng đợi này như là các hàng đợi có độ ưu tiên cao, giống như PQ. Nói cách khác, LLQ luôn cố gắng phục vụ các gói tin trong những hàng đợi này trước.

LLQ thỉnh thoảng có thể dùng trong một số hình thức khác nhau. Nếu một chính sách policy map có ít nhất một LLQ, chính sách policy map đó có thể xem như đang hiện thực LLQ, và hàng đợi đó được gọi là LLQ. Thỉnh thoảng, một hàng đợi LLQ còn được gọi là PQ vì đặc tính hoạt động giống PQ.

Khi LLQ thêm vào một hàng đợi có độ trễ thấp vào cơ chế CBWFQ, nó cũng giúp ngăn ngừa hiện tượng hàng đợi chết của PQ. LLQ thực sự khống chế hàng đợi dựa trên băng thông được cấu hình. Thực sự, mức băng thông cấp cho một hàng đợi LLQ sẽ vừa là mức băng thông đảm bảo tối thiểu, vừa là mức băng thông tối đa.
Kết quả là, các gói tin có thể được giải phóng khỏi hàng đợi để có độ trễ thấp nhưng sẽ có vài gói tin bị loại bỏ để ngăn ngừa các hàng đợi khác rơi vào trạng thái chết vì không được xử lý.

Hình dưới đây mô tả thuật toán hoạt động của LLQ. Chú ý rằng mặc dù có một thành phần chạy theo thuật toán PQ là được hiển thị, nhưng thành phần này cũng bị khống chế về băng thông.
Cấu hình LLQ đòi hỏi thêm vào một số lệnh bên cạnh các lệnh được dùng để cấu hình CBWFQ. Thay vì dùng câu lệnh bandwidth trong một class, lệnh priority sẽ được dùng.

priority { bandwidth-kbps | percent percentage} [ burst]

Lệnh này bật LLQ trong một lớp lưu lượng, cung cấp băng thông cho lớp đó và bật chức năng policing. Bạn cũng có thể cấu hình chỉ ra phần lưu lượng bùng nổ burst size đi kèm với tính năng khống chế băng thông policing. Ỏ chế độ mặc định, mức chỉ định 20% của băng thông được cấu hình là một chọn lựa hợp lý. Ví dụ dưới đây mô tả một cấu hình LLQ mẫu, dùng các tiêu chuẩn giống như ví dụ trước. Các chính sách LLQ được áp dụng vào cổng S0/0 của R3.

- Băng thông của cổng S0/0 là 128 kbps.
- Các gói tin đã được đánh dấu với giá trị DSCP tốt.
- Tải của VoIP đã được đánh dấu giá trị DSCP EF và sẽ được đưa vào hàng đợi LLQ với băng thông là 58kbps.
- Các lưu lượng có giá trị AF41, AF21 và AF23 sẽ được cấp phần băng thông tương ứng là 22, 20 và 8 kbps.
- Tất cả những traffic còn lại sẽ được đặt vào hàng đợi mặc định, và sẽ dùng cơ chế WRED và WFQ.

Lệnh class map được dùng bởi hàng đợi queue-on-dscp không được mô tả nhưng cái tên này ngầm định rằng từng class map đã được cấu hình để so sánh. Chú ý câu lệnh priority 58 sẽ làm cho lớp dscp-ef là một LLQ.

policy-map queue-on-dscp
class dscp-ef
priority 58
class dscp-af41
bandwidth 22
class dscp-af21
bandwidth 20
random-detect dscp-based
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
! max-res has to be raised or the policy map would be rejected.
interface Serial0/0
bandwidth 128
encapsulation frme-relay
load-interval 30
max-reserved-bandwidth 85
service-policy output queue-on-dscp

Dưới đây, đối với lớp dscp-ef, chú ý thuật ngữ “strict priority” cũng như việc tính toán ra giá trị bùng nổ dữ liệu ở mức 1450 bytes (là 20% của 58 kbps và chia cho 8 để chuyển thông số trên về đơn vị là số bytes).

R3# show policy-map queue-on-dscp
Policy Map queue-on-dscp
Class dscp-ef
Weighted Fair Queueing
Strict Priority
Bandwidth 58 (kbps) Burst 1450 (Bytes)
! lines omitted for brevity

Chú ý các thống kê dưới đây. Bất kỳ gói tin nào bị loại bỏ do policer sẽ hiển thị trong dòng cuối cùng dưới đây.

R3# show policy-map interface s 0/0 output class dscp-ef
Serial0/0
Service-policy output: queue-on-dscp
Class-map: dscp-ef (match-all)
227428 packets, 14555392 bytes
30 second offered rate 52000 bps, drop rate 0 bps
Match: ip dscp ef
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 58 (kbps) Burst 1450 (Bytes)
(pkts matched/bytes matched) 12194/780416
(total drops/bytes drops) 0/0
Định nghĩa và giới hạn băng thông trong LLQ
Lệnh priority trong LLQ có hai tuỳ chọn để định nghĩa băng thông cho LLQ. Một tùy chọn sẽ chỉ ra băng thông, tùy chọn còn lại là chỉ ra tỉ lệ phần trăm của băng thông (không có tùy chọn remaining bandwidth). Tuy nhiên không giống lệnh bandwidth, cả hai tùy chọn này đều có thể dùng trong cùng một policy. IOS vẫn giới hạn tổng số băng thông bên trong một chính sách LLQ policy map, với phần băng thông từ cả hai LLQ và những nhóm non-LLQ đều không được vượt quá giới hạn max-res*int-bw.

Mặc dù công thức trên là khá dễ, tuy nhiên các chi tiết có thể làm ta nhầm lẫn, đặc biệt là trong tình huống một policy map có một hàng đợi cấu hình với lệnh priority bw, một hàng đợi khác với lệnh priority percent bw và các hàng đợi khác với câu lệnh bandwidth. Hình dưới đây là một ví dụ với ba phiên bản của lệnh. Trong ví dụ có hai phiên bản của lệnh priority, class 3 có lệnh priority 32, dành ra 32 kbps. Class 2 có lệnh priority percent 25, nếu áp dụng vào băng thông của cổng (256Kbps) sẽ cấp cho class 2 một phần băng thông 64Kbps.

Phần thú vị của hình trên là cách mà hệ điều hành IOS tính khái niệm băng thông còn lại (remaining bandwidth) khi PQ được cấu hình. IOS sẽ trừ phần băng thông mà câu lệnh priority đã xin cấp. Kết quả là, một chính sách policy map có thể cấp cho những nhóm lưu lượng không được ưu tiên khác theo tỉ lệ phần trăm của phần băng thông còn lại, với tổng giá trị là 100</m:defjc></m:rmargin></m:lmargin></m:dispdef></m:smallfrac>

Ryta

22-04-2010, 10:30

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="Edit-Time-Data" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_editdata.mso"><link rel="themeData" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5CKIMHOA%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"> <m:smallfrac m:val="off"> <m:dispdef> <m:lmargin m:val="0"> <m:rmargin m:val="0"> <m:defjc m:val="centerGroup"> <m:wrapindent m:val="1440"> <m:intlim m:val="subSup"> <m:narylim m:val="undOvr"> </m:narylim></m:intlim> </m:wrapindent><style>  </style> Cấu hình LLQ với nhiều hơn một hàng đợi ưu tiên PQ

LLQ cho phép nhiều hàng đợi/class được cấu hình như PQ. Điều này dẫn đến câu hỏi “Hàng đợi nào sẽ được phục vụ trước?”. Thật ra, LLQ thực sự đặt các gói tin từ các hàng đợi LLQ vào một hàng đợi bên trong. Vì vậy, các gói tin trong các hàng đợi ưu tiên khác nhau vẫn được phục vụ trước những gói tin trong các hàng đợi không ưu tiên, nhưng nó sẽ được phục vụ dựa trên mà thời gian gói tin đến trong bất kỳ hàng đợi ưu tiên nào.

Vậy tại sao lại dùng nhiều hàng đợi ưu tiên? Câu trả lời là do công cụ khống chế băng thông policing. Khi khống chế băng thông của một lớp ở một mức nào đó và với lớp lưu lượng khác ở mức khác, ta sẽ có nhiều mức hiệu chỉnh khác nhau cho LLQ. Ví dụ nếu hoạch định cho dữ liệu video và voice, ta có thể đặt các loại dữ liệu này vào các hàng đợi LLQ riêng biệt và cả hai loại dữ liệu này sẽ có độ trễ thấp, đồng thời ngăn ngừa dữ liệu video chiếm băng thông của voice và ngược lại.

Các chủ đề linh tinh trong CBWFQ/LLQ

CBWFQ và LLQ cho phép một chính sách policy map cấp hoặc cũng có thể không cấp băng thông đến lớp class-default. Khi lệnh bandwidth được cấu hình ở lớp class-default, lớp này sẽ thật sự giữ phần băng thông tối thiểu đó. IOS sẽ không cho phép lệnh priority trong lớp mặc định class-defaut. Khi lớp mặc định class-default không có cấu hình câu lệnh bandwidth, IOS sẽ cấp bất kỳ phần băng thông còn trống cho tất cả các lớp còn lại. Kết quả là class-default sẽ không có nhiều băng thông trừ khi một lớp được cấu hình một phần băng thông tối thiểu dùng lệnh bandwidth.

Thực tế, một policy map có thể không có các gói tin trong tất cả các hàng đợi ở cùng một thời điểm. Trong trường hợp đó, các hàng đợi có thể nhận nhiều hơn phần băng thông mà nó yêu cầu. Hệ điều hành IOS sẽ cấp các phần băng thông thêm tỉ lệ theo phần băng thông mà mỗi lớp lưu lượng xin.

Cuối cùng, hệ điều hành IOS dùng các hàng đợi chỉ khi có nghẽn xảy ra. IOS xem nghẽn xảy ra khi hàng đợi phần cứng bị đầy và thường điều đó xảy ra khi phần tải mà router chấp nhận thì rất thấp so với tốc độ của kết nối. Vì vậy một router có thể có lệnh service policy out trên một cổng khi LLQ được cấu hình, nhưng LLQ chỉ có thể thực sự được dùng khi hàng đợi phần cứng là đầy.

Tóm tắt cho phần hàng đợi

WFQ có thể dùng trong hàng đợi class-default hoặc trong tất cả các CBWFQ của router 7500. Số hàng đợi trên đã bao gồm các hàng đợi hệ thống.</m:defjc></m:rmargin></m:lmargin></m:dispdef></m:smallfrac>

Powered by vBulletin® Version 4.1.12 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.