Load interval 30 cisco что это

Troubleshooting Interface Drops

Output drops are a result of the traffic rate exceeding the maximum bandwidth specification of a given interface. Given that this is normally an outcome to interface congestion the following steps explain the commands used to clarify the total interface usage in both terms of Mbits and overall utilization.

Output Drop Totals

To confirm the total drops of a particular port the following command is run:

switch#sh int fa0/1 | in drop|bits
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 142478
5 minute input rate 1079000 bits/sec, 5524 packets/sec
5 minute output rate 8688000 bits/sec, 9018 packets/sec

We can also see the interface errors using the following command. The output errors are report here as OutDiscards.

switch#show interface FastEthernet0/1 counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Fa0/1 0 0 0 0 0 179107

Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa0/1 0 0 0 0 0 0 0

Changing Load-Intervals

As you can see from the previous section the load-intervals are configured to 5 minute intervals. To obtain a clearer view of the total throughput of a given interface the load-interval can be reduced to a lower value.

Below we change the load-interval to 30 secs:

switch(config)#interface FastEthernet0/1
switch(config-if)#load-interval 30

switch#sh int fa0/1 | in drop|bits
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 142478
30 second input rate 10079000 bits/sec, 5524 packets/sec
30 second output rate 86888000 bits/sec, 9018 packets/sec

Interface Ultization

To view the overall utilization (%) of an interface the following command is run:

switch#sh controllers fastEthernet 0/1 utilization
Receive Bandwidth Percentage Utilization : 13
Transmit Bandwidth Percentage Utilization : 100

Additional Errors

To display further details of the traffic that has transversed the interface the following command is run :

switch#sh controllers ethernet-controller fastEthernet 0/1
Transmit FastEthernet0/1 Receive
1755650038 Bytes 550748297 Bytes
565241190 Unicast frames 3235647489 Unicast frames
19304109 Multicast frames 0 Multicast frames
3784939 Broadcast frames 671 Broadcast frames
0 Too old frames 550705353 Unicast bytes
0 Deferred frames 0 Multicast bytes
0 MTU exceeded frames 42944 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 1912867443 Minimum size frames
0 8 collision frames 3138104280 65 to 127 byte frames
0 9 collision frames 80595969 128 to 255 byte frames
0 10 collision frames 29329601 256 to 511 byte frames
0 11 collision frames 551146604 512 to 1023 byte frames
0 12 collision frames 1818571559 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 0 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
2417481382 64 byte frames 0 Valid frames, too small
1021375875 127 byte frames
691455767 255 byte frames 0 Too old frames
562825073 511 byte frames 0 Valid oversize frames
292399558 1023 byte frames 0 System FCS error frames
4192727175 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames

QoS в Cisco

[править] Утилиты для классификации и маркировки

[править] Class-Based Marking (CB Marking)

Особенности логики и настройки CB Marking:

Для CB Marking нужно включать CEF, иначе соответствующую service-policy нельзя будет применить на интерфейсе.
CB Marking включается для пакетов входящих или выходящих из интерфейса.
Могут быть настроены несколько команд set для маркировки трафика в нескольких полях.
Пакеты, которые не совпали с явно настроенными class, совпадают со специальным class, который называется class-default.
Если для class не задана команда set, то трафик, который совпадает с ним, не маркируется.

[править] Настройка CB Marking

Маркировка трафика, который совпадает с параметрами class-map определенным значением поля IP Precedence:

Для этой и следующей команды, если указан параметр ip, то значение поля устанавливается только для пакетов IPv4. Если параметр опущен, то значения IPP и DSCP устанавливаются для пакетов IPv4 и IPv6.

Маркировка трафика определенным значением поля DSCP:

Маркировка трафика определенным значением поля CoS:

Указание идентификатора группы для QoS group:

Установка в ячейке ATM бита CLP:

Установка в кадре Frame Relay бита DE:

[править] QoS Pre-Classification

Устройство, на котором выполняется маркировка трафика, может терминировать VPN-туннель. В этом случае в туннельные заголовки (IPsec или GRE) копируется значение поля ToS. Но такие функции как NBAR не могут работать с трафиком, который инкапсулирован в туннельный заголовок.

В IOS существует функция, которая помогает решить этот вопрос — QoS Pre-Classification.

QoS pre-classification «помнит» исходный, не зашифрованный трафик, до тех пор пока не будут выполнены действия QoS в исходящем направлении.

Эта функция может быть включена командой qos pre-classify в таких режимах:

interface tunnel (для GRE и IPIP)
interface virtual-template (для L2F и L2TP)
crypto map (для IPsec)

[править] Просмотр информации

Для того чтобы регулировать частоту с которой проверяется статистика на интерфейсах (packet rate, bit rate) используется команда load-interval. Интервал указывается в секундах, по умолчанию 5 минут:

[править] Управление перегрузками и избежание перегрузок

Управление перегрузками (congestion management) или queuing — каким образом маршрутизатор или коммутатор управляет пакетами или кадрами, пока они ожидают своей очереди для выхода из устройства.

Для маршрутизаторов характерно output queuing, а для коммутаторов input и output queuing.

Избежание перегрузок (congestion avoidance) — логика, которую использует устройство, когда решает отбрасывать ли пакет и когда его отбрасывать, если система очередей становится более загруженной.

[править] Программные и аппаратные очереди

Программная очередь (software queue) — очереди, которые реализованы в программном обеспечении и которыми можно управлять с помощью различных утилит.
Аппаратная очередь (hardware queue) — после того как пакет покидает программную очередь, он попадает в небольшую аппаратную FIFO очередь. В Cisco эта очередь ещё называется transmit queue (TX queue) или transmit ring (TX ring).

Свойства аппаратных очередей:

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

Посмотреть текущий размер аппаратной очереди (для этого маршрутизатора по умолчанию размер очереди 256):

Изменение размера очереди:

После изменения размер аппаратной очереди:

[править] Утилиты управления очередями

Priority queuing (PQ)
Custom queuing (CQ)

Class-based weighted fair queuing (CBWFQ)
Low-latency queuing (LLQ)

Классы определенные в policy-map соответствуют очередям. Поэтому термины очередь (queue) и класс (class) взаимозаменяемы в контексте обсуждения LLQ и CBWFQ.

LLQ и CBWFQ поддерживают 64 очереди. Кроме того, существует одна специальная очередь по умолчанию class-default queue. В эту очередь попадают пакеты, которые НЕ совпали с критериями явно настроенных классов.

[править] CBWFQ

Принципы работы CBWFQ:

Классификация — выполняется на основании любых критериев, которые доступны в MQC с помощью команды match,
Политика отбрасывания пакетов — tail drop или WRED, настраивается для каждой очереди,
Количество очередей — 64,
Максимальная длина очереди — зависит от модели маршрутизатора,
Обслуживание в пределах одной очереди — FIFO в 63 очередях, FIFO или WFQ в class-default queue,
Обслуживание между очередями — на основании выделенной пропускной способности для каждой очереди.

[править] Проверка количества выделенной пропускной способности

Когда policy-map применяется к интерфейсу (команда service-policy output), IOS выполняет проверку не выделяет ли эта policy map слишком много пропускной способности для конкретного интерфейса. Если policy map не проходит проверку, то она не применяется к интерфейсу.

Проверка выполняется на основании двух команд указанных в режиме настройки интерфейса:

bandwidth
max-reserved-bandwidth

IOS позволяет policy map выделять пропускную способность величиной (сумма всех значений bandwidth) не более чем произведение значений bandwidth и max-reserved-bandwidth (по умолчанию 75 процентов).

Пример задания величин на интерфейсе (bandwidth задается в килобитах, а max-reserved-bandwidth а процентах):

После задания таких параметров, если на интерфейс fa0/0 применяется policy-map, то пропускная способность, которая выделена в ней не должна быть более чем 7000.

Применение policy-map на интерфейсе:

Policy-map не была применена так как максимальное значение пропускной способности которое может быть для неё выделено 7000. Первый класс забрал 4000, а оставшихся 3000 не хватает для второго класса. Поэтому и появляется ошибка, что доступно только 3000, а класс запросил 5000.

Существует другой вариант выделения пропускной способности для policy-map. При выделении пропускной способности для класса используются команды:

bandwidth percent — процент пропускной способности выделенной для класса, процент считается от всей пропускной способности интерфейса. Сумма пропускной способности выделенной для классов в policy-map не должна превышать max-reserved-bandwidth настроенной на соответствующем интерфейсе.
bandwidth remaining percent — процент пропускной способности выделенной для класса, процент считается от значения произведения bandwidth и max-reserved-bandwidth интерфейса. Сумма пропускной способности выделенной для классов в policy-map соответственно может быть 100 процентов.

В одной policy-map может использоваться только один из трёх вариантов выделения пропускной способности для класса (bandwidth, bandwidth percent или bandwidth remaining percent).

[править] Размер очереди для CBWFQ

Пример задания размера очереди для класса (диапазон от 1 до 4096 пакетов):

[править] Включение WFQ для класса по умолчанию

Для класса по умолчанию можно включить WFQ (и только для него):

[править] congestive-discard-threshold

[править] LLQ

Синтаксис команды для настройки LLQ:

Команда priority для класса:

включает LLQ,
резервирует пропускную способность,
включает функцию policing,
(опционально) указывает размер burst для policer (по умолчанию 20 процентов).

Пропускная способность может быть задана конкретным значением или процентами от пропускной способности интерфейса. В одной и той же policy-map могут использоваться различные способы указания пропускной способности priority или priority percent.

Суммарная пропускная способность выделенная в policy-map командами priority и bandwidth не должна превышать значение произведения bandwidth и max-reserved-bandwidth.

Фактически LLQ будет использоваться только когда аппаратная очередь заполнена.

Параметр bandwidth указывает максимальное значение пропускной способности, которое выделяется пакетам, которые принадлежат классу в котором указана команда priority. Этот параметр с одной стороны гарантирует указанную пропускную способность классу, с другой — сдерживает поток пакетов приоритетного класса.

Когда устройство не перегружено, то приоритетному классу разрешено превышать указанную пропускную способность. Если устройство перегружено, то трафик приоритетного класса, который превышает указанную пропускную способность, будет отброшен.

Пример policy-map в которой для class1 настроено LLQ:

Просмотр статистики по конкретному классу:

[править] Weighted Round Robin Queuing

Weighted Round Robin (WRR)

[править] Weighted Random Early Detection (WRED)

Tail drop — когда очередь заполнена, IOS начинает отбрасывать новые пакеты.

Weighted Random Early Detection (WRED) — отслеживает длину очереди и отбрасывает некоторый процент пакетов в очереди для улучшения производительности сети.

WRED отбрасывает пакеты до тех пор как очередь заполнится.

Для того чтобы определить достаточно ли полна очередь для того чтобы отбрасывать пакеты WRED измеряет среднюю глубину очереди (average queue depth). Затем, значение average depth сравнивается с minimum threshold и maximum threshold. В зависимости от результата сравнения выполняются различные действия.

Значение average depth относительно threshold	Действие	Название действия в WRED
average < min threshold	Пакеты не отбрасываются	No drop
min threshold < average < max threshold	Процент пакетов отбрасывается. Процент пакетов, которые отбрасываются возрастает от 0 до максимального процента по мере приближения значения average к max threshold	Random drop
average > max threshold	Все новые пакеты отбрасываются	Full drop

Mark probability denominator (MPD) — на основании этого значения вычисляется процент пакетов, которые будут отброшены.

WRED дает больший приоритет пакетам с определенными значениями IPP и DSCP. Для того чтобы сделать это WRED использует разные профили трафика (traffic profile) для пакетов с разными значениями IPP и DSCP.

WRED traffic profile состоит из настроек для трёх переменных:

minimum threshold,
maximum threshold,
MPD.

Профили WRED заданные по умолчанию для DSCP-based WRED:

DSCP	Min threshold	Max threshold	MPD	1/MPD
AFx1	33	40	10	10%
AFx2	28	40	10	10%
AFx3	24	40	10	10%
EF	37	40	10	10%

Exponential weighting constant контролирует насколько быстро меняется средняя глубина очереди. Если значение константы меньше, то средняя глубина очереди меняется быстрее; если константа больше, то — медленнее. По умолчанию используется значение 9.

[править] Настройка WRED

WRED может быть настроен на:

физическом интерфейсе (с FIFO очередью),
для класса (класс должен быть не LLQ) внутри CBWFQ policy-map,
для ATM VC.

Для использования WRED на физическом интерфейсе, IOS отключает остальные механизмы управления очередями и создает одну очередь FIFO.

Команды по настройке WRED аналогичны на интерфейсе и для класса внутри policy-map.

Включение WRED (по умолчанию включается WRED с использованием IPP):

Включение WRED с использованием DSCP для определения профиля трафика:

Изменение настроек по умолчанию WRED для конкретного значения IPP:

Изменение настроек по умолчанию WRED для конкретного значения DSCP:

Exponential weighting constant:

[править] Просмотр настроек

Пример вывода настроек:

[править] Modified Deficit Round-Robin (MDRR)

Утилита MDRR реализована только для маршрутизаторов Cisco 12000, так как они не поддерживают CBWFQ и LLQ.

Читать:

Как перенаправить dns запросы на другой сервер

MDRR позволяет классифицировать трафик на семь round-robin очередей (0-6), с одной дополнительной приоритетной очередью.

Если в приоритетной очереди нет пакетов, то WDRR обслуживает очереди по принципу round-robin. Если в приоритетной очереди есть пакеты, то WDRR может обрабатывать пакеты одним из вариантов:

Strict priority mode — приоритетная очередь обслуживается сразу, как только там появляются пакеты;
Alternate mode — приоритетная очередь обслуживается после каждой не приоритетной очереди.

MDRR поддерживает два типа scheduling.

Quantum value (QV) — количество байтов. WDRR удаляет пакеты из очереди до тех пор пока QV для этой очереди будет удалено.
Deficit — количество байт которые были обработаны сверх нормы (более чем QV). При следующем прохождении цикла с очереди в которой было взято больше байт, будет взято на эту же величину меньше.

[править] Управление перегрузками и избежание перегрузок на коммутаторах

Коммутаторы 3550 и 3560 выполняют входящее и исходящее управление очередями. У 3550 одна входящая очередь работающая по принципу FIFO. У 3560 две входящих очереди, одна из которых может быть настроена как приоритетная очередь.

В 3560 packet scheduler использует метод shared round-robin (SRR) для того чтобы контролировать отправку пакетов. На входящих очередях SRR разделяет пропускную способность между очередями, в соответствии с настроенными весами. Вес выполняет роль относительной, а не абсолютной величины.

Пол умолчанию, трафик промаркированный значением COS 5 попадает во вторую очередь, остальной в первую. Можно настроить назначение трафика в очередь по значению DSCP.

Настройка коэффициентов для очередей (по умолчанию 90 процентов в очередь 1 и 10 процентов в очередь 2):

Настройка процентов для пропускной способности, которые устанавливают частоту с которой scheduler берет пакеты из двух буферов (по умолчанию оба значения 4):

Две указанные команды вместе определяют какое количество данных коммутатор может

Настройка приоритетной очереди:

Коммутатор будет обслуживать приоритетную очередь до тех пор, пока пропускная способность не достигнет настроенного значения weight. После этого остальная пропускная способность разделяется между очередями.

[править] Shaping и Policing

[править] Терминология

Tc — временной интервал, измеряемый в секундах, в течение которого может быть отправлен commited burst (Bc). Для многих shaping утилит Tc=Bc/CIR.
Bc — commited burst rate, измеряется в битах. Количество трафика которое будет отправлено в течение Tc интервала.
CIR — commited information rate, в битах в секунду, определяет rate VC в соответствии с контрактом.
Shaped rate — rate, в битах за секунду, до которого конкретная настройка делает shape трафику. Может быть установлен или нет в значение равное CIR.
Be — excess burst size, в битах. Количество битов, которое может быть отправлено сверх указанного Bc после периода неактивности.

[править] Shaping в сетях Frame-Relay

Minimum information rate (MIR) или mincir.

Уменьшает rate шейпер в том случае, если обнаруживает перегрузку с помощью одного из двух методов:

получает кадр с установленным битом BECN (Backward Explicit Congestion Notification),
получает проприетарное сообщение о перегрузке (congestion message) Cisco ForeSight.

При получении BECN или ForeSight сообщения, шейпер снижает rate на 25 процентов от максимального rate. Фактически уменьшается Bc и Be на 25 процентов, а Tc остается неизменным. Если опять приходит сообщение BECN или ForeSight, то происходит уменьшение ещё на 25 процентов. Так происходит то тех пор пока не будет достигнут mincir.

После получения 16 сообщений без BECN или ForeSight, rate снова возрастает.

[править] Class-based shaping

CB shaping может быть настроен только для исходящих пакетов и может быть применен к физическому интерфейсу или подынтерфейсу.

Должен быть указан shaping rate. Bc и Be могут быть опущены, а Tc не может быть задан напрямую. Соответственно CB shaping высчитывает неуказанные значения. Значения высчитываются по-разному в зависимости от того чему равен shaping rate.

Переменная	Rate <= 320 kbps	Rate > 320 kbps
Bc	8000 bits	Bc = shaping rate * Tc
Be	Be = Bc = 8000	Be = Bc
Tc	Tc = Bc / shaping rate	25ms

[править] CB shaping peak rate

Если CB shaping настроен командой shape peak, то:

значения Bc, Be, Tc высчитываются как и для команды shape average,
токены Bc и Be (а не только Bc) пополняются каждый временной интервал.

[править] Generic Traffic Shaping

[править] Frame-Relay traffic shaping

Frame-Relay traffic shaping (FRTS):

FRTS может использоваться только на frame-relay интерфейсах, а CB shaping может использоваться для любого протокола канального уровня.
Как и CB shaping, FRTS позволяет использовать утилиты для управления очередями вместо одной очереди FIFO.
В отличие от CB shaping, FRTS не позволяет включать дополнительные утилиты управления очередями на физическом интерфейсе одновременно с FRTS.
FRTS всегда шейпит трафик в каждой VC отдельно.
FRTS не может классифицировать трафик для того чтобы шейпить часть трафика конкретной VC.
В отличие от CB shaping, FRTS может динамически получать значение CIR, Bc и Be, настроенные на FR-коммутаторе, используя Enhanced Local Management Interface (ELMI).

Пример явного указания параметров:

Настройка динамического реагирования маршрутизатора на основании BECN:

[править] CB policing

CB policing разделяет пакеты на две или три категории, в зависимости от вида policing, а затем применяет к каждой категории соответствующее действие.

conforming
exceeding
violating

[править] Single-rate, two-color policing (one bucket)

Policer использует две категории:

conform
exceed

CB Policer заполняет bucket не на основании временных интервалов, а на основании пакетов.

Количество токенов высчитывается по формуле:

Так как токен представляет право на передачу одного байта, то результат разделен на 8, чтобы перевести его из битов в байты.

Когда приходит новый пакет, policer должен определить превышает или нет этот пакет установленный контракт.

Policer сравнивает количество байт в пакете (Xp) с количеством токенов в token bucket (Xb).

Категория	Требования	Токены, которые забраны из bucket
Conform	Если Xp <= Xb	Xp токенов
Exceed	Если Xp > Xb	не забираются

[править] Single-rate, three-color policing (two buckets)

Policer использует три категории:

conform
exceed
violate

Xbc — количество токенов в Bc bucket, Xbe — количество токенов в Be bucket.

Категория	Требования	Токены, которые забраны из bucket
Conform	Если Xp <= Xbc	Xp токенов из Bc bucket
Exceed	Если Xp > Xbc и Xp <= Xbe	Xp токенов из Be bucket
Violate	Если Xp > Xbc и Xp > Xbe	не забираются

[править] Two-rate, three-color policing (two buckets)

Commited information rate (CIR)
Peak information rate (PIR)