2. Граница
Домашние
абоненты Бизнес
Контент сторонних
поставщиков
Агрегация
Доступ
Ядро
Универсальный
доступ
Cisco
Prime IP NGN
SP сервисы/
Контент
nV
Граница и агрегация
управляются как единая
виртуальная система с
помощью Cisco Prime IP NGN
Plug-N-Play для выносов:
Уменьшение протокольной
сложности на сети агрегации
Упрощение замены ПО
Единый релиз ПО, единый
функционал
Масштабируемость по GE
портам простым
добавлением выносов
Каждое устройство
управляется отдельно:
различные процедуры
замены ПО, цикл жизни ПО
Сложная
протокольная
конфигурация
Различный функционал на
устройствах границы и
агрегации
Количество портов
ограничено физическим
шасси
Без: nV Технологии
С использованием:
nV Технологии
Обзор nV технологии ASR 9000
4. nV Edge Обзор архитектуры
Канал управление EOBC (L1 или L2* соединение)
Расширение управления: активный RSP и резервный RSP в разных шасси синхронизируют
свое состояние через EOBC канал связи
Расширение коммутации: объединение нескольких 10GE портов в специальный “nV fabric
link” канал связи для имитации коммутационной фабрики
Не требуется использования отдельного фабрик шасси
Отдельный
физический порт
EOBC 1G/10G на RSP
Active
RSP
Secondary
RSP
LC LC LC LC
0
Standby
RSP
Secondary
RSP
LC LC LC LC
1
Inter-chassis data link (L1 соединение)
Nx 10xG агрегация (до 32 портов)
Обычные 10G/40G/100G
порты коммутации
Internal
EOBC
Единая виртуальная ASR 9000 nV система
5. Позиционирование ASR 9000 Кластера
• Carrier Ethernet
• Business PE
• Video Distribution PE
• BNG
SP
• WAN/Campus Core
• Internet Edge
• Metro
• Enterprise PE
Enterprise
• DC Interconnect
• DC CoreDC
7. ASR 9000 nV Сателлит
Установить специальную версию ПО на устройстве доступа для его конвертации в ASR9K nV сателлит
Сателлит и ASR 9000 базовое шасси используют специальный протокол (аналог CDP) для автоматического
обнаружения, конфигурации и управления подключенными устройствами
Сателлит и хост могут находиться на разных узлах, нет ограничения на дистанцию между устройствами
Соединение между сателлитом и хостом называется “nV фабрикой”, может быть L1 или поверх L2 туннеля
С пользовательской точки зрения сателлиты выглядят как удаленные или виртуальные линейные карты
ASR 9000
Базовое шасси ASR 9000 и подключенные сателлиты это одна виртуальная система
“виртуальные/
удаленные”
интерфейсы
Протокол управления
Сателлит
Хост
nV фабрика
Локальные
интерфейсы
Единая ASR 9000 nV система
8. ASR 9000 Базовая система
Аппаратные и программные требования
Минимальная версия ПО XR 4.2.1
Любое ASR9000 шасси
• ASR9001
• ASR9006 / ASR9010
• ASR9904 / ASR9912
• ASR9922
Поддерживаемые RSP/ линейные карты
• RSP440 (-TR & -SE)
• Typhoon линейные карты (-TR* & -SE)
• Совместимость с Trident, SIP-700 и AVSM
линейными картами**
• nV Satellite & nV Cluster могут работать
совместно ***
* ”nV Ethernet” на -TR карте ограничен 8 очередями
** Trident и SIP-700 карты не поддерживают nV Satellite подключения; AVSM видео потоки на портах сателлита будут
поддерживаться в будущем
*** nV Cluster не поддерживает Trident или SIP-700 линейные карты
9. ASR 9000v Аппаратная составляющая
Электропитание
• Резервируемое -48
VDC подключение
• Один AC ввод
44x10/100/1000 Mbps вставки
• Коммутация на скорости порта
• Медные и оптические SFP
• Speed/duplex автоматическое
согласование
Заменяемый блок вентиляторов с
• ToD/PSS выходом
• BITS выходом
4x10G SFP+
• Первоначально используются только как nV
фабрик порты (в будущем могут
использоваться как порты доступа)
• Медные и оптические SFP+ вставки
Расширенный температурный
диапазон
• От -40C до +65C –работы
• От -40C до +70C –хранения
1 RU Высота
Максимальное энергопотребление
210 Вт
Номинальное 159 Вт
10. Обзор ASR 901
• Компактное, полностью резервируемое
устройство
3RU, 6 интерфейсных слотов
55Gbps емкость с RSP 1-ого поколения
Резервируемые источники электропитания
(<550W), FAN и RSP
Установка в 300 мм стойки (235 мм глубина)
Расширенный температурный диапазон от
-40º до 65º C
• Интерфейсы* и портовая емкость:
Ethernet : 1x10GE и 8x1GE модули
• Компактный маршрутизатор
1RU высотой
16 Gbps емкость коммутации
Резервированное электропитание и
вентиляторы
Энергопотребление менее ~50W
Установка в 300 мм стойки, 1RU
Расширенный температурный диапазон
от -40 до 65 C
• Интерфейсы* и портовая емкость:
Ethernet: 12 x GE
ASR 903 Платформа
пре-агрегации
*Поддерживаются только Ethernet интерфейсы
11. Управление nV сателлитом – взгляд пользователя
Uplink порты сателлита не конфигурируются, рассматриваются как внутренние nV фабрик интерфейсы
Порты доступа на сателлите представлены виртуальными “nV” интерфейсами на ASR 9000 базе. Пользователь
конфигурирует виртуальные интерфейсы так же как и обычные L2/L3 интерфейсы или саб-интерфейсы
Вся конфигурация сателлитов делается на базовой системе
Если порт доступа на сателлите переходит в состояние “Down”, то виртуальный интерфейс на базе также
принимает это состояние. Если административно выключить виртуальный “nV” интерфейс, то реальный порт на
сателлите также будет выключен
Порты доступа
сателлита
ASR 9000v
ASR 9000
Виртуальные порты
доступа –
соответствуют
физическим портам на
сателлите
“nv” Ethernet интерфейсы
interface GigabitEthernet 100/0/0/1
ipv4 address 1.1.1.1 255.255.255.0
interface GigabitEthernet 100/0/0/2.100 l2transport
encapsulation dot1q 100
rewrite ingress tag push dot1q 2
12. Обнаружение и управление nV cателлитом
Сателлит ASR 9000v
ASR 9000 База
MAC-DA MAC-SA Payload/FCSControl VIDCPU CPU
Фаза обнаружения
• Используется протокол второго уровня, аналогичный CDP, для обнаружения
сателлитов и периодических сообщений проверки связности
• Для проверки связности nV фабрик каналов раз в секунду посылается
сообщение. Также возможно определение отказов с помощью CFM (релиз IOS
XR 5.1.1)
Управление
• Специальный протокол, разработанный Cisco, поверх TCP
• Get/ Set сообщения для применения конфигурации и получения состояния
устройства
13. Нет локальной коммутации/маршрутизации на сателлите, все выполняется на хосте
Сателлит таким образом не выполняет заучивания MAC адресов
Все интеллектуальные функции реализуются на ASR 9000 шасси, виртуальных портах
Очень небольшой функционал может быть реализован на сателлитах, например, базовый
QoS, репликация широковещательного трафика, OAM измерение производительности, SyncE
и 1588*. Однако конфигурация их все равно выполняется на хосте, основном шасси
Сателлит ТОЛЬКО выполняет
локальную коммутацию
трафика между портами
доступа и фабрики
ASR 9000v
ASR 9000 Хост
Сателлит – передача данных (1)
14. MAC-DA MAC-SA Payload
MAC-DA MAC-SA Payload/FCSnV-tag
VLANs (OPT)
VLANs (OPT)
Сателлит – передача данных (2)
На сателлите
Принимается Ethernet фрейм на порту
доступа
Добавляется специальный nV-tag, затем
локальная коммутация на nV фабрику
Помещаем фрейм в исходящую очередь
порта nV фабрики и затем передаем его
Сателлит ASR 9000v
ASR 9000 Хост
MAC-DA MAC-SA PayloadVLANs (OPT)
На хосте
База получает фрейм на порту фабрики
Проверяет nV-tag, сопоставляет фрейм с виртуальным
портом доступа сателлита
В дальнейшем рассматриваем принятый пакет, как
полученный на локальном порту, применяем L2/L3
функционал, QoS, ACL, и т.д.
Пакет коммутируется на локальный порт или на другой
виртуальный порт сателлита
15. RP/0/RSP0/CPU0:R1#sh install active
Node 0/RSP0/CPU0 [RP] [SDR: Owner]
Boot Device: disk0:
Boot Image: /disk0/asr9k-os-mbi-4.2.1.22K.CSCtz10483-0.0.4.i/0x100305/mbiasr9k-rsp3.vm
Active Packages:
disk0:asr9k-px-4.2.1.22K.CSCtz10483-0.0.4.i
disk0:asr9k-satellite-px-4.2.1.22K ß пакет программного обеспечения (PIE)
disk0:asr9k-mini-px-4.2.1.22K
disk0:asr9k-mpls-px-4.2.1.22K
disk0:asr9k-mcast-px-4.2.1.22K
disk0:asr9k-fpd-px-4.2.1.22K
RP/0/RSP0/CPU0:R1#install nv satellite ?
<100-65534> Satellite ID
all All active satellites
RP/0/RSP0/CPU0:R1#install nv satellite 100 ?
activate Install a new image on the satellite, transferring first if necessary
transfer Transfer a new image to the satellite, do not install yet
RP/0/RSP0/CPU0:R1#install nv satellite 100 active
В ROM памяти сателлита
всегда находится
резервная копия ПО
(Golden image)
Управление сателлитом – Обновление ПО
18. Схемы подключения сателлитов
Модель 1: Статическая привязка. Нет
резервирования фабрик портов
Любой порт доступа может быть привязан к
любому фабрик порту. При отказе фабрик порта
соотвествующие порты доступа автоматически
отключаются
Модель 2: Агрегация фабрик каналов.
Резервирование фабрик портов
• Трафик портов доступа балансируется по фабрик
интерфейсам, составляющим агрегированный канал
• При отказе одного из фабрик интерфейсов трафик
разбалансируется по оставшимся
• Балансировка трафика по фабрик каналам – по
порту доступа, при этом на стороне сателлита и базы
выбор фабрик канала может не совпадать
Порты
доступа
Фабрик
порты
1
2
Satellite
Поддержка
смешанного режима
с IOS XR 4.3.0
19. Настройка сателлитов: подключение к хосту
RP/0/RP0/CPU0:ios#show route vrf **nVSatellite!
!
VRF: **nVSatellite!
!
<пропущено>
Gateway of last resort is not set!
!
L 10.0.0.1/32 is directly connected, 00:12:01, nV-Loopback0!
C 10.0.101.1/32 is directly connected, 00:01:01, TenGigE0/1/0/0!
<пропущено>
nv!
satellite 101!
type asr9000v!
interface TenGigE0/1/0/0!
nv!
satellite-fabric-link satellite 101!
remote-ports GigabitEthernet 0/0/0-10!
1
2
Определение Satellite ID и Type
Определение Satellite ICL
22. MST/REP/G.8032 пакеты обрабатываются на Базе
Порты доступа сателлитов полностью поддерживают MST/MST-AG/REP-AG/G.8032
PVST-AG поддерживается только для статической модели подключения сателлита
L2 доступ с STP/
REP/G.8032
L2 резервирование подключений доступа
Поддерживаемые STP/REP/G.8032 конфигурации
Сателлит
Сателлит
24. nV Satellite сетевые топологии
Кольцевое, каскадное, подключение к двум хостам и L2
фабрика
Сателлит
VLAN-B
VLAN-A
CFM
CFM
Сателлит
Сателлит
Сателлит
CFM
CFM
СателлитСателлит
CFM ICCP
Сателлит
Host A
Host B
XR 5.1.1
25. ICCP: Синхронизация состояний хостов
Синхронизация MAC адресов баз и приоритетов сателлитов
Пользователь создает redundancy group, конфигурирует системный MAC и задает
приоритет каждого сателлита на каждом из хостов (опционально). Оба хоста в каждой
«redundancy group» синхронизируют системный MAC адрес и приоритеты сателлитов
Системный MAC адрес должен совпадать на обоих базах. Если он отличается, то
берется наименьший МАС обоих хостов
Приоритет сателлита используется для определения его Active/Backup статуса на каждой
из баз.
S
SDCP
SDCP
ICCP
Host-chassis-MAC,
iccp-system-MAC,
satellite-priority
Хост 1
Хост 2
26. redundancy iccp group <group-id>
nv satellite
system-mac <macaddr>
interface TenGigE 0/1/0/1
nv satellite-fabric-link satellite 100
host-redundancy iccp-group <group-id>
host-priority <0-255>
← ICL или фабрик-порт
← опционально, меньше число, выше приоритет
Подключение к двум хостам, пример CLI
Балансировка трафика Active/Standby от хостов к сателлитам
Основной хост выбирается на основании заданного приоритета. Если приоритеты равны, то
используется MAC адрес каждого из шасси
E-ICCP
Сателлит
27. SDCP расширение для Dual-Host сценария
Сателлит «слышит» hello обоих баз (host-chassis-mac, iccp-system-mac, satellite priority, port-mapping)
Если host-chassis-mac разные И iccp-system-mac адрес одинаков, то это dual-host сценарий
Если host-chassis-mac разные И iccp-system-mac тоже разные, то это может означать неправильную системную
MAC конфигурацию без ICCP синхронизации (например, начальное состояние), «split-brain» сценарий или не
Dual-Host подключение
Сателлит будет поддерживать SDCP сессию с текущей активной базой и сбросит соединение с
альтернативным хостом
Альтернативная база потеряет SDCP подключение и выключит ассоциированные с сателлитом
виртуальные порты доступа
Failover: когда сателлит детектирует отказ основного хоста, он переассоциирует порты доступа на запасную
базу. Подобное переключение портов составляет менее 10 мс
S
Host-chassis-MAC, iccp-system-
MAC, priority, port-mapping
ICCP
Host-chassis-MAC, iccp-system-
MAC, priority, port-mapping
Хост 1
Хост 2
28. Хост 1
Хост 2
Сценарии отказов и время их определения (1)
Время определения отказа
LoS детектирование: << 50 мс на сателлите и базе
LoS + Нотификация: используется в кольцевой топологии
CFM: CFM между сателлитом и базой как средство определения отказа. Применимо ко всех
сценариях, обязательно для L2 фабрик топологии
SDCP keepalive: 3 по 1 секунде. Применимо к всем топологиям в качестве запасного средства
Сценарии отказов: A,B,C (порт, канал, порт)
Определяется одновременно сателлитом и хостом, независимые процедуры восстановления
Основной хост посылает нотификацию запасному хосту. Запасной хост становится активным
S ICCP
A
B
C
SDCP
SDCP
29. Хост 1
Хост 2
Сценарии отказов и время их определения (2)
Сценарий D (отказ основного H2 узла)
Сателлит обнаружит отказ по LoS (или CFM) и переключится на резервную базу
Хост H1 теряет ICCP сессию. Обнаружение возможно за счет ICCP route-watch (BFD в будущем)
Если хост обнаруживает отказ ICCP соседства, то он анонсирует свой собственный MAC адрес шасси в качестве
системного MAC в сторону сателлита
Сателлит переключает свои порты доступа на новую базу, когда он получает новый системный МАС
H1 становится новым активным хостом
Сценарий E (отказ резервного H1 узла)
Основной хост H2 теряет ICCP соседа
Если хост обнаруживает отказ ICCP соседства, то он анонсирует свой собственный MAC адрес шасси в качестве
системного MAC в сторону сателлита
Сателлит сохраняет SDCP сессию с текущим хостом, когда он получает новый системный МАС
Нет потери трафика
S ICCP
SDCP
SDCP D
E
32. Кольцевое и каскадное подключение сателлитов
Топологии
Каскадная к одному хосту (5.1.1)
Кольцевая к двум хостам (5.1.1)
Балансировка трафика в кольцевой топологии с двумя хостами
Active/standby для каждого сателлита
Каждый сателлит может выбрать один активный хост. Сателлиты в кольце могут выбрать
разные хосты в качестве активных
S
S
S
SS
S
Кольцевая топология
с двумя хостами
Каскадная топология
Хост 1
Хост 2
33. Кольцевая топология с двумя хостами
Каждый сателлит в кольце поддерживает SDCP сессию (опционально CFM) с двумя
хостами
Физическая кольцевая топология логическая Hub-and-Spoke топология
Нет локальной коммутации трафика между двумя сателлитами в кольце, весь трафик
проходит через хост
Определение отказов, восстановление и время восстановления аналогично Hub-and-
Spoke топологии
S1
ICCP
SDCP
SDCPS2
S3
ICCP
SDCP
SDCPS2
Физическая кольцевая, логическая H&S топология Физическая H&S топология
Хост 1
Хост 2
Хост 1
Хост 2
35. Инкапсуляция данных: Кольцевая/ Каскадная/ L2
топологии
Один VLAN тег недостаточен для идентификации сателлита и его порта доступа
802.1ah (Mac-in-Mac) инкапсуляция
I-SID для идентификации порта доступа
B-MAC для идентификации сателлита или хоста
Принципы коммутации трафика на сателлите:
Если MAC DA == MyMAC, то обработать
В противном случае передать дальше
BVID в B-MAC коммутационном домене
Нетегирован для SDCP контрольных сессий и CFM
Одиночный BVID для пользовательских данных
Различные BVID для репликации Multicast трафика
в кольце
DMAC=H1
MAC: H1
Satellite ID Satellite access port ID
S3
S2
S4
S1
MAC: H2
Host ID
Сателлит
S2
Хост
H1
DMAC: H1 SMAC: S2 BVID I-SID Original Access Port Frame
Хост 1
Хост 2
36. Автоматическое согласование в Кольцевой/
Каскадной топологиях (1)
H1 посылает Multicast пробник к S1 от MAC адреса фабрик-порта. S1 изначально слушает все пробники
на всех портах
S1 принимает пробник и посылает в ответ Unicast сообщение, указывая в нем свой серийный номер
H1 принимает ответ от S1. На основе серийника идентифицируется Satellite ID и его конфигурация
H1 отправляет базовую конфигурацию S1 в широковещательном сообщении, указывая IP адрес
управления
H1 инициализирует SDCP сессию управления с S1 и загружает конфигурацию на S1. S1 программирует
порты доступа
S1 готов к работе, коммутации трафика и будет использован для дальнейшего обнаружения устройств в
кольце
S1
S4
S2
S3
MAC A
MAC B
Хост 1
Хост 2
37. Автоматическое согласование в Кольцевой/
Каскадной топологиях (2)
S1 продолжает получать Multicast one-hop пробники от H1, которые включают MAC адрес хоста
S1 добавляет к пробнику собственную информацию, как то - S1 MAC, количество хопов до
хоста, и передает пробник по всем “non-access” портам
S2 принимает пробник, отправляет Unicast ответ H1. S1 прозрачно коммутирует трафик между
фабрик-портами в сторону H1 на основе D-MAC (=H1)
H1 сообщает базовую конфигурацию S2 и затем устанавливает сессию управления. H1
загружает полную конфигурацию на S2. S2 готов к работе
Процесс продолжается …
H2 проводит аналогичные процедуры с другой стороны кольца
S1
S4
S2
S3
Хост 1
Хост 2
38. Ring Operation
Добавление сателлита в кольцо
Начальное состояние
S1, S2 H1 выбран активным хостом, S3 H2 активный хост
S4 добавлен между S1-S2
S1 и S2 обнаруживают отказ фабрик канала
S2 переключается на H2 хост
S1 и S2 детектируют восстановление фабрик-канала и отправляют пробники
S4 устанавливает сессию управления с H1 и H2
S4 программируется, выбирает H1 в качестве активного хоста по критерию количества хопов до
него или заданного приоритета. S2 поддерживает активную сессию с H2
S3
S1
S2
S4
Хост 1
Хост 2
39. Ring Operation
Удаление сателлита из кольца
Начальное состояние
S1, S4 H1 активный хост, S2, S3 H2 активный
S4 удаляется из кольца, S1-S2 подключены друг к другу
S1 и S2 детектируют отказ фабрик-канала, оба сателлита теряют одну из SDCP сессий с хостами
S1 и S2 определяют, что фабрик-канал работоспособен, посылают пробы
S1 и S2 устанавливают сессии управления с хостами
S2 пересчитывает количество хопов до H1 и выбирает его в качестве активного хоста
S3
S1
S2
S4
Хост 1
Хост 2
40. Быстрое определение отказа (1)
LoS отсутствие сигнала + нотификация по каналу
управления
S1
S4
S2
S3
S2: После определения отказа
канала посылает Multicast
сообщение “H1 недоступен” всем
сателлитам и хостам
S1: Посылает сообщение “H2 недоступен”
S3/S4: При получении сообщения
«H1 недоступен» изменить
приоритет H1 и начать работать с H2
H1/H2: (при получении сообщений от S1/S2)
Восстановление сервисов
Хост 1
Хост 2
41. Быстрое определение отказа (2)
С использованием CFM
Каждый сателлит поддерживает две независимые CFM сессии с каждым хостом
При отказе канала/узла все сателлиты обнаружат это независимо и одновременно, что
приведет в переходу на резервный хост
Минимальные CFM таймеры зависят от аппаратного обеспечения сателлита и хоста
S1
S2
S3
При отказе S1-S2 канала
S1 теряют CFM сессию к H2
S2/S3/S4 теряют CFM сессию
к H1
Хост 1
Хост 2
S4
43. Хост 2
Хост 1Сателлит 101Один интерфейс
• С двумя VLAN/EVC
Два интерфейса
• Каждый с VLAN/EVC
Sub-interface:
VLAN 11, 21
Сателлит 102
VLAN: 11
VLAN: 12
VLAN: 21
VLAN: 22
Sub-interface:
VLAN 12,22
Поддерживаемые схемы L2 подключений
44. MAC-DA MAC-SA BVID I-SID VLANs (OPT) Payload/FCS
Сателлит
L2 фрейм (802.1q)
Каждый L2 сабинтерфейс соответствует на
хосту одному сателлиту
Транспортный VLAN (B-
VLAN) для передачи
данных в «облаке»
Сателлит
B-VLAN: A
B-VLAN: B
B-VLAN: A
B-VLAN: B
Сателлит
Single Home
Dual Home:
Один интерфейс, два VLAN Dual Home: Два канала
L2 фабрика – формат пакетов
46. Автоматическое согласование
L2 Фабрика
Хост 1 каждую секунду посылает Multicast пробники со своего MAC адреса (L2 фабрика
добавляет .1Q тэг - BVID). S201 слушает пробники на всех своих портах
S201 принимает пробник, который содержит .1Q тэг, таким образом сателлит узнает
транспортный VLAN
S201 отправляет Unicast ответ (с ранее определенным .1Q тэг), обязательно указание
серийного номера
Хост 1 принимает ответ от S201, на основании серийного номера сателлита определяет его
конфигурацию
Host 1 и S201 устанавливают соседство, S201 применяет конфигурацию
Аналогичный процесс для Хоста 2 / S201
Хост 1
Хост 2
S201 VLAN-X
VLAN-Y
47. Сателлит
CFM
CFM
ICCP
Fast Fabric Link Failure Detection
L2 фабрика
CFM контрольная связность между сателлитом
и хостом
При обрыве CFM сессии сателлит
перекоммутируется на резервный хост,
переключает порты доступа
Новый активный хост уведомляет резервный по
ICCP каналу. Происходит переключение
сервисов
interface TenGigE 0/2/0/2.11 l2transport
encap dot1q 11
nv satellite-fabric-link network
satellite 101
host-redundancy iccp-group 10 host-priority 100
remote-ports GigabitEthernet 0/0/0-9
ethernet cfm level <level> continuity-check interval <interval>
Хост 1
Хост 2
48. Реализация QoS (1) – База -> Сателлит
P1: протокол управления сателлитом
50 Mbps police
Regular MQC, H-QoS
P1 +P2 + P3+ Normal“nv” Ethernet
“nv” Ethernet
“nv” Ethernet
“nv” Ethernet
“nv” Ethernet
Regular MQC, H-QoS
P1+P2 + P3+ Normal
…
…
…
ASR 9000v Fabric
port
ASR 9000 Хост
Ограничение трафика на “nv” Ethernet интерфейсе с
соответствии с реальной скоростью порта на сателлите:
10/100/1000Mbps перед отправкой на фабрику
Неблокируемо
на сателлите
49. Реализация QoS (2) – Сателлит -> База
P1: Управл. сателл.
50mbps policed
P2: сигнализация
1G policed
Пользоват. данные
Приорит. очередь
Пользоват. данные
Нормальн. очередь
Cos/IPP/EXP 5-7
L2/L3 трафик
управления
ASR 9000v
ASR 9000 Хост
• Пользовательские приоритетные и обычные данные попадают не в приоритетные очередь на фабрик
порту, неявно поддерживается отношение 100:1
• P1 и P2 передаются с приоритетом относительно пользовательских данных
• И контрольный и пользовательский трафик классифицируется по очередям неявно
Порт
фабрики
Regular MQC, H-QoS
P1+P2 + Normal
Политика MQC QoS на входе
“nv” Ethernet интерфейса
Cos/IPP/EXP 0-4
50. Реализация QoS (3) – развитие
• Ограничение входящего трафика на порту
• Классификация трафика на входе
• Маркировка CoS/DSCP на входе
• Исходящая приоритетная очередь
Сателлит
• 2-ух уровневый H-QoS на фабрик порту, на
физическом или саб-интерфейсе
• Для пользовательского трафика: 2 PQ + 4 Q
очереди
P1: Satellite protocol
50MB policed
P2: control packet
1G policed
User data
Priority queue 1
User data
Priority queue 2
Normal queue 1
Normal queue 2
Normal queue 3
Хост
Normal queue 4
XR 5.1.1
51. interface gig 101/0/0/1.10 l2transport
encapsulation dot1q 10
rewrite ingress tag pop 1 sym
service-policy input user-qos1
service-policy output user-qos
nv satellite
service-policy input user-qos2
Отметим: пользователь может сконфигурировать QoS политику на вход
либо только на хосте, либо на сателлите, но не обе
одновременно!
ß функционал, применяемый на сателлите
ß qos политика на порту доступа сателлита (только на вход)
ß qos политика на хосту, порт доступа
ß qos политика на хосту, порт доступа
Реализация QoS - CLI пример (1)
Ingress qos политика на порту доступа сателлита
XR 5.1.1