Bước 1: Đặt IP như mô hình.
Bước 2: Định tuyến OSPF, đảm bảo mạng hội tụ (mạng mà có tất cả các thiết bị đầu cuối liên lạc được với nhau)
Bước 3: Cấu hình QoS trên R3. Cấu hình các chức năng chính: - Phân loại.
- Đánh dấu (dùng DSCP).
- Cấu hình hàng đợi (CBWFQ, LLQ, WFQ).
- Cấu hình tránh nghẽn mạng bằng WRED. Các lệnh cấu hình cụ thể như sau (phần trong ngoặc {} là giải thích cho các lệnh):
- Cấu hình NetFlow trên R3:
70 R3(config-if)#ip route-cache flow {bật Netflow trên các cổng của Router} R3(config-if)# exit
R3(config)#interface serial 0/0
R3(config-if)#ip route-cache flow {bật Netflow trên các cổng của Router} R3(config-if)# exit
{Bật NetFlow trên tất cả các cổng của router để kiểm tra được cả lưu lượng vào và ra trên các cổng này. Ví dụ, router có 2 cổng A và B, nếu chỉ bật NetFlow trên cổng A thì sẽ chỉ nhận được thông tin về lưu lượng vào cổng A và lưu lượng ra cổng B. Thông tin về lưu lượng ra ra cổng A sẽ được tính toán dựa vào thông tin NetFlow gửi từ cổng B. Do đó cần phải bật NetFlow trên cả 2 cổng.}
R3(config)#ip flow-export version 5
{Chọn version NetFlow để sử dụng (ở đây là version 5). NetFlow Analyzer chỉ hỗ trợ NetFlow version 1, 5, 7, 9. Thông thường các router series 2600 thường chỉ hỗ trợ 3 loại version là :1, 5, 9. Version 1 chỉ nên sử dụng nếu phần mềm NetFlow chỉ hỗ trợ version này. Version 5 thường được sử dụng nhiều hơn và các trường thông tin của nó đầy đủ hơn. Version 9 có định dạng các gói thông tin NetFlow rất linh hoạt và có thể thay đổi tùy theo ý muốn người sử dụng.}
R3(config)#ip flow-export destination 10.0.0.2 9996
{Xuất các dữ liệu trong NetFlow cache tới một địa chỉ IP xác định. Sử dụng địa chỉ IP của NetFlow collector (chạy NetFlow Analyzer hoặc các chương trình NetFlow khác) và cổng lắng nghe kèm theo. Cổng mặc định của NetFlow Analyzer là 9996 tuy nhiên có thể thay đổi tùy theo người sử dụng.}
R3(config)#ip flow-export source serial 0/0
{Thiết lập địa chỉ nguồn của các gói dữ liệu NetFlow gửi tới NetFlow Analyzer. Dựa vào địa chỉ này NetFlow Analyzer có thể biết được nó đang nhận dữ liệu từ router nào gửi đến và nó có thể gửi các truy vấn SNMP tới router đó theo địa chỉ này. Có thể đặt source là các cổng giao tiếp của router (ví dụ, int fa0/0) nhưng thường nên đặt địa chỉ source đó là địa chỉ loopback của router (ví dụ, loopback 0). Điều đó làm cho những người muốn tấn công hệ thống mạng khó hơn bởi vì địa chỉ IP cổng loopback của router không dễ bị dò ra như địa chỉ IP của các cổng vật lý khác của router.}
71
R3(config)#ip flow-cache timeout active 1
R3(config)#ip flow-cache timeout inactive 15
{Thiết lập thời hạn cho các luồng. Active: thiết lập thời hạn tồn tại (theo phút) của một luồng đang chứa trong cache. Thời hạn này từ 1 đến 60 phút. (khuyến cáo để là 1). Inactive: thiết lập thời hạn tồn tại (theo giây) của các luồng không hoạt động chứa trong cache. Thời hạn này từ 10 đến 600 s. (khuyến cáo để là 15).}
R3(config)#snmp-server ifindex persist
{Đảm bảo thông tin về các cổng vẫn duy trì khi thiết bị reboot.} - Cấu hình phân loại lưu lượng theo chiều vào trên R3
R3(config)#access-list 100 permit tcp any any eq 80 {ACL cho HTTP} R3(config)#access-list 101 permit tcp any any eq 20 {ACL cho FTP} R3(config)#access-list 101 permit tcp any any eq 21 {ACL cho FTP}
R3(config)#access-list 102 permit udp any any range 16384 32768 {ACL cho Voice}
R3(config)#class-map match-any http R3(config-cmap)# match access-group 100 R3(config-cmap)#exit
R3(config)#class-map match-any ftp R3(config-cmap)# match access-group 101 R3(config-cmap)#exit
R3(config)#class-map match-any voice R3(config-cmap)# match access-group 102 R3(config-cmap)#exit
Câu lệnh class-map: dùng để phân loại lưu lượng theo ý muốn của người sử dụng bằng cách đưa lưu lượng vào một class tương ứng (với tên class đặt tùy ý sao cho dễ gợi nhớ), có thể sử dụng kết hợp với nhiều công cụ phân loại như ACL hay dùng cơ chế NBAR ... Lệnh class-map kết hợp với lệnh match để phân loại các gói tin vào trong các class đã tạo (tương ứng với ACL đã tạo).
72
- Cấu hình đánh dấu gói tin đi vào (trên R3):
Đánh dấu các gói tin trong mỗi lớp dịch vụ dùng lệnh set } {Câu lệnh policy- map: dùng để quy định cách xử lý cho từng loại lưu lượng đã được phân loại, cách xử lý là xét độ ưu tiên cho các gói tin. Luôn tồn tại 1 loại cấu hình class-map tên là class-default nhằm phân loại tất cả các lưu lượng chưa được phân loại bởi những class-map trước. R3(config)#policy-map marking-in R3(config-pmap)#class http R3(config-pmap-cmap)#set ip dscp AF21 R3(config-pmap-cmap)#exit R3(config-pmap)#class ftp R3(config-pmap-cmap)#set ip dscp AF31 R3(config-pmap-cmap)#exit R3(config-pmap)#class voice R3(config-pmap-cmap)#set ip dscp EF
{Câu lệnh service-policy: Đây là câu lệnh dùng để áp dụng policy-map đã cấu hình lên một cổng tương ứng, mỗi cổng chỉ áp dụng được một policy-map theo hướng vào hoặc hướng ra.}
R3(config)#interface fastEthernet 1/0
R3(config-int)#service-policy input marking-in - Cấu hình đánh dấu gói tin đi ra (trên R3):
R3(config)# class-map match-any http R3(config-cmap)# match ip dscp AF21 R3(config-cmap)#exit
R3(config)# class-map match-any ftp R3(config-cmap)# match ip dscp AF31 R3(config-cmap)#exit
73 R3(config-cmap)# match ip dscp EF
R3(config-cmap)#exit
- Cấu hình ưu tiên Bandwidth cho các class theo chiều ra:
R3(config)# policy-map queuing-out R3(config-pmap)# class voice R3(config-pmap-c)# priority 350 R3(config-pmap-c)#exit
R3(config-pmap)# class http
R3(config-pmap-cmap)# bandwidth 60
R3(config-pmap-cmap)# random-detect dscp-based R3(config-pmap-cmap)#exit
R3(config-pmap)# class ftp
R3(config-pmap-cmap)# bandwidth 60
R3(config-pmap-cmap)# random-detect dscp-based R3(config-pmap-cmap)#exit
R3(config-pmap)# class class-default {những lưu lượng còn lại}
R3(config-pmap-c)# fair-queue R3(config-pmap-c)#exit
R3(config)#interface serial
R3(config-int)#service-policy output queuing-out 6. Kết quả đạt được
Dùng Netflow để đo các lưu lượng mạng. Thực hiện cuộc gọi bằng Polycom từ Client đến Server, đồng thời tải một lượng dữ liệu lớn dữ liệu từ FTP server. Nếu không áp dụng các kỹ thuật QoS thì lưu lượng FTP chiếm phần lớn Bandwidth. Kết quả được thể hiện trong hình sau:
74
Hình 4.6: Kết quả thực nghiệm khi chưa thực hiện QoS
Sau khi thực hiện cấu hình QoS như trên. Kết quả được thể hiện trong hình sau:
75 KẾT LUẬN
Các Kết quả đạt được
Đề tài đã thực hiện được các yêu cầu sau:
Tìm hiểu một cách tổng quát khái niệm, yêu cầu, sự cần thiết cũng như một số
cách tiếp cận để đánh giá chất lượng dịch vụ trong mạng IP và các tham số chính để đánh giá chất lượng dịch vụ mạng IP.
Tìm hiểu và chọn lựa một số mô hình bảo đảm chất lượng dịch vụ mạng phổ biến
đang được ứng dụng trong thực tế từ đó tập trung tìm hiểu sâu vào nguyên lý hoạt động và các thành phần của các mô hình đó.
Tìm hiểu các kỹ thuật bảo đảm chất lượng dịch vụ mạng như; các kỹ thuật đánh
dấu gói tin, phân loại gói tin, chính sách lưu lượng mạng, định hướng lưu lượng mạng nhằm bảo đảm chất lượng dịch vụ mạng.
Tìm hiểu về các nguyên nhân chính gây ra tắc nghẽn mạng, các kỹ thuật quản lý
tắc nghẽn và các kỹ thuật tránh tắc nghẽn.
Tìm hiểu và tự thực hành việc cấu hình các kỹ thuật bảo đảm chất lượng dịch vụ
mạng và các kỹ thuật quản lý tắc nghẽn, tránh tắc nghẽn trong mạng trên thiết bị mạng Cisco.
Sau khi tìm hiểu một cách tổng thể về nguyên lý và các kỹ thuật bảo đảm chất lượng dịch vụ, đồ án còn thực hiện một số mô hình bảo đảm chất lượng dịch vụ trong mạng LAN, mạng WAN giữa doanh nghiệp và nhà cung cấp dịch vụ mạng theo bản thỏa thuận mức dịch vụ SLA.
Hướng phát triển của đề tài
Nếu có nhiều thời gian hơn:
Tìm hiểu các kỹ thuật bảo đảm chất lượng dịch vụ trong mạng không dây
Wireless, mạng chuyển mạch nhãn đa giao thức MPLS, mạng riêng ảo VPN.
Đưa ra các mô hình mô phỏng lơn hơn và phức tạp hơn.
76 TÀI LIỆU THAM KHẢO
1. Tiếng Việt
[1] Hoàng Trọng Minh, “Chất lượng dịch vụ IP”, 2007
[2] TS. Võ Thanh Tú, “Bài giảng Đánh giá hiệu năng mạng”
2. Tiếng Anh
[3] Vinod Joseph and Brett Chapman, “Developing QoS for Cisco IP and Next
Generation Networks”, 2009
[4] Patrick J. Conlan, “Cisco Network Professional’s Advanced Internetworking
Guide”, 2009
[5] Scott Empson and Hans Roth, “CCNP ONT Portable Command Guide”, April 04, 2008
[6] Mario Marchese, “QoS over heterogeneous networks”, 2007
[7] IBM Corp, “TCP/IP Tutorial and Technical Overview”, December 2006
[8] Ph.D Kun I. Park, “QoS in packet Networks”, 2005
[9] Knet Hires, “CCIP QoS version 2.0”, 2004
[10] Michael J. Cavanaugh, “IP Telephony Self-Study”, November 18, 2004
[11] Cisco Systems, “Catalyst 2950 and Catalyst 2955 Switch Software
Configuration Guide”, October, 2003
[12] E. Brent Kelly, “Quality of Service In Internet Protocol (IP) Networks”, 2002
77 PHỤ LỤC
1. Thỏa thuận mức dịch vụ QoS - QoS Service Level Agreement
Để duy trì các yêu cầu về phân loại và ưu tiên các loại lưu lượng qua mạng của nhà cung cấp dịch vụ, phải có sự thỏa thuận giữa doanh nghiệp, khách hàng và nhà cung cấp dịch vụ mạng để thực hiện điều đó. Sự thỏa thuận này được gọi là thỏa thuận mức dịch vụ (SLA). Một SLA là một bản hợp động quy định làm thế nào để mỗi lớp lưu lượng sẽ được đối xử và các mức xử phạt nếu các thỏa thuận này không phù hợp. Sự đối xử bao gồm việc bảo đảm về băng thông, độ trễ, jitter, tính sẵn sàng cao, phụ thuộc vào mức dịch vụ được trả.
Một SLA phải có khả năng phân lớp và ưu tiên được từ 3 đến 5 lớp lưu lượng. Đó là các lớp dịch vụ ứng dụng thời gian thực, nó nhận được một bảo đảm về băng thông tối thiểu, bảo đảm độ trễ, bảo đảm Jitter, và bảo đảm mức độ mất gói. Tùy thuộc vào các lớp ứng dụng mà có một SLA cụ thể, và việc bảo đảm này phải trả phí.
Ví dụ, giả sử rằng nhà cung cấp dịch vụ đưa ra một SLA như sau: độ trễ là 40 ms, jitter là 20 ms, và 0,5% mất gói cho 3 lớp dịch vụ:
Vàng (Gold): Các lưu lượng “Vàng” bao gồm các ứng dụng thời gian thực. Lưu lượng trong một lớp được bảo đảm một lượng băng thông tối đa (dành cho các lưu lượng này) và bảo đảm 90% thời gian các dịch vụ thời gian thực này không vượt quá băng thông tối đa (của đường liên kết). Nếu các lưu lượng này vượt quá băng thông tối đa đã được bảo đảm sẽ bị phân loại lại như các lưu lượng bình thường.
Bạc (Sliver): Các lưu lượng “Bạc” bao gồm các ứng dụng dữ liệu mất phí (premium). Lưu lượng trong lớp này được bảo đảm một lượng băng thông tối thiểu và bảo đảm 75% thời gian của các lưu lượng này không vượt quá băng thông tối thiểu của đường truyền. Nếu các lưu lượng này vượt quá băng thông tối thiểu đã được bảo đảm sẽ bị phân loại lại như các lưu lượng bình thường.
Nỗ lực tối đa: Các lưu lượng nỗ lực tối đa (Best-effort) bao gồm tất cả các lưu lượng đã bị phân loại lại và bất kỳ lưu lượng nào chưa được phân loại. Lưu lượng trong lớp này được bảo đảm một lượng băng thông tối thiểu và bảo đảm 50% thời gian của các lưu lượng này không vượt quá băng thông tối thiểu của đường truyền. Nếu các lưu lượng này vượt quá băng thông tối thiểu đã được bảo đảm sẽ được gửi đi nếu băng thông còn băng thông. Nếu không đủ băng thông còn lại, các lưu lượng này sẽ bị loại bỏ (dropped).
Dưới đây là bảng SLA mẫu dành cho các loại lưu lượng khác nhau Bảng phụ lục 1: Bảng SLA mẫu
78 Lớp lưu lượng Giá trị DSCP Bảo đảm % tốc độ liên kết hoặc
CIR
Vàng (Gold) DSCP EF
CS 3
Băng thông tối đa Độ trễ thấp Không mất gói 25% tốc độ đường link hoặc CIR Bạc (Silver) DSCP AF31 DSCP AF32 DSCP AF33 CS 6
Băng thông tối thiểu Mất gói rất nhỏ
50% tốc độ đường link hoặc CIR sau khi lưu lượng “vàng” được truyền đi
Đồng (Bronze) DSCP AF21 DSCP AF22 DSCP AF23
Băng thông tối thiểu Mất gói trong khoảng thấp đến không bị mất gói
25% tốc độ đường link hoặc CIR sau khi lưu lượng “vàng” và “bạc” được truyền đi
Mặc định DSCP 0 Không có 25% tốc độ đường link
hoặc CIR sau khi lưu lượng “vàng”, “bạc” và “đồng” được truyền đi
2. Các ứng dụng yêu cầu QoS và các giá trị tương ứng để tham khảo
Để bảo đảm các luồng lưu lượng của các ứng dụng khác được cư xử đúng mực và bảo đảm theo SLA giữa khách hàng với nhà cung cấp dịch vụ thì nhà cung cấp dịch vụ phải quan tâm đến các yêu cầu tối thiểu của các ứng dụng đó về băng thông, độ trễ, jitter và tỷ lệ mất gói khi chúng được thực thi trên mạng, đặc biệt là các ứng dụng thời gian thực như Voice, Video…
2.1. Lưu lượng thoại (Voice Traffic)
Một gói tin thoại bao gồm các thành phần như: Voice payload, tiêu đề giao thức truyền thời gian thực RTP, tiêu đề giao thức UDP, tiêu đề IP, và tiêu đề giao thức tầng 2 của mô hình TCP/IP.
Trong mỗi trường thoại IP của Cisco, có hai kiểu mã hóa được sử dụng phổ biên là G.711 và G.729. Bảng 6-2 dưới đây là các tùy chọn cách mã hóa payload của thoại tương ứng với băng thông và số lượng gói tin được truyền qua trong một giây. Bảng phụ lục 2: Bảng tùy chọn cách mã hóa payload và băng thông yêu cầu tương ứng.
79 Mã hóa Tốc độ lấy mẫu Voice Payload Số gói tin/giây
Tổng băng thông cho một cuộc gọi
G.711 20 ms 160 bytes 50 pps 80 kbps
G.711 30 ms 240 bytes 33 pps 74 kbps
G.729 20 ms 20 bytes 50 pps 24 kbps
G.729 30 ms 30 bytes 33 pps 19 kbps
Bảng phụ lục 3: Bảng yêu cầu các tham số QoS để bảo đảm lưu lượng Voice
Độ trễ Nhỏ hơn hoặc bằng 150 ms
Jitter Nhỏ hơn hoặc bằng 30 ms
Tỷ lệ mất gói Nhỏ hơn 1%
Các ứng dụng thoại không chấp nhận độ trễ và vấn đề tắc nghẽn trên mạng. Để hạn chế độ trễ, jitter, và mất gói, lưu lượng thoại phải luôn luôn được đưa vào hàng đợi ưu tiên, có thể sử dụng hàng đợi LLQ bất kỳ lúc nào có thể được.
2.2. Lưu lượng Video
Nếu các gói tin Video bị mất hoặc bị trễ hoặc jitter quá nhiều thì video có thể bị mất hình hoặc giật video. Vì vậy các tham số như độ trễ, jitter, tỷ lệ mất gói phải đặc biệt quan tâm, đặc biệt là băng thông.
Bảng phụ lục 4: Bảng yêu cầu các tham số QoS để bảo đảm lưu lượng Video
Độ trễ Nhỏ hơn hoặc bằng 150 ms
Jitter Nhỏ hơn hoặc bằng 30 ms
Tỷ lệ mất gói Nhỏ hơn 1 %
Băng thông giao động (Bandwidth Fluctuation) 20 %
Các ứng dụng thoại không chấp nhận độ trễ và vấn đề tắc nghẽn trên mạng. Để hạn chế độ trễ, jitter, và mất gói, lưu lượng thoại phải luôn luôn được đưa vào hàng đợi ưu tiên, có thể sử dụng hàng đợi LLQ bất kỳ lúc nào có thể được.
2.3. Lưu lượng dữ liệu
Các ứng dụng dữ liệu có thể tách ra không quá 4 hoặc 5 lớp lưu lượng khác nhau, mỗi lớp bao gồm các ứng dụng dữ liệu yêu cầu QoS như nhau. Các lớp này bao gồm:
80 Các ứng dụng quan trọng (Mission – critical applications). Các ứng dụng này được xác định như là các ứng dụng lõi trong việc kinh doanh dựa trên chức năng thực tế và tính hiệu quả. Các ứng dụng này cần rất nhiều băng thông bởi vì chúng sử dụng giao thức TCP, và chúng không nhạy cảm với độ trễ, jitter, và mất gói. Các ứng dụng này có thể giới hạn trong 3 lớp hoặc thấp hơn, sẽ nhận được tối thiểu (least) 50% băng thông còn lại sau khi hàng đợi LLQ được phục vụ ưu tiên lưu lượng.
Các ứng dụng giao dịch (Transactional applications). Các ứng dụng này là