Inside Cisco IOS®

Software

Arcitecture



Vijay Bollapragada, CCIE #1606,
Curtis Murphy, CCIE #1521,	<

Russ White, CCIE #2635

Cisco Systems

Cisco Press ’

Cisco Press -
201 West 103rd Street,
Indianapolis, IN 46290 USA
Структура
операционной
системы Cisco IOS®

Виджэй Боллапрагада, CCIE #1606,

Кэртис Мэрфи, CCIE #1521,
Расс Уайт, CCIE #2635

Москва • Санкт-Петербург* Киев
2002
ББК 32.973.26-018.2.75

Б79

УДК 681.3.07

Издательский дом “Вильямс”

Зав. редакцией С.Н. Тригуб

Перевод с английского А.И. Бенилова, А.Ю. Олейникова, А.А. Судакова
и К.Э. Юштина

Под редакцией А.В. Мысника

По общим вопросам обращайтесь в Издательский дом “Вильямс”
по адресу: info@williamspublishing.com, http://www.williamspublishing.com

Боллапрагада, Виджэй, Мэрфи, Кэртис, Уайт, Расс.

Б79 Структура операционной системы Cisco IOS. : Пер. с англ. — М. : Издатель-
ский дом “Вильямс”, 2002. — 208 с. : ил. — Парал. тит. англ.

ISBN 5-8459-0264-9 (рус.)

В этой книге представлена основная техническая информация о структуре и
принципах работы операционной системы 1OS маршрутизаторов Cisco. Целью
книги является углубленное рассмотрение ключевых моментов структуры и
функционирования операционной системы IOS. Кроме всего прочего, в издании
также содержится описание аппаратного устройства некоторых платформ Cisco.
Описание аппаратных решений используется как иллюстрация уникальных воз-
можностей операционной системы IOS.

Книга может использоваться как вместе с другими книгами из серии Cisco
Press для подготовки к экзаменам на звание сертифицированного Cisco систем-
ного администратора, так и в качестве самостоятельного справочного пособия.

ББК 32.973.26-018.2.75

Все названия программных продуктов являются зарегистрированными торговыми марками
соответствующих фирм.

Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой
бы то ни было форме и какими бы то ни было средствами, будь то электронные или механиче-
ские, включая фотокопирование и запись на магнитный носитель, если на это нет письменного
разрешения издательства Cisco Press.

Authorized translation from the English language edition published by Cisco Press, Copyright © 2000

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage
retrieval system, without permission from the Publisher.

Russian language edition published by Williams Publishing House according to the Agreement with
R&l Enterprises International, Copyright © 2002

ISBN 5-8459-0264-9 (pyc.)

ISBN 1-57870-181-3 (англ.]

© Издательский дом “Вильямс”, 2002

© Cisco Press, 2000
Оглавление

Глава 1. Введение в структуру операционной системы IOS 11

Глава 2. Принципы коммутации пакетов	47

Глава 3. Маршрутизаторы с разделяемой памятью	71

Глава 4. Первые машрутизаторы с шиной Cbus	87

Глава 5. Распределенные системы	95

Глава 6. Маршрутизаторы Cisco 7500	111

Глава 7. Гигабитовый коммутирующий
маршрутизатор Cisco 12000	143

Глава 8. качество обслуживания	163

Приложение А. Протокол коммутации NetFlow

191
Содержание

Введение	9

Глава 1. Введение в структуру операционной системы IOS 11

Устройство операционных систем	11

Управление ресурсами центрального процессора и	многозадачность	12

Управление памятью	14

Прерывания	15

Структура операционной системы IOS	15

Организация памяти	16

Пулы памяти	19

Процессы в системе IOS	21

Цикл жизни процесса	21

Приоритеты процессов в системе IOS	23

Примеры процессов	24

Ядро системы IOS	27

Планировщик	27

Менеджер памяти	31

Менеджер пакетного буфера	37

Системные буферы	38

Драйверы устройств	44

Резюме	44

Глава 2. Принципы коммутации пакетов	47

Программная коммутация	48

Балансировка нагрузки каналов с использованием	программной коммутации 50

Недостатки программной коммутации	51

Быстрая коммутация: кэширование для экономии ресурсов	53

Структура быстрого кэша	55

Поддержка кэша	58

Использование процесса балансировки нагрузки и механизма быстрой
коммутации	60

Оптимальная коммутация	61

Экспресс-пересылка корпорации Cisco	63

Как работает CEF	64

Балансировка нагрузки и CEF	67

Резюме	69

Глава 3. Маршрутизаторы с разделяемой	памятью	71

Аппаратное устройство маршрутизаторов с разделяемой памятью	71

Центральный процессор	72

Память	73

Контроллеры интерфейсов	76

Буферы пакетов маршрутизаторов с разделяемой памятью	76

Локальные буферные пулы	76

Кольца приема и передачи	78

Коммутация пакетов в маршрутизаторах с разделяемой	памятью	80

Получение пакета	80
Коммутация пакета	81

Передача пакета	83

Резюме	85

Глава 4. Первые машрутизаторы с шиной Cbus	87

Аппаратные принципы создания маршрутизаторов AGS+	87

Коммутация пакетов на шине Cbus	89

Автономная коммутация	90

Быстрая пакетная память шины Cbus	90

Маршрутизаторы серии Cisco 7000	92

Резюме	93

Глава 5. Распределенные системы	95

Управление фрагментарным буфером	95

Пулы фрагментов	98

Слияние фрагментов	99

Маршрутизаторы серии 7200	99

Аппаратное устройство маршрутизаторов 7200	101

Память	ЮЗ

Коммутация пакетов в маршрутизаторах Cisco серии 7200	105

Этап получения пакета	105

Этап коммутации пакета	106

Этап передачи пакета	108

Этап передачи пакета: программная коммутация	109

Резюме	109

Глава 6. Маршрутизаторы Cisco 7500	111

Аппаратная структура маршрутизатора Cisco 7500	111

Шина данных	112

Процессор коммутации-маршрутизации	113

Центральный процессор (CPU)	114

Быстрая пакетная память	114

Выделение буферов в памяти MEMD и неиспользуемые
сетевые интерфейсы	116

Основная память	120

Коммутация пакетов в маршрутизаторах Cisco 7500	120

Прием пакета при RSP-коммутаиии	121

Коммутация пакета с использованием модуля RSP	122

Передача пакета при RSP-коммутации	126

Структура многоцелевых интерфейсных процессоров (VIP)	127

Составные компоненты модуля VIР	128

Модели многоцелевых интерфейсных процессоров	130

Обработка пакетов процессором VIР: распределенная коммутация	131

Буферизация в устройстве VIР на стороне приема	136

Устранение неисправностей в маршрутизаторах Cisco 7500	137

Перегрузка центрального процессора	137

Аннулирование пакетов на входе	139

Игнорирование пакетов	140

Аннулирование пакетов на выходе	140

Резюме	141
Глава 7. Гигабитовый коммутирующий
маршрутизатор Cisco 12000	143

Аппаратная структура	143

Коммутирующая структура	144

Шина обслуживания	149

Гигабитовый процессор маршрутизации	149

Линейный адаптер	150

Коммутация пакетов	155

Коммутация пакетов в устройствах перенаправления типов 0 и 1	156

Коммутация пакетов в устройстве перенаправления типа 2	157

Коммутация ячеек через структуру	159

Передача пакетов при коммутации	159

Резюме	160

Глава 8. Качество обслуживания	163

Обзор технологии QoS	163

Использование приоритетной очереди	166

Настраиваемые очереди	168

Справедливая взвешенная очередь	171

Распределенная взвешенная справедливая очередь	180

Механизм циклически изменяемого дефицита	183

Конфигурирование механизма MDRR	185

Механизм взвешенного случайного раннего обнаружения перегрузок	186

Выборочное аннулирование пакетов	189

Другие возможности технологии QoS	189

Резюме	189

Приложение А. Протокол коммутации NetFlow	191

Управление кэшем потока	192

Экспорт потока	194

Экспорт агрегированных данных протокола NetFlow
с помощью маршрутизатора	195

Предметный указатель	196
Введение

Заглянув в любой книжный магазин, вы обнаружите огромное количество книг по
сетевым технологиям, начиная от описания протоколов передачи данных и заканчи-
вая созданием сетей. В наше время уже никто не сомневается, что компьютерные се-
ти стали одной из самых популярных сфер человеческой деятельности благодаря
стремительному росту Internet и все большему слиянию технологий передачи данных,
голоса и видео. Корпорация Cisco разработала очень удачную бизнес-модель продажи
необходимого сетевого оборудования, которое формирует инфраструктуру сети (по
некоторым подсчетам ее доля рынка в данной сфере сегодня составляет более 85%), а
операционная система Cisco IOS превратилась в индустриальный стандарт де-факто.
Несмотря на то что существует множество книг о принципах создания сетей и работе
протоколов, которые используют системы на базе IOS, малая толика этой информа-
ции доступна из источников, не относящихся к корпорации Cisco.

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

Данная книга — это попытка объединить и упорядочить изобилие разрозненной
информации о структуре и принципах работы операционной системы IOS. Часть ис-
пользуемой в книге информации ранее была публично доступна в форумах, группах
новостей, на презентациях корпорации Cisco и в материалах центра технической под-
держки, однако большую часть из того, что представлено в данной книге, вы не най-
дете в технической документации Cisco.

Цель книги

Структура операционной системы JOS задумана как настольная книга для админист-
раторов и специалистов по разработке и созданию компьютерных сетей. Целью книги,
прежде всего, является рассмотрение ключевых моментов структуры и функционирова-
ния операционной системы IOS. Кроме всего прочего, в настоящем издании описана
аппаратная структура некоторых специфических платформ Cisco, поскольку операцион-
ная система IOS является встроенным миниатюрным программно-реализованным ин-
терфейсом для специфического аппаратного оборудования и в большинстве случаев не
может быть рассмотрена отдельно. Однако следует заметить, что данная книга никоим
образом не претендует на самый полный справочник по сетевым устройствам Cisco.
Описание аппаратных решений используется только как иллюстрация к некоторым
уникальным возможностям операционной системы IOS. Кроме того, вы, несомненно,
обратите внимание на тот факт, что книга не затрагивает множество распространенных
аппаратных платформ, так, например, вы не встретите здесь ни малейшего упоминания
о коммутаторах Catalyst, а также никаких сведений о серверах доступа. В основном это
вызвано тем, что устройства, не описанные в книге, очень похожи на те, которые при-
ведены в примерах или, как в случае с коммутаторами Catalyst, коренным образом отли-
чаются от рассматриваемых и поэтому требуют отдельной книги.
Ключевые темы этой главы

	Принципы построения операционной системы

	Обзор структуры IOS	?

	Методы управления памятью

	Процессы системы IOS /	*

	Ядро операционной системы 1OS

	Управление пакетными буферами

	Драйверы устройств *
Глава

1

Введение в структуру
операционной системы IOS

Если бы вас попросили назвать самые известные и широко используемые операци-
онные системы, какие из них вы бы выбрали? Вероятнее всего, в ваш список попали бы
такие названия, как UNIX, MS-DOS, Microsoft Windows и даже MVS — операционная
система фирмы IBM для мэйнфреймов. Все вышеперечисленные системы известны до-
вольно широко, и одна из них наверняка установлена на вашем компьютере. Но если
задуматься на минутку — ведь существуют же и другие! Отметили ли вы в своем списке
такую систему, как Cisco IOS? Скорее всего, нет, хотя IOS на сегодняшний день являет-
ся одной из наиболее развитых операционных систем.

В отличие от операционных систем общего назначения, IOS никогда не использу-
ется нами напрямую. Большинство пользователей, работающих с Internet, даже не по-
дозревают, что за всем этим стоит IOS. Впрочем, даже те, кто непосредственно имеют
дело с IOS, зачастую воспринимают ее не как полноценную систему, а лишь как
программу, управляющую работой маршрутизатора Cisco.

Система 1OS не позволяет вам пользоваться текстовым редактором или какими-
либо бухгалтерскими приложениями, как это делают другие системы общего назначе-
ния. Однако IOS все же, является полноценной операционной системой, пусть и
предназначенной лишь для быстрото й эффективного переключения путей следования
информационных пакетов. Именно на этом сосредоточенно все внимание системы
IOS, как мы увидим в дальнейшем.

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

Для начала мы познакомимся с основными концепциями и определениями, которые
будут полезны для дальнейшего понимания устройства системы IOS. Если вы уже зна-
комы с принципами работы операционных систем, не теряйте времени и переходите к
изучению раздела “Структура операционной системы IOS”. Заключительная часть главы
посвяшена наиболее важным структурным элементам системы IOS.

Устройство операционных систем

Перед современными операционными системами стоят две основные задачи:
управление ресурсами и логическое разделение между аппаратной и программной
частями вычислительной системы. Такое разграничение предоставляет разработчикам
интерфейс между прикладными программами и аппаратной частью компьютера. Это
означает, что программисту вовсе не обязательно знать тонкости аппаратуры: ведь
программный код, общающийся непосредственно с различными устройствами, уже
написан и встроен в операционную систему. Программисту остается лишь воспользо-
ваться возможностями системы, а не изобретать велосипед.

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

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

Некоторые операционные системы позволяют выполнять только одну программу в
конкретный промежуток времени (таким образом, например, работает большинство
систем семейства MS-DOS). Однако большинство современных операционных систем
позволяет приложениям функционировать совместно. Ситуация, когда программы
выполняются одновременно, называется многозадачностью (multitasking), а операци-
онная система, позволяющая работать в таком режиме, — многозадачной операционной
системой (multitasking operating system).

Компьютерные программы, написанные для многозадачных систем, сами зачастую со-
держат несколько независимых задач, выполняющихся параллельно. Подобные маленькие
программы-задачи получили название потоков (threads), поскольку они все вместе форми-
руют единый поток выполняемых инструкций программы. Каждый поток снабжен персо-
нальным набором значений регистров центрального процессора — контекстом (context).
Потоки, выполняемые внутри одной программы, могут использовать общую область опе-
ративной памяти. Группа потоков, разделяющих общее пространство памяти и совместно
пользующихся ресурсами операционной системы, носит название процесса (process). Если
процессор и операционная система поддерживают работу с так называемой виртуальной
памятью1, то каждый отдельно взятый процесс может выполняться в своем адресном про-
странстве, защищенном от доступа со стороны других процессов.

Поскольку в конкретный момент времени процессор может отрабатывать инструкции
только одной программы, операционная система должна сама решать, какие именно набо-
ры инструкций (потоки) будут выполняться. Процесс принятия решений такого рода на-
зывается планированием (scheduling). Планирование задач обычно возлагают на централь-
ную часть операционной системы — ядро (kernel). В зависимости от специфики приложе-
ний, на исполнение которых рассчитана конкретная операционная система, могут
использоваться различные механизмы планирования потоков. Различные типы приложе-
ний (пакетные приложения, интерактивные, программы реального времени) по-разному
загружают центральный процессор. Поэтому в целом производительность системы сущест-
венно зависит от выбранного механизма планирования.

Простейший метод планирования заключается в выстраивании всех потоков в порядке их
появления и выполнении каждого потока до его полного завершения. Этот механизм полу-
чил название исполнение до полного завершения в порядке FIFO (first-in-first-out — аналог очере-
ди: первым вошел — первым вышел). Несомненными преимуществами данного метода пла-
нирования являются простота реализации, очень низкий показатель вычислительных затрат
и его “справедливость” — все потоки обрабатываются поочередно по мере их появления. *

' Программе абсолютно не обязательно знать свое точное месторасположение в памяти. Поэтому
в многозадачных системах используется относительная адресация, а выполняемые процессы полага-
ют, что им доступна вся операционная память. Это также позволяет симулировать наличие в
системе большего количества памяти, нежели есть на самом деле. — Прим, перев.
Рассмотренный метод планирования хорошо применим для пакетных и некоторых
транзакционных приложений, которые последовательно обрабатывают данные, а за-
тем завершают свою работу. В тоже время данная схема абсолютно не применима для
интерактивных приложений и приложений реального времени. Поскольку интерак-
тивные программы должны оперативно обслуживать внешние устройства и реагиро-
вать на команды пользователя, такие приложения требуют быстрого, хотя и кратко-
временного доступа к ресурсам центрального процессора.

Одним из путей решения данной проблемы является назначение приоритетов для
каждого потока. Критичные по времени выполнения потоки, требующие оперативно-
сти со стороны центрального процессора, наделяются более высоким приоритетом,
нежели, скажем, пакетные приложения. Потоки с более высоким приоритетом могут
напрямую перемещаться в начало очереди ожидающих выполнения потоков. Если же
в очереди присутствует несколько потоков с одинаковым приоритетом, то они выпол-
няются в порядке их появления (так же, как и для обычного планирования FIFO).
Описанный метод планирования носит название приоритетное исполнение до полного
завершения (run-to-completion priority scheduling).

Несмотря на то что приоритетное планирование задач имеет несомненные пре-
имущества перед планированием FIFO, оно все же имеет серьезный недостаток — по-
ток с высоким приоритетом может монополизировать использование центрального
процессора. К тому же, если процессор уже занят выполнением потока с низким при-
оритетом, отнимающем больше процессорного времени, потоки с более высоким
приоритетом “застревают” в очереди на выполнение, ожидая освобождения процессо-
ра. Для решения возникшей проблемы рассмотренный метод планирования должен
иметь возможность откладывать (прерывать) выполнение текущего потока, таким об-
разом, чтобы другие потоки могли пользоваться ресурсами центрального процессора.

Приоритетное прерывание выполнения

Вынужденная остановка выполнения одного потока с целью предоставления ресур-
сов центрального процессора называется приоритетным прерыванием (preemption), а со-
ответствующий метод планирования — планированием с приоритетным прерыванием
(preemptive scheduling, или преемптивное планирование). Функция преемптивного пре-
рывания всецело возлагается на ядро операционной системы, которое периодически ме-
няет выполняемые процессором потоки путем переключения контекстов (context switch).
Сигналом, по которому будет происходить переключение контекстов, может выступать,
к примеру, системный таймер или же прямой вызов функции ядра системы. В первом
случае каждому потоку выделяется промежуток времени выполнения центральным про-
цессором. По истечении этого времени поток искусственно прерывается, и ресурсы пе-
редаются следующему. Если же поток сам решил передать полномочия своим конкурен-
там, он вызывает специальную функцию ядра системы, которая и осуществляет пере-
ключение потоков. Итак, когда поступает сигнал на переключение контекстов, ядро
выбирает очередной поток из очереди, а прерванный поток возвращает назад ожидать
следующей возможности использовать ресурсы процессора.

Внимание!

Как мы уже видели, переключение контекстов буквально означает, что ядро системы
освобождает центральный процессор от выполнения одного потока и назначает вы-
полнение следующего. Другими словами, компьютер просто меняет задачу, над кото-
рой он работает. Однако само переключение контекстов тоже является задачей, от-
нимающей процессорное время. Ведь все значения регистров (контекст) прерванного
потока должны быть сохранены, а регистры очередного потока соответственно загру-
жены. Контекст позволяет задаче, получающей право на выполнение, “вспомнить" то,
чем она занималась во время последнего ее прерывания.
Перечислим основные преимущества многозадачности с приоритетным прерыванием.

	Предсказуемость. Поток “знает” с некоторой точностью, когда он будет выпол-
няться в следующий раз. Например, учитывая возможности ядра, поток может
быть настроен на его запуск раз в секунду. Программист может быть совершенно
уверен, что выполнение потока будет спланировано именно таким образом.

	Стабильность. У потоков нет никакой возможности монополизировать использо-
вание ресурсов центрального процессора. А вошедший в бесконечный цикл поток
(попросту “зависший”) никак не повлияет на выполнение других потоков.

Конечно, рассмотренный метод планирования имеет и свои недостатки, которые
перечислены ниже.

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

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

Управление памятью

Операционная система также осуществляет управление оперативной памятью ком-
пьютера. Обычно память разделяется на различные части: одна часть используется для
размещения кода (инструкций, выполняемых центральным процессором), другая — для
программных данных. Свободная область памяти, из которой система может динамиче-
ски выделять области для последующего использования, получила название кучи (heap).

Некоторые операционные системы позволяют процессам адресовать большее про-
странство памяти, нежели физически установлено в компьютере, — это так называе-
мая виртуальная память (virtual memory). Механизм виртуальной памяти позволяет
расширить область доступной памяти за счет использования дополнительного носите-
ля, такого как жесткий диск. Использование виртуальной памяти базируется на аппа-
ратной особенности некоторых процессоров, внутри которых содержится так назы-
ваемый блок управления памятью (memory map unit — MMU). Механизм MMU авто-
матически переадресует запросы или к оперативной памяти (random access memory —
RAM), или к дополнительному носителю (жесткий диск), в зависимости от того, где в
действительности находятся запрашиваемые данные. Использование механизма MMU
также позволяет защищать фрагменты памяти, помечая их атрибутом “только для
чтения” или вообще исключая из операций с картой памяти3.

Виртуальная память обладает также и другими преимуществами: механизм MMU
может быть запрограммирован таким образом, чтобы отделять области памяти раз-

2 На самом деле все эти сложности целиком возлагаются на операционную систему. Использование
механизмов виртуальной памяти и страничной адресации позволяет полностью исключить возмож-
ность "порчи " данных одного процесса другим. — Прим, перев.

3 Фрагменты памяти, используемые наиболее часто, обычно помещаются в оперативной памяти.
Редко используемые данные при этом выгружаются на диск. Если приложение обращается к участ-
ку памяти, который в данный момент выгружен на диск, система считывает его в оперативную
память и лишь после этого предоставляет приложению доступ к данным. Для некоторых участков
памяти можно запретить проводить такие операции. В этом случае система не будет переме-
щать указанный фрагмент или выгружать его на диск. — Прим, перев.
личных процессов друг от друга. Таким образом, предотвращается доступ к памяти
одного процесса со стороны других.

Наделенная всеми своими достоинствами, виртуальная память не дается системе
“даром”. Платить приходится производительностью. Именно по этой причине систе-
ма 1OS не использует механизм виртуальной памяти в полной мере, как мы увидим в
дальнейшем.

Прерывания

Операционные системы обычно осуществляют обработку прерываний централь-
ного процессора. Прерывание — это аппаратное событие, по которому выполнение
текущего набора инструкций приостанавливается, а управление передается специаль-
ной программе. Эта специальная программа — обработчик прерывания (interrupt han-
dler) — выполняет необходимые действия, связанные с природой прерывания, и воз-
вращает процессор к выполнению приостановленного набора инструкций. Зачастую
прерывания генерируются внешними устройствами-контроллерами, требующими
внимания со стороны системы. Однако и сам центральный процессор может генери-
ровать прерывания. Операционная система, поддерживающая обработку прерываний,
содержит различного рода обработчики для всех видов возможных прерываний.

Структура операционной системы IOS

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

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

По сравнению с другими операционными системами, структура системы IOS
очень проста. Как и большинство маленьких встраиваемых операционных систем, IOS
была спроектирована таким образом, чтобы занимать как можно меньшее пространст-
во памяти и функционировать максимально быстро. Первоначально маршрутизаторы
были оснащены небольшим объемом памяти для хранения программного обеспечения
и данных (таких как таблицы маршрутизации). Чтобы достигнуть очень маленьких
размеров выполняемого образа операционной системы, IOS была оснащена лишь са-
мыми необходимыми функциями.

Необходимая производительность операционной системы также сыграла решающую
роль в проектировке структуры IOS. Значительные усилия были потрачены на создание
системы, позволяющей маршрутизатору перенаправлять сетевые пакеты с максимальной
скоростью. Это потребовало уменьшения расходов процессорного времени на служебные
нужды операционной системы, что позволило максимально эффективно использовать ре-
сурсы процессора для маршрутизации сетевых пакетов. Различные меры защиты, такие
как механизм защиты внутрипотоковой памяти, присутствующие в других операционных
системах, исключены из системы IOS с целью снижения затрат процессорных ресурсов на
обслуживание нужд системы. В целом идея IOS состоит в том, чтобы достичь максималь-
ной скорости работы, пусть и ценой снижения эффективности защиты системы от сбоев.

На рис. 1.1 показан наиболее общий вид структуры операционной системы IOS.

Процессы

Пакетные
буферы

Драйверы устройств

Аппаратное обеспечение

Рис. 1.1. Структура операционной системы IOS

На рис. 1.1 приведены основные элементы системы, которые перечислены ниже.

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

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

	Буферы пакетов. Обычно это буферы памяти, используемые для хранения мар-
шрутизируемых сетевых пакетов.

	Драйверы устройств. Драйверы управляют аппаратной частью сетевых интерфей-
сов и периферийными устройствами (такими как флэш-карты). Драйвер выступа-
ет в роли посредника между ядром системы IOS со всеми процессами и аппарат-
ной частью маршрутизатора. Драйверы также напрямую взаимодействуют с про-
граммным обеспечением быстрого переключения пакетов.

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

Все описанные элементы операционной системы IOS мы рассмотрим в последую-
щих разделах. Программное обеспечение механизма быстрого переключения пакетов
будет рассмотрено в главе 2, “Принципы коммутации пакетов”. Прежде чем мы зай-
мемся детальным обсуждением вышеуказанных архитектурных компонентов, рассмот-
рим, как организована память системы IOS.

Организация памяти

Операционная система IOS проецирует всю имеющуюся физическую память в одну не-
прерывную область виртуального адресного пространства. Как мы уже отмечали выше, в сис-
теме IOS не реализован полноценный механизм виртуальной памяти. Для снижения вычис-
лительных затрат на обслуживание системы и процессов ядро IOS не поддерживает ни стра-
ничную адресацию памяти, ни подкачку отдельных областей памяти. Таким образом, все
адресное пространство системы IOS ограничено объемом доступной физической памяти.
Всю память операционная система IOS разделяет на отдельные области (regions), кото-
рые обычно соответствуют различным типам физической памяти. Например, статическая
память (Static Random Access Memory — SRAM) может использоваться для хранения паке-
тов, а динамическая (Dynamic Random Access Memory — DRAM) — для хранения про-
граммного обеспечения и данных маршрутизатора определенного типа. Разделение памяти
по областям позволяет системе 1OS объединять различные типы памяти, а программы да-
же не знают особенностей памяти на конкретной аппаратной платформе.

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

I Таблица 1.1. Разновидности областей памяти

Область памяти	Описание
Локальная (Local)	Структуры данных периода времени выполнения и локальная ку- ча. Обычно DRAM-память
Память ввода-вывода (lomem)	Общая область памяти, доступная как центральному процессору, так и контроллерам сетевых устройств через шину данных. Чаще всего это SRAM-память
Быстрая память (Fast)	Быстрая память (такая как SRAM) используется для критичных по скорости задач и специальных целей
Код IOS (IText)	Выполняемый код системы IOS
Инициализированные данные IOS ((Data)	В данной области хранятся инициализированные переменные
Неинициализированные данные (IBss)	Здесь хранятся неинициализированные переменные
Шинная память (PCI)	Память шины PCI. Данная область памяти доступна для всех уст- ройств на шине
Флэш-память (Flash)	Данная область памяти используется для хранения выполняемых об- разов системы IOS (запускающихся из оперативной памяти или на- прямую из флэш-памяти). Также область памяти такого типа исполь- зуется для хранения конфигурационных данных маршрутизатора. Обычно файловая система также размещается во флэш-памяти

Области памяти могут быть вложенными в отношении “родительская область—
дочерняя область”. В принципе, ограничений на глубину подобного рода вложений
нет, однако реально используется лишь один уровень. Вложенные области формируют
подобласти (subregions) родительских областей. На рис. 1.2 проиллюстрирована воз-
можная в системе 1OS конфигурация памяти с областями и подобластями.

Для того чтобы узнать, какие области памяти присутствуют в данной системе, ис-
пользуется команда show region. В примере 1.1 продемонстрирован результат выпол-
нения этой команды для маршрутизатора Cisco 7206.
Физическая	Области

память	памяти

DRAM		Локальная область
SRAM		Область быстрой памяти

Рис. 1.2. Области памяти

Подобласти
памяти

j Пример 1.1. Результат выполнения команды show region	_ _J

router#show region
Region Manager:

Start	End	Size(b)	Class	Media	Name
0х1А000000	OxOlFFFFFF	6291456	lomem	R/W	iomem
0х31А00000	0x31FFFFFF	6291456	lomem	R/W	iomem:(iomem_cwt)
0х4В000000	0x4B0FFFFF	1048576	PCI	R/W	pcimem
0x60000000	0x619FFFFF	27262976	Local	R/W	main
0x600088F8	0x61073609	17214738	IText	R/O	main:text
0x61074000	0x611000FF	573696	IData	R/W	main:data
0x61100100	0x6128153F	1578048	IBss	R/W	main:bss
0x61281540	0X619FFFFF	7858880	Local	R/W	main:heap
0х7В000000	0x7B0FFFFF	1048576	PCI	R/W	pcimem:(pcimem_cwt)
0x80000000	0x819FFFFF	27262976	Local	R/W	main:(main_k0)
0XA0000000	0XA19FFFFF	27262976	Local	R/W	main:(main kl)

Колонки Start и End выведенной таблицы указывают на начальные и конечные ад-
реса областей памяти в общем пространстве виртуальной памяти системы. Справа
указаны соответствующие области и подобласти. Имена подобластей не выделены
скобками и отделены двоеточием от соответствующих имен областей. На рис. 1.3 изо-
бражены соответствующие области памяти с подобластями.

Между различными областями памяти преднамеренно оставлены пропуски в про-
странстве адресов (например, область pcimem оканчивается на адресе 0x4B0FFFFF, а
область main начинается с адреса 0x60000000). Эти свободные области могут исполь-
зоваться для расширения и предоставляют некоторого рода защиту от выполнения по-
токов с ошибками. Если вышедший из под контроля поток начнет записывать мусор в
различные участки памяти, то такой поток немедленно будет остановлен при попытке
записать что-либо в свободную область.

Из примера 1.1 и рис. 1.3 мы видим, что вся область DRAM-памяти, начиная с адре-
са 0x60000000 и заканчивая адресом 0x619FFFFF, рассматривается как локальная область
(local) и разделяется на несколько подобластей. Такие подобласти соответствуют различ-
ным частям образа системы IOS (текст, BSS и данные), а также куче. Кучей обозначает-
ся вся свободная локальная память после того, как в нее был загружен образ системы.
Карта
виртуальной
памяти

Области

Подобласти

0X619FFFFF

0x60000000

0X4B0FFFFF

0Х4В000000
OxOtFFFFFF

0х01А00000

DRAM

PCI
SRAM

DRAM

Куча

Основная
память

pcimem

iomem

Основная: bss,
Основная: data,
Основная: text

Рис. 1.3. Карта памяти и области памяти

Названия некоторых областей повторяются в различных адресах памяти, как, на-
пример, для области iomem:(iomem_cwt):

Start	End	Size(b)

OxOlAOOOOO	OxOlFFFFFF	6291456

0X31A00000	0x31FFFFFF	6291456

Class	Media	Name

lomem	R/W	iomem

lomem	R/W	iomem:(iomem_cwt)

Такие повторяющиеся регионы называются алиасами (aliases). В некоторых плат-
формах Cisco используется несколько диапазонов адресов для указания одной и той
же области памяти. Алиасы используются для обеспечения альтернативного метода
доступа к данным в памяти. Например, один диапазон адресов может использоваться
для кэшированного доступа к региону памяти, в то время как другой диапазон адре-
сов обеспечивает некэшируемый доступ к тому же самому участку памяти.

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

Пулы памяти

Управление памятью в системе IOS осуществляется посредством так называемых
пулов памяти (memory pools). Каждый пул представляет собой блок памяти, который
может быть выделен из кучи или освобожден от использования. Пулы составляются
из областей памяти, а управление ими осуществляется ядром системы. Очень часто
пул памяти в точности соответствует области памяти, однако один пул может покры-
вать и несколько участков памяти. Таким образом, память может выделяться для ис-
пользования сразу из нескольких областей, что оказывается весьма эффективным.

Информация о пулах памяти может быть получена с помощью команды show memory.
Пример 1.2. Результат выполнения команды show memory

router#show memory

	Head	Total(b)	Used(b)	Free(b)	Lowest(b)	Largest(b)
Processor	61281540	7858880	3314128	4544752	4377808	4485428
I/O	1А00000	6291456	1326936	4964520	4951276	4964476
PCI	4B000000	1048576	407320	641256	641256	641212

Внимание!

На самом деле команда show memory выводит очень много различной информации. По-
этому не следует использовать эту команду при отключенном страничном выводе ин-
формации на консоль (размер буфера терминала установлен в значение, равное 0), по-
скольку невозможно остановить вывод до полного его завершения.

Из примера 1.2 видно, что в системе выделены три пула памяти: Processor, I/O и
PCI. Сравнивая значения колонки Head (адрес пула) с соответствующими значениями
из колонки Start (начальный адрес) команды show region (пример 1.3), можно опреде-
лить, какие области покрывает каждый пул памяти.

J Пример 1.3. Информация, выводимая командой ehow region	j

router#show region

Region Manager:

Start	End	Size(b)	Class	Media	Name
OxOlAOOOOO	OxOlFFFFFF	6291456	lomem	R/W	iomem
0x31A00000	0X31FFFFFF	6291456	lomem	R/W	iomem:(iomem_cwt)
0x4B000000	0X4B0FFFFF	1048576	PCI	R/W	pcimem
0x60000000	0x619FFFFF	27262976	Local	R/W	main
0x600088F8	0x61073609	17214738	Itext	R/O	main:text
0x61074000	0x611000FF	573696	Idata	R/W	main:data
0x61100100	0x6128153F	1578048	Ibss	R/W	main:bss
0X61281540	0x619FFFFF	7858880	Local	R/W	main:heap

Из примера 1.3 видно, что пул памяти процессора (Processor memory pool) включает
подобласть под названием куча (heap) из основной области (mam region), который, в свою
очередь, принадлежит к локальному классу (class Local). Пул памяти процессора присут-
ствует во всех IOS-системах и всегда размещается в локальной памяти. Для размещения
различных данных (таких как таблицы маршрутизации) из процессорного пула памяти
выделяется необходимая часть. Аналогичным образом пул ввода-вывода (I/O pool) отве-
чает за память региона iomem, а пул шины PCI — соответственно за регион pcimem.

В выводе команды show memory присутствует еще несколько колонок, которые
отображают различную информацию о пулах. Ниже приведено краткое описание этих
значений (все показатели измеряются в байтах).

	Total (всего) — размер пула памяти.

	Used (использовано) — показывает объем памяти, выделенной из данного пула.

	Free (доступно) — доступный объем памяти.

	Lowest (наименьший объем) — наименьший объем памяти, когда-либо доступ-
ный со времени создания данного пула.

	Largest (наибольший объем) — размер наибольшего непрерывного блока памяти,
доступного для выделения в данный момент.
Как мы увидим далее, команда show memory может отображать выделенные блоки
памяти внутри каждого пула.

Процессы в системе IOS

Процессы операционной системы IOS эквивалентны потокам в других операционных
системах, поскольку в 1OS процессы состоят лишь из одного потока. Каждый процесс на-
делен собственным стеком, контекстом центрального процессора и может распоряжаться
ресурсами памяти и консольными устройствами, о которых мы поговорим позднее. Чтобы
снизить затраты на обслуживание, система 1OS не реализует механизм зашиты областей
памяти отдельных процессов. Также не осуществляется управление памятью во время пе-
реключения контекстов. Все это означает, что хотя каждому процессу и выделена своя об-
ласть памяти, ничто не мешает ему вторгаться в память другого процесса.

Как мы уже отмечали раньше, операционная система 1OS использует модель при-
оритетного выполнения до полного завершения для планирования своих процессов.
Может показаться, что использование планирования без приоритетных прерываний —
не лучшее решение для системы, которая должна оперативно обслуживать входящие
сетевые пакеты. В некоторых случаях так оно и есть: потребность в оперативности
выходит за ограничения механизма планирования процессов в системе 1OS. В главе 2,
“Принципы коммутации пакетов”, мы расскажем, как была решена рассмотренная
проблема. Все же механизм планирования задач операционной системы IOS имеет
массу несомненных преимуществ, что позволяет использовать его для обслуживания
процессов, не претендующих на сверхоперативность переключения пакетов. Перечис-
лим некоторые положительные стороны данного подхода.

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

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

Цикл жизни процесса

Процессы могут “рождаться и умирать” в любой момент работы системы IOS, исклю-
чая время обработки прерывания. Процесс может создаваться или “умерщвляться” ядром
системы (во время инициализации IOS) или любым другим выполняющимся процессом.

Внимание!

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

4 Если два процесса выполняются параллельно и пытаются изменить один и тот же ресурс (например,
переменную памяти), то результат оказывается непредсказуемым. Для обеспечения однозначности
процесс можно прервать лишь в момент, когда он не использует этот общий ресурс. Операционные
системы с приоритетным прерыванием следят за этим сами, используя так называемые семафоры. В
1OS же за возможный момент переключения процессов ответствен программист. — Прим, псрев.
В частности, за возникновением большинства процессов операционной системы 1OS
ответствен процесс синтаксического анализатора (parser). Синтаксический анализатор
представляет собой набор функций, которые интерпретируют конфигурационные файлы
системы IOS и исполняемые команды (ЕХЕС). Синтаксический анализатор вызывается
ядром системы во время инициализации и процессом ЕХЕС, который предоставляет ин-
терфейс командной строки (command line interface — CLI) для консоли или сессии Telnet.

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

Некоторые команды требуют, чтобы синтаксический анализатор породил новый
процесс. К примеру, получив через интерфейс командной строки конфигурационную
команду router eigrp, анализатор создает новый процесс, именуемый ipigrp (если, ко-
нечно, такой процесс еше не запушен в системе), который занимается обслуживанием
IP-пакетов протокола EIGRP. Если же введена команда no router eigrp, анализатор
прекращает работу процесса ipigrp и соответственно пакеты IP EIGRP больше не об-
рабатываются маршрутизатором.

Жизнь процессов в системе IOS состоит из нескольких фаз. На рис. 1.4 изображе-
ны эти фазы и соответствующие им состояния процессов.

Рис. 1.4. Цикл жизни процесса

Трансформация

Фаза рождения

Когда новый процесс рождается, он получает в распоряжение собственный стек и
переходит в состояние “новый” (new). После этого процесс может перейти в фазу
трансформации. Если же нужды в трансформации нет, то процесс напрямую следует в
фазу своего выполнения.
Фаза трансформации

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

Фаза выполнения

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

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

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

Фаза уничтожения

Последняя фаза в жизненном цикле процесса — фаза уничтожения. Процесс входит
в эту фазу после завершения всех своих задач и прекращает работу (так называемое са-
мостоятельное завершение работы). Процесс также может быть “убит” и другим процес-
сом. Когда процесс завершил работу самостоятельно или под действием другого процес-
са, он переходит в состояние “мертвый” (dead). Завершившиеся процессы пребывают в
“мертвом” состоянии, пока ядро не освободит все занимаемые ими ресурсы. Ядро мо-
жет также сохранить информацию об использовании процессом стека. После того как
все ресурсы “мертвого” процесса освобождены, он полностью выгружается из системы.

Приоритеты процессов в системе IOS

Планируя выполнение своих процессов, операционная система 1OS использует по-
литику приоритетов. При рождении процесса ему назначается один из четырех при-
оритетов, в зависимости от целей данного процесса. Впоследствии приоритет процес-
са не изменяется. Приведем описание возможных приоритетов процессов операцион-
ной системы 1OS.

	Критический приоритет. Зарезервирован для системных процессов, распреде-
ляющих ресурсы.
	Высокий приоритет. Назначается процессам, обеспечивающим высокую опера-
тивность (как, например, процесс, получающий пакеты непосредственно от се-
тевого интерфейса).

	Средний приоритет. По умолчанию такой приоритет назначается большинству
процессов системы JOS.

	Низкий приоритет. Назначается процессам, которые выполняют фоновые зада-
чи, такие как информационные сообщения.

В зависимости от приоритетов механизм приоритетов дает различным процессам
различные привилегии на доступ к процессорным ресурсам. Однако следует помнить,
что операционная система IOS не реализует приоритетные прерывания. Таким обра-
зом, процесс с более высоким приоритетом не может прервать выполнение процесса с
более низким приоритетом. Вместо этого система IOS предоставляет процессам с вы-
соким приоритетом больше возможности захватить процессорные ресурсы.

Примеры процессов

Для того чтобы определить, какие процессы выполняются в системе, используется
команда show process. Результат исполнения команды включает также дополнитель-
ную информацию о каждом процессе (пример 1.4).

Пример 1.4. Результат работы команды show process	. ' /	4

router#show process

CPU	utilization for five seconds:			0%/0%; one	minute:	0%; five	minutes: 0%	
PID	QI у	PC	Runtime(ms)	Invoked	uSecs	Stacks	TTY	Process
1	M*	0	400	55	7272	10020/ 12000	0	Exec
2	Lst	6024E528	201172	33945	5926	5752/ 6000	0	Check heaps
3	Cwe	602355E0	0	1	0	5672/ 6000	0	Pool  Manager
4	Mst	6027E128	0	2	0	5632/6 000	0	Timers
5	Mwe	602F3E60	0	1	0	5656/ 6000	0	OIR Han- dler
6	Msi	602FA560	290744	1013776	286	5628/ 6000	0	EnvMon
7	Lwe	60302944	92	17588	5	5140/ 600	0	ARP In- put
8	Mwe	6031C188	0	1	0	5680/ 6000	0	RARP In- put
9	Mwe	60308FEC	15200	112763	134	10748/  12000	0	IP Input
10	Mwe	6033ADC4	420	202811	2	5384/  6000	0	TCP  Timer
11	Lwe	6033D1E0	0	1	0	11644/ 12000	0	TCP Pro- tocols
12	Mwe	60389D6C	10204	135198	75	5392/  6000	0	CDP Pro- tocol
13	Mwe	6035BF28	66839	1030665	64	11200/  12000	0	IP Back- ground
14	Lsi	60373950	0	16902	0	5748/  6000	0	IP Cache Ager
15	Cwe	6023DD60	0	1	0	5692/  6000	0	Critical Bkgnd
16	Mwe	6023DB80	0	13	0	4656/ 6000	0	Net Back- ground
17	Lwe	6027456C	0	11	0	11512/  12000	0	Logger
18	Msp	6026B0CC	100	1013812	0	5488/  6000	0	TTY Back- ground
19	Msp	6023D8F8	8	1013813	0	5768/  6000	0	Per-  Scond  Jobs
20	Msp	6023D854	405700	1013812	400	4680/  6000	0	Net Pe- riodic
21	Hwe	6023D9BC	5016	101411	49	5672/  6000	0	Net Input
22	Msp	6023D934	135232	16902	8000	5640/  6000	0	Per- minute  Jobs

Ниже описаны значения полей вывода команды show process.

 PID — идентификатор процесса (process identifier). Каждому процессу назначается
уникальный идентификатор, который позволяет различать процессы в системе.

 Qty — приоритет процесса и его состояние. Первый символ данного поля пока-
зывает приоритет процесса:

• К — приоритет не назначен, так как процесс был “убит”;

• D — нет приоритета, так как процесс разрушен;

• X — нет приоритета, так как процесс поврежден;

• С — критический приоритет;

• Н — высокий приоритет;

• М — средний приоритет;

• L — низкий приоритет.

Два последующих символа обозначают текущее состояние процесса.

• * * — в данный момент процесс выполняется центральным процессором.

• Е — процесс ожидает события.

• S — процесс приостановлен.

• rd — процесс готов к выполнению.

• we — процесс простаивает в ожидании события.

• sa — процесс простаивает, ожидая некоего абсолютного времени.

• si — процесс простаивает, ожидая истечения некоего интервала времени.

• sp — процесс простаивает, ожидая истечения временного интервала
(периодически).

• st — процесс простаивает, ожидая истечения временного интервала таймера.

• hg — процесс “подвешен”.

• хх — “мертвый” процесс.

 PC — значение процессорного регистра program counter (программный счетчик) на
момент последнего выполнения процесса. Данное значение представляет собой ад-
рес ячейки памяти, с которого будет продолжено выполнение соответствующего
процесса при его следующем доступе к центральному процессору. Нулевое значение
свидетельствует о том, что процесс в данное время выполняется процессором.

 Runtime (время выполнения) — суммарный период времени выполнения (в мил-
лисекундах) процесса центральным процессором.
	Invoked (активизация) — данное поле отображает значение счетчика активизации
данного процесса центральным процессором с момента его (процесса) создания.

	uSecs — среднее значение периода выполнения процесса при его активизации.

	Stacks — статистика использования пространства стека. Число справа от косой
черты означает общий размер стекового пространства, число слева — размер
свободной области.

	ТГУ — консольное устройство, связанное с данным процессом. Нулевое значе-
ние свидетельствует о том, что у процесса нет консоли либо что он связан с
главной системной консолью.

	Process — параметр имени процесса. Данное имя не уникально (несколько ко-
пий одного процесса может выполняться одновременно). Тем не менее иден-
тификаторы процессов всегда уникальны.

Если выполнить команду show process на различных системах IOS, можно заме-
тить, что некоторые процессы присутствуют в каждой системе. Большинство из этих
процессов выполняют сервисные функции или обслуживают другие процессы. В
табл. 1.2 приведен список таких процессов с описанием выполняемых ими задач.

Таблица 1.2. Общесистемные процессы и их функции

Процесс	Функция
ЕХЕС	Интерфейс командной строки (Command-line interface — CLI), консоли и подключенных напрямую терминальных асинхронных линий. Процесс ЕХЕС принимает ввод от пользователя и предоставляет интерфейс для интерпретатора команд (parser)
Pool manager	Управление буферными пулами (более детальная информация представ- лена в разделе “Управление пакетным буфером" данной главы)
Check heaps	Процесс периодически проверяет целостность выполняемого кода систе- мы IOS и структуры кучи
Per-minute jobs	Системный процесс, который выполняется кажцые 60 секунд, осуществляя фоновые сервисные задачи, например проверку целостности стеков процессов
Per-second jobs  Critical back- ground	Системный процесс, обслуживающий задачи, которые требуют ежесе- кундного выполнения  Процесс с критическим приоритетом, предоставляющий системно- необходимые функции, например выделение дополнительных элементов очереди системы IOS при необходимости
Net background	Отсылает пакеты жизнеобеспечения сетевых интерфейсов, дезактивирует интерфейсы и изменяет их состояния
Logger	Просматривает сообщения (отладочные, сообщения об ошибках и инфор- мационные сообщения), выстроенные в очередь сообщений другими про- цессами через ядро системы, и выводит их на консоль и (при необходимо- сти) на удаленный сервер
TTY back- ground	Отслеживает подключенные асинхронные терминальные линии и звпускает ЕХЕС при их активизации

Все описанные выше процессы (за исключением ЕХЕС) создаются ядром системы
во время инициализации и обычно существуют в операционной системе IOS вплоть
до ее остановки.
Ядро системы IOS

В терминах операционной системы ядро представляет собой “сердцевину” системы, ее
центральную часть, выполняющуюся в специальном защищенном режиме процессора и
управляющую системными ресурсами. Несмотря на то что ядро помогает управляться с
ресурсами системы, структура его отличается от ядер других операционных систем. Ядро
операционной системы 1OS не является отдельным модулем, а представляется довольно
широким набором компонентов и функций, связанных с остальными частями системы, и
выступает наравне с ними, а не как управляющий элемент. Для ядра не существует
“специального” режима выполнения. Все процессы, не исключая и ядра, выполняются на
процессорном уровне пользователя и имеют полный доступ к системным ресурсам.

Ядро операционной системы 1OS планирует выполнение процессов, управляет па-
мятью, предоставляет сервисные функции для захвата и обработки аппаратных пре-
рываний, поддерживает таймеры и отрабатывает программные исключения. Основные
функции ядра мы рассмотрим более детально в последующих разделах.

Планировщик

Все задачи, касающиеся планирования процессов, целиком и полностью возлагаются
на планировщик (scheduler). Планировщик системы IOS координирует работу всех процес-
сов в системе с помощью так называемых очередей процессов (process queue), каждая из ко-
торых соответствует определенному состоянию процесса. Очереди также хранят информа-
цию о контекстах процессов в соответствующих состояниях. Процессы переходят из од-
ного состояния в другое, тогда как планировщик перемещает их контексты из одной очереди
в другую. Итак, существует шесть очередей процессов, которые перечислены ниже.

	Очередь простоя содержит процессы, которые все еще активны, но находятся в
стадии ожидания события.

	Очередь “мертвых” процессов содержит процессы, выполнение которых было
завершено, однако прежде чем они будут полностью удалены из системы, за-
нимаемые ими ресурсы должны быть освобождены.

	Очередь готовых процессов содержит процессы, готовые для выполнения про-
цессором. Существует четыре очереди готовых процессов — по одной для каж-
дого возможного приоритета выполнения:

•	критический;

•	высокий;

•	средний;

•	низкий.

Когда выполняющийся процесс приостанавливается, управление ресурсами про-
цессора берет на себя планировщик. Используя специальный алгоритм, планировщик
выбирает из очередей готовых процессов один и предоставляет ему ресурсы процессо-
ра. Рассмотрим последовательность действий планировщика поэтапно.

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

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

Этап 3. После того как в очереди процессов с высоким приоритетом не осталось ни
одного процесса, планировщик проверяет очередь процессов со средним
приоритетом. Если процессов в данной очереди не оказывается, планиров-
щик переходит к этапу 4 и проверяет очередь низкоприоритетных процес-
сов. В противном случае планировщик извлекает из очереди процессы и
выполняет их. Во время выполнения процессов со средним приоритетом
планировщик проверяет очередь процессов с высоким приоритетом и вы-
полняет их все (перемежая с критичными процессами) перед тем, как пе-
рейти к выполнению очередного процесса со средним приоритетом. После
того как все процессы из очереди выполнились, планировщик пропускает
этап 4 и переходит к этапу 1. Планировщик пропускает очередь низкопри-
оритетных процессов максимум 15 раз, прежде чем перейти к этапу 4. Этот
порог позволяет предотвратить блокировку низкоприоритетных процессов.

Этап 4. После того как все процессы с высоким и средним приоритетами были вы-
полнены (или выполнение данного пункта было пропущено 15 раз), плани-
ровщик переходит к очереди низкоприоритетных процессов. Планировщик
извлекает из очереди процесс и выполняет его. Между выполнением низко-
приоритетных процессов планировщик выполняет процессы со средним при-
оритетом (перемежая их с высокоприоритетными и критичными процессами).

Этап 5. В завершение всего планировщик возвращается к выполнению этапа 1.

Алгоритм работы планировщика в чем-то схож с работой секундомера. В данной
аналогии секунды можно представить как критичные процессы, минуты — как про-
цессы с высоким приоритетом, часы — как процессы со средним приоритетом и
дни — как низкоприоритетные процессы. Каждый оборот секундной стрелки покры-
вает все секунды. Каждый оборот минутной стрелки покрывает все минуты, включая
it прошествие всех секунд для каждой минуты, и т.д.

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

Использование ресурсов центрального процессора

Хотя система IOS и не предоставляет никаких статистических данных о работе плани-
ровщика, существует способ узнать, как различные процессы разделяют ресурсы централь-
ного процессора. В предыдущих примерах мы рассматривали результат работы команды
show process, которая выводит общую информацию об активных процессах в системе. Мо-
дификация данной команды — show process epu — имеет довольно схожий результат рабо-
ты, однако внимание ее больше сосредоточено на использовании ресурсов центрального
процессора. Результат работы команды show process epu приведен в примере 1.5.
Пример 1.5. Результат работы команды show process cpu

Router#show process cpu

CPU utilization for five seconds: 90%/82%; one minute: 60%; five min-
utes: 40%

PID	Runti me (ms	Invoked	uSecs	5Sec	IMin	5Min	TTY	Process
1	1356	2991560	0	0.00%	0.00%	0.00%	0	BGP  Router
2	100804	7374	13670	0.00%	0.00%	0.00%	0	Check
3	0	1	0	0.00%	0.00%	0.00%	0	heaps  Pool Man-
4	0	2	0	0.00%	0.00%	0.00%	0	ager  Timers
5	6044	4	1511000	0.00%	0.00%	0.00%	0	OIR Han- dler
6	0	1	0	0.00%	0.00%	0.00%	0	I PC Zone
7	0	1	0	0.00%	0.00%	0.00%	0	Manager  I PC Realm
8	7700	36331	211	8.00%	0.00%	0.00%	0	Manager IP Input

Первая строка в выводе команды show process cpu показывает общую загрузку цен-
трального процессора, усредненную по трем различным интервалам времени: 5 се-
кунд, 1 минута и 5 минут. Пятисекундная статистика использования процессора пред-
ставлена двумя числами, разделенными косой чертой. Число слева представляет об-
щий процент использования ресурсов процессора (процент занятости). Число
справа — процент использования ресурсов процессора при обработке прерываний.
Одно- и пятиминутная статистика использования процессорного времени показывает
общий процент занятости процессора, значение которого экспоненциально уменьша-
ется для одно- и пятиминутной статистики соответственно.

После общей статистики использования процессора те же самые временные ин-
тервалы отображают загруженность каждого процесса в отдельности. Планировщик
автоматически просчитывает данные значения и сохраняет их в памяти на случай вы-
полнения команды show process cpu. Таким образом, выполняя команду show process
cpu дважды в течение пятисекундного интервала, мы не увидим обновленной стати-
стики использования центрального процессора.

С помощью команды show process cpu довольно просто определить наиболее актив-
ные в системе процессы и процент использования ими ресурсов центрального процес-
сора. В приведенном выше примере средняя загруженность процессора в течение пяти
секунд перед запуском команды составляла 90%. Средняя загруженность при обработке
прерываний — 82%. Оставшиеся 8% (90% — 82% = 8%) используются планировщиком.
В течение последних 60 секунд загруженность процессора составила 60%, а средняя за-
груженность в течение пяти минут — 40%. Из индивидуальной для каждого процесса
информации видно, что в течение последних пяти секунд 8?% процессорных ресурсов
было занято процессом ip_input. Нулевые значения показателей загруженности означа-
ют, что процесс не имел возможности выполняться в промежутке соответствующего ин-
тервала либо значение загруженности составляло меньше 0,01%.

Из приведенного выше примера видно, что довольно-таки большой процент про-
цессорных ресурсов приходится на обработку прерываний. Возникает вопрос: чем же
занимается операционная система IOS в течение 82% своего рабочего времени? К со-
жалению, система не предоставляет детальной информации об обработке процессором
прерываний, как это сделано для процессов; посему трудно привязать загруженность
процессора к конкретной задаче. Однако можно сделать предположение относительно
использования процессорных ресурсов. Как вы узнаете в главе 2, “Принципы комму-
тации пакетов”, при использовании механизма быстрой коммутации (fast switching)
пакетов львиная доля работы выполняется именно на уровне обработки прерываний.
Операционная система IOS также выполняет и другую работу, обрабатывая прерыва-
ния, однако большая часть времени все же тратится на коммутацию пакетов. Посему
высокое значение загруженности процессора обычно означает, что системе IOS при-
ходится заниматься коммутацией большого количества сетевых пакетов.

Незадействованное процессорное время (10% в нашем примере) носит название
времени холостого хода или простоя. “Время простоя”, однако, не совсем точное оп-
ределение, поскольку процессор на самом деле никогда не простаивает: в нем посто-
янно выполняются какие-то инструкции (машинные команды). В системе IOS время
простоя в действительности означает, что ресурсы процессора используются собст-
венно планировщиком (а это весьма важный процесс в системе). Очень важно, чтобы
у операционной системы IOS было достаточно времени холостого хода. При прибли-
жении загруженности процессора к 100% на нужды планировщика практически не ос-
тается ресурсов, что приводит к весьма серьезным последствиям. Поскольку плани-
ровщик отвечает за выполнение всех фоновых критичных процессов, нехватка про-
цессорных ресурсов может привести к отказу системы.

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

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

Сторожевой таймер

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

Каждый раз, когда планировщик предоставляет процессу возможность выполняться,
запускается сторожевой таймер для этого процесса. По истечении заданного промежутка
времени (по умолчанию 2 секунды), если процесс все еще выполняется, то управление пе-
редается обратно планировщику. После первого срабатывания сторожевого таймера пла-
нировщик выводит предупреждающее сообщение и продолжает выполнение процесса:
%SNMP-3-CPUHOG: Processing GetNext of ifEntry.17.6
%SYS-3-CPUHOG: Task ran for 2004 msec (49/46), Process = IP SNMP, PC =
6018EC2C

-Traceback= 6018EC34 60288548 6017E9C8 6017E9B4

Если сторожевой таймер срабатывает во второй раз, а процесс все еще не приоста-
навливается, планировщик насильно останавливает выполнение процесса.
Менеджер памяти

Менеджер памяти ядра несет ответственность на макроуровне за управление всей
доступной памятью операционной системы IOS, включая и память, содержащую соб-
ственно выполняемый код системы 1OS. Менеджер памяти в действительности не
единичный компонент и состоит из трех отдельных модулей, каждый из которых от-
вечает за свои задачи, которые перечислены ниже.

	Менеджер областей памяти — выделяет и поддерживает различные области па-
мяти для данной платформы.

	Менеджер пулов памяти — управляет созданием пулов памяти, выделением и
освобождением отдельных блоков внутри пулов.

	Менеджер фрагментов памяти — управляет специально выделенными блоками
памяти, содержащими несколько фрагментов фиксированного размера.

Менеджер областей памяти

Менеджер областей памяти отвечает за поддержание всех существующих областей.
Он предоставляет услуги другим частям операционной системы 1OS создавать отдель-
ные области и устанавливать их атрибуты. Менеджер областей также позволяет орга-
низовывать запросы для получения информации о доступных областях (например, для
определения общего объема доступной памяти).

Менеджер пулов памяти

Менеджер пулов памяти является весьма важным компонентом системы. Так же
как планировщик отвечает за предоставление процессам ресурсов центрального про-
цессора, менеджер пулов памяти предоставляет процессам возможность выделения
памяти. Для выделения памяти под собственные нужды процесс должен напрямую
или косвенно обратиться к менеджеру пулов памяти. Менеджер пулов отрабатывается
каждый раз, когда процесс вызывает стандартные системные вызовы malloc или free
для выделения и освобождения памяти соответственно.

Вся работа менеджера пулов памяти опирается на использование списка свобод-
ных блоков памяти внутри каждого пула. Очевидно, что изначально каждый пул со-
держит по одному большому блоку свободной памяти, размер которого равен размеру
пула. В процессе обработки запросов к памяти начальный свободный блок памяти
становится все меньше и меньше. В то же время процессы могут освобождать занятые
блоки памяти. Таким образом, в ходе работы системы образуется несколько блоков
свободной памяти, отличающихся по своим размерам (рис. 1.5). Данное явление но-
сит название фрагментация памяти (memory fragmentation).

После того как освобожденный блок памяти будет возвращен в пул, менеджер до-
бавляет размер и начальный адрес данного блока в один из списков сходных по раз-
мерам свободных блоков. По умолчанию менеджер пулов поддерживает списки для
следующих размеров блоков: 24, 84, 144, 204, 264, 324, 384, 444, 1500, 2000, 3000, 5000,
10000, 20000, 32768, 65536, 131072 и 262144 байт. Следует отметить, что данные разме-
ры никоим образом не связаны с системными буферами, о которых речь пойдет ниже.
Изначально
свободный
блок

Свободная
память
...Вь^еленнадЗ

..’память#-^

Свободная
память

<Вьщеленнад]й
W^naMBTb-'Wi

Свободная
память

Начальный
блок памяти

Рис. 1.5. Выделение пулов памяти

Память после использования
(выделение и освобождение памяти)

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

Менеджер пулов памяти пытается контролировать фрагментацию памяти путем объ-
единения рядом расположенных свободных блоков. Когда блок памяти освобождается,
менеджер просматривает память на предмет наличия за освобожденным блоком свобод-
ной области. Если такая область найдена, то блоки объединяются в один с последую-
щим размещением его в соответствующий список свободных блоков памяти (рис. 1.6).

Свободная
память

i Выделенная
'память

Свободная
память

Только что
освобожденная
память

. Выделенная

- память

Свободная
память

Выделенная-
j память :

Свободная
память

Освобождение
блока памяти

Рис. 1.6. Объединение свободных блоков

Выделенная -

:; память

Память после объединения
освобожденных блоков
Выше мы рассматривали результат работы команды show memory, выводящей име-
на и различную информацию о пулах памяти, а также детальную информацию о каж-
дом блоке памяти внутри пулов. Вывод команды show memory содержит список всех
блоков памяти, включенных в соответствующие пулы (пример 1.6.)

j Пример 1.6. Детальная информация о пулах памяти	:]

router#show memory

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Processor	61281540	7858880	3314128	4544752	4377808	4485428

I/O	1A00000	6291456	1326936	4964520	4951276	4964476

PCI	4B000000	148576	407320	641256	641256	641212

Processor memory

Address	Bytes	Prev.	Next	Ref.	PrevF	NextF	Alloc PC	What
61281540	1460	0	61281B20	1			6035CCB0	List  Elements
61281В20	2960	61281540	612826DC	1			6035CCDC	List  Headers
612826DC	9000	61281B20	61284A30	1			60367224	Interrup t Stack
61284А30	44	612826DC	61284A88	1			60C8BEEC	*Init*
61284А88	9000	61284А30	61286DDC	1			60367224	Interrupt  Stack
61286DDC	44	61284А88	61286E34	1			60C8BEEC	*Init*
61286Е34	9000	61286DDC	61289188	1			60367224	Interrupt  Stack
61289188	44	61286Е34	612891E0	1			60C8BEEC	*Init*
612891Е0	4016	61289188	6128A1BC	1			602F82CC	TTY data
6128A1BC	2000	612891Е0	6128A9BB	1			602FB7B4	TTY In- put Buf
6128A9B8	512	6128A1BC	6128ABE4	1			602FB7E8	TTY Out- put Buf

Ниже приведено описание полей из примера 1.6.

	Address — поле начального адреса блока.

	Bytes — размер блока.

	Prev — адрес предшествующего блока.

	Next — адрес следующего блока.

	Ref — число владельцев данного блока.

	PrevF — адрес предыдущего блока в списке свободных блоков (только для сво-
бодных блоков).

	NextF — адрес следующего блока в списке свободных блоков (только для сво-
бодных блоков).

	Alloc PC — значение регистра счетчика команд на момент выделения данного блока.
Это значение позволяет определить, какой процесс выделил данный блок памяти.

	What — описание использования блока.

Можно использовать модификацию команды show memory free для отображения
свободных блоков в каждом пуле памяти (пример 1.7). Вывод команды содержит пе-
речень свободных блоков в порядке списков свободных блоков. Пустые списки сво-
бодных блоков отображаются без последующей информации о блоках памяти.
• Пример 1.7. Результат выполнения команды show memory free

Router# show memory free

Processor memory

Address	Bytes 24	Prev.  Free	Next list 1	Ref	PrevF	NextF	Alloc PC	What
6153Е628	52	6153E5F0	6153E688	0	0	615A644	603075D8	Exec
615А6444	44	615A63F8	615A649C	0	6153E62	0	603567F0	(fragm ent)
	92	Free	list 2				z	
	112	Free	list 2					-<
	116	Free	list 3					 ; , ''j't'IP
	128	Free	list 4					
61552788	128	6155273C	61552834	0	0	0	603075D8	(coale seed)
	132	Free	list 6					
	152	Free	list 7					
	160	Free	list 8					
	208	Free	list 9					
	224	Free	list 10					
	228	Free	list 11					
6153Е460	240	6153E428	6153E57C	0	0	0	6047A960	CDP Pro- tocol'
	240	Free	list 12					
	272	Free	list 13					
	288	Free	list 14					
	364	Free	list 15					
	432	Free	list 16					
	488	Free	list 17					
	500	Free	list 18					
6153E6D4	544	6153E69C	6153E920	0	0	0	60362350	(coale seed)
	1500	Free	list 19					
	2000	Free	list 20					
61552В84	2316	61552954	615534BC	0	0	0	603075D8	(coale seed)
	3000	Free	list 21					
6153ЕА14	4960	6153E9D4	6153FDA0	0	0	0	60308BC	(coale seed)
	5000	Free	list 22					
	10000	Free	list 23					
61572824	15456	6157106C	615764B0	0	0	0	603080BC	(coale seed)
	20000	Free	list 24					
	32768	Free	list 25					
6159ВА64	35876	61598B6C	615A46B4	0	0	0	60371508	(coale seed)
	65536	Free	list 26					
	131072	Free	list 27					
	262144	Free	list 28					
Total: >	59616							

Менеджер фрагментов

Менеджер пулов предоставляет довольно эффективный способ организации блоков
памяти разного размера. Однако это не дается даром: для каждого такого блока памяти
приходится использовать 32 байта служебной информации. Конечно, для пулов с неболь-
шим количеством блоков большого размера на служебную информацию тратится весьма
малый объем памяти. Однако для пулов, содержащих несколько тысяч маленьких блоков,
такая расточительность менеджера пулов становится неоправданной. Как вариант решения
возникшей проблемы, ядро предоставляет так называемый менеджер фрагментов (chunk
manager), который обслуживает большие пулы с большим количеством маленьких блоков.
При этом память не расходуется на служебную информацию для каждого блока.

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

В общем случае механизм работы с памятью выглядит следующим образом: процесс
запрашивает выделение большого блока памяти из определенного пула. Затем процесс об-
ращается к менеджеру фрагментов для разделения этого блока на несколько фрагментов
фиксированного размера и последующего выделения отдельных фрагментов. Преимущест-
во такого подхода состоит в том, что служебная информация (32 байта) связана с большим
блоком памяти, а менеджеру пулов не приходится выделять множество маленьких кусоч-
ков памяти. Таким образом, удается заметно снизить фрагментацию пула памяти.

Использование памяти процессами

Модификация команды show process — show process memory — позволяет получить
информацию об использовании памяти отдельными процессами. Данная команда по-
может быстро определить доступный объем памяти и объем памяти, занятой процес-
сами. Результат выполнения команды show process memory приведен в примере 1.8.

[ Пример 1.8. Результат выполнения команды show process memory I >
router#show process memory

Total: 7858880, Used: 3314424, Free: 4544456

PID	TTY	Allocated	Freed	Holding	Getbufs	Retbufs Process
0	0	86900	1808	2631752	0	0 *Init*
0	0	488	55928	448	0	0 *Sched*
0	0	7633024	2815568	6348	182648	0 ‘Dead*
1	0	268	268	3796	0	0 Load Meter
2	0	228	0	7024	0	0 CEF Scanner
3	0	0	0	6796	0	0 Check heaps
4	0	96	0	6892	0	0 Pool Manager
5	0	268	2 68	6796	0	0 Timers

65	0	0	14492	6796	0	13248 Per-minute Jobs
66	0	143740	3740	142508	0	0 CEF process
67	0	0	0	6796  3314184 Total	0	0 Xcpa-driver

Первая строка вывода команды в примере 1.8 отображает суммарный объем памяти в
пулах, объем свободной и занятой памяти. Данные из первой строки вывода соответствуют
статистике для процессорного пула памяти (processor memory pool) и совпадают с выводом
команды show memory. Далее вывод команды содержит детальную информацию об исполь-
зовании памяти каждым процессом, которая рассмотрена более подробно ниже.

	PID — идентификатор процесса.

	TTY — консоль, связанная с данным процессом.

	Allocated — общий объем памяти, выделенной процессу, с момента его создания.

	Freed — объем памяти, освобожденной процессом с момента его создания.

	Holding — объем памяти, который выделен процессу на текущий момент. Сле-
дует отметить, что, поскольку выделенная процессу память может быть освобо-
ждена другим процессом, значения величин allocated, freed и holding не находят-
ся в прямой зависимости, т.е. allocated минус freed не всегда равно holding.
	Getbufs — общий объем памяти для буферов пакетов, выделенных данному
процессу. Пулы пакетных буферов мы рассмотрим ниже, в разделе
“Управление пакетными буферами”.

	Retbufs — общий объем памяти для усеченных пакетных буферов данного про-
цесса.

	Process — имя процесса.

Следует обратить внимание на процессы, помеченные как *Init*, *Sched* и ‘Dead*.
На самом деле это вовсе не процессы, а информация, соответствующая им, которая
описывает выделенную память за пределами реальных процессов. Приведенные ниже
сведения подробно описывают данную информацию.

	*Init* — строка отображает объем выделенной для ядра системы памяти во вре-
мя инициализации, прежде чем создаются процессы.

	*Sched* — отображает память, выделенную планировщиком процессов.

	‘Dead* — память, выделенная процессами, перешедшими в “мертвую” фазу.
Память “мертвых” процессов впоследствии возвращается ядром в соответст-
вующие пулы.

Проблемы, связанные с выделением памяти

Во всех примерах, рассмотренных выше, мы предполагали, что запрос процесса на
выделение памяти всегда обслуживается и память процессу выделяется. Однако это не
всегда так. Ресурсы памяти, как и ресурсы центрального процессора, ограничены, по-
этому всегда есть вероятность нехватки требуемого объема памяти. Что же происходит
в случае отказа подобного рода? В зависимости от того, для чего необходима выде-
ляемая память, процесс может либо продолжать выполняться, либо остановиться и
прекратить работу. В любом случае при получении запроса, который менеджер пулов
не в состоянии обработать, он выводит предупреждающее сообщение на консоль:
%SYS-2-MALLOCFAIL: Memro allocation of 2129940 bytes failed from
0x6024C00C,

pool I/O, aligment 32

-Process= "OIR Handler", ipl= 4, pid= 7

-Traceback= 6024E738 6024FDA0 6024C014 602329C8 60232A40 6025A6C8
60CEA748

60CDD700 60CDF5F8 60CDF6E8 60CDCB40 60286F1C 602951

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

	нехватка свободной памяти;

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

Обычно отказы из-за нехватки памяти возникают тогда, когда физически не уста-
новлена память для поддержания всех возможностей системы. Существует два вариан-
та решения указанной проблемы: увеличение объема памяти маршрутизатора либо
уменьшение затрат ресурсов памяти (уменьшение количества интерфейсов и различ-
ных программных возможностей системы). В редких случаях ошибка нехватки памяти
может быть связана с утечкой памяти (memory leak) в одном из процессов. Это озна-
чает, что процесс постоянно пытается выделить память, однако никогда ее не освобо-
ждает, что обычно приводит к расходу всей доступной памяти. Обычно утечки памяти
связаны с ошибками в программном обеспечении.

Сбои выделения памяти могут также происходить при наличии требуемого объема
свободной памяти. Например, рассмотрим вывод команды show memory (пример 1.9.)
| Пример 1.9. Применение команды show memory

router#show memory

Head Total (b) Used(b)

Processor 61281540	785880	4898452

Free(b) Lowest (b) Largest(b)

2960428	10507	" '8426

В рассматриваемом нами примере в системе доступно 20960428 байт свободной па-
мяти. Однако, если попытаться выделить 9000 байт памяти, возникнет ошибка. Чтобы
понять, почему так происходит, достаточно взглянуть на значение в колонке Largest.
Поскольку на момент выполнения команды show memory максимальный непрерывный
блок памяти составляет 8426 байт, выделить 9000 байт нам никак не удастся.

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

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

Менеджер пакетного буфера

Маршрутизируя пакеты, система должна иметь некоторое пространство памяти для
временного хранения пакетов. Обычно для этого создаются буферы памяти, в которых
хранятся поступающие пакеты, пока система решает, куда их переправить. Поскольку вся
идея операционной системы IOS заключается в маршрутизации пакетов, для работы с бу-
фером пакетов существует специальный менеджер пакетного буфера (packet buffer manager).
Он используется системой для создания и последующего управления набором пулов буфе-
ра пакетов. Буферы в таких пулах памяти имеют общее название — системные буферы.

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

Пулы памяти для буферизации пакетов создаются путем выделения памяти из пула
(например, процессорного или пула ввода-вывода). Для того чтобы создать пул, ме-
неджер пакетного буфера требует у менеджера пулов выделить блок памяти и затем
разделяет его на буферы. Менеджер пакетного буфера создает список всех свободных
буферов для их последующего заполнения и освобождения.

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

Пулы пакетного буфера могут быть общими либо локальными. Общие пулы, как
следует из их названия, могут использоваться любым системным процессом. Локаль-
ные пулы используются лишь процессом, для которого пул был создан.
Системные буферы

В любой IOS-системе существует определенный набор общих буферных пулов —
системных буферов. Эти буферные пулы используются для коммутации приходящих
пакетов либо для хранения пакетов, генерируемых системой (например, тестрвые па-
кеты сетевых интерфейсов или пакеты обновления таблиц маршрутизации). Инфор-
мация, касающаяся системных и прочих буферов, может быть получена с помощью
команды show buffer (пример 1.10).

• Пример 1.10. Использование команды show buffer	r :	'	* i

......  ............ ............. ...... . ..................._ .. .₽ . '
routertfshow buffer

Buffer elements:

500 in free list (500 max allowed)

747314 hits, 0 misses, 0 created

Public buffer pools:

Small buffers, 104 bytes (total 50, permanent 50):

46 in free list (20 min, 150 max allowed)

530303 hits, 6 misses, 18 trims, 18 created

0 failures (0 no memory)

Middle buffers, 600 bytes (total 25, permanent 25):

25 in free list (10 min, 150 max allowed)

132918 hits, 3 misses, 9 trims, 9 created

0 failures (0 no memory)

Big buffers, 1524 bytes (total 50, permanent 50):

50 in free list (5 min, 150 max allowed)

.47 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

VeryBig buffers, 4520 bytes (total 10, permanent 10):

10 in free list (0 min, 100 max allowed)

26499 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Large buffers, 5024 bytes (total 0, permanent 0):

0 in free list (0 min, 10 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Huge buffers, 18024 bytes (total 0, permanent 0):

0 in free list (0 min, 4 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Указанные в примере общие буферы являются стандартными для любой системы
IOS. У каждого буфера есть имя (как, например, small buffer, или малый буфер, middle
buffer, или средний буфер, и т.д.), которое указывает на определенный пул. За названи-
ем пула следует размер буферов, содержащихся в данном пуле. В пределах одного пула
размер всех буферов одинаковый и варьируется от 104 до 18024 байт, чтобы приспосаб-
ливаться к передаваемым настройке параметра размера передаваемого блока (maximum
transmission unit — MTU), сопоставленных различным сетевым интерфейсам. Содержи-
мое прочих полей вывода содержит информацию, которая описана ниже.

	total — суммарное количество буферов в пуле (свободных и занятых).

	permanent — начальное (базовое) число буферов в пуле. Для динамических пу-
лов число буферов может меняться. Однако оно не может достигать меньшего
значения, чем указано в данной графе.
	min free list — число свободных буферов.

	min — минимальное число свободных буферов в пуле. Если количество свобод-
ных буферов становится меньше указанного значения, менеджер буферного пу-
ла пытается расширить пул с целью добавления дополнительных буферов.

	max allowed — максимальное число свободных буферов в пуле. Соответственно, ко-
гда число свободных буферов превышает указанное значение, менеджер уменьшает
количество свободных буферов и освобождает память. Независимо от значения max
allowed, количество буферов не может быть меньше значения permanent.

	hits — число буферов, которые были использованы в данном пуле.

	misses — число запросов на предмет выделения свободного буфера, в то время,
как число свободных буферов было меньше значения min.

	trims — число буферов, удаленных из пула в результате сокращения его размера.

	created — число буферов, созданных в процессе расширения пула.

	failures — количество отказов буферного пула. Отказы обусловлены следующи-
ми причинами:

•	запрос на выделение буфера получен во время отработки прерывания, когда
расширение пула невозможно;

•	получен запрос на выделение буфера, в то время как доступных буферов не
осталось, а объем свободной памяти не позволяет расширить пул.

 no memory — число отказов, связанных с отсутствием свободной памяти в пуле
(данный показатель не используется в более поздних версиях системы 1OS)

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

Small buffers, 104 bytes (total 16, permanent 16):

16 in free list (8 min, 16 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Рис. 1.7. Пустой буфер пакетов

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

Small buffers, 104 bytes (total 16, permanent 16):

8 in free list (8 min, 16 max allowed)

Рис. 1.8. Получение восьми пакетов с последующим размеще-
нием в буферы

Если система получает еще четыре пакета до того, как были обработаны предыду-
щие восемь, то количество свободных буферов сокращается до четырех (рис. 1.9):

Small buffers, 104 bytes (total 16, permanent 16):

4 in free list (8 min, 16 max allowed)

12 hits, 4 misses, 0 trims, 0 created

0 failures (0 no memory)

Итак, свободных буферов — четыре, использованных — двенадцать. Поскольку
минимальное значение свободных буферов составляет восемь (8 min), мы имеем че-
тыре “промаха” (4 misses). Это говорит менеджеру о необходимости расширить пул
буферов, чтобы число свободных буферов составляло минимально допустимое (т.е.
восемь в нашем примере). На рис. 1.10 показан процесс расширения пула буферов:

Small buffers, 104 bytes (total 20, permanent 16):

8 in free list (8 min, 16 max allowed)

12 hits, 4 misses, 0 trims, 4 created

0 failures (0 no memory)

Из примера видно, что менеджер создал четыре дополнительных буфера (4 created)
для того, чтобы число свободных буферов достигало минимально допустимое значе-
ние — 8 (8 min).

Теперь представим, что требуется выделить девять буферов для размещения паке-
тов, а уже использованные буферы по-прежнему не освобождены (данная ситуация
проиллюстрирована на рис. 1.11).
В списке4
— свободных
буфера

&&feigfe8S

Рис. 1.9. Получение дополнительных четырех пакетов



у



— Всего 16

		
		
		
		
		
		
		
		
		
		
		
		
		
		
		У>'
		

 ’ -

.?Г

W’
t

' -T

&£?• 4,A-

Рис. 1.10. Создание дополнительных буферов

В списке 8
— свободных
буферов

— Всего 20
Рис. 1.11. Попытка размещения девяти пакетов

Из вывода команды show buffers следует, что список свободных буферов оказался
полностью исчерпанным. В результате свободных буферов в пуле не осталось (0 in free
list), 20 буферов заполнено (20 hits), есть 13 промахов и один отказ (так как один па-
кет не удалось разместить в буфере).

Small buffers, 104 bytes (total 20, permanent 16):

0 if free list (8 min, 16 max allowed)

20 hits, 13 misses, 0 trims, 4 created

1 failure (0 no memory)

В итоге система обрабатывает поступившие пакеты и освобождает ранее занятые
буферы. Пусть система IOS обработала 17 пакетов из 20-ти, и в результате было осво-
бождено 17 буферов, как показано на рис. 1.12,

Small buffers, 104 bytes (total 20, permanent 16):

17 in free list (8 min, 16 max allowed)

20 hits, 13 misses, 0 trims, 4 created

1 failure (0 no memory)

Итак, рассматриваемый нами пул содержит теперь 17 свободных буферов. Однако,
как показывает значение max allowed, максимально возможное число свободных буфе-
ров составляет 16. Это говорит менеджеру о необходимости сократить размер свобод-
ной области до 16-ти буферов. В итоге один буфер высвобождается из пула (1 trims),
как показано на рис. 1.13.
Буфер урезан

Рис. 1.12. Освобождение 17 буферов

В списке 16 свободных буферов

Рис. 1.13. Сокращение числа свободных буферов
Small buffers, 104 bytes (total 20, permanent 16):

17 in free list (8 min, 16 max allowed)

20 hits, 13 misses, 1 trims, 4 created

1 failure (0 no memory)

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

Small buffers, 104 bytes (total 16, permanent 16):

16 in free list (8 min, 16 max allowed)

20 hits, 13 misses, 4 trims, 4 created

1 failure (0 no memory)

Драйверы устройств

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

Драйверы сетевых устройств операционной системы IOS предоставляют интерфейс
для работы с входящими и исходящими пакетами. Любой драйвер состоит из двух
компонентов: управляющей части и компонента, связанного с хранением и обработ-
кой данных. Управляющая часть драйвера служит для контроля за состоянием устрой-
ства (например, отключение интерфейса). Компонент данных отвечает за передачу
информации через устройство и поддерживает операции коммутации пакетов. Как мы
увидим в главе 2, “Принципы коммутации пакетов”, драйверы сетевых устройств
очень тесно связаны с механизмом коммутации пакетов.

Драйверы устройств взаимодействуют с другими частями системы IOS посредством
специальной управляющей структуры, называемой дескриптором интерфейса (interface
descriptor block — 1DB). Данная структура содержит список управляющих функций
драйвера и информацию о параметрах устройства и его состоянии (например, IP-
адрес, статистику прохождения сетевых пакетов). Операционная система IOS содер-
жит дескрипторы для каждого интерфейса.

Резюме

Процесс эволюции межсетевой операционной системы IOS начинался с маленькой
системы, превратившейся со временем в очень мощную сетевую систему. Основные
элементы 1OS не отличаются от элементов других операционных систем. Однако все
компоненты операционной системы IOS оптимизированы для эффективной работы в
условиях ограниченного объема памяти и необходимости быстрой коммутации пакетов.

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

Система 1OS содержит маленькое ядро, которое планирует выполнение процессов
процессором. В отличие от других операционных систем, ядро системы IOS выполня-
ется на пользовательском уровне (не используется механизм защищенного режима) и
разделяет одно и то же пространство адресов памяти со всеми процессами.
Драйверы устройств операционной системы IOS предоставляют логическую абст-
ракцию аппаратной части маршрутизатора от его программного обеспечения. Драйве-
ры сетевых устройств очень тесно связаны с работой механизма коммутации пакетов.
Более детально процесс коммутации пакетов мы рассмотрим в следующей главе.

Глава

2

Принципы коммутации
пакетов

'* I..	I.'

’*4** 3»».*А

Основное назначение многопротокольного маршрутизатора— коммутация пакетов
из одного сетевого сегмента в другой. В межсетевой операционной системе (Internetwork
operating .system—<IOS) основополагающими являются принципы коммутации пакетов,
¥ в то время как диспетчер памяти и планировщик — это часть инфраструктуры маршру-
j тизатора. Методы и схемы коммутации, используемые IOS, строго определяют, каким
« образом маршрутизатор выполняет свою основную задачу. Поэтому много усилий было
5; потрачено на разработку и улучшение этой важной части IOS.

Операция обработки данных сама по себе довольно проста и состоит из следую-
щих этапов. '£,.«/•’	% р V

 ' Этап 1. Пакет приходит в интерфейс.

	 Этап 2. Определяется адрес получателя пакета и сравнивается со списком из-

3 вестных получателей, '.д?

V  Этап 3. Если найдено совпадение . пакет пересылается в соответствующий интерфейс.

	Этап 4. Если совпадение с соответствующим списком не найдено, то пакет иг-
норируется.	......

Безусловно, ничего сложного в ртом нет, однако проблема состоит не в том, как
. коммутировать пакеты, а в том, так сделать это быстро. Коммутация пакетов — это
f процесс, который.требует обработки большого количества данных. В отличие от ре-
сурсоемких процессов, для его ускорения недостаточно просто использовать более
быстрый процессор. Скорость коммутации пакетов может сильно зависеть от других
параметров, например от производительности шины ввода-вывода и скорости доступа
к памяти. Задача разработчиков ..IOS состоит в том, чтобы обеспечить наибольшую
скорость коммутации пакетов при ограниченных ресурсах производительности про-
цессора, шины ввода-вывода и памяти.

В связи с постоянным увеличением размеров и количества маршрутизируемых сетей
’ разработчики системы IOS постоянно ищут новые возможности для повышения произ-
водительности коммутаторов. Результатом этих разработок является непрерывная мо-
дернизация и улучшение методов коммутации операционной системой. В первой версии
операционной системы 1OS использовался только один метод коммутации пакетов, ко-
торый называется программной коммутацией (process switching). В новых версиях появи-
лись более современные улучшенные методы коммутации, некоторые из них основаны
. на аппаратно-зависимой оптимизации, иные используют программные приемы, кото-
рые хорошо работают на многих других платформах. На сегодняшний день система IOS
может коммутировать до нескольких сотен тысяч пакетов в секунду с использованием
таблицы маршрутизации, содержащей сотни тысяч маршрутов.
Ниже перечислены все методы коммутации пакетов, включенные в операционную
систему Cisco IOS версии 12.0 (Cisco IOS Release 12.0).

	Программная коммутация.

	Быстрая коммутация (Fast switching).

	Автономная коммутация (Autonomous switching).

	Процесс коммутации корпорации Silicon (Silicon switching engine switching, SSE
switching).

	Оптимальная коммутация (Optimum switching).

	Распределенная быстрая коммутация (Distributed fast switching).

	Экспресс-пересылка корпорации Cisco (Cisco Express Forwarding, CEF).

	Распределенная экспресс-пересылка корпорации Cisco (Distributed Cisco Express
Forwarding, или dCEF).

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

Несмотря на то что для иллюстрации методов коммутации используются примеры,
основанные на маршрутизации протокола IP (Internet Protocol, протокол Internet),
большинство из них можно применить и к другим сетевым протоколам, таким как
протокол межсетевого пакетного обмена IPX (Internetwork Packet Exchange protocol) и
туннельный протокол (bridging). Хотя для разных протоколов используются различные
структуры данных (например, разделен кэш для протоколов IP и IPX при использова-
нии метода быстрой коммутации), но их содержание однотипно и коммутация проис-
ходит идентично для каждого протокола.

Программная коммутация

Программная коммутация — это первый метод коммутации, который использовался
в системе IOS. В своей основе для коммутации пакетов он использует метод последова-
тельного перебора (brute-force method)1. Метод программной коммутации наименее оп-
тимизирован и поэтому требует много процессорного времени. Однако преимуществом
этого метода является независимость от аппаратного обеспечения, что позволяет приме-
нять его во всех устройствах, работающих под управлением системы Cisco IOS. Кроме
того, программная коммутация позволяет использовать некоторые механизмы распреде-
ления нагрузки, которые недоступны большинству других методов. Подробнее этот во-
прос будет рассмотрен ниже, в разделе “Балансировка нагрузки каналов с использова-
нием программной коммутации”.

Чтобы лучше представить работу метода программной коммутации, рассмотрим
последовательность, необходимую для коммутации пакета. На рис. 2.1 показан путь
прохождения IP-пакета при использовании метода программной коммутации. *

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

В приведенном выше примере (см. рис. 2.1) процесс обработки пакета начинается
с сетевого интерфейса на маршрутизаторе, который считывает пакеты из среды пере-
дачи данных2, которые необходимо обработать. Аппаратная часть интерфейса получает
пакеты и пересылает их в буфер ввода-вывода (первый этап на рис. 2.1).

Сетевой интерфейс посылает прерывание основному процессору, сообщая ему о том,
что пришел пакет, находящийся в буфере ввода-вывода, который необходимо обрабо-
тать; этот процесс называется прерывание на получение. Обработчик прерываний IOS счи-
тывает информацию из заголовка пакета (тип инкапсуляции, заголовок сетевого уровня
и др.), определяет, что данный пакет является пакетом протокола 1Р, и помещает его в
очередь пришедших пакетов для соответствующего процесса коммутации (второй этап
на рис. 2.1). Для пакетов протокола 1Р рассмотренный процесс называется ipjnput.

Процесс ip_input начинает выполняться в том случае, когда хотя бы один пакет по-
падает во входящую очередь (третий этап на рис. 2.1).

По окончании работы процесса ip_input (четвертый этап на рис. 2.1) начинается опе-
рация пересылки пакета. На этом этапе проводятся все проверки и выбирается направ-
ление пересылки входящего пакета. В рассмотренном примере ip_input просматривает
таблицу маршрутизации на наличие маршрута к получателю IP-пакета. Если маршрут
найден, то по записи в таблице маршрутизации определяется адрес следующей точки
перехода (следующего маршрутизатора на пути к получателю пакета). Затем из таблицы
протокола ARP (Address Resolution Protocol) определяется информация, необходимая для
формирования нового заголовка MAC (Media Access Control)3, для пересылки пакета к
следующей точке перехода. Процесс ip_input формирует новый заголовок МАС и запи-
сывает его поверх старого во входящем пакете, после чего он помещается в очередь для
отправки через выходной сетевой интерфейс (этап пятый на рис. 2.1).

Когда аппаратная часть исходящего интерфейса определяет, что в очереди нахо-
дится пакет для отправки, она считывает его из буфера ввода-вывода и передает в сеть
(шестой этап на рис. 2.1). После того как аппаратная часть закончит передачу пакета,

2 Обычно это медный проводник или оптический кабель. — Прим, перев.

3 Заголовок второго уровня модели OS/. — Прим, перев.
интерфейс посылает прерывание основному процессору, сообщая, что пакет, уже от-
правлен. Операционная система IOS обновляет счетчик исходящих пакетов на интер-
фейсе и освобождает место в буфере ввода-вывода, занятое отправленным пакетом
(седьмой этап на рис. 2.1).

Балансировка нагрузки каналов с
использованием программной коммутации

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

Параметр метрики или удельный вес маршрута в таблице маршрутизации опреде-
ляется из счетчика балансировки нагрузки (load share counter) для определения пути
прохождения каждого пакета. Для того чтобы понять принципы работы балансировки,
рассмотрим рис. 2.2.

Пакеты 1,3,5,7,9...

/10.1.2.0/24

Пакеты 2,4,6,8,10...

10.1.4.0/24

Рис. 2.2. Балансировка нагрузки через маршруты с
одинаковым удельным весом

Маршрутизатор A (RouterA) имеет два пути к сети 10.1.4.0/24 (см. рис. 2.2). В при-
мере 2.1 показаны два эквивалентных пути для этого маршрутизатора.

^Пример 2.1. Таблица маршрутизации маршрутизатора А на рис. 2.2	  i . 1

RouterA# show ip route 10.1.4.0 255.255.255.0

Routing entry for 10.1.4.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:	• • •

10.1.2.1
Route metric is 0, traffic share count is 1

* 10.1.3.1
Route metric is 0, traffic share count is 1

Обратите внимание на звездочку (*) возле одного из сетевых маршрутов в приме-
ре 2.1, которая означает, что для коммутации следующего пакета в сеть 10.1.4.0/24 бу-
дет использоваться именно этот маршрут. Коэффициент балансировки нагрузки (traffic
share count) для обоих маршрутов равен единице. Это означает, что пакеты будут по
очереди отправляться то по одному, то по другому маршруту.
В приведенном примере первый полученный пакет будет отправлен через узел
10.1.3.1, 'а второй — через узел 10.1.2.1, третий снова через 10.1.3.1 и т.д. (на рис. 2.2
показаны номера пакетов, которые пройдут через каждый маршрут).

Некоторые протоколы маршрутизации семейства IP, как, например, протокол
маршрутизации внутренних граничных маршрутизаторов (Interior Gateway Routing
Protocol — IGRP) и расширенный протокол IGRP (Enhanced IGRP), могут назначать
разные метрики в таблице маршрутизации. В этом случае алгоритм балансировки на-
грузки будет иметь незначительные отличия. Если изменить конфигурацию сети на
рис. 2.2 таким образом, что один из путей будет иметь вдвое большую пропускную
способность, то получим сеть, которая показана на рис. 2.3.

Пакеты 1,2,4,5,7...

Рис. 2.3. Балансировка нагрузки через маршруты с
разным удельным весом

Обратите внимание на значение коэффициента балансировки нагрузки в результате
выполнения команды show ip route. Меньший удельный вес маршрута через устройство с
адресом 10.1.3.1 приводит к тому, что значение данного коэффициента равно 2; боль-
ший вес маршрута к устройству 10.1.2.1 дает значение коэффициента балансировки на-
грузки, равное 1. Теперь маршрут с большим значением указанного коэффициента будет
пропускать через себя два пакета в расчете на каждый пакет, который будет проходить
через путь с меньшим значением коэффициента балансировки нагрузки (рис. 2.3).

Внимание!

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

Недостатки программной коммутации

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

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

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

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

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

 Доступность. Доступен ли получатель? Если доступен, то каков IP-адрес следующей
точки перехода на пути к получателю пакета? Необходимая информация хранится в
таблице маршрутов (также называемой forwarding table — таблицей пересылки).

 Интерфейс. В какой интерфейс необходимо отправить пакет? Необходимые
данные также хранятся в таблице маршрутизации.

 МАС-заголовок. Какой заголовок МАС необходимо прописать в пакете для пра-
вильной адресации к следующей точке перехода? МАС-заголовок хранится в
ARP-таблице протокола IP или другой таблице соответствия МАС-адресов, как,
например, в карте маршрутов протокола Frame Relay (Frame Relay map table).

Поскольку любой входящий пакет может быть предназначен разным получателям,
процесс ip_input должен каждый раз заново находить информацию для коммутации па-
кета. Необходимую информацию приходится искать в потенциально большой таблице
маршрутизации, чтобы определить, доступен ли адресат, и найти выходной интерфейс
для пакета, а затем МАС-заголовок в другой, тоже, возможно, большой таблице. Возни-
кает вопрос, почему бы процессу ipjnput не “запоминать” результаты предыдущих по-
исков указанных таблиц? Если хранить в маленькой таблице информацию о комбина-
ции доступности, об интерфейсе и о МАС-адресе для наиболее часто используемых
маршрутов, то можно существенно уменьшить время поиска необходимой информации
для большинства входящих пакетов. Поскольку поиск необходимого соответствия явля-
ется наиболее продолжительной частью процесса коммутации пакетов, то использование
меньших таблиц для поиска может значительно повысить скорость коммутации и вся
операция будет выполнена в процессе обработки прерывания на получение пакета. В
этом случае отпадает необходимость в копировании пакета между буфером ввода-вывода
и памятью, что также уменьшает общее время операции. Итак, каким образом система
IOS позволяет организовать меньшие таблицы для поиска и добиться с их помощью
увеличения производительности? Ответ — быстрый кэш (Fast Cache).
Быстрая коммутация: кэширование
для экономии ресурсов

Термин кэш в компьютерных технологиях обычно означает хранение некоторого,
часто используемого подмножества в большом множестве данных в локальной области
хранения информации с очень быстрым доступом. Например, для повышения произво-
дительности компьютер может хранить в оперативной памяти копию данных с жесткого
диска, которые часто используются, или центральный процессор может с упреждением
записывать последовательность инструкций в очень быструю память для увеличения
производительности. Кэш можно охарактеризовать двумя основными параметрами: он
имеет относительно небольшой размер по сравнению с обшей областью данных и пре-
доставляет очень быстрый доступ к любым данным, которые он содержит.

Разработчики операционной системы IOS использовали описанные выше концеп-
ции при создании быстрого кэша. Быстрый кэш — это структура данных, используе-
мая в системе 1OS, для хранения копии комбинации доступности адресата, интерфей-
са и МАС-заголовка, найденных в процессе коммутации пакетов.

Для понимания механизма использования быстрого кэша рассмотрим пример
программной коммутации, приведенный выше. Добавим еше один этап к коммута-
ции, выполняемой процессом ipinput. После того как ipinput определит адрес сле-
дующей точки перехода, необходимый интерфейс и МАС-заголовок пакета, добавим
операцию сохранения найденной информации в специальной структуре данных, по-
зволяющей получить быстрый доступ к любой записи в кэше, основанной на IP-
адресе получателя пакета. Подобная структура называется быстрым кэшем. Через не-
которое время процесс ip input создаст достаточно большое количество записей в кэ-
ше часто используемых IP-адресов получателей пакетов. Теперь рассмотрим, как опи-
санный выше кэш используется в процессе коммутации пакетов. На рис. 2.4 показан
алгоритм механизма быстрой коммутации.

Процесс ipjnput^ ‘

Рис. 2.4. Алгоритм быстрой коммутации

По сравнению с программной коммутацией здесь присутствует еше один эле-
мент — быстрый кэш. Как и прежде, процесс коммутации начинается с аппаратной
части интерфейса, которая получает пакет из среды передачи данных. Подучав пакэ$,
она помешает его в буфер ввода-вывода — первый этап на рис. 2.4.	‘	'

На втором этапе аппаратная часть интерфейса посылает прерывание центральному
процессору, информируя его о том, что пришедший пакет находится в буфере ввода-
вывода. Обработчик прерываний операционной системы IOS проверяет заголовок па-
кета и убеждается, что это пакет протокола IP. Затем, вместо помещения пакета, как
это делалось раньше, в очередь для процесса ip_input, обработчик прерываний прове-
ряет быстрый кэш на наличие в нем записи адреса устройства-получателя. При нали-
чии записи в кэше обработчик прерываний считывает МАС-заголрво,к в таблиц?, и
помешает его в пакет. Из записи в кэше также определяется указатель для соответст-
вующего выходного интерфейса. Третий этап на рис. 2.4 демонстрирует чтение записи
из кэша и переписывание МАС-адреса пакета.

Затем центральный процессор (в течение времени обработки того же прерывания)
сообщает аппаратной части выходного интерфейса, что пакет, находящийся в буфере
ввода-вывода, готов для передачи, и заканчивает обработку прерывания, следователь-
но, другие процессы могут продолжать работу (четвертый этап на рис. 2.4).4

Аппаратная часть интерфейса выводит из очереди пакет, находящийся в буфере
ввода-вывода, и отправляет его в среду передачи данных (пятый этап на рис. 2.4). За-
тем посылается прерывание основному процессору для обновления счетчиков и осво-
бождения места в буфере ввода-вывода, занимаемого пакетом (это шестой этап).

Данный пример только иллюстрирует, как работает механизм быстрой коммута-
ции. Обратите внимание на то, что процесс ip_input не принимает участия в коммута-
ции пакета; фактически ни один отложенный процесс при работе метода быстрой
коммутации не влияет на сам процесс коммутации до тех пор, пока существует запись
в кэше. При использовании быстрого кэша система IOS выполняет всю последова-
тельность коммутации пакета в течение очень короткого периода одного прерывания!
Кэширование позволяет разделить ресурсоемкую операцию выбора маршрута с отно-
сительно легкой процедурой пересылки пакета. Итак, метод быстрой коммутации
вводит понятие “маршрутизировать однажды, пересылать — много раз”.

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

Метод использования механизма программной коммутации для заполнения быст-
рого кэша работает хорошо при определенных условиях: сеть должна быть стабильной
с небольшими изменениями в маршрутизации, поток данных в основном идет между
небольшим количеством получателей. Эти условия справедливы в большинстве случа-
ев. В некоторых ситуациях, как, например, для бекбона Internet5, они нарушаются. В
случае магистрального канала возрастает количество “промахов” кэша (ситуация, ко-
гда для пакета не найдена запись в кэше), и как результат — большее количество па-
кетов коммутируется методом программной коммутации. Также возможна ситуация,
приводящая к очистке кэша, когда старые записи в кэше переписываются новыми из-
за отсутствия свободного места в кэше для всех необходимых записей. Такие ситуации
мы рассмотрим ниже в данной главе.

4 При обработке прерывания все процессы в системе останавливаются до завершения работы обра-
ботчика прерываний. — Прим, перев.

5 Backbone дословно означает позвоночник Internet; совокупность быстрых каналов и обслуживаю-
щих их маршрутизаторов, объединяющих крупные узлы сети. — Прим, перев.
Структура быстрого кэша

Как же на самом деле работает быстрый кэш? Каким образом быстро предоставля-
ется информация, необходимая для коммутации? Для ответа на эти вопросы рассмот-
рим типичную структуру быстрого кэша.

Сначала рассмотрим выводимую командой show ip cache verbose информацию
(пример 2.3) для более точного представления о том, что такое быстрый кэш.

[пример 2.3. Просмотр содержимого быстрого кэша

murka#sh ip cache verbose

IP routing cache 1 entry, 160 bytes

40 adds, 39 invalidates, 0 refcounts

Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests

Invalidation rate 0 in last second, 0 in last 3 seconds

Last full cache invalidation occurred 2w6d ago

Prefix/Length	Age	Interface	Next Hop

10.21.2.4/32-16	2d00h Seriall/0	10.21.2.4

4	FF030021

Из примера 2.3 очевидно, что маршрутизатор хранит префикс получателя, длину
префикса, исходящий интерфейс, следующую точку перехода и МАС-заголовок. Все
указанные данные необходимы для коммутации пакета и хранятся в одной записи кэша.

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

Структуры данных быстрого кэша: хеш-таблицы
и базисное дерево

Быстрый кэш для протокола IP изначально реализован как структура данных, на-
зываемая хеш-таблицей, или просто хешем (рис. 2.5).

Каждый IP-префикс указывает на определенное место в хеш-таблице. Отдельные
записи в хеше находятся с помощью двух логических операций: “исключающее ИЛИ”
отдельно над старшими и младшими 16 битами 32-битового IP-адреса. Результатом
поиска является указатель на необходимое место в хеш-таблице, которое называется
ячейкой хеша. Каждая ячейка хеша содержит запись кэша, включая заготовку МАС-
адреса для следующей точки перехода.

Вычисление хеша (или просто хеширование) не всегда дает уникальный адрес ячей-
ки хеш-таблицы для каждого IP адреса. Случай, когда более чем один IP-адрес указыва-
ет на одну и ту же ячейку, называется коллизией (или столкновением). Когда это про-
исходит, система IOS соединяет каждую из записей для таких адресов в одну ячейку.
Максимум одна ячейка хеша может содержать до шести записей кэша, поэтому не более
чем среди шести записей кэша необходимо искать необходимое совпадение.
10.1.11.0	172.16.188.0	192.168.104.0	10.89.83.0		
		;			,	* If   .4/
172.16.216.0	10.1.111.0	10.84.55.0	172.147.91.0	10.254.144	192.168.12.0
10.89.54.0					
10.1.109.0	192.168.14.0	172.16.218.0	10.89.53.0		
192.168.15.0	10.89.52.0	10.1.108.0			
10.254.156.0	172.16.212.0	172.147.87.0	10.89.59.0	192.168.0.0	10.1.99.0
 '	 ч ,			“’A	, «.г	
10.1.244.0	172.16.67				



£

Префиксы
протокола II

МАС-заголовки

Рис. 2.5. Структура быстрого кэша

Начиная с версии 10.2 операционной системы Cisco IOS хеш-таблица заменена
другой структурой данных — бинарным базисным деревом. В такой реализации струк-
туры данных МАС-адрес, как и раньше, хранится в виде части кэш-таблицы.

Базисное дерево, как и хеш-таблица, — это дополнительная структура данных, не-
обходимая для ускорения выборки нужных записей.

Базисное дерево получило свое название от способа его построения — от основы
(базиса). На практике это означает, что информация хранится в древовидной структу-
ре, основанной на бинарном представлении ключа (или уникального поля, иденти-
фицирующего каждый элемент данных). Например, для хранения таких чисел исполь-
зуется приведенное ниже представление.

	10, 1010 в бинарном виде.

	7, 0111 в бинарном виде.

	2, 0010 в бинарном виде.

Структура базисного дерева приведена на рис. 2.6.
Ветки дерева представляются двоичными знаками с номером для каждого уровня.
Как, например, сохранение или поиск числа 10 начинается с основания дерева и
старший бит в числе 1010 — единица.

Старший бит, равный единице, приводит к выбору правой ветви дерева. Так как
данный узел не имеет больше потомков, то следующий этап — сравнение числа в узле
с искомым числом. В данном случае число в текущем узле дерева и есть искомое.

Для нахождения или сохранения числа 7 поиск снова начинается с основания де-
рева. Первый бит бинарного представления числа 7 — нуль, поэтому необходимо вы-
брать левую ветвь дерева. Так как узел на левой ветви имеет потомков, то следующая
ветвь дерева выбирается на основании второго по старшинству бита в числе 7. Так как
этот бит равен 1, то выбираем правую ветвь дерева.

И еше один пример того, как найти запись, соответствующую числу 2: старший
бит двоичного представления числа 2 — 0, следовательно, выбираем левую ветвь дере-
ва. Следующий бит в двоичном представлении числа 2 тоже 0, значит, будет выбрана
левая ветвь дерева. Полученный узел не имеет потомков, поэтому сравниваем запи-
санное в узле число с искомым и находим совпадение. Поиск завершен.

Ограничения быстрого кэша для 1Р-маршрутизации

Существует одно основное ограничение для быстрого кэша при хранении IP-
префиксов — не допускается наличие записей с перекрывающимися значениями. Для
примера рассмотрим построение записей кэша для указанных ниже IP-префиксов:

	172.31.46.0/24

	172.131.46.128/25

	172.31.46.129/32

Когда быстрый кэш ишет информацию для коммутации, он не использует маску под-
сети или длину префикса и не существует способа определить, что запись 172.31.46.129 ис-
пользует префикс длиной в 32 бита, а запись 172.131.46.128 — длиной в 25 бит.

Самый простой способ преодолеть такое ограничение — создать записи в таблице
для каждого получателя. Однако такой метод неприменим из-за того, что необходимо
создавать множество записей в кэше для каждой машины получателя и каждая новая
запись будет содержать всю необходимую информацию; при этом будет увеличиваться
объем памяти, занимаемой кэшем.

Что же делает система IOS для решения этой проблемы? Она создает записи в кэ-
ше согласно определенному набору правил, которые приведены ниже.

	Если получатель напрямую соединен с маршрутизатором, то запись в кэше со-
держит 32-битовый префикс.

	Если существует несколько путей к получателю, то запись будет также содер-
жать 32-битовый префикс.

	Если это суперсеть (supernet), кэш использует длину префикса суперсети.

	Если основная сеть не содержит подсетей, используется префикс основной сети.

	Если основная сеть содержит подсети, то используется самый длинный пре-
фикс в этой основной сети.

Из приведенной в примере 2.4 части таблицы маршрутизации IP-протокола на
маршрутизаторе Cisco можно определить, какие префиксы будут использоваться для
разных получателей.
Пример 2.4. Определение длин префиксов для получателей, которые использует
маршрутизатор	'	

Router#show ip route

О 172.31.0.0 [110/11] via 172.25.10.210, 2d01h, EthernetO
[110/11] via 172.25.10.215, 2d01h, EthernetO

172.16.0.0/16 is variably subnets, 2 subnets, 2 masks

D EX 172.16.180.0/25 [170/281600] via 172.25.10.210, 3d20h, EthernetO

D EX 172.16.180.0/32 [170/281600] via 172.25.10.210, 3d20h, EthernetO

О 10.0.0.0 [110/11] via 172.25.10.210, 2d01h, EthernetO

О 192.168.0.0/16 [110/11] via 172.25.10.210, 2dl8h, EthernetO

172.25.0.0/24 is subnetted, 1 subnet

C 172.25.10.0 [0/0] via connected, EthernetO

Ниже приведен список, в котором показано, каким образом будут кэшироваться
длины префиксов, указанные в примере 2.4.

	Каждый получатель в сети 172.31.0.0/16 будет кэшироваться с 32-битовым пре-
фиксом. так как существуют два эквивалентных пути к этой сети, записанных в
таблице маршрутизации.

	Каждый получатель в сети 172.16.0.0/16 будет кэшироваться с 32-битовым пре-
фиксом, поскольку в данной подсети существует маршрут с таким префиксом.

	Сеть 10.0.0.0/8 будет иметь одну запись в кэше, потому что это маршрут к ос-
новной сети без подсетей и маршрутов к конечным пользователям, эквивалент-
ных маршрутов и т.д.

	Сеть 192.168.0.0/16 будет иметь одну запись в кэше, потому что это маршрут к
суперсети без подсетей.

	Все получатели в сети 172.25.10.0/24 будут кэшироваться с использованием 32-
битового префикса, так как они напрямую подключены к маршрутизатору.

Поддержка кэша

При кэшировании данных особенно важно каким-либо образом поддерживать
синхронизацию кэша с изначальным источником информации и отслеживать уста-
ревшие данные. Существуют два механизма обслуживания кэша: аннулирование и уда-
ление старых записей (cache invalidation и cache aging).

При использовании быстрой коммутации проблема состоит в нахождении метода
обновления информации в быстром кэше, чтобы он содержал ту же информацию, ко-
торая имеется в таблице маршрутизации и ARP-таблице (или другой таблице, из ко-
торой создается МАС-заголовок).

Аннулирование записей кэша

Проблема поддержания синхронизации кэша с таблицей маршрутизации осложня-
ется возможностью использования рекурсивных или зависимых маршрутов при ком-
мутации IP-пакетов.

Рекурсия является одним из наиболее важных понятий при рассмотрении опера-
ций над кэшем маршрутизации, поэтому полезно рассмотреть пример рекурсивной
маршрутизации. На рис. 2.7 изображен пример того, как выглядит рекурсия в сети.
10.1.1.0/24 . 10.1.2.0/24	10.1.3.0/24

10.1.3/24 через 10.1.2.2

Рис. 2.7. Рекурсивный маршрут

На рис. 2.7 маршрутизатору А необходимо найти маршрут к получателю с адресом
10.1.3.38 и определить, какой МАС-заголовок необходимо прописать в пакете при его
отправке к следующему узлу. Когда маршрутизатор А просматривает свою таблицу
маршрутизации, он находит, что получатель доступен через узел с IP-адресом 10.1.2.2.

Этот узел не подключен напрямую к маршрутизатору А, следовательно, необходимо
снова просматривать таблицу маршрутизации для определения следующей точки пере-
хода. Маршрутизатор А определяет, что 1Р-адрес 10.1.2.2 доступен через устройство с ад-
ресом 10.1.1.2, которое, в свою очередь, подключено к маршрутизатору напрямую.

Маршрутизатор А теперь будет посылать все данные, предназначенные для получа-
теля с адресом 10.1.3.38, через устройство 10.1.1.2.

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

Поскольку раскрытие рекурсии происходит при создании записи для кэша, то нет
прямой зависимости между быстрым кэшем и таблицей маршрутизации или таблицей
записей протокола ARP. Каким же образом тогда поддерживается синхронизация с
данными основных таблиц? Наилучшим решением описанной проблемы будет ис-
пользование механизма, который периодически аннулирует, или удаляет, записи в
кэше при изменении соответствующих данных в основных таблицах.

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

	Для точки перехода изменилась, была удалена или устарела запись в ARP-
таблице.

	Префикс в таблице маршрутизации изменился или был удален.

	Изменился адрес следующей точки перехода в таблице маршрутизации.

Удаление старых записей кэша

Операционная система 1OS периодически удаляет некоторые записи из кэша. Не-
большое количество записей аннулируется каждую минуту во избежание излишнего
увеличения размеров кэша и повторной синхронизации кэша с таблицами маршрути-
зации и МАС-адресов. При наличии свободной памяти более чем 200 Кбайт процесс,
отвечающий за очистку кэша (cache ager process), случайным образом аннулирует одну
двадцатую всех записей. Если же свободной памяти осталось меньше 200 Кбайт, то
указанный процесс начинает более агрессивно удалять записи: одна пятая всех запи-
сей кэша аннулируется каждую минуту.
Использование процесса балансировки нагрузки
и механизма быстрой коммутации

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

На рис. 2.8 показано несколько рабочих станций, подключенных к сетевому сег-
менту маршрутизатора А. Каждая рабочая станция обменивается данными с единст-
венным сервером в другом сегменте сети, который подключен к маршрутизатору В.
Маршрутизаторы А и В соединены между собой двумя параллельными маршрутами.
Пусть в рассматриваемом примере оба параллельных пути имеют одинаковый удель-
ный вес. Можно ожидать, что поток данных между клиентским и серверным сегмен-
тами будет равномерно распределяться по указанным двум маршрутам. Проверим, что
происходит в таком случае.

Начиная работу с пустым кэшем, маршрутизатор А получает пакет от клиента с адре-
сом 10.1.1.220, адресованный серверу, который имеет адрес 10.1.4.42. Как уже было ска-
зано выше, первый пакет коммутируется программно, и маршрутизатор А вносит в кэш
запись для получателя с адресом 10.1.4.42. Так как существуют два эквивалентных пути
к получателю 10.1.4.42 (через маршрутизатор В), то маршрутизатор А выберет один из
них для создания записи в кэше. При этом используется алгоритм пакетной баланси-
ровки нагрузки, описанный ранее для механизма программной коммутации.

Рис. 2.8. Балансировка нагрузки с использованием быстрого кэша

Затем маршрутизатор А получает от другого клиента еше один пакет, адресованный
получателю с адресом 10.1.4.42 (серверу). В этот раз для коммутации будет использо-
ваться механизм быстрой коммутации, потому что в кэше уже существует запись для
данного получателя. В то же время в кэше уже прописан указатель на выходной интер-
фейс для данного получателя, следовательно, маршрутизатор А отправит второй пакет
через тот же интерфейс, что и первый. Очевидно, что маршрутизатор А будет продол-
жать посылать все пакеты, адресованные серверу с адресом 10.1.4.42, через тот же самый
интерфейс, для которого есть запись в кэше, до тех пор, пока по какой-то причине не
аннулируется первая запись. После удаления записи может быть выбран другой путь, но
пакеты будут коммутироваться для сервера 10.1.4.42 только через один путь.

Если на сегменте 10.1.4.0/24 расположено несколько серверов, то аналогичный
процесс будет применен для каждого из них. Путь кэшируется для каждого сервера и
может быть разным, но для каждого отдельного сервера все пакеты, приходящие от
клиентов, будут идти по одному маршруту.

Теперь рассмотрим поток данных, идущий в другом направлении. Маршрутизатор
В будет кэшировать получателей в клиентской сети точно таким же образом, как это
делал маршрутизатор А для серверной сети. В данном примере маршрутизатор В соз-
даст две записи в кэше для одного пути и третью запись — для другого пути. Возмож-
на ситуация, когда маршрутизатор В выберет для отправки трафика двум клиентам
путь, который не выбрал маршрутизатор А для пересылки пакетов в серверную сеть. В
этом случае будет относительно хорошая балансировка нагрузки между двумя парал-
лельными путями. Если же маршрутизатор В для двух записей выберет тот же путь,
который маршрутизатор А использует для потока данных на сервер, то в результате
мы получим несбалансированное использование маршрутов.

Отсутствие четкой схемы балансировки нагрузки — это область поиска возможных
решений для многих сетевых дизайнеров. В результате такого поиска появились более
современные методы коммутации, поддерживающие схемы распределения нагрузки,
которые помогают обойти эту проблему. Одним из таких методов является экспресс-
пересылка корпорации Cisco (Cisco Express Forwarding — CEF), которая более под-
робно рассмотрена ниже.

Оптимальная коммутация

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

Выше было показано, что доступ к быстрому кэшу осуществлялся с помощью хеш-
таблицы в ранних версиях и с помощью бинарного базисного дерева в более поздних
версиях системы IOS. Доступ к кэшу методом оптимальной коммутации осуществля-
ется через 256-ветвистое дерево со множеством путей (так называемое м-дерево). На
рис. 2.9 показан пример м-дерева с 256 ветвями.

Информация о доступности адресата и МАС-заголовке получателя хранится во мно-
жестве узлов, каждый из которых имеет 256 потомков. Несмотря на то что такое дерево
предоставляет более быстрый способ выборки информации, чем бинарное дерево быст-
рого кэша, на оптимальный кэш накладываются те же ограничения, что и на быстрый.

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

	Запись кэша создается при обработке первого пришедшего пакета механизмом
программной коммутации.

	Записи в кэше устаревают и аннулируются, как только изменяется информация
в таблице маршрутизации или другая кэшируемая информация.
	Возможности балансировки нагрузки также ограничены использованием только
адреса получателя.

	Одинаковые правила используются для определения, какая запись в кэше соот-
ветствует каждому конкретному получателю.

|	1.0.0.0	]-----------

|	2.0.0.0	\

|	3.0.0.0

Рис. 2.9. Структура оптимального кэша

Выводимая командой show ip cache optimum информация, которая приведена в приме-
ре 2.5, очень похожа на результат команды show ip cache verbose из примера 2.3. Основное
отличие состоит в первых строках подробной информации о кэше, отображающих данные
об описанном выше м-дереве, в котором хранится вся необходимая информация.
Пример 2.5. Информация о записях в оптимальном кэше

routerttshow ip cache optimum

Optimum Route Cache

1	prefixes, 1 nodes, 0 leaf refcount, 8K bytes

0 nodes pending, 0 node alloc failures

8	prefix updates, 4 prefix invalidations

Prefix/Lenght	Age	Interface	Next Hop

10.1.1.16/32-24 lw4d EthernetO 10.1.1.16

Первые несколько строк вывода под заголовком Optimum Route Cache дают ин-
формацию о количестве узлов в м-дереве, конечных узлов дерева, узлов, связанных с
любыми другими узлами (что проявляется при наличии рекурсивных маршрутов), о
размере выделенной памяти и счетчике обновлений м-дерева.

В начале работы алгоритма кэширования не все узлы м-дерева оптимального кэша со-
держат записи (данные); большинство потомков каждого узла ссылаются на NULL
(нулевой указатель). Несмотря на то что кэш заполняется при обработке пакетов методом
программной коммутации и что постепенно количество заполненных узлов увеличивается,
скорее всего вы никогда не увидите полностью заполненное м-дерево оптимального кэша.

Экспресс-пересылка корпорации Cisco

Экспресс-пересылка корпорации Cisco (Cisco Express Forwarding — CEF) — это
наиболее современный и быстрый метод коммутации, реализованный в операци-
онной системе IOS. Изначально он был разработан для того, чтобы преодолеть
основные недостатки метода быстрой коммутации. Возвращаясь к описанию ме-
тода быстрой коммутации, обратим внимание на его основные недостатки, кото-
рые перечислены ниже.

	Недостаточная поддержка перекрывающихся записей кэша.

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

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

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

Большинство из этих недостатков не создают проблем в корпоративных сетях
среднего размера, потому что маршруты изменяются достаточно редко и таблица
маршрутизации не очень велика. Однако существует область, в которой перечислен-
ные ограничения приводят к появлению проблем, а именно: бекбон Internet и маги-
стральные каналы.

Маршрутизаторы, работающие на бекбоне Internet, поддерживают огромные таб-
лицы маршрутизации (порядка 56000 маршрутов на начало 1999 года), и количество
маршрутов постоянно увеличивается. Некоторые маршрутизаторы на бекбоне содер-
жат более 100000 записей в таблице маршрутизации. Кроме того, таблица маршрути-
зации постоянно изменяется, что приводит к частому аннулированию записей кэша.
На практике записи аннулируются с такой скоростью, что значительная часть трафи-
ка, проходяшая через некоторые Internet-маршрутизаторы, использует метод про-
граммной коммутации. Протокол CEF разработан специально для повышения произ-
водительности маршрутизаторов в таких условиях.
Метод коммутации CEF тестировался в крупномасштабном сетевом окружении
Internet. Провайдеры услуг Internet получили серию специальных образов системы
IOS (прозванных “дегенеративными” образами системы 1OS для провайдеров услуг
Internet, или ISP Geeks images) с реализацией метода коммутации CEF для наблюдения
за работой метода в экстремальных условиях. Разработанная технология показала
свою жизнеспособность в условиях большой нагрузки lnternet-бекбона и вскоре была
встроена в операционную систему Cisco IOS, и, кроме того, стала методом коммута-
ции, используемым по умолчанию в системе Cisco IOS версии 12.0. На текущий мо-
мент это — единственный метод коммутации, доступный на некоторых платформах, в
частности в маршрутизаторах серии Cisco 12000 и коммутаторах серии Catalyst 8500.

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

В отличие от метода быстрой коммутации, которая кэширует часть таблицы мар-
шрутизации и таблицы МАС-адресов, алгоритм CEF создает отдельную структуру,
полностью воспроизводящую таблицы маршрутизации и МАС-адресов. Коммутация
CEF поддерживает две основные структуры, которые обобщенно могут быть названы
как “быстрый кэш” CEF и приведены ниже.

	CEF-таблица.

	Таблица связей.

CEF-таблица

CEF-таблица — это “урезанная” версия таблицы маршрутизации, представленная
в виде 256-ветвистого м-древа для получения оптимальной производительности. Вы
можете отобразить размер CEF-таблицы (и другую основную информацию о таблице)
на экране с помощью команды show ip cef summary, как показано в примере 2.6.

Пример 2.6. Получение информации о CEF-таблице	'

tom#show ip cef summary

IP CEF with switching (Table Version 1173570), flags=0x0

106443 routes, 0 reresolve, 0 unresolved (0 old, 0 new)

106443 leaves, 6541 nodes, 20001572 bytes, 1173573 inserts, 1067130
invalidations

0 load sharing elements, 0 bytes, 0 references

universal per-destination load sharing algorithm, id 8EFDD987

3 CEF resets, 666 revisions of existing leaves
refcounts: 1881096 leaf, 1674752 node

Adjacency Table has 120 adjacencies

1 incomplete adjacency

В структуре 256-ветвистого м-древа6 каждый узел может иметь до 256 потомков. В
CEF-таблице каждый потомок (или связь) используется для представления разных ад-
ресов в одном октете ]Р-адреса (рис. 2.10).

Например, для IP-адреса 10.10.10.4 поиск данных осуществляется выбором деся-
того потомка от корня (основания) дерева, десятого потомка полученного узла, еще
раз отбором десятого потомка уже следующего полученного узла, а затем выбором
четвертого потомка последнего узла. Этот последний узел, или конечный узел, содер-

6 В английском языке используются два понятия — тггее и mtrie. Логически они означают одно и то
же, но у них разная реализация, поэтому для miree используется понятие м-дерево, а для mtrie — м-
древо. — Прим, перев.
жит указатель на запись в другой внешней таблице, в алгоритме, называемом табли-
цей связей. Таблица связей содержит МАС-заголовки и другую информацию, необхо-
димую для коммутации пакета.

CEF-таблица
Внимание!

При использовании структуры данных а аиде м-дерева данные хранятся внутри самого де-
рева; например, м-дерево кэша метода оптимальной коммутации содержит МАС-
заголовок, используемый при коммутации пакета. В структуре м-древа само дерево ис-
пользуется для нахождения нужных данных, но в нем не содержится никакой информации.

Таблица связей

Таблица связей содержит данные МАС-заголовка пакета для прямого соединения
со следующим узлом и заполняется данными из таблицы протокола ARP, карты про-
токола Frame Relay и других таблиц с информацией о заголовках второго уровня мо-
дели OSI (Open System Interface — интерфейс взаимодействия открытых систем). Ко-
манда show adjacency показывает информацию, которую содержит таблица связей
(результат ее работы приведен в примере 2.7).

| Лримар 2.7. Пример

tom#show adjacency		
Protocol	Interface	Address
IP	ATM1/0.1	point2point(3)
IP	Serial2/2 -:	point2point(363)
IP	Serial2/1	point2point(212129)
IP	FastEthernetO/O.4	10.37.0.46(5)
IP	FastEthernetO/O.4	10.37.0.33(5)

Существует несколько типов записей для поля Address, которые можно увидеть при
выполнении команды show adjacency (они перечислены ниже).

	Кэшированная связь (cached adjacency). Для записи предопределен МАС-
заголовок для следующей точки перехода на пути к получателю.

	Запись отправки (punt). Пакет, адресованный этому адресу, для коммутации
должен пройти по указанному пути.

	Запись хост-маршрут (host-route). Данный получатель напрямую подсоединен к
маршрутизатору.

	Аннулированная запись (drop). Пакет, адресованный указанному получателю, иг-
норируется.

	Неполная запись (incomplete). Не определен МАС-заголовок для данного адреса;
обычно это означает, что отсутствует запись в кэше для данного адреса или ее невоз-
можно создать (как, например, при неправильной конфигурации сети у получателя).

	Незаполненная запись (glean). Данный получатель напрямую подключен к мар-
шрутизатору, но для него не создан МАС-заголовок; необходимо послать за-
прос протокола ARP для создания заголовка.

Метод CEF и его преимущества

Как и механизм быстрой коммутации, CEF использует кэш для выполнения всей
операции коммутации в течение одного прерывания процессора. Главное отличие ме-
жду CEF и методом быстрой коммутации состоит в алгоритме создания кэша. Меха-
низм быстрой коммутации требует прохождения первого пакета к любому получателю
через механизм программной коммутации для создания записи в кэше. В то же время
таблица метода CEF создается напрямую из таблицы маршрутизации и ARP-кэша.
Структура протокола CEF создается до того, как любой пакет будет коммутироваться.

Поскольку метод CEF создаем кэш до того, как будут коммутироваться пакеты, ка-
ждый пакет, отправленный к доступному получателю, будет переправляться операци-
онной системой в течение одного прерывания на получение пакета. Нет необходимо-
сти использовать программную коммутацию для создания записи в кэше. Заранее
созданная кэш-таблица значительно повышает производительность маршрутизации на
маршрутизаторах с большой таблицей маршрутизации. При использовании быстрой
коммутации операционная система IOS может быть перегружена трафиком, проходя-
щим через механизм программной коммутации, прежде, чем будут созданы необхо-
димые записи в кэше. Благодаря использованию протокола CEF исчезает большая
нагрузка, вызванная программной коммутацией пакетов, что предохраняет систему
IOS от перегрузки программной коммутацией при частом переключении маршрутов.

Разделение информации о доступности/интерфейсе и МАС-заголовке на две структуры
дает еше одно дополнительное преимущество — таблицы, используемые при коммутации
пакетов, напрямую связаны с теми ресурсами данных, из которых они создаются. Следова-
тельно, не требуется выполнять процедуру удаления устаревших записей (aging process).

Записи в структурах метода CEF никогда не'устаревают. Все изменения в таблице
машрутизации или ARP-таблйце легко переносятся в Структуры CEF. Кроме того, при
работе CEF отпадает необходимость в аннулировании большого .количества записей
кэша при изменениях в таблице маршрутизации или ARP-кэше.

Балансировка нагрузки и CEF

Балансировка нагрузки при использовании CEF-коммутации может выполняться
как по паре отправитель—получатель, так и по отдельным пакетам. Балансировка на-
грузки, основанная на паре отправитель—получатель, решает проблему( описанную
ранее для быстрой коммутации, когда весь трафик, идущий к одному серверу, прохо-
дит по одному пути, потому что кэш создается на основе адреса получателя. Как это
Происходит? Вместо указателя на таблицу связей.запись в CEF-таблице может содер-
жать указатель на структуру балансираМИ нагрузки,.показанную на рис. 2.11.

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

Последовательность операций в алгоритме коммутации пакета

В каком порядке осуществляются операции над пакетом в процессе коммутации?
Приведенный ниже короткий список может не включать все возможности, реализо-
ванные в операционной системе IOS, но все же дает начальное представление о по-
следовательности, выполнения операций.

	Компрессия и декомпрессия.

	Шифрование.

	Фильтр входящих пакетов.

	Однонаправленная обратная проверка пути.

	Ограничение входящего потока.

	Обработка широковещательных запросов физического уровня.

	Уменьшение TTL (Time То Live — параметр времени существования пакетов),
если это не было выполнено ранее.

	Подсистема проверки пакетов (возможность организации брандмауэра или
средства межсетевой защиты).

	Трансляция сетевых адресов из внешних на внутренние (outside to inside — NAT).

	Обработка флагов в IP-пакете.
CEF-таблица

Рис. 2.11. Структура балансировки нагрузки CEF

	Поиск выходного интерфейса в таблице маршрутизации.

	Применение правил маршрутизации (policy routing) для пакета.

	Поддержка перенаправления пакетов на Web-кэш (организация transparent proxy).
	Трансляция сетевых адресов извнутренних во внешние (inside to outside — NAT)

	/Шифрование..	\' * ,	j;	.....	: ’

	Исходящий фильтр пакетов.

	Конечная обработка пакетов подсистемой фильтров или списков доступа.

	Обработка перехват управления протоколом TCP.

Резюме

Маршрутизаторы корпорации Cisco коммутируют пакеты по одному из нескольких
алгоритмов; алгоритмы коммутации характеризуются типом используемого кэша, ме-
тодом организации доступа и создания кэша и тем, каким образом (программно или
во время прерывания) происходит сама коммутация.

	Программная коммутация не кэширует информацию и коммутирует пакет с
помощью отдельного процесса, т.е. программно.

	Быстрая коммутация кэширует информацию о доступности, об интерфейсе и о
МАС-заголовке, необходимую для пересылки пакета. Эта информация хранится в
бинарном базисном дереве, и пакеты коммутируются в течение одного прерывания.

	Метод оптимальной коммутации кэширует информацию о доступности и МАС-
заголовок в многоветвистом дереве (м-дереве) и коммутирует пакеты в течение
одного прерывания.

	Метод коммутации CEF кэширует информацию о МАС-заголовоках и сведения
о достижимости узла в таблице связей. Протокол CEF также коммутирует паке-
ты в течение одного прерывания.

Г.Т."?"2	—т  [Таблица 2.1.0бо€	5щенные характеристики <	>азлйчных мбтойов коммутаций^
Метод коммутации	Тип кэша	Характеристика обработки пакетов
Программная ком- мутация	Нет	Переключение пекетов выполняется с помощью службы, запускаемой плани- ровщиком задвч
Быстрая коммута- ция	Хеш-таблица или двуна- правленное базисное ра- диальное дерево и кэш маршрутов	Пакет коммутируется центральным процессором в течение обработки прерывания
Оптимальная ком- мутация	М-дерево и быстрый мар- шрутный кэш	Пакет коммутируется центральным процессором в течение обработки прерывания
Экспресс- пересылка корпора- ции Cisco (CEF)	М-древо и таблице соседей	Пакет коммутируется центральным процессором в течение обработки прерывания
...
а*'" Ч‘ >>’	«

Jt^-	*Й^>..	*;

Ключевые темы этой главы ,	’ . •	.<

 Принципы аппаратного устройства маршрутизаторов с разделяемой памятью
Глава

3

Маршрутизаторы
с разделяемой памятью

В двух предыдущих главахмы коснулись общих принципов создания структуры
операционной системы IOS ^механизма коммутации пакетов. Однако для того, что-
бы понять, -как в действительности устроена система IOS, было бы полезным рас-
смотреть ее работуна реальноьг^Маршрутизаторе. Поскольку операционная система
IOS тесно связана ^аппаратным' обеспечением, на котором она выполняется, каждая
: конкретная реализация операционной системы имеет свои особенности.

' В данной главе мы рассмотрйм наиболее общую реализацию Системы, предназна-
ченную для так называемых маршрутизаторов с разделяемой памятью. Семейство
маршрутизаторов с’разделяемой ^памятью включает несколько моделей: Cisco 1600,
2500, 4000, 4500 й 4700 серий. Несмотря на то, что все они имеют свои отличительные
особенности, у,таких устройств есть два общих принципа: использование разделяемых
ресурсов (центральный процессор, основная память и интерфейсы) и использование
. системных буферов для хранен^ пакетов.

Аппаратное устройство
маршрутизаторов
с разделяе мо й п।а мятью

Рассмотрим детально аппаратную .структуру маршрутизаторов с разделяемой памятью.
Для начала коснемся наиболее общей схемы, представленной на рис. 3.1, а затем остано-
вимся на конкретных аппаратных Особенностях маршрутизаторов данного семейсПва.

Как видно jis^Bc. 3.1, наиболее'общий взгляд на устройство маршрутизатора по-
зволяет выдёлить'Три основных’компонента: центральный процессор (Central Process-
? ing Unit — СРи)рпамять (Dyriartic Random Access Memory — DRAM) и контроллеры
интерфейсов. Причем как процессор, так и контроллеры связаны с памятью посредст-
вом шин данных? На рисЙЗ.1 Отображено также разделение памяти на логические об-
ласти, назначение которых мЫ? рассмотрим ниже.
Центральный процессор

Память (динамическая)

данных)

Интерфейс

Интерфейс

Кольцо ТХ
(передача

X. данных)

Системные буферы

Кольцо RX

(прием },

данных)

J Кольцо ТХ'мг Кольцо RX\|
(передача 4 '---------- 151

1 данных) }'t

Рис. 3.1. Устройство маршрутизатора с разделяемой памятью

Центральный процессор

Центральный процессор является поистине “мозговым” центром маршрутизатора с
разделяемой памятью: он исполняет код системы IOS и коммутирует пакеты. Цен-
тральный процессор несет ответственность за реализацию всех механизмов коммута-
ции, поддерживаемых данной платформой, при этом никакие дополнительные про-
цессоры не привлекаются.

Тип используемого процессора зависит от конкретной платформы. Так, для маршрути-
заторов Cisco серий 1600 и 2500 применяется процессор Motorola 68000, в то время как в
маршрутизаторах серий 4500 и 4700 используется процессор MIPS RISC. Тип используе-
мого процессора можно определить с помощью команды show version. В примере 3.1 при-
веден результат выполнения команды show version на маршрутизаторе Cisco 1600. В приме-
ре 3.2 показана аналогичная ситуация для маршрутизатора Cisco 4500.
Пример 3.1,. Информация дляма
?^|h^^wsI10v^ version ЛЛдайИ

ЫХОклЛа4£ии_--«адЯМИ

рутизатора Cisco 1600,выводимая командой).

-diiL.-a-lAsxa.- - -S-/X лг^иа—Ч

router-1600>show version

Cisco Internetwork Operating System Software

cisco 1604 (68360) processor (revision C) with 17920K/512K bytes of
memory.

Processor board ID 05385389, with hardware revision 00972006

router-4500>show version

Cisco Internetwork Operating System Software

cisco 4500 (R4K) processor (revision B) with 16384K/16384K bytes of memory.
Processor board ID 01657190

R4600 processor, Implementation 32, Revision 2.0

Память

Маршрутизаторы с разделяемой памятью оснашены динамической памятью
(Dynamic Random Access Memory — DRAM), которая используется для хранения
большинства данных: таблиц маршрутизации, кэша, данных системы IOS, буферов
пакетов и самого кода IOS (для большинства систем).

Динамическая память, доступная в системе, разделяется IOS на два логических
класса: локальная память (Local) и lomem (I/O memory — память ввода-вывода). В
большинстве случаев локальная память расположена в области main (основная), а па-
мять ввода-вывода — в области iomem, что проиллюстрировано в примере 3.3, кото-
рый содержит результат исполнения команды show region.

}Пример~ 3.3. Области динамической .памяти, Ьтрбрфгаемые командой show region

Router-4500#show region

Region Manager:

Start	End	Size(b)	Class	Media	Name
0x30000000	0x30FFFFFF	16777216	Flash	R/O	flash
0x38000000	0X383FFFFF	4194304	Flash	R/O	Bootflash
0x40000000	0X40FFFFFF	16777216	lomem	R/W	iomem
0x60000000	0x61FFFFFF	33554432	Local	R/W	main
0х600088А0	0x607229BF	7446816	IText	R/O	main:text
0x60726000	0x6096506F	2355312	IData	R/W	main:data
0x60965070	0x609DBlCF	483680	IBss	R/W	mainsbss
0X609DB1D0	0x61FFFFFF	23219760	Local	R/W	maimmainheap
0x80000000	0x81FFFFFF	33554432	Local	R/W	main:(main_k0)
0x88000000	0x88FFFFFF	16777216	lomem	R/W	iomem:(iomem_k0)
ОхАООООООО	OxAlFFFFFF	33554432	Local	R/W	main:(main_kl)
0хА8000000	0xA8FFFFFF	16777216	lomem	R/W	iomem:(iomem_kl)

Размеры рассматриваемых нами областей памяти также отображены в выводе ко-
манды show version, как показано в примере 3.4.
[Пример? 3.4.Размер областей памяти^- огабражашЯийй i^f^qii/show5reiiiotfgfeg^i j

Cisco Internetwork Operating System Software

IOS (tm) 4500 Software (C4500-J-M), Version 11.1(24), RELEASE SOFTWARE
(fcl)

cisco 4500 (R4K) processor (revision E) with 32768K/16384K bytes of
memory.

Processor bard ID 09337282	1

Число, стоящее перед косой чертой, обозначает объем локальной памяти (32768
Кбайт), ’-'а Число,! стоящее за косой чертой, объем памяти ввода-вывода
(16384 Кбайт). Общий объем установленной динамической памяти можно вычислить,
сложив два этих числа (49152 Кбайт). Для системы из примеров 3.3 и 3.4 32786 Кбайт
локальной памяти соответствуют области main (основная), а 16384 Кбайт — памяти
ввода-вывода и области iomem соответственно.

На платформах с разделяемой памятью область памяти main используется для хра-
нения таблиц маршрутизации, кэша и структур данных системы IOS общего назначе-
ния. Зачастую в данной области памяти хранится Исполняемый код операционной
системы. Буферы пакетов, однако, содержатся в другой области памяти — iomem, ко-
торую зачастую называют разделяемой памятью (shared memory), поскольку доступ к
ней имеют и процессор, и сетевые интерфейсы.

В большинстве систем динамическая память (DRAM), используемая для локаль-
ных нужд, и память, отведенная для операций ввода-вывода, разделены аппаратно на
два разных банка. В таких системах весь банк памяти используется под конкретную
область: один банк зарезервирован для области ввода-вывода iomem, другой — для об-
ласти main. Тем не менее в моделях маршрутизаторов Cisco 1600 и 2500 Локальная па-
мять и память ввода-вывода размешены в одном банке динамической Памяти. Объем
памяти, отводимый для области ввода-вывода, зависит При этом от общего объема ус-
тановленной памяти, согласно числам, приведенным ниже.

	1 Мбайт — из них 512 Кбайт выделяется для области ввода-вывода.

	2 Мбайт — из них 1 Мбайт выделяется для области ввода-вывода.

	4 Мбайт и больше — из них 2 Мбайта отводится под область ввода-вывода.

Местоположение исполняемого кода системы IOS в
маршрутизаторах с разделяемой памятью

Некоторые платформы маршрутизаторов с разделяемой памятью, в частности се-
рии 1600 и 2500, имеют возможность запускать систему IOS из флэш-памяти. В том
случае, если система запушена из флэш-памяти, область памяти main не используется
для хранения исполняемого кода IOS. При этом исполняемый код системы содержит-
ся в области памяти, названной flash (пример 3.5).

: Пример 3.5. Результат использования команды show region для системы,
L	запущенной из флэш-памяти	i

Router-2500#show region
Region Manager:

Start	End	Size(b)	Class	Media	Name
0x00000000	0x007FFFFF	8388608	Local	R/W	main
0x00001000	0x0001922F	98864	Idata	R/W	main:data
0x00019230	ОхОООбббВЗ	316548	Ibss	R/W	main:bss
0х000666В4	0x007FEFFF	7965004	Local	R/W	main:heap
0x007FF000	0x007FFFFF	. 4096	Local	R/W	main: flhlog
0x00800000	0X009FFFFF	2097152,.	„Ipmem	R/W	iomem
0x03000000	0x03FFFFFF	16777216	Flash	R/O	flash
0x0.3 04 ОЗЗС	0X037A7D37	7764476	Itext	R/O	flash:text

В главе 1, “Введение в структуру операционной системы IOS” было сказано, что класс
памяти IText обозначает место, где размещается исполняемый код системы IOS. В рас-
смотренном выше примере 3.5 класс IText назначен подобласти flash:text из области памя-
ти flash и обозначает тот факт, что система выполняет код операционной системы IOS из
флэш-памяти.

Информацию о местонахождении кода системы во время исполнения можно полу-
чить из формата имени файла-образа. Последний символ имени файла (или два сим-
вола) обозначает образ как перемещаемый (relocatable) или выполняемый из динамиче-
ской памяти (run-from-DRAM). Последний выполняется из локальной памяти, а пе-
ремещаемый — из флэш-памяти.

В примере 3.6 показан вывод команды show version для маршрутизатора Cisco 2500
с операционной системой 1OS, запущенной из флэш-памяти.

! ПримерЗ.б.’Образ IOS, размещённый во флэш-памята'	я ।

..................... Г.........- .........Т	J
router~2500>show version.......................-	• •

Cisco Internetwork Operation System Software
IOS (tm) 2500 Software (C2500-JS-L), Version 12.0(7.3)T, MAINTENANCE.
INTERIM SE

Copyright (c) 1986-199.9 by cisco Systems, Inc.

Последний символ в названии файла-образа (символ L) означает, что образ яв-
ляется перемещаемым (relocatable), т.е. выполняется из флэш-памяти, Напротив, если
имя образа оканчивается символами М или MZ, это означает, что образ выполняется
из локальной памяти. В примере 3.7 приведен результат выполнения команды show
version для рассмотренного выше случая.

; Пример 3.7. Образ IOS, размещенный в динамической памяти  ’' ''

Router-4500?show version	’ .

Cisco Internetwork Operation System Software

IOS (tm) 4500 Software (C4500-P-M), Version 11.2(18)P, RELEASE
SOFTWARE (fcl)

Copyright (c) 1986-1999 by cisco Systems, Inc.

Пулы памяти

Для управления выделением и освобождением памяти в пределах областей динами-
ческой памяти операционная система 1OS создает два пула. Как видно из примера 3.8, эти
два пула называются Processor (процессорный) и I/O (ввода-вывода) соответственно.

L Пример 3.8. Результат выполнений команды show memory, показывающий пулы памяти
router-2500#show memory

	Head	Total(b)	Used(b)	Free(b)	Lowest(b)	Largest(b)
Processor	3BB08	16528632	878596	15650036	15564280	15630436
I/O	4000000	2097152	473468	1623684	1603060	1623232
Пул памяти процессора (processor) создается в подобласти mainzheap, размешенной в ло-
кальной (local) памяти, а пул памяти ввода-вывода (I/O) — в области iomem памяти ввода-
вывода. Объем памяти, отводимый для пула ввода-вывода, в точности соответствует объему
области iomem. Однако размер процессорного пула всегда меньше размера области памяти
main. Пул процессора может занимать только часть области main, поскольку оставшаяся
часть области используется для внутренних данных системы IOS, для сегментов BSS и на
большинстве платформ для размещения самого исполняемого образа IOS.

Внимание!

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

Контроллеры интерфейсов

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

Буферы пакетов маршрутизаторов
с разделяемой памятью

Как было описано в главе 1, “Введение в структуру операционной системы IOS”, в
операционной системе IOS предусмотрен набор буферов, называемых системными бу-
ферами (system buffers), которые используются для коммутации пакетов. Система IOS
на платформах с разделяемой памятью также использует системные буферы. Отличие
состоит лишь в том, что системные буферы используются во время всего процесса
коммутации, а не только во время обработки.

Вдобавок к стандартному набору системных буферов IOS на платформах с разде-
ляемой памятью создает несколько персональных буферных пулов и специальные бу-
ферные структуры для контроллеров интерфейсов, называемых кольцами (rings).

Локальные буферные пулы

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

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

В примере 3.9 приведен результат вывода команды show buffers, отображающий
информацию об общих и о персональных буферных пулах.

Router#show buffers

Buffer elements:

500 in free list (500 max allowed)
57288024 hits, 0 misses, 0 created

Public buffer pools:

Small buffers, 104 bytes (total 50, permanent 50):
50 in free list (20 min, 150 max allowed)
11256002 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)

Middle buffers, 600 bytes (total 25, permanent 25):

24 in free list (10 min, 150 max allowed)
3660412 hits, 12 misses, 36 trims. 36 created
0 failures (0 no memory)

Big buffers, 1524 bytes (total 50, permanent 50):

50 in free list (5 min, 150 max allowed)
585512 hits, 14 misses, 12 trims, 12 created
2 failures (0 no memory)

VeryBig buffers, 4520 bytes (total 10, permanent 10):

10 in free list (0 min, 100 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Large buffers, 5024 bytes (total 0, permanent 0):

0 in free list (0 min, 10 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Huge buffers, 18024 bytes (total 0, permanent 0):

0 in free list (0 min, 4 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Interface buffers pools:

EthernetO buffers, 1524 bytes (total 32, permanent 32):
8 in free list (0 min, 32 max allowed)
3398 hits, 3164 fallbacks
8 max cache size, 7 in cache

SerialO buffers, 1524 bytes (total 32, permanent 32):

7 in free list (0 min, 32 max allowed)

25 hits, 0 fallbacks
8	max cache size, 8 in cache	-.r

Seriall buffers, 1524 bytes (total 32, permanent 32):

7	in free list (0 min, 32 max allowed)

25 hits, 0 fallbacks

8	max cache size, 8 in cache

Большинство параметров в выводимой приведенной командой информации объясня-
лось в главе 1, “Введение в структуру операционной системы IOS”, поэтому мы рассмот-
рим лищь.параметры, соответствующие персональным буферным пулам интерфейсов.

	fallbacks (аварийные обращения) — число обращений центрального процессора
к общему буферному пулу для размещения пакета.

	max cache size. Несколько буферов локального пула кэшируются для более бы-
строго обращения. Данный параметр определяет максимально возможное число
кэшированных буферов.

	In cache. Число кэшированных локальных буферов.

Отметим, что для локальных пулов не указываются параметры creates (число рас-
ширений буферных пулов) и trims (число усечений пулов). Это и понятно, поскольку
локальные пулы являются статическими.

Кольца приема и передачи

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

Каждому интерфейсу соответствует пара колец: одно — для приема пакетов
(кольцо приема), другое — для передачи пакетов (кольцо передачи). Размеры таких
колец фиксированы. Размер кольца приема зависит от конкретного интерфейса и ука-
зывается в спецификации контроллера устройства. Размер кольца передачи, помимо
спецификации контроллера зависит также от типа очереди пакетов, установленной
для данного интерфейса.

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

Число буферов, выделенных для кольца передачи, может варьироваться от нуля до мак-
симального размера кольца передачи. Буферы пакетов кольца передачи выбираются либо
из кольца приема, если необходима коммутация пришедшего пакета, либо из общего пула,
если пакет порожден системой IOS. Такие буферы впоследствии (после того, как пакеты
отправлены) высвобождаются из кольца передачи и возвращаются обратно в пул.

Команда show controller (пример 3.10) используется для определения размеров и
местоположения в памяти колец приема и передачи. Информация, которую мы видим
в примере 3.10, характерна для большинства типов интерфейсов, однако может иметь
несколько иной вид в разных системах.
isp-4700b#show controller ethernet	*	?'

AM79970 unit 0 NIM slot 1, NIM type code 14, NIM version 1 ‘

Media Type is lOBaseT, Half Duplex, Link State is Down, Squelch is

Normal	.	•	.

Idb 0x60AE8324, ds 0x60AE9D10, eim_regs = ОхЗСПООО

IB at 0x40006E64: mode=0x0010, mcfilter 0000/0000/0100/0000

Station address 0060.837c.7089 default station address 0060.837c.7089

Buffer size 1524	...

RX ring with 32 entries at 0x40030D0

Rxhead = 0x400303D0 (0), Rxp = 0x60AE9D28 (0)

00 pak=0x60AF2468 ds=0xA80C745E status=0x80 max_size=l&24 pak_size=0

01 pak=0x60AF2254 ds=0xA80C6DA2 status=0x80 max_size=1524 pak_size=0

02 pak=0x60AF2040 ds=0xA80C66E6 status=0x80 max_size=1524 pak_size=0

TX ring with 32 entries at 0x40059BD0, tx_count = 0
tx_head = 0x40059BD0 (0), head_txp = 0x60AE9E3C (0) ,
tx_tail = 0x40059BD0 (0), tail_txp = 0x60AE9E3C (0)
00 pak=0x000000 ds=0xA8000000 status=0x03 status2=0x0000 pak_size=0
01 pak=0x000000 ds=0xA8000000 status=0x03 status2=0x0000 pak_size-0
02 pak=0x000000 ds=0xA8000000 status=0x03 status2=0x0000 pak_size=0

Ниже описаны наиболее интересные параметры, выводимые командой show controller.

•	RX ring with 32 entries at 0x400303D0. Размер кольца приема равен 32, а на-
чало блока находится по адресу 0x400303D0 в памяти ввода-вывода.

•	00 pak=0x60AF2468 ds=0xA80C745E status=0x80 max_size=1524 pak_size=0.
Данная строка повторяется для каждого элемента кольца приема. Каждый
элемент кольца, называемый дескриптором, несет информацию о соответст-
вующем пакетном буфере, выделенном для кольца приема. Все значения, вы-
водимые в строке (кроме значения рак), специфичны для конкретного уст-
ройства и изменяются от одного контроллера устройства к другому. Значение
параметра рак обозначает адрес в памяти, где размешается связанный с дан-
ным дескриптором заголовок пакета. Все пакетные буферы в системе IOS
имеют соответствующий заголовок, содержащий информацию о содержимом
буфера и указатель на собственно буфер, размещенный в памяти. Хотя буфе-
ры пакетов на платформах с разделяемой памятью и находятся в памяти вво-
да-вывода, их заголовки могут размещаться в локальной памяти, как в рас-
сматриваемом нами случае.

•	TX ring with 32 entries at 0x40059BD0, tx_count=0. Данные параметры означают
размер кольца передачи и число пакетов, ожидающих передачи. В приведенном
случае размер кольца равен 32, и нет ожидающих передачи пакетов.

•	00 pak=0x000000 ds=0xA8000000 status=0x03 status2=0x0000 pak_size=0. Дан-
ная строка повторяется для каждого элемента в кольце передачи. Так же как
и для кольца приема, каждый элемент в кольце передачи — это дескриптор,
содержащий информацию о соответствующем пакетном буфере в кольце.
Значение параметра рак указывает на заголовок соответствующего пакетного
буфера, ожидающего передачи. Остальные параметры специфичны для кон-
кретного контроллера устройства. В отЛичйе от дескрипторов кольца приема,
дескрипторы кольца передачи связаны только с пакетным буфером, когда су-
ществует пакет, ожидающий передачи. После передачи пакета связь между
буфером и дескриптором теряется, буфер возвращается в соответствующий
пул, а значение дескриптора рак сбрасывается в 0x000000.
Коммутация пакетов
в маршрутизаторах
с разделяемой памятью

Теперь вы знакомы с аппаратной реализацией маршрутизаторов с разделяемой памя-
тью и с тем, как операционная система IOS управляется с этой памятью. Теперь давайте
рассмотрим, как происходит собственно процесс коммутации пакетов. Система IOS на
маршрутизаторах с разделяемой памятью поддерживает следующие функции.

	Процесс коммутации.

	Коммутация с помощью метода CEF.

	Быстрая коммутация.

Процесс коммутации состоит из нескольких этапов:

•	получение пакета;

•	коммутация пакета;

•	передача пакета.

Получение пакета

На рис. 3.2 проиллюстрирован этап получения пакета.

Этап 1. Контроллер интерфейса определяет наличие пакета в сети и копирует

его в буфер, указанный первым свободным элементом кольца приема
(очередной доступный буфер контроллера интерфейса). Контроллер ис-
пользует механизм прямого доступа к памяти (Direct Memory Access —
DMA) для копирования пакета.

Этап 2. Контроллер интерфейса передает процессору права владения пакетным

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

Внимание!

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

Этап 3. Процессор обрабатывает прерывание и пытается удалить только что заполнен-

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

3.1.	В персональном цуле интерфейса имеются свободные буферы для
пополнение кольца приема. Свободный буфер подключается к
кольцу, и процесс коммутации пакета продолжается на 4-м этапе.

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

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

Рис. 3.2. Получение пакета

Коммутация пакета

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

Операционная система IOS пытается коммутировать пакеты наиболее быстрым
способом из тех, которые сконфигурированы для данного интерфейса. На платформах
с разделяемой памятью система IOS сначала пробует осуществить CEF-коммутацию
(если она сконфигурирована для данного интерфейса), затем — быструю коммутацию,
потом она обращается к процессу коммутации, если предыдущие методы не дали ре-
зультата. На рис. 3.3 показаны стадии коммутации пакета.
Рис. 3.3. Коммутация пакета

Этап 5. На стадии обработки прерывания от полученного пакета система IOS пы-
тается использовать таблицу CEF и кэш быстрой коммутации для опреде-
ления пути следования пакета.

5.1.	CEF-коммутация. Если для интерфейса включена CEF-
коммутация, система IOS пытается использовать ее. При этом
возможны следующие ситуации.

5.1.1.	Если в CEF-таблице есть соответствующие смежные записи,
операционная система IOS просто переписывает МАС-адрес в
заголовке пакета и передает его дальше (этап 8).

5.1.2.	Если соответствующей записи в CEF-таблице не найдено, сис-
тема IOS переходит к этапу быстрой коммутации пакета (п. 5.2).

1	5.1.3. Если запись в CEF-таблице для данного'пакета указывает на из-

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

5.1.4.	Если в CEF-таблице нет записи для пункта назначения пакета,
• пакет игнорируется.

5.2.	Быстрая коммутация. Если механизм CEF-коммутации не вклю-
чен или CEF-коммутация не позволила переправить пакет, опе-
рационная система IOS предпринимает попытку быстрой ком-
мутации.

5.2.1.	Если в кэш-таблице есть запись для места назначения, система
IOS переписывает МАС-заголовок в заголовке пакета и передает
пакет дальше (этап 8).
5.2.2.	Если необходимая запись не найдена, паккт добавляется в оче-
редь процесса коммутации.

Этап 6. Процесс коммутации. Если перечисленные выше мехайизмы коммутации не
смогли определить пункт назначения пакета, операционная система IOS об-
ращается к процессу коммутации. Пакет помещается в очередь входящих па-
кетов соответствующего процесса (например, IP-пакеты выстраиваются в оче-
редь процесса коммутации). После этого обработка прерывания завершается.

Этап 7. В конечном итоге процесс коммутации выполняет свои функции, опреде-
ляет маршрут пакета и переписывает в его заголовке МАС-адрес. Важно
отметить, что пакет при этом все еще находится в буфере, куда он изна-
чально был скопирован. После того, как выполнился процесс коммута-
ции, система 1OS переходит к этапу передачи пакета (этап 9).

Передача пакета

На рис. 3.4 представлены стадии передачи пакета.

Рис. 3.4. Передача пакета

Этап 8. Если коммутация пакета была осуществлена с помощью метода CEF или
быстрой коммутации, система IOS проверяет наличие пакетов в выходной
очереди передающего интерфейса (находясь при этом все еще в стадии
обработки прерывания).

8.1.	Если в исходящей очереди уже присутствуют какие-либо паке-
ты, система 1OS добавляет новый пакет в очередь, вместо того,
чтобы передать его напрямую передающему кольцу. Это сни-
жает вероятность беспорядка в очередности следования паке-
тов. Затем операционная система переходит к п. 8.3.

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

8.3.	Если очередь исходящих пакетов полностью заполнена, пакет
игнорируется. Счетчик игнорированных пакетов увеличивается,
и обработка прерывания заканчивается.

Внимание!

На этапе 8 передачи пакета система IOS, прежде чем поместить коммутированный
пакет в кольцо передачи, проверяет очередь исходящих пакетов. Это уменьшает ве-
роятность разупорядочивания пакетов. Как может пакет изменить порядок передачи,
если его коммутация осуществляется сразу же при его получении? Рассмотрим сле-
дующий пример.

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

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

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

Этап 9. Если коммутация пакета была осуществлена процессом, пакет поме-
щается в выходную очередь. Если свободного места в очереди не на-
ходится, пакет игнорируется. При этом увеличивается счетчик игно-
рированных выходных пакетов.

Этап 10. Система IOS пытается найти свободный дескриптор. Если таковой
существует, операционная система извлекает пакет из очереди и свя-
зывает буфер пакета с кольцом передачи. Если же свободных деск-
рипторов нет (кольцо полностью заполнено), система IOS оставляет
пакет в очереди до тех пор, пока контроллер интерфейса не передаст
пакет из кольца и не освободит дескриптор.

Этап 11. Передающий интерфейс периодически опрашивает кольцо передачи
на предмет нахождения в нем пакетов. Как только контроллер обна-
руживает пакет, он передает его на линию передачи и генерирует
процессору прерывание передачи.
Этап 12. Операционная система IOS обрабатывает прерывание передачи, вы-
свобождает буфер из кольца передачи И возвращает его в соответст-
вующий пуй. ЗаТеЙ система IOS проверяет очередь исходящих паке-
тов интерфейса. Если в ней есть пакеты, система извлекает очеред-
ной пакет из очереди и связывает его с кольцом передачи. На этом
обработка прерывания передачи завершается.

Резюме

В данной главе мы рассмотрели работу операционной системы IOS на маршрути-
заторах Cisco с разделяемой памятью. Под данную категорию попадают маршрутиза-
торы серии 2500, которых на сегодняшний день насчитывается более миллиона. Мы
рассмотрели, как система IOS разделяет память на области и как осуществляется
коммутация пакетов.

Резюме

85
Ключевые темы этой глаяы - •*. , г , * * 'as *
 Принципы аппаратного построения устройств AGS+

4 а'

‘;*ш	п	!

- г-.	. ъ .	' ••

_> ,»'* • -	.
Глава

4

Первые машрутизаторы
с шинюи СЬиз

В главе 2 “Дринципы коммутации пакетов” рассказывалось об изменениях в про-
граммной реализации IOS (Internetwork Operation System — межсетевая операционная сис-
. тема), внесенныхдля повышений скорости коммутации. Не останавливаясь только на
программных усовершенствования?; корпорация Cisco создает собственные специализиро-
ванные аппаратные решения, направленные на увеличение скорости коммутации. Первым
примером данной тенденции явилось создание в начале 1990-х годов шины Cbus, исполь-
зованной в Маршрутизаторах серии|А€>8+, а затем в маршрутизаторах Cisco серии 7000.
: Несмотря на то что маршрутизаторы указанного класса являются устаревшими и не под-
держиваются последними версиями операционной системы 1OS, значительная часть кон-
структивных новшеств в рамках разработки аппаратных средств была применена в мар-
шрутизатора Cisco серии 7500,- Широко-Используемых в настояшее время. В данной главе
описываются маршрутизаторы серий 7000 и серверы AGS+, поскольку значительная часть
специфических средств коммутации маршрутизаторов серии 7500 возникла на основе кон-
структивных улучшений системы ЮЗ, разработанных для устройств серии 7000.

Аппаратные принципы создания
маршрутизаторов AGS+

R.-	4W

Маршрутизаторы серии AGS+ Иэто обычные AGS-Маршрутизаторы с большим коли-
чеством функций. Устройства AGS (без знака +) базировались на процессоре Motorola се-
рии 68000 (М68к) и использовали интерфейсные модули доступа к разделяемой среде пе-
редачи данных, присоединенные к относительно медленной шине Multibus со скоростью
доступа 155 Мбит/с? Из-за ограниченной скорости обработки данных указанным процес-
сором и невысокой пропускной способности шины Multibus скорость коммутации не мо-
_ жет быть более — 7000—14000 пакетов в секунду (packets per second — pps). Даже при ис-
пользовании механизма быстрой коммутации скорость обработки пакетов гораздо ниже
современных скоростей коммутации, поэтому в определенных ситуациях даже маршрути-
заторы Cisco 2500 могут обеспечивать большую производительность.

Маршрутизаторй 'АСЗ-!- и серии 7000 были разработаны до появления высокоско-
ростных комттьютерных2шин и мощных процессоров, основанных на RISC-
технологий: Во время разработки маршрутизаторов AGS+ на рынке присутствовал
лишь небольшой выбор готовых аппаратных компонентов, поэтому разработчики
компании Cisco ^шили проблему увеличения скорости коммутации, создав высоко-
скоростную шину данных и механизм коммутации пакетов. Так появилась шина Cbus.
Первоначально шина Cbus (название возникло от сокращенного написания-Cisco
bus) являлась 32-битовой и работала ж ласфге 16,67 Мйш Врезультате общая ско-
рость передачи данных составляла 533 мбит/с, что значительно (больше чем в 3,5
раза) превосходила скорость передачи данных по шине Multibus. Шина Cbus состояла
из 32 бит данных, из которых 24 бита выделено на адреса и 8 — управляющие биты.

Механизм коммутации пакетов шины Cbus основывался на 16-битовом микропро-
цессоре с величиной командного слова 80 бит. Такой размер слова позволял выпол-
нять одновременно несколько операций за один такт. В отличие от процессоров об-
щего назначения, таких как М68к, процессор шины Cbus имел небольшой, узкоспе-
циализированный набор инструкций, разработанный специально для обеспечения
операций коммутации. Процессор устанавливался в специальный интерфейсный мо-
дуль, содержащий также память для процессорных команд (управляющая память, или
control store), быструю память для хранения пакетов (fast packet memory) и интерфей-
сы для шин Cbus и Multibus. Модуль, содержащий механизм коммутации, называется
контроллером шины Cbus (Cbus controller).

AGS+ маршрутизаторы были созданы на основе устройств AGS с добавлением
двух новых элементов: шины и контроллера шины. На рис. 4.1 изображена внутрен-
няя структура AGS+.

Рис. 4.1. Внутренняя структура маршрутизатора AGS+

Подробное описание основных компонентов, представленных на рис. 4.1, приве-
дено ниже.
	Процессор (CPU) — устройство, которое обеспечивает работу системы IOS и
выполняет программную быструю коммутацию для интерфейсов шин Multibus.
Кроме того, процессор также осуществляет быструю коммутацию пакетов, по-
лученных от шины Cbus, которые не могут быть обработаны автономно.

	Основная память — обычно память типа DRAM, в которой размещается выпол-
няемый образ операционной системы IOS, данные и системные буферы для
хранения пакетов.

	Multibus — шина данных, обеспечивающая связь процессора с интерфейсными
модулями Multibus. Контроллер шины Cbus также подсоединен к шине Mutlibus.

	Процессор коммутации шины Cbus (Cbus switching processor) — устройство, обес-
печивающее быструю коммутацию пакетов между интерфейсами Cbus посред-
ством исполнения собственного оптимизированного микрокода, не относяще-
гося, собственно, к самой системе IOS. Описанный процессор расположен в
модуле контроллера шины Cbus.

	Быстрая пакетная память — высокоскоростная двунаправленная память, находя-
щаяся в контроллере шины Cbus, которая используется для обмена данными ме-
жду контроллером шины Cbus и интерфейсными модулями. Быстрая пакетная
память предназначена для хранения пакетов, полученных или передаваемых на
интерфейсы Cbus. В спецификации шины Cbus такая память называется MEMD.

	Шипа Cbus — разработанная корпорацией Cisco шина данных, соединяющая
контроллер шины Cbus с интерфейсными модулями шины Cbus.

Внимание!

Процессор шины Cbus, память MEMD и устройство управления шиной Cbus находятся
в одном модуле, который называется контроллером шины Cbus, или модулем CBUSII.
Поэтому сам по себе процессор шины Cbus иногда называется процессором модуля
CBUSH. Термин процессор коммутации шины Cbus (Cbus Switching Processor) не
следует путать с процессором коммутации (Switching Processor) маршрутизаторов се-
рии С7000.

Устройства AGS+ унаследовали в своей структуре и процессор серии Motoria
68000, и заднюю панель маршрутизатора AGS с шиной Multibus. Изменения, связан-
ные с шиной Cbus, затронули пять интерфейсных модулей, которые -были перестрое-
ны для подключения к указанной шине. Такое усовершенствование позволило ис-
пользовать как старые интерфейсные модули шины Multibus, так и новые интерфейс-
ные модули шины Cbus, которые могут быть установлены на одно и то же шасси.

Наряду со структурными изменениями и новыми аппаратными решениями в мар-
шрутизаторах AGS+ необходима программная поддержка конструктивных элементов.
Позже мы рассмотрим, как операционная система IOS использует рассмотренные
выше усовершенствования.

Коммутация пакетов на шине Cbus

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

Шина Cbus и контроллер, обеспечивают альтернативный режим обработки пакетов
маршрутизаторами AGS+. Вместо коммутации с помощью главного процессора под
управлением операционной системы IQS значительная часть пакетов может быть обра-
ботана с использованием только контроллера шины Cbus без обращения к ресурсам
главного процессора. Контроллер шины Cbus способен выполнять быструю коммутацию
автономно с помощью своего внутреннего коммутационного процессора в- том случае,
если и передающий, и приемный интерфейсы находятся в модуле шины Cbus. Возмож-
ность переключения пакетов лишь средствами коммутационного процессора шины Cbus
породила новый вид коммутации, по праву названный автономной коммутацией.

Автономная коммутация

По сути автономная и быстрая коммутации работают одинаково, разница состоит
лишь в том, какой процессор используется. Так же как и в методе быстрой коммута-
ции, появление пакета на интерфейсе вызывает прерывание, но при автономной
коммутации данное прерывание относится к коммутационному процессору шины
Cbus, кроме того, оба указанных метода переключения пакетов роднит использование
быстрой памяти для хранения пакетов (так называемой быстрый кэш). Действитель-
но, для своего быстрого кэша автономная коммутация использует ту же самую струк-
туру хеш-таблицы (hash table), что и системы IOS до версии 10.2 включительно. В
процессе работы программной коммутации операционная система 1OS управляет как
главным быстрым кэшем, так и кэшем локального коммутационного процессора. При
каждом добавлении и удалении записи из главного кэша соответствующая запись
также добавляется или удаляется из кэша шины Cbus.

Однако автономная коммутация имеет отличия от Выстрой: она поддерживает
меньшее количество протоколов, чем быстрая коммутация, может работать только с
протоколами IP, IPX и туннельным протоколом, а также по-иному обрабатывает си-
туацию отсутствия записи в кэше данных.

При бйСТрой коммутации, если НаКет получен и для него Нет соответствующей за-
писи в быстром кэше, то он сразу же ставится в очередь программной коммутации. В
случае автономной коммутации, если для пакета нет соответствующей записи в кэше
шины Cbus, то он посылается главному процессору для быстрой коммутации данного
пакета. Если пакет адресован другому интерфейсу шины Cbus, то главный процессор
может его быстро переключить в соответствующий интерфейс, пока пакет все еще на-
ходится внутри контроллера шины Cbus. Если же пакет адресован модулю, который
подключен к шине Multibus, то он должен быть полностью скопирован в системный
буфер посредством медленной шины Multibus и только потом уже программно комму-
тирован. Хотя контроллер шины Cbus и имеет доступ к интерфейсу шины Multibus,
но использовать его для автономной коммутации пакетов не может.

Быстрая пакетная память шины Cbus

В конструкции контроллера шины Cbus была представлена новая стратегия буфери-
зации пакетов, которая и по сей день используется в маршрутизаторах Cisco серии 7500.
В маршрутизаторах серии AGS+ программная и быстрая коммутации используют сис-
темные буферы для хранения пакетов, как описано в главе 1 “Введение в структуру
операционной системы 1OS”. Однако такие системные буферы в случае автономной
коммутации Имеют существенный недостаток: они выделяются в основной памяти мо-
дуля главного процессора, что делает ее недоступной для модулей интерфейса Cbus.
Чтобы обеспечить модули интерфейсов шины Cbus пакетными буферами, компа-
ния Cisco разработала контроллер1 шины Cbus таким образом, что он содержит ло-
кальную выделенную пакетную память. Память, получившая название MEMD, пред-
ставляет собой область объемом 512 Кбайт, доступную как для процессора коммута-
ции, так и для модулей интерфейсов шины Cbus. Первые 8 Кбайт памяти MEMD (так
называемая граница страницы, или page zero) выделены для управляющих структур
памяти, а остальные 504 Кбайт используются в качестве пакетной памяти. 

Память MEMD

Вас может заинтересовать, откуда появилось название MEMD. Несмотря на господ-
ствующее мнение, MEMD — это не название какого-либо особенного типа памяти, а
лишь тер|л|1|ц которым компания Cisco обозначает класс памяти, используемый в
маршрутизаторах, содержащих шйну Cbus. MEMD — Ьто обычная статическая память
SRAM, используемая для буферизации пакетов, приходящих из интерфейсов шины
Cbus или направляемых в них.

Термин MEMD произошел от сокращения слова память (memory) плюс буква D латин-
ского алфавита, обозначающая четвертый класс памяти шины Cbus. Существуют и
другие классы памяти шины Cbus, используемые в маршрутизаторах серии, AGS+.
Как, например, МЕМА — память для хранения автономного кэша и глобальных указа-
телей, используемых процессором коммутации. *

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

Буферы для хранения пакетов группируются максимум в четыре пула, причем ка-
ждый пул содержит буферы только одного размера, и далее могут быть выделены для
использования интерфейсами. Из-за ограниченного размера памяти MEMD и соот-
ветственно области управляющей структуры, находящейся на границе страницы, мак-
симальное число пакетных буферов не может быть больше 470, независимо от коли-
чества интерфейсов, подключенных к шине Cbus.

На границе страницы памяти MEMD содержится информация, с помощью кото-
рой процессор коммутации управляет очередями прирма и передачи для каждого ин-
терфейса шины Cbus. По своим функциям очереди приема и передачи похожи на
входную и выходную очереди операционной системы IOS. Когда интерфейс на шине
Cbus определяет входящий пакет, он выделяет буфер в памяти MEMD из пула соот-
ветствующего размера, копирует данные пакета в буфер и помещает буфер в очередь
приема процессора коммутации. При автономной коммутации пакета коммутацион-
ный процессор переключает его и помещает измененные данные в очередь передачи
именно на тот интерфейс шины Cbus, которому был адресован входящий пакет. В
случае коммутации пакета методом быстрой коммутации главны») процессор обраба-
тывает его и направляет процессору коммутации для помещения пакета в соответст-
вующую передающую очередь шины Cbus. Если пакету суждено быть переключенным
программно, то процессор коммутации копирует его в память главного процессора
через шину Multibus, затем возвращает MEMD-буфер в исходный пул.

Коммутационный процессор также управляет счетчиками и предельными значе-
ниями для каждой из очередей передачи и приема. Чтобы предотвратить заполнение
пакетами из одного интерфейса всего объема памяти MEMD, каждая очередь приема
характеризуется предельным значением очереди приема (RQL), а каждая очередь переда-
чи — предельным значением очереди передачи (TQL).
Значение RQL определяет максимально возможное количество пакетных буферов,
которые в любой момент времени могут находиться в очереди приема. При достижении
максимального размера очередь приема считается полном и все последующие приходя-
щие на такой интерфейс пакеты будут игнорироваться до тех пор, пока размер очереди
будет оставаться максимальным. Аналогично, величина TQL определяет максимальное
число пакетов, которые могут находиться в очереди передачи в любой момент времени.
Все последующие пакеты, направленные на интерфейс с заполненной до предела очере-
дью передачи, будут уничтожаться до момента уменьшения размера очереди.

В главе 6 “Маршрутизаторы Cisco 7500” вы найдете более детальное описание
счетчиков памяти MEMD и процесса освобождения буферов.

Маршрутизаторы серии Cisco 7000

Маршрутизаторы серии 7000 представляют собой следующий шаг эволюции уст-
ройств AGS и структуры шины Cbus. Кроме механической структуры и внешнего вида
маршрутизаторы Cisco 7000 практически ничем не отличаются от своих предшествен-
ников — маршрутизаторов серии AGS+. Существенным различием является отказ от
использования шины Multibus и ее интерфейсных модулей. В маршрутизаторах серии
7000 поддерживаются только интерфейсы шины Cbus.

Некоторые изменения структуры являются сугубо формальными. Например, в мар-
шрутизаторах серии 7000 модуль процессора маршрутизации (Route Processor — RP) и
модуль процессора коммутации (Switching Processor — SP) заменяют соответственно мо-
дули процессора AGS+ и контроллера шины Cbus, присутствовавшие в устройствах се-
рии AGS+. В то же время процессоры SP и RP сохранили в своем составе микропроцес-
соры, которые присутствовали у их предшественников. Хотя в составе маршрутизаторов
серии 7000 И отсутствует шина Multibus, однако, по существу, процессор коммутации SP
все еще присоединен к главному процессору и RP посредством 155-Мбитовой шины
класса Multibus. Поэтому внутренняя схожесть конструкций позволяет программному
обеспечению операционной системы 1OS и микрокодам процессора коммутации рабо-
тать в маршрутизаторах серии 7000 без внесения значительных изменений.

С другой стороны, в маршрутизаторах серии 7000 появилась отсутствовавшая в
устройствах серии AGS+ аппаратная возможность — интерфейсные модули с
"горячей заменой”. Маршрутизаторы серии 7000 позволяют вставлять или вынимать
интерфейсные модули шины Cbus (в маршрутизаторах серии 7000 интерфейсные мо-
дули получили название интерфейсных процессоров, или interface processors) без пере-
загрузки системы 1OS и с минимальными искажениями работы других интерфейсных
процессоров. Когда операционная система IOS замечает, что модуль вставлен или
удален, она моментально приостанавливает операции на шине Cbus на время замены
интерфейса. После завершения такой операции система IOS возобновляет работу ши-
ны Cbus и продолжает коммутацию пакетов с момента остановки.

Возможность “горячей замены” интерфейсных модулей также внесла необходимость
изменения работы микрокода процессора коммутации. В устройствах класса AGS+ во
время работы системы 1OS количество интерфейсов постоянно, а в маршрутизаторах се-
рии 7000 может меняться “на лету”. Именно поэтому исходные коды процессора ком-
мутации в маршрутизаторах серии AGS+ были разработаны с учетом того, что буферы в
памяти MEMD выделяются статически во время инициализации устройства. В маршру-
тизаторах серии 7000 при каждой операции добавления или удаления модуля интерфей-
са микрокод предусматривает изменение размещения буферов. Данная операция позво-
ляет процессору коммутации наиболее эффективно управлять ресурсами памяти для
хранения пакетов даже в случае изменения числа интерфейсов в процессе работы.
Резюме . 	‘X '

Архитектура маршрутизаторов серий 7000 и AGS+ явилась основой для создания
новых устройств с шиной Cbus. Если принять во внимание тот факт, что внутренняя
структура маршрутизаторов Cisco изменилась, то знание ранних систем полезно, по-
скольку многие из сегодняшних технологий коммутации базируются на технологиях
ранних моделей маршрутизаторов.

В главе 5 “Распределенные системы” рассмотрены новейшие аппаратные решения
маршрутизаторов Cisco.

Резюме

93

Глава

5

елейные системы

Все рассмотренные ранее системы буферизации имеют одно общее свойство: они
выделяют пулы буферов’различного размера, а потом выделяют для каждого пакета свой
собственный буфер ^ Подобные типы буферов называют непрерывными (contiguous
buffers), потомуЙто каждый тфкет находится внутри собственного отдельного буфера в
непрерывной области памяти. Для разделения памяти на отдельные буферы использует-
ся один из двух способов^илй ргВмер буфера выбирается исходя из наибольшего разме-
ра пайётармли размер бу<Йра выбирается фиксированным по определенному закону.

Непрерывными буферами легче^управлять, но они не всегда обеспечивают наибо-
{ёлее эффективное использование‘памяти. Потери памяти в схемах с непрерывной бу-
й феризацией !могут быгЬ связаны с тем, что размер буфера значительно больше сред-
\ него размер» пакета,1гили. с неравномерным использованием буферов. Для примера
рассмотрим схему разделения’ памяти. MEMD для шины Cbus. В схеме данного типа
J г размер .создаваемых интерфейсных буферов равен установленной для интерфейса ве-
личине параметра MTU, т.е. максимально возможной величине пакета. Если средний

у размер получаемого пакета значительно, меньше, чем величина установленного значе-
S; ния MTU, большая часть пространства памяти пакетного буфера не используется.

Например, пусть величина параметра'MTU интерфейса равна 4 Кбайт, а средний
“ размер большинства (90 процентов) пакетов меньше 1 Кбайт, тогда 75 процентов па-
;; мяти, выделенной для хранения Пакётбв; не используется 90 процентов времени!

' В операционной системе 1OS версий 11.1СА был предложен новый способ выде-
’ ления памяти — распределенная буферизация (particle buffering), — разработанный для
’ устранения недостатков непрерывнойЕбуферизации. Несмотря на то что указанный
метод не поддерживается всеми платформами, распределенная буферизация использу-
ется в маршрутизаторах Cisco серий 2600, 3600, 7500 V1P и 7200, а также в маршрути-
заторах серий 7100 и 6400 NRP, созданных на основе моделей 7200. В данной главе
описана распределенная буферизация и подробно рассмотрено ее использование на
одной из поддерживаемых платформ — маршрутизаторах Cisco серии 7200.

Управление фрагментарным буфером

Для управления пакетной памятью распределенная буферизация использует подход
“рассеяния-сборки” (“scatter-gather”). При распределенной буферизации вместо выделения
непрерывной протяженной области памяти используются прерывистые (dis-contiguous,
обычно называемые распределенными) участки памяти, называемые фрагментами. После
коммутации всё пакеты собираются воедино, формируя один логический буфер, который
называется распределенный буфер (particle buffer). При использований распределенного под-
хода один пакет может быть распределен по нескольким буферам.
Связанные воедино одиночные фрагменты образуют распределенный буфер. Для -
каждого пришедшего в интерфейс пакета создается распределенный буфер (более де-
тально процесс данного алгоритма будет описан в примере для маршрутизатора Cisco
серии 7200). Указанный метод отличается от метода непрерывной буферизации тем,
что состоящий из нескольких фрагментов пакет нужно собрать в одно целое непо-
средственно перед его обработкой. Вследствие того что данные хранятся в распреде-
ленном виде, в данном методе нет предопределенных наборов буферов, используемых
в методе непрерывных буферов. Таким образом, возникает вопрос, откуда операцион-
ная система 1OS знает, сколько и каких фрагментов нужно использовать для работы с
каждым пакетом? Система IQS управляет несколькими пулами фрагментов и при по-
лучении пакетов использует данные фрагменты для создания распределенных буфе-
ров. Фрагменты являются “кирпичиками”, а распределенные буферы — “строитель-
ными блоками” памяти для хранения пакетов.

В пределах определенного пула все фрагменты имеют один и тот же фиксирован-
ный размер. Поэтому любой фрагмент в каждом определенном пуле может использо-
ваться без указания его размера. Одинаковый размер фрагмента внутри пула упрощает
процесс управления и помогает эффективно управлять памятью. В системе 1OS раз-
мер фрагментов меняется от платформы к платформе, однако каждой серии обычно
присущ основной размер. Как будет показано ниже, бывают и исключения — некото-
рые платформы могут иметь пулы с иными размерами фрагментов, но обычно всегда
существует преобладающий размер фрагментов. Размер выбирается таким образом,
чтобы фрагмент мог содержать пакет среднего размера и чтобы потеря памяти при
хранении пакета была минимальна. Стандартный размер фрагмента — 512 байт, по-
этому большинство распределенных буферов может состоять из одного фрагмента.
Для большего понимания принципов работы с распределенными буферами рассмот-
рим пример, приведенный на рис. 5.1. Пусть в рассматриваемом примере существует
всего один фрагментарный пул и все распределенные буферы созданы на его основе.

Рис. 5.1. Пример использования фрагментов

Пусть размер фрагментов в едином пуле равен 512 байт и в данный момент време-
ни в пуле существует всего 3 свободных фрагмента: фрагмент 1, фрагмент 2 и фраг-
мент 3, помеченные как Ф1, Ф2 и ФЗ соответственно. Теперь проследим за этапами
обработки системой 1OS пакета размером 1200 байт.
	Этап 1. Операционная система 1OS находит первый свободный фрагмент (Ф1) и на-
чинает копировать в него данные. В первый фрагмент копируются первые 512 байт.

	Этап 2. После заполнения первого фрагмента система 1OS переходит к сле-
дующему фрагменту (Ф2), связывает его логически с Ф1 и продолжает копиро-
вать данные пакета во второй фрагмент. Так копируются следующие 512 байт.

	Этап 3. После заполнения второго фрагмента все еще остается 176 байт данных
пакета. Поэтому система 1OS переходит к следующему свободному фрагменту
(ФЗ), связывает его с Ф2 и копирует оставшиеся 176 байт в последний фрагмент.

Таким образом, операционная система IOS копирует 1200-байтовый пакет в 3 уча-
стка памяти (фрагмента), которые, являются логическими составляющими одного
фрагментарного пакетного буфера, ...

Фрагментарные буферы в действительности состоят не только из областей памяти,
которые содержат данные пакета. Избыточное количество памяти (в виде дополни-
тельных компонентов) используется для хранения информации о пакете, как, напри-
мер, информация о том, как логически связаны разбросанные участки памяти. На
рис. 5.2 показаны компоненты распределенного буфера и их взаимосвязь.

Рис. 5.2. Компоненты распределенного буфера

Каждый распределенный буфер содержит заголовок пакета, который связан с од-
ним или более фрагментами. Сам фрагмент состоит из заголовка фрагмента и связан-
ного с ним блока данных фрагмента (particle data block). Детальное описание компо-
нентов распределенного буфера приведено ниже.

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

	Заголовок фрагмента — это управляющий блок, который содержит ссылки на
блок данных фрагмента и на следующий фрагмент, составляющий буфер (если
такой существует). Также заголовок фрагмента содержит и другую информа-
цию, например количество байт в блоке данных и пул, которому принадлежит
данный фрагмент.

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

Для управления пулами фрагментов операционная система 1OS исполвзует те же
подходы, что и для управления непрерывными пакетными буферами в. системах с раз-
деляемым доступом к памяти. Система 1OS создает локальный1 статический фрагмен-
тарный пул для каждого интерфейса, а потом создает общий динамический пул;..на-
зываемый. мортальным пулом. К нормальному пулу имеют доступ все интерфейсы и
процессw.i.B iaflyfiae. заполнения всех фрагментов в локальных пулах нормальный пул
используется как дополнительная область памяти.	. .с

В большинстве, систем создается еще один пул из маленьких 128-^айтовых(фраг-
ментов, который называется пулом быстрой коммутации (fast switching pool). Пул бы-
строй коммутации используется в случае необходимости добавления данных в начало
пакета, например, когда к пакету нужно присоединить заголовок большего размера,
чем исходный. Чтобы добавить данные в начало пакета, операционная система 1OS
дрлжйа вставить новый фрагмент в начало распределенного буфера, после того как
его части логически связаны. В связи с небольшим размером добавляемых данных
используются фрагменты из пула быстрой коммутации.

В примере 5.1 показана информация, выводимая командой show buffers. Приведен-
ный результат содержит информацию об общих и о локальных буферах; созданных
системой 1OS. Пул быстрой коммутации помечен символом F/S.

[ Пример 5.1. Использование команды show buffers для прлунения имформацйи.
(•,,,• \ • ... об общих и о локал ьных,буферах.^,

Router-7200#show buffers

Public particle pools:

P/S buffers, 128 bytes (total 512, permanent 512):

0 in free list(0 min, 512 max allowed)

512 hits, 0 misses

512 max cache size, 512 in cache

Normal buffers, 512 bytes (total 1024, permanent 1024):

1024 in free list (512 min, 2048 max allowed)
. . . 0 hits,. (0 misses, 0 trims, 0 created

0 failures (0 no memory)

Private particle pools:

FastEthernetO/O buffers, 512 bytes (total 400, permanent 400):
0 in free list(0 min, 400 max allowed)

400 hits, 0 misses

400 max cache size, 271 in cache
Ethernetl/0 buffers,. 512 bytes (tgtal 128 permanent 128) : ,,,
0 in free list‘.(0 min, 128 max allowed)

128 hits, 0 fallbacks

>	12-8max cache size, 64 in cache

Ethernetl/1. buffers» 512 bytes (total 128 permanent 128):

0 in.free list(0 min, 128 max allowed)

128,hits, 0 fallbacks

128 max cache size, 64 in cache

1 Иногда также называемый приватным, поскольку пул принадлежит определенному интерфейсу. —
Прим, перев.
Слияние фрагментов

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

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

По своей сути слияние — это последовательное копирование содержимого всех
фрагментов в один непрерывный буфер соответствующего размера. В зависимости от
платформы данный процесс выполняется или главным процессором, или отдельным
модулем с прямым доступом к памяти (Direct Memory Access — DMA). Процесс слия-
ния осуществляется в четыре этапа, которые приведены ниже.

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

	Этап 2. Система 1OS копирует данные из каждого фрагмента пакета в новый
непрерывный буфер.

	Этап 3. Операционная система освобождает все фрагменты и возвращает их в
исходный пул.

	Этап 4. В завершение система 1OS разъединяет заголовок пакета и освобожден-
ные фрагменты и присоединяет его к новому непрерывному буферу.

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

Для понимания того, как распределенные буферы используются в операционной сис-
теме IOS, необходимо рассмотреть пример их реализации. В следующем разделе приведен
пример использования фрагментарных пакетных буферов в маршрутизаторах Cisco 7200.
Именно для данной серии устройств впервые начали использоваться фрагменты.

Маршрутизаторы серии 7200

Маршрутизаторы серии 7200 были первыми устройствами Cisco, использующими шину
PCI, ставшую в настоящее время промышленным стандартом. Данные маршрутизаторы
имеют модульную структуру, которая использует заменяемые интерфейсы доступа к среде
передачи данных, называемые модулями портов (port adapters), и сменный основной про-
цессор, называемый сетевым операционным модулем (Network Processing Engine — NPE).

Существует много конфигураций маршрутизаторов серии 7200, которые основаны
на комбинациях моделей шасси и различных модулях NPE. Количество разъемов и
тип установленной материнской платы2 различаются в зависимости от модели шасси.

2В терминологии Cisco встречаются 3 термина: frontaplane, midplane, backplane. Первый термин
обозначает переднюю панель, последний — заднюю панель и кабельные разъемы. Второй термин
На момент написания данной книги существовали 2 модели материнских плат дл$
устройств серии 7200, которые перечислены ниже.	'  '

	Базовая материнская плата содержит две шины PCI, работающие на частоте 25
МГц. Каждая шина присоединена к половине установленных на шасси разъемов.
Данный тип материнских плат поддерживает все модули NPE кроме N РЕ-300.

	Плата VXR содержит две двухскоростные шины PCI, которые могут работать на
частотах 25 или 50 МГц. Каждая шина присоединена к половине разъемов, ус-
тайбвленных на'шасси. На плате ййхойится устройство мультиплексора с разде-
лением по времени (time division multiplexing — TDM) с двумя выделенными
линиями связи, которые называются сменными многофункциональными контак-
тами (Multiservice Interchange Connections), для каждого из разъемов. Данный
тип материнских плат первоначально разрабатывался для работы с модулями
NPE-300, но он также поддерживает все остальные устройства типа NPE.

Шасси для маршрутизаторов серии 7200 реализуются в комплекте с двумя, че-
тырьмя и шестью разъемами. Ниже описаны возможные конфигурации шасси для
устройств 7200.

	Модель 7202 — шасси с двумя разъемами, используемое в некоторых специаль-
ных приложениях. Маршрутизаторы с данным типом шасси имеют исходную ма-
теринскую плату с частотой 25 МГц и поддерживают только модуль NPE-150.

	Модель 7204 — шасси с четырьмя разъемами и базовой материнской платой.

	Модель 7206 — шасси с шестью разъемами и материнской платой VXR.

	Модель 7204VXR — шасси с четырьмя разъемами и материнской платой VXR.

	Модель 7206VXR — шасси с шестью разъемами и материнской платой VXR.

Для маршрутизаторов серии 7200 было разработано несколько вариантов модулей NPE,
все функций которого определяются MIPS-совместимым процессором; Большинство мо-
дулей (за исключением нескольких) такого типа являются взаимозаменяемыми. Например,
шасси с двумя разъемами поддерживает модули версии NPE-150, а NPE-ЗОО поддержива-
ется только в шасси с материнской платой VXR. Каждый тип модуля NPE отличается
только скоростью процессора и типом встроенной памяти, что подробно описано ниже.

	NPE-100 — первый NPE-модуль для маршрутизаторов серии 7200; работающий
на частоте 100 МГц и содержащий процессор с соответствующей Частотой
VR4700-100 и память DRAM (без памяти типа SRAM).

	Модуль NPE-150 — содержит работающий на частоте 150 МГц процессор VR4700-150.
Память DRAM используется в качестве основной памяти, а устройства хранения
типа DRAM и SRAM — в качестве памяти для хранения пакетов.

	Модуль NPE-175 — содержит работающий на частоте 200 МГц процессор
RM 5270-200 с унифицированным кэшем объемом 2 Мбййт, В" 1фче<тве*0СноВН(Й)
памяти и памяти для хранения пакетов используется устройство Типа SDRAM.

	Модуль NPE-200 — содержит работающий на частоте 200 МГц процессор
VR5000-200. Память типа DRAM используется в качестве основной, а устройст-
ва типа DRAM и SRAM — как память для хранения пакетов.

	Модул£ NPE-225 — содержит работающий на частоте 262 МГц процессор RM5271-262
с унифицированным кэшем объемом 2 Мбайт. В качестве основной памяти и памя-
ти для хранения пакетов используется устройство хранения типа SDRAM.

описывает то, что находится внутри корпуса. А поскольку в данную панель вставляется модуль
процессора, то наилучший аналог — это материнская плата обычного компьютера.
	Модуль NPE-300 — содержит работающий на частоте 300 МГц процессор
RM7000-300 и два независимых.банка памяти SDRAM. Для улучшения произ-
водительности данный модуль имеет два различных контроллера шины памяти
PCI, которые предоставляют однрвременный доступ к SDRAM-памяти с двух
различных модулей портов. Кроме того, устройство NРЕ-300 может работать на
шинах PCI на частоте 50 МГц и требует наличия материнской платы VXR.

Аппаратное устройство маршрутизаторов 7200

Аппаратная структура маршрутизаторов серии 7200 меняется от модели к модели и
зависит от комбинации шасси и модулей NPE. В общем случае структура может быть
разделена на две основные части: маршрутизаторы с базовой материнской платой и
ранними типами устройств NPE (NPE-100, NPE-150, NPE-200) и маршрутизаторы с
материнской платой VXR и модулями NPE-300. На рис. 5.3 представлены компонен-
ты маршрутизаторов серии 7200 для конструкций с базовой материнской платой, а
именно — маршрутизатор 7206 с модулем NРЕ-150.

Рис. 5.3. Структура маршрутизаторов Cisco серии 7200 с базовой материнской платой

Функции компонентов устройств серии 7200, приведенных на рис. 5.3, подробно
описаны ниже.

	Модуль NPE содержит основную память, процессор, память шины PCI
(устройство типа SRAM, за исключением модуля NРЕ-100, который использует
память DRAM) и управляющую схему шин PCI. Как было описано выше, в ба-
зовых материнских платах поддерживаются почти все модели устройств NPE,
совместимые с исходной материнской платой, за исключением NPE-300.

	Шина PCI. В маршрутизаторах серии 7200 используются три шины PCI: PCI 0, PCI
1 и PCI 2. Шины PCI 1 и PCI 2 физически расположены между модулем NPE и ма-
теринской платой и соединяют модули портов с находящимися в устройстве NPE
процессором и памятью. Шина PCI 0 — это отдельная шина, соединяющая модули
портов и разъемы PCMCIA контроллера ввода-вывода с находящимися в модуле
NPE процессором и памятью. Шины PCI О, PCI 1 и PCI 2 работают на частоте 25
МГц, что обеспечивает пропускную способность каждой из них до 80S Мбит/с.

	Шина ввода-вывода — эта шина соединяет все устройства, не работающие с
шиной PCI (консольный и AUX-порт, память NVRAM, загрузчики ^ROM и
^Jash) с процессором модуля NPE..	;

	.—,'это модульные контроллеры интерфейса, содержащие, кольца
передачи и приема пакетов из физической среды передачи данньц. Точно такие
же модули портов используются в VIP-процессорах маршрутизаторрв Cisco се-
рии 7 5 Об.'Обе платформы поддерживают большинство модуле^’портов,за'ред-
ким исключением устройств, специфичных для платформ.	,

	Контроллер ввода-вывода обеспечивает подключение к консольному устройству,
порту модема AUX, памяти NVRAM, загрузчикам ROM и Flash и встроенному
контроллеру интерфейса, а также к интерфейсам Ethernet или Fast Ethernet.
Посредством шины РС1 0 контроллер ввода-вывода обеспечивает доступ к мо-
дулям Flash-памяти, находящимся внутри модуля PCMCIA.

На рис. 5.4 показана аппаратная структура маршрутизатора Cisco 7200VXR. В дан-
ном примере рассмотрены шасси 7206VXR и NPE-300.

Рис. 5.4. Элементы структуры маршрутизатора Cisco 7200VXR

На рис. 5.4 приведены элементы аппаратной схемы маршрутизатора Cisco
7200VXR, которые подробно описаны ниже.

	Сетевой операционный модуль (NPE) — содержит основную память, процессор,
память шины РС1 и схему управления шиной PCI. Устройство NPE-300 содержит
два контроллера шины PCI и два независимых банка памяти SDRAM, которые
используются как для основной памяти, так и для динамической пакетной.
	Шина PCI. В маршрутизаторах серии 7200VXR присутствуют три разновидно-
сти шины PCI: PCI О, PCI 1 и PCI 2. Шины PCI 1 и PCI 2 расположены между
модулем NPE и материнской платой и соединяют модули портов с находящи-
мися в устройстве NPE процессором и памятью. Шина PCI 0 — это отдельная
шина, соединяющая модули портов и разъемов или устройств PCMCIA кон-
троллера ввода-вывода с находящимися в модуле NPE процессором и памятью.
Шина PCI 0 работает на частоте 25 МГц. В том случае, если установлен модуль
NPE, способный работать на частоте 50 МГц (как в данном примере NPE-300),
то шины PCI 1 и PCI 2 работают на частоте 50 МГц, в противном случае дан-
ные шины будут работать на частоте 25 МГц. :

	TDM-коммутатор. Материнская плата содержит мультиплексор с разделением
времени (TDM).c двумя выделенными соединениями к каждому слоту шасси.
TDM-коммутатор обеспечивает взаимодействие модулей портов, которые име-
ют TDM-интерфейсы.

	Шина ввода-вывода — соединяет все устройства, которые не работают с шиной
PCI (порт консольного устройства, AUX-порт, память NVRAM, загрузчики
ROM и Flash), с находящимся в модуле NPE процессором.

	Модули портов — обычно это точно такие же карты, которые используются в
обычных маршрутизаторах 7200 (не VXR), за исключением тех, которые требу-
ют коммутатора TDM и поэтому могут быть установлены только на моделях
7200VXR. Конфигурация модели 7200VXR поддерживает адаптеры портов, ко-
торые работают с шиной PCI как на частоте 25 МГц, так и 50 МГц; несогласо-
ванность скорости шины разрешается на материнской плате.

	Контроллер ввода-вывода обеспечивает подключение к консольному порту, ши-
не AUX, памяти NVRAM, загрузчикам ROM и Flash и встроенному контролле-
ру интерфейса, а также к интерфейсам Ethernet или Fast Ethernet. Контроллер
ввода-вывода также обеспечивает доступ к модулям Flash-памяти в разъеме
карт PCMCIA посредством шины PCI 0.

Память

В зависимости от модели устройства NPE маршрутизаторы серии 7200 используют па-
мять типа DRAM, SDRAM и SRAM в различных комбинациях. Три пула памяти делят
всю доступную память на следующие области: стандартный пул памяти процессора, пул
ввода-вывода и пул PCI (в случае использования модуля N РЕ-300 используются два пула
ввода-вывода — I/O и I/O-2). В примере 5.2 показан результат выполнения команды show
memory, который содержит информацию обо всех приведенных выше пулах. Первая часть
примера предоставляет информацию о распределении памяти для маршрутизатора с моду-
лем N РЕ-200, вторая часть — результат выполнения команды для устройства N РЕ-300.

.. ————ч; --------------------------------------------------------1

Пример 5.2. Пример использования команды show memory для получения	,• ;

ин^рмащии 0ЛУлах ламяти Для маршрутизаторов серии 7Д00,, г»«i

router-NPE-200#show

memory

	Head	Total(b)	Used(b)
Processor	61BEBC60	96551840	7287388
I/O	7800000	8388608	901616
PCI	48000000	4194304	993276
router-NPE	-300#show	memory	
	Head	Total(b)	Used(b)
Processor	612A02A0	106298720	7408336
I/O	20000000	33554432	3604696
I/O-2	7800000	8388608	35608'

Free(b) Lowest(b) Largest(b)

89264452	88777932	88547216
7486992	7463324	7480508
3201028	2227180	2702716
Free(b)	Lowest(b)	Largest(b)
98890384	98748252	98836460
29949736	29925740	29949692
8553000	8353000	8352956
На рис. 5.5 показаны пулы памяти, приведенные в примере 5.2, и принцип выде-
ления свободной памяти при использовании двух различных модулей NPE.

Модуль NPE-200

МодульЫРЕ:300
~i/O-2(PCI)

DRAM Процессор

SDRAM 0 Процессор

I/O

SRAM PCI

SDRAM 1 I/O

Рис. 5.5. Типы памяти

Как операционная система IOS распределяет доступную память между разными
пулами, описано ниже.

Память процессора

Пул памяти процессора используется для хранения кода операционной системы
IOS, общих структур данных (таких как таблицы маршрутизации) и системных буфе-
ров. Данная область выделяется из памяти DRAM для модулей NPE-100, NPE-150 и
NPE-200 или памяти SDRAM для устройств NPE-175 и NPE-225; или из нулевого
банка памяти SDRAM для NPE-300.

Память ввода-вывода

Пул памяти ввода-вывода используется для фрагментарных пулов и из него выде-
ляются как локальные фрагментарные пулы интерфейсов, так и обший пул, называе-
мый нормальным. Для платформ с устройствами NPE-100, NPE-150 и NPE-200 такой
пул создается в памяти DRAM, так что его основное предназначение — это выделение
локальных (иногда называемых приватными) фрагментарных пулов для более медлен-
ных по скорости интерфейсов. Размер памяти ввода-вывода зависит от общего объема
памяти DRAM, доступной в NPE. Например, в модуле NPE-150 объем и распределе-
ние памяти ввода-вывода определяются по совокупности правил, приведенных ниже.

	Если модуль NPE-150 содержит всего 16 Мбайт памяти DRAM, то для памяти
ввода-вывода выделяется 4 Мбайт.

	Если модуль NPE-150 содержит от 24 до 48 Мбайт памяти DRAM, из них для
памяти ввода-вывода выделяется 6 Мбайт.
	Если модуль NPE-150 содержит более 48 Мбайт памяти DRAM, то для памяти
ввода-вывода выделяется 8 Мбайт.

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

В устройствах NPE-300 пул памяти ввода-вывода создается на основе первого бан-
ка памяти SDRAM, и его размер устанавливается равным 32 Мбайт. Для такого моду-
ля все локальные фрагментарные пулы интерфейсов создаются в памяти ввода-
вывода, независимо от скорости среды передачи данных.

Память шины PCI

Пул памяти шины PCI используется для передающих и приемных колец интер-
фейсов. В некоторых случаях для высокоскоростных интерфейсов пул шины PCI ис-
пользуется для выделения памяти под локальные фрагментарные пулы интерфейсов.
В случае использования модулей NPE-175, NPE-225 и NPE-300 такой пул создается в
области памяти SDRAM. В случае использования устройств NPE-150 и NPE-200 пул
PCI-памяти полностью создается в области SRAM.

Обычно пул памяти шины PCI очень мал. Как видно из примера 5.2, модуль NPE-
200 содержит только 4 Мбайт PCI-памяти, а модуль NPE-300 — около 8 Мбайт, обо-
значенной как I/O-2.

Коммутация пакетов

в маршрутизаторах Cisco серии 7200

Маршрутизаторы серии 7200 поддерживают программную коммутацию, быструю
коммутацию и быструю пересылку корпорации Cisco (CEF), однако не поддерживают
ни одну из форм распределенной коммутации. Все задачи коммутации выполняет
процессор, установленный в модуле NPE.

Этап получения пакета

Процесс получения пакета проиллюстрирован на рис. 5.6.

Этап 1. Пакет из среды передачи данных копируется в ряд фрагментов, логиче-
ски связанных с приемным кольцом интерфейса. Фрагменты могут рас-
полагаться как в памяти ввода-вывода, так и в памяти шины PCI, что за-
висит от платформы и скорости среды передачи данных интерфейса.

Этап 2. Интерфейс отправляет прерывание процессору.

Этап 3. Операционная система IOS подтверждает прерывание и начинает по-
иск фрагментов для замены заполненных участков в приемном кольце
интерфейса. Сначала система 1OS проверяет локальный пул интерфей-
са и, если он заполнен до отказа, проверяет общий нормальный пул.
При недостаточном числе свободных фрагментов для сохранения ин-
формации из приемного кольца пакет уничтожается (при этом все за-
полненные фрагменты приемного кольца очищаются) и значение счет-
чика “переполнение буфера" (no buffer) увеличивается на единицу.

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

Этап 4. Сначала операционная система IOS связывает воедино фрагменты,
которые составляют пакет, а потом логически привязывает к нему
фрагменты заголовка. Далее система заполняет приемное кольцо
маркированными фрагментами, связывая заполненные участки.

Входная
очередь

Выходная
очередь

Кэш
маршрутов

Основная память

Память
процессору

1

Модуль Модуль Модуль

порта 3

порта 5

порта 1

Пул

Память I/O

Сетевой операционный модуль

2

Рис. 5.6. Процесс получения пакета

Этап коммутации пакета

После того как пакет разбит на фрагменты, операционная система IOS приступает
к его коммутации. Последовательность данного процесса приведена на рис. 5.7 и под-
робно описана в следующем ниже списке.

Этап 5. Сначала программный код коммутации проверяет кэш маршрутов
(быстрый кэш или CEF), для того чтобы определить, может ли пакет быть
переключен с помощью какого-либо из алгоритмов быстрой коммутации.
Если возможно коммутировать пакет во время обработки прерывания, то
происходит переход на этап 6, в противном случае операционная система
подготавливает пакет к программной коммутации.

5.1.	Пакет объединяется в один непрерывный буфер (системный). Ес-
ли свободные системные буферы для размещения пакета отсутст-
вуют, он уничтожается и значение счетчика переполнения буфера
увеличивается, что можно увидеть в информации, выводимой ко-
мандой show interface.
Рис. 5.7. Коммутация пакета

Router# show interface

Ethernet2/1 is up, line protocol is up

Output queue 0/40? 0 drops; input queue 0/75, 0 drops

5 minute input rate 5000 Data/sec, 11 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

1903171 packets input, 114715570 bytes, 1 no buffer

Received 1901319 broadcasts, 0 runts, 0 giants, 1 throttles

Когда операционная система IOS не может выделить буфер для слияния
фрагментов пакета, интерфейс подавляется и увеличивается, значение
счетчика подавления (throttles), как показано в приведенном выше приме-
ре использования команды show interface. Весь входной трафик при этом
игнорируется, и такое положение дел сохраняется до тех пор, пока опера-
ционная система IOS не освободит системные буферы интерфейса.

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

рывание приема.

5.3.	Предположим, что мы работаем с IP-пакетом. Когда в таком слу-
чае запускается служба IP Input, он обращается к таблице мар-
шрутизации и определяет выходной интерфейс. Далее служба
проверяет таблицы, связанные с выходным интерфейсом, и нахо-
дит соответствующий МАС-заголовок, который помещается в на-
чало пакета (что не показано на рис.5.7).

5.4.	В случае успешной коммутации пакет копируется в исходящую
очередь выходного интерфейса.

5.5.	Начиная с этого момента система 1OS переходит к этапу передачи.

Этап 6. Программный код коммутации (быстрая или CEF-коммутация) операци-
онной системы IOS заменяет в МАС-заголовке пакета адрес получателя
(что не показано на рис. 5.7). Если новый МАС-заголовок больше исход-
ного, то система IOS выделяет новый фрагмент из пула быстрой комму-
тации и вставляет его в начале цепочки фрагментов, составляющих пакет,
чтобы разместить больший заголовок.

Этап передачи пакета

На данном этапе мы имеем коммутированный пакет, МАС-заголовок которого из-
менен соответствующим образом. На рис. 5.8 показано, что происходит дальше.

Рис. 5.8. Передача пакета

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

Этап передачи пакета: быстрая и экспресс-коммутация

В приведенном ниже списке описаны основные этапы передачи пакета для быст-
рой коммутации.

Этап 7. Сначала операционная система IOS проверяет выходную очередь интер-
фейса. Если данная,очередь не пуста или передаюшая цепь интерфейса
заполнена, то полученное прерывание сбрасывается и пакет помешается
в исходящую очередь. Даже если интерфейс в данный момент обрабаты-
вает другой программно-коммутированный пакет или запрашивает пре-
рывание на передачу данных, то пришедший пакет все равно будет по-
ставлен в очередь. Если выходная очередь пуста и в передающей цепи
имеется свободная память, система IOS переходит к этапу 8.

Этап 8. Система IOS связывает фрагменты пакета с передающей цепью интер-
фейса и освобождает полученное прерывание.

Этап 9. Контроллер интерфейса опрашивает передающий интерфейс и опреде-
ляет новый пакет для передачи.
9taff 10» , КОйфЬллер. интерфейса копирует пакет из передающей1цепи в среду й
' л. вызывает прерывание контроллера.	,	-

Этап 11. IOS подтверждает передающее прерывание и очищает все составляющие
пакет фрагменты, потом возвращает освобожденные фрагменты в ис-
ходные фрагментарные пулы.

Этап 12. Если какие-то пакеты все еще ожидают своей очереди на передачу
(например, если исходящая очередь была до сих пор заполнена), то IOS
убирает Пакеты из очереди и связывает соответствующие им фрагменты
с передающей цепью, чтобы контроллер интерфейса мог увидеть осво-
божденные фрагменты (не показан на рис. 5.8).

Этап 13. IOS освобождает передающее прерывание.

Этап передачи пакета: программная коммутация

В данном разделе описаны этапы передачи пакета в случае программной коммута-
ции (на рис. 5.8 они не показаны).

Этап 14. Система IOS проверяет размер следующего пакета в исходящей очереди
и сравнивает его со свободной памятью в передающей цепи. Если сво-
бодного места достаточно, то 1OS удаляет пакет из исходящей очереди и
связывает его непрерывный пакет (или фрагменты) с передающей це-
пью. Нужно заметить, что если в исходящей очереди стоит несколько
пакетов, то IOS попытается перевести все пакеты из очереди в интер-
фейсную передающую цепь.

Этап 15. Контроллер интерфейса опрашивает передающий интерфейс и замечает
новый пакет для передачи.

Этап 16. Контроллер интерфейса копирует пакет из передающей цепи в среду и
вызывает прерывание контроллера.

Этап 17. Система 1OS подтверждает передающее прерывание и освобождает не-
прерывный буфер (или фрагменты), составляющий пакет, возвращая ос-
вобожденный буфер (или фрагмент) в исходный пул.

Резюме

Фрагментарная буферизация обеспечивает эффективный способ буферизации па-
кетов с минимальными потерями памяти. Начиная с операционной системы IOS вер-
сии 11.1 фрагментарная буферизация фактически становится основной схемой буфе-
ризации маршрутизаторов Cisco; в настоящее время разрабатываются новые устройст-
ва, которые используют аналогичную технологию.

Резюме

109

лЧл»|. ’МНЙ&'’	’		ь.-'и..	1<1Г> rj'ili 4

Маршрутизаторы Cisco 7500

Платформа маршрутизаторов Cisco 7500 была анонсирована в 1995 году и предназначе-
на для высокоэффективной .тларшрутизации в условиях непрерывного роста Internet, а
также для промышленныхтгриложений, критичных к пропускной способности сети.
Структура маршрутизаторов серии 7500 обеспечивает значительно большую производи-
тельность по. сравнению сгболее-ранними маршрутизаторами, такими как Advansed Gate-
way Server+(AGS+, или расширенный сервер маршрутизации), и серией устройств Cisco
7000, несмотря на тот,факт,, что является производной от них. Данная глава посвящена ап-
i паратному созданию маршрутизаторов;серии 7500; специфическим для них деталям реали-
зации средств коммутации в межсетевой операционной системе (IOS), а также архитектуре
Versatile Interface Processors (VIPs —'многоцелевой интерфейсный процессор).

-	М	чЩ, И  “W4

Ап паратная структура
маршрутизатора-Cisco 7500

На рис. 6.1 представлена блок-схема верхнего уровня структуры маршрутизатора серии
7500. Как видно из рисунка, ключевыми для понимания уникальных особенностей межсе-
тевой операционной системы (IOS) маршрутизаторов серии 7500 являются два компонен-

те. 6.1. Структура маршрутизатора серии 7500
Шина данных

Шина данных маршрутизатора серии 7500, как и у его предшественников (сервера
AGS+ и маршрутизатора Cisco 7000), основана на оригинальной архитектуре Cbus1. Шина
Cbus, используемая в Cisco 7500, называется Су Bus и является более быстрым вариантом
шины Cbus маршрутизаторов серии 7000 (Cbus 7000 часто называют CxBus). Как и перво-
начальные варианты Cbus, шина CyBus является 32-битовой с 32 линиями передачи дан-
ных, 8 линиями передачи команд, 24 линиями передачи адреса, а также с другими линия-
\ ми, которые используются для , управления, как, например, для осуществления доступа к
шине, подтверждения успешных транзакций и передачи сообщений об ошибках.

Может показаться, что всего лишь 32 линии передачи данных — это слишком мало
по сравнению с другими современными шинами, отдельные из которых используют 128
и более линий данных. Тем не менее было выбрано именно такое количество линий, и,
как следствие, старые процессоры с интерфейсом CxBus также смогут работать, если их
подключить к CyBus. Новые процессоры с интерфейсом CyBus способны отрабатывать
две транзакции (чтение двух 4-байтовых слов) за один такт шины (60 нс/16,67 МГц),
тогда как процессоры шины CxBus могут выполнять только одну транзакцию (чтение
одного 4-байтового слова) за один такт. В результате шина CyBus обеспечивает пропу-
скную способность 1,066 Гбит/с (64 битах1б,б7 МГц), что соответствует удвоенной про-
пускной способности шины CxBus — 533 Мбит/с (32 битах16,б7 МГц).

Внимание!

При использовании комбинации процессороа с интерфейсами CyBus и CxBus на шине
CyBus процессор с интерфейсом CyBus может использовать полную пропускную спо-
собность 1,066 Гбит/с. Процессор с интерфейсом CxBus ограничится использованием
533 Мбит/с из полной пропускной способности.

Существует четыре различные модели маршрутизаторов семейства 7500.

	Маршрутизатор Cisco 7505 — одинарная CyBus-шина, пять слотов, из них один
RSP-слот (или слот процессора маршрутизации-коммутации).

	Маршрутизатор Cisco 7507 — двойная шина CyBus, семь слотов, в том числе два
RSP-слота.

	Маршрутизатор Cisco 7513 — двойная CyBus-шина, 13 слотов, в том числе два
RSP-слота.

	Маршрутизатор Cisco 7576 — два независимых маршрутизатора 7500 в одном
корпусе, каждый с двойной шиной CyBus.

Номер модели маршрутизатора 7500 может быть определен с помощью команды
show environment all, выполненной с консоли маршрутизатора. В примере 6.1 показан
результат выполнения этой команды для маршрутизаторов моделей 7505 и 7507.

Пример 6.1. Результат выполнения команды show environment all на консоли^ „.^’'”'’'1
маршрутизатора’'	, :

7505#show environment all

Arbiter type 1, backplane type 7505 (id 1)

7507#show environment all

Arbiter type 1, backplane type 7507 (id 4)

1 Буквально С — шина. — Прим, перев.
Процессор коммутации-
маршрутизации

Процессор коммутации-маршрутизации, часто называемый RSP, централизованно
выполняет как функции коммутации, так и маршрутизации (приятный сюрприз,
правда!). Процессор RSP считается “сердцем" маршрутизаторов серии 7500, поскольку
он принимает решения по коммутации, выполняет задания, связанные с протоколами
маршрутизации, а также обеспечивает различные функции поддержки.

Процессор RSP по существу эквивалентен комбинации процессора маршрутизации
RP (Route Processor) и процессора коммутации SP (Switch Processor), которые исполь-
зуются в устройствах серии Cisco 7000. Комбинация процессоров RP и SP на одной
плате позволяет избавиться от относительно медленной шины Multibus2 (с пропуск-
ной способностью 155 Мбит/с), которая используется в маршрутизаторах серий 7000 и
AGS+ для соединения RP- и SP-подсистем. Данный факт является одной из причин,
почему процессор RSP так существенно опережает по производительности комбина-
цию процессоров RP и SP.

В табл. 6.1 приведены различные типы процессоров RSP, которые поддерживаются
серией Cisco 7500.

Таблица 6.1. Типы процессоров RSP для маршрутизаторов серии 7500

Процессор RSP Характеристики

RSP1	Процессор R4600 или R4700 архитектуры MIPS; интерфейс к одинарной

шине CyBus; может использоваться только в модели 7505; максимум
128 Мбайт памяти DRAM3; 2 Мбайт памяти MEMD

RSP2	Процессор R4600 или R4700 архитектуры MIPS; интерфейс к двойной ши-

не CyBus; может использоваться в моделях 7505, 7507, 7513 и 7576; мак-
симум 128 Мбайт памяти DRAM; 2 Мбайт памяти MEMD

RSP4	Процессор R5000 архитектуры MIPS; интерфейс к двойной шине CyBus;

может использоваться в моделях 7507, 7513 и 7576; максимум 256 Мбайт
DRAM; 2 Мбайт MEMD

RSP8	Процессор MIPS R7000; интерфейс к двойной шине CyBus; может исполь-

зоваться в моделях 7507, 7513 и 7576; максимум 256 Мбайт памяти ЕСС
DRAM; 8 Мбайт памяти MEMD

Тип RSP-процессора, который инсталлирован в маршрутизаторе серии 7500, может
быть определен с помощью команды show version, как показано в примере 6.2.

[пример 6.2. Определение типа процессора RSP в маршрутизаторе серии7500 j
router#show version

Cisco RSP2 (R4700) processor with 32768K/2072K bytes of memory.

R4700 CPU at lOOMhz, Implementation 33, Rev 1.0

2 Буквально многоцелевая шина. — Прим, перев.

3Dynamic random access memory — динамическое оперативное запоминающее устройство. — Прим, перев.
На рис. 6.2 приведена функциональная схема устройства RSP.

Главную роль в работе межсетевой операционной системы (Internetwork .Operating
System — IOS) маршрутизаторов серии 7500 (в частности, в процессе коммутации) иг-
рают три приведенных ниже компонента.	< и

	Центральный процессор (CPU).

	Быстрая пакетная память (Fast Packet Memory), которая выделена в памяти MEMD.

	Основная память (Main memory), которая выделена в DRAM.

Детально эти компоненты описаны в следующих разделах.

Рис. 6.2. Процессор коммутации-маршрутизации

Центральный процессор (CPU)

Центральный процессор (или CPU) подсистемы процессора RSP — это основной
процессор маршрутизатора 7500; он отвечает за работу операционной системы (IOS) и
коммутацию пакетов. В отличие от архитектур серии 7000 и AGS+ здесь нет отдель-
ного микрокода коммутации пакетов (SP-микрокод, или микрокод контроллера Cbus);
за исключением распределенной коммутации все решения по коммутации в маршру-
тизаторе 7500 принимает система 1OS, которая выполняется на центральном процес-
соре модуля RSP. В модуле RSP используются процессоры со структурой MIPS, кото-
рые созданы на сокрашенном наборе команд (RISC); тактовая частота, объем и тип
кэш-памяти зависят от модели устройства.

Быстрая пакетная память

Процессоры RSP1, RSP2 и RSP4 содержат банк памяти SDRAM объемом 2Мбайт,
специально выделенной под пакетные буферы; RSP8 имеет 8 Мбайт SDRAM-памяти,
отведенной под пакетные буферы. Эта область быстрой пакетной памяти также называ-
ется MEMD, как и соответствующая область в устройствах Cisco 7000 и сервере AGS+.
Область памяти MEMD маршрутизаторов серии 7500 доступна как центральному про-
цессору RSP, так и интерфейсным процессорам (через шину CyBus); оба указанных ти-
па устройств имеют прямой доступ к данной области памяти как к разделяемому ресур-
су. Несмотря на то что область MEMD разбита на пулы буферов, которые используются
в алгоритме, аналогичном работающему в маршрутизаторах Cisco 7000, аппаратные от-
личия позволяют внести некоторые полезные усовершенствования. Как, например, в
маршрутизаторе 7500 память может быть разбита на 3520 буферов, что является значи-
тельным Улучшением по сравнению с устройством серии 7000, для которого 470 буферов
являются пределом. Полное описание алгоритма распределения памяти выходит за рам-
ки данной книги, поэтому рассмотрим его упрощенный вариант.

Этап 1. Сетевые интерфейсы маршрутизатора классифицируются по группам с
различным параметром MTU4. Диапазон разброса значений MTU, кото-
рые попадают в каждую группу, первоначально устанавливается равным
256 байтам. Если получается больше четырех групп, разброс увеличивает-
ся до 512 байт. Если вее еще остается больше четырех Групп, То разброс
значений параметра MTU каждой группы снова удваивается и так до тех
пор, пока не будет сформйровано максимум четыре группы.

Этап 2 Каждый из буферных пулов, выделенных на этапе 1, получает 20 процен-
тов (360 Кбайт) памяти MEMD, а оставшаяся память MEMD делится ме-
жду пулами в соответствии с суммарной пропускной способностью всех
сетевых интерфейсов, которые включены в данный пул.

Для иллюстрации процедуры рассмотрим маршрутизатор, который имеет пять се-
тевых интерфейсов с перечисленными ниже величинами параметра MTU.

	512 байт.

	1024 байт.

	1500 байт.

	4096 байт.

	16000 байт.

Операционная система IOS начинает работу с определения пяти пакетных буфер-
ных пулов, которые описаны подробнее ниже.

	Пул А — набор буферов размером 512 байт, которые обслуживают интерфейсы
с параметром MTU в диапазоне 266 <MTU<512 байт.

	Пул В — набор буферов размером 1024 байта, которые обслуживают интерфей-
сы с параметром MTU в диапазоне 768 <MTU<1024 байт.

	Пул С — набор буферов размером 1500 байт, обслуживающих интерфейсы с па-
раметром MTU в диапазоне 1244 <MTUsi500 байт.

	Пул D — набор буферов размером 4096 байт, обслуживающих интерфейсы с
параметром MTU в диапазоне 3840 <MTU<4096 байт.

	Пул Е — набор буферов размером 16000 байт, которые обслуживают интерфей-
сы с параметром MTU в диапазоне 15744 <MTUs 16000 байт.

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

	Пул А — буферы размером 512 байт; обслуживающие интерфейсы с MTU в
диапазоне 0 <МТ1К512 байт.

	Пул В — буферы размером 1500 байт, обслуживающие интерфейсы с MTU в
диапазоне 988 <MTU<1500 байт.

	Пул С — буферы размером 4096 байт, обслуживающие интерфейсы с MTU в
диапазоне 3584 <MTU<4096 байт.

	Пул D — буферы размером 16000 байт, обслуживающие интерфейсы с MTU в
диапазоне 15488 <MTU£16000 байт.

* MTU (Maximum Transfer Unit) — максимально возможное количество данных, которое может пе-
редаваться сетевым интерфейсом как одна непрерывная единица. — Прим, перев.
Теперь все пять интерфейсов распределены между четырьмя пулами. Обратите
внимание, что пул В в данном случае обслуживает интерфейсы с MTU размерами
1024 и 1500 байт.

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

После определения размеров пулов операционная система IOS разбивает память
MEMD на пять частей, содержащих по 20 процентов всей доступной памяти. Каждый
из четырех пулов получает по одной части, а оставшаяся часть делится между пулами
исходя из типов и скоростей интерфейсов, соответствующих определенному пулу.
Существуют некоторые дополнительные затраты памяти MEMD, связанные с управ-
ляющими структурами, — например, часть памяти MEMD зарезервирована для взаи-
модействия центрального процессора (CPU) и интерфейсных процессоров; таким об-
разом, не все 2 Мбайт памяти MEMD доступны для пакетных буферов.

В предыдущем примере мы для простоты предполагали, что размеры буферов, вы-
деляемых в памяти MEMD, равны значениям параметра MTU соответствующих бу-
ферных пулов, однако на практике буферы выделяются несколько большего размера,
чем максимальная величина MTU, которой соответствует данный пул. Буферы в па-
мяти MEMD должны иметь достаточный размер для содержания данных объемом, со-
ответствующим максимальной величине параметра MTU данного пула, также необхо-
димо, чтобы оставалось место для добавления заголовка инкапсуляции. Кроме того,
размер буфера в памяти MEMD должен быть кратным 32 байтам, что необходимо для
выравнивания положения буфера в аппаратной кэш-памяти, чтобы обеспечить мак-
симальную производительность. В результате размер памяти, выделяемой в области
MEMD под буферы, определяется по формуле: размер = mtu + е + п, где mtu — мак-
симальная величина параметра MTU; е— максимальная величина заголовка для ин-
капсуляции, который может добавляться соответствующими интерфейсами;' п — коли-
чество байт заполнения (0—31) для обеспечения кратности значения 32 байтам.

Выделение буферов в памяти MEMD
и неиспользуемые сетевые интерфейсы

При определении размеров пулов алгоритм выделения буферов в памяти MEMD
не учитывает состояния сетевого интерфейса (включен он или выключен5). Буферы
выделяются неиспользуемым и административно выключенным интерфейсам так, как
если бы они были включены и работали с полной нагрузкой. Основная причина та-
кого решения заключается в том, что административно выключенные интерфейсы
могут быть включены позже и все равно потребуют выделения ресурсов памяти
MEMD. Так как неиспользуемые сетевые интерфейсы приводят к неоптимальному
распределению памяти MEMD под буферы, то наилучшим вариантом будет по воз-
можности отключить все неиспользуемые интерфейсные процессоры, чтобы обеспе-
чить активные сетевые интерфейсы максимально возможным количеством памяти.

Ресурсы памяти MEMD используются наиболее эффективно, если все сетевые ин-
терфейсы сконфигурированы с одинаковым значением параметра MTU (обычно это
1500 байт). В таком случае алгоритм выделения буферов создает только один буфер-
ный пул, который используется совместно всеми сетевыми интерфейсами.

Команда show controller cbus позволяет увидеть состояние структур, которые управ-
ляют распределением памяти MEMD, и посмотреть, как распределена память MEMD,

5 В английском языке соответственно up or down. — Прим, перев.
что является очень важной информацией для поиска неисправностей. В примере 6.3
показана часть результата выполнения данной команды с пояснением наиболее инте-
ресных параметров.

(Пример 6.3. Результат выполнения команды show controller output
routertfshow controller cbus.

MEMD at 40000000, 2097152 bytes (unused 2976, recarves 4, lost 0)
RawQ 48000100, ReturnQ 48000108, EventQ 48000110

BufhdrQ 48000128 (2939 items), LovltrQ 48000140 (11 items, 2016 bytes)
IpcbufQ 48000150 (16 items, 4096 bytes)
IpcbufQ_classic 48000148 (8 items, 4096 bytes)
3570 buffer headers (48002000 - 4800FF10)
poolO: 9 buffers, 256 bytes, queue 48000130
pooll: 278 buffers, 1536 bytes, queue 48000138
poo!2: 305 buffers, 4544 bytes, queue 48000158
poo!3: 4 buffers, 4576 bytes, queue 48000160
slotl: EIP, hw 1.5, sw 20.06, ccb 5800FF30, cmdq 48000088, vps 4096
software loaded from system

Ethernetl/0, addr 00e0.8f6d.a820 (bia 00e0.8f6d.a820)
gfreeq 48000138, Ifreeq 48000168 (1536 bytes), throttled 015
rxlo 4, rxhi 101, rxcurr 0, maxrxcurr 1 txq 48000170, txacc 48000082
(value 49), txlimit 50

	MEMD at 40000000, 2097152 bytes (unused 2976, recarves 4, lost 0). Данная строка
означает, что память MEMD начинается с адреса 0x40000000 в адресном про-
странстве центрального процессора (CPU) и имеет объем 2 Мбайт. Значение поля
unused (или неиспользованная) показывает объем неиспользованной памяти в
байтах, который обычно небольшой (меньше самого большого значения парамет-
ра MTU). Поле recarves показывает, сколько раз алгоритм распределения памяти
MEMD выполнялся операционной системой IOS. Необходимость в перераспре-
делении памяти MEMD может возникать в нескольких ситуациях, как, например,
подключение новой сетевой платы, изменение значения параметра MTU для се-
тевого интерфейса, перезагрузка микрокода. Значение этого параметра устанавли-
вается равным 1 при инициализации операционной системы IOS, когда алгоритм
распределения памяти MEMD запускается в первый раз.

	RawQ 48000100, ReturnQ 48000108, EventQ 48000110

BufhdrQ 48000128 (2939 items), LovltrQ 48000140 (11 items, 2016 bytes)

IpcbufQ 8000150 (16 items, 4096 bytes)

IpcbufQ_classic 48000148 (8 items, 4096 bytes). Эти строки показывают адреса
структур данных, которые являются внутренними для Очередей в памяти
MEMD. Структуры данных представляют собой списки буферов в памяти
MEMD (точнее, заголовков буферов, описанных в следующем пункте), часть
данных из которых используется в обработке пакетов. Наиболее интересная
очередь — RawQ6. Более детально RawQ описана ниже, в разделе, посвященном
коммутации пакетов. Здесь лишь скажем, что в нее ставятся пакеты, которые
принимаются интерфейсными процессорами и направляются на обработку цен-
тральным процессором устройства RSP.

	3570 buffer headers (48002000 — 4800ffl0). Строка, показывающая общее количе-
ство заголовков буферов в памяти MEMD. Заголовок буфера в памяти MEMD —
это управляющая структура, содержащая данные о буфере в памяти MEMD, и

6 Буквально — очередь необработанных данных. — Прим перев.
Рис. 6.3. Структура буферных заго-
ловков

указатель на сами данные буфера (рис. 6.3). Каждый MEMD-буфер имеет евой
уникальный заголовок. Заголовки буферов можно сравнить с метками на
крышках консервных банок, которые позволяют узнать, что находится внутри,
без необходимости открывать банку. Точно так же и заголовок позволяет очень
удобным способом реализовать передачу информации о пакетнык буферах
внутри операционной системы IOS без необходимости пересылать данные,.са-
мих буферов. В модуле RSP всего может быть 3570 буферных заголовков.

	рооЮ: 9 buffers, 256 bytes, queue 48000130

pooll: 278 buffers, 1536 bytes, queue 48000138
pool2: 305 buffers, 4544 bytes, queue 48000158
poo!3: 4 buffers, 4576 bytes, queue 48000160.

Данные строки показывают, как распределены
2Мбайт доступной памяти MEMD. Первый
(рооЮ), а также последний (роо!3 в данном
примере) буферные пулы зарезервированы для
взаимодействия процессов интерфейсов, цен-
трального процессора (CPU) и процессора
коммутации-маршрутизации, а два других пула;
pooll и роо12, выделены под пакетные буферы.
Пакеты размещаются в буферах памяти MEMD
в соответствии с сетевым интерфейсом, из ко-
торого они получены, а не на основании разме-
ра пакета. Например, если пакет размером
64 байта приходит из интерфейса, параметр
MTU которого равен 1500 байт (размер
MEMD-буфера 1536 байт), то он будет хра-
ниться в 1536-байтовом буфере, даже если име-
ется пул с буферами меньшего размера.

Если пакет приходит в интерфейс и нет доступных MEMD-буферов в пуле данного
интерфейса, то пакет аннулируется, а счетчик числа аннулированных (ignore) пакетов
данного интерфейса увеличивается на единицу. Такая ситуация возникает, даже ес-
ли имеются свободные буферы в других пулах. Установка одинакового значения па-
раметра MTU для всех интерфейсов приводит к тому, что MEMD-буферы разме-
шаются в одном пуле и соответственно уменьшается вероятность аннулирования
пакета из-за отсутствия свободных буферов в пуле отдельного интерфейса.

	slotl: EIP, hw 1.5, sw .06, ccb 58001130, cmdq 48000088, vps 4096 software loaded from
system. Строка содержит данные об, интерфейсном процессоре в слоте 1. Анало-
гичная строка информации выводится для каждого слота, в котором работает ин-
терфейсный процессор. В слоте 1 (slotl) работает интерфейсный процессор Ether-
net (Ethernet interface processor— EIP), который имеет аппаратную версию
(hardware version — hw) равную 1.5, а версию программного обеспечения (software
version — sw) равную .06. Параметры cmdq и ccb — это адреса структур данных,
которые используются для взаимодействия с устройством RSP.

	Ethemetl/0, addr 00e0.8f6d.a820 (bia 00e0.8f6d.a820)

gfreeq 48000170, Ifreeq 48000082 (1536 bytes), throttled 015

rxlo 4, rxcurr 0, maxrxcurr 1

txq 48000170, txacc 48000082 (value 49), txlimit 50. Информация о каждом се-
тевом интерфейсе, включая указатели на соответствующие им структуры дан-
ных в памяти MEMD.

/
	gfreeq. Данный параметр содержит указатель7 * 9 на глобальную очередь свободных буфе-
ров (global free queue). Глобальная очередь свободных буферов — это список всех
свободных буферов в памяти MEMD, относящихся к одному определенному пулу.
Все сетевые интерфейсы, относящиеся к одному пулу, имеют общую очередь сво-
бодных буферов и соответственно одинаковое значение данного указателя.

	Ifreeq. Данный параметр является указателем на локальную очередь свободных буферов
(local free queue) для рассматриваемого интерфейса. Наряду с глобальным для дан-
ного пула списком свободных MEMD-буфероВ каждый отдельный интерфейс мо-
жет поддерживать свой локальный список, буферов, полученных из глобальной оче-
реди. Все свободные буферы первоначально находятся в общ^й очереди свободных
буферов. Как только интерфейс получил' буфер из* глобальной очереди, он может
удержать его в своей локальной очереди свободных буферов'на протяжении некото-
рого времени, что позволяет предотвратить отбрасывание приходящих на интерфейс
пакетов в том случае, когда перегруженные интерфейсы “конкурируют” за свободные
буферы в глобальном списке. Неиспользуемые свободные буферы из локальных оче-
редей периодически возвращаются в глобальный список свободных буферов.

	rxhi*. Данный параметр показывает максимальное количество MEMD-буферов,
которые интерфейс может удерживать в локальной очереди свободных буферов.
Данный порог предотвращает возможность использования всех свободных бу-
феров одним интерфейсом за счет “обделения” других.

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

	maxrxcurr. Параметр показывает максимальное чйслО буферов, которые данный
интерфейс когда либо удерживал со времени последнего перераспределения
памяти (данный параметр часто Называют ‘'high water mark’” — буквально озна-
чает уровень прилива). Значение данного параметра не может быть больше, чем
величина параметра rxhi.

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

	txq*. Параметр содержит указатель на список буферов, содержащих пакеты, ко-
торые ждут передачи данным интерфейсом. Этот список называется очередью
передачи, а данный параметр — указателем очереди передачи.

	txlimit. Параметр показывает максимальное число буферов, которое может со-
держаться в очереди передачи данного интерфейса в любой момент времени.
Число в скобках, указанное перед данным параметром, — это количество остав-
шихся свободных мест в очереди передачи. В примере 6.3 число в скобках — 49, а
значение txlimit — 50. Это означает, что один пакет поставлен в очередь пере-
дачи данного интерфейса. Значение параметра в скобках, равное нулю, означа-
ет, что больше ни один пакет не может быть поставлен в очередь передачи, по-
ка какой-нибудь из пакетов в очереди Не будет удален.

7 Указатель является адресом в памяти MEMD, которому соответствует начало списка. — Прим, перев.

г гх — аббревиатура am receive (прием). В сетевой терминологии обычно используется для указания
всего, что связана с приемом пакетов сетевым интерфейсом. В данном случае-свободные буферы испо-
льзуются для хранения данных, которые принимаются сетевым интефейсом. — Прим, перев.

9 tx — сокращение от transmit (передача). В сетевой терминологии употребляется для указания
связи с передачей данных сетевым интерфейсом.
Основная память

Основная память в процессоре коммутаций-маршрутизации может содержать
до 128 Мбайт (256 Мбайт для RSP4 и RSP8) расширяемой динамической оперативной
памяти (DRAM). Обычно память DRAM используется в модуле RSP для хранения
выполняемого кода операционной системы 1OS и структур данных, которыми 1OS
пользуется во время выполнения. В примере 6.4 показан результат вывода команды
show memory summary для маршрутизатора Ciscd 7500.

Пример 6.4. Результат выполнения команды show memory summary для
'	маршрутизатора Cisco 7500	г 1 ч

router# show memory summary

	Head	Total(b)	Used(b)	Free(b)	Lowest(b)	Largest(b)
Processor	60AD9EE0	55730464	9405352	46325112	45891060	46251636
Fast	60AB9EE0	131072	82168	48904	48904	48860

Из рассмотренного примера видно, что операционная система 1OS разбивает основную
память процессора коммугации-1-маршрутизации (RSP) на два пула: пул процессорной памяти
(processor) и пул быстрой памяти (fast).‘.Пул быстрой памяти используется для хранения ин-
терфейсных структур данных/: которые называются блоками интерфейсных дескрипторов.
Процессорный пул служит для хранения выполняемых инструкций, данных, управляющих
структур, таблиц перенапрандения;данных (forwarding tables), системных пакетных буферов и
куч (heap). Небольшой объем пула быстрой памяти не является ограничивающим фактором,
так как если объем блоков интерфейсных дескрипторов превышает объем пула быстрой па-
мяти, то система IOS просто начнет, использовать память из процессорного пула.

Процессорная память на маршрутизаторах, платформы 7500 также содержит сис-
темные буферные пулы, которые описаны в разделе 1 “Основы программных прин-
ципов построения операционной системы IOS”.

Коммутация пакетов
в маршрутизаторах Cisco 7500

Операционная система 1OS маршрутизаторов Cisco 7500 предоставляет наиболее
широкий диапазон методов коммутации среди всех существующих платформ. Среди
поддерживаемых методов коммутации следует отметить следующие основные схемы.

	Программная коммутация на уровне процессов10 (process switching).

	Быстрая коммутация (fast switching).

	Оптимальная коммутация (optimum switching).

	Экспресс-пересылка корпорации Cisco (Cisco Express Forwarding" — CEF)

	Распределенная быстрая коммутация (distributed fast switching)

	Распределенная экспресс-пересылка данных корпорации Cisco (Distributed
CEF - dCEF).

	Протокол коммутации NetFlow (NetFlow switching).

_________4__________

10 Имеется в виду, что пакет коммутируется в контексте процесса, работающего в операционной
системе ЮБ, в отличие от других способов коммутации, которые осуществляются, например, в
контексте t/бработки прерывания. — Прим, перев.

“Буквально скоростное перенаправление методами корпорации Cisco. — Прим, перев.
Реализация распределенной быстрой коммутации и распределенной пересылки
данных CEF возможна благодаря использованию многоцелевых интерфейсных про-
цессоров (VIP), которые рассматриваются ниже в данной главе. Протокол коммутации
NetFIow подробно описан в приложении А.

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

Прием пакета при RSP-коммутации

На рис. 6.4 показаны этапы приема пакетов при коммутации с использованием
процессора коммутации-маршрутизации (RSP). Каждый этап описывается в соответ-
ствующем пронумерованном подпункте.

Рис. 6.4. Прием пакета при коммутации на основе RSP
Этап 1. Контроллер среды передачи данных обнаруживает приходящий пакет и на-
чинает прием данных пакета в ОЗУ интерфейсного процессора. Микрокод,
который выполняется интерфейсным процессором (например, интерфейс-
ным процессором Ethernet, или EIP), собирает приходящие данные в пакет,
занимающий непрерывную область памяти в ОЗУ интерфейсного процессора.

Этап 2. Микрокод интерфейсного процессора пытается найти буфер в памяти
MEMD для вновь прибывшего пакета. Сначала интерфейс пытается полу-
чить буфер из локальной очереди свободных буферов (IfreeQ). Если свобод-
ных буферов в локальной очереди не оказывается, микрокод пробует полу-
чить буфер из глобальной очереди свободных буферов (gfreeQ), которая со-
ответствует данному интерфейсу. В этом случае возможны три ситуации.

2.1.	В глобальной очереди пула нет свободных MEMD буферов. В
этом случае пакет отбрасывается и счетчик аннулированных па-
кетов (ignore) данного интерфейса увеличивается на единицу.

2.2.	В глобальной очереди пула есть свободные буферы, но интер-
фейс не может их получить, поскольку интерфейс удерживает
максимально возможное число буферов, которое задается соот-
ветствующим данному интерфейсу значением параметра rxhi
(т.е. rxcurr=rxhi). В этом случае пакет также отбрасывается, а
значение счетчика игнорированных пакетов увеличивается.

2.3.	Микрокод успешно получает буфер из глобальной очереди сво-
бодных буферов.

Этап 3. После получения свободного пакетного буфера памяти MEMD микро-
код копирует данные пакета из внутреннего ОЗУ в буфер памяти
MEMD через шину CyBus.

Этап 4. Интерфейсный процессор включает заголовок MEMD-буфера в очередь
необработанных данных RawQ для обработки процессором коммутации-
маршрутизации.

Этап 5. Специальное устройство шины CyBus определяет, что буфер помешен в
очередь RawQ, и активизирует сетевое прерывание центрального про-
цессора (CPU) модуля RSP.

Коммутация пакета

с использованием модуля RSP

На рис. 6.5 изображен процесс коммутации пакета в устройстве RSP. Ниже описан
каждый этап коммутации.

Этап 6. Центральный процессор устройства RSP подтверждает сетевое прерывание.

.....Операционная система 1OS начинает обработку пакета: удаление заголовка
пакетного MEMD-буфера из очереди RawQ, нахождение данных пакета и
просмотр содержимого буфера. Заметим, что все следующие шаги предпола-
гают, что система 1OS обрабатывает только один пакет во время обработки се-
тевого прерывания. Практически во время обработки сетевого прерывания
система 1OS продолжает обрабатывать пакеты до тех пор, пока есть заголовки
буферов, которые ожидают обработки в очереди RawQ. Далее операционная
система 1OS принимает решение о том, как коммутировать пакет.
Интерфейсный процессор
(с микрокодом)

Рис. 6:5. Коммутация пакета в устройстве RSP

6.1.	Если в буфере содержится IP-пакет и входной сетевой интерфейс
сконфигурирован для CEF-коммутации, то осуществляется пере-
ход к методу коммутации CEF.

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

6.3.	Если в буфере содержится IP-пакет и входной сетевой интерфейс
сконфигурирован для метода коммутации NetFlow (NetFlow switch-
ing), осуществляется переход к процессу коммутации NetFlow.
6.4.	Если содержимое буфера не является IP-пакетом, то система 1OS
использует метод быстрой коммутации.

Этап 7. Коммутация с помощью метода CEF. В контексте обработки сетевого
прерывания центральный процессор просматривает кэш CEF на предмет
наличия информации о выходном интерфейсе и следующей точке перехо-
да (next hop) для данного пакета.

7.1.	В таблице CEF есть запись для адреса получателя данного пакета.
Осуществляется новая инкапсуляция данных пакета с использо-
ванием того же буфера памяти MEMD и начинается стадия от-
правки пакета.

7.2.	Пакет адресован данному маршрутизатору или содержит управ-
ляющие данные, такие как обновление информации о маршрути-
зации. В этом случае пакет подготавливается к коммутации на
уровне процессов (см. этап 10).

7.3.	Нет соответствующей записи в таблице CEF. В этом случае пакет ан-
нулируется и счетчик игнорированных пакетов на этапе коммутации
с помощью метода CEF увеличивается на единицу. Центральный
процессор прекращает обработку сетевого прерывания и снимает
подтверждение прерывания (данный шаг не показан на рис. 6.5).

7.4.	Поиск в кэше CEF приводит к проблеме несогласованности (punt adja-
cency). Пакет передается процессу быстрой коммутации. Такая ситуа-
ция возникает, например, когда инкапсуляция в протокол выходного
интерфейса не поддерживается подсистемой коммутации метода CEF.

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

8.1.	Если необходимая для перенаправления пакета информация най-
дена в кэше оптимальной коммутации, то осуществляется инкап-
суляция пакета в протокол передачи в том же MEMD-буфере и
обработка пакета продолжается „на стадии передачи.

8.2.	Если в кэше оптимальной коммутации нет соответствующей за-
писи, то пакет перенаправляется для быстрой коммутации.

Этап 9. Быстрая коммутация. В процессе обработки сетевого прерывания цен-
тральный процессор ищет IP-адрес устройства-назначения в кэш-
структуре быстрой коммутации (fast cache).

9.1.	Если поиск завершился успешно, то пакет инкапсулируется в
протокол передачи в том же буфере памяти MEMD и обработка
передается на стадию передачи пакета.

9.2.	Если поиск закончился безрезультатно или пакет предназначен
данному маршрутизатору, то пакет подготавливается к коммута-
ции на уровне процессов (этап 10).

Этап 10. Во время обработки сетевого прерывания центральный процессор ищет свобод-
ный системный буфер и копирует в него пакет из буфера в памяти MEMD. Па-
кеты для коммутации с помощью процесса должны быть скопированы в сис-
темный буфер, находящийся в основной памяти, так как буферы в памяти
MEMD доступны только на уровне обработчиков прерываний (чтобы предот-
вратить возможность нехватки свободных буферов в памяти MEMD).
10.1.1	. Если система, IOS не может получить системный буфер, то счет-
чик пакетов^ аннулированных на Входном интерфейсе (input
drop), и счетчик событий отсутствия буферов (по buffer) увеличи-
ваются на единицу, а сам пакет отбрасывается. Центральный про-
цессор заканчивает обработку прерывания и с шины снимается
подтверждение прерывания.

10.1.2	. Если системный буфер доступен, но число пакетов во входной оче-
реди сетевого интерфейса имеет максимально возможное значение,
осуществляется подавление интерфейса 12, счетчик пакетов, анну-
лированных на входном интерфейсе (input drop), увеличивается на
единицу, а пакет игнорируется. Система IOS заканчивает обработку
прерывания и снимает подтверждение прерывания с шины управ-
ления. По умолчанию интерфейсы могут содержать 75 пакетов,
ожидающих обработки, во входной очереди (input hold queue).

10.1.3	. Если центральный процессор успешно получил системный буфер,
то пакет копируется из памяти MEMD в системный буфер и
MEMD-буфер возвращается в локальную очередь свободных бу-
феров данного интерфейса. Счетчик пакетов во входной очереди
интерфейса (input hold queue) увеличивается на единицу.

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

10.3.	В итоге пакет коммутируется фоновым процессом; более подробную
информацию см. в главе 2 “Принципы коммутации пакетов”.

10.4.	После коммутации пакет помешается в очередь выходящих пакетов
выходного интерфейса. Если очередь выходящих пакетов переполне-
на (по умолчанию в ней может быть максимум 40 пакетов), то пакет
аннулируется и счетчик игнорированных пакетов на выходном ин-
терфейсе (output drop) увеличивается на единицу. Если пакет аннули-
руется, то число пакетов в очереди входящих пакетов входного ин-
терфейса (input hold queue) также уменьшается на единицу.

10.5.	Операционная система IOS пытается получить пакетный буфер в
памяти MEMD, чтобы пакет мог быть отправлен интерфейсным
процессором. Сначала система IOS пытается получить MEMD-
буфер из глобального списка свободных буферов. Если в этом
списке нет свободных буферов или очередь передачи выходного
интерфейса заполнена, IOS оставляет пакет в очереди выходящих
пакетов (в системном буфере) и пытается отправить пакет позже.

10.6.	Операционная система IOS копирует пакет из системного буфера в
пакетный буфер памяти MEMD. Системный буфер удаляется из
очереди выходящих пакетов, память, занимаемая буфером, освобо-
ждается, и буфер помешается в системный буферный пул. На этом
этапе счетчик числа пакетов во входной очереди также уменьшается
на единицу. Система IOS переходит на стадию передачи пакета.

12 Уменьшение скорости приема пакетов. — Прим, перев.
Передача пакета при RSP-коммутации

На рис. 6.6 показаны этапы передачи пакет как результата работы процесса
коммутации. Ниже указанные этапы описаны более детально;

Этап 11. Система 1OS пытается поместить заголовок MEMD-буфера в очередь пе-
редачи (transmit queue) выходного интерфейса.

11.1. Если очередь передачи заполнена и на интерфейсе не сконфигу-
рировано вспомогательное хранилише (backing store), пакет анну-
лируется и счетчик пакетов, проигнорированных во выходном ин-
терфейсе (output drop), увеличивается на единицу.
? s : .. , 11.2. Если очередь передачи заполнена и интерфейс сконфигурирован с
' ;	использованием вспомогательного хранилища, пакет копируется из

буфера памяти MEMD в системный буфер, который помещается в
очередь выходящих пакетов интерфейса. Счетчик буферов, задер-
жанных на выходе (output buffer’s swapped out), увеличивается на
единицу. Следует заметить, что если на интерфейсе сконфигуриро-
ван какой-либо из способов обеспечения очередности прохождения
пакетов (fancy queuing), как, например, взвешенная абсолютная
очередность (weighted fair queuing), то вспомогательное хранилище
разрешено по умолчанию и не может быть отключено.

11.3.	Если выходная очередь интерфейса не полна, то MEMD-буфер
ставится в эту очередь и значение аккумулятора передачи (т.е.
число заголовков буферов, которые могут быть помещены в оче-
редь) уменьшается на единицу.

11.4.	Если система IOS находится в состоянии обработки прерывания,
то центральный процессор (CPU) завершает обработку прерыва-
ния и снимает подтверждение прерывания с шины управления.

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

Этап 13. Заголовок буфера памяти MEMD освобождается и возвращается в ло-
кальную очередь свободных буферов (Ifreeq) входного интерфейса.

Этап 14. Контроллер среды передачи данных выходного интерфейса передает пакет из
внутренней оперативной памяти интерфейсного процессора в среду передачи.

Внимание!

Вспомогательное хранилище (backing store) используется для предотвращения от-
брасывания пакетов маршрутизатором во время бросков количества пакетов. Вспомо-
гательное хранение обеспечивает возможность копировать пакеты, которые уже про-
шли процесс коммутации, обратно в выходную очередь интерфейса, если очередь
передачи интерфейса полностью занята. Данная операция является очень ресурсо-
емкой. Указанное свойство нельзя использовать на интерфейсе, если его полоса про-
пускания больше 2 Мбит/с, поскольку описанная опция способствует сильному воз-
растанию нагрузки на центральный процессор (CPU) маршрутизатора.

Структура многоцелевых
интерфейсных процессоров (VIP)

Корпорация Cisco разработала многоцелевые интерфейсные процессоры (VIР) для
создания распределенных структур на основе уже существующих платформ. Устройст-
во VIP размещено на одной материнской плате и может работать с несколькими адап-
терами портов, которые, в свою очередь, могут иметь разный тип среды передачи
данных (отсюда название процессора — многоцелевой).
Составные компоненты модуля VIP

По существу, устройства V1P являются маршрутизаторами, которые установле-
ны на платах интерфейсных процессоров системы Cisco 7500. Каждый модуль VIР
имеет свой процессор, пакетную память и каждый из них исполняет свою копию кода
операционной системы 1OS. На рис. 6.7 показана блок-схема архитектуры многоцеле-
вого интерфейсного процессора.

| Память DRAM |----------1 Процессор |

Шина CyBus

| Интерфейс шины CyBus]

Мост PCI

РМА

| Память SRAM |

[ Адаптер порта |

| Адаптер порта |

Рис. 6.7. Блок-схема архитектуры многоцелевых интерфейсных процессоров

Интерфейс шины CyBus

Модуль VIР является интерфейсным процессором, который полностью совместим
с интерфейсом шины CyBus, т.е. может выполнять чтение двух четырехбайтовых слов
за один такт шины и использовать полную пропускную способность шины CyBus,
равную 1066 Гбит/с.
Центральный процессор

Локальный центральный процессор устройства VIP (процессор R4700 или R7000
архитектуры MIPS) работает под управлением специальной версии операционной
системы IOS. Она может выполнять коммутацию пакетов, освобождая центральный
процессор RSP от излишней нагрузки. Операционная система IOS процессора VIР
также может локально выполнять расширенные функции 3-го уровня, такие как
фильтрацию пакетов, взвешенную абсолютную очередность (weighted fair queuing, WFQ)
передачи пакетов и процедуру взвешенного случайного аннулирования пакетов на ранних
этапах приема (weighted early drop, WRED). Именно локальные функции коммутации
J4 фильтрации пакетов составляют основу распределенной структуры коммутации
(distributed switching architecture) маршрутизаторов серии 7500.

•»

Основная память

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

Пакетная память

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

Система IOS процессоров VIP разбивает пакетную память на пулы пакетных буфе-
ров, которые используются интерфейсами. Так же как и система IOS на маршрутиза-
торах серии Cisco 7200, система IOS на процессорах VIР использует подход, основан-
ный на частичной буферизации, для обеспечения интерфейсов пакетными буферами.

Размер буферного фрагмента памяти (распределенного буфера) для устройства VIР
фиксирован и обычно равен 256 или 512 байтам и одинаков для всех его интерфейсов.
Размер фрагмента определяется типом адаптеров портов, которые инсталлированы на
плате V1P. Значение размера частичного буфера можно получить, выполнив команду
show controller vip slot <номёр слота> tech-support.

Адаптер порта

Процессоры VIР используют такие же адаптеры портов, как и маршрутизаторы се-
рии Cisco 7200. Каждый многоцелевой интерфейсный процессор может работать с од-
ним или двумя адаптерами, которые инсталлированы на его плате. Поддерживаются
два однопортовых или один двухпортовый адаптер. Заметим, что система IOS не под-
держивает подключение или отключение адаптеров портов во время работы.

Шина PCI’3

Многоцелевой интерфейсный процессор использует шину CyBus для взаимодействия с
процессором коммутации-маршрутизации, однако на плате VIP взаимодействие с цен-
тральным процессором и адаптерами портов идет через шину PCI, так же как и в модели
маршрутизатора Cisco 7200. На плате VIP имеются две шины PCI, которые соединены че-
рез мост PCI (PCI bridge), имеют 32 разряда и работают на частоте 25 МГц, что теоретиче-
ски позволяет получить пропускную способность 800 Мбит/с (25 МГц х 32бит/такг).

13 Peripheral Component Interconnect — 32- или 64-разрядная шина, которая позволяет присоединенным
к ней устройствам оперировать друг с другом без участия центрального процессора. — Прим. Перев.
Модели многоцелевых интерфейсных
процессоров

Существуют три модели многоцелевых интерфейсных процессоров, которые назы-
ваются VIP2-15, VIP2-40 и VIP2-50. Модель процессора VIР может быть определена с
помощью команды show diag. Устройство VIP2-40 содержит процессор (CPU) модели
R4700 на основе технологии MIPS, 2 Мбайт памяти SRAM, 32 Мбайт памяти DRAM.
Конфигурация памяти для процессора VIP2-40 не может быть изменена. Устройство
VIP2-5O содержит процессор R5000 на основе технологии MIPS, до 8 Мбайт памяти
SRAM, до 64 Мбайт памяти DRAM.

Результат выполнения команды show diag для процессора VIP2-40 показан в при-
мере 6.5.

Пример 6.5. Результат выполнения команды show diag для модели процессора VIP2-40 i

Router>show diag

Slot 2:

Physical slot 2, -physical slot 0x0, logical slot 2, CBus 0

Microcode Status 0x4

Master Enable, LED, WCS Loaded

Board is analyzed Pending I/O Status: None

EEPROM format version 1

VIP2 controller, HW rev 2.04, board revision DO

Serial number: 06745223 Part number: 73-1684-03

Test history: OxOE RMA number: 16-96-31

Flags: Cisco 7000 board; 7580 compatible

EEPROM contents (hex) :

0x20: 01 15 02 04 00 66 EC 87 49 06 94 03 0E 10 60 IF

0X30: 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Slot database information:

Flags: 0x4 Insertion time: 0X32B7F4 (3d04h ago)

Controller Memory Size: 32 MBytes DRAM, 2048 KBytes SRAM

Результат выполнения команды show diag для процессора VIP2-50 показан в примере 6.6.

; Пример 6.6. Результат выполнения команды show diag для модели процессора VIP2-50 ]

Router>show diag

Slot 1:

Physical slot 1, -physical slot OxE, logical slot 1, CBus 0
Microcode Status 0x4
Master Enable, LED, WCS Loaded
Board is analyzed
Pending I/O Status: None

EEPROM format version 1

VIP2 R5K controller, HW rev 2.02, board revision A0

Serial number: 12345678 Part number: 73-2167-04

Test history: 0x00 RMA number: 00-00-00

Flags: cisco 7000 board; 7500 compatible

EEPROM contents (hex):

0x20: 01 IE 02 02 00 93 63 AC 49 08 77 04 00 00 00 00

0x30: 50 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00

Slot database information:
Flags: 0x4 Insertion time: 0xl4D4 (9w3d ago)

Controller Memory Size: 32 MBytes DRAM, 4096 KBytes SRAM

Обработка пакетов процессором VIP:
распределенная коммутация

В сущности, многоцелевые интерфейсные процессоры выполняют те же функции,
что и менее “интеллектуальные” интерфейсные процессоры с микрокодом. Они соби-
рают входные пакеты для обработки в устройстве RSP из данных, поступающих из
среды передачи, и передают пакеты, приходящие от процессора RSP, в среду переда-
чи. Однако, как уже упоминалось, устройства VIР также могут выполнять функции,
недоступные интерфейсным процессорам с микрокодом. Так как на процессорах VIР
выполняются инструкции операционной системы IOS, то соответственно эти процес-
соры имеют определенные встроенные логические функции, позволяющие принимать
решения по коммутации пакетов, что является очень мощным средством. VIP-
процессоры также имеют некоторые аппаратные функции, позволяющие использовать
шину CyBus для обмена данными с другими интерфейсными процессорами без уча-
стия центрального процессора RSP. Эти две возможности позволяют каждому процес-
сору VIР работать как независимому средству коммутации пакетов внутри маршрути-
заторов серии 7500, а также обеспечивать распределение работы по коммутации паке-
тов между несколькими процессорами в маршрутизаторе. Все вышеизложенное
составляет основу функции распределенной коммутации операционной системы IOS.

В приведенных ниже разделах более детально описываются три стадии коммутации
пакета в контексте операционной системы IOS процессоров VIР: прием, коммутация
и передача пакета.

Прием пакета при распределенной коммутации

На рис. 6.8 показаны этапы приема пакета и стадии коммутации пакетов при распреде-
ленной коммутации. Каждый этап описан в подпункте, соответствующем его номеру.

Этап 1. Контроллер среды передачи данных интерфейса (внутри адаптера порта)
определяет момент прихода пакета из среды передачи. Далее контроллер
среды передачи принимает пакет в один из своих свободных фрагментов
памяти и хранит его в локальной области пакетной памяти, которая назы-
вается приемным кольцом (receive ring).

Этап 2. Контроллер среды передачи данных посылает сетевое прерывание цен-
тральному процессору VIP-модуля. Центральный процессор VIР подтвер-
ждает прерывание, и операционная система IOS процессора VIР начинает
обработку прерывания для приема пакета из интерфейса, прервавшего ра-
боту центрального процессора.

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

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

4.2/5.3

Аппаратура шины CyBus 5

Память DRAM

Кэш оптимальной/
CEF-коммутации

Входная очередь]

Очередь RAWQ |

Память MEMD

CyBus

*-----------

и Пакетная
।' память

('] Приемное
। кольцо

Процессор

Выходная очередь]

Очередь передачи]

Кэш рас-
пределенной
коммутации

]4и5
Память DRAM

Интерфейсный ( Интерфейсный

процессор

процессор

32-

1
со
ф
5

Пакетная
память

Приемное
кольцо

Интерфейсный
процессор

7

1 1

3

3

\ 1

ф
£

ф

Рис. 6.8. Прием пакета при распределенной коммутации

3.2.	Если функция обработки приема успешно обновила приемное
кольцо, то она просматривает содержимое буферных фрагментов
для определения типа принятого пакета.

3.2.1.	Если принят IP-пакет, то обработка переходит к распределенной

коммутации (распределенная оптимальная или распределенная
CEF-коммутация).

3.2.2.	Если принят не IP-пакет, то для него распределенная коммута-
ция не поддерживается. В этом случае пакет направляется через
шину CyBus в память MEMD подсистемы модуля RSP по ана-
логии с тем, как это делают интерфейсные процессоры с микро-
кодом. В конце процедуры система IOS процессора VIР закан-
чивает обработку прерывания, и процессор VIР снимает под-
тверждение сетевого прерывания.

Коммутация пакета при распределенной коммутации

На рис. 6.8 показаны этапы коммутации пакета в рассматриваемом случае распреде-
ленной коммутации. Все решения по распределенной коммутации пакета принимает
центральный процессор подсистемы VIР. Этапы коммутации пакета следующие.

Этап 4. Оптимальная распределенная коммутация. В основной памяти процессора
VIР содержится полная копия кэш-структуры распределенной коммута-
ции устройства RSP, что позволяет центральному процессору модуля VIР
принимать решения по коммутации пакетов. Соответствующие распреде-
ленные кэш-структуры и кэш-структуры процессора RSP синхронизиру-
ются с помощью обмена сообщениями между центральными процессора-
ми этих устройств. Во время обработки сетевого прерывания система IOS
подсистемы модуля VIР ищет необходимую для коммутации информацию
в локальной кэш-структуре оптимальной коммутации.

4.1. Если необходимая информация найдена в кэш-структуре оптимальной
коммутации, то осуществляется инкапсуляция пакета в протокол пере-
дачи нижнего уровня с учетом новой информации адреса МАС14.
Дальнейшая обработка пакета выполняется на стадии передачи.

Этап 5. Распределенная коммутация с помощью метода CEF. Копии таблицы CEF и
таблицы соседства устройства RSP также содержатся в локальной памяти
многоцелевого интерфейсного процессора, так что это устройство может са-
мостоятельно принимать решения по коммутации входных пакетов с помо-
щью метода CEF. С помощью обмена сообщениями между центральными
процессорами устройств VIР и RSP осуществляется синхронизация главных
таблиц из модуля RSP с таблицами всех процессоров VIP. Во время обработки
сетевого прерывания система IOS процессора VIР просматривает таблицы
CEF на предмет информации, необходимой для коммутации пакета.

5.1.	Если необходимая для коммутации информация найдена в локаль-
ной CEF-таблице, пакет инкапсулируется и управление передается
на этап передачи.

5.2.	Если в результате поиска необходимая для коммутации информа-
ция не найдена, то пакет аннулируется. Система IOS устройства
VIР заканчивает обработку прерывания, а центральный процессор
VIР снимает подтверждение прерывания с шины управления.

5.3.	Если в результате поиска обнаружена ситуация спорной (punt) или
приемной (receive) несогласованности, пакет передается через шину
CyBus в память MEMD подсистемы RSP, как и в случае интерфейс-
ных процессоров с микрокодом. Система IOS устройства VIP в дан-
ном случае заканчивает обработку прерывания, а центральный про-
цессор VIР снимает подтверждение прерывания с шины управления.

74 Media Access Control — управление доступом к среде передачи. Обычно употребляется в связи с
канальным уровнем модели OSI. — Прим, перев.
Передача пакета при распределенной коммутации

На рис. 6.9 показаны этапы передачи пакета при распределенной коммутации.
Каждый этап описан ниже в нумерованном списке.

<л

Аппаратура шины CyBus 5

Процессор

Память DRAM

Кэш оптимальной/
CEF-коммутации

Входная очередь|

Выходная очередь |

Память MEMD
__	7.4

Очередь RAWQ |

Очередь передачи |

4.2/5.3 ;

CyBus



Тх Пакетная
1 \ память

Приемное4^

КОЛЬЦО ’

Кэш рас-
пределенной
коммутации

4и 5

Память DRAM

О.

§

Интерфейсный ч Интерфейсный

процессор

процессор

ф
с;
ф

8
о

8L

о.

§

Приемное
кольцо

Интерфейсный
процессор

_________,8/

Пакетная । '
память •/

а

3

3

ф

Ф



6

9

Рис. 6.9. Передача пакета при распределенной коммутации

Этап 6. Если пакет предназначен интерфейсу, который связан с той же подсисте-
мой VIP, то он может быть отправлен локально без необходимости пере-
дачи через шину CyBus.
6.1.	Программное обеспечение, работающее на процессоре VIP, поме-
щает фрагменты пакета из буфера в специальную локальную об-
ласть передачи выходного интерфейса, которая называется кольцом
передачи (transmit ring). Операционная система IOS устройства VIP
заканчивает обработку прерывания, а центральный процессор VIP
снимает подтверждение прерывания с шины управления.

6.2.	Контроллер среды передачи выходного интерфейса (на адаптере порта)
передает данные пакета из его кольца передачи в физическую среду.

6.3.	Когда контроллер среды заканчивает передачу пакета, он помечает
буферы, содержащие фрагменты пакета, как пустые и сообщает
операционной системе IOS устройства VIР (посредством специаль-
ного прерывания), что фрагменты буферов освободились и могут
быть возвращены в глобальный пул распределенных буферов.

Этап 7. Если пакет предназначен для интерфейса на другом интерфейсном про-
цессоре, то система IOS устройства VIP передает пакет данному интер-
фейсному процессору по шине CyBus через память MEMD.

7.1.	Система IOS подсистемы VIP пытается получить свободный бу-
фер в памяти MEMD, сначала из локальной очереди свободных
буферов, а затем — из глобальной.

7.2.	Если нет свободных MEMD-буферов, система IOS устройства VIP
пытается временно сохранить пакет в пакетной памяти, а не ан-
нулирует его (более подробно такая ситуация описана ниже, в
разделе “Буферизация в устройстве VIP на стороне приема”).
Точно так же, если очередь передачи выходного интерфейса за-
полнена, то система IOS устройства VIР пытается временно со-
хранить пакет в пакетной памяти.

7.3.	Если система IOS устройства VIP успешно получила буфер памя-
ти MEMD, то она копирует данные пакета из распределенных
буферов в буфер памяти MEMD по шине CyBus.

7.4.	Заголовок MEMD-буфера для данного пакета помещается непо-
средственно в очередь передачи выходного интерфейса. Цен-
тральный процессор устройства RSP при этом не прерывает рабо-
ту, а продолжает выполнять процессы в фоновом режиме и обра-
батывать данные, которые коммутируются на уровне процессов, а
также оперировать с таблицами маршрутизации и т.д.

7.5.	Система IOS устройства VIP заканчивает обработку прерывания, а цен-
тральный процессор VIР снимает подтверждение прерывания с шины.

Этап 8. Выходной интерфейс может быть установлен на обычном интерфейсном
процессоре или на другом процессоре VIP. В любом случае управляющий
код выходного интерфейсного процессора определяет, что пакет находит-
ся в очереди передачи, и копирует содержимое пакетного буфера из памя-
ти MEMD по шине CyBus во внутреннюю память выходного интерфейса .

Этап 9. Контроллер среды передачи данных выходного интерфейса передает пакет
из памяти интерфейса в физическую среду.
Буферизация в устройстве VIP на стороне приема

Интерфейсные процессоры маршрутизаторов серии Cisco 7500, включая и процессоры
VIP, не имеют доступа к внутренней памяти других интерфейсных процессоров. Они мо-
гут получить доступ только к своей внутренней памяти и к памяти MEMD процессора
коммутации-маршрутизации. Поскольку память MEMD — это единственный ресурс об-
щего доступа, то каждый пакет, который переходит из одного интерфейса в другой по ши-
не CyBus, должен пройти через буфер в памяти MEMD процессора RSP. Однако размеры
памяти MEMD ограничены, и нет гарантии, что буфер в памяти MEMD окажется доступ-
ным, когда процессор VIР захочет передать данные в другой интерфейсный процессор.

В случае, когда процессор VIP выполняет распределенную коммутацию и свободный
буфер памяти MEMD недоступен, операционная система IOS процессора VIР позволяет
буферизировать принятый пакет локально. Этот процесс называется буферизацией на
стороне приема. Буферизация на стороне приема позволяет сократить число отброшен-
ных пакетов на интерфейсном процессоре VIP путем использования локальной памяти
данного интерфейсного процессора для временного хранения пакетов, которые были бы
аннулированы из-за отсутствия ресурсов памяти MEMD или переполнения очереди пе-
редачи. Описанное свойство особенно ценно в ситуациях, когда на высокоскоростных
интерфейсах принимается большое количество пакетов, которые должны быть перена-
правлены через более медленные интерфейсы на другом интерфейсном процессоре.

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

Статистику по использованию буферизации на стороне приема можно получить,
выполнив команду show controller vip accumulator, как показано в примере 6.7.

[ Пример 6.7. Результат выполнения комайды show controllerMp accumulator	j

Router# show controller vip 2 accumulator

Buffered RX packets by accumulator:

Forward queue 0 : 573 in, 0 drops (0 paks, 0 bufs)

1	FastEthernetl/O:

2	MEMD txacc 0X0082: 4500 in, 300 drops (0 paks, 0/24414/24414 bufs)
100000kbps

3	No MEMD acc: 4500 in, 300 limit drops, 0 no buffer

4	No MEMO buf: 0 in, 0 limit drops, 0 no buffer

ATM2/0/0:

local txacc 0xlA02: 0 in, 0 drops (0 paks, 0/37968/37968 bufs)
155520kbps

Строки, пронумерованные от 1 до 4, содержат статистику по использованию буфе-
ров на стороне приема для соответствующих выходных интерфейсов.

Строка 2 в примере 6.7 показывает, что в пакетной памяти в общем случае буфе-
ризировано 4500 пакетов, предназначенных для отправки через интерфейс FastEther-
netl/O, а 300 пакетов — проигнорировано. В данный момент 0 пакетов находится в
очереди буферизации на стороне приема, а максимальное количество пакетов, кото-
рые могут быть буферизированы, — 24414. Такое количество буферов необходимо для
буферизации пакетов, передаваемых за одну секунду через интерфейс с соответст-
вующей пропускной способностью, что может быть выражено следующей формулой:

максимальное число буферов = (выходная пропускная способность интерфейса
в бит/с)/(8 х размер фрагмента буфера).

В приведенном выше примере пропускная способность составляет 100 Мбит, а
размер фрагмента буферного 512 байт.
Строка 3 показывает, что все буферизированные пакеты, указанные в строке 2 (всего
4500), были буферизированы из-за переполнения очереди передачи (No MEMD асе.) 300
пакетов были аннулированы по той же причине. Заметим, что если значение счетчика
проигнорированных пакетов по причине нехватки буферов (no buffer) не равно нулю, то
это значит, что недостаточно ресурсов пакетной памяти для буферизации на стороне
приема. Такая ситуация, в свою очередь, может означать нехватку пакетной памяти
(SRAM) в процессоре VIР. Строка 4 показывает, что ни один пакет не был буферизиро-
ван из-за отсутствия свободных буферов в памяти MEMD (No MEMD buf.).

Устранение неисправностей
в маршрутизаторах Cisco 7500

В приведенном ниже разделе описаны способы устранения наиболее часто встречаю-
щихся проблем, связанных с операционной системой IOS платформы Cisco 7500. Наибо-
лее общие из них — это перегрузка центрального процессора, аннулирование пакетов на
входных интерфейсах, игнорирование пакетов и аннулирование пакетов на выходе.

Перегрузка центрального процессора

В примере 6.8 показана часть результатов вывода команды show process cpu для мар-
шрутизатора, на котором замечена слишком большая загрузка центрального процессора.

[ пример 6.8. Результат выполнения команды show process cpu	|

Router# show process cpu

CPU utilization for		fife seconds: 90%/80%; one			minute:	60%; five		minutes: 40% PID
Runtime	Invoked	uSecs	5Sec	IMin	5Min	TTY		process
1	1356	2991560	0	0.00%	0.00%	0.00%	0	BGP Router
2	100804	7374	13670	0.00%	0.02%	0.00%	0	Check heaps
3	0	1	0	0.00%	0.00%	0.00%	0	Pool Manager
4	0	2	0	0.00%-	0.00%	0.00%	0	Timers
5	6044	4	1511000	0.00%	0.00%	0.00%	0	OIR Handler
6	0	1	0	0.00%	0.00%	0.00%	0	IPC Zone Manager
7	0	1	0	0.00%	0.00%	0.00%	0	IPC Realm Manager
8	7700	36331	211	8%	0.00%	0.00%	0	IPC Input

В примере 6.8 показано, что за последние 5 секунд средняя загрузка центрального
процессора (CPU) составляла 90 процентов от полной производительности и 80 про-
центов полной производительности (88,8 процента от полного времени работы про-
цессора) составляла обработка прерываний. Скользящее среднее загрузки процессора
за 1 и 5 минут составляло соответственно 60 и 40 процентов. Так как самый большой
вклад в нагрузку дает обработка прерываний и загруженность устройства за длитель-
ное время несколько меньше, то, скорее всего, данный маршрутизатор обрабатывает
резкий скачок количества коммутируемых пакетов.

В подобной ситуации нет ничего страшного, однако для маршрутизаторов серии 7500 и
других, которые используют процессоры, основанные на технологии MIPS, нагрузка на про-
цессор при обработке прерывания может быть больше обычной из-за ошибки размещения
данных в памяти (alignment error). Подобные ошибки возникают тогда, когда программа пы-
тается записать данные в память по адресу, который недопустим правилами размещения
данных в памяти для данного центрального процессора (CPU). Для процессоров, созданных
по технологии MIPS, 16-битовое число должно быть размешено по адресу, кратному 2, а 32-
битовое — по адресу, кратному 4, и т.д. В случае, когда операционная система 1OS пытается
получить доступ к данным, размещение которых противоречит правилам, процессор генери-
рует исключительную ситуацию (exception) и вызывает функцию операционной системы IOS,
которая пересылает данные в сегменты памяти, не нарушающие правила размещения.
Функция обработки исключительной ситуации добавляет значительное количество инструк-
ций выполнения к сравнительно простой операции доступа к данным, что вызывает значи-
тельные затраты процессорного времени. По этой причине ошибки размещения могут зна-
чительно снижать производительность. Все ошибки размещения данных фиксируются в
журнале записи, который можно просмотреть с помощь команды show align.

Большая загрузка центрального процессора процессами должна быть исследована для вы-
явления процессов, которые максимально занимают процессорное время. По результатам
вывода команды show process cpu очень легко определить, какие процессы больше всех зани-
мают процессорное время. Названия процессов интуитивно понятны. Например, процесс IP
Input отвечает за обработку всех IP-пакетов на уровне процессов. Если процесс IP Input за-
нимает много процессорного времени, то это скорее всего означает, что множество пакетов,
приходящих на маршрутизатор, коммутируются с помощью данного процесса. Чтобы опре-
делить, действительно ли приходящие пакеты коммутируются с помощью процессов, целесо-
образно воспользоваться командой show interface stat, как показано в примере 6.9.

[Пример 6.9. Определение J	[		 shew interface i	статистики t	соммутации паке	ГТОВ С помощью к	оманды <{!  i	• -и." '• "ф
Router# sh int stat				
POS8/1/0				
Switching path	Pkts In	Chars In	Pkts Out	Chars Out
Processor	2	4498	15586	23285531
Route cache	0	0	0	0
Distributed cache	60448	57737596	30772	1357152
Total	60450	57742094	46358	24642683

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

	Pkts In — количество пакетов, которые пришли из данного интерфейса, и ме-
тод, который использовался для их коммутации. В примере 6.9 общее количест-
во пакетов, пришедших в интерфейс POS8/1/0, — 60450, два пакета коммутиро-
валось на уровне процессов, 0 пакетов коммутировались методами быстрой
коммутации, оптимальной коммутации и с помощью протокола CEF, 60448 па-
кетов коммутировались методами распределенной коммутации.

	Chars In — количество байт, пришедших из интерфейса. Отношение Chars In/Pkts
In позволяет определить средний размер пакета, приходящего в интерфейс.

	Pkts Out — количество пакетов, переданных данным интерфейсом, и метод, с
помощью которого эти пакеты коммутировались. Пакеты, которые передаются
интерфейсом, могли быть получены из многих интерфейсов. В примере 6.9 по-
казано, что из переданных интерфейсом POS8/1/0 пакетов 15586 коммутирова-
лись с помощью процесса, а 30772 — методами распределенной коммутации.

Наибольшее количество пакетов, полученных интерфейсом, должны коммути-
роваться с помощью самого быстрого для данного интерфейса метода. Управ-
ляющие пакеты (например, обновления таблиц маршрутизации, тестовые паке-
ты keep-alive15) и пакеты, предназначенные для данного маршрутизатора, всегда

15 Буквально означает поддерживать в живом состоянии. Информация, которая используется многими
протоколами для подтверждения, что какое-либо состояние все еще активно. Например, keep-alive-
пакеты протокола TCP подтверждают, что данное соединение не разорвано. — Прим, перев.
считаются входными пакетами, коммутированными с помощью процессов. Интер-
претируя результаты вывода команды show interface stat, следует помнить, что
пакеты, принятые данным интерфейсом, обычно передаются другим интерфей-
сом и, наоборот, пакеты, которые передаются данным интерфейсом, были при-
няты на другом интерфейсе. Таким образом, необходимо просмотреть результа-
ты вывода команды show interface stat для всех интерфейсов, чтобы оценить об-
щее количество данных, прошедших через маршрутизатор.

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

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

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

	Атака “отказ в обслуживании”. Очень большая категория нестандартных ситуа-
ций. Ping-атака — достаточно распространенный вид атак, когда злоумышлен-
ник посылает маршрутизатору интенсивный поток пакетов с помощью про-
граммы ping. Для предотвращения такого вида атак необходимо использовать
списки доступа. В случае возникновения проблемы может быть полезной уста-
новка фиксированной скорости доступа (Committed Access Rate — CAR). Более
детальную информацию о конфигурации параметра CAR можно найти в доку-
ментации по операционной системе Cisco IOS.

	Циклический маршрут (routing loop). Маршрутная петля может привести к тому,
что IP-пакеты, у которых закончилось время жизни (TTL), аннулируются на
маршрутизаторе. Такой случай легко распознать по постоянно увеличивающе-
муся значению счетчика bad hop counter (ошибка перехода к следующей точке) в
результатах вывода команды show ip traffic.

Аннулирование пакетов на входе

Для маршрутизаторов серии 7500 значение счетчика input drop в выводимой коман-
дой show interface информации увеличивается только тогда, когда игнорируется пакет,
предназначенный для коммутации с помощью процессов. Небольшое количество от-
брошенных пакетов на входе является допустимым. Однако соотношение между ко-
личеством отброшенных пакетов и общим количеством пакетов — очень важная ин-
формация. Сложно точно определить границу, когда необходимо серьезно обратить
внимание на игнорирование пакетов, однако заметное уменьшение пропускной спо-
собности сети требует анализа причин отбрасывания пакетов на входе.

Размер входной очереди пакетов по умолчанию равен 75. Увеличение ее разме-
ра не всегда может решить проблему. Необходимо исследовать причины, поче-
му пакеты переходят на уровень коммутации с помощью процессов. Некоторые
из причин, описанных в разделе о перегрузке центрального процессора мар-
шрутизатора, также могут приводить к аннулированию пакетов. Если в резуль-
тате выполнения команды show interface видно увеличение значения счетчика по
buffer, то это говорит о нехватке свободных буферов для хранения пакетов. Ко-
манда show buffer операционной системы IOS может быть полезной для опреде-
ления, какой из пулов буферов является пустым.
Игнорирование пакетов

Увеличение значения параметра ignore в результатах вывода команды show interface
свидетельствует о нехватке буферов в памяти MEMD. Всплески сетевого трафика
также могут приводить к игнорированию пакетов. Как и в случае с аннулированием
пакетов на входном интерфейсе, важным является соотношение между количеством
проигнорированных пакетов и общим количеством пакетов.

Передача пакетов, полученных из быстрых интерфейсов в более медленные, также мо-
жет привести к игнорированию пакетов. В этом случае MEMD-буферы из пула входного
интерфейса на протяжении длительного времени удерживаются занятыми в очереди пере-
дачи медленного интерфейса. В этой ситуации другие интерфейсы, которые используют
тот же пул, испытывают недостаток буферов. Один из путей решения — конфигурация
одинаковых значений параметра MTU для всех интерфейсов маршрутизатора. В случае
одинаковых значений параметров MTU для всех интерфейсов они используют один об-
щий пул большого размера в памяти MEMD и все интерфейсы потенциально могут полу-
чить большее количество буферов. Конфигурация интерфейсов, установленных на VIР-
процессорах, для распределенной коммутации позволяет использовать буферизацию на
стороне приема и тем самым избежать игнорирования пакетов.

Аннулирование пакетов на выходе

Увеличение значения параметра output drop в результатах вывода команды show in-
terface может происходить вследствие перечисленных ниже причин.

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

	Быстрая коммутация — пакет не может быть поставлен в очередь передачи ин-
терфейса, поскольку она переполнена. Значения параметров очереди передачи
интерфейса в данный момент времени могут быть получены с помощью коман-
ды show controller cbus. Небольшие значения параметров свидетельствуют о пе-
реполнении очереди передачи.

Увеличение длины выходной очереди не может сократить число пакетов, аннулируе-
мых на выходе, если большинство пакетов аннулируется на этапе быстрой коммутации.
Так же как и для других случаев отбрасывания пакетов, небольшое количество аннули-
рованных на выходе пакетов является допустимым. Абсолютное количество пакетов, ан-
нулированных на выходе, не является настолько важным параметром, как соотношение
между обшим количеством пакетов и количеством отброшенных пакетов.
Резюме

В данной главе была рассмотрена аппаратная структура маршрутизаторов серии
7500, для которой характерна шина данных со скоростью передачи 1 Гбит/с — так на-
зываемая CyBus. Центральный процессор подсистемы RSP поддерживает методы бы-
строй и оптимальной коммутации, а также коммутации с помощью процесса. Устрой-
ства на основе VIP-процессоров распределяют работу по коммутации пакетов между
центральными процессорами VIР и тем самым обеспечивают масштабируемость мар-
шрутизаторов серии 7500.

Основное внимание в этой главе было уделено аппаратной структуре маршрутизаторов
Cisco серии 12000, а также коммутации пакетов в маршрутизаторах Cisco серии 12000.

Резюме

141
Ключевые темы этой главы .жллг. . .. .	> г -?

	Принципы аппаратного устройства маршрутизаторов серии Cisco 12000

	Коммутация: пакетов в маршрутизаторах серии Cisco 12000.-
Гигабитовый
коммутирующий
маршрутизатор Cisco 12000

В начале 1990-х годов Internet начала приобретать существенное значение для бизнеса,
и, как результат, ее стремительный рост в конце концов стал ограничиваться пропускной
способностью магистральных маршрутизаторов (backbone routers), в качестве которых в ос-
новном использовались» Cisco 7500.? Одновременно с увеличением сетевого трафика воз-
росли требования к надежности сете^Дтак как в сфере бизнеса все больше начали исполь-
зовать WWW (AVorkijWide Web — “Всемирная паутина”) и электронную почту (E-mail).

Для удовлетворения растуших потребностей в надежности и высокой пропускной
способностиканалов корпораций СЦсо разработала гигабитовый коммутирующий
маршрутизатор gigabit Switcl^outer |~,GSR) серии 12000.

т	ж ё®

Аппаратная структура

Гигабитовые маршрутизаторы’ (С5К) существуют в трех конфигурациях, которые
подробно описаны ниже.	К

Модель 12008 содержит ша?сси/'с 8 разъемами и коммутирующей структурой
" ' "(switching fabric), обеспечивающей пропускную способность 40 Гбит/с.

	Модель 12012 основана на шасси с 12 разъемами и коммутирующей структурой
(switching fabric), обеспечивающей пропускную способность 60 Гбит/с.

	Модель 12016 содержит шасси с 16 разъемами и коммутирующей структурой
(switching fabric), обеспечивающей пропускную способность 80 Гбит/с, с воз-
можностью расширения д<5?320 Гбит/с.

На рйс':7Л показана блок-cxfeMa верхнего уровня маршрутизатора Cisco 12000.

Наиболее важными компонентами архитектуры являются следующие.

	Коммутируюшаяструктура.

	Шина обслуживания (maintanence bus, MBUS).

	Процессор маршрутизации.

Ш,уЛЙнейные адаптеры (line cards).
^Процессор маршрутизации

Линейный адаптер |

v ;

| Линейный адаптер

Перекрестная
коммутирующая
структура

Линейный адаптер |



| Линейный адаптер

Шина обслуживания

| Вентилятрр | | Источники питания |

Рис. 7.1. Архитектура маршрутизатора Cisco 12000

Коммутирующая структура

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

	Арбитражные затраты. Каждый раз, когда линейному адаптеру (Line Card — LC)
необходимо передать данные, ему необходимо пройти арбитражную фазу, в хо-
де которой определяется возможность получения права на передачу.

	Передача только одним адаптером. В любой момент времени только один ли-
нейный адаптер может передавать данные по шине. Независимо от количества
адаптеров в системе, только один из них может передавать или принимать дан-
ные в произвольный момент времени.

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

Структура совместно используемой памяти может обеспечивать значительно боль-
шую скорость. Увеличение скорости передачи в такой системе ограничено следующи-
ми факторами.

	Избыточные затраты, связанные с невозможностью выполнения операции за-
писи двум процессам в одну область памяти в один и тот же момент времени.

	Физические ограничения на скорость работы с памятью.

Использование перекрестной коммутирующей структуры в качестве объединитель-
ной платы позволило избежать обеих проблем в маршрутизаторах Cisco серии 12000.
Сеть перекрестных соединений представляет собой 2N шин (где N — число линейных
адаптеров, подключенных к коммутирующей структуре), соединенных друг с другом в
NxN узлах. На рис. 7.2 показана принципиальная схема подобной структуры. Если
один из узлов замкнут, то два устройства LC, подсоединенные к нему, оказываются
соединенными вместе и могут обмениваться данными.

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

Рис. 7.2. Перекрестная коммутирующая структура

Внимание!

Алгоритм планирования, который используется в маршрутизаторах серии Cisco 12000,
был разработан в Стэнфордском университете. Подробное описание архитектуры пе-
рекрестной коммутирующей структуры можно найти в статье Nick McKeown. Fast
Swithed Backplane for a Gigabit Swithed Router. — Stanford University. Данную статью
можно найти в Internet по адресу http://www.cisco.com/warp/
public/cc/cisco/mkt/core/12000/tech/fasts_wp.pdf.

Рис. 7.3. Коммутирующая структура маршрутизатора Cisco 12000
Физически перекрестная коммутирующая структура маршрутизаторов Cisco серии
12000 содержит до пяти плат. В системе имеются два типа соответствующих плат: модуль
синхронизирующего планировщика (Clock Scheduler card — CSC) и модуль коммутирую-
щей структуры (Switch Fabric Card — SFC). Плата CSC является расширением платы SFC.

Платы CSC и SFC содержат специализированные интегральные схемы (ASIC), ко-
торые обеспечивают для каждого разъема пропускную способность 1,25 Гбит/с в пол-
нодуплексном режиме. Плата CSC также содержит микросхему планировщика, кото-
рая обеспечивает планирование доступа линейных адаптеров к структуре, и тактовый
генератор, синхронизирующий работу всех плат в системе. В каждой системе должна
быть установлена хотя бы одна плата CSC. Если установлены две такие платы, то вто-
рая становится резервной.

В примере 7.1 показан результат выполнения команды show controller fia, из кото-
рого видно, какая из плат CSC активна.

;—- -.............’—   - —-----------------------  ..... ....-....—- -----

। Пример 7.1. Определение активной платы CSC по результатам выполнения	|

|	команды show controller fia	t -/у	i

Router# show controller fia

Fabric configuration: Full bandwidth nonredundant

Master Scheduler: Slot 17

В случае, приведенном в примере 7.1, активной является плата, включенная в разъем
номер 17. В следующем разделе описано, что означают значения соответствующих па-
раметров в конфигурации структуры (как, например, параметр full bandwidth). В данном
примере также показано, что в системе имеется всего одна плата CSC, поскольку кон-
фигурация структуры не обладает соответствующим резервом (nonredundant).

Пропускная способность коммутирующей структуры

Коммутирующая структура GSR маршрутизаторов может работать в двух режимах:

	полная пропускная способность (full bandwidth);

	одна четвертая пропускной способности (quarter bandwidth).

Для того чтобы понять, какую пропускную способность можно получить в той или
иной конфигурации, необходимо вспомнить, что каждая коммутирующая плата обеспе-
чивает в полнодуплексном режиме пропускную способность 1,25 Гбит/с для каждого
разъема. В режиме полной пропускной способности устанавливается пять коммутирую-
щих плат: две платы CSC и три платы SFC. В таком случае одна плата CSC находится в
состоянии ожидания, так как обеспечивает наличие резервного планировщика и такто-
вого генератора. Таким образом, только четыре платы передают данные через коммути-
рующую структуру. Для определения пропускной способности необходимо перемножить
следующие параметры: число коммутирующих плат (4), пропускную способность платы
(1,25 Гбит/с) и количество линейных адаптеров (зависит от модели маршрутизатора).

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

Заметим, что из рис. 7.3 видно, что каждый линейный адаптер подключен к каждой
коммутирующей плате. В такой конфигурации трафик, идущий из одного линейного
адаптера, разбивается на пакеты одинакового размера (64 байта), которые делятся на
части размером по 16 байт и передаются параллельно через четыре коммутирующие
платы, подключенные к данному линейному адаптеру. Пятая, резервная линия исполь-
зуется для передачи контрольной суммы (CRC) всех 16-байтовых частей, что позволяет
проверить и в некоторых случаях исправить ошибки. Если одна из четырех линий обры-
вается, то автоматически активизируется резервная линия передачи, что обычно проис-
ходит без потерь или с небольшими потерями данных. Через коммутирующую структуру
данные всегда передаются пакетами одинакового размера, называемыми Cisco cell
(ячейка корпорации Cisco), о чем подробнее рассказывается в. следующих разделах.

, Таблица 7.1. Определение результирующей пропускной способности '
{ коммутирующей структуры для различных конфигураций GSR в режиме ’
‘ полной пропускной способности ' '	Л	\ -- J !

Конфигурация GSR	Расчет	Результирующая пропускная  способность
Модель 12008	1,25 Гбит/с х 4 коммутирующие платы х 40 Гбит/с 8 разъемов
Модель 12012	1,25 Гбит/с х 4 коммутирующие платы х 60 Гбит/с  12 разъемов
Модель 12016	1,25 Гбит/с х 4 коммутирующие платы х 80 Гбит/с  16 разъемов

Конфигурация в режиме одной четвертой пропускной способности поддерживает
скорость передачи 1,25 Гбит/с на каждый разъем в полнодуплексном режиме. В
табл. 7.2 приведены расчеты результирующей пропускной способности для каждой
конфигурации в режиме с одной четвертой пропускной способности.

 Таблица 7.2. Определение результирующей пропускной способности .

. коммутирующей структуры для различных конфигураций маршрутизаторов J
\ GSR в режиме с одной четвертой пропускной способности	J

Конфигурация GSR	Расчет	Результирующая пропускная способность
Модель 12008	1,25 Гбит/с х 8 разъемов	10 Гбит/с
Модель 12012	1,25 Гбит/с х 12 разъемов	15 Гбит/с
Модель 12016	1,25 Гбит/с х 16 разъемов	20 Гбит/с

В режиме с одной четвертой пропускной способности данные, передаваемые ли-
нейным адаптером, сегментируются на ячейки одинакового объема и передаются че-
рез единственное соединение с активной платой CSC.

Внимание!

При конфигурировании маршрутизаторов Cisco 12000 в режиме с полной пропускной
способностью настоятельно рекомендуется использовать резервную плату. Фвктиче-
ски в системвх с высокоскоростными интерфейсными адвптервми, такими как Gigabit
Ethernet, Fast Ethernet, DPT, OC-48/STM-16 или 4xOC12, использование режима с
полной пропускной способностью является обязательным. Также следует заметить,
что коммутирующая структура обеспечивает передачу данных только в двух режи-
мах— с полной пропускной способностью и с одной четвертой пропускной способно-
сти. Нет никакой возможности получить половину или три четвертых от полной пропу-
скной способности. Кроме того, корпорация Cisco не производит системы с режимом
одной четвертой пропускной способности.
В примере 7.1 результат выполнения команды show controller fia позволяет опреде-
лить режим работы коммутирующей структуры. В данном случае коммутирующая струк-
тура не имеет резервных компонентов, что означает наличие только одной платы CSC.

Внимание!

Маршрутизаторы модели 12016 могут быть модернизированы с использованием усо-
вершенствованной коммутирующей структуры на основе перекрестной структуры раз-
мером 64x64, которая обеспечивает пропускную способность до 5 Гбит/с на каждую
плату (разъем) в полнодуплексном режиме. Усовершенствованная коммутирующая
структура в режиме с полной пропускной способностью обеспечивает скорость пере-
дачи 20 Гбит/с (5 Гбит/сх4) на каждый разъем, что необходимо для поддержки линей-
ного адаптера ОС-192. На момент написания данной книги усовершенствованная
коммутирующая структура недоступна и находится в разработке.

Блокировка в конце линии

Блокировка в конце линии может значительно ограничить пропускную способ-
ность коммутатора на основе перекрестной структуры. Суть данного эффекта показа-
на на рис. 7.4.

На рис. 7.4 показаны четыре линейных адаптера, подключенных к перекрестной ком-
мутирующей структуре. Пакеты пронумерованы в соответствии с номером выходного ли-
нейного адаптера для данного пакета. Один пакет, который направляется в линейный
адаптер с номером 3, не может быть передан, пока три пакета, предназначенных для ли-
нейного адаптера 4, не будут переданы через коммутирующую структуру. Эффект задерж-
ки передачи данных (или ячеек) пакетами, находящимися впереди и предназначенными
для передачи в другой линейный адаптер, называется блокировкой в конце линии.

В коммутаторах GSR описанная выше проблема решается с помощью виртуальных
выходных очередей (virtual output queue), как показано на рис. 7.5.
Пакеты или ячейки, предназначенные для каждого отдельного адаптера, помеща-
ются в отдельную очередь, которая называется виртуальной выходной очередью и по-
зволяет устранить проблему блокировки в конце линии. По умолчанию очереди яв-
ляются простыми (FIFO1), однако возможно использование и других алгоритмов, на-
пример Modified Deficit Round Robin2 (MDRR), Weighted Random Early Detection’
(WRED), что позволяет обеспечивать качество обслуживания (QoS) в маршрутизато-
рах серии 12000 на уровне коммутирующей структуры. Более детально механизмы
QoS описаны в главе 8 “Качество обслуживания”.

Ячейки корпорации Cisco

Блок данных, который передается через коммутирующую структуру как одно це-
лое, всегда представляет собой пакет фиксированного размера, называемый Cisco cell
(ячейка корпорации Cisco). Пакеты фиксированного размера значительно легче ком-
мутировать, чем пакеты переменного размера. Пакеты разбиваются на ячейки перед
помещением в структуру и собираются обратно выходным линейным адаптером для
последующей передачи. Ячейки Cisco имеют размер 64 байт: размер заголовка — 8
байт, полезный объем — 48 байт и контрольная сумма (CRC) — 8 байт.

Шина обслуживания

Шина обслуживания (Maintenance, Bus — MBUS) представляет собой шину последова-
тельной передачи с пропускной способностью 1 Мбит/с, которая подключена к процессо-
ру маршрутизации, линейным адаптерам, платам коммутирующей структуры, источникам
питания, вентиляторам. Шина MBUS, как ясно из названия, используется для обслужива-
ния системы. Во время начальной загрузки маршрутизатора процессор маршрутизации ис-
пользует шину MBUS для опроса устройств в системе; начальной загрузки линейных адапте-
ров; для сбора номеров версий устройств, данных о среде окружения и другой информации.
Данные, с которыми работает маршрутизатор, никогда не передаются через шину обслужи-
вания, а всегда коммутируются с помощью перекрестной структуры, при этом шина MBUS
используется только для целей управления компонентами маршрутизатора.

Гигабитовый процессор маршрутизации

Гигабитовый процессор маршрутизации, часто также называемый GRP, является
“мозгом” системы. Процессор GRP обеспечивает работу протоколов маршрутизации,
вычисляет элементы таблиц перенаправления пакетов (forwarding tables) и распростра-
няет их всем линейным адаптерам через коммутирующую структуру. На рис. 7.6 пока-
заны наиболее важные компоненты устройства GRP, которые описаны ниже.

	Центральный процессор GRP маршрутизатора марки R5000, аналогичный исполь-
зуемому в устройствах серии Cisco 7500 модели RSP4, в основном выполняет инст-
рукции, связанные с протоколами маршрутизации, и обслуживает основную копию
таблицы CEF, которая загружается в линейные адаптеры, коммутирующие пакеты.

	Основная память (DRAM). Память объемом до 256 Мбайт, которая используется для
хранения исполняемого кода операционной системы 1OS и всех структур данных.

	Регистр адресов управляющей статической памяти (CSAR SRAM). Статическая
память (SRAM) имеет объем 512 Кбайт и используется для сборки пакетов из
ячеек, которые поступают из коммутирующей структуры.

7 First /п First Out — обработка данных в порядке их поступления. — Прим, перев.

2 Буквально — модифицированная круговая схема с учетом нехватки. — Прим, перев.

3 Буквально — взвешенное случайное определение на ранних этапах. — Прим, перев.
 Контроллер Ethernet используется для экстренного (out-of-band) управления. Данные
между указанным портом и портами линейных адаптеров передаваться не должны.

Рис. 7.6. Процессор маршрутизации

Линейный адаптер

Большую часть пакетов коммутируют линейные адаптеры. В каждом линейном
адаптере можно выделить три основные части.

•	Модуль интерфейса физического уровня (Physical Layer Interface Module, или
PLIM). Специфичный для различных физических сред передачи (ATM,
POS, Fast Ethernet) аппаратный модуль, который является терминалом фи-
зического соединения.

•	Интерфейс коммутирующей структуры подготавливает пакеты для передачи в
линейный адаптер назначения через коммутирующую структуру.

•	Устройство перенаправления пакетов осуществляет коммутацию пакетов. На мо-
мент написания книги существовало три типа устройств перенаправления паке-
тов: устройства типа 0, 1 и 2. Линейные адаптеры, систематизированные по ти-
пу устройства перенаправления пакетов, приведены в табл. 7.3. Устройство типа
О было первым устройством перенаправления пакетов, которое использовалось
в ранних версиях линейных адаптеров для маршрутизаторов GSR. Линейные
адаптеры на базе устройств типа 1 содержат некоторые усовершенствования,
позволяющие улучшить качество коммутации пакетов. Устройства перенаправ-
ления типа 2 обладают еще большей производительностью и позволяют реали-
зовать аппаратно основные функции технологии качества обслуживания (QoS).

Таблица 7.3. Классификация линейных адаптеров для маршрутизаторов
GSR по типу устройства перенаправления пакетов ;	. j

Линейный адаптер	Устройство	Устройство	Устройство	пере-

GSR	перенаправления типа 0 перенаправления типа 1 направления типа 2

ОС-12 PoS	X

4хОС-3 PoS	X

От ОС-12 с разделе-	X

нием каналов до DS-3

ОС-12 ATM	X
Окончание табл. 7.3

6 и 12 портовые X
DS-3

Time to Market
(TTM) OC-48 PoS

ТТМ 4хОС-12 PoS

1 х Gigabit (GE)

8 x Fast Ethernet

1	xOC-12 DPT

Enhanced OC-48 PoS

Enhanced 4xOC-12
PoS

x

X

X

X

X

X

X

Назначение первых двух компонентов линейных адаптеров ясно из их названия.
Устройство перенаправления пакетов является “сердцем” линейного адаптера, его
структура детально описана в следующем разделе.

Устройства перенаправления пакетов

На момент написания данной книги существовали три типа устройств перенаправ-
ления пакетов (устройства типа 0, 1, 2). На рис. 7.7 показаны их основные элементы
для типов 0, 1 и линейных адаптеров. Общими для всех типов устройств перенаправ-
ления являются основная и пакетная память (для приема и передачи).

Основная память

Динамическая память (DRAM) объемом до 256 Мбайт служит для хранения ис-
полняемых инструкций и соответствующих структур данных (таких как CEF-таблицы
и таблицы соседства) операционной системы IOS линейных адаптеров.

Пакетная память

Каждый адаптер LC имеет до 256 Мбайт (до 128 Мбайт для устройств типа 0) статиче-
ской памяти (SRAM), которая разделена на две равные части — приемную и передающую
память. В примере 7.2 показан результат выполнения команды show diag, который позво-
ляет определить объем передающей и приемной памяти в линейном адаптере.

Пример 7.2. Определение объема приемной и передающей памяти по результатам ]
।	выполнения команды show diag . i .	...	....	|

Router# show diag 1

SLOT 1 (RP/LC 1 ): 4 Port Packet Over SONET OC-3C/STM-1 Multi Mode

FrFab SDRAM size: 67108864 bytes

ToFab SDRAM size: 67108864 bytes

Значения параметров вывода команды в примере 7.2 — следующие.

•	FrFab SDRAM (статическая память FrFab) — передающая пакетная память.

•	ToFab SDRAM (статическая память ToFab) — приемная пакетная память.
_______________________। Интерфейс коммутирующей '	,
!	структуры	,	I

Рис. 7.7. Устройства перенаправления пакетов типов 0 и 1

Приемная пакетная память разбивается на пулы пакетных буферов. Чтобы увидеть,
как произведена разбивка памяти, необходимо присоединиться к соответствующему
линейному адаптеру (attach) и выполнить команду show controller tofab queue, как по-
казано в примере 7.3.

Пример 7.3. Определение распределения приемной памяти нй" пулы пакетных	-и 5 г

буферов по результатам выполнения команды show controller tofab queue Q:

LC-Slotl#show controller tofab queue
Carve information for ToFab buffers
SDRAM size: 67108864 bytes, address: 38000000, carve base: 30019100
67006208 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize,
3 carvels)
max buffer data size 4544 bytes, min buffer data size 80 bytes
65534/65534 buffers specified/carved
66789056/66789056 bytes sum buffer sizes specified/carved

Qnum Head	Tail #Qelem	LenThresh

4 non-IPC free queues:
26174/26174 (buffers specified/carved), 39.93%, 80 byte data size
1	101	26274	26174	65535

19630/19630 (buffers specified/carved), 29.95%, 608 byte data size
2	26275	45904	19630	65535
13087/13087 (buffers specified/carved), 19.96%,1568 byte data size

3	45905	58991	13087	65535

6543/6543 (buffers specified/carved) , 9.98%, 4544 byte data size

4	58992	65534	6543	65535	
IPC Queue:				
100/100 (buffers	specified/carved),	, 0.15%,	4112 byte data	size
30	7	6	100	65535	
Raw Queue:				
31	0	0	0	65535	
ToFab Queues:				
Dest				
Slot				
0	0	0	0	65535
1	0	1	0	65535
2	0	0	0	65535
3	0	0	0	65535
4	0	0	0	65535
5	0	0	0	65535
6	0	0	0	65535
7	0	0	0	65535
8	0	0	0	65535
9	0	0	0	65535
10	0	0	0	65535
11	0	0	0	65535
12	0	0	0	65535
13	0	0	0	65535
Multicast	0	0	0	65535

Ключевые поля в результате вывода команды из примера 7.3 описаны ниже.

	SDRAM size: 67108864 bytes, address: 30000000, carve base:30019100 — параметр пока-
зывает размер области приемной пакетной памяти и адрес начала данной области.

	max buffer data size 4544 bytes, min buffer data size 80 bytes — максимальный и
минимальный размеры буфера.

	65534/65534 buffers (specified/carved) — количество буферов, заданное операци-
онной системой 1OS, и количество реально выделенных буферов.

	4 non-IPC free queues — буферные пулы, не связанные с межпроцессным взаи-
модействием (поп-IPC), являются только пакетными буферами. Для пакетов,
поступающих в линейный адаптер, выделяются буферы из определенного бу-
ферного пула, в зависимости от размера пакета. В приведенном выше примере
показано четыре буферных пула соответственно для размеров 80, 608, 1568 и
4544 байт. Ниже приводится более детальная информация о каждом из них.

•	26174/26174 (buffers specified/carved), 39.93 %, 80 byte data — 39,93 процента
от приемной пакетной памяти разделено на 26174 буфера размером 80 байт.

•	Qnum — номер очереди.

•	#Qelem — число буферов в очереди.

	IPC Queue — очередь для межпроцессного взаимодействия, как, например, пе-
редача сообщений от процессора маршрутизации к линейным адаптерам.

	Raw Queue. Пакет, который приходит в линейный адаптер и которому назначен
буфер из очереди non-IPC Queue, помешается в очередь Raw Queue. Данная
очередь является простой (типа FIFO) и обрабатывается центральным процес-
сором линейного адаптера во время обработки прерываний.
	ToFab Queues — виртуальные выходные очереди. Существуют по одной очереди для
каждого разъема выходного адаптера и одна очередь для данных с множеством уст-
ройств назначения (multicast). Выделенный текст в примере 7.3 соответствует мар-
шрутизатору модели 12012 с 15 виртуальными очередями. Модель 12012 первона-
чально разработана для шасси с 15 слотами. Очереди от 13 до 15 не используются.

Как только центральный процессор входного линейного адаптера принимает
решение о коммутации пакета, данный пакет помешается в виртуальную оче-
редь, соответствующую разъему, в котором находится линейный адаптер назна-
чения. Значение в четвертой колонке соответствует числу пакетов, поставлен-
ных в виртуальную выходную очередь.

Передающая пакетная память также разбита на пулы. Подключение к соответст-
вующему адаптеру и выполнение команды show controller frfab queue позволяет
увидеть состояние передающей пакетной памяти. Единственное поле, которым
отличается вывод данной команды от примера 7.3, — это колонка Interface
Queues (колонка номер 4 в следующем списке).

0000	65535

1000	65535

2000	65535

3000	65535

Для каждого линейного адаптера существует одна очередь Interface Queue, в ко-
торую помешаются пакеты, приходящие из соответствующего линейного адап-
тера. Только что были рассмотрены элементы, общие для всех типов устройств
перенаправления пакетов, далее будут рассмотрены детали, специфичные для
каждого из устройств.

Линейный адаптер с устройством перенаправления типа 0

Каждое устройство перенаправления типа 0 имеет две специализированные микро-
схемы менеджера буферов (Buffer Manager ASIC — ВМА), соответствующие менедже-
рам буферов приема и передачи на рис. 7.7, которые управляют пакетными буферами,
осуществляют фрагментацию и сборку пакетов для передачи через коммутирующую
структуру. Приемный менеджер буферов отвечает за прием пакетов из модуля РЫМ,
фрагментацию пакетов на ячейки фиксированного размера и передачу ячеек в спе-
циализированную микросхему интерфейса коммутирующей структуры (Fabric Interface
ASIC — FIA) для передачи через структуру. Менеджер буферов передачи с помощью
микросхемы FIA осуществляет сборку пакетов из ячеек, которые приходят из комму-
тирующей структуры, и передает пакеты в модуль РЫМ для отправления их дальше.

Главная задача центрального процессора устройства перенаправления типа 0 —
коммутация пакетов.

Линейный адаптер с устройством перенаправления типа 1

Общими элементами для устройства перенаправления типов 0 и 1 являются цен-
тральный процессор (ЦП), основная и пакетная память. Функции этих элементов для
устройств перенаправления типа 0 и 1 совпадают. Производительность коммутации
пакетов линейных адаптеров с устройством перенаправления типа 1 выше по сравне-
нию с линейными адаптерами типа 0 благодаря применению новой микросхемы ме-
неджера буферов и усовершенствованного устройства коммутации.

Линейный адаптер с устройством перенаправления типа 2

На рис. 7.8 показаны ключевые компоненты линейного адаптера с устройством
перенаправления типа 2. Основная и пакетная память имеют те же функции, что и
для линейных адаптеров с устройствами перенаправления типов 0 и 1.
Рис. 7.8. Устройство перенаправления пакетов типа 2

В устройстве перенаправления типа 2 применена новая специализированная мик-
росхема коммутации пакетов (Packet Switch ASIC — PSA), которая позволяет значи-
тельно повысить производительность обработки пакетов. В памяти PSA (объемом до
128 Мбайт) хранится локальная копия глобальной CEF-таблицы, которая использует-
ся для поиска записей при коммутации пакетов методом CEF. Все операции по ком-
мутации пакетов в линейном адаптере с устройством перенаправления типа 2 реали-
зованы аппаратно в микросхеме PSA, и центральный процессор линейного адаптера
никогда не обрабатывает прерывания с целью принятия решений по коммутации.
Применение новых и оптимизированных микросхем, также называемых менеджерами
буферов приема (Receive Buffer Manager — RBM) и менеджерами буферов передачи
(Transmit Buffer Manager — ТВМ), позволило аппаратно реализовать поддержку функ-
ций технологии класса обслуживания (Class of Service — CoS) в линейных адаптерах.

Коммутация пакетов

После обзора различных компонентов маршрутизаторов серии Cisco 12000 рас-
смотрим, как они используются для коммутации пакетов. Большинство пакетов, ко-
торые коммутируются маршрутизатором Cisco 12000, коммутируются линейными
адаптерами с помощью метода dCEF. Только управляющие пакеты, такие как пакеты
протоколов маршрутизации, отправляются в процессор GRP для обработки. Схема
прохождения пакетов в маршрутизаторах GSR зависит от типа устройства перена-
правления пакетов в линейных адаптерах. Рассмотрим схемы прохождения пакетов
для различных типов устройств перенаправления.

Коммутация пакетов в устройствах
перенаправления типов 0 и 1

На рис 7.9 показаны этапы коммутации пакетов в линейных адаптерах с уст-
ройствами перенаправления типа 0 и 1.

Рис. 7.9. Схема коммутации пакетов в устройствах перенаправления типов 0 и 1

Схема прохождения пакетов для устройств перенаправления типов 0 и 1 одинако-
ва, хотя линейные адаптеры с устройством типа 1 имеют усовершенствованное уст-
ройство коммутации и менеджер буферов для повышения производительности. Схема
прохождения пакетов приведена ниже.

Этап 1. Интерфейсный процессор (модуль PL1M) определяет наличие пакета в
физической среде передачи и копирует его в память типа FIFO, называе-
мую пакетной памятью (burst memory) линейного адаптера. Объем пакет-
ной памяти в каждом интерфейсном адаптере зависит от его типа и
обычно составляет от 128 Кбайт до 1 Мбайт.

Этап 2. Интерфейсный процессор запрашивает буфер у устройства ВМА. Пул, из
которого предоставляется память, зависит от размера пакета. Если свобод-
ных буферов в соответствующем пуле нет, то пакет отбрасывается и счетчик
игнорированных пакетов (ignore) на интерфейсе увеличивается на единицу.'
Например, если в интерфейс приходит пакет размером 64 байта, устройство
ВМА пытается выделить буфер размером 80 байт. Если в соответствующем
пуле нет свободных буферов, то из другого пула буферы не выделяются.

Этап 3. Если свободный буфер от устройства ВМА получен, то пакет копируется в
него и ставится в очередь RawQ для обработки процессором. Централь-
ному процессору линейного адаптера посылается прерывание.

Этап 4. Центральный процессор обрабатывает каждый пакет в очереди RawQ по
мере поступления (очередь RawQ является простой), обращаясь к локаль-
ной dCEF-таблице для принятия решения о коммутации.

4.1.	Если текущий пакет не является широковещательным (unicast) IP-
пакетом, то в заголовке пакета записывается новая информация,
полученная из таблицы соседства CEF. Пакет ставится в виртуаль-
ную выходную очередь в соответствии со слотом назначения.

4.2.	Если адрес назначения отсутствует в таблице CEF, пакет игнорируется.

4.3.	Если пакет является управляющим (например, обновление табли-
цы маршрутизации), то он ставится в виртуальную выходную оче-
редь процессора GRP.

Этап 5. Менеджер приемных буферов разбивает пакет на ячейки корпорации
Cisco размером по 64 байта и передает их в контроллер F1A для передачи
в выходной линейный адаптер.

На финальной стадии этапа 5 пакет, который пришел в линейный адаптер с уст-
ройством перенаправления типа 0, уже прошел процесс коммутации и готов к переда-
че в форме ячеек через коммутирующую структуру. Далее необходимо перейти к эта-
пу 6, описанному ниже, в разделе “Коммутация ячеек через структуру”.

Коммутация пакетов в устройстве
перенаправления типа 2

На рис. 7.10 показана схема прохождения пакета в линейном адаптере с устройст-
вом перенаправления типа 2. Этапы прохождения пакетов приведены ниже.

Этап 1. Интерфейсный процессор (модуль PLIM) определяет наличие пакета в
физической среде передачи и копирует его в память типа FIFO, называе-
мую также пакетной памятью (burst memory) линейного адаптера. Объем
пакетной памяти в каждом интерфейсном адаптере зависит от его типа и
обычно составляет от128 Кбайт до 1 Мбайт.

Этап 2. Первые 64 байта пакета, называемые заголовком, проходят через микро-
схему коммутации (PSA).

2.1. Микросхема PSA коммутирует пакет в соответствии с локальной
таблицей CEF в памяти PSA. Если коммутация пакета в PSA не-
возможна, то осуществляется переход к этапу 4, в противном слу-
чае обработка данных продолжается на этапе 3.
Рис. 7.10. Схема коммутации пакетов в устройстве перенаправления типа 2

Этап 3. Менеджер приемных буферов (RBM) принимает заголовок от микросхе-
мы PSA и копирует его в свободный буфер пакетной памяти в соответст-
вии с размером пакета, который указан в заголовке. Если размер пакета
больше 64 байт, то остаток пакета копируется в тот же буфер, что и заго-
ловок, и буфер ставится в виртуальную очередь, соответствующую выход-
ному линейному адаптеру. Далее выполняется этап 5.

Этап 4. Пакет, полученный на первом этапе, не был перенаправлен с помощью мик-
росхемы PSA. Такие пакеты ставятся в очередь RawQ, далее схема коммута-
ции пакета аналогична той, что используется в устройствах перенаправления
типов 0 и 1 (этап 4 для устройства типа 0). Следует заметить, что пакеты, ко-
торые прошли коммутацию в микросхеме PSA, никогда не попадают в оче-
редь RawQ и центральному процессору не посылается прерывание.

Этап 5. Модуль интерфейса коммутирующей структуры (FIM) отвечает за фраг-
ментацию пакетов в ячейки корпорации Cisco и передачу ячеек в интер-
фейс структуры (FIA) для передачи в выходной адаптер.
Коммутация ячеек через структуру

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

Этап 6. Микросхема FIA посылает запрос на получение доступа плате CSC, кото-
рая планирует каждую передачу ячеек через структуру.

Этап 7. Когда планировщик разрешает доступ к коммутирующей структуре, все
ячейки пересылаются в слот назначения. Заметим, что не все ячейки па-
кета могут быть переданы за один раз, ячейки из разных пакетов могут
передаваться попеременно.

Передача пакетов при коммутации

На рис. 7.11 показано прохождение ячеек в выходном линейном адаптере.

Рис. 7.11. Передача пакетов при коммутации в маршрутизаторах GSR
Этап 8. Ячейки, которые прошли через коммутирующую структуру, попадают в
выходной линейный адаптер через микросхему F1A.

Этап 9. Менеджер буферов передачи выделяет буфер из передающей пакетной
памяти и собирает пакет из ячеек в данном буфере.

Этап 10. Когда пакет восстановлен, микросхема менеджера буферов передачи
ставит его в очередь передачи выходного интерфейса линейного адапте-
ра. Если очередь передачи интерфейса переполнена (пакет не может
быть поставлен в очередь), то пакет отбрасывается и счетчик пакетов,
отброшенных на выходе (output drop), увеличивается на единицу.

Внимание!

На этапе передачи пакет может быть поставлен в очередь RawQ, если центральный про-
цессор должен обработать его перед отправкой. Примерами подобной обработки может
быть IP-фрагментация, широковещательная передача для многих получателей (multicast)
или маршрутизация с централизованным доступом (Central Access Routing — CAR).

Этап 11. Интерфейсный процессор определяет, что в передающей очереди находится
пакет, считывает его из передающей пакетной памяти, копирует во внут-
реннюю память типа FIFO и передает пакет в физическую среду передачи.

Резюме

В данной главе описаны наиболее важные элементы маршрутизаторов Cisco 12000,
которые коренным образом отличаются от архитектур маршрутизаторов Cisco с памя-
тью совместного доступа или обшей шиной. Использование перекрестной коммути-
рующей структуры позволило обеспечить очень высокую пропускную способность и
масштабируемость в устройствах серии 12000. Более того, в маршрутизаторах данной
серии используются виртуальные выходные очереди, которые позволяют избежать
блокировки в конце линии внутри коммутирующей структуры.

Основная часть операций коммутации пакетов в маршрутизаторах Cisco 12000 рас-
пределена между линейными адаптерами. В большинстве случаев коммутация пакетов
осуществляется специализированной выделенной микросхемой. Единственным дос-
тупным методом коммутации является dCEF.

Ключевые темы этой главй'

-	™	А

	Обзор технологиироа

 Метод приоритетной очередности

 Метод настраиваемой очереди

-.У;, -,

	Метод-справедливой взвешенной очереди...;

	Механизм .циклически изменяемогодефииита

	Мёханизм’&учайного раннеийсюнаруженйя

	.Механизм выборочного.Дннулирования пакетов

	^Цругие возможности QoSr







&






Глава

8





'’Д'

Качество обслуживания





Возрастающие возможности цифровых сетей дали мощный импульс развитию ин-
фраструктуры, обеспечивающей передачу потоков всех видов информации — видео,
аудио и цифровых1 данных; Одна из проблем, с которыми сталкиваются сетевые ин-
теграторы при объединении звуковой информации, видео и цифровых данных в одну
сеть, — это различные требования к качеству обслуживания соединения при передаче
разных типов данных через сеть^^

 Для передачи»видеоинформации необходимы высокая пропускная способность
и стабильное 'время задержки; при передаче данных. Задержка не обязательно
Л. должна бьггь небольшой (кроме случаев интерактивного обмена видео), но для
избежания эффекта “снега” , и других искажений изображения необходим ста-
Сильный поток данных.

1	• •	* X г-’	l'F	??

<	 Интерактивная передача звука требует меньшей пропускной способности кана-

'ла, чем поток видеоданных, но'необходима малая временная задержка при пе-
редаче через сеть Избыточная задержка при передаче звука приводит к такому
трудно устраняемому искажению, как “эхо”.

 Интерактивное терминальное соединение, например Telnet, требует малого
времени задержки при передаче данных. Непостоянная задержка обычно не
влияет на качество соединения, .в отличие от постоянно присутствующих боль-
ших задержек, которые метут привести к ухудшению качества соединения и
вызвать недовольство пользователей.

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

Каким же образом единая инфраструктура обеспечивает передачу всех типов дан-
ных? Для этого используются различные механизмы обеспечения качества обслужи-
вания (Quality of Service mechanisms, или QoS mechanisms) для распределения потоков
данных в зависимости от типа передаваемой информации.

Подробный анализ всех методов и протоколов QoS невозможен в рамках данной
книги, поэтому рассмотрим, каким образом в системе IOS реализованы основные ме-
ханизмы технологии QoS,

Лк#

Обзор технологии QoS

-	-.г'.	.«.•

Рассмотрим простую сеть из двух компьютеров, соединенных единственным кана-
лом. В идеальном случае эти компьютеры могут передавать и принимать необходимое
количество данных, не заботясь о задержке при передаче информации. Единственное,
что ограничивает количество передаваемых файлов, звуковых соединений и видеосес-
сий между ними, — это производительность процессора. Фактически они имеют вы-
деленный канал с бесконечной пропускной способностью!

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

В предыдущих главах были рассмотрены простые механизмы организации очере-
дей, используемые в операционной системе IOS. В большинстве случаев применяются
FIFO-очереди (first-in, first-out). При достаточной пропускной способности канала и
высокой производительности коммутации очередь FIFO удовлетворяет всем требова-
ниям для различного типа трафика.

Чтобы понять, почему технология FIFO не всегда может удовлетворить все требо-
вания, рассмотрим модель простой сети (рис. 8.1).

Рис. 8. J. Технология QoS в простой сети

Предположим, что пропускная способность каждого соединения равна 10 Мбит/с
и маршрутизатор может коммутировать суммарные потоки до 50 Мбит/с. Если сред-
няя скорость передачи данных для всех машин составляет 700 Кбайт/с с временными
пиками до 5 Мбайт/с, то FIFO-очередь на маршрутизаторе справится со всеми зада-
чами и интерфейсы маршрутизатора всегда будут иметь пустую очередь на отправку.

Увеличим пиковые повышения скорости передачи с 5 до 10 Мбайт/с. Это быстро
выявит слабые стороны использования рассматриваемой очереди FIFO. Маршрутиза-
тор может обрабатывать пять Ethernet-интерфейсов, работающих на полной скорости,
следовательно, его мощности достаточно для коммутации всех пакетов. Но если две
машины, А и В, попытаются послать поток в 10 Мбит/с к машине С одновременно,
то обший поток данных, приходящих на маршрутизатор (20 Мбит/с), превысит про-
пускную способность исходящего интерфейса.

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

Описанная проблема становится все более и более заметной при значительном отличии
в скорости соединений по пути следования данных. Например, если соединение к компь-
ютеру С (см. рис. 8.1) заменить на канал Т1 с пропускной способностью 1,544 Мбит/с, то
временное увеличение потока данных только с одного Компьютера может перегрузить ин-
терфейс к машине С на маршрутизаторе. Фактически пропускной способности канала Т1
едва хватает для обеспечения средней скорости передачи данных с компьютеров А и В.

Для обеспечения необходимых требований к различным потокам данных исполь-
зуются две основные методики технологии QoS: управление перегрузками (congestion
management) и предотвращение перегрузок (congestion avoidance). Управление перегруз-
ками подразумевает помещение пакетов в очередь и попытку минимизировать за-
держки отправки пакетов для различных типов данных путем отправки пакетов из
очереди в порядке, который удовлетворяет их уровню привилегий. Методика избежа-
ния перегрузок состоит в попытке ограничить размер очереди, сигнализируя источни-
кам данных о необходимости уменьшить скорость передачи информации.

Управление перегрузками

Методы управления перегрузками отличаются тем, как классифицируются пакеты
и в каком порядке из очереди выбираются пакеты для отправки. В операционной сис-
теме IOS существуют два основных типа методов управления перегрузками: аппарат-
но-независимый и аппаратно-зависимый. Аппаратно-независимые методы доступны
на большинстве маршрутизаторов Cisco и выполняются основным процессором, на-
пример, таким, как RSP (Route Switch Processor) в маршрутизаторах Cisco серии 7500.
Аппаратно-зависимые методы реализованы в многоцелевых контроллерах интерфей-
сов и доступны только на определенных моделях маршрутизаторов.

В настоящее время существуют два аппаратно-зависимых метода управления перегруз-
ками: метод распределенной справедливой взвешенной очереди (Distributed Weighted Fair
Queuing — DWFQ) и метод циклически изменяемого дефицита (Modified Deficit Round
Robin — MDRR). Метод DWFQ реализован в универсальном интерфейсном процессоре
(Versatile Interface Processor — VIP) для маршрутизаторов Cisco серии 7500, а метод MDRR
реализован в линейных адаптерах маршрутизаторов Cisco серии 12000.

Аппаратно-независимые методы управления перегрузками, реализованные в сис-
теме IOS, включают:

	метод приоритетной очереди (Priority Queuing — PQ);

	метод настраиваемой очереди (Custom Queuing — CQ);

	метод справедливой взвешенной очереди (Weighted Fair Queuing — WFQ).

•	WFQ, основанный на потоках (Flow-Based WFQ — FBWFQ);

•	WFQ, основанный на классах (Class-Based WFQ — CBWFQ).

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

Внимание!

Аппаратно-независимые методы управления перегрузками в системе IOS применяют-
ся между буфером интерфейса и очередью на отправку (или передающим кольцом
интерфейса). Очередь на отправку— это FIFO-очередь; когда пакет помещается в
выходную очередь интерфейса, он задерживается для отправки по физической линии
передачи данных. Таким образом, для того, чтобы любой пакет обрабатывался одним
из методов управления перегрузками, его необходимо поместить а очередь интер-
фейса прежде, чем в очередь на отправку.

Как операционная система IOS определяет, что пакет необходимо поместить в оче-
редь на исходящем интерфейсе, а не в очередь на отправку?

•	Если пакет обрабатывался методом программной коммутации (или сгенерирован
самой системой IOS), он всегда помещается в очередь на интерфейсе, а не в оче-
редь на отправку далее.
•	Если очередь на отправку заполнена, любой пакет помещается а очередь на ин-
терфейсе.

•	Кроме того, если хотя бы один пакет находится в выходной очереди, любой пакет,
адресованный этому интерфейсу, помещается в очередь на данном интерфейсе.

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

Как много пакетов необходимо поместить в очередь на отправку для ее заполнения?
Это зависит от аппаратных особенностей маршрутизатора и интерфейса. Если на ин-
терфейсе включен любой из методов управления перегрузками, тогда автоматически
уменьшается размер очереди на отправку. Это позволяет повысить эффективность
управления перегрузками.

В дальнейшем во всех примерах будут рассматриваться перегруженные интерфейсы.

Предотвращение перегрузок

Основная задача алгоритмов предотвращения перегрузок — не допустить ситуации,
при которой пропускной способности интерфейса недостаточно для передачи всего по-
тока данных. Среди методов предотвращения перегрузок, используемых системой 1OS,
можно выделить два основных типа: аппаратно-зависимые и аппаратно-независимые
алгоритмы. Аппаратно-независимые методы выполняются основным процессором, та-
ким как RSP (Route Switch Processor) в маршрутизаторах Cisco серии 7500. Аппаратно-
зависимые методы реализованы в многоцелевых контроллерах интерфейсов и доступны
только на определенных типах маршрутизаторов. В данной главе будет рассмотрен один
из аппаратно-независимых методов ликвидации перегрузок — взвешенное случайное
раннее обнаружение перегрузки (Weighted Random Early Detection — WRED).

Использование приоритетной очереди

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

Приведенное сравнение примерно описывает, каким образом реализована приори-
тетная очередь на маршрутизаторах. Пакеты классифицируются на основании на-
страиваемых правил и помещаются в очередь. Реализация приоритетной очереди в
операционной системе IOS содержит 4 различные подочереди (кассы в приведенной
выше аналогии): high, medium, normal и low (высокоприоритетная очередь, очереди со
средним приоритетом, нормальным приоритетом и низкоприоритетная).

Высокоприоритетная очередь должна быть пустой для обслуживания очереди со
средним приоритетом. Аналогично должна быть пустой очередь среднего приоритета
для обслуживания очереди с нормальным приоритетом. И, наконец, для обслужива-
ния низкоприоритетной очереди все остальные очереди не должны содержать пакетов.

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

Конфигурирование и контроль механизма приоритетной очереди

В примере 8.1 показано, как можно настроить очередь приоритетов.

j Пример 8.^ Конфигурирование очереди приоритетов .	< д	<>„

access-list 110 permit ip host 10.1.1.1 any

access-list 120 permit ip host 172.16.28.1 any

access-list 130 permit ip any any
i

priority-list 1 protocol ip high list 110

priority-list 1 protocol ip medium list 120

priority-list 1 protocol ip normal list 130
i

interface SerialO
priority-group 1

Пусть, например, маршрутизатор отправляет через интерфейс SerialO следующие пакеты:

 rtghwrtwg

•	первый пакет — отправитель 172.18.40.8, получатель 192.168.40.8;

•	второй пакет — отправитель 10.1.1.1, получатель 192.168.40.8;

•	третий пакет — отправитель 172.18.40.8, получатель 192.168.10.1;

•	четвертый пакет — отправитель 10.1.1.1, получатель 192.168.10.1;

•	пятый пакет — отправитель 172.16.28.1, получатель 192.168.10.1;

•	шестой пакет — отправитель 172.18.40.8, получатель 192.168.20.56.

Указанные пакеты сначала распределяются по очередям: высокого приоритета,
среднего приоритета и нормального приоритета. Распределение проводится на осно-
вании списков доступа (access list), связанных с командой priority-list. Результат рас-
пределения показан на рис. 8.2.

Высокий приоритет

Средний приоритет

Нормальный приоритет

<	Пакет №4	Пакет №2
		Пакет №5
Пакет №6	Пакет №3	Пакет №1

Рис. 8.2. Распределение пакетов на основе команды priority-list

После распределения пакетов по очередям операционная система IOS обслуживает
высокоприоритетную очередь до тех пор, пока там не останется пакетов. В нашем
примере будут отправлены пакеты №2 и №4. Затем система IOS отправляет пакеты из
очереди среднего приоритета — пакет №5. И в последнюю очередь, когда очереди с
высоким и средним приоритетом пусты, отправляются оставшиеся пакеты из очереди
с нормальным приоритетом.

Однако с момента начала отправки пакетов другие пакеты продолжают приходить
и помещаться в соответствующие очереди. Если достаточное количество пакетов при-
ходит в очереди высокого и среднего приоритета, то система IOS не будет отправлять
пакеты из очереди с нормальным приоритетом. Любые приложения или устройства,
которые будут использовать очередь с нормальным (normal) приоритетом для переда-
чи данных, просто не смогут функционировать.

Для контроля параметров настройки очереди приоритетов используется команда
show queueing priority.

> Пример 8.2. Использование команды вЬоуу queueing priority для получения
	информации р состоянии.очереди приоритетов	ц

murka#show queueing priority

Current priority queue configuration:

List	Queue	Args			
1	high	protocol	ip	list	110
2	medium	protocol	ip	list	120
3	normal	protocol	ip	list	130

Информация, выводимая командой show queueing priority, обобщает текущую кон-
фигурацию очереди приоритетов, при этом не предоставляя никакой дополнительной
информации о количестве пакетов, которые находятся или игнорированы в каждой
очереди.1 Для получения такой информации необходимо использовать команду show
interface, как показано в примере 8.3.

j Пример 8.3. Команда show interface используется для получения информации о i
прохождении потоков данных через очереди	л

murka#show interface serial 0/0

Serial0/0 is up, line protocol is up

Queueing strategy: priority-list 1

Output queue (queue priority: size/max/drops):

high:0/20/397,medium:0/40/0,normal:0/60/3024, low:0/80/0

С помощью команды show interface (см. пример 8.3) можно определить тип исполь-
зуемого механизма управления перегрузками (в поле Queueing strategy), номер группы
приоритетов (priority group), примененной к данному интерфейсу, количество пакетов
в очереди, размер очереди и количество пакетов, игнорированных в каждой очереди.

Максимальный размер каждой очереди может быть изменен с помощью команды
операционной системы IOS priority-list list-number queue-limit.

Настраиваемые очереди

Настраиваемые очереди — это один из аппаратно-независимых механизмов управ-
ления перегрузками, который очень похож на механизм приоритетной очереди. На-
страиваемые очереди позволяют более справедливо обслуживать различные потоки и,
в отличие от механизма приоритетной очереди, не блокируют низкоприоритетный
трафик. Вернемся к рассмотренному выше примеру с бакалейным магазином. Допус-
тим, что теперь кассир обслуживает только определенное количество человек со спе-
циальными карточками, а потом переходит к другой кассе и наоборот. Теперь кассир
выбирает между двумя очередями, обслуживая в одной очереди разрешенное количе-
ство покупателей, прежде чем перейти к другой.

' Игнорирование пакетов происходит при переполнении какой-либо из очередей. Пакет просто не
обрабатывается маршрутизатором и теряется. — Прим, перев.
Рассматриваемый механизм поддерживает до 16 отдельных очередей, для каждой
из которых определено количество байт, которое необходимо отправить прежде, чем
система 1OS перейдет к следующей очереди.

Внимание!

На самом деле в механизме настраиваемых очередей, который реализован в операцион-
ной системе IOS, — это 17 различных очередей, но пользователь не может направить ка-
кой-либо пакет в нулевую очередь. Данная очередь зарезервирована для управляющих
данных, таких как пакеты обновления таблиц маршрутизации и тестовые пакеты.

Рассмотрим конфигурацию в примере 8.4 и распределение пакетов по очередям.

Пример 8.4. Пример настраиваемой очереди	~

access-list 110 permit ip host 10.1.1.1 any

access-list 120 permit ip host 172.16.28.1 any

queue-list	1	protocol	ip 1 list	110
queue-list	1	protocol	ip 2 list	120
queue-list 1	1	default	3	
queue-list	1	queue 1	byte-count	1000
queue-list	1	queue 2	byte-count	1000
queue-list	1	queue 3	byte-count	2000

i

interface Serial 0
custom-queue-list 1

Предположим, что система IOS получила следующий набор пакетов для коммута-
ции через интерфейс Serial 0:

•	первый пакет — отправитель 172.18.40.8, длина 100 байт;

•	второй пакет — отправитель 10.1.1.1, длина 500 байт;

•	третий пакет — отправитель 172.18.40.8, длина 100 байт;

•	четвертый пакет — отправитель 10.1.1.1, длина 1000 байт;

•	пятый пакет — отправитель 172.16.28.1, длина 200 байт;

•	шестой пакет — отправитель 172.18.40.8, длина 100 байт;

•	седьмой пакет — отправитель 10.1.1.1, длина 100 байт.

После классификации рассмотренных семи пакетов очередь будет выглядеть как на
рис. 8.3.

Очередь I	Пакет 7/100	Пакет 4/1000	Пакет 2/500
Очередь 2			Пакет 5/200
Очередь 3	Пакет 6/100	Пакет 2/100	Пакет 1/100

Рис. 8.3. Начальное распределение пакетов для примера настраиваемой очереди

Операционная система 1OS начинает цикл обработки трафика с очереди №1; первый па-
кет именно этой очереди передается по назначению, и алгоритм освобождает занимаемое им
место. Для рассматриваемой очереди первым будет пакет №2, длина которого равна 500 байт.
Его размер вычитается из разрешенного для указанной очереди количества байт — 1000. По-
еле вычитания остаются неиспользованными 500 байт, и поскольку полученное число боль-
ше нуля, передается следующий пакет — пакет №4. Он отправляется к месту назначения че-
рез выходной интерфейс, и система освобождает занимаемое им место.

После пересылки пакета №4 для первой очереди разрешенное к передаче число
байт будет меньше нуля (от оставшихся 500 байт необходимо отнять длину пакета
№4 — 1000 байт), поэтому система IOS переходит к обработке второй очереди. На
рис. 8.4 демонстрируется состояние очередей после обработки первой очереди.

Теперь передается пакет №5 из второй очереди, и его размер вычитается из общего ко-
личества байт, разрешенных для этой очереди. После вычитания параметр разрешенных к
передаче байт имеет значение 800, но в данной очереди больше нет пакетов для отправки.
На рис. 8.5 показано состояние настраиваемой очереди после выполнения второго этапа.

Очередь 1			Пакет 7/100
Очередь 2			Пакет 5/200
Очередь 3	Пакет 6/100	Пакет 3/100	Пакет 1/100

Рис. 8.4. Распределение пакетов в очереди после однократной обработки
первой очереди

Очередь 1	Пакет 7/100
Очередь 2	
Очередь 3	Пакет 6/100	Пакет 3/100	Пакет 1/100

Рис. 8.5. Распределение пакетов после обслуживания второй очереди

Затем система IOS переходит к последней сконфигурированной очереди. Теперь пере-
дается пакет №1, система вычитает его размер из параметра 2000 байт, разрешенных для
передачи. Оставшихся два пакета — №3 и №6 — тоже передаются далее. Затем маршрути-
затор возвращается к первой очереди и передает последний оставшийся пакет — №7.

Как можно заметить, механизм настраиваемых очередей не позволяет возникнуть си-
туации, когда пакет находится в очереди в течение неопределенного времени. Система
IOS обслуживает все очереди через некоторый промежуток времени. Если пакеты при-
ходят в какую-либо очередь быстрее, чем они могут быть обработаны, и увеличивается
количество пакетов, которые ожидают отправки, то после достижения максимального
допустимого размера очереди все последующие пакеты будут игнорироваться. Таким об-
разом, механизм настраиваемых очередей выделяет некоторый минимум пропускной
способности для каждого типа трафика в случае возникновения перегрузки, но не га-
рантирует в данном случае доставку пакетов с большей скоростью, чем гарантировано.
Данные могут быть доставлены сверх гарантированного минимума пропускной способ-
ности в том случае, если нет перегрузки остальных очередей. Так, в рассмотренном
примере первая очередь обеспечивает доставку 1000 байт на каждый цикл обработки
4000 байт трафика. В результате первая очередь гарантированно может использовать 25
процентов пропускной способности интерфейса в случае перегрузки канала.

Внимание!

Пакет полностью передается из очереди (независимо от его размера), если счетчик
разрешенных байт для этой очереди содержит хотя бы один байт.
С помощью команды show queueing custom можно получить информацию о количе-
стве очередей и конфигурации каждой из них (пример 8.5).

i Пример 8.5. С помощью команды show queUeing custom 1иЬжн6 п&йучить '

• -J д -. информацию о том, как и какие очереди сконфигурированы • j
router#show queueing custom

Current custom queue configuration:

List Queue		Args			
1	3	default			
1	1	protocol ip		list	110
1	2	protocol ip		list	120
1	1	byte-count	1000		
1	2	byte-count	1000		
1	3	byte-count	2000		

Использование приведенной выше команды не дает информации о том, какое ко-
личество пакетов находится в ожидании в каждой очереди и как много пакетов было
отброшено. Для получения подробной информации о состоянии очереди используется
команда show interface (пример 8.6).

! Пример 8.6. Использование команды show interface для получения информации о

I . трафике в очереди ; - <	, „„___„ ,	*.. > Ч

router# show interface serial О
Serial 0 is up, line protocol is is up

Queueing strategy: custom-list 1

Output queues: (queue #: size/max/drops)

0: 0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0

5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0

10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0

15:	0/20/0 16: 0/20/0

Справедливая взвешенная очередь

В системе IOS существуют две реализации механизма справедливой взвешенной
очереди (WFQ):

•	аппаратно-независимый механизм WFQ;

•	механизм распределенной справедливой взвешенной очереди (DWFQ).

Все маршрутизаторы Cisco, описываемые в данной книге, за исключением уст-
ройств серии 12000, поддерживают аппаратно-независимый механизм WFQ. Техно-
логия DWFQ доступна только на VIP-интерфейсах в маршрутизаторах 7500-серии при
использовании механизма коммутации dCEF.

Аппаратно-независимый механизм WFQ

Операционная система IOS поддерживает две реализации аппаратно-независимого
механизма WFQ, которые подробно описаны ниже.

	Механизм WFQ, основанный на потоках (Flow-Based WFQ — FBWFQ).

	Механизм WFQ, основанный на классах (Class-Based WFQ — CBWFQ).
Технология FBWFQ

Потоковый механизм WFQ похож на метод настраиваемой очереди по используе-
мому способу обработки потоков. В отличие от механизма настраиваемой очереди, где
пакеты распределяются в отдельные очереди согласно заранее описанным правилам,
потоки в технологии FBWFQ сортируются автоматически. Механизм WFQ, основан-
ный на потоках, — это традиционный метод управления перегрузками в операцион-
ной системе IOS начиная с версии 11.0. Далее в книге под термином WFQ будет под-
разумеваться механизм WFQ, основанный на потоках.

При использовании технологии WFQ классификация IP-пакетов осуществляется
по параметрам, перечисленным ниже.

	Биты типа обслуживания (ToS) в заголовке IP-пакета.

	Тип протокола IP.

	IP-адрес отправителя.

	Порт протокола TCP или UDP отправителя.

	IP-адрес получателя.

	Порт протокола TCP или UDP отправителя.

По умолчанию механизм WFQ разбивает весь трафик на 256 различных потоков;
данное число можно изменить, используя параметр dynamic-queues в команде конфи-
гурирования fair-queue. В том случае, если отдельных потоков существуем больше, чем
очередей, то в одну очередь помешается несколько потоков.

Внимание!

Механизм WFQ по умолчанию сконфигурирован на всех последовательных интер-
фейсах (serial interface) с пропускной способностью (clock rate) ниже 2 Мбит/с. На
маршрутизаторах Cisco серии 7500 запуск любого специального механизма управле-
ния перегрузками (приоритетной очереди, настраиваемой очереди или механизма
WFQ) требует копирования пакета из буфера памяти MEMD в буфер DRAM-памяти
для его обработки. Копирование данных методу указанными буферами требует доста-
точно много процессорного времени, в результате чего использование аппаратно-
независимого механизма WFQ замедляется только низкоскоростными интерфейсами
на маршрутизаторах Cisco серии 7500.

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

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

удельный вес = 4096/(1Р-приоритет + 1).

Допустим, что три потока пакетов, которые перечислены ниже, прибыли для обра-
ботки с помощью механизма WFQ.

	Al, А2 — пакеты размером по 500 байт с приоритетом 0.

	Bl, В2 — пакеты размером по 400 байт с приоритетом 0.

	С1 — 40 байт с приоритетом 3.

Когда в интерфейс прибывает первый пакет (А1), он классифицируется и пере-
правляется в подочередь А. Алгоритм WFQ вычисляет порядковый номер пакета А1
по следующей формуле:

порядковый номер = текущий порядковый номер + (удельный вес * размер пакета),
где текущий порядковый номер — это один из параметров, перечисленных ниже.
	Порядковый номер последнего пакета, помешенного в очередь для отправки по
физической линии (transmit queue), если подочередь пуста.

	Порядковый номер последнего пакета в подочереди, если она содержит пакеты.

Для пакета А1 текущий порядковый номер — нуль, потому что это первый пакет,
прибывший в подочередь А. Его удельный вес равен 4096 (согласно значению ToS-
битов в заголовке пакета), а длина равна 500 байт. Таким образом, порядковый номер
пакета будет вычислен так:

0 + (4096 * 500) = 2048000.

Следующим приходит пакет А2, механизм WFQ классифицирует его и помешает в
подочередь А. Пакет А2 получает порядковый номер 4096000 (порядковый номер А1 +
4096*500). При этом пакет А1 помешается в очередь для отправки. На рис. 8.6 демон-
стрируется состояние очереди на данный момент.

Передача

А1/2048000

Очередь А	А2/4096000

Очередь В

Очередь С

Рис. 8.6. Состояние механизма WFQ после первого этапа

Далее в интерфейс приходят пакеты В1 и В2. Механизм WFQ помешает их в подоче-
редь В и вычисляет порядковый номер для каждого из них, как было описано выше.

В подочереди В нет пакетов, когда в нее приходит пакет В1, поэтому для вычисле-
ния порядкового номера этого пакета используется порядковый номер последнего пе-
реведенного в выходную очередь пакета (А1):

2048000 + (4096 * 400) = 3686400.

Порядковый номер пакета В2 вычисляется так же, как и для пакета А2:

3686400 + (4096 * 400) = 5324800.

В рассматриваемый момент завершается передача пакета А1. Механизм WFQ сор-
тирует подочереди на основании порядкового номера первого пакета в начале каждой
очереди. Пакет В1 имеет меньший порядковый номер и переводится в выходную оче-
редь. Обратите внимание, что пакет В1 отправляется раньше пакета А2, хотя пришел
он позже. На рис. 8.7 показано состояние очереди на данный момент.

Передача

В1/3686400

Очередь А	А2/4096000

Очередь В	В2/5324800

Очередь С

Рис. 8.7. Состояние очередей механизма WFQ
Далее в интерфейс приходит пакет С1 и помещается в подочередь С. Поскольку подо-
чередь С в текущий момент пуста, то при вычислении порядкового номера пакета С1 ис-
пользуется порядковый номер последнего переданного пакета, которым является пакет В1:

3686400 + (1024 * 40) = 3727360.

После пересылки пакета В1 операционная система пересортировывает очереди.
Пакет С1 имеет наименьший порядковый номер (рис. 8.8), следовательно, именно он
будет переведен в очередь на отправку.

Очередь А	А2/4096000

Очередь В	В2/5324800

Передача .

С1/3727360

Очередь С

Рис. 8.8. Состояние WFQ после второго этапа

Пакет С1 будет отправлен раньше, чем пакеты В2 и А2, несмотря на то, что он
пришел позже них.

Какое же преимущество дают все рассмотренные пересортировки очередей, назначение
удельного веса и порядкового номера? Преимущество состоит в справедливом распределе-
нии доступной пропускной способности между всеми потоками на основании байт типа
обслуживания (Type of Service — ToS). Из-за того что размер пакета принимается во вни-
мание при назначении порядкового номера, потоки, длина пакетов которых ниже средней,
могут посылать большее количество пакетов, чем потоки с размером пакетов больше сред-
него. Например, поток, содержащий пакеты размером по 500 байт, может пересылать в
три раза больше пакетов, чем поток, который посылает пакеты длиной 1500 байт.

Классический пример необходимости рассмотренного механизма — терминальное
соединение и передача файлов. Терминальное соединение (telnet) использует неболь-
шие пакеты, и пользователь легко замечает проблемы и выражает недовольство за-
держками. При передаче файлов используются большие пакеты и при этом процесс
менее чувствителен к задержкам. Механизм WFQ автоматически пересылает пакеты
терминального соединения чаше, чем пакеты службы передачи фалов, даже несмотря
на то, что они пришли раньше.

Если распределение по потокам основано на типе обслуживания, то потоки с
большим значением параметра ToS получают больший приоритет и соответственно
большую часть пропускной способности соединения.

Конфигурация и контроль WFQ

Для включения механизма WFQ на интерфейсе выполняется команда fair-queue на
уровне конфигурации интерфейса:

Router(config-if)# fair-queue [congestive-discard-treshold [dynamic-
queues [reservable queues]]]

Параметр congestive-discard-treshold (стандартное значение равно 64) — это число
сообщений или пакетов, разрешенных для каждой очереди. Когда данное ограничение
превышается, любые пакеты, которые обычно помешались в очередь, игнорируются.

dynamic-queues (стандартное значение равно 256) — это число подочередей, по ко-
торым алгоритм WFQ классифицирует трафик.

Если поток пакетов резервируется с помощью технологии RSVP, его данные по-
мешаются в очередь reservazble-queue (резервируемая очередь). Команда show queueing
interface interface-number используется для отображения текущего состояния очередей
WFQ на интерфейсе (пример 8.7).
j Пример 8.7. Контроль состояния очередей механизма WFQ с^помощ£ю команды ’ - ]
[ «;4LV’'<®Mshow queueing interface'lia интерфейсе маршрутизатора	/ у), j

tom#show queueing interface serial 2/1
Interface Serial2/1 queueing strategy: fair

Input queue: 0/75/5/132 (size/max/drops/flushes); Total output
drops: 1289054

Queueing strategy: weighted fair

Output queue: 4/1000/64/1289054 (size/max total/threshold/drops)
Conversations 4/198/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1536 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves)
1/16192/6050/0/0

Conversation 2, linktype: ip, length: 64

source: 193.125.78.45, destination: 212.42.70.4, id: 0xE37B, ttl:

254, prot: 1

Ниже раскрыты наиболее важные поля в информации, выводимой командой show
queueing interface serial 2/1. Затененная область в примере 8.7 выделяет статистику об
одном потоке или диалоге (conversation); очередь диалога — это то же, что и подоче-
редь, рассматриваемая в предыдущих примерах.

	Output queue: 4/1000/64/1289054 (size/max total/threshold/drops)

•	size — текущее количество пакетов в очереди.

•	max total — максимальное количество буферов, которое может выделить ме-
ханизм WFQ.

•	threshold — порог перегрузки, описанный выше. Данный параметр означает
максимальное число пакетов, разрешенное в одной подочереди. Такое огра-
ничение не является жестким, на самом деле в очередь диалога может быть
помешено больше пакетов, чем указано для threshold. Параметр max total
предохраняет механизм WFQ от чрезмерного использования памяти и иг-
норирует пакеты по достижении указанного значения.

•	drops — число пакетов, проигнорированных механизмом WFQ, включая те,
которые превысили параметр threshold в отдельной подочереди, и те, кото-
рые превысили общее число пакетов max total.

 . Conversations 4/198/256 (active/max active/max total)

•	active — данный параметр показывает количество существующих в потоков
или диалогов. В текущий момент активны 4 диалога (или потока).

•	max active — максимальное количество потоков за все время работы.

•	max total — максимально возможное число потоков. Если возникает необ-
ходимость создать еще один поток, то несколько потоков помешается в од-
ну подочередь.

	(depth/weight/total drops/no-buffer drops/interleaves) 1/16192/6050/0/0

•	depth — номер пакета, помешенного в подочередь.

•	weight — удельный вес каждого пакета в очереди.

•	total drops — количество проигнорированных пакетов при превышении па-
раметра threshold.

•	no-buffer drops — количество проигнорированных пакетов при превышении
параметра max total.
•	interleaves — счетчик числа прошедших пакетов небольшого размера между
фрагментами больших при разбиении пакетов на кадры для передачи по
физической линии.

Механизм WFQ, основанный на классах (CBWFQ)

Механизм WFQ, основанный на потоках, как уже говорилось в предыдущей главе, ав-
томатически классифицирует потоки, поэтому отсутствует какая-либо возможность кон-
тролировать механизм распределения по потокам. Метод WFQ, основанный на классах
(CBWFQ), разработан для предоставления механизму WFQ возможности сортировать по-
токи на основе заранее определяемых правил. Механизм CBWFQ, как и WFQ, — это ап-
паратно-независимый метод управления перегрузками, который доступен на всех маршру-
тизаторах, описанных в данной книге, за исключением устройств серии 12000. Кроме того,
на VIP-картах для маршрутизаторов Cisco серии 7500 реализован аппаратно-зависимый
механизм распределенного CBWFQ (DCBWFQ). В данном разделе рассматривается только
аппаратно-независимый механизм CBWFQ, a DCBWFQ рассматривается ниже.

Внимание!

Механизм CBWFQ — это относительно новая возможность операционной системы
IOS; для его использования вам необходимо просмотреть документацию к вашей IOS
на предмет наличия возможности использования CBWFQ.

Механизм CBWFQ позволяет разбивать весь трафик на 64 класса на основании та-
ких параметров, как протокол, списки доступа (access list) и входной интерфейс. Каж-
дому классу выделяется часть пропускной способности выходного интерфейса. По
умолчанию пакеты, которые переполняют очередь любого класса, игнорируются, но
можно настроить специальный механизм выбора проигнорированных пакетов для по-
вышения производительности вместо обычного игнорирования при переполнении
очереди. Алгоритм, по которому происходит выбор отбрасываемых пакетов, называет-
ся взвешенное случайное раннее определение перегрузки (Weighted Random Early
Detection, WRED) и рассматривается ниже в данной главе.

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

Внимание!

Механизм CBWFQ позволяет выделить определенную часть пропускной способности
на каждый класс. Если на класс, называемый “voice", выделено 200 Кбит/с, но он пол-
ностью не использует свою часть канала, то оставшаяся часть пропорционально рас-
пределяется между остальными классами (в соответствии с выделенными им пор-
циями общего канала).

Модульный интерфейс командной строки для конфигурирования
механизма CBWFQ

При конфигурировании механизма CBWFQ используется новый модульный ин-
терфейс командной строки (Command-Line interface — CLI), который стандартизиро-
ван для всех механизмов технологии QoS, реализованных в операционной системе
IOS. Модульный интерфейс командной строки позволяет разграничить настройки
правил классификации трафика с другими правилами, установленными для маркиро-
ванных пакетов. Дерево модульного интерфейса командной строки состоит из трех
конструкций, описанных ниже.
	Class-map — распределение пакетов по классам.

	Policy-map — описание правил для каждого класса.

	Service-policy — запуск заданных правил на интерфейсе.

В примере 8.8 приведена схема базовой конфигурации механизма CBWFQ.

| Примере^Jnjjocraw конфигурация мехаЯй^ЖМФ	' Wrf, 1'

class-map class!

match access-group 101
i

policy-map policyl
class classl
bandwidth 100
queue-limit 20
class class-default
bandwidth 200
random-detect
I
interface serialO

service-policy output policyl
i

access-list 101 permit ip any any precedence critical

Параметр class-map определяет пользовательский класс, называемый “classl”. Дан-
ные, относящиеся к такому классу, обрабатываются согласно правилу, описанному
командой access-list 101.

Команда policy-map определяет правила для существующих классов. В данном
примере для “classl” выделено 100 Кбит/с из обшей пропускной способности интер-
фейса (т.е. при перегрузке интерфейса этот класс будет использовать поток в 100
Кбит/с). Также можно выделять пропускную способность в процентном отношении,
используя параметр percent в команде bandwidth (пример 8.9).

Пример "в.& Конфйгурация прбйжгного^вццелёнйя пропускной способности

tom#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.
tom(config)#policy-map policyl
tom(config-pmap)#class classl
tom(config-pmap-c)#bandwidth percent ?

<l-100> Percentage

tom(config-pmap-c)#bandwidth percent

Команда queue-limit определяет максимальное количество пакетов, которые могут
находиться в очереди класса. Стандартное значение (как и максимальная величина)
данного параметра — 64. Команда policy-map может определять правила для несколь-
ких классов (максимум 64). Обратите внимание, что данная команда связана с ранее
определенным классом (см. пример 8.9) и содержит правила этого класса.

Параметр class-default команды class определяет правила для пакетов, которые не
попали ни в один из сконфигурированных классов. Механизм WRED включается для
класса с помощью команды random-detect.

После определения, какие пакеты необходимо классифицировать, и действий над
ними используется команда service-policy для применения сконфигурированных пра-
вил к пакетам, проходящим через интерфейс. Дополнительные ключевые слова
(input/output) определяют, к каким именно пакетам (входящим или выходящим из ин-
терфейса) необходимо применить описанные правила. Механизм CBWFQ применим
только для пакетов, выходящих из интерфейса.

Контроль механизма CBWFQ

Команда show policy policy-map используется для вывода информации о конфигура-
ции всех классов в списке правил (policy тар). В примере 8.10 показан вывод инфор-
мации, указанной командой.

——гжг—••; 'Vf-f-'-t- --7-—	—-г-.-—.—* - —.. -• —•	»-*•" .	. •• - —л	 а-жч'-ч-у»»? •т'—	тг» -.у

Пример 8.10. CBWFQ: результат выполнения команды show policy; ; 'Л \ v - ;-;л-

tom#show policy-map s2/0-cbwfq

Policy Map s2/0-cbwfq

Class classl

Weighted Fair Queueing

Bandwidth 128 (kbps) Max Threshold 512 (packets)
exponential weight 9
class min-threshold max-threshold mark-probablity

0

1

2

3

4

5

6

7
rsvp

1/10
1/10

1/10
1/10

1/10
1/10

1/10
1/10
1/10

Traffic Shaping

Average Rate Traffic Shaping

CIR 384000 (bps) Max. Buffers Limit 1000 (Packets)

Параметры механизма WRED в разделе class-default раскрываются в описаний ал-
горитма взвешенного случайного раннего обнаружения перегрузок.

Выводимая командой show policy interface информация — это один из способов оп-
ределения настроек, параметров механизма CBWFQ на интерфейсах (пример 8.11).

I Пример 8.11. Использование команды show policy interface для проверки	’

конфигурации механизма CBWFQ	’ L_

tom#show policy interface

Serial2/0

Service-policy output: s2/0-cbwfq (4777)

Class-map: uninet (match-all) (4779/2)

32597785 packets, 24107714053 bytes

5 minute offered rate 67000 bps, drop rate 0 bps

Match: access-group name uninet_dst (4783)

Weighted Fair Queueing

Output Queue: Conversation 137

Bandwidth 128 (kbps)

(pkts matched/bytes matched)23014897/14993566476

(depth/total drops/no-buffer drops)
0/0/0 .

exponential weight: 9
mean queue depth: 0

Class  (Ргес)	Random drop pkts/bytes	Tail drop pkts/bytes	Minimum threshold	Maximum threshold	Mark prob-
ability 0	0/0	0/0	20	40	1/10
1	0/0	0/0	22	40	1/10

Class-map: class-default (match-any) (4819/0)

82511985 packets, 48855741634 bytes

5 minute offered rate 409000 bps, drop rate 0 bps

Match: any (4823)

Weighted Fair Queueing

Output Queue: Conversation 141

Bandwidth 128 (kbps)

(pkts matched/bytes matched)62331918/35063598190

(depth/total drops/no-buffer drops)

0/4221/0

random-detect:

exponential weight: 9

mean queue depth: 0					
Class	Random drop	Tail drop	Minimum	Maximum	Mark
(Prec)	pkts/bytes	pkts/bytes	threshold	threshold prob-	
ability 0	10/961	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	4016/2392001	195/117832	28	40	1/10
5	0/0	0/0	30	40	1/10
6	0/0	0/0	32	40	1/10
7	0/0	0/0	34	40	1/10
rsvp	0/0	0/0	36	40	1/10

Ниже описаны значения наиболее важных параметров из примера 8.11.

 Bandwidth 128 (kbps)

•	(pkts matched/bytes matched) 62331918/35063598190 — количество и суммар-
ный размер пакетов, прошедших через интерфейс в рамках данного класса.

•	Maximum threshold — параметры, аналогичные механизму WFQ; нежесткое
ограничение на количество пакетов, которые можно поместить в очередь
для данного класса.

 (depth/total drops/no-buffer drops)

•	depth — количество пакетов в очереди (в текущий момент).

•	total drops — количество пакетов, проигнорированных при достижении за-
данного значения параметра maximum threshold.

•	no-buffer drops — количество пакетов, проигнорированных при переполнении
обшего буфера (его размер — 1000 пакетов, и он не может быть изменен).

Создание очереди с низкой задержкой

Очереди с низкой задержкой (Low Latency Queueing — LLQ) — это комбинация
строгой приоритетной очереди с механизмом CBWFQ. Строгая приоритетная очередь
позволяет первыми отправлять пакеты из потоков данных, чувствительных к задержкам
(например, для установления голосовой связи через Internet). Данная технология позво-
ляет уменьшить помехи при передаче звукового потока через сеть. Для того чтобы ис-
пользовать механизма строгой приоритетной очереди в рамках определенного класса,
используется параметр priority после указания имени класса в модуле policy-map.

Внутри блока policy-map можно определить один или несколько классов, которые
используют приоритетную очередь. Когда несколько классов внутри одного блока
policy-map используют механизм приоритетной очереди, то весь трафик таких классов
обрабатывается как единая приоритетная очередь. В примере 8.12 сконфигурирован
класс “classl” из примера 8.11 с использованием приоритетной очередности.

[прйм^1м2. Настройка приоритетной очереди.внутри'Mexmfttswia'CBWFQ
policy-map policyl
classs classl
priority 100

class class-default
bandwidth 200
random-detect

Распределенная взвешенная справедливая очередь

Механизм распределенной взвешенной справедливой очереди (Distributed Weighted
Fair Queueing — DWFQ) разработан для многоцелевых контроллеров интерфейсов
(VIP-cards) маршрутизаторов Cisco серии 7500. Аппаратно-независимые механизмы
управления перегрузками (PQ, CQ или WFQ) не могут быть применены в высокоско-
ростных интерфейсах (с пропускной способностью выше 2 Мбит/с) на маршрутизато-
рах серии 7500. Основная причина такой ситуации — необходимость копирования па-
кетов между памятью MEMD и DRAM, что дает большую нагрузку на основной про-
цессор при перегрузке интерфейсов.

Механизм DWFQ разработан для распределенной коммутации пакетов на VIP-картах
и имеет повышенную производительность по сравнению с обычным механизмом WFQ.

	Все пакеты, обрабатываемые на VIP-интерфейсе, не используют процессор RSP
(Route Switch Processor), что освобождает его для выполнения других задач
(например, для поддержки протоколов маршрутизации).

	Пакеты не копируются между различными областями памяти внутри маршру-
тизатора; все операции проводятся в SRAM-памяти внутри VIP-карты.

	Алгоритм DWFQ оптимизирован для использования на VIP-интерфейсах.

Таким образом, механизм DWFQ может применяться на высокоскоростных ин-
терфейсах, таких как ОС-3 (155 Мбит/с) в модулях VIP2-50. Алгоритм DWFQ класси-
фицирует пакеты по последующим четырем критериям:

	на основе информации о потоках (Flow-Based);

	на основе битов ToS (ToS-Based);

	на основе QoS-групп (QoS Group-Based);

	на основе классов (Class-based).

DWFQ на основе информации о потоках

Механизм DWFQ, основанный на потоках, классифицирует трафик исходя из пе-
речисленных ниже параметров.

	ToS-биты в заголовке IP-пакета.

	Тип протокола IP.

	IP-адрес отправителя.
	Порт протокола TCP или UDP отправителя.

	IP-адрес получателя.

	Порт протокола TCP или UDP получателя.

Весь поток данных разделяется на максимум 512 отдельных потоков. Каждый из
таких потоков циклически обрабатывается из календарной очереди (более подробно
календарная очередь описана ниже, в разделе “Реализация механизма DWFQ”). Каж-
дый из 512 потоков использует равную часть обшей пропускной способности канала.

При включенном механизме коммутации dCEF механизм FBWFQ для VIP-модуля
может быть запушен с помощью команды fair-queue:

Router(config-if)#fair-queue

DWFQ на основе ToS-информации

Механизм DWFQ, основанный на битах ToS (также известный как Class-Based
DWFQ), распределяет пакеты на основании двух младших битов приоритета в IP-
заголовке и, следовательно, создает четыре различные очереди. Удельный вес каждой
очереди определяет выделенную часть от общей пропускной способности канала при
перегрузке исходящего интерфейса.

Следующая команда активизирует механизм ToS DWFQ:

Router(config-if)#fair-queue tos

Классы 3, 2, 1 и 0 по умолчанию имеют удельный вес 40, 30, 20 и 10 соответствен-
но. Стандартные значения могут быть изменены с помощью следующей команды:
Router(confgi-if)#fair-queue tos 0 weight 20

Общий удельный вес всех классов не может превышать 100.

DWFQ на основе QoS-групп

Другим вариантом механизма DWFQ с использованием классов является метод,
основанный на битах QoS, а не на битах ToS в заголовке IP-пакета. Пакеты в данном
методе классифицируются на основании локальных правил с использованием пара-
метра гарантированной скорости передачи (Committed Access Rate — CAR), который
распространяется с помощью механизма распространения правил протокола маршру-
тизации BGP (Border Gateway Protocol Policy Propagation). Описание данного меха-
низма выходит за рамки настоящей книги.

Распределенный механизм CBWFQ

Механизмы WFQ на основе информации ToS и QoS-группах — это две разновид-
ности распределенного алгоритма CBWFQ. Для конфигурирования механизма
CBWFQ на VIP-интерфейсах используется тот же самый модульный интерфейс ко-
мандной строки, что и для аппаратно-независимого механизма CBWFQ, включая ор-
ганизацию очереди с низкой задержкой (Low Latency Queuing).

Реализация механизма DWFQ

Механизм DWFQ не использует список сортировки и перегруппировки очередей,
как это делает аппаратно-независимая реализация WFQ. Вместо этого используется от-
лаженный алгоритм, использующий календарную очередь, которая дает тот же резуль-
тат, что и пересортировка, но с большей эффективностью. Благодаря этому механизм
DWFQ может использоваться на ОС-3- интерфейсах (155Мбит/с) в модулях VIP2-50.

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

Контроль механизма DWFQ

Основная команда контроля механизма DWFQ — show interface fair (пример 8.13).

; Пример 8.13. контроль механизма DWFQ с помощью команды show interface fair

routerffshpw interface fair

FastEth'er’hetll/i/O tjueue size 0

packets output 44404, wfq drops 1, nobuffer drops 0

WFQ: aggregate queue limit 6746, individual queue limit 3373
max available buffers 6746

Class 0:	weight	10	limit	3373	qsize	0	packets	output	44404 drops 1

Class 1:	weight	20	limit	3373	qsize	0	packets	output	0	drops	0

Class 2:	weight	30	limit	3373	qsize	0	packets	output	0	drops	0

Class 3:	weight	40	limit	3373	qsize	0	packets	output	0	drops	0

Ниже описаны значения основных полей в информации, выводимой командой
show interface fair.

	Packets output — общее количество пакетов, отправленных через интерфейс.

	wfq drops — сумма проигнорированных механизмом DWFQ пакетов для каждого
класса. Они могут быть проигнорированы по следующим причинам.

•	Превышен максимальный суммарный размер очереди.

•	Превышен размер индивидуальной очереди (этого не происходит, если об-
щая очередь заполнена меньше чем на две трети).

•	Нет свободных буферов.

	nobuffer drops — параметр означает нехватку SRAM-памяти в VIP-модуле,
вследствие чего данный модуль не смог добавить пакет в DWFQ-очередь. Об-
щее количество доступных буферов, которые может использовать механизм
DWFQ, определяется параметром max available buffers.

	aggregate queue limit — максимальное количество пакетов, которое может быть
поставлено в очередь механизма DWFQ. По умолчанию это значение равно па-
раметру max available buffers, но мржет быть уменьшено.

	max available buffers — это часть памяти, выделенная в SRAM для создания
DFWQ-очереди. Она вычисляется исходя из скорости интерфейса и макси-
мального доступного объема памяти SRAM.

•	Если достаточно свободной SRAM-памяти, то выделяется память, необходи-
мая для хранения пакетов, которые приходят на полной скорости интерфейса
исходя из предположения, что размер каждого пакета составляет 250 байт.

•	Если свободной памяти недостаточно для выделения такого буфера, то па-
мять выделяется на основе более сложных алгоритмов.

	individual queue limit — количество пакетов, которые могут быть помещены в
очередь для одного класса. По умолчанию эта величина равняется половине па-
раметра aggregate queue limit. Данное ограничение не является жестким, и паке-
ты игнорируются только в том случае, если буфер заполнен более чем на две
трети. По умолчанию сумма всех индивидуальных ограничений на размер оче-
реди превышает размер общей очереди (aggregate queue limit); это умышленное
завышение может быть изменено.

	qsize — размер очереди класса в текущий момент времени.
Внимание!

Если в определенный класс (например, classl) попадает много больших пакетов, а за-
тем приходит несколько пакетов другого класса, возможна ситуация, когда буфер бу-
дет переполнен и пакеты второго класса будут проигнорированы из-за переполнения
буфера. Возможное решение данной проблемы состоит в добавлении SRAM-памяти в
VIP-модуль или настройке параметров aggregate limit и individual limit Таким обра-
зом, что буфер не будет переполняться. Если же необходимо полностью защитить
каждый класс от возникновения подобной ситуации, то сумма размеров индивидуаль-
ных очередей не должна превышать размер общей очереди. Другими словами, не
разрешается превышение размеров буферов во избежание исчезновения пакетов од-
ного класса из-за большого потока пакетов другого класса.

Механизм циклически изменяемого дефицита

В отличие от других маршрутизаторов Cisco, маршрутизаторы серии 12000 не под-
держивают механизмы приоритетной, настраиваемой или взвешенной справедливой
очереди. Вместо этих методов реализован другой механизм управления перегрузка-
ми — механизм циклически изменяемого дефицита (Modified Deficit Round Robin —
MDRR). Технология MDDR применяется на входящих интерфейсах для пакетов, на-
правляемых в модуль коммутации, и на выходных интерфейсах для пакетов, ожидаю-
щих отправки. Механизм MDRR классифицирует пакеты на основании битов при-
оритета в заголовке IP-пакета. Очереди обслуживаются циклически; за каждый цикл
обслуживания из очереди передается определенное число байтов, называемое кван-
том. Счетчик дефицита показывает передаваемое за каждый цикл число байтов.

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

Кроме очередей, основанных на битах приоритета, механизм MDDR имеет специ-
альную очередь, которая может обслуживаться в одном из двух режимов:

•	режим строгого приоритета;

•	альтернативный режим.

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

В альтернативном режиме происходит периодическое переключение между специ-
альной очередью и очередями на основе битов приоритета.

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

количество байтов = параметр MTU + (удельный вес —1) * 512,
где параметр MTU — Maximum Transfer Unit, т.е. максимальный размер передавае-
мого пакета.

Рассмотрим пример работы механизма с тремя очередями, которые приведены ниже.

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

	Первая очередь — размер кванта равен 3000 байт.
	Вторая очередь — размер кванта равен 1500 байт.

На рис. 8.9 показано начальное состояние очереди при получении и перерас-
пределении нескольких пакетов.

	Очереди		Счетчики дефицита	
Очередь 1	3/250	2/1500	1/250	0
Очередь 2	6/1500	5/1500	4/1500	0
ОчередьЗ	11/1500	10/250	9/250	8/250	7/250	0

Рис. 8.9. Начальное состояние очередей MDRR

Нулевая очередь обслуживается первой; значение кванта добавляется к счетчику
дефицита. Пакет №1 размером 250 байт пересылается, и его размер вычитается из
счетчика дефицита. Так как счетчик дефицита нулевой очереди все еще больше нуля
(1500 — 250 = 1250), то пересылается второй пакет из данной очереди. Размер второго
пакета также вычитается из счетчика дефицита ( 1250 — 1500 — -250). Поскольку зна-
чение счетчика дефицита меньше нуля, то механизм MDRR переходит к обслужива-
нию первой очереди (рис. 8.10).

Очередь 1			Очереди		Счетчики дефицита	
					3/250	-250
Очередь 2			6/1500	5/1500	4/1500	0
ОчередьЗ	11/1500	10/250	9/250	8/250	7/250	0

Рис. 8.10. Состояние очередей MDRR

Счетчик дефицита для первой очереди выставляется равным значению кванта (0+3000
= 3000). После пересылки четвертого и пятого пакетов (при этом размер каждого пакета
вычитается из счетчика дефицита) значение счетчика становится равным 0 (рис. 8.11).

Счетчики
дефицита

Очереди

Очередь 1					3/250
Очередь 2					6/1500
ОчередьЗ	11/1500	10/250	9/250	8/250	7/250

Рис. 8.11. Состояние очередей MDRR

250

0

0

Поскольку включен альтернативный режим, механизм MDRR возвращается к об-
служиванию нулевой очереди. Вновь добавляется размер кванта к счетчику дефицита
(-250 + 1500 = 1250). Затем пакет №3 отправляется на выход, и его размер вычитает-
ся из счетчика дефицита. Так как нулевая очередь пуста, то ее счетчик дефицита вы-
ставляется равным 0 (рис. 8.12).
Очереди

Счетчики
дефицита

Очередь 1	О

Очередь 2					6/1500	0
Очередь 3	11/1500	10/250	9/250	8/250	7/250	0

Рис. 8.12. Состояние очередей MDRR

Следующей обслуживается очередь №2. Значение счетчика дефицита выставляется 1500
(0 + 1500 = 1500). В данной очереди передаются пакеты с седьмого по десятый, при этом
значение счетчика становится равным 500 (1500 - (4 * 250) = 500). Так как значение счет-
чика больше нуля, то передается последний, одиннадцатый, пакет в этой очереди.

После передачи одиннадцатого пакета очередь становится пустой, поэтому значе-
ние счетчика дефицита обнуляется (рис. 8.13).

Очереди

Счетчики
дефицита

Очередь 1	0

Очередь 2	6/1500	0

Очередь 3	О

Рис. 8.13. Состояние очередей MDRR

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

Конфигурирование механизма MDRR

Команда cos-queue-group переводит маршрутизатор в режим настройки механизма
MDRR, в котором можно создавать CoS-шаблоны, которые описаны ниже.

	Шаблон precedence — используется для отображения информации IP-precedence
(битов приоритета в заголовке IP-пакета) в очереди механизма MDRR и на-
стройки специальной очереди с низкой задержкой.

	Шаблон queue — устанавливает удельный вес для каждой очереди.

	Шаблон tx-cos — используется для сопоставления параметров команды cos-
queue-groups и выходного интерфейса.

При использовании механизма MDRR для входящего трафика группы cos-queue-
groups логически связаны с выходным интерфейсом LC. Команды slot-table-cos и rx-cos-
slot используются для проверки параметров шаблонов каждого устройства назначения.

Например, пусть в маршрутизаторе используются два модуля: ОС-12 — во втором
слоте маршрутизатора серии 12000 и ОС-3 — в третьем слоте. Необходимо направить
поток данных с приоритетом 7 в очередь с низкой задержкой (специальную очередь) и
обслуживать его в режиме строгого приоритета. Для этого может быть использована
конфигурация, показанная в примере 8.14.
; Пример 8.14. Конфигурация механизма MDRR в GSR-маршрутизаторе

Interface pos2/l
Description 0С12 Interface
i
Interface 3/1
Description OC-3 Interface
tx-cos frfab
i
rx-cost-slot 2 table-a
i
slot-table-cos table-a
destination-slot 3 tofab
i
cos-queue-group frtab
precedence 7 queue low-latency
queue low-latency strict-priority 10
i
cos-queue-group tofab
precedence 7 queue low-latency
queue low-latency strict-priority 10
i

Механизм взвешенного случайного раннего
обнаружения перегрузок

Механизм случайного раннего обнаружения (Random Early Detection — RED) —
это метод избежания перегрузок, который наиболее часто используется при адаптив-
ном потоке данных, например, таком как TCP-поток. Протокол TCP использует иг-
норирование пакетов как сигнал перегрузки сети, уменьшая при этом скорость пере-
дачи данных и повторно отправляя потерянный пакет.

Когда основной поток данных загруженного соединения содержит TCP-потоки от раз-
ных отправителей, то при использовании FIFO-буфера отбрасываются пакеты в перепол-
ненной очереди. Это приводит к снижению скорости передачи от всех источников данных
одновременно. Через период времени (г) скорость TCP-потока снова увеличивается, канал
(или соединение) снова перегружается, что, в свою очередь, опять приводит к снижению
скорости передачи данных. Такие колебания называются общей синхронизацией (рис. 8.14).

В задачу различных механизмов управления перегрузками, таких как RED, входит
предотвращение описанной выше ситуации синхронизации. Идея, лежашая в основе
механизма RED, довольно проста: пакеты случайно начинают отбрасываться прежде,
чем переполнится очередь. Если пакеты аннулируются в разные промежутки времени,
то каждое TCP-соединение будет реагировать на потерю пакета в разное время и не
будет синхронизироваться с остальными.

В механизме RED определяются нижний и верхний пороги (min и max соответст-
венно), а также средний размер очереди. Средний размер очереди (avg) определяется
по следующей формуле:

параметр Avg = (старое значение Avg * (1 - 1/2“нстан™э''ето™нчиальноговеса)) +

(Текущий размер ОЧереДИ *	экспоненциального веса^

Заметьте, что средний размер очереди в механизме RED не имеет мгновенного
значения. При вычислении данного параметра используется его предыдущее значе-
ние. Поэтому механизм RED позволяет увеличить поток данных до пикового значе-
ния. Обычно не рекомендуется менять значение постоянной экспоненциального веса.
Переполнение очереди/количество проигнорированных пакетов

Рис. 8.14. Синхронизированные ТСР-потоки

Внимание!

Детальное описание механизма RED содержится в документе Random Eady Detection
for Congestion Avoidance, написанном Sally Floyd и Van Jacobson (cm. IEEE/АСМ Trans-
action on Networking, v. 1, n. 4, August 1993).

Механизм RED игнорирует пакеты на оснований следующих критериев:

если avg < min, пакеты не игнорируются;

если min < avg < max, пакеты игнорируются случайным образом; при увеличении
параметра avg увеличивается вероятность игнорирования пакета;

если avg > max, все пакеты игнорируются.

Механизм взвешенного случайного раннего обнаружения перегрузок (Weighted
Random Early Detection — WRED) — это усовершенствованный механизм RED, в ко-
тором вероятность отбрасывания пакетов зависит от битов приоритета в IP-заголовке,
что позволяет разделить пакеты по уровню обслуживания. Существуют две реализа-
ции механизма WRED (как и механизма WFQ):

	аппаратно-независимый механизм WRED;

	распределенный механизм WRED (dWRED).

Аппаратно-независимый механизм WRED реализован во всех маршрутизаторах
Cisco, кроме устройств серии 12000; механизм dWRED доступен только для маршрутиза-
торов Cisco серии 7500 с использованием VIP-карт и включенного протокола'dCEF.

Конфигурирование и контроль механизма WRED

Механизм WRED настраивается с помощью всего одной команды на интерфейсе:
Router(config-if)#random-detect

Для контроля работы механизма WRED используется команда show interface random
(пример 8.15). Данная команда была запущена на маршрутизаторе серии 7500 с вклю-
ченным механизмом dWRED.
Пример 8.15. Команда show interface random используется для контроля работы z
ЛЙ?;М0Х8иизмаWRED	Д ‘	‘	]

Router#show interface random

POS8/1/0 queue size 0

packets output 151051, wred drops 1, nobuffer drops 0

WRED: queue average 0, weight 1/512, max available buffers 23523

Precedence 0: 5880 min threshold, 11761 max threshold, 1/10 mark weight
151043 packets output, drops: 0 random, 0 threshold

Precedence 1: 6615 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Precedence 2: 7350 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Precedence 3: 8085 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Precedence 4: 8820 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Precedence 5: 9555 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Precedence 6: 10290 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Precedence 7: 11025 min threshold, 11761 max threshold, 1/10 mark weight
(no traffic)

Ниже подробно описаны наиболее важные поля в информации, выводимой ко-
мандой show interface random.

•	packets output — общее количество переданных пакетов.

•	wred drops — количество пакетов, проигнорированных алгоритмом WRED.

•	no buffer drops — количество пакетов, проигнорированных из-за нехватки
памяти (SRAM) на VIP-карте.

•	queue average — текущий средний размер очереди.

•	mark weight — вероятность игнорирования пакета при превышении параметра
среднего размера очереди mm threshold. В данном примере значение 1/512 по-
казывает, что каждый 512-й пакет будет проигнорирован (при avg > min).

•	max available buffers — количество буферов, выделенных в памяти SRAM для
хранения пакетов.

•	min threshold — значение среднего размера очереди, при котором механизм
RED начнет игнорировать пакеты для данного уровня приоритета.

•	max threshold — значение среднего размера очереди, при котором будут иг-
норироваться все пакеты.

Внимание!

Стандартное значение параметров min threshold и max threshold вычисляется исхо-
дя из размера выходной очереди для интерфейса. Необходимо помнить, что выход-
ная очередь — это не то же самое, что очередь на отправку.

Параметр min threshold для очереди с битом приоритета, равным 0, принимает зна-
чение половины длины очереди. Интервал между значением min threshold для оче-
реди с битом приоритета 0 и значением max threshold разбивается на восемь частей,
и полученные значения используются для оставшихся очередей. Очередь для данных
с битами приоритета, равными 0, имеет минимальное значение параметра min
threshold, а очередь для данных с битами приоритета, равными 7, — максимальное.

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

Когда входная очередь на интерфейсе переполняется данными, предназначенными для
маршрутизатора, то очень вероятно, что следующий проигнорированный пакет будет важ-
ным для состояния самой сети. Так, например, это может быть пакет с обновлением таб-
лицы маршрутизации или тестовый пакет. Механизм выборочного аннулирования пакетов
(Selective Packet Discard — SPD) позволяет системе IOS при перегрузке входной очереди
сделать более приоритетными данные, которые важны для стабильности сети.

Любой пакет, определяемый операционной системой 1OS как жизненно важный для
поддержания стабильности сети, обрабатывается по отдельным правилам при распреде-
лении входящих пакетов. Механизм SPD доступен на всех маршрутизаторах Cisco.

Команда show ip spd используется для просмотра параметров механизма SPD
(пример 8.16).

! Пример 8.16. Использование команды show ip spd для получения информации о J
механизмаБРР	' ' 'IS/	/1

murka#show ip spd

Current mode: normal.

Queue min/max thresholds: 73/74, Headroom: 100
IP normal queue: 0, priority queue: 0.

SPD special drop mode: none

Пакеты с более низким приоритетом игнорируются при достижении параметра
размера очереди min threshold. Количество пакетов (важных для поддержания стабиль-
ности), которые могут быть обработаны сверх нормального размера очереди, опреде-
ляются параметром headroom.

Другие возможности технологии QoS

Существует много других механизмов QoS, не рассмотренных в данной главе.
Многие из них заслуживают отдельной книги. Ниже приведены некоторые другие
возможности системы IOS при разработке политики QoS для сети.

	Гарантированная скорость передачи данных (Commited Access Rate — CAR) —
популярный механизм распределения пропускной способности канала для вхо-
дящих и выходящих данных.

	Общее ограничение скорости (Generic Traffic Shaping — GTS) — возможность,
используемая для ограничения скорости передачи определенного потока дан-
ных через интерфейс.

	Протокол резервирования ресурсов (Resource Reservation Protocl — RSVP) — ме-
ханизм QoS, используемый для резервирования ресурсов сети.

Резюме

В данной главе описывалась реализация различных механизмов QoS в рамках операци-
онной системы Cisco IOS. Существ; тот два различных механизма обслуживания потоков
данных на необходимом уровне качества — управление перегрузками и предотвращение пе-
регрузок. Рассмотренные механизмы управления перегрузками содержат механизмы при-
оритетной и настраиваемой очередей, различные виды механизма взвешенной справедли-
вой очереди и механизм циклически изменяемого дефицита. Кроме того, был рассмотрен
один метод предотвращения перегрузок — метод случайного раннего обнаружения.

Резюме

189

Приложение

Протокол коммутации
NetftoW

Несмотря на1 то чт^йля'большинства пользователей работа протокола NetFlow
представляется в виде определения коммутационного пути пакета, на самом деле это

не так. NetFlow обеспечивает функционирование нескольких ключевых приложений,
которые пользователи могут использовать для учета (billing), мрниторинга и профили-
рования трафика. Протокол NetFlow предоставляет службы уйёта трафика (traffic ac-
counting) и возможность ускорения, а переключение пакетов выполняется с помощью
процесса коммутации или быстроЙ(‘коммутации, оптимальной коммутации, а также
протокола CEF (Cisco Express Forwarding). Таким образом, NetFlow может применять-
ся совместно с другими методами коммутации.

Потоком .(flow) является однонаправленная последовательность пакетов между за-
данными конечными точками отправителя и получателя. В контексте NetFlow поток
может быть представлен в виде комбинации следующих полей.

	IP-адрес отправителя.

	IP-адрес получателя.

	Номер порта протокола TCP или UDP, который используется приложением-
отправителем. ’

	Номер порта протокола TCP или UDP, который используется приложением-
получателем.’

	Тип протокеда 1Р.

	Тип сервиса IP (Type of Service — IP ToS).

	Входной лоГИческий йнтерфейс.

Когда служба NetFlow сконфигурирована для работы с интерфейсом, только те па-
кеты, которые приходят в данныйитнтерфейс, учитываются NetFlow. NetFlow не под-
считывает пакеты; которые выходят из интерфейса. Ниже описаны этапы алгоритма
обработки IP-пакёта, который входит в интерфейс с включенным NetFlow.

	Этап 1. Выполняется поиск потока в кэше (определение того, из чего состоит
поток, будет дано ниже).'

	Этап 2. Если в интерфейс доставлен первый пакет для данного потока, создает-
ся новая запись. Если пакет не является первым в данном потоке, обновляется
запись статистики потока в кэше.

	Этап 3. Если указаны какие-либо входные свойства (как, например, входные
списки доступа — access list) и если это первый пакет потока, проверяется спи-
сок доступа, чтобы убедиться, разрешена или запрещена передача пакета. Про-
верка списков доступа для всех последующих пакетов потока не выполняется.

	Этап 4. Поиск адреса получателя выполняется с помощью CEF, оптимальной
коммутации, быстрой коммутации или таблицы маршрутизации. Если поиск
адреса получателя увенчался успехом, пакет инкапсулируется в заголовок уров-
ня 2 (Layer 2) для передачи на выходной интерфейс.

	Этап 5. Выполняется проверка выходных свойств (как, например, выходные
списки доступа — access list) для первого пакета потока. Проверка списков дос-
тупа для всех последующих пакетов потока не выполняется.

	Этап б. Пакет передается на выходной интерфейс.

Функция NetFlow включается с помощью команды ip route-cache flow на уровне
конфигурации интерфейса. Кэш NetFlow хранится в памяти карт 7500 VIP и Line
Card в распределенных1 системах типа GSR (Gigabit Switch Router — гигабитовый
коммутирующий маршрутизатор) и в основной памяти обычных маршрутизаторов. По
мере поступления пакетов одного и того же потока в интерфейс счетчики статистики
трафика увеличивают свои значения для данного потока.

Управление кэшем потока

Размеры и количество записей в кэше потока зависят от аппаратной платформы. В
табл. А.1 приведены стандартные значения записей.

Таблица А.1. Стандартные значения записей кэша пс		'ТОКОВ	К;:
Аппаратная платформа	Стандартное количество элементоа в кэше	Стандартный объем памяти для кэша NetFlow
AS5800, 4x00, 3600, 2600, 2500, 1600, 1400	4000	256 Кбайт
7200, RSP7000	64000	4 Мбайт
Карта VIP с 16 Мбайт памяти	2000	126 Кбайт
Карта VIP с 32 Мбайт памяти	32000	2 Мбайт
Карта VIP с 64 Мбайт памяти	64000	4 Мбайт
Карта VIP с 128 Мбайт памяти	128000	6 Мбайт

Каждый раз, когда в кэш NetFlow добавляется новый поток, проверяется количество
доступных записей кэша. Если остается всего три свободных записи потока, NetFlow пы-
тается “состарить” 30 из существующих потоков, используя уменьшенное время существо-
вания. В том случае, если остается всего один свободный поток, NetFlow автоматически
удаляет 30 потоков независимо от их времени существования. Выполнение вышеуказан-
ных действий гарантирует, что всегда будут доступны свободные записи потоков.

Процесс “старения” используется для следующих потоков.

	Потоки, которые были неактивны (idle) в течение 15 секунд, являются устарев-
шими и удаляются из кэша.

' Под распределенными платформами здесь подразумеваются высокоскоростные магистральные
устройства (как, например, маршрутизаторы серии Cisco 12000), в которых обработка таблиц
маршрутизации и пакетов осуществляется не центральным процессором, а модулями интерфейсов
V1P и Line Card. — Прим, перев.
	Долго существовавшие потоки (настройка по умолчанию — больше 30 минут)
являются устаревшими и удаляются из кэша. Параметр “старения” потока мо-
жет быть настроен пользователем.

	TCP-потоки, которые достигли конца байтовой последовательности (F1N) или
сброшены в исходное состояние (RST), удаляются из кэша.

В примере А.1 показана выводимая командой show ip cache verbose flow информа-
ция с подробными сведениями о кэше NetFlow.

Пример АХ Использование команды show’ ip cache verbose flow ’
'•--il'S'#. vyJK---	'. - ' 	 '	• ’	.......:  	..	-

для получения подробной информации о кэше NetFlow

router#show ip cache verbose flow

IP packet size distribution (9703897 total packets):

1-32	64	96	128	160	192	224	256	288	320	352	384	416	448	480

.002	.675	.024	.003	.004	.007	.004	.004	.045	.006	.057	.021	.008	.007	.005

512	544	576	1024	1536	2048	2560	3072	3584	4096	4608

.004	.001	.011	.003	.098	.000	.000	.000	.000	.000	.000

IP Flow Switching Cache, 0 bytes
0 active, 0 inactive, 771407 added
11374632 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
last clearing of statistics never ’

Protocol	Total	Flows	Packets Bytes		Packets Active(Sec)		
Idle(Sec)	Flows	/Sec	/Flow	/Pkt	/Sec	/Flow	/Flow
							
TCP-Telnet	3849	0.0	4	141	0.0	11.6	14.9
TCP-FTP	2485	0.0	18	59	0.0	11.9	9.9
TCP-FTPD	2559	0.0	230	42	0.1	13.4	1.8
TCP-WWW	279804	0.0	10	82	0.6	8.7	3.2
TCP-SMTP	2718	0.0	42	523	0.0	10.9	3.2
TCP-X	7	0.0	21	40	0.0	18.6	5.5
TCP-BGP	3	0.0	3	48	0.0	3.2	15.5
TCP-NNTP	562	0.0	17	44	0.0	11.2	10.7
TCP-other	348262	0.0	16	348	1.3	6.8	4.5
UDP-DNS	92040	0.0	1	66	0.0	0.6	15.4
UDP-NTP	60	0.0	2	76	0.0	0.1	14.9
UDP-other	17451	0.0	6	218	0.0	10.5	15.4
ICMP	21603	0.0	3	62	0.0	4.8	15.4
IGMP	2	0.0	386	1434	0.0	104.2	15.7
IP-other	2	0.0	148	670	0.0	147.3	0.3
Total:	771407	0.1	12	246	2.2	6.9	5.9

Srclf	SrcIPaddress Dstlf	DstIPaddress Pr TOS Figs

Pkts
Port Msk AS	Port Msk AS NextHop	B/Pk Active

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

	Рг — байт поля протокола 1Р (как, например, ТСР=6, UDP=17);

	TOS — байт типа сервиса (Type of Service) в IP-заголовке;

	Figs — поле флагов содержит логическое ИЛИ (OR) для всех пакетов данного
ТСР-потока;
	AS — поле номера автономной системы (AS) протокола маршрутизации BGP (Border
Gateway Protocol). Поле может принимать значение, равное 0, в таких случаях.

•	Трафик направлен на маршрутизатор.

•	Данный поток не маршрутизируемый.

•	Трафик является локальным по отношению к автономной системе (другими
словами, трафик, который является исключительно внутренним).

•	Используется асимметричная маршрутизация. В том случае, если использу-
ется запросная схема кэша (быстрая, оптимальная коммутация) как основ-
ной метод пересылки пакетов, IP-адрес получателя или отправителя не мо-
жет храниться в кэше маршрутов согласно асимметричной маршрутизации.
Поскольку CEF управляется топологией сети, а не данными, именно он
может быть использован для решения данной проблемы.

•	Параметры peer-as или origin-as не были однозначно сконфигурированы. С
помошью команды ip flow-export version 5 peer-as | origin-as должны быть
четко заданы указанные параметры, для того чтобы разрешить сбор номеров
автономных систем (AS numbers).

Экспорт потока

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

	Версия 1 (vl). Формат версии 1 был оригинальным форматом, который изна-
чально поддерживался программным обеспечением Cisco 1OS, содержащим
возможности NetFlow.

	Версия 5 (v5). В эту версию добавлены номера автономных систем BGP (Border
Gateway Protocol) и номера последовательности потоков.

	Версия 7 (v7). В формат этой версии внесено усовершенствование, которое до-
бавляет поддержку NetFlow для коммутаторов серии Cisco Catalyst 5000, осна-
щенных модулем NetFlow (NetFlow Feature Card — NFFC). Версия 7 поддержи-
вается только непосредственно картой Catalyst 5000 NFFC.

	Версия 8 (v8). Версия 8 — это формат, используемый для экспорта агрегиро-
ванной статистики NetFlow с помошью RBA (Router-Based NetFlow
Aggregation — агрегирование потоков с помошью роутера); данная версия также
обеспечивает обшие номера последовательности потоков.

Версии 2—4 и 6 не были выпущены или не поддерживаются.

Дейтаграмма версии 1 может содержать до 24 записей потока, которые отсылаются в
одном пакете UDP размером около 1200 байт. В дейтаграмме версии 5 до 30 записей по-
токов может быть отправлено в одном пакете UDP размером приблизительно 1500 байт.
Для версии 7 размер дейтаграммы и количество потоков составляют 1500 и 28 байт соот-
ветственно. Вполне очевидно, что приложение, собирающее информацию о потоках,
должно поддерживать версию протокола, которая используется маршрутизатором.
Экспорт агрегированных данных протокола
NetFlow с помощью маршрутизатора

Экспорт потока из загруженного интерфейса с большим количеством потоков мо-
жет создавать весьма заметный трафик NetFlow. Схема RBA (Router-Based
Aggregation — агрегирование с помошью роутера для NetFlow версии 8) решает эту
проблему с помошью агрегирования потоков без экспорта индивидуальных номеров.
На момент написания этой книги IOS (Internetwork Operating System) поддерживала
пять схем агрегирования NetFlow.

	Схема агрегирования по автономным системам (autonomus system — AS) значитель-
но уменьшает объем экспорта данных NetFlow и генерирует данные о потоке по
типу “автономная система—автономная система”. Подобная схема агрегирования
группирует потоки данных с одинаковым BGP-адресом (Border Gateway Protocol)
автономной системы отправителя, одинаковым BGP-адресом автономной систе-
мы получателя, одинаковыми входным и выходным интерфейсами.

	Схема агрегирования по префиксу устройства-получателя генерирует данные та-
ким образом, что вы можете проверить адрес получателя сетевого трафика, про-
ходящего через интерфейс с сконфигурированным NetFlow. Данная схема аг-
регирования группирует потоки данных с одинаковым префиксом получателя,
маской префикса получателя, префиксом BGP автономной системы получателя
и одинаковыми выходным устройством.

	Схема агрегирования по префиксу генерирует данные таким образом, что вы може-
те проверить адреса отправителя и получателя сетевого трафика, проходящего через
устройство с сконфигурированным NetFlow. Данная схема агрегирования группиру-
ет потоки данных с одинаковым префиксом отправителя, с одинаковым префиксом
получателя, маской префикса отправителя, маской префикса получателя, префик-
сом BGP автономной системы отправителя, префиксом BGP автономной системы
получателя, одинаковыми входным и выходным интерфейсами.

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

	Схема агрегирования по префиксу устройства-источника создает данные таким
образом, что вы можете проверить адреса отправителей сетевого трафика, про-
ходящего через устройство с сконфигурированным NetFlow. Данная схема аг-
регирования группирует потоки данных с одинаковым префиксом отправителя,
одинаковой маской префикса, префиксом BGP автономной системы отправи-
теля и входным интерфейсом.

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

За более подробной информацией о схемах агрегирования NetFlow обратитесь на
сайт ССО (Cisco Connection Online) www.cisco.com и задайте в строке поиска
“NetFlow aggregation” (агрегирование NetFlow).
Предметный указатель

А

Алиас, 19

Б

Блокировка в конце линии, 148

Буфер

непрерывный, 95

переполнение, 80

постоянный, 37

распределенный, 95

слияние, 99

системный, 37; 38, 76

счетчик переполнения, 105

В

Взвешенная абсолютная
очередность, WFQ, 129

Взвешенное случайное аннулирование
пакетов на ранних этапах приема,
WRED, 129

И

Интерфейс
дескриптор, 44
командной строки, 22, 26
подавление, 105; 107

Исполнение до полного завершения
в порядке FIFO, 12

К

Качество обслуживания
механизм

выборочного аннулирования пакетов, 189

распределенной взвешенной справедливой
очереди, 180

случайного раннего обнаружения, 186

циклически изменяемого дефицита, 183
очередь

настраиваемая. 168

приоритетная, 166

с низкой задержкой, 179

справедливая взвешенная, WFQ, 171

перегрузки

предотвращение, 166

управление, 165

Кольцо, 76

передачи, 78, 135

приема, 78, 131

Коммутатор TDM, 103

Коммутация

автономная, 90

быстрая коммутация, 53; 60, 69

быстрый кэш, 53; 55

аннулирование, 58; 59

базисное дерево, 56

структура, 55

удаление записей, 58

м-дерево, 61

оптимальная, 61; 69

программная, 47; 69, 109

протокол CEF, 61; 63; 64; 66; 69

распределенная, 131

структура балансировки нагрузки, 67

таблица CEF, 64

таблица связей, 66

Контекст, 12

Контроллер

ввода-вывода, 102, 103

интерфейса, 76

Коэффициент

балансировки нагрузки, 50

Куча, 14; 20

Кэш, 53

м

Материнская плата

VXR, 100

базовая, 100

Менеджер

областей памяти, 31

пакетного буфера, 37

пулов памяти, 31

фрагментов, 35

Многозадачная операционная система, 12

Многозадачность, 12

Модуль

NPE-100, 100

NPE-150, 100, 104

NPE-175, 100

NPE-200, 100
NPE-225, 100

NPE-300, 101

VIP, 128

портов, 99, 102, 103

сетевой операционный, NPE, 99, ЮГ, 102

п

Память

MEMD, 91; 114

блок управления памятью, 14

быстрая пакетная, 89

ввода-вывода, 73; 74

виртуальная, 14

локальная, 73

области, 17

пакетная, 129, 156; 157

передающая пакетная, 154

подобласти, 17

приемная пакетная, 152

разделяемая, 74

утечка, 36

фрагментация, 31

Переключение контекстов, 13

Планирование, 12

с приоритетным прерыванием, 13

Планировщик, 27

очередь процессов, 27

Поток, 12

Предельное значение

очереди передачи, 92

очереди приема, 92

Прерывание, 21

на получение, 49

обработчик, 15

приоритетное, 13

Приоритетное исполнение до полного
завершения, 13

Протокол

CEF, 63

E1GRP, 22

NetFlow, 191

Процесс, 12

ipjnput, 49, 52

Процессор

интерфейсный, 92

коммутации, 92

коммутации-маршрутизации, 111

маршрутизации, 92

многоцелевой интерфейсный, VIР, 11 Г, 127

центральный, 72, 89, 114', 129, 149

Пул

быстрой коммутации, 98

быстрой памяти, 120

ввода-вывода, 103

нормальный, 98, 104

процессорной памяти, 120

Пул памяти, 19

ввода-вывода, 20

локальный, 20

шины РС1, 20; 103

С

Синтаксический анализатор, 22

Сторожевой таймер, 30

Счетчик

аннулированных пакетов, 118, 122

балансировки нагрузки, 50

дефицита, 183; 184

игнорированных пакетов, 81; 84, 125; 131

количества подавлений, 107

переполнения буфера, 106

программный, 25

ш

Шина

Cbus, 89, 99, 112

быстрая пакетная память, 90

multibus, 89

PCI, 101; 103; 129

ввода-вывода, 102, 103

обслуживания, 149

Я

Ядро, 12, 27
Научно-популярное издание

Виджэй Боллапрагада, Кэртис Мэрфи, Расс Уайт

Структура операционной системы Cisco IOS

Литературный редактор

Верстка

Художественный редактор
Корректор

И.А. Попова

К. В. Самоцветов

В. Г. Павлютин

О. В. Мишу тина

Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д. 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.

Подписано в печать 25.02.2002. Формат 70x100/16.

Гарнитура Times. Печать офсетная.
Усл. печ. л. 16,77. Уч.-изд. л. 17,71.

Тираж 3500 экз. Заказ № 29.

Отпечатано с диапозитивов в ФГУП “Печатный двор”
Министерства РФ по делам печати,
телерадиовещания и средств массовых коммуникаций.

197110, Санкт-Петербург, Чкаловский пр., 15.