Вход в роутер Cisco по умолчанию через логин (Имя пользователя) и Пароль через актуальные IP-адреса для входа. Инструкция универсальная и подходит для всех моделей.
Архив метки: Cisco
Настройка Cisco Nexus N3K-C3064PQ-10GX
Коммутатор имеет 48 портов SFP+ 10 Gb/s и 4 QSFP+ 40 Gb/s
При первом подключении через консоль, указываем пароль для пользователя admin:
|
1
2
3
4
5
6
7
8
|
Do you want to enforce secure password standard (yes/no): yes
Enter the password for "admin":
Confirm the password for "admin":
Would you like to enter the basic configuration dialog (yes/no): no
|
Переключаемся в режим конфигурирования и указываем файл прошивки:
|
1
2
3
4
|
configure terminal
show incompatibility nxos bootflash:nxos.7.0.3.I4.6.bin
boot nxos bootflash:/nxos.7.0.3.I4.6.bin
exit
|
Сохранить конфигурацию, и перезагрузить коммутатор:
|
1
2
3
|
copy running-config startup-config
reload
This command will reboot the system. (y/n)? [n] y
|
Далее смотрим текущую и сохраненную конфигурации:
|
1
2
|
show running-config
show startup-config
|
Во время включении коммутатора при необходимости можно перейти в режим загрузчика:
|
1
|
Press ctrl L to go to loader prompt in 2 secs
|
Из загрузчика также можно вручную запустить коммутатор с указанной прошивки:
|
1
|
loader>boot bootflash:nxos.7.0.3.I4.6.bin
|
Или так:
|
1
|
switch(boot)#load bootflash:nxos.7.0.3.I4.6.bin
|
Выбрать режим портов, и после этого действия необходимо перезагрузить кошку:
|
1
2
3
4
5
6
7
8
|
hardware profile portmode 48x10g+4x40g
hardware profile portmode 52x10g+3x40g
hardware profile portmode 56x10g+2x40g
hardware profile portmode 60x10g+1x40g
hardware profile portmode 64x10g
exit
reload
|
Добавим необходимые VLAN и при необходимости описания:
|
1
2
3
4
5
|
vlan 100
name Management
vlan 200
name Users
exit
|
Настройка access и trunk портов:
|
1
2
3
4
5
6
7
8
9
10
11
|
interface Ethernet1/46
switchport
switchport mode access
description disnetern
switchport access vlan 200
storm-control broadcast level 0.50
interface Ethernet1/44
switchport
switchport mode trunk
switchport trunk allowed vlan 100,200
|
Настройка гибридного порта, Vlan 100 без тага, а все остальные vlan с тагом:
|
1
2
3
|
switchport mode trunk
switchport trunk native vlan 100
switchport trunk allowed vlan 300-400,100
|
По умолчанию порты 1-48 настроены на скорость 10 Gb/s, чтобы подключить 1 Gb/s нужно указать:
|
1
2
3
4
|
interface ethernet 1/1-20
speed 1000
interface ethernet 1/21-48
speed 10000
|
Часовой пояс и ntp сервер для синхронизации времени:
|
1
2
3
|
ntp server 10.5.103.20
clock timezone UTC 3 0
show clock
|
Настроим SNMP:
|
1
|
snmp-server community blabla ro
|
Если будут создаваться interface vlan (SVI), то нужно активировать feature interface-vlan:
|
1
2
|
show feature
feature interface-vlan
|
Создание interface vlan (SVI):
|
1
2
3
4
5
6
7
8
9
|
vlan 100
exit
interface vlan 100
description support
ip address 172.20.1.5/24
ip address 10.5.100.5/24 secondary
no ip redirects
no shutdown
exit
|
Маршрут по умолчанию(default):
|
1
|
ip route 0.0.0.0/0 172.20.1.1
|
Или:
|
1
2
|
vrf context default
ip route 0.0.0.0/0 172.20.1.1
|
Настройка mgmt порта:
|
1
2
3
4
5
6
7
|
int mgmt 0
ip address 192.168.100.10/24
exit
vrf context management
ip route 0.0.0.0/0 192.168.100.1
exit
ping 192.168.100.55 vrf management
|
Можно указать hostname:
|
1
|
hostname nexus
|
Прочее
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
show version
show system uptime
show system resources
show boot variables
show banner motd
show feature
show vdc membership
show running-config copp all
show running-config interface ethernet 1/1-10
show interface ethernet 1/1 transceiver details
show interface ethernet 1/1-10
show interface status
show interface brief
show interface Ethernet1/52
show interface Ethernet1/52 brief
show processes cpu
show processes log
show processes log details
show processes memory
show logging
show cli history
show install all status
dir
show sprom all
show inventory
show module
show environment
show environment power
show environment fan
show environment fan detail
show environment temperature
show license
show system reset-reason
show terminal
|
Uptime :
|
1
|
show version
|
Разрешим использование SFP модулей от сторонних производителей:
|
1
|
service unsupported-transceiver
|
При использовании сторонних SFP и DAC кабелей можно указать команды ниже для интерфейсов, так как без них либо не было линка, либо он пропадал через некоторое время, например:
|
1
2
3
|
interface ethernet 1/52
no negotiate auto
duplex full
|
Также можно выключить flow-control если он не выключился автоматически:
|
1
2
|
no flowcontrol receive
no flowcontrol send
|
Настроим завершение консольных сессий через 30 минут:
|
1
2
|
line console
exec-timeout 30
|
Пример ограничения доступа к коммутатору по IP адресам:
|
1
2
3
4
5
6
7
|
ip access-list manage
permit ip 10.100.5.1/32 any
permit ip 192.168.100.5/32 any
line vty
exec-timeout 30
access-class manage in
|
Активация telnet:
|
1
|
feature telnet
|
Для очистки конфигурации используется команда:
|
1
|
write erase
|
Пример копирования текущей и сохраненной конфигурации на TFTP сервер:
|
1
2
|
copy running-config tftp://disnetern.ru/running-config.bak
copy startup-config tftp://disnetern.ru/startup-config.bak
|
Пример восстановления конфигурации с TFTP сервера:
|
1
|
copy tftp://disnetern.ru/running-config.bak running-config
|
2021-01-28T12:22:31
Cisco
Juniper Class of Service
Введение
Традиционно, принимая во внимание, что cisco-адептов больше чем juniper-кунов, будут наблюдаться регулярные отсылки на названия и конкретные реализации той или иной технологии на Cisco IOS.
Вы можете ужаснуться от того как сложно это реализуется на Juniper, но, во-первых эта многословность дарит возможность очень гибкой и тонкой настройки, а во-вторых, монструозность CLI это лишь дело привычки и спустя недели лаб иерархичность Junos становится родной и понятной.
Легенда
Для обеспечения читателю возможности упорядоченного следования нам необходимо определиться с задачей, которую будет решать наша конфигурация.
Будет использоваться следующая схема, на базе реального оборудования:
- S3 – Juniper EX4200 – источник немаркированного трафика
- R1 – Juniper MX5 – точка выполнения CoS-манипуляций
- R3 – Cisco 3845 – получатель трафика
Как видите, для некоторого упрощения процесса, один из узлов работает на базе Cisco IOS – к этому узлу трафик будет направляться и там будет выполнятся классификация трафика, с целью определения корректности выполнения маркировки на R1.
Далее будут вноситься разъяснения в задачу, но поэтапно, чтобы не вызвать чувства запутанности.
Весь трафик будет направляться к трём loopback-интерфейсам на R3, со следующими IP-адресами:
- lo0 – 3.3.3.3
- lo1 – 123.0.0.1
- lo2 – 123.0.0.2
Эти адреса нужны чтобы можно было разделить трафик на три группы:
- трафик с адресом назначения 123.0.0.1 – считается высокоприоритетным трафиком телефонии (будем называть его телефонным);
- трафик с адресом назначения 123.0.0.2 – считается приоритетным трафиком важных корпоративных приложений (будем называть его серверным);
- трафик с адресом назначения 3.3.3.3 – считается обычным трафиком.
(легко запомнить, если смотреть на последний октет как на степень важности – 1=первая, максимальная важность).
Итак, мы имеет условный трафик, направляемый посредством утилиты ping, с S3 в сторону R3, через транзитный R1, который выполняет следующие манипуляции на интерфейсе ge-1/1/0:
- телефонный трафик маркируется DSCP EF, помещается в очередь VOICE и учитывается (кол-во байт и пакетов);
- серверный трафик маркируется DSCP AF31, помещается в очередь DATA и учитывается;
- обычный трафик маркируется DSCP BE, помещается в очередь OTHER и учитывается.
Очень важно поместить трафик в нужные и разные очереди, так как основные манипуляции выполняются именно с очередями – некими трубами, где трафик скапливается в ожидании своей участи.
Далее, как бы внутри устройства выполняются следующие манипуляции:
- очередь VOICE наделяется высшим приоритетом на передачу (LLQ), получает гарантированную полосу в 10% от общей полосы, без права выхода за рамки и 5% от общего объёма буферов без права выхода за рамки. Традиционно считается, что нет смысла давать много буферного пространства под трафик реального времени (голос, видео), ведь в случае перегрузки линии долгое время нахождения этого трафика в буфере будет бесполезной тратой ресурсов – к конечному узлу задержанный трафик придёт с большим опозданием, вероятно будучи уже не нужным, а значит его проще отбросить в момент когда мы предполагаем его уже опоздавшим;
- очередь DATA наделяется средним приоритетом, получает гарантированную полосу в минимум 40% от общей полосы, т.е. с правом выхода за рамки и гарантированные 50% от общего объёма буферов с правом выхода за рамки;
- очередь OTHER наделяется наименьшим приоритетом, получает всю незанятую кем-либо полосу и все незанятые кем-либо объёмы буферов от общего объёма буферов (доедает крошки со стола). При этом, за счёт именно этой очереди выполняется попытка избежания перегрузки (congestion avoidance – CA), с помощью WRED (weighted random early detection) – при достижении 70% занятости полосы отбрасываются 25% случайного трафика, при достижении 90%отбрасывается 50%. Это гораздо эффективнее чем базовый CA средствами Taildrop, благодаря которому при 100%перегрузке линии отбрасывается 100% трафика и рождается TCP global synchronization – график трафика будет выглядеть как зубчики пилы, ибо все TCP-сессии не получив ACK снижают свой MSS в 2 раза, показывая провал в графике и все вместе начинают передавать вновь, до повторения зубчика.
Настройка
Получатель
Давайте для начала выполним быструю настройку R3 – обеспечим классификацию трафика и убедимся, что весь трафик приходит немарированный:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
!
class–map VOICE
match ip dscp EF
class–map DATA
match ip dscp AF31
!
policy–map PM_CHECK
class VOICE
class DATA
class class–default
!
interface GigabitEthernet 0/0
service–policy input PM_CHECK
!
|
Мы выполняем простую Behavior aggregate (BA) классификацию пакетов, на основании DSCP, не применяя никаких действий к этому трафику. В итоге мы можем смотреть сколько пакетов одного из трёх классов с помощью одной простой командой:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
R3# show policy-map interface GigabitEthernet 0/0
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp ef (46)
Class–map: DATA (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp af31 (26)
Class–map: class–default (match–any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
R3#
|
(для обычного трафика не создаём отдельный класс, а используем встроенный class-default)
Отправитель
Отправим несколько пакетов с S3 и убедимся, что весь данный трафик попадает в class-default, т.е., как минимум, ни метки EF, ни AF31 там нет (вывод сокращён, для улучшения читабельности):
|
1
2
3
4
5
6
7
8
9
10
|
root@S3# run ping 123.0.0.1 count 1 rapid
PING 123.0.0.1 (123.0.0.1): 56 data bytes
!
root@S3# run ping 123.0.0.2 count 2 rapid
PING 123.0.0.2 (123.0.0.2): 56 data bytes
!!
root@S3# run ping 3.3.3.3 count 3 rapid
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!
root@S3#
|
Проверим на R3:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
R3# show policy-map interface GigabitEthernet 0/0
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp ef (46)
Class–map: DATA (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp af31 (26)
Class–map: class–default (match–any)
6 packets, 588 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
R3#
|
Как видите все 6 пришедших пакета успешно дошли до Получателя и попали в класс для немаркированного трафика.
Транзит
Это важно. Всю настройку мы разобьём на следующие этапы:
- Создание очередей
- Классификация, маркировка, помещение в очередь
- Создание планировщиков
- Привязывание очередей к планировщикам
- Закрепление на интерфейсе
- Policer
Создание очередей
Как уже говорилось ранее, очереди это те самые трубы в которые попадает трафик и в котором он ожидает своей участи. С точки зрения конфигурации нам это удобно для логического разделения трафика на блоки с которыми и творится вся магия. Т.е. раз у нас три типа трафика, то мы сделаем под них три разных очереди.
Отступление 1: конфигурацию Juniper можно приводить в нескольких вариантах – в длинном выводе формата конфигурационного файла, с кучей скобочек {{{{ }}}} а ля perl, либо в формате set, то как выполняется сама настройка. Мы будем использовать второй вариант с переходом по иерархическим уровням.
Отступление 2: все параметры указываемые исключительно буквами верхнего регистра являются именуемыми параметрами, имя для который выбирается администратором и задаётся вручную. В некоторых случая добавлено обозначение места куда применяется имя, чтобы не путаться, например RULE-VOICE, COUNTER-VOICE, SCHEDULER-VOICE.Всё это используется для улучшения читабельности конфигурации.
|
1
2
3
4
5
6
7
8
9
10
|
# Переходим на уровень настройки очередей
edit class–of–service forwarding–classes
# Создаём очередь VOICE и назначаем ей номер очереди 6.
# (доступны 8 очередей на порт, от 0 до 7)
set class VOICE queue–num 6
# очередь DATA
set class DATA queue–num 4
# очередь OTHER
set class OTHER queue–num 0
top
|
Надеюсь, такие конфигурации вас не пугают – перешли на уровень, сделали класс привязали его к какому захотели номеру очереди.
Проверим, что всё правильно создалось (несмотря на то, что безошибочный commit гарантирует это):
|
1
2
3
4
5
6
7
8
|
root@R1# run show class-of-service
Forwarding class ID Queue
OTHER 0 0
expedited–forwarding 1 1
assured–forwarding 2 2
network–control 3 3
VOICE 4 6
DATA 5 4
|
Видим все наши очереди и в столбце Queue видим номера.
Классификация, маркировка, помещение в очередь
Мы заведомо знаем, что трафик с S3 отправляется немаркированным, значит для того чтобы его классифицировать нам необходимо воспользоваться классификацией на основе Multi-field (MF) [т.е. отлов по любым значениям кроме самих меток CoS – по IP-адресам, портам, etc] – с самого начала мы определились, что специально для этого у нас есть три адреса назначения.
Процедура классификации, маркировки, подсчёта пакетов выполняется через обычный firewall-фильтр, который вещается на нужный интерфейс. В нашем случае это интерфейс ge-1/1/0 на R1 смотрящий в сторону S3.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
# Переходим на уровень настройки фильтра с именем MARK1
edit firewall family inet filter MARK1
# согласно правилу VOICE, любой пакет направляемый к 123.0.0.1,
# маркируется DSCP EF, кладётся в очередь VOICE,
# а количество/размер таких пакетов подсчитываются
set term TERM–VOICE from destination–address 123.0.0.1
set term TERM–VOICE then dscp ef forwarding–class VOICE count COUNTER–VOICE
# трафик с DSTIP 123.0.0.2, помечается DSCP AF31
# кладётся в очередь DATA и подсчитывается
set term TERM–DATA from destination–address 123.0.0.2
set term TERM–DATA then dscp af31 forwarding–class DATA count COUNTER–DATA
# прочий трафик явно перемаркируется DSCP BE
# (мало ли ктододумается весь свой трафик как EF маркировать),
# кладётся в очередь OTHER и подсчитывается
set term TERM–OTHER then dscp be forwarding–class OTHER count COUNTER–OTHER
top
|
Как видите конфигурация легко читается. Специально используется возможность Junos CLI, указания нескольких настроек сразу в одной строке. В конфигурации это выглядит иерархически и отдельно:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
firewall {
family inet {
filter MARK1 {
term TERM–VOICE {
from {
destination–address {
123.0.0.1/32;
}
}
then {
count COUNTER–VOICE;
forwarding–class VOICE;
dscp ef;
}
}
}
}
|
(представлен не полный вывод вышесозданного правила, а только ознакомительный блок TERM-VOICE).
Итак, мы сделали очереди, запихали туда трафик на основании известных о нём данных – самое время прикрепить фильтр на ближайших к S3 интерфейс – ge-1/1/0.
|
1
2
|
root@R1# set interfaces ge-1/1/0.0 family inet filter input MARK1
root@R1#
|
Прекрасно, проверяем – ещё раз отправляем пакеты до R3 и смотрим всё ли маркируется как было приказано.
Проверим для VOICE (помните, что это трафик до 123.0.0.1 ?):
|
1
2
3
4
5
6
7
8
9
|
! До отправки всё по нулям
R3# show policy-map interface GigabitEthernet 0/0 input class VOICE
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: dscp ef (46)
R3#
|
|
1
2
3
4
5
|
# Отправка
root@S3# run ping 123.0.0.1 count 6 rapid
PING 123.0.0.1 (123.0.0.1): 56 data bytes
!!!!!!
root@S3#
|
|
1
2
3
4
5
6
7
8
9
|
! Контрольная проверка
R3# show policy-map interface GigabitEthernet 0/0 input class VOICE
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
6 packets, 588 bytes
30 second offered rate 0 bps
Match: dscp ef (46)
R3#
|
Вуаля – пакеты вот прям реально маркируются на R1 и приходят таковыми до R3, где он может их классифицировать на основании BA – простого DSCP кода.
Мы так же можем зафиксировать корректную классификацию трафика на R1, просмотрев заблаговременно прикрученные счётчики:
|
1
2
3
4
5
6
7
8
|
root@R1# run show firewall filter MARK1
Filter: MARK1
Counters:
Name Bytes Packets
COUNTER–DATA 0 0
COUNTER–OTHER 0 0
COUNTER–VOICE 504 6
root@R1#
|
Создание планировщиков
Планировщики это те ребята которые будут управлять очередями на основании заданных нами правил. Именно здесь на очередях применяются все технологии QoS, от избежания перегрузок до управления доступным буферным пространством.
Раз у нас три типа трафика, три DSCP кода, три счётчика, три очереди, то и планировщиков (schedulers) будет три, со следующими именами:
- планировщик SCHED-VOICE для очереди VOICE;
- планировщик SCHED-DATA для очереди DATA;
- планировщик SCHED-OTHER для очереди OTHER.
Настоятельно рекомендую подняться в раздел “Легенда” и перечитать как именно планируется управлять очередями.
Итак:
Переходим на уровень настройки планировщиков
|
1
|
edit class–of–service schedulers
|
Планировщик SCHED-VOICE в будущем будет ассоциирован с очередью VOICE и выполняет следующие инструкции: выставляет наивысший приоритет трафику данной очереди (LLQ), обеспечивая максимально быструю отправку пакетов данной очереди, для обеспечения минимальной задержки и джиттера.
|
1
|
set SCHED–VOICE priority strict–high
|
Так как лучше отбросить трафик реального времени, вместо долгосрочной задержки в буферах, мы выдаём данной очереди только 5% объёма буферов, без права эти пределы превысить, таким образом, когда буфер заполнен, мы не может поместить в него новые пакеты и отбрасываем их, надеясь, что перегрузка вот-вот прекратится.
|
1
|
set SCHED–VOICE buffer–size percent 5 exact
|
Далее нам нужно ограничить максимально утилизируемую голосовым трафиком полосу пропускания, так как если этого не сделать, то наделяя его наивысшим приоритетом, мы рискуем, что при правильных объёмах голоса никакой другой трафик не пролезет вовсе. Сделать это можно несколькими путями:
- shaping-rate – суть метода заключается в буферизации трафика перед отправкой, что для голоса не годится;
- transmit-rate – гарантирует часть полосы, при этом, если трафика больше, то совершаются попытки использовать никем не занятую пропускную способность, что для нашего случая не походит, так как нам необходимо жёстко лимитировать полосу под голос, ибо приоритет опасен;
- transmit-rate exact – гарантируется часть полосы и всё что выходит за рамки попросту отбрасывается. К сожалению, наивысший приоритет и transmit-rate exact не могут использоваться одновременно и при попытке сделать это Junos ругнётся следующим образом: “cos_config_scheduler_attributes: cannot configure transmit rate exact and priority strict-high at the same time.”
- policer – последний и идеальный вариант для ограничения полосы под голос, так как во-первых policing, в отличие от shaping, не использует такой ограниченный ресурс как буферы для временного хранения чего-либо, а во-вторых имеются интересные возможности – вместо отбрасывания голосового трафика при превышении лимитов, можно перемаркировывать его (например в DSCP BE) или просто отдать в очередь BE, надеясь что там дальше разберуться сами. Т.е. мы обещаем что до считаем голос особенным только до определённого предела. Настройки конкретного устройства ответственны за то чтобы избегать или управлять перегрузками только на нём самом, поэтому подход с понижением приоритета вместо отброса имеет право существовать. Таким образом, мы обходим проблему буферов, отброса важного трафика и опасности переполнения линии высокоприоритетным трафиком.
Делается это не в планировщиках и мы вернёмся к этому чуть позже.
Конец планировщика SCHED-VOICE
Для очереди которая будет привязана к планировщику SCHED-DATA (у нас это будет DATA), выполняются следующие условия: средний приоритет, позволяющий обеспечить отправку пакетов из очереди данного планировщика, раньше чем ожидающие пакеты из очередей с меньшим приоритетом.
|
1
|
set SCHED–DATA priority medium–high
|
Такого трафика ожидается много, но мы гарантируем ему только 40% буферного пространства
|
1
|
set SCHED–DATA buffer–size percent 40
|
, а так же гарантируем 50% пропускной способности, при этом не жёстко ограничиваем его в этих рамках, т.е. если часть линии свободна, он может её занять
|
1
|
set SCHED–DATA transmit–rate percent 50
|
Для обычного трафика, как и договорились, остаются все объедки не съеденные явным # образом кем-то более привилегированным
|
1
2
|
set SCHED–OTHER buffer–size remainder
set SCHED–OTHER transmit–rate remainder
|
Без комментариев список команд конфигурации выглядит так:
|
1
2
3
4
5
6
7
8
9
|
edit class–of–service schedulers
set SCHED–VOICE priority strict–high
set SCHED–VOICE buffer–size percent 5 exact
set SCHED–DATA priority medium–high
set SCHED–DATA buffer–size percent 40
set SCHED–DATA transmit–rate percent 50
set SCHED–OTHER buffer–size remainder
set SCHED–OTHER transmit–rate remainder
top
|
Согласитесь – ничего пугающего.
Привязка очередей к планировщикам
Согласно уговору привязываем планировщики к одноимённым классам (воису воисово, дате датово, кесарю кесарево). Нашу карту планировщиков назовёт SCHEDMAP1:
|
1
2
3
4
5
|
edit class–of–service scheduler–maps SCHEDMAP1
set forwarding–class VOICE scheduler SCHED_VOICE
set forwarding–class DATA scheduler SCHED_DATA
set forwarding–class OTHER scheduler SCHED_OTHER
top
|
Закрепление на интерфейсе
Всё основное мы сделали, осталось зацепить это на тот интерфейс смотрящий в сторону R3 – ge/1/1/1 и после этого там же обеспечить там policing.
Привязка к интерфейсу:
|
1
|
set class–of–service interfaces ge–1/1/1 unit * scheduler–map SCHEDMAP1
|
Policer
Уже сейчас всё нами настроеное находится в эксплуатации и нарезается раздаётся согласно тем условиями которые мы указали.
Осталось “зарезать” голосовой трафик, чтобы защитить себя от обработки только высокоприоритетных пакетов. Есть два уточнения благодаря которым мы поймём как и где это делать:
- policing можно использовать как для входящего трафика, так и для исходящего, в отличие от shaping, который не особо разумен для входящего трафика, так как буферы уже были использованы для трафика который отбросится;
- как и многие другие вещи, policing выполняется посредством firewall filter, который назначается на некоторый интерфейс;
Собственно из этого можно сделать вывод, что ничего не мешает и даже следует использовать policing уже в составе имеющегося фильтра на порту ge-1/1/0, смотрящего в сторону S3!
Для начала создадим сам policer, чтобы можно было его поместить как условие в наш фильтр.
|
1
2
3
4
|
edit firewall policer POLICER1
set if–exceeding bandwidth–percent 10 burst–size–limit 1m
set then forwarding–class OTHER
top
|
Вы наверняка заметили, что правила фаервольных полисеров и фильтров очень удобно читать – если так, то делать вот это.
В нашем случае мы говорим, что если нечто, к чему будет применён данный полисер пытается занять больше положенных 10% от пропусной способности линии (10Мб/с для 100Мбит/с), то трафик сверх этого лимита стоит переместить в класс OTHER, для которого как вы помните имеется большой выбор крошек. Мы не станем перемаркировывать трафик, а просто поместим в очередь для обычного трафика, где он, если выживет, то может на следующей узле всё будет хорошо, и на основании его сохранившего DSCP EF, его обслужат его как подабает таким особам.
Далее, мы имеем следующий фильтр, на интерфейсе, смотрящем в сторону S3:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
root@R1# show firewall family inet
filter MARK1 {
term VOICE {
from {
destination–address {
123.0.0.1/32;
}
}
then {
count COUNTER–VOICE;
forwarding–class VOICE;
dscp ef;
}
}
term DATA {
from {
destination–address {
123.0.0.2/32;
}
}
then {
count COUNTER–DATA;
forwarding–class DATA;
dscp af31;
}
}
term OTHER {
then {
count COUNTER–OTHER;
forwarding–class OTHER;
dscp be;
}
}
}
root@R1#
|
Значит нам необходимо прицепить только что созданный policer POLICER1 к правилу TERM-VOICE:
|
1
|
set firewall family inet filter MARK1 term VOICE then policer POLICER1
|
В итоге правило TERM-VOICE обретёт следующий вид:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
root@R1# show firewall family inet filter MARK1 term VOICE
from {
destination–address {
123.0.0.1/32;
}
}
then {
policer POLICER1;
count VOICE;
forwarding–class VOICE;
dscp ef;
}
root@R1#
|
Только-только трафик будет классифицирован, маркирован и помещён в очередь, как тут же будет проверен и на соответствие правилу допустимой ему полосы пропускания.
Рассморение калькуляции значения burst-size преднамеренно не упоминается в рамках статьи, для обеспечения небольшого уровня сложности текста.
Проверка
Не сказать, что Junos достоин похвалы за удобство проверки корректности работы, но инструменты имеются.
show class-of-service
show class-of-service scheduler-map
show class-of-service scheduler-map SCHEDMAP1
show class-of-service drop-profile
show class-of-service drop-profile DROPMAP1
show class-of-service interface ge-1/1/1 comprehensive | find “Scheduler map”
show class-of-service interface
show class-of-service interface ge-1/1/1
show class-of-service interface ge-1/1/1 comprehensive | find “CoS info”
show interfaces ge-1/1/0 extensive detail | find “CoS info”
show interfaces queue ge-1/1/1
Дополнения
Микросекунды
Для голосового трафика может быть полезным указать размер буфера не в процентах, а явным образом, в микросекундах, ограничив тем самым время жизни трафика который уставает задержаваясь в буферах. Известно, что delay голосового трафика, при котором наблюдается явная деградация звука имеется уже на 150мс. Так как данный параметр выставляется в микросекундах, что на три порядка меньше миллисекунды, 150мс будут выглядеть как 150000, но мы поставишь чуть меньше:
|
1
2
|
delete class–of–service schedulers SCHED_VOICE buffer–size
set class–of–service schedulers SCHED_VOICE buffer–size temporal 100000
|
RED
Совсем забыли про необходимость пытаться избегать перегрузки на линии, за счёт предварительного отбрасывания части пакетов полуслучайным образом – random early detection (RED).
Разумеется, это будет делаться за счёт трафика в очереди класса OTHER, который у нас best-effort.
Согласно легенде будет выполняться следующее: “при достижении 70% занятости полосы отбрасываются 25% случайного трафика, при достижении 90% отбрасывается 50%”.
Настраивается всё в отдельной ветке иерархии и после цепляется к нужному планировщику:
|
1
2
3
4
|
edit class–of–service drop–profiles DROPMAP1
set fill–level 70 drop 25
set fill–level 90 drop 50
top
|
Как видите и здесь блок конфигурации отлично читается.
Обновим на ходу планировщик SCHED_OTHER:
|
1
|
set class–of–service schedulers SCHED_OTHER drop–profile–map protocol any loss–priority any drop–profile DROPMAP1
|
Проверка:
|
1
2
3
4
5
|
root@R1> show class–of–service drop–profile DROPMAP1
Drop profile: DROPMAP1, Type: discrete, Index: 13794
Fill level Drop probability
70 25
90 50
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
root@R1> show class–of–service scheduler–map SCHEDMAP1
Scheduler map: SCHEDMAP1, Index: 20828
Scheduler: SCHED_OTHER, Forwarding class: OTHER, Index: 47444
Transmit rate: remainder, Rate Limit: none, Buffer size: remainder, Buffer Limit: none, Priority: low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 13794 DROPMAP1
Medium low any 13794 DROPMAP1
Medium high any 13794 DROPMAP1
High any 13794 DROPMAP1
Scheduler: SCHED_VOICE, Forwarding class: VOICE, Index: 15390
Transmit rate: 5 percent, Rate Limit: none, Buffer size: 100000 us, Buffer Limit: none, Priority: strict–high
Excess Priority: unspecified
Shaping rate: 50000 bps, Shaping Rate Burst: 31000 bytes
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default–drop–profile>
Medium low any 1 <default–drop–profile>
Medium high any 1 <default–drop–profile>
High any 1 <default–drop–profile>
Scheduler: SCHED_DATA, Forwarding class: DATA, Index: 57929
Transmit rate: 30 percent, Rate Limit: none, Buffer size: 40 percent, Buffer Limit: none, Priority: low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default–drop–profile>
Medium low any 1 <default–drop–profile>
Medium high any 1 <default–drop–profile>
High any 1 <default–drop–profile>
root@R1#
|
Источники
Configuring Large Delay Buffers in CoS
Configuring CoS Hierarchical Schedulers
Enabling Class of Service on EX Series Switches in a Campus LAN [pdf]
Example: Configuring CoS on EX Series Switches
2020-12-14T11:06:39
Cisco
Первоначальная настройка Cisco Catalyst
- Дефолтовых конфигов не бывает, т.к. у каждого своя сеть и свои «правила»
- Нету у Cisco IP-адреса по умолчанию (это же не Dlink), все настраивается ручками и сначала через консоль.
Итак, попробуем разобраться в том, что желательно настроить на нулевом Cisco Catalyst ?
Например, часто встречающиеся:
- Cisco Catalyst 2950
- Cisco Catalyst 2960
- Cisco Catalyst 3550
- Cisco Catalyst 3560
- Cisco Catalyst 3560G
Роутеры Cisco: популярные модели, настройка основных параметров
Настроить практически любой роутер можно самостоятельно даже без навыков системного администратора. Как наладить доступ к интернету через роутер Cisco? Где происходит настройка для этого девайса? Какие параметры следует установить в первую очередь?
Настройка MSTP (Multiple Spanning Tree Protocol)
Multiple Spanning Tree Protocol (MSTP) описан в стандарте IEEE 802.1s и позднее в IEEE 802.1Q-2003. В отличие от RSTP, где для всех VLAN создаётся одна loop-free топология, в MSTP можно запустить несколько multiple spanning-tree instances (MSTI) — каждую для одной или нескольких отдельных VLAN, что позволит использовать избыточные линки с большей продуктивностью и обеспечить балансировку нагрузки через доступные линки.
MSTP позволяет создать логическое группирование коммутаторов в управляемые кластеры, известные как Multiple Spanning Tree (MST) region. Регион MST (MST region) — это набор коммутаторов с одинаковыми:
- region name — именем региона
- revision level
- VLAN-to-instance mapping parameters
Каждый MST region поддерживает до 64-ёх multiple spanning-tree instances (MSTI). MSTP значительно уменьшает количество BPDU в сети путём включения STP-информации для всех MSTI в одну BPDU. MSTI configuration messages передают STP-информацию для каждого MSTI.
MSTP выбирает Regional Root Bridge для каждого MSTI. Regional Root Bridge выбирается на основании приоритета и рассчитывает дерево STP в назначенном MSTI.
MSTP кодирует информацию о регионе после стандартной RSTP BPDU. Поэтому коммутатор, на котором запущен RSTP воспринимает MSTP BPDU как RSTP BPDU. Такое поведение обеспечивает полную совместимость между устройствами с запущенным MSTP и устройствами с запущенными RSTP и даже STP посредством CST. Все RSTP-коммутаторы «видят» MST Region как один RSTP-коммутатор. Common Spanning Tree (CST) соединяет все MST регионы, а также STP-устройства, не связанные с конкретным регионом, облегчая end-to-end пути в MSTP среде.
Все MSTP окружения включают CST, который используется для соединения различных MST-регионов и независимых STP-устройств, т.е. MSTP работает с STP/RSTP через CST. Все коммутаторы в CST выбирают один Root Bridge, который ответственен за выбор пути для CST. Коммутаторы вне MST-региона рассматривают каждый MST-регион как единый виртуальный коммутатор несмотря на количество устройств в каждом MST-регионе.
Common and Internal Spanning Tree (CIST) — единая топология, которая соединяет все RSTP и MSTP коммутаторы через активную топологию. CIST имеет единый spanning tree, рассчитанный RSTP совместно с логическим продолжением подключения через MST-регион. MSTP рассчитывает CIST, а CIST обеспечивает соединение между сетями и устройствами в коммутируемой сети.
Настройка MSTP
На первый взгляд кажется, что mstp сложен для настройки, но если поставить себе более простую задачу, например, аналог RSTP, то все намного проще. Нужно для начала определить минимальное количество instance. Если должен быть один, в который будут включены все возможные, и такая конфигурация никогда не будет изменяться, то поэтому можно не читать про номера ревизий и т.п. Здесь в качестве нулевого — cist инстанс, через который mstp будет взаимодействовать с другими протоколами, а в первом msti — все возможные vlan. В качестве примера для 0 и 1 увеличены приоритеты. Бывает, что для 1-го увеличишь, а для cist — нет.
Для коммутаторов cisco:
spanning-tree mst configuration name name_region revision 1 instance 1 vlan 1-4094 spanning-tree mode mst spanning-tree mst 0-1 priority 28672
Для коммутаторов juniper:
qfx-3500> show configuration protocols mstp configuration-name name_region; revision-level 1; bridge-priority 28k; msti 1 { bridge-priority 28k; vlan 1-4094; }
Для коммутаторов eltex
spanning-tree mode mst spanning-tree priority 28672 spanning-tree mst configuration instance 1 vlan 1-4094 name name_region revision 1 exit spanning-tree mst 1 priority 28672
2018-10-08T10:12:43
Cisco