Базовые сведения о работе с коммутаторами Cisco
Данная статья когда-то разрабатывалась, как пособие по основам работы с коммутаторами для «самых начинающих» инженеров. Постараемся в нём рассмотреть практические аспекты работы, не закапываясь особенно в теорию коммутации. В качестве подопытной зверушки у нас будут выступать коммутатор L3 серии Cisco Catalyst 3560 – достаточно универсальная железка, позиционируемая производителем как коммутатор корпоративного класса с фиксированной конфигурацией. Может применяться, как на уровне доступа, так и на уровне распределения.
При написании статьи предполагается, что читающий уже знаком с основами работы в Cisco IOS, или способен разобраться с встроенной системой помощи, благо, что она достаточно информативна и дружелюбна. Также предполагается само собой разумеющимся хотя бы базовое знание технологий TCP/IP и модели OSI.
Базовая конфигурация режимов работы портов.
Поскольку в построении сети практически невозможно обойтись без использования VLAN, то первое, на что мы обратим внимание – это два основных режима работы портов для передачи тегированного и нетегированного трафика, или, в терминологии Cisco – trunk & access соответственно.
К access порту подключаются, как правило, оконечные устройства, не умеющие работать с тегированным трафиком, а к trunk – каналы для передачи данных по различным VLAN в сети.
Конфигурация access-порта предельно проста, и выглядит примерно так:
interface FastEthernet0/4
description –simple access port—
switchport access vlan 100
switchport mode access
Настраивается, соответственно, так:
sw1.cs.ntk#conf t
Enter configuration commands, one per line. End with CNTL/Z.
sw1(config)#interface fastEthernet0/4
sw1(config-if)# description —SKY-CONTROL—
Задаем описание интерфейса. Не обязательно, но очень помогает в документации сети.
sw1(config-if)# switchport access vlan 100
Устанавливаем VLAN в который будет попадать трафик при входе в этот интерфейс. Соответственно, при выходе кадров из него, метки VLAN снимаются.
sw1(config-if)# switchport mode access
Переключаем порт в режим access.
Базовая конфигурация транковых портов тоже элементарна:
interface FastEthernet0/21
description –simple trunk port—
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 952, 953
switchport mode trunk
Как мы видим – добавляется только список разрешенных к прохождению VLAN (не обязательно, но в целях безопасности лучше применить) и применяемый стандарт энкапсуляции – dot1q, пропиетарный Cisco ISL, или автосогласование.
Транковый порт сам по себе не умеет работать с нетегированным трафиком, поэтому такой трафик будет просто отброшен. Для его обработки можно настроить на портах native vlan. Любой пакет, не принадлежащий к определенному VLAN будет помечаться меткой native vlan, а трафик из данного vlan будет передаваться в транковый порт нетегированным.
Стоит заметить, что конфигурация порта при переключении его из одного режима в другой не изменяется, в отличие от режима его работы. Поэтому порт, сконфигурированный, как показано ниже, будет работать в trunk. Стоит ориентироваться только на switchport mode или, на вывод информации, как будет изложено далее.
interface FastEthernet0/21
description — port — switchport access vlan 2
switchport trunk encapsulation dot1q
switchport mode trunk
Конфигурация скорости и дуплекса.
Несмотря на повсеместное распространение автосогласования работы портов, зачастую встречаются проблемы, связанные с некорректной работой автосогласования, в результате чего порт может постоянно «прыгать» из рабочего состояние в нерабочее и генерировать ошибки. Поэтому самым надежным путем решения данной проблемы является ручной перевод портов на обои концах линка в одинаковый режим работы.
Конфигурируется элементарно, следующими командами:
sw1(config-if)#speed?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration
sw1(config-if)#duplex?
auto Enable AUTO duplex configuration
full Force full duplex operation
half Force half-duplex operation
О диагностике проблем, связанных с автосогласованием будет сказано далее.
Сами VLAN создаются так:
ors-sw-ortpc(config)#vlan 777
ors-sw-ortpc(config-vlan)#name test_vlan
ors-sw-ortpc(config-vlan)#exit
Просмотр информации о созданных VLAN – show vlan
Catalyst 3560 поддерживает до 1005 созданных VLAN. Возникает вопрос – что делать, если число созданных VLAN подходит к концу, а нужно подключить скажем, новый сегмент сети? Или же, до новой БС присоединяющий оператор выделил 1 VLAN, а нам нужно пробрасывать свой VLAN. В таком случае можно использовать dot1q tunneling, или Q-in-Q – двойное тегирование VLAN. В таком случае на входе транспорта внуть одного VLAN упаковываются остальные VLAN, и распаковываются на выходе. Сражу стоит отметить что 29хх серия Catalyst, в отличие от 35xx, 37xx такой режим работы не поддерживает.
Настраивается тоже достаточно элементарно:
sw1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
sw1(config)#interface fa0/17
sw1(config-if)#description – QinQ double encapsulation — sw1(config-if)#switchport mode dot1q-tunnel
sw1(config-if)#switchport access vlan 77
interface FastEthernet0/17
switchport access vlan 77
switchport mode dot1q-tunnel
end
Таким образом настроенный порт все приходящие пакеты будет энкапсулировать в VLAN 77, который и будет виден для всех устройств, находящихся далее. Достаточно передать данный VLAN до того узла, на котором необходимо развернуть обратно, и там распаковать, используя аналогичные настройки порта.
При этом, возможно, нужно будет увеличить MTU по данному пути на 4 байта, для обеспечения дополнительной метки vlan tag.
Адресация и маршрутизация.
Catalyst 3560 может работать как на третьем уровне сетевой модели, так и на втором. В любом случае для доступа к нему необходимо присвоить ему IP адрес в требуемом VLAN (как правило, для управления устройствами выделяется отдельный VLAN) и настроить маршрутизацию.
interface Vlan100
ip address 192.168.10.254 255.255.255.0
ip default-gateway 192.168.10.1
Тем самым мы назначили коммутатору IP-адрес 192.168.10.254/24 в 100м VLAN и установили шлюзом по умолчанию 192.168.10.1. При такой схеме коммутатор используется как L2. Включить L3 маршрутизацию можно командой ip routing. При этом становится возможным задавать множество маршрутов, и просматривать, соответственно, таблицу маршрутизации (show ip route). Естественно, перед переключение необходимо сначала указать маршруты, чтобы не потерять управление коммутатором из другой сети.
conf t
ip route 0.0.0.0 0.0.0.0 192.168.10.1
Получение и обработка информации.
Думаю, тут стоит рассмотреть практические примеры с пояснениями:
show interfaces status – выводит общую информацию по всем портам.
sw1#show interfaces status
Port Name Status Vlan Duplex Speed Type
Fa0/1 Sector-1 connected trunk a-full a-100 10/100BaseTX
Fa0/2 Sector-2 connected trunk a-full a-100 10/100BaseTX
Fa0/3 Sector-3 connected trunk a-full a-100 10/100BaseTX
Fa0/4 notconnect 1 auto auto 10/100BaseTX
Fa0/5 port connected 100 a-full a-100 10/100BaseTX
Fa0/6 connected trunk full 100 10/100BaseTX
Fa0/7 disabled 100 auto auto 10/100BaseTX
Здесь мы можем видеть:
Собственно, сам порт, его имя (задаваемое description).
Status – порта – подключен и поднят (connected)/не подключен физически (notconnect) либо административно отключен (disabled).
Vlan – режим работы порта – trunk, или соответствующий access vlan.
Дуплекс и скорость порта – авто, или же жестко заданные установки (Fa0/6 – принудительно в режиме 100 Mb, full duplex.), Обратите внимание что на нерабочих интерфейсах прописано auto.
sh interfaces – просмотр подробной информации об указанном интерфейсе.
sw1#sh interfaces fa0/21
FastEthernet0/21 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001f.0001.0001 (bia 001f.0001.0001)
Description: — some port — MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:06, output hang never
Last clearing of «show interface» counters 17w4d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1056000 bits/sec, 203 packets/sec
5 minute output rate 551000 bits/sec, 269 packets/sec
1015031190 packets input, 556493190204 bytes, 0 no buffer
Received 8800603 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 5337282 multicast, 0 pause input
0 input packets with dribble condition detected
1761812043 packets output, 340685749958 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Is up, line protocol is up (connected) — Первое «up» относится к состоянию физического уровня передачи данных интерфейса. Сообщение «line protocol up» показывает состояние уровня канала передачи данных для данного интерфейса и означает, что интерфейс может отправлять и принимать запросы keepalive.
Для сравнения
FastEthernet0/4 is down, line protocol is down (notconnect) – порт отключен.
FastEthernet0/7 is administratively down, line protocol is down (disabled) – отключен административно (shutdown).
Full-duplex, 100Mb/s (полнодуплексный, 100 Мбит/с) — текущая скорость и режим дуплексирования для данного интерфейса. Заметьте, что сейчас невозможно узнать – было ли включено автосогласование для порта.
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
– очередь входа для пакетов. На коммутаторах данной серии не используется, но служит для отброса пакетов с низким приоритетом в случае перегрузки CPU. Общее число сбросов. Стоит заметить, что типичной причиной сброса пакетов может быть прием трафика в канал с меньшей пропускной способностью из более широкого канала.
5 minute input rate 1056000 bits/sec, 203 packets/sec
5 minute output rate 551000 bits/sec, 269 packets/sec
Скорость ввода/вывода трафика за 5 минут – в битах и пакетах. Возможно подсчитывать трафик за иные промежутки времени – для этого используется команда load-interval. Однако, это ведет к увеличению загрузки CPU.
sw1(config)#int fa0/1
sw1(config-if)#load-interval?
Load interval delay in seconds
1015031190 packets input, 556493190204 bytes, 0 no buffer
Received 8800603 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 5337282 multicast, 0 pause input
0 input packets with dribble condition detected
1761812043 packets output, 340685749958 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Далее показаны текущие счетчики ошибок, являющиеся важнейшим инструментом в диагностике возникающих проблем.
Счетчики ошибок на самом деле разбросаны по разным местам IOS, но для примера можно рассмотреть следующее:
sw1#sh interfaces fa0/1 counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Fa0/1 0 0 0 3 1.46E+08
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa0/1 0 0 0 0 0 3 64
Счетчик и некоторые рекомендации:
Align-Err
Количество ошибок выравнивания.
Как правило, увеличение данного счетчика свидетельствует о проблемах согласования дуплексных режимов, либо о наличии проблемы на физическом уровне.
collisions
Число коллизий произошедших до окончания передачи пакета. Нормальное явление для полудуплексного интерфейса. Быстрый рост счетчика может быть вызван высокой загрузкой интерфейса, либо несоответствием режимов дуплекса.
CRC
Несовпадение контрольной суммы кадра.
Обычно является результатом конфликтов, но может указывать и на физическую неполадку. В некоторых случаях возможны наводки на физику ЛВС, либо помехи.
pause input
Подключенное устройство запрашивает приостановку передачи трафика при переполнении его буфера.
Excess-ColПодобно коллизиям не должно наблюдаться на полнодуплексном интерфейсе.
FCS-Err
Ошибки в контрольной последовательности кадров.
Как правило, увеличение данного счетчика свидетельствует о проблемах согласования дуплексных режимов, либо о наличии проблемы на физическом уровне.
ignored
Может быть признаком широковещательного шторма в сети.
Late-Col
Коллизии на последних этапах передачи кадра. Не должны наблюдаться на полнодуплексном порту.
lost carrier
Потеря несущей. Проблемы на физическом уровне.
Underruns
Скорость передатчика превышает возможности коммутатора.
Undersize
Полученные кадры с размером меньше минимума. Необходимо проверить устройство, посылающее такие кадры.
Для получения подробной информации по обработанным пакетам можно использовать команду
sh controllers ethernet-controller
Пример вывода:
sw1 #sh controllers ethernet-controller fa0/21
Transmit FastEthernet0/1 Receive
665578020 Bytes 662563391 Bytes
3057832162 Unicast frames 2887447872 Unicast frames
2443399319 Multicast frames 100518228 Multicast frames
132541948 Broadcast frames 90307083 Broadcast frames
0 Too old frames 533536518 Unicast bytes
0 Deferred frames 3228404572 Multicast bytes
0 MTU exceeded frames 1010212552 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 145990113 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 735750877 Minimum size frames
0 8 collision frames 1557036200 65 to 127 byte frames
0 9 collision frames 305275380 128 to 255 byte frames
0 10 collision frames 95908725 256 to 511 byte frames
0 11 collision frames 126755638 512 to 1023 byte frames
0 12 collision frames 257546363 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 64 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
521536351 64 byte frames 145990113 Valid frames, too small
3679829207 127 byte frames
317941784 255 byte frames 0 Too old frames
197523329 511 byte frames 64 Valid oversize frames
114203781 1023 byte frames 0 System FCS error frames
802738977 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:
router(config-pmap-c)# set [ip] precedence
Для этой и следующей команды, если указан параметр ip, то значение поля устанавливается только для пакетов IPv4. Если параметр опущен, то значения IPP и DSCP устанавливаются для пакетов IPv4 и IPv6.
Маркировка трафика определенным значением поля DSCP:
router(config-pmap-c)# set [ip] dscp
Маркировка трафика определенным значением поля CoS:
router(config-pmap-c)# set cos
Указание идентификатора группы для QoS group:
router(config-pmap-c)# set qos-group
Установка в ячейке ATM бита CLP:
router(config-pmap-c)# set atm-clp
Установка в кадре Frame Relay бита DE:
router(config-pmap-c)# set fr-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 минут:
dyn5(config-if)# load-interval
[править] Управление перегрузками и избежание перегрузок
Управление перегрузками (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):
dyn5# sh controllers fa0/0 . tx_limited=0(256) .
Изменение размера очереди:
dyn5(config)# int fa0/0 dyn5(config-if)# tx-ring-limit 3
После изменения размер аппаратной очереди:
dyn5# sh controllers fa0/0 . tx_limited=0(3) .
[править] Утилиты управления очередями
- 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 не проходит проверку, то она не применяется к интерфейсу.
Проверка выполняется на основании двух команд указанных в режиме настройки интерфейса:
IOS позволяет policy map выделять пропускную способность величиной (сумма всех значений bandwidth) не более чем произведение значений bandwidth и max-reserved-bandwidth (по умолчанию 75 процентов).
Пример задания величин на интерфейсе (bandwidth задается в килобитах, а max-reserved-bandwidth а процентах):
dyn5(config)# int fa0/0 dyn5(config-if)# bandwidth 10000 dyn5(config-if)# max-reserved-bandwidth 70
После задания таких параметров, если на интерфейс fa0/0 применяется policy-map, то пропускная способность, которая выделена в ней не должна быть более чем 7000.
dyn5(config)# policy-map test-bw dyn5(config-pmap)# class class1 dyn5(config-pmap-c)# bandwidth 4000 dyn5(config-pmap)# class class2 dyn5(config-pmap-c)# bandwidth 5000
Применение policy-map на интерфейсе:
dyn5(config-if)# service-policy output test-bw I/f FastEthernet0/0 class class2 requested bandwidth 5000 (kbps), available only 3000 (kbps)
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 процентов.
dyn5(config)# policy-map test-bw dyn5(config-pmap)# class class1 dyn5(config-pmap-c)# bandwidth percent 20
В одной policy-map может использоваться только один из трёх вариантов выделения пропускной способности для класса (bandwidth, bandwidth percent или bandwidth remaining percent).
[править] Размер очереди для CBWFQ
Пример задания размера очереди для класса (диапазон от 1 до 4096 пакетов):
dyn5(config)# policy-map test-bw dyn5(config-pmap)# class class1 dyn5(config-pmap-c)# queue-limit 500
[править] Включение WFQ для класса по умолчанию
Для класса по умолчанию можно включить WFQ (и только для него):
dyn5(config)# policy-map test-bw dyn5(config-pmap)# class class-default dyn5(config-pmap-c)# fair-queue
[править] congestive-discard-threshold
fair-queue [congestive-discard-threshold]
[править] LLQ
Синтаксис команды для настройки LLQ:
dyn5(config-pmap-c)# priority > [burst-size]
Команда 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:
dyn5(config)# policy-map test-bw dyn5(config-pmap)# class llq-class dyn5(config-pmap-c)# priority percent 30
dyn5# sh policy-map test-bw Policy Map test-bw Class llq-class Strict Priority Bandwidth 30 (%)
Просмотр статистики по конкретному классу:
dyn5# sh policy-map interface fa0/0 output class llq-class FastEthernet0/0 Service-policy output: test-bw Class-map: llq-class (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: none Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 30 (%) Bandwidth 30000 (kbps) Burst 750000 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0
[править] Weighted Round Robin Queuing
Weighted Round Robin (WRR)
sw(config-if)# wrr-queue cos-map queue-id threshold-id cos-1. cos-n
wrr-queue priority-queue
sw(config-if)# wrr-queue bandwidth
[править] 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 состоит из настроек для трёх переменных:
Профили 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):
dyn5(config-if)# random-detect
Включение WRED с использованием DSCP для определения профиля трафика:
dyn5(config-if)# random-detect dscp-based
Изменение настроек по умолчанию WRED для конкретного значения IPP:
dyn5(config-if)# random-detect precedence
Изменение настроек по умолчанию WRED для конкретного значения DSCP:
dyn5(config-if)# random-detect dscp
Exponential weighting constant:
dyn5(config-if)# random-detect exponential-weighting-constant
[править] Просмотр настроек
dyn5# sh queueing [interface | custom | fair | priority | random-detect]
Пример вывода настроек:
dyn5# sh queueing Current fair queue configuration: Current DLCI priority queue configuration: Current priority queue configuration: Current custom queue configuration: Current random-detect configuration: FastEthernet0/0 Queueing strategy: random early detection (WRED) Random-detect not active on the dialer Exp-weight-constant: 9 (1/512) Mean queue depth: 0 class Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes thresh thresh prob 0 0/0 0/0 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 3 0/0 0/0 26 40 1/10 4 0/0 0/0 28 40 1/10 5 0/0 0/0 31 40 1/10 6 0/0 0/0 33 40 1/10 7 0/0 0/0 35 40 1/10 rsvp 0/0 0/0 37 40 1/10 Current per-SID queue configuration:
[править] Modified Deficit Round-Robin (MDRR)
Утилита MDRR реализована только для маршрутизаторов Cisco 12000, так как они не поддерживают CBWFQ и LLQ.
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.
switch# show mls qos maps cos-input-q
switch# show mls qos maps dscp-input-q
Настройка коэффициентов для очередей (по умолчанию 90 процентов в очередь 1 и 10 процентов в очередь 2):
switch(config)# mls qos srr-queue input buffers
Настройка процентов для пропускной способности, которые устанавливают частоту с которой scheduler берет пакеты из двух буферов (по умолчанию оба значения 4):
switch(config)# mls qos srr-queue input bandwidth
Две указанные команды вместе определяют какое количество данных коммутатор может
Настройка приоритетной очереди:
switch(config)# mls qos srr-queue input priority-queue bandwidth
Коммутатор будет обслуживать приоритетную очередь до тех пор, пока пропускная способность не достигнет настроенного значения 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 может быть настроен только для исходящих пакетов и может быть применен к физическому интерфейсу или подынтерфейсу.
dyn5(config-pmap-c)# shape [average | peak] [[burst-size][exceed-burst-size]]
Должен быть указан shaping rate. Bc и Be могут быть опущены, а Tc не может быть задан напрямую. Соответственно CB shaping высчитывает неуказанные значения. Значения высчитываются по-разному в зависимости от того чему равен shaping rate.
| Переменная | Rate | 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) пополняются каждый временной интервал.
Shaping rate = configured rate (1 + 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).
dyn5(config)# map-class frame-relay testFR dyn5(config-map-class)# frame-relay traffic-rate [peak]
Пример явного указания параметров:
dyn5(config)# map-class frame-relay testFR dyn5(config-map-class)# frame-relay cir 64000 dyn5(config-map-class)# frame-relay bc 640
Настройка динамического реагирования маршрутизатора на основании BECN:
dyn5(config-map-class)# frame-relay adaptive-shaping
[править] CB policing
CB policing разделяет пакеты на две или три категории, в зависимости от вида policing, а затем применяет к каждой категории соответствующее действие.
- conforming
- exceeding
- violating
[править] Single-rate, two-color policing (one bucket)
Policer использует две категории:
CB Policer заполняет bucket не на основании временных интервалов, а на основании пакетов.
Количество токенов высчитывается по формуле:
((current_packet_arrival_time - Previous_packet_arrival_time) * Police_rate) / 8
Так как токен представляет право на передачу одного байта, то результат разделен на 8, чтобы перевести его из битов в байты.
Когда приходит новый пакет, policer должен определить превышает или нет этот пакет установленный контракт.
Policer сравнивает количество байт в пакете (Xp) с количеством токенов в token bucket (Xb).
| Категория | Требования | Токены, которые забраны из bucket |
|---|---|---|
| Conform | Если Xp | Xp токенов |
| Exceed | Если Xp > Xb | не забираются |
[править] Single-rate, three-color policing (two buckets)
Policer использует три категории:
Xbc — количество токенов в Bc bucket, Xbe — количество токенов в Be bucket.
| Категория | Требования | Токены, которые забраны из bucket |
|---|---|---|
| Conform | Если Xp | Xp токенов из Bc bucket |
| Exceed | Если Xp > Xbc и Xp | Xp токенов из Be bucket |
| Violate | Если Xp > Xbc и Xp > Xbe | не забираются |
[править] Two-rate, three-color policing (two buckets)
- Commited information rate (CIR)
- Peak information rate (PIR)
Policer использует три категории:
- conform — пакеты передающиеся до CIR,
- exceed — пакеты передающиеся выше CIR, но до PIR,
- violate — пакеты передающиеся выше PIR.
| Категория | Требования | Токены, которые забраны из bucket |
|---|---|---|
| Conform | Если Xp | Xp токенов из Bc bucket и Xp токенов из Be bucket |
| Exceed | Если Xp > Xbc и Xp | Xp токенов из Be bucket |
| Violate | Если Xp > Xbc и Xp > Xbe | не забираются |
[править] Настройка CB policing
police cir 8000 bc 1000 be 500 conform-action transmit exceed-action transmit violate-action drop
Если не указаны значения Bc или Be, то используются значения по умолчанию, которые зависят от типа policing.
| Тип policing | Как определить тип по команде police | Значения по умолчанию |
|---|---|---|
| Single rate, two color | не настроено violate-action | Bc = CIR/32, Be = 0 |
| Single rate, three color | настроено violate-action | Bc = CIR/32, Be = Bc |
| Dual rate, three color | настроено PIR | Bc = CIR/32, Be = PIR/32 |
[править] Multi-action policing
Multi-action policing — маркировка нескольких полей в одном пакете с помощью CB policing.
[править] Commited access rate (CAR)
CAR это single-rate, two-color policing.
CAR оптимизирован для высокоскоростных соединений.
CAR применяется для входных и выходных интерфейсов (включая подинтерфейсы в том числе Frame Relay и ATM)
может так же использоваться для предотвращения DOS атак.
dyn5(config-if)# rate-limit [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action action exceed-action action
- access-group — аксесс лист классификации
- bps — скорость бит/с (commited access rate)
- burst-normal — размер всплеска рекомендовано считать по формуле ([4]):
- burst-normal = bps * (1 byte)/(8 bits) * 1.5 seconds
- burst-max — максимальный размер всплеска
- burst-max=burst-normal*2
- conform-action action — действие при соответствии ограничения
- exceed-action action — действие при превышении ограничения
- Возможные варианты действий:
- drop – уничтожить
- transmit — передать
- set-dscp-transmit – пометить пакет
interface Tunnel122 ip address 10.84.239.230 255.255.255.252 ip mtu 1420 rate-limit input access-group 199 8000 1600 2000 conform-action transmit exceed-action drop . end
Просмотр трафика, который попадает под CAR:
sm-sht-c2811#sh int tu 122 rate-limit Tunnel122 crypto tunnel sm Input matches: access-group 199 params: 8000 bps, 1600 limit, 2000 extended limit conformed 23741 packets, 1994692 bytes; action: transmit exceeded 3210 packets, 184395 bytes; action: drop last packet: 1149595396ms ago, current burst: 0 bytes last cleared 14w0d ago, conformed 0 bps, exceeded 0 bps
На интерфейс можно описывать любое число правил, ограничивающих трафик на данном интерфейсе
Следующий пример ограничивает ICMP трафик до 500 kb/s, а так же UDP трафик до уровня 2 Мб/s на одном из интерфейсов! sm-c3660(config-if)#rate-limit input access-group 100 500000 62500 62500 conform-action transmit exceed-action drop sm-c3660(config-if)#rate-limit input access-group 101 2010000 250000 250000 conform-action transmit exceed-action drop ! sm-c3660(config)#access-list 100 permit icmp any any sm-c3660(config)#access-list 101 permit udp any any
[править] rate-limit ACL
dyn1(config)# access-list rate-limit ? Precedence ACL index MAC address ACL index mpls exp ACL index
dyn1(config)# access-list rate-limit 1 mask
Порядок вычисления параметра mask:
- Определить какие значения IPP нужны.
- Каждому значению IP precedence соответствует бит в выделенном байте:
- 00000001 — 0
- 00001000 — 3
- 00100001 — 5
- Сложить получившиеся 8мибитные числа. Например, если необходимо совпадение значений 0, 3 и 5, то итоговое значение будет 00101001.
- Перевести полученное значение в соответствующее шестнадцатеричное число. Для приведенного примера это будет число 0x29.
- Настроить соответствующий ACL. Для указанного примера: access-list rate-limit 1 mask 29.
[править] QoS Policy Propagation через BGP (QPPB)
[править] Дополнительная информация
- Class-Based Shaping Configuration
- Shaping vs. Policing At A Glance
- Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting (англ.)
- QoS для DMVPN
- Understanding How Routing Updates and Layer 2 Control Packets Are Queued on an Interface with a QoS Service Policy (pak_priority) (англ.)
- Bridging the gap between 3550 and 3560 QoS: Part I (англ.)
- Bridging the gap between 3550 and 3560 QoS: Part II (англ.)
- Traffic Classification in the 3550/3560 Switches (англ.)
- Comparing Traffic Policing Features in the 3550 and 3560 switches (англ.)
- Quick Notes on the 3560 Egress Queuing (англ.)
Cisco Systems, Inc. Устройства Cisco 871 • Cisco Router • Cisco Switch • Сisco Сatalyst • Cisco IPS • Cisco ASA • PIX • Dynamips Безопасность
(коммутаторы и
маршрутизаторы)Cisco Security • Port security • DHCP snooping • Dynamic ARP Protection • IP Source Guard • Аутентификация при доступе к сети • 802.1X в Cisco • Zone-Based Policy Firewall • Cisco NAT • NAT в Cisco • Cisco SSH Cisco ASA Cisco ASA/NAT • Cisco ASA/Troubleshooting • Cisco ASA/IPS • Cisco ASA failover • Cisco ASA/Transparent firewall • Cisco ASA/Site-to-Site_VPN • Cisco ASA/Easy_VPN • Cisco ASA/WebVPN • Объединение OSPF-сетей туннелем между двумя системами ASA (без GRE) • Центр сертификатов на Cisco ASA VPN IPsec в Cisco • Cisco IOS Site-to-Site VPN • DMVPN • Cisco Easy VPN • Cisco Web VPN • Cisco ipsec preshared Канальный уровень CDP • VLAN в Cisco • ISL • VTP • STP в Cisco • Cisco Express Forwarding • Агрегирование каналов • Зеркалирование трафика • QinQ • Frame Relay Сетевой уровень Маршрутизация в Cisco • RIP • EIGRP • IS-IS • OSPF • BGP • PIM • Multicast • GLBP • VRRP • HSRP • DHCP • IPv6 • IPv6 vs IPv4 • Резервирование Интернет-каналов без использования BGP • Использование BGP для резервирования Интернет-каналов Разное Режим ROMMON в Cisco • Опция 82 DHCP • 802.1X и RADIUS • SNMP в Cisco • QoS в Cisco • EEM • Troubleshooting • Автоматизация работы устройств Cisco • Cisco NTP • Cisco IP SLA • Cisco Enhanced Object Tracking Load interval 30 cisco что это
Что нам расскажет Cisco FastEthernet Interface status. Сейчас мы подробно разберем что полезного рассказывают нам цыски(cisco) при вводе команды show interface. Понимание этой информации, а главное верная ее интерпритация может сэкономить много времени, сил, а иногда и средств при решении проблем со связью.
Я приведу сводку по основным параметрам выводимым по комманде show interface на маршрутизаторе Cisco.
FastEthernet0/0 is up
Показывает что интерфейс аппаратно активен (в интерфейс воткнут патч и есть сигнал на контрольных цепях).Line protocol is up
Показывает что программа поддержки физического протокола считает интерфейс рабочим (с удаленной стороны приходят keepalive).MTU 1500 bytes
Размер MTU (Maximum Transmission Unit) установленного на интерфейсе.BW 100000 Kbit
Полоса пропускания (bandwidth) интерфейса в килобитах в секунду. Значение устанавливается командой «bandwidth» в режиме конфигурации интерфейса. Не влияет на реальную полосу пропускания интерфейса. Учитывается протоколами динамической маршрутизации при выборе оптимального маршрута. И при расчете параметров txload/rxload.DLY 100 usec
Задержка вносимая интерфейсом при передаче пакетов в микросекундах.reliability 255/255
Надежность интерфейса как доля от 255 (255/255 означает 100% надежность), расчитывается как экспоненциальное среднее. Если наблюдаются прорблемы на 1 или 2 уровне, значение надежности понижается. Например: 236/255.txload 1/255, rxload 1/255
Загрузка интерфейса на прием/передачу как доля от 255 (255/255 означает полностью загруженный интерфейс). Расчитывается на основе параметра «bandwidth» заданного на интерфейсе.Encapsulation ARPA
Тип инкапсуляции сконфигурированный на интерфейсе.Keepalive set (10 sec)
Пакет keepalive посылается каждые 10 секунд для поддержания линка в работе.Full-duplex, 100Mb/s, 100BaseTX/FX
Параметры дуплекса, скорости, и тип стандарта линии. Несовпадение этих параметров чаще всего является причиной отсутствия связи через интерфейс.Last clearing of «show interface» counters 00:00:02
Информативный параметр. Показывает когда последний раз выполнялась команда сброса счетчиков интерфейса «clear counters«.
Показывает за какое время накоплена статистика по интерфейсу.Queueing strategy: fifo
Показывает какой тип очереди сконфигурирован на интерфейсе. В примере — очередь первый пришел — первый ушел (fifo — first in, first out).Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Количество пакетов стоящих во входящей и исходящей очередях. Если интерфейс перегружен — будет расти количество дропов.30 minute input rate 624000 bits/sec, 254 packets/sec
30 minute output rate 571000 bits/sec, 231 packets/sec
Средняя скорость входящего и исходящего трафика за период (в примере за 30 минут). По умолчанию период усреднения 5 минут. Минимальный период — 30 секунд. Задается командой «load-interval» в режиме конфигурации интерфейса.runts
Если контрольная сумма пакета CRC правильная, а сам пакет меньше, чем минимальный размер установленный стандартом Ethernet, пакет отклоняется. Счетчик runts показывает количество пакетов отклоненных по причине их малого размера. Любой пакет меньше 64 байт на FastEthernet интерфейсе отбрасывается как runts.giants(Jabber)
Если контрольная сумма пакета CRC правильная, а сам пакет больше, чем минимальный размер установленный стандартом Ethernet, пакет отклоняется. Счетчик giants(Jabber) показывает количество пакетов отклоненных по причине их малого размера. Любой пакет больше 1518 байт на FastEthernet интерфейсе отбрасывается как giants(Jabber).input errors
Общее количество ошибок на интерфейсе. Сумма счетчиков runts, giants, no buffer, CRC, frame, overrun, ignored.CRC
Счетчик пакетов с неправильной контрольной суммой CRC (Cyclic Redundancy Checksum). Обычно растет при наличии проблем на физическом уровне, при несовпадении режима дуплекса или при наличии повреждений/помех на физике.frame
Количество пакетов полученных с поврежденой структурой кадра.overrun
Счетчик количества ошибок вызванных неспособностью приемника обработать входящий поток данных: пакеты на интерфейс из сети приходят а передать их в буфер интерфейс не успевает. При росте таких ошибок необходимо проверить загрузку процессора устройства (команды show processes cpu и show processes cpu history).ignored
Счетчик количества пакетов отброшенных интерфейсом по причине занятости внутреннего буфера интерфейса.watchdog
Счетчик истечения интервала ожидания приема пакета. Ситуация возникает при получении пакета длинной более 2048 байт.input packets with dribble condition detected
Как пишут цыски — счетчик указывающи количество кадров которые «немного длиннее» стандартного. Информативный параметр так как роутер такие кадры принимает.packets output
Общее количество переданных пакетов.antiCisco blogs
Выезжаем на перекресток (Настройка очередизации на коммутаторах Cisco Catalyst 2960/3560/3750)
Опубликовано Stratosphere 29 Январь , 2013
Наконец-то очередная статья на тему настройки QoS на 2960/3560/3750! Теперь поговорим об очередизации трафика.
В отличии от коммутаторов-предшественников 2950/3550, на новых моделях к исходящим очередям добавились еще и входящие, и принципиально поменялся алгоритм работы исходящих очередей – теперь это SRR (Shaped Round Robin). В каждой из исходящих очередей есть 3 порога сброса (2 из которых можно двигать). Одна из 4-х исходящих очередей на порту – приоритетная (теперь это очередь номер 1). Таким образом, возможности QoS на этой серии коммутаторов кодируются как 1P3Q3T (1 приоритетная очередь, 3 карусельных, по 3 порога сброса в каждой из карусельных очередей). Появилась возможность тонкой настройки буферов во входящих и исходящих очередях.
Настройка исходящих очередей на коммутаторах 2960/3560/3750
Итак, даже если мы имеем коммутатор — быстрый, как американский хайвей, с полностью неблокируемой матрицей, у нас есть возможность поиметь затык (по-научному — переполнение) на исходящем интерфейсе, и огрести соответствующие проблемы в виде исключительно плохого качества голоса и видео, а также проседания прочих весьма полезных приложений. Но у нас есть Shaped Round Robin! Да здравствует управляемая несправедливость! Даешь деление полосы пропускания интерфейса между очередями в соответствии с приоритетом трафика! Отсутствует трафик в одной из очередей – полоса делится в заданных пропорциях между теми очередями, которым она нужнее (режим Shared). А будет у нас плохое настроение – вообще ограничим полосу пропускания какой-либо из очередей, чтобы не выпендривалась (режим Shaped). Тогда трафик этой очереди не сможет превысить планку, даже если есть свободная полоса.
Пороги сброса нужны для того, чтобы начинать сбрасывать трафик при достижении какого-то уровня заполнения очереди. А несколько порогов сброса нужны для реализации дифференцированного сброса. Он проявляется в том, что разные маркировки страдают по-разному сбрасываются на разных порогах. Надо только определить, кто на каком пороге должен «страдать» �� Получается следующая картинка:
Помните, в предыдущей статье мы говорили, что в качестве внутренней маркировки в этих моделях используется QoS Label, которая может формироваться из входящего DSCP или CoS? И та же самая «КОСовская метка» используется как для назначения трафика на так и на исходящие очереди, так и на пороги сброса в исходящих очередях, причем все это делается одной и той же командой:
Switch(config)# mls qos srr-queue output dscp-map queue queue-id threshold threshold-id dscp1…dscp8
Switch(config)# mls qos srr-queue output cos-map queue queue-id threshold threshold-id cos1…cos8
Switch(config)# mls qos srr-queue output dscp-map queue 1 threshold 2 10 11
Это означает, что трафик с DSCP 10 и 11 должен попадать в первую очередь и сбрасываться на втором пороге сброса.
ОК, трафик рассажен по очередям и по порогам сброса, теперь настроим режим Shaped – ограничение полосы пропускания в определенной очереди/очередях, даже если в соседних очередях есть незанятая полоса пропускания. Это делается командой:
Switch(config-if)# srr-queue bandwidth shape weight1 weight2 weight3 weight4
Switch(config-if)# srr-queue bandwidth shape 25 0 0 0
Это означает, что первая очередь ограничивается до 1/25 = 4% от интерфейсной полосы пропускания (не спрашивайте меня, почему сделали именно так), а остальные 3 – не поверите! работают в режиме Shared! И отдельной командой настраиваются весовые коэффициенты деления полосы пропускания в режиме Shared:
Switch(config-if)# srr-queue bandwidth share weight1 weight2 weight3 weight4
Switch(config-if)# srr-queue bandwidth share 30 20 25 25
При том, что 1-я очередь уже настроена в режиме Shaped, деление полосы пропускания между 2-й, 3-й, 4-й очередями считается так:
Команда srr-queue bandwidth shape имеет более высокий приоритет, чем srr-queue bandwidth share. В этом примере в команде srr-queue bandwidth share цифра 30 просто не учитывается.
Абсолютный приоритет для очереди номер 1 (что будет весьма пользительно для голоса, видео и другого real-time трафика) настраивается так:
Switch(config-if)# priority-queue out
Настройка буферов на исходящих очередях
На коммутаторах этих моделей можно настроить пропорции распределения буферной памяти между очередями 1, 2, 3, 4, а также двигать пороги сброса (двигать можно 1-й и 2-й, а третий порог двигать нельзя, он всегда 100% — это край очереди).
Настраивается это все хозяйство на уровне Queue Set – это некий шаблон, который потом назначается на интерфейс. Создать можно максимум 2 шаблона – номер 1 и номер 2.
Switch(config)# mls qos queue-set output qset-id buffers allocation1 … allocation4
Switch(config)# mls qos queue-set output qset-id threshold queue-id drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold
Switch(config)# interface interface-id
Switch(config-if)# queue-set qset-id
Switch(config)# mls qos queue-set output 2 buffers 40 20 20 20
Switch(config)# mls qos queue-set output 2 threshold 2 40 60 50 200
Switch(config)# interface gigabitethernet0/1
lSwitch(config-if)# queue-set 2
Мы только что создали шаблон 2, который повесили на interface gigabitethernet0/1. Первая команда в примере задает проценты деления буферной емкости между очередями:
Вторая команда определяет для очереди номер 2 первый порог как 40% от длины очереди, второй порог – как 60% от длины очереди. Третий порог не двигается и равен 100%. Следующее число – изменение «зарезервированного» порога, а четвертый – «максимальный» порог. Что за числа такие?
Представьте себе общество, в котором у каждого есть некий минимальный объем ресурсов, который гарантирован при любых обстоятельствах. И есть «общак», из которого мы можем брать дополнительные ресурсы, если нам не хватает. Из «общака» берем по принципу «кто первый встал, того и тапки», то есть если весь «общак» уже раздербанили, и нам не хватило, то мы опоздали. И чтобы этот «общак» кто-нибудь один не захапал, есть максимальный порог объема ресурсов, который можно взять из «общака».
Итак, на каждом порту коммутатора у каждой из четырех очередей есть минимальный объем буферной памяти, которая гарантирована данной очереди конкретного порта. На хватает буферов – никто не мешает пойти и попросить из «общака». Но – не больше, чем максимальный порог (больше просто не дадут – например, не больше трех товаров в одни руки, надо же все-таки и совесть иметь!), и при условии, что в общаке хоть что-то осталось.
Как понять, какие проценты там указывать? Логика заключена в относительности величин. Например, по умолчанию минимальный порог 100%. Зададим 50% – значит, отказываемся от половины наших гарантий в пользу «общака». Зададим 200% – увеличим наши гарантии в 2 раза. Зададим максимальный порог 400% – значит, потенциально можем захапать в 4 раза больше, чем минимальные гарантии (если дадут, конечно). В вышеприведенном примере для второй очереди первый порог – 40%, второй порог – 60%, третий какой? Правильно, 100%! Далее в команде – резерв 50% (тут надо знать, что было по умолчанию, если 100%, значит отказались от половины резерва в пользу «общака»). И максимально захапать можем в 4 раза больше, чем резерв.
Вот таблица с параметрами по умолчанию для исходящих очередей:
Настройка входящих очередей на коммутаторах 2960/3560/3750
Опустим холивар на тему, для чего нужны входящие очереди, и скажем, что очередей всего две. Режим – только Sharing. Можно указать одну из очередей как приоритетную. Но приоритезация здесь работает по-особому: сначала обслуживается очередь, продекларированная как приоритетная, например, до 10% полосы пропускания. А оставшиеся 90% полосы делятся между обоими очередями в пропорции, задающейся весовыми коэффициентами. Девиз – «сначала мы твое съедим (впрочем, не полностью), а потом каждый свое будет есть». Нужно задать эти самые весовые коэффициенты, то есть в каких пропорциях «каждый свое будет есть». Еще во входящих очередях есть по 2 порога сброса в каждой очереди, оба по умолчанию равны 100%.
Команды назначения фреймов на входящие очереди (назначение — по QoS Label – CoS или DSCP) – такие же, как и для входящих очередей, только вместо output пишем input.
Switch(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 0 1 2 3 4 5 6
Switch(config)# mls qos srr-queue input dscp-map queue 1 threshold 2 20 21 22 23 24 25 26
Конфигурим сами пороги (например, для очереди номер 1):
Switch(config)# mls qos srr-queue input threshold 1 50 70
Распределяем буфера между входящими очередями (первой — 60%, второй — 40%):
Switch(config)# mls qos srr-queue input buffers 60 40
Далее конфигурим приоритезацию и весовые коэффициенты:
Switch(config)# mls qos srr-queue input priority-queue 1 bandwidth 10
Switch(config)# mls qos srr-queue input bandwidth 4 4
Первая команда означает, что очередь номер 1 — приоритетная, ей гарантировано 10% от полосы пропускания входящего интерфейса, а оставшиеся 90% делятся поровну между первой и второй очередями (поровну — потому, что весовые коэффициенты 4 и 4 — они равны). То есть первая очередь получит 10% + 45% = 55% интерфейсной полосы, а второй достанется 45%. Первая очередь будет обслуживаться до тех пор, пока не выжрет свои 10% гарантированной полосы (чтобы была низкая задержка трафика real-time), а потом будет карусельная обработка между первой и второй очередями.
Если в первой команде поставить нуль, это означает, что мы запрещаем приоритезацию в этой очереди:
Switch(config)# mls qos srr-queue input priority-queue 2 bandwidth 0
Вот таблица с параметрами по умолчанию для входящих очередей:
Настройка ограничения скорости на исходящем порту
Иногда есть необходимость ограничить скорость на исходящем интерфейсе — одеть на него ограничивающий «хомут». Делается это следующей командой:
Switch(config)# interface gigabitethernet0/1
Switch(config-if)# srr-queue bandwidth limit 80
Диапазон возможных значений — от 10 до 90, показывает, сколько процентов от скорости исходящего интерфейса должно быть доступно.
Последовательность операций
Ну и напоследок — 2 блок-схемы, отображающие последовательность операций на входящем порту коммутатора:
… и исходящем порту коммутатора:
Дорогие коллеги, как говорится, не переключайтесь �� скоро следующая статья про полисинг и шейпинг на 2960/3560/3750.
С уважением,
Евгений Киселев aka Stratosphere
8 комментариев “Выезжаем на перекресток (Настройка очередизации на коммутаторах Cisco Catalyst 2960/3560/3750)”
Жень, личная просьба: обрежь статью для главной страницы (тэг «More —>»)
Stratosphere :
О, Сереж, пардон, совсем забыл про эту обрезку.
Сделал.
Благодарю за статью! Пишите еще! ��
Stratosphere :
Спасибо! обязательно буду писать!Как всегда на высоте. Отменная статья. Благодарствую.
Вот интересно как много народу спускается до такого тонкого тюнинга как L2 QoS.Красиво на словах, но настройки очередей не могут полностью избавить от дропов: 3750me#sh int fast 1/0/1
FastEthernet1/0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0019.6082.e2c1 (bia 0019.6082.e2c1)
Description: 100Mbps, inet
MTU 1998 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 95/255, rxload 20/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of «show interface» counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 452285394
Queueing strategy: fifo
Output queue: 0/4096 (size/max)
30 second input rate 8032000 bits/sec, 3565 packets/sec
30 second output rate 37514000 bits/sec, 5167 packets/sec
32026946800 packets input, 13406208556049 bytes, 0 no buffer
Received 9073264 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
32037 input errors, 32037 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 9046727 multicast, 0 pause input
0 input packets with dribble condition detected
49960545188 packets output, 43284144020560 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
*************************
3750me#sh int fast 1/0/1
FastEthernet1/0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0019.6082.e2c1 (bia 0019.6082.e2c1)
Description: 100Mbps, inet
MTU 1998 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 96/255, rxload 14/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of «show interface» counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 452285700
Queueing strategy: fifo
Output queue: 0/4096 (size/max)
30 second input rate 5819000 bits/sec, 3173 packets/sec
30 second output rate 37717000 bits/sec, 4972 packets/sec
32027928179 packets input, 13406491358807 bytes, 0 no buffer
Received 9073270 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
32037 input errors, 32037 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 9046733 multicast, 0 pause input
0 input packets with dribble condition detected
49962124797 packets output, 43285662408104 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
*************************
Queueset: 1
Queue : 1 2 3 4
———————————————-
buffers : 0 100 0 0
threshold1: 100 3100 100 100
threshold2: 100 3100 100 100
reserved : 50 100 50 50
maximum : 400 3200 400 400
************************* interface FastEthernet1/0/1
description 100Mbps, inet
no switchport
no ip address
load-interval 30
no keepalive
speed 100
duplex full
srr-queue bandwidth share 25 255 25 25
xconnect encapsulation mpls
backup peer
hold-queue 4096 out
end
****************************** 3750me#sh platform port-asic stats drop fast 1/0/1 Interface Fa1/0/1 TxQueue Drop Statistics
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 452009123
Weight 1 Frames 1377
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0 3750me#sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is disabled 3750me#sh ver
Cisco IOS Software, C3750ME Software (C3750ME-I5-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)> Switch(config-if)# srr-queue bandwidth share 30 20 25 25 > При том, что 1-я очередь уже настроена в режиме Shaped, деление полосы пропускания между 2-й, 3-й, 4-й очередями считается так: Небольшая поправка: согласно документации, для режима shared считается не полоса пропускания, а частота, с которой планировщик отправляет пакеты из очередей, при этом используется вся свободная полоса пропускания, вплоть до 100%.
- Возможные варианты действий: