Асинхронный режим передачи (ATM) : "Класс обслуживания (IP, ATM и т. п.)"

Основные сведения об организации весовой справедливой очереди на основе классов для ATM

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

В данном документе кратко рассматривается постановка трафика в очередь по технологии взвешенной организации очередей на основе классов (CBWFQ).

Очередь с весами (WRQ) включает низкоскоростные каналы, такие как последовательные каналы, для обеспечения "справедливой" обработки всех типов трафика. Эта технология помогает классифицировать трафик по нескольким потокам (они также известны как собеседования) на основании информации, полученной с третьего и четвертого уровней – например, IP-адресов и портов TCP. Для этого определять списки доступа не требуется. Это означает, что трафик низкой пропускной способности эффективно имеет приоритет над широкополосным трафиком, потому что широкополосный трафик совместно использует средства передачи в пропорции к его назначенному весу. Однако WFQ имеет некоторые ограничения:

  • Он не масштабируется, если поток возрастает значительно.

  • Собственное WFQ недоступно на высокоскоростных интерфейсах ATM.

CBWFQ предоставляет способ решения для этих ограничений. CBWFQ, в отличие от стандартной WFQ, позволяет определить классы трафика и применить к ним такие параметры, как пределы пропускной способности и размера очереди. Полоса пропускания, назначенная классу, используется для определения его "веса". Вес каждого пакета, соответствующего условиям класса, также определяется на основе этих характеристик. Принцип WFQ применяется к классам, которые могут содержать несколько потоков, а не к самим потокам.

Для получения дополнительных сведений по настройке CBWFQ щелкните следующие ссылки:

Формирование взвешенных справедливых очередей на основе классов для каждого VC (Per-VC CBWFQ) на маршрутизаторах Cisco 7200, 3600 и 2600.

Взвешенная справедливая классовая организация очереди в рамках VC на платформах на базе RSP.

Перед началом работы

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. Cisco Technical Tips Conventions.

Предварительные условия

Для данного документа отсутствуют предварительные условия.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, содержащиеся в данном документе, были получены с устройств в специальной лабораторной среде. Все устройства, описанные в данном документе, были запущены с конфигурацией по умолчанию. При работе с реальной сетью необходимо полностью осознавать возможные результаты использования всех команд.

Схема сети

Для того чтобы проиллюстрировать работу WFQ, обратимся к приведенной ниже настройке:

/image/gif/paws/10406/wfq_illustrated.gif

В используемой настройке пакеты могут храниться в одной из двух очередей:

  • Аппаратная очередь FIFO на адаптере порта и сетевом модуле.

  • Очередь в Cisco программное обеспечение IOS� (на вводе/выводе маршрутизатора [ввод-вывод] память), где могут быть применены функции Качества обслуживания (QoS), такие как CBWFQ.

Очередь FIFO на адаптере порта хранит пакеты, прежде чем они будут сегментированы в ячейки для передачи. Если очередь заполнена, к программному обеспечению IOS передаются сигналы модуля сети или адаптера, что очередь перегружена. Этот механизм называется "противодавлением". Получив этот сигнал, маршрутизатор прекращает отправку пакетов в очередь FIFO интерфейса и сохраняет пакеты в программном обеспечении IOS, пока очередь снова не разгрузится. Когда пакеты хранятся в IOS, система может применять такие функции QoS, как CBWFQ.

Установка ограничения передачи по кольцу

Одна из проблем с механизмом организации очередей состоит в том, что чем больше простая очередь на интерфейсе, тем продолжительнее задержка перед отправкой пакетов в конце очереди. Это может вызвать серьезные проблемы качества работы для чувствительного к задержкам трафика, например речевого.

Команда tx-ring-limit постоянного виртуального канала (PVC) позволяет уменьшить размер очереди FIFO.

interface ATMx/y.z point-to-point
      ip address a.b.c.d M.M.M.M
      PVC A/B 
       TX-ring-limit 
       service-policy output test

Предел (x), который можно здесь задать, это либо число пакетов (для маршрутизаторов Cisco 2600 и 3600), либо число частей (для маршрутизаторов Cisco 7200 и 7500).

Уменьшение размера кольца передачи имеет два преимущества:

  • Уменьшается время ожидания пакетов в очереди FIFO перед их сегментированием.

  • Это ускоряет использование службы QoS в программном обеспечении IOS.

Действие ограничения кольца передачи

Давайте рассмотрим действие предела кольца передачи с помощью настройки, изображенной на приведенной выше схеме сети. Мы можем принять придерживающееся:

  • Генератор трафика посылает трафик (1500-байтовые пакеты) приемнику данных, и этот трафик перегружает постоянный виртуальный канал 0/102 между маршрутизаторами router1 и router2.

  • Маршрутизатор3 пытается проверить доступность маршрутизатора1.

  • CBWFQ включен на маршрутизаторе 2.

Чтобы определить влияние ограничений кольца передачи, давайте рассмотрим две конфигурации, в которых используются разные ограничения кольца передачи.

Пример A

В этом примере было послано кольцо передачи при ограничении, равном трем (TX-ring-limit=3). Вот то, что мы видим, когда мы пропинговываем router1 от router3.

POUND#ping ip
     Target IP address: 6.6.6.6
     Repeat count [5]: 100000
     Datagram size [100]: 
     Timeout in seconds [2]: 
     Extended commands [n]: 
     Sweep range of sizes [n]: 
     Type escape sequence to abort.
     Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
     Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

Пример B

В данном примере мы установили кольцо передачи на 40 (TX-ring-limit=40). Вот что мы видим, когда используем такую же команду "ping", как в Примере А:

POUND#ping ip
     Target IP address: 6.6.6.6
     Repeat count [5]: 10000
     Datagram size [100]: 36
     Timeout in seconds [2]: 10
     Extended commands [n]: 
     Sweep range of sizes [n]: 
     Type escape sequence to abort.
     Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
     !!!!!!!!!!!!.
     Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488

Как видно из этого, чем больше предел передачи по кольцу, тем больше время проверки доступности приема-передачи (RTT). Отсюда следует, что большой предел для кольца может привести к существенным задержкам при передаче.

Как работает CBWFQ

Увидев то, какое воздействие оказывает размер FIFO-очереди аппаратных ресурсов, давайте подробнее рассмотрим работу CBWFQ.

Собственное WFQ назначает вес на каждый диалог, и затем планирует время передачи для каждого пакета других потоков. Вес является функцией приоритета IP-трафика каждого потока, и запланированное время зависит от размера пакета. Щелкните здесь для получения дополнительной информации на WFQ.

CBWFQ назначает вес каждому настроенному классу, а не каждому потоку. Этот вес пропорционален ширине полосы пропускания, определенной для каждого класса. Если точнее, вес — это функция ширины полосы пропускания интерфейса, разделенная на ширину полосы пропускания класса. Поэтому, чем больше параметр пропускной способности, тем меньший вес.

Вычислить планируемое время пакета можно с помощью следующей формулы:

scheduling tail_time= queue_tail_time + pktsize * weight 

Разделение общей пропускной способности интерфейса

Давайте посмотрим на то, как маршрутизатор делит общую пропускную способность интерфейса между другими классами. Для обслуживания классов маршрутизатор использует календарные очереди. В каждой из календарных очередей хранятся пакеты, которые должны передаваться в одно и то же время scheduling_tail_time. Маршрутизатор обслуживает затем эти календарные очереди по одной. Рассмотрим этот процесс:

  1. Если перегрузка происходит на адаптере порта, когда пакет поступает в выходной интерфейс, это вызывает организацию очереди в IOS (CBWFQ в этом случае).

  2. Маршрутизатор вычисляет планируемое время для прибывающего пакета и хранит его в календарной очереди в соответствии с данным планируемым временем. В определенной календарной очереди можно хранить только один пакет на класс.

  3. Когда приходит время обслуживания календарной очереди, в которой хранился пакет, IOS очищает эту очередь и отправляет пакеты в очередь FIFO на самом адаптере порта. Размер этой очереди FIFO определен пределом кольца передачи, описанным выше.

  4. Если очередь FIFO слишком мала, чтобы вместить все пакеты, содержащиеся в обслуживаемой календарной очереди, маршрутизатор перепланирует пакеты, которые не могут быть сохранены до следующего планируемого времени (из-за своего размера), и помещает их в соответствующую календарную очередь.

  5. Когда все это сделано, адаптер порта рассматривает пакеты в своей очереди FIFO и передает ячейки на проводе, и IOS перемещается в следующую календарную очередь.

    Благодаря этому механизму каждый класс статистически получает часть полосы пропускания интерфейса в соответствии с определенными для него параметрами.

Механизм очереди календаря и размер кольца передачи данных

Рассмотрим взаимосвязь между календарным механизмом очереди и размером кольца передачи. Малое кольцо передачи позволяет быстрее запускать QoS и уменьшает задержку пакетов, ожидающих передачи (что очень важно для трафика, чувствительного к задержкам, например для голоса). Однако если он слишком мал, то это может стать причиной более низкой пропускной способности для определенных классов. Это вызвано тем, что много пакетов, вероятно, придется перенести, если кольцо для передачи не может принять их.

Нет, к сожалению, никакого идеального значения для размера кольца передачи и единственного способа найти, что оптимальное значение путем экспериментирования.

Совместное использование полосы пропускания

Чтобы рассмотреть вопрос совместного использования полосы пропускания, можно использовать настройки из приведенной выше схемы сети. Генератор пакетов производит различные потоки и посылает их на стоковое устройство. Общего объема трафика, представленного этими потоками, достаточно для перегрузки PVC. CBWFQ внедрен на Маршрутизаторе 2. Конфигурация будет выглядеть так:

access-list 101 permit ip host 7.0.0.200 any 
   access-list 101 permit ip host 7.0.0.201 any 
   access-list 102 permit ip host 7.0.0.1 any 
   ! 
   class-map small 
     match access-group 101 
   class-map big 
     match access-group 102
   !
   policy-map test
   policy-map test 
     small class 
      bandwidth <x>
     big class 
      bandwidth <y>
    interface atm 4/0.102 
     pvc 0/102 
       TX-ring-limit 3 
       service-policy output test 
       vbr-nrt 64000 64000

В нашем примере Router2 является Маршрутизатор Cisco 7200. Это важно, поскольку лимит кольца передачи считается в частицах, а не в пакетах. Пакеты помещаются в очередь FIFO адаптера порта по мере освобождения буферов, даже если для хранения пакета требуется более одного буфера.

Что такое фрагмент?

При фрагментированной буферизации вместо выделения непрерывного блока памяти используются разрозненные фрагменты, называемые "частицами", которые объединяются в один логический буфер пакетов. Это называется "Буфер частиц". В такой схеме пакет может быть распределен по нескольким участкам памяти.

В используемом маршрутизаторе 7200 размер частиц составляет 512 байтов.

Можно проверить, используют ли маршрутизаторы Cisco 7200 частицы с помощью команды show buffers:

router2#show buffers
     [snip]
     Private particle pools: 
     FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
          0 in free list (0 min, 400 max allowed)
          400 hits, 0 fallbacks
          400 max cache size, 271 in cache
     ATM4/0 buffers, 512 bytes (total 400, permanent 400): 
          0 in free list (0 min, 400 max allowed)
          400 hits, 0 fallbacks
          400 max cache size, 0 in cache

Тест А

Классы "Малый" и "Большой", которыми мы будем пользоваться в этом тесте, заполняются следующим образом:

  • Маленький класс – сконфигурированы параметры пропускной способности до 32 кбит/с. Данный класс хранит 10 пакетов по 1500 байтов от 7.0.0.200, за которыми следуют 10 пакетов по 1500 байтов от 7.0.0.201

  • Big class – настроенный параметр пропускной способности 16 кбит/сек. Этот класс хранит один поток десяти 1500 байтовых пакетов от 7.0.0.1.

Генератор трафика передает пакет трафика, предназначенный за устройством приемника в 100 Мбит/с к Router2 в следующем порядке:

  1. Десять пакетов с 7.0.0.1.

  2. Десять пакетов с 7.0.0.200.

  3. Десять пакетов от 7.0.0.201.

Проверка веса потока

Давайте рассмотрим вес, примененный к разным потокам. Для этого можно использовать команду show queue ATM x/y.z.

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated) 

  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Когда все пакеты от 7.0.0.200 были помещены в очередь из маршрутизатора, мы видим придерживающееся:

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)
 
  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255
  
  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Как можно здесь видеть потоки из 7.0.0.200 и 7.0.0.201 имеют одинаковый вес (128). Этот вес составляет половину веса, назначенного потоку от 7.0.0.1 (256). Это соответствует тому, что полоса пропускания малого класса по размеру в два раза меньше, чем крупного класса.

Проверка распределения пропускной способности

Как можно проверить распределение полосы пропускания между различными потоками? Метод организации очередей FIFO используется в каждом классе. Этот малый класс заполнен десятью пакетами первого потока и десятью пакетами второго потока. Первый поток удаляют из малого класса в 32 Кбит/с. После их отправки десять пакетов из другого потока также будут отправлены. Тем временем пакеты из нашего крупного класса удаляются на скорости в 16 кбит/с.

Мы видим, что, так как генератор трафика передает пакет в 100 Мбит/с, будет перегружен PVC. Однако поскольку PVC не передает трафик в самом начале теста, а пакеты от 7.0.0.1 первыми поступают на маршрутизатор, некоторые из этих пакетов будут отправлены до запуска CBWFQ по причине перегрузки (другими словами, до заполнения кольца передачи).

Поскольку размер частицы составляет 512 байт, а размер кольца передачи – три частицы, видно, что перед перегрузкой с адреса 7.0.0.1 были отправлены два пакета. Один пакет немедленно отправляется по проводному соединению, а второй сохраняется в трех частях, формируя очередь FIFO порта адаптера.

Отладочную информацию приемника данных (который является простым маршрутизатором) можно увидеть ниже:

Nov 13 12:19:34.216: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 1482, rcvd 4 
   Nov 13 12:19:34.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- congestion occurs here.


   Nov 13 12:19:34.640: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:34.856: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.280: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.496: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.920: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.136: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.560: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.988: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.200: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.416: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.628: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.840: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.056: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.268: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.480: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.696: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.908: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.136: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.348: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.776: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.988: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.200: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.416: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4  

Поскольку размеры пакетов у обоих потоков одинаковы (основаны на формуле запланированного времени), в ответ на каждый пакет большого класса отправляется два пакета малого класса. Это в точности то, что отображается в отладках, приведенных выше.

Тест B

Что касается второй проверки, заполним классы следующим образом:

  • Маленький класс - значение параметра пропускной способности равно 32 кбит/с. Создаются десять пакетов по 500 байт с 7.0.0.200, которые сопровождаются десятью пакетами по 1500 байт с 7.0.0.201.

  • Big class – настроенный параметр пропускной способности 16 кбит/сек. Этот класс хранит один поток пакетов из 1500 байт, приходящий из 7.0.0.1.

Генератор трафика посылает пакет трафика на скорости 100 Мб/с маршрутизатору 2 в следующем порядке:

  1. Десять пакетов размером 1500 байт с адреса 7.0.0.1.

  2. 10 пакетов размером по 500 байт с адреса 7.0.0.200.

  3. Десять 1500-байтных пакетов из 7.0.0.201.

FIFO настроено во всех классах.

Проверка веса потока

Следующий шаг – проверить вес, приложенный к классифицированным потокам:

alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 23/512/64/0 (size/max total/threshold/drops) 
      Conversations  2/3/16 (active/max active/max total)  
      Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 15/128/0/0/0    
     Conversation 25, linktype: ip, length: 494 
     source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 

   alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 13/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 5/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63,

Как видно по вышеуказанным выходным данным, потоки от 7.0.0.200 и 7.0.0.201 получили один и тот же вес (128). Этот вес составляет половину веса, назначенного потоку от 7.0.0.1. Это соответствует тому факту, что пропускная способность маленького класса в два раза больше, чем пропускная способность большого.

Проверка распределения пропускной способности

Из приемника данных можно провести следующие отладки:

Nov 14 06:52:01.761: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:01.973: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- Congestion occurs here.
 

   Nov 14 06:52:02.049: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.121: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.193: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.269: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.341: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.413: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.629: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:02.701: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.773: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.849: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.921: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:03.149: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.361: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.572: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.788: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.000: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.212: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.640: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.852: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.280: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.492: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.920: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.132: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

Потоки малого класса не имеют идентичного размера пакета в данном сценарии. Поэтому механизм распространения пакетов не настолько прост, как в проверке A, описанной выше.

Установка времени

Рассмотрим поподробнее время планирования каждого пакета. Запланированное время для пакетов вычислено с помощью следующей формулы:

scheduling tail_time= sub_queue_tail_time + pktsize *
     weight

Запланированное время для разных размеров пакетов рассчитывается по следующей формуле:

500 bytes (small class): scheduling tail_time = x + 494 * 128
     = x + 63232 
     1500 bytes (small class): scheduling tail_time = x + 1494 *
     128 = x + 191232 
     1500 bytes (big class): scheduling tail_time = x + 1494 *
     256 = x + 382464

Из этих формул мы может видеть, что на каждые шесть пакетов по 500 байт из нашего малого класса при передаче приходится один пакет по 1500 байт из большого класса (см. вывод отладочной команды выше).

Можно также увидеть, что два пакета 1500 байт из маленького класса, направлены для одного пакета 1500 байт от большого класса (показано выше в выходных данных команды отладки).

На основании вышеуказанных тестов можно сделать следующий вывод:


Дополнительные сведения


Document ID: 10406