Phân loại và đánh dấu trong QoS

[danghoangkhanh]

QoS: Phân loại và đánh dấu

Các trường có thể đánh dấu cho mục đích QoS

Các IP header, LAN trunking header, Framerelay header và ATM cell header đều có ít nhất một trường có thể được dùng cho tiến trình đánh dấu QoS. Phần này sẽ liệt kê ra các trường này, trong đó sẽ tập trung vào IP header, IP Precedence và DSCP.

So sánh IP Precedence và DSCP

RFC791 mô tả định dạng của IP header, bao gồm một trường 10byte được gọi là ToS. Trường ToS này dự định được dùng như một trường đánh dấu một gói tin để các công cụ QoS có thể xử lý. Giá trị ToS được chia ra thành các trường con, với 3 bit cao được định nghĩa như IP Precedence (IPP). Danh sách đầy đủ của các giá trị ToS và IPP được liệt kê trong bảng dưới đây:

Vị trí bit 3 đến bit 6 của ToS bao gồm các trường được được bật on hay off để chỉ ra một mức dịch vụ đặc biệt. Bit cuối cùng (bit 7) không được định nghĩa trong RFC791. Các cờ không được dùng thường xuyên, vì vậy mục đích chính của ToS là để lưu giữ các giá trị độ ưu tiên của gói tin IP.

Một loạt các RFC được gọi là Differentiated Services (DiffServ) ra đời sau. DiffServ cần nhiều hơn 3bit để đánh dấu gói tin, vì vậy DiffServ chuẩn hóa một định nghĩa lại của byte ToS. Byte ToS được đặt tên là trường Differentiated Services (DS) và IPP được thay thế bằng một trường có độ dài 6bit được gọi là Differentiated Services Code Point (DSCP).

Sau đó, RFC 3168 định nghĩa hai bit thứ tự thấp của DS để dùng với thuộc tính Explicit Congestion Notification (ECN). Hình dưới đây mô tả định dạng của giá trị ToS trước và sau khi có định nghĩa DiffServ.

Các công cụ đánh dấu và phân loại C&M thường đánh dấu trường DSCP hoặc IPP bởi vì các gói tin được bảo toàn khi nó được truyền trên mạng. Có một khả năng đánh dấu khác nằm bên trong L2, có nghĩa là thông tin đánh dấu này không được quan tâm nếu nó được truyền đi bởi một tiến trình L3. Như vậy, việc đánh dấu ở mức 2 không thể được triển khai nếu lưu lượng đi xa hơn một hop.

Thiết lập các giá trị DSCP và các thuật ngữ

Có vài DiffServ RFC đề xuất một vài giá trị được dùng trong trường DSCP và các ý nghĩa ngầm định cho những giá trị này. Ví dụ RFC2598 định nghĩa giá trị DSCP bằng 46, với tên là Expedited Forwarding (EF). Theo RFC đó, các gói tin được đánh dấu như EF sẽ được đưa vào hàng đợi ưu tiên sao cho gói tin sẽ bị độ trễ tối thiểu. Nhưng gói tin sẽ chịu những chính sách sao cho lưu lượng của nó không chiếm hết đường truyền và ngăn ngừa những loại lưu lượng khác được truyền khi cổng của router đạt mức ngưỡng. Những giá trị này và các trạng thái QoS được khuyến cáo tương ứng cho từng trạng thái được gọi là trạng thái theo từng chặng Per-Hop Behaviors (PHBs) dùng DSCP. Trong ví dụ vừa nêu trước đây, trạng thái được gọi là EF PHB.

Class Selector PHB và giá trị DSCP

Thông số IPP bị chồng lấp với ba bit đầu tiên của trường DSCP bởi vì các trường DS chỉ đơn giản là một cách diễn dịch khác của giá trị DSCP ban đầu. Do có sự chồng lấp này, RFC 2475 định nghĩa một tập hợp các giá trị DSCP và PHBs, được gọi là Class Selector (CS) PHBs, trong đó cung cấp các tính tương thích ngược với thông số IPP. Một công cụ đánh dấu và phân loại C&M có thể gán giá trị DSCP và nếu một router khác chỉ xem giá trị IPP, router đó vẫn có thể diễn dịch được giá trị IPP của gói tin. Bảng dưới đây liệt kê các trường của CS DSCP, tên, giá trị và các tên, giá trị tương ứng bên IPP.

Bên cạnh việc định nghĩa tám giá trị DSCP và các tên của nó, cơ chế xử lý theo từng trạm CS PHB cũng đề xuất một tập hợp của các hành động QoS nên được thực hiện trên các giá trị CS này. Cơ chế này chỉ ra rằng các gói tin với giá trị CS DSCP lớn hơn phải được dùng các hàng đợi ưu tiên hơn các gói tin với giá trị DSCP thấp hơn. Cả hai thuật ngữ “CS0” và “Default”đều ám chỉ đến giá trị nhị phân 000000 nhưng phần lớn các lệnh của Cisco IOS chỉ cho phép từ khóa default để đại diện cho giá trị này.

Trạng thái Assured Forwarding PHB và giá trị DSCP

Trạng thái đảm bảo truyền Assured Forwarding (AF) PHB (RFC 2597) định nghĩa bốn nhóm lưu lượng cho mục đích xếp hàng, cùng với ba mức khác nhau về khả năng bị loại bỏ bên trong từng hàng đợi. Để đánh dấu các gói tin và đẩy các gói vào hàng đợi, trạng thái AF PHB định nghĩa 12 giá trị DSCP khác nhau và các ý nghĩa của nó. Tên của các các trạng thái AF DSCP tuân theo dạng sau: AFxy.

Trong đó x ngầm định chỉ đến một trong bốn hàng đợi (giá trị từ 1 đến 4) và y chỉ ra một trong ba giá trị ưu tiên loại bỏ gói tin (giá trị từ 1 đến 3). Trạng thái AF PHB đề xuất rằng giá trị x càng cao trong công thức Afxy, gói tin sẽ được xếp vào hàng đợi tốt hơn. Ví dụ, gói tin với giá trị AF11 DSCP sẽ được đưa vào hàng đợi kém hơn gói tin có giá trị DSCP là AF23. Thêm vào đó, giá trị y càng cao trong công thức Afxy, gói tin càng có nguy cơ bị loại bỏ càng cao. Ví dụ gói tin có DSCP AF11 sẽ ít nguy cơ bị loại bỏ hơn gói tin có DSCP AF23. Bảng dưới đây chỉ ra tên của giá trị DSCP, các nhóm hàng đợi và trạng thái loại bỏ mặc định.

Các tên của trạng thái AF PHB không phải tuân theo nguyên tắc “càng lớn càng tốt”. Ví dụ AF11 tượng trưng giá trị thập phân là 10 và tên AF13 tượng trưng giá trị DSCP thập phân là 14. Tuy nhiên, AF11 thì tốt hơn AF13 bởi vì AF11 và AF13 là trong cùng một nhóm hàng đợi, nhưng AF11 có khả năng bị loại bỏ thấp hơn so với AF13. Trong dạng hiển thị nhị phân, ba bit đầu tiên của giá trị chỉ ra nhóm hàng đợi (từ bit 0 đến bit 2) và hai giá trị bit kế tiếp (bit 3 và 4) chỉ ra độ ưu tiên loại bỏ gói tin. Kết quả là, các công cụ hàng đợi hoạt động chỉ trên IPP vẫn có thể phản ứng với các giá trị AF DSCP, làm cho các giá trị DSCP tương thích một cách cơ bản với các hệ thống mạng non-Diffserv. Để chuyển đổi từ dạng AF sang dạng tương đương thập phân, ta có thể dùng công thức đơn giản. Nếu giá trị AF có dạng AFxy thì công thức tính giá trị thập phân là
Giá trị thập phân = 8x + 2y
Ví dụ giá trị AF41 sẽ tương đương với (8 * 4) + (2 * 1) = 34.

(còn tiếp)

[danghoangkhanh]

Phân loại và đánh dấu trong QoS

Trạng thái EF PHB và các giá trị DSCP

RFC 2598 định nghĩa trạng thái Expedited Forwarding (EF) PHB, được mô tả trong phần này. RFC mô tả hai hành động đơn giản của trạng thái này:
Đưa vào hàng đợi các gói tin EF sao cho nó có thể được giải phóng nhanh, độ trễ thấp.
Áp đặt băng thông cho các gói EF sao cho các gói tin này không làm tốn băng thông trên kết nối hoặc làm ảnh hưởng các hàng đợi khác.

Giá trị DSCP định nghĩa cho EF có tên là EF, có giá trị nhị phân là 101110.

Các trường đánh dấu dữ liệu không phải là IP

Khi gói tin IP truyền trên hệ thống mạng, các gói tin được đóng gói trong các header khác nhau. Trong vài trường hợp, các header khác có trường QoS có thể dùng cho phân loại và đánh dấu.

Khái niệm lớp dịch vụ CoS trong Ethernet LAN

Ethernet hỗ trợ 3-bit QoS, nhưng các trường này chỉ tồn tại khi Ethernet header được đóng gói trong phần header 802.1q hay ISL. IEEE 802.1Q định nghĩa trường QoS của nó là ba bit có trọng số lớn nhất trong trường Tag Control 2-bytes, được gọi là các bit độ ưu tiên người dùng (user-priority). ISL định nghĩa ba bit trọng số thấp nhất từ trường 1-byte, gọi trường này là lớp dịch vụ (class of service – CoS). Nói chung, phần lớn mọi người (và phần lớn các lệnh IOS) đều mô tả trường này như là CoS, bất chấp kiểu trunking được dùng.

Hình dưới đây mô tả vị trí của trường CoS trong các header ISL và 802.1p.

Đánh dấu các gói tin trên WAN

Frame Relay và ATM hỗ trợ một bit đơn có thể được dùng để gán cho mục đích QoS, nhưng các bit đơn này được dùng cho mục đích chỉ ra khả năng loại bỏ. Các frame có bit này được gán bằng 1 thì frame đó được xem là ứng cử viên cho việc bị loại bỏ. Các bit này được đặt tên là bit DE và ATM CLP (Discard Eligibility (DE) bit và ATM Cell Loss Priority (CLP) bit). Các bit này có thể gửi bởi một router, một tổng đài ATM hoặc FR Switch. Router và switch sẽ được cấu hình để chủ động loại bỏ các frame và các cell có DE=1 hoặc CLP=1. MPLS định nghĩa trường 3bit khác gọi là MPLS Experimental (EXP) bit cho mục đích đánh dấu tổng quát. Thường thì các công cụ đánh dấu và phân loại C&M được dùng ở ngoài rìa của mạng MPLS để ánh xạ giá trị DSCP hoặc IPP sang EXP để cung cấp chức năng QoS bên trong một mạng MPLS.

Các vị trí đánh dấu và so sánh dữ liệu trong mạng

Trong hệ thống mạng trên, các giá trị IPP và DSCP bên trong một gói tin IP không bị thay đổi. Tuy nhiên, một vài thiết bị có thể không có khả năng đọc vào các trường IPP và DSCP và một vài thiết bị có thể đọc các trường khác dễ dàng hơn.

Ví dụ một router MPLS Label Switch Router (LSR) bên trong một đám mây MPLS có thể được cấu hình để ra quyết định QoS dựa trên ba bit MPLS EXP trong nhãn MPLS nhưng không có khả năng đọc đến các header IP đã đóng gói bên trong. Trong những trường hợp như vậy, các công cụ QoS có thể cần phải được cấu hình trên những thiết bị ngoài rìa của hệ thống mạng để đọc các giá trị DSCP và đánh dấu bằng những trường khác nhau. Các trường có thể dùng để đánh dấu cho các giao thức non-IP có thể tồn tại chỉ trong vài phần của mạng. Các luật cho các trường này là như sau: (CoS, DE, CLP, EXP).
Để phân loại: Chỉ trên cổng vào và chỉ nếu cổng của router hỗ trợ trường trong header.
Để đánh dấu: chỉ trên cổng ra và chỉ nếu cổng đó hỗ trợ trường đó trong header.

Nếu quá trình đánh dấu phải được cấu hình trên R1 F0/0.1 802.1Q subinterface, nó có thể phân loại các frame đi vào dựa trên giá trị CoS và đánh dấu các frame đi ra với giá trị CoS. Tuy nhiên, khi dữ liệu đi vào, router không thể đánh dấu giá trị CoS và trên chiều đi ra, router cũng không thể phân loại dựa trên CoS. Tương tự như vậy, quá trình đánh dấu cũng không thể phân loại hay đánh dấu các bit DE, CLP hoặc MPLS EXP bởi vì các header này không tồn tại trong cổng Ethernet.

Bảng dưới đây tóm tắt các trường dùng trong quá trình đánh dấu

(còn tiếp)

[danghoangkhanh]

Phân loại và đánh dấu trong QoS

Công cụ giao diện dòng lệnh Cisco Modular QoS CLI (MQC)

Trong nhiều năm và trong nhiều phiên bản IOS, Cisco thêm vào các tính năng QoS, mỗi tính năng có các tập lệnh cấu hình riêng. Cuối cùng, số công cụ QoS khác nhau và các lệnh QoS khác nhau nhiều đến nổi việc cấu hình QoS trở thành khó khăn. Cisco đã tạo ra cú pháp Modular QoS CLI (MQC) để giúp giải quyết vấn đề này. MQC không phải là một giao diện dòng lệnh mới, thay vào đó, nó là một phương thức để nhóm các lệnh phân loại, lệnh đánh dấu và các hành động liên quan vào một nhóm để hợp nhất giao diện dòng lệnh.

MQC định nghĩa một tập hợp mới các lệnh cấu hình, là các lệnh cho phép gõ vào ở cùng IOS CLI trong chế độ cấu hình. Tuy nhiên, khi đã hiểu MQC, bạn chỉ cần học vài lệnh để biết làm thế nào để cấu hình bất kỳ các công cụ MQC. Bạn có thể chỉ ra các công cụ MQC bằng tên của công cụ. Tất cả các công cụ này đều bắt đầu bằng cụm từ “Class-Based” (viết tắt là CB). Các công cụ này bao gồm CB Marking, CB Weighted Fair Queuing (CBWFQ), CB Policing, CB Shaping, và CB Header Compression.

Cơ chế của MQC

MQC tách biệt chức năng phân loại của công cụ QoS ra khỏi hành động (PHB) mà công cụ QoS đó muốn thực hiện. Để làm điều này, có nhiều lệnh trong MQC, với vài lệnh con.

Lệnh class-map định nghĩa các thông số so sánh để phân loại các gói tin vào các nhóm dịch vụ.
Hành động trong từng chặng (PHB): Đánh dấu, đưa vào hàng đợi…được cấu hình bằng câu lệnh policy-map.
Lệnh policy map sẽ được bật trên một cổng bằng lệnh service policy.

Trong hình trên, chính sách QoS của mạng xử lý các gói theo hai nhóm khác nhau, gọi là các nhóm dịch vụ QoS. Kiểu dữ liệu thật sự được đặt vào từng nhóm lưu lượng không được hiển thi. Việc phân loại các gói tin vào hai nhóm trên thực hiện được thông qua lệnh class-map. Mỗi lệnh class-map sẽ theo sau bởi lệnh match, trong đó định nghĩa các thông số thực sự cần phải so sánh bên trong từng gói tin hay từng frame. Với mỗi class, một vài hành động (PHB) cần phải được thực hiện. Hành động này được cấu hình bằng lệnh policy-map. Dưới một policy-map, có thể có nhiều nhóm lưu lượng được tham chiếu đến. Trong hình trên, có hai nhóm là myclass1 và myclass2. Bên trong một policy được gọi là mypolicy, dưới mỗi nhóm myclass1 và myclass2, ta có thể cấu hình nhiều hành động QoS.

Ví dụ, bạn có thể áp dụng các biện pháp đánh dấu khác nhau trong myclass1 và myclass2 ở thời điểm này. Cuối cùng, khi lệnh service-policy được áp dụng vào một cổng, các đặc điểm QoS sẽ có hiệu lực cho lưu lượng vào hoặc ra trên cổng đó.

Phân loại dùng class map

Các công cụ MQC phân loại gói tin dùng lệnh match bên trong một phát biết class map của MQC. Phần dưới đây liệt kê các luật mô tả làm thế nào class map tìm kiếm và phân loại gói tin.

Có nhiều tuỳ chọn trong phát biểu match để tìm ra gói tin bao gồm các trường QoS, ACL và địa chỉ MAC.
Tên của class-map là phân biệt chữ thường và chữ hoa.
Lệnh match protocol có ý nghĩa là IOS dùng giao thức NBAR để thực hiện việc tìm kiếm.
Lệnh match any sẽ bắt được mọi loại gói tin so trùng với bất kỳ gói tin nào. Nói cách khác, tất cả các loại gói tin.

Ví dụ dưới đây mô tả một cấu hình CB đơn giản.

Ví dụ cấu hình cơ chế đánh dấu cơ bản

Để cấu hình CB Marking, ta phải bật tính năng CEF trong router. Nếu không có CEF, các cấy hình class map và cấu hình policy map vẫn có thể nhập vào được, nhưng lệnh service policy sẽ bị từ chối.
ip cef
Class-map đầu tiên sẽ lựa ra tất cả các gói tin UDP/RTP với các cổng UDP giữa 16384 và 32767. Số 32767 là chỉ số kết thúc của một dãy. Lệnh class map thứ hai sẽ lựa ra bất kỳ gói tin nào.

class-map match-all msclass1
match ip rtp 16384 16383
class-map match-all myclass2
match any

Lệnh policy map sẽ gọi đến hai class map. Lệnh set sẽ thực hiện việc đánh dấu, nghĩa là đây là một cấu hình đánh dấu theo lớp.

policy-map mypolicy
class myclass1
set dscp EEFF

class myclass2
set dscp default

Lệnh policy map sẽ xứ lý các gói tin rời khỏi cổng F0/0.

interface Fastethernet0/0
service-policy output mypolicy

Trong ví dụ trên, mỗi gói tin đi ra khỏi cổng F0/0 sẽ rơi vào một trong hai lớp lưu lượng. Bởi vì chính sách mypolicy dùng câu lệnh set dscp trong từng lớp lưu lượng và tất cả các gói tin sẽ so trùng với một trong hai lớp: hoặc là myclass1 hoặc myclass2, mỗi gói tin sẽ rời khỏi cổng và bị đánh dấu như là DSCP EF (giá trị thập phân là 46) hay là mặc định (giá trị thập phân bằng 0).

Nếu giả sử gói tin không rơi vào nhóm myclass1 hay myclass2, các gói tin này sẽ không bị đánh dấu và sẽ giữ nguyên giá trị DSCP ban đầu.

Dùng nhiều phát biểu match

Trong vài trường hợp, câu lệnh class map có thể cần kiểm tra cùng lúc nhiều thông số bên trong một gói tin để quyết định gói tin có trở thành thành viên của nhóm đó không. Các lệnh class map có thể dùng nhiều phát biểu match và ngay cả các câu lệnh class map lồng vào bên trong một class map. Dưới đây là danh sách tóm tắt các điểm chủ chốt liên quan đến các cơ chế so trùng matching phức tạp:
Có tối đa bốn giá trị CoS hay IPP hoặc tám giá trị DSCP có thể được liệt kê trong một phát biểu match cos, match precedence, hay match dscp. Nếu có bất kỳ một giá trị nào là tìm thấy trong gói tin, phát biểu này xem như so trùng.
Nếu một class map có nhiều phát biểu match bên trong nó, lệnh match-any và match-all sẽ định nghĩa khi nào thuật toán OR hay thuật toán AND sẽ áp dụng giữa các phát biểu match.
Lệnh match class ám chỉ đến tên một class map khác, lồng vào bên trong class map hiện hành. Lệnh match class <name> được xem là match nếu câu lệnh class-map cũng so trùng được với gói tin.

Class-map có tên là examplé dùng thuật toán match-all. Vì vậy class map này so trùng tất cả các gói tin được chỉ ra bởi ACL 102 và có độ ưu tiên IPP bằng 5.

class-map match-all example1
match access-group 102
match precedence 5

Class-map có tên là example 2 dùng thuật toán match-any, vì vậy class map này so trùng với tất cả các gói tin chỉ ra bởi ACL 102 hoặc có giá trị DSCP AF21 hoặc cả hai.

class-map match-any example2
match access-group 102
match dscp AF21

Class-map có tên là example 3 không so trùng được với gói tin nào, lý do là hai phát biểu match dùng thuật toán AND do câu lệnh match-all, nghĩa là một gói tin phải có giá trị DSCP 0 và DSCP 1, là một điều không thể.

class-map example4
! shows how to correctly match either DSCP 0 or 1.
class-map match-all example3
match dscp 0
match dscpp 1
!
class-map match-any example4
match dscp 0 1

Class-map có tên là I-am-nesting muốn tham chiếu đến một class-map có tên là I-am-nested trong lệnh I-am-nested. Cơ chế được giải thích ở phần sau của ví dụ.

class-map match-all i-am-nested
match access-grouup 102
match precedence 5
!
class-map match-any i-am-nesting
match class i-am-nested
match cos 5

Phần lắt léo nhất của cấu hình trên là các class map có thể lồng vào nhau. Class-map I-am-nesting dùng phép OR giữa hai phát biểu match, có nghĩa là “tôi quan tâm đến gói tin có CoS bằng 5, hoặc nếu gói tin thuộc về nhóm class-map I-am-nested hoặc gói tin thỏa mãn đồng thời cả hai điều kiện”. Nếu dùng phép AND, thứ tự xử lý của gói sẽ là “Các gói tin được cho phép hoặc được chỉ ra bởi ACL 102 và có giá trị ưu tiên IPP bằng 5 hoặc các frame có giá trị CoS bằng 5.


(còn tiếp)

[danghoangkhanh]

Phân loại và đánh dấu trong QoS

Phân loại dùng NBAR

Đối với các gói tin khó phân loại, kỹ thuật nhận dạng ứng dụng lớp mạng NBAR có thể được dùng. Ví dụ, một vài ứng dụng dùng các port động, vì vậy một câu lệnh cấu hình match đơn thuần so sánh một cổng UDP hay TCP sẽ không có khả năng phân loại được lưu lượng. NBAR sẽ xem các UDP và TCP header, xem tên máy, URL hoặc các kiểu yêu cầu HTTP request. Kiểu kiểm tra này còn được gọi là kiểm tra sâu bên trong gói tin (deep packet inspection).

NBAR cũng có thể xem các header TCP và UDP để nhận ra các thông tin liên quan đến ứng dụng. Ví dụ, NBAR cho phép nhận ra các ứng dụng Citrix và cho phép tìm kiếm một phần của chuỗi URL. NBAR cũng có thể được dùng để đếm các loại lưu lượng và tải của từng loại. Đối với QoS, NBAR có thể được dùng bởi CB Marking để lựa ra những loại gói tin phức tạp. Bất cứ khi nào câu lệnh MQC match protocol được dùng, IOS sẽ dùng NBAR để lựa ra gói tin. Bảng dưới đây liệt kê vài lệnh phổ biến và NBAR.

Các công cụ đánh dấu và phân loại

Cấu hình đánh dấu theo lớp Class-Based Marking (CB Marking)

Cũng như các công vụ QoS khác có tên bắt đầu với cụm từ “Class-based”, bạn có thể dùng các lệnh của MQC để cấu hình đánh dấu theo từng lớp lưu lượng CB Marking. Danh sách dưới đây liệt kê ra các đặc điểm chủ chốt liên quan đến CB.

Thuật toán và cấu hình phân loại như sau:
Để thực hiện đánh dấu lớp hoặc nhóm các lưu lượng yêu cầu phải có CEF (bật lên bằng lệnh ip cef).
Các gói tin được phân loại dựa theo tiêu chuẩn nêu ra trong cấu hình classmap.
Một chính sách MQC muốn tham khảo đến một hoặc nhiều classmap sẽ dùng lệnh class. Các gói tin được phân vào nhóm này sẽ được đánh dấu.
Cơ chế đánh dấu theo lớp lưu lượng CB Marking sẽ có hiệu lực trên những gói tin đang đi vào hoặc đi ra trên một cổng ngay khi lệnh MQC service policy in|out được áp dụng.
Một chính sách đánh dấu CB Marking sẽ được xử lý tuần tự. Khi một gói tin phù hợp với một lớp lưu lượng class, nó sẽ được đánh dấu theo các câu lệnh set cho nhóm đó.
Bạn có thể cấu hình nhiều lệnh set trong một nhóm để gán nhiều thông số cho lưu lượng đó, ví dụ như gán đồng thời DSCP và CoS.
Các gói tin không có rơi vào nhóm nào sẽ được xem như thuộc về nhóm/lớp mặc định, được gọi là class-default.
Đối với bất kỳ nhóm nào bên trong một policy mà không có lệnh set, gói tin sẽ không bị đánh dấu.

Bảng dưới đây sẽ liệt kê cú pháp cho lệnh set trong cơ chế CB Marking

Các lệnh để giám sát CB Marking

Ví dụ cấu hình đánh dấu CB

Lưu lượng được tạo ra để lệnh show hiển thị nhiều ý nghĩa. Hai cuộc gọi voice G.711 được hoàn thành giữa R4 và R1 dùng các card FXS trên hai router với tính năng Voice Activity Detection VAD bị tắt. Máy client 1 thực hiện lệnh FTP get từ server 1 và download hay file HTTP kích thước lớn, có tên là important.jpg và no-so.jpg. Cuối cùng, máy client1 và server1 sẽ có một cuộc hội thoại Microsoft netmeeting, dùng G.723 cho audio và H.263 cho video.

Các tiêu chuẩn sau sẽ định nghĩa các yêu cầu để đánh dấu các loại lưu lượng khác nhau.

Tải VoIP sẽ được gán giá trị DSCP EF
Lưu lượng video netmeeting sẽ được đánh dấu giá trị DSCP AF41.
Bất kỳ lưu lượng web này mà trong địa chỉ URL có chứa chuỗi “important” sẽ được đánh dấu với giá trị AF21.
Bất kỳ lưu lượng web này mà trong địa chỉ của nó có chứa chuỗi “not-so” ở bất cứ nơi nào trong URL sẽ bị đánh dấu giá trị DSCP bằng AF23.
Tất cả những loại lưu lượng còn lại được đánh dấu giá trị DSCP mặc định (0).

ip cef

Class-map voip-rtp dùng NBAR để lựa ra tất cả các lưu lượng RTP audio nhưng không quan tâm đến lưu lượng video hay các báo hiệu.

class-map voip-rtp
match protocol rtp audio

Class map http-impo sẽ tìm ra tất cả các gói tin liên quan đến tiến trình download trong đó có chứa chuỗI “important” vớI bất kỳ ký tự nào xung quanh chuỗI này. Cơ chế tương tự áp dụng cho class-map http-not.

class-map http-impo
match protocol http url "*important*"
!
class-map http-not
match protocol http url "*not-so*"

Class map netMeet lựa ra hai kiểu dữ liệu RTP: một là kiểu G.723 audio (type 4) và một là H263 (type 34). Chú ý rằng từ khóa match-any được dùng sao cho chỉ cần một trong hai điều kiện được thỏa mãn.

class-map match-any NetMeet
match protocol rtp payload-type 4
match protocol rtp payload-type 34

policy-map laundry-list sẽ tham chiếu đến từng class map. Chú ý rằng thứ tự được liệt kê là thứ tự mà các câu lệnh class được thêm vào trong chính sách.

policy-map laundry-list
class voip-rtp
set ip dscp EF
class NetMeet
set ip dscp AF41
class http-impo
set ip dscp AF21
class http-not
set ip dscp AF23
class class-default
set ip DSCP default

Trong đoạn cấu hình trên, lệnh class class-default là cần thiết chỉ nếu một vài hành động khác vớI chế độ mặc định cần phảI được thực hiện cho một gói tin không thuộc về một class nào đã khai báo trước đây. Trong trường hợp này, các gói tin không thuộc về các lớp lưu lượng nào đã khai báo thì sẽ rơi vào lớp mặc định, và được đánh dấu bằng giá trị DSCP default (decimal 0). Nếu không có hai lệnh này, các gói tin trong lớp này sẽ không bị thay đổi. DướI đây, policy sẽ được bật cho các gói tin theo chiều vào trên cổng F0/0.



interface Fastethernet 0/0
service-policy input lundry-list

Lệnh show policy-map laundry-list đơn giản liệt kê lại cấu hình.

R3#show policy-map laundry-list
Policy Map laundry-list
Class voip-rtp
set ip dscp 46
Class NetMeet
set ip dscp 34
Class http-impo
set ip dscp 18
Class http-not
set ip dscp 22
Class class-default
set ip dscp 0

Lệnh show policy-map interface liệt kê các thống kê liên quan đến MQC.

R3# show policy-map interface fastethernet0/0 input
Fastethernet0/0
Service-policy input: laundry-list
Class-map: voip-rtp (match-all)
35268 packets, 2609832 bytes
5 minute offered rate 59000 bps, drop rate 0 bps
Match: protocol rtp audio
QoS Set
ip dscp 46
Packets marked 35268
Class-map: NetMeet (match-any)
817 packets, 328768 bytes
5 minute offered rate 19000 bps, drop rate 0 bps
Match: protocol rtp payload-type 4
protocol rtp payload-type 34
QoS Set
ip dscp 34
Packets marked 817
Class-map: class-default (match-all)
33216 packets, 43649458 bytes
5 minute offered rate 747000 bps, drop rate 0 bps
Match: any
QoS Set
ip dscp 0
Packets marked 33301

Ví dụ trên bao gồm vài tùy chọn phân loại khác nhau dùng lệnh match, bao gồm việc chọn ra MS Netmeeting. Netmeeting dùng RTP cho các dòng lưu lượng video và mặc định sẽ dùng G.723 cho audio và H.323 cho video. Để lựa ra cả hai loại dữ liệu này, ta định nghĩa một classmap chỉ ra cả hai loại RTP cho G.723 và H.623.
Vì vậy class map Netmeet dùng thuật toán OR và so trùng với các kiểu tải 4 (G.723) và 34 (H.263).

Lệnh show policy-map interface cung cấp các thông tin thống kê về số gói tin và bytes đã so trùng ở mỗi lớp. Cú pháp tổng quát như sau:

show policy-map interface interface-name [vc [ vpi/vci] [dlcii dlci] [input | output] [class class-name]

Lệnh này cho phép quan sát chỉ một cổng, theo chiều in hay chiều out và ngay cả chọn lựa một cổng bên trong một policy map. Lệnh load-interval cũng có thể hữu ích khi xem các thống kê của các công cụ QoS. Lệnh này định nghĩa khoảng thời gian mà IOS đo các gói tin trên một cổng của router. Nếu khoảng thời gian này là thấp, các thông tin thống kê sẽ thay đổi nhanh hơn. Nếu khoảng thời gian thống kê là thấp, các thông tin thống kê thay đổi chậm hơn. Giá trị mặc định là 5 phút và nó có thể hạ xuống còn 30 giây. Trong một policy, thứ tự khai báo các class cũng rất quan trọng.

Trong cấu hình trên, nhóm đầu tiên là class voip-rtp. Bởi vì class map so trùng với tất cả các lưu lượng RTP, nó cũng so trùng với các dòng Microsoft Netmeeting audio, vì vậy các dữ liệu của Netmeeting sẽ không rớt vào nhóm Netmeet theo sau. Nếu hai nhóm đầu tiên (voip-rtp và Netmeet) đổi vị trí thì dữ liệu Netmeeting sẽ so trùng chính xác với nhóm NetMeet và tất cả các dữ liệu audio khác sẽ đánh dấu như voip-rtp.

(còn tiếp)

[danghoangkhanh]

Phân loại và đánh dấu trong QoS

Gán giá trị CoS và DSCP

Ví dụ dưới đây minh hoạ làm thế nào cấu hình CB Marking khi một LAN switch thực hiện chức năng QoS dựa trên CoS. Trong trường hợp này, R3 đọc các frame đi vào trên cổng F0/9, đánh dấu giá trị DSCP dựa trên các thông số CoS. Thêm vào đó R3 đọc các giá trị DSCP cho các gói tin đang đi ra cổng F0/0 về switch, gán giá trị trong 802.1Q header. Giá trị thực sự trên cổng F0/0 của R3 cho quá trình phân loại và đánh dấu C&M là như sau:

Các frame đi vào với giá trị CoS 5 sẽ được gán giá trị DSCP EF
Các frame đi vào với giá trị CoS 1 sẽ được gán giá trị AF11.
Các frame đi vào với bất kỳ giá trị CoS nào sẽ được gán DSCP 0.
Các frame đi ra với giá trị DSCP EF sẽ được gán CoS 5.
Các gói đi ra với DSCP AF11 sẽ được gán Cos 1
Các gói tin đi ra với bất kỳ giá trị DSCP nào sẽ được gán CoS 0.

Các chính sách QoS yêu cầu hai policy map trong trường hợp này. Policy map map-cos-to-dscp sẽ so sánh các giá trị CoS cho các frame đi vào cổng F0/0.1 của R3 và đánh dấu các giá trị DSCP này. Vì vậy, dòng lệnh policy map sẽ bật trên cổng F0/0.1 của R3. Không có policy map nào trong hai policy map có thể được áp dụng trên cổng WAN bởi vì chỉ có các cổng được cấu hình cho 802.1Q chấp nhận lệnh service-policy tham chiếu đến các biến CoS. Lưu ý rằng ta không thể áp dụng vào cổng f0/0.2 vì không có header của 802.1Q được dùng.

Ví dụ:

Class-map cos1
Match cos 1
!
class-map cos5
match cos 5
!
class-map AF11
match dscp af11
!
class-map EF
match dscp EF
!
policy-map map-cos-to-dscp
class cos1
set dscp af11
class cos5
set ip dscp ef
class class-default
set ip dscp default
!
policy-map map-dscp-to-cos
class AF11
set cos 1
class EF
set cos 5
class class-default
set cos 0
interface FastEthernet0/0.1
encapsulation dot1q 102
services-policy input map-cos-to-dscp
service-policy output map-dscp-to-cos
!
interface FastEthernet0/0.2
encapsulation dot1q 2 native

NBAR Network-Based Application Recognition

CB marking có thể dùng khả năng phân loại mạnh của NBAR thông qua lệnh match protocol. Dưới đây là một cấu hình cho đánh dấu và NBAR trong đó có các yêu cầu sau được thoả mãn:
Bất kỳ một web traffic nào có URL chứa chuỗi “important” sẽ được gán giá trị AF21.
Bất kỳ web traffic nào có URL chứa chuỗi “not-so” sẽ được gán giá trị DSCP mặc định.
Tất cả những traffic còn lại được gán giá trị AF11.

Ip cef
Class-map http-impo
Match protocol http url “*important*”
!
Class-map http-not
Match protocol http url “*not-so*”
!
Policy-map http
Class http-impo
Set dscp AF21
!
class http-not
set dscp default
!
class class-default
set dscp AF11
!
interface FastEthernet0/0
ip nbar protocol-discovery
service-policy input http
!

Bắt đầu từ IOS 12.2T/12.3, lệnh ip nbar protocol-discovery là cần thiết trên một cổng trước khi dùng lệnh service-policy. Với phiên bản 12.2T/12.3 T Train, lệnh này không còn cần thiết. Việc sử dụng lệnh match protocol ngầm định rằng NBAR sẽ được dùng để tìm ra gói tin.

Không giống như các đặc điểm IOS khác, bạn có thể nâng cấp NBAR mà không dùng phiên bản IOS mới. Cisco dùng một đặc tính gọi là các module ngôn ngữ mô tả gói tin Packet Description Language Modules (PDLMs) để định nghĩa những giao thức mới mà NBAR phải so sánh. Khi Cisco quyết định thêm vào một hoặc nhiều giao thức vào danh sách những giao thức mà NBAR phải nhận diện, nó sẽ tạo và biên dịch một PDLM. bạn có thể download các phiên bản PDLM từ Cisco, chép nó vào flash và thêm vào dòng ip nbar pdlm pdlm-name trong cấu hình, trong đó pdlm là tên của file pdlm nằm trong bộ nhớ flash của router. NBAR sau đó có khả năng phân loại dựa trên thông tin từ PDLM mới.

Các chọn lựa thiết kế cho quá trình đánh dấu

Mục tiêu của quá trình đánh dấu là giúp đơn giản hóa các yêu cầu bởi những công cụ QoS khác bằng cách đánh dấu các gói tin của cùng một lớp lưu lượng có cùng các thông số QoS. Để những công cụ QoS khác được thuận lợi trong quá trình đánh dấu này, các gói tin thường phải được đánh dấu càng gần nguồn của gói tin càng tốt. Tuy nhiên, điểm sớm nhất có thể không phải là một thiết bị tin cậy. Ví dụ trong hình, server 1 có thể gán giá trị DSCP của chính nó và ngay cả giá trị CoS nếu card mạng hỗ trợ trunking. Tuy nhiên, không nên nhất thiết tin tưởng hoàn toàn người quản trị server. Vì vậy, luật sau tóm tắt làm thế nào để chọn vị trí tốt nhất cho quá trình đánh dấu: Hãy đánh dấu càng gần rìa của mạng càng tốt nhưng không nên quá gần nguồn đến nỗi quá trình đánh dấu được thực hiện bởi một thiết bị không tin cậy.

Các tài liệu thiết kế của Cisco QoS cũng khuyến cáo không chỉ thực hiện quá trình đánh dấu ở đâu mà còn khuyến cáo những giá trị nào CoS, IPP và DSCP nên gán cho vài loại traffic. Bảng dưới đây tóm tắt các khuyến cáo này.

Cũng lưu ý rằng Cisco khuyến cáo không nên dùng nhiều hơn năm mức dịch vụ khác nhau. Khi dùng nhiều nhóm dịch vụ, sự khác nhau trong trạng thái của các nhóm trở nên nhạt nhoà. Tương tự, ta cũng không nên cho nhiều nhóm dữ liệu có độ ưu tiên cao.

Đánh dấu dùng policers

Các công cụ khống chế lưu lượng policer sẽ đo tốc độ dữ liệu vào và ra một cổng của router với mục đích xác định mức qui định có bị vượt quá hay không. Mức qui định này gồm hai thành phần: tốc độ dữ liệu (traffic rate) được cấu hình ở đơn vị bits/giây và lượng dữ liệu bùng nổ (burst size), đơn vị dùng là số bytes. Nếu lưu lượng là bên trong mức giới hạn, tất cả các gói tin sẽ được xem như là tuân theo mức qui định. Tuy nhiên, nếu tốc độ vượt quá mức qui định, thì sẽ có vài gói tin bị xem như vượt qua mức thoả thuận. Các hành động QoS tương ứng có thể thực hiện trên cả hai nhóm lưu lượng này.

Dạng đơn giản nhất của chính sách khống chế lưu lượng policer là ép lưu lượng tuân theo chặt chẽ bằng cách chỉ truyền những gói tin nằm dưới mức qui định và sẽ loại bỏ các gói tin vượt quá mức ngưỡng. Tuy nhiên, cả hai chính sách đều cho phép một hành động thoả hiệp trong đó công cụ policer sẽ hạ độ ưu tiên của lưu lượng thay vì loại bỏ lưu lượng. Để hạ độ ưu tiên xuống, công cụ khống chế policer sẽ gán lại giá trị QoS, thường là các giá trị IPP, DSCP với một giá trị mà làm cho gói tin có khả năng bị loại bỏ bởi những router phía sau. Ví dụ, một chính sách có thể là gán lạ gói tin AF11 cho một gói tin vượt quá mức ngưỡng với một giá trị mới là AF13 nhưng không loại bỏ gói tin. Bằng cách làm này, gói tin cũng vẫn truyền thông qua router. Nhưng nếu gói tin gặp nghẽn về sau khi trên đường vận chuyển, nó có khả năng bị loại bỏ.

Khi các yêu cầu đánh dấu có thể được thực hiện bằng CB Marking, công cụ này nên được dùng thay vì dùng công cụ khống chế policer. Tuy nhiên, nếu một yêu cầu tồn tại để đánh dấu gói tin dựa trên việc nó có tuân theo mức ngưỡng qui định của việc truyền dữ liệu, việc đánh dấu dùng công cụ policer nên được dùng.

Định tuyến theo chính sách

Định tuyến theo chính sách cung cấp một khả năng cho router để định tuyến một gói tin dựa trên thông tin chứa trong gói tin, bên cạnh thông tin về địa chỉ đích của gói. Cấu hình định tuyến theo chính sách dùng route map để phân loại gói tin. Mệnh đề route-map bao gồm lệnh set, để định nghĩa tuyến đường, thông qua việc thiết lập giá trị nexthop hoặc chỉ định cổng ra. Định tuyến theo chính sách cũng có thể giúp đánh dấu trường IPP hoặc gán toàn bộ byte ToS. Khi dùng định tuyến theo chính sách, thứ tự các sự kiện sau được dùng:

Gói tin được kiểm tra khi nó đi vào cổng.
Một route map được dùng để tìm ra các tập hợp của các gói tin.
Đánh dấu hoặc là giá trị IPP hoặc toàn bộ byte TOS dùng lệnh set.
Chức năng định tuyến truyền thống của lệnh set cũng có thể được dùng nhưng không cần thiết.

Định tuyến theo chính sách chỉ nên dùng để đánh dấu những gói tin trong trường hợp cơ chế CB Marking là không có sẵn hoặc khi một router cần dùng cả định tuyến theo chính sách và đánh dấu gói tin khi đi vào cùng một cổng.

---Hết---

[Gunz]

VnPro có thể upload lại hình ảnh của bài viết này không?