• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.
Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Hỏi về các kỹ thuật queuing?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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 khi có nghẽn xảy ra, 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 (tail-drop) 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à 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ỏ.

    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 giao thức 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.
    Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

    Email : dangquangminh@vnpro.org
    https://www.facebook.com/groups/vietprofessional/

    Comment


    • #17
      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.

      Lệnh, Chế độ và chức năng

      fair-queue [congestive-discard-threshold [dynamicqueues[reservable-queues]]]

      - Chế độ cổng. Bật WFQ và thay đổi các giá trị mặc định

      hold-queue length out
      Lệnh ở mức cổng. Thay đổi chiều dài của hàng đợi.

      show queue interface-name interface-number [vc [vpi/] vci]]
      Liệt kê các thông tin về các gói tin trong hàng đợi.

      show queueing [custom | fair | priority | randomdetect[interface atm-subinterface [vc [[vpi/] vci]]]]
      Liệt kê các thông tin cấu hình và các thông tin thống kê.

      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
      Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

      Email : dangquangminh@vnpro.org
      https://www.facebook.com/groups/vietprofessional/

      Comment


      • #18
        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.

        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 điểm CBWFQ và Mô tả
        Phân loại:Phân loại dựa trên bất kỳ tiêu chuẩn so trùng nào
        Chính sách loại bỏ: Loại bỏ gói tin cuối hàng đợi hay cho từng hàng
        Số hàng đợi: 64
        Chiều dài hàng đợi tối đa: Thay đổi tuỳ theo kiểu router và bộ nhớ
        Định thời bên trong một hàng đợi: FIFO 63 hàng, FIFO hay WFQ trên hàng mặc định
        Định thời trên tất cả các hàng: Kết quả của phần định thời cung cấp một tỉ lệ phần trăm của băng thông đến từng hàng đợi.
        Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

        Email : dangquangminh@vnpro.org
        https://www.facebook.com/groups/vietprofessional/

        Comment


        • #19
          Các lệnh tham khảo cho CBWFQ
          Lệnh, Chế độ lệnh và chức năng của lệnh:

          Bandwidth {bandwidth bandwidth| percent percent}: Lệnh này nằm bên trong class; Gán tỉ lệ phần trăm băng thông cho nhóm.
          bandwidth {remaining percent percent}: Lệnh bên trong class, gán tỉ lệ phần trăm còn lại cho nhóm.
          Queue-limit limit: Lệnh này trong cấu hình class. Chỉ ra chiều dài tối đa của hàng đợi CBWFQ.
          fair-queue [queue-limit queuevalue]: Lệnh này trong cấu hình class, bật WFQ trên class mặc định
          max-reserved-bandwidthpercent: Lệnh này ở chế độ cổng. Định nghĩa tỉ lệ % băng thông có thể dùng để dùng cho CBWFQ, chưa kể đến hàng đợi mặc định.
          Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

          Email : dangquangminh@vnpro.org
          https://www.facebook.com/groups/vietprofessional/

          Comment


          • #20
            Dưới đây là một cấu hình CBWFQ đơn giản dùng hàng đợi WFQ 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)
            Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

            Email : dangquangminh@vnpro.org
            https://www.facebook.com/groups/vietprofessional/

            Comment


            • #21
              Đị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 (system queue). 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.

              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/lớp lưu lượng 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.
              Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

              Email : dangquangminh@vnpro.org
              https://www.facebook.com/groups/vietprofessional/

              Comment


              • #22
                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ý.

                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ý.
                Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

                Email : dangquangminh@vnpro.org
                https://www.facebook.com/groups/vietprofessional/

                Comment


                • #23
                  Đị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.
                  Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

                  Email : dangquangminh@vnpro.org
                  https://www.facebook.com/groups/vietprofessional/

                  Comment


                  • #24
                    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.
                    Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

                    Email : dangquangminh@vnpro.org
                    https://www.facebook.com/groups/vietprofessional/

                    Comment


                    • #25
                      Các kỹ thuật queuing này có thể áp dụng cho mọi loại router/switch luôn phải không anh?

                      Comment


                      • #26
                        Hi Nam

                        Các cơ chế queueing trên switch thì càng phức tạp hơn. TranNam có quan tâm vấn đề queueing trên switch không?
                        Đặng Quang Minh, CCIEx2#11897 (Enterprise Infrastructure, Wireless), DEVNET, CCSI#31417

                        Email : dangquangminh@vnpro.org
                        https://www.facebook.com/groups/vietprofessional/

                        Comment

                        Working...
                        X