УМК Проектир.и Мод.Сетей

В.Н. ТАРАСОВ, Н.Ф.
БАХАРЕВА,
А.Л. КОННОВ, Ю.А . УШАКОВ
ПРОЕКТИРОВАНИЕ
И МОДЕЛИРОВАНИЕ СЕТЕЙ ЭВМ
В СИСТЕМЕ OPNET Modeler
Лабораторный практикум
ИЗДАНИЕ ВТОРОЕ,
ДОПОЛНЕННОЕ
Рекомендовано ГОУ ВПО

МГТУ им. Н.Э. Баумана
в качестве учебного пособия
для студентов высших учебных
заведений, обучающихся по
специальности 230105
Программное обеспечение
ВТ и АС»
Рег.№ рецензии 040 от 13.03.2008 г.
МГУП
Оренбург 2012
Т19
УДК 004.942(075.8)
Рецензенты:
декан факультета информационных систем и
технологий, заведующий кафедрой информационных
систем и технологий ПГУТИ д.т.н., профессор
М.А.Кораблин; заведующий кафедрой передачи
дискретных сообщений д.т.н., профессор
Б.Я.Лихтциндер; доцент кафедры компьютерных
систем и сетей МГТУ им. Н.Э.Баумана Б.И.Ващенко.
Тарасов В.Н., Бахарева Н.Ф.,

Коннов А.Л., Ушаков Ю.А.
Т 19 Проектирование и моделирование сетей

ЭВМ в системе OPNET Modeler.
Лабораторный практикум. – Оренбург:
2012. – 258 с.
ISBN 978-5-904029-01-2
Учебное пособие предназначено для студентов

специальностей по направлению подготовки 230100 –
Информатика и вычислительная техника.
©Тарасов В.Н., Бахарева Н.Ф.,

Коннов А.Л., Ушаков Ю.А.
2
СОДЕРЖАНИЕ
Предисловие от авторов 6
Введение 7
1 Технология IT Guru 9
1.1 Редактор проекта 9
1.2 Проектирование небольших объединенных сетей 13
1.3 Выполнение задания 14
1.4 Расширение сети 29
1.5 Руководство по устранению ошибок 35
моделирования
2 Оценка соединений INTERNET для небольшой сети 37
2.1 Содержание лабораторной работы 1 37
2.3 Установка WAN cвязи на скорость 20 Кб/с 40
2.4 Настройка, запуск сценария и анализ результатов 41
2.5 Сценарий соединения на 40 Кб/с 44
2.6 Сценарий соединения на скорость 512 Кб/с 45
2.7 Сценарий связи по выделенному соединению Т1 46
2.8 Выводы по лабораторной работе 48
2.9 Задания на самостоятельную работу 48
3 Проектирование и моделирование ЛВС 50
многоэтажного здания
3.3 Моделирование сети 53
4 Оценка производительности WAN приложения 61
4.3 Оценка производительности сети 65
4.4 Сравнительный анализ результатов 69
4.5 Сравнительный анализ производительности 72
сети для всех сценариев
5 Влияние скорости канала PVC FRAME 78
RELAY на производительность приложений
3
5.3 Изменение параметров связей сети 82
6 Исследование влияния размера окна ТСР на 86
выполнение приложения
7 Применение межсетевого экрана для 94
управления трафиком вычислительной сети
8 Оценка производительности приложений 104
ORACLE
8.3 Моделирование обмена данными 110
9 Технология ETHERNET 117
9.4 Выбор статистик и вычисление их средних 124
значений
10 Внедрение и использование 130
коммутированных ЛВС
10.3 Моделирование сети по сценариям 136
11 Проектирование и оптимизация сети 142
4
12 Пакетно– коммутированная технология АТМ 155
12.3 Одновременное моделирование сценариев 168
13 Моделирование протокола контроля 172
передачи TCP
13.3 Одновременное моделирование сценариев 180
14 Проектирование и моделирование сетей 186
кафедры ВУЗа и кампуса
14.4 Модель сети кафедры ВТ 195
14.5 Анализ трафика сети 197
14.6 Моделирование сети кафедры в системе 198
OPNET Modeler
14.7 Моделирование сети кампуса 204
15 Проектирование кабельной системы 212
16 Краткий обзор программных систем для 225
структурного моделирования сетей и систем
телекоммуникаций
16.1 Программная система NETWisard 225
16.2 Система NetCracker 236
Список использованных источников 245
Приложение 246
Глоссарий 254
5
ПРЕДИСЛОВИЕ ОТ АВТОРОВ
Предлагаемое пособие является фактическим

продолжением учебного пособия «Компьютерное
моделирование вычислительных систем. Теория, алгоритмы,
программы. Допущено УМО вузов по университетскому
политехническому образованию для студентов, обучающихся
по направлению 230100 «Информатика и вычислительная
техника» (авторы - Тарасов В.Н, Бахарева Н.Ф.). В нем были
изложены теоретические основы моделирования
вычислительных систем, включая аналитическое
вероятностное (первый раздел) и имитационное
моделирование (второй раздел). При этом в первом разделе,
кроме результатов из теории массового обслуживания,
рассматривалось применение программной системы
PROBMOD, разработанной авторами, для моделирования
различных вычислительных систем. Во втором разделе
рассматривались базовые модели вычислительных систем на
основе универсального языка системного моделирования
GPSS World.
В данном пособии предлагается лабораторный практикум
по проектированию и моделированию сетей ЭВМ с помощью
программной системы OPNET Modeler IT Guru. Каждая
лабораторная работа в пособии представляет собой решение
отдельной проблемы из области сетевых технологий.
Работа с этой программной системой предполагает
обязательное знакомство пользователей с курсом «Сети ЭВМ
и телекоммуникации» Государственного образовательного
стандарта ВПО для направления подготовки 230100
«Информатика и вычислительная техника».
Авторы надеются, что данное пособие будет полезным и
интересным не только студентам, но и аспирантам,
обучающимся по данному направлению.
Во втором издании расширен раздел 14 и добавлен новый
раздел о структурированных кабельных системах.
6
Введение
В данном пособии изложены основы обучения

информационным технологиям (технологии IT Guru). В
эти технологии входит также программная система OPNET
Modeler, применению которой в проектировании и
моделировании сетей ЭВМ посвящено данное пособие.
Для работы в программной системе OPNET Modeler
сначала необходимо установить стандартные и учебные
модели. Они могут быть установлены автоматически по
умолчанию вместе с программной системой (см. в
ПРИЛОЖЕНИИ инструкцию пользователя). В дальнейшем
под словосочетанием IT Guru будем иметь ввиду именно
эту программную систему.
Стандартные модели содержат широкий набор
протоколов и устройств (ресурсов сети) и они находятся в
специальной поддиректории установленной IT Guru:
<каталог guru>\models\std\<название протокола>,
где <каталог guru> - это директория установленной IT
Guru.
Определить эту директорию поможет пункт меню
помощь о программе (Help About this application),
затем необходимо найти строку <корневой каталог
OPNET> (OPNET root directory) в секции <системная
информация> (System Information) и добавить номер
версии из строки <релиз> (Release).
Например, <каталог guru> для компьютера с ОС
Windows будет
C:\Program Files\OPNET EDU\<версия>.
Будем рассматривать использование особенностей IT
Guru для создания и анализа моделей сетей. В каждом
разделе пособия представлена отдельная проблема
моделирования, которую необходимо решить путем
создания модели сети, сбора статистики о ней и анализа
полученных результатов. Таким образом, каждое задание
поможет больше узнать о программе IT Guru путем
демонстрации проблем, решаемых при помощи этой
программы.
Для полного освоения программной системы
7
необходимо последовательно выполнить все задания.
Большинство заданий имеют ключевые параграфы,
которые содержат новую информацию о программе IT Guru
и описывают важные детали теории проектирования и
моделирования сетей ЭВМ.
Замечания. 1. Для тех пользователей, у кого нет этой
программной системы, в Приложении к пособию
приведены правила получения инсталляции программы, ее
регистрации, установки и запуска.
2. В глоссарии в конце пособия дается толкование ряда
используемых терминов из области сетевых технологий.
8
1 ТЕХНОЛОГИЯ IT GURU
Вкратце рассмотрим технологию IT Guru, а прежде всего

рабочую область программы и редактор проекта.
Под технологией IT Guru подразумевают
совокупность действий для создания модели
сети и проведение на ней имитационных Начало
экспериментов. Для этого рассмотрим
редактор проекта (Project Editor). С его
помощью можно создавать модель сети, Создание
модели сети
выбирать требуемую статистику, собираемую
с каждого объекта сети или со всей сети,
запускать процесс моделирования и Выбор
осуществлять просмотр результатов. Ниже статистик
будет рассмотрено тренировочное задание,
состоящее из двух частей.
Прогон модели
В первой части показывается, как с Просмотр и

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

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

Разные области окна редактора проекта отвечают за создание
(рисунок 1.1) и прогон модели. Об этом будет сказано ниже.
9
Рисунок 1.1 – Модель сети в редакторе проекта
Когда открыт какой-либо проект, то экран редактора

будет выглядеть так, как показано на рисунке 1.2.
Рисунок 1.2 – Окно редактора проекта

10
Меню
Меню расположено в верхней части окна редактора.
Оно упорядочивает все контекстно-независимые операции
редактора в набор тематических меню. Количество меню и
их операции могут изменяться в зависимости от активных
модулей программы. Контекстное меню редактора
появляется при нажатии правой кнопки мыши на объекте
или на фоне рабочей области.
Панель инструментов
Несколько наиболее часто используемых действий
меню могут быть доступны через панель инструментов, она
отображена на рисунке 1.3.
Рисунок 1.3 – Панель инструментов
Наиболее часто используемые кнопки при выполнении

заданий приведены в таблице 1.
Таблица 1 – Кнопки панели инструментов

1.Открыть палитру 6. Увеличить масштаб
компонентов
2. Проверить 7. Уменьшить масштаб
работоспособность
соединения
3. Отключить выделенный 8. Настроить
объект моделирование отдельных
событий
4. Включить выделенный 9. Посмотреть результаты
объект моделирования
5. Назад в родительскую 10.Показать/скрыть все
подсеть графики
11
Рабочая область
Центральное место в редакторе занимает прокручиваемая
рабочая область. В ней располагается модель сети, там
же можно выделять и перемещать объекты, а также
вызывать контекстные меню нажатием правой кнопки
мыши на фоне.
Строка сообщений
Строка сообщений находится внизу окна редактора. Она
отображает информацию об операциях:
Если щелкнуть левой кнопкой мыши по картинке справа

от строки сообщений, то откроется окно истории
сообщений. Оно показывает список сообщений,
возникающих в строке сообщений. Если часть
сообщения обрезана или последние сообщения заместили
важное предупреждение или напоминание, то можно
открыть окно истории.
Всплывающие подсказки
Если задержать указатель мыши на кнопке панели
инструментов или объекте сети в рабочей области, то
возникнет всплывающая подсказка. Она описывает либо
действие, присвоенное кнопке, либо информацию об
объекте сети. Пример такой подсказки приведен на
рисунке 1.4.
Рисунок 1.4 – Всплывающая подсказка
Документация
Время от времени могут возникнуть вопросы о
12
различных аспектах использования программной системы,
а также инструментов или моделей.
В таких случаях нужно обращаться к литературе, которая
приведена в конце пособия.
Замечание. Академическая версия IT Guru поставляется
с ограниченными функциональными возможностями и
документацией. Коммерческая версия поставляется с
полной документацией, учебниками, технической
поддержкой online или по телефону.
1.2 Проектирование небольших объединенных сетей

Задание на проектирование
1. Спроектировать небольшую сеть с помощью редактора
проекта (Project Editor).
2. Выбрать виды статистик для сбора.
3. Провести имитационное моделирование и
проанализировать полученные результаты.
Предположим, что планируется расширение внутренней
сети маленькой компании. В данный момент компания
использует сетевую топологию типа «звезда» на одном
этаже и планирует добавить еще одну сеть с топологией
«звезда» на другом этаже. Необходимо спроектировать
такую сеть и убедиться, что дополнительная нагрузка от
второй сети будет приемлемой (рисунок 1.5).
13
Рисунок 1.5 – Результирующая сеть
1.3 Выполнение задания
Перед созданием новой модели сети необходимо

добавить новый проект (project) и сценарий (scenario).
Проект - это группа зависимых сценариев, каждый из
которых описывает различные детали сети. Проект может
содержать множество сценариев.
После создания нового сценария для добавления нужно
использовать начальный <мастер запуска> (Startup
Wizard). Параметры мастера позволяют:
- определить начальную топологию сети;
- определить масштаб и размер сети;
- выбрать карту для фона сети (план здания, города);
- сопоставить палитру компонентов (базу ресурсов сети)
сценарию.
Замечание. <Мастер запуска> автоматически открывается
каждый раз при создании проекта и помогает выбрать
14
необходимые свойства сетевой среды.
Для создания нового сценария с помощью мастера
необходимо:
1. запустить IT Guru;
2. выбрать пункт <файл> новый… (File New…);
3. из выпадающего меню выбрать <проект> (Project) и
нажать Ok;
4. назвать проект и сценарий по следующему принципу:
- название проекта - <ваши инициалы>_Sm_Int (
это необходимо
чтобы не спутать этот проект с другими версиями);
- назвать сценарий first_floor;
- нажать Ok (тогда запустится начальный мастер);
5. ввести значения из таблицы 2 в диалоговых окнах
мастера.
Таблица 2
Название диалогового Значение
окна
1.Начальная топология Выбрать значение по
(Initial Topology) умолчанию: создать пустой
сценарий (Create empty
scenario)
2.Выбор масштаба сети Выбрать Office (сеть
(Choose Network Scale) масштаба офиса). Поставить
галку в поле использовать
метрическую систему (Use
metric Units)
3.Определение размеров Выбрать размер по
(Specify Size) умолчанию 100м х 100м
4.Выбор технологий Включить семейство
(Select Technologies) моделей Sm_Int_Model_list
5. Обзор (Review) Проверить значения и
нажать Ok
После этого создается рабочая область заданного

размера. В отдельном окне откроется палитра заданных
объектов (база ресурсов).
15
Создание топологии сети
Модель сети создается с помощью редактора с
использованием узлов (nodes) и каналов связи (links) из
базы ресурсов (object palette).
Узел сети (node) – это реальный объект сети, который
может передавать и принимать информацию.
Рисунок 1.6 – Узлы сети
Канал связи (link) – среда передачи данных,

соединяющая узлы. Связь может быть представлена
электрическим или оптоволоконным кабелем.
Рисунок 1.7 – Канал связи
Все эти объекты находятся в базе ресурсов (окне с

изображениями узлов и связей, Object Palette).
Замечание. Можно использовать любой из трех
указанных методов создания топологии сети или же их
комбинацию. Первый метод – импорт топологии
(рассматривается в следующем задании). Второй –
расстановка узлов и связей из базы ресурсов в рабочей
области. Третий метод заключается в использовании
метода «быстрого создания топологии» (Rapid
Configuration).
Метод «быстрого создания топологии» (Rapid
Configuration) создает сеть за одно действие, после выбора
топологии сети, типов узлов и типов связей между узлами. Для
создания сети первого этажа здесь использован метод
16
«быстрого создания топологии».
1. Выбрать пункт <топология> <быстрое
создание топологии> Rapid
(Topology
Configuration).
2. Выбрать <звезда> (Star) из выпадающего списка
и нажать Ok.
Рисунок 1.8 – Выбор топологии
3. Определить модели узлов и каналов связи сети.

Модели подчиняются следующей структуре
обозначений:
<протокол 1>_<протокол
n>_<функция>_<модификация>,
где:
<протокол> - это протокол сети, поддерживаемый
моделью;
<функция> - сокращенное описание основной
функции модели;
<модификация> - означает уровень отклонения модели
от идеальной.
Например, ethernet2_bridge_int означает сетевой мост
(bridge) с 2-мя портами Ethernet (ethernet2) и средним
отклонением (int – intermediate).
Модели оборудования разных фирм имеют
дополнительный префикс, определяющий фирму
производитель и номер (модель) устройства для
17
конкретного объекта сети.
Например, коммутатор 3COM, используемый в данном
задании, называется 3C_SSII_1100_3300_4s_ae52_e48_ge3.
Этот узел – стек из двух коммутаторов 3Com SuperStack II
1100 и два шасси Superstack II 3300 (3C_SSII_1100_3300)
с четырьмя слотами расширения (4s), 52 портов Ethernet с
авто-определением (ae52), 48 обычных портов Ethernet
(e48), и 3 гигабитных порта Ethernet (ge3).
Проектирование сети
1. Установить модель центрального узла (Center Node
Model) в 3C_SSII_1100_3300_4s_ae52_e48_ge3 - это
коммутатор 3Com.
2. Установить модель периферийного узла (Periphery
Node Model) в Sm_Int_wkstn и изменить количество
(Numbers) на 30. Этим создается 30 Ethernet станций в
качестве периферийных узлов.
3. Установить модель канала связи (Link model) в
10BaseT.
4. Определить, где (на карте или плане) будет
размещаться новая сеть.
5. Установить X center и Y center на 25.
6. Установить <радиус> (Radius) на 20.
7. Нажать Ok (рисунок 1.9).
18
Рисунок 1.9 – Окно быстрой конфигурации
После этого в окне редактора появится искомая сеть

(рисунок 1.10).
Рисунок 1.10 - Полученная сеть

19
После создания основной топологии сети в схему нужно
добавить сервер. Для этого будем использовать второй
метод создания объектов сети.
1. Открыть базу ресурсов нажатием на
кнопку <палитра> (Object Palette) для
перемещения объектов на рабочую область.
2. Найти Sm_Int_server и переместить на рабочую

область. Такой модели сервера, кроме как в этой
палитре (Sm_Int_Model_List) больше нигде нет. Она
специально создана для этих заданий. По умолчанию
можно создавать дополнительные копии объектов
простым нажатием левой кнопки мыши на рабочей
области.
3. Чтобы больше не добавлять копий сервера, нужно
нажать правую кнопку. Затем надо присоединить
сервер к сети. Для этого необходимо выполнить
следующие действия:
- найти объект типа «связь» с названием 10BaseT и
нажать на нее;
- нажать на сервер, а потом - на центр звезды;
- нажать правую кнопку для того, чтобы закончить
создание связей.
Далее необходимо определить характер трафика в сети.
Для этого задания в базе ресурсов уже есть все
необходимое, а именно:
- настроенный объект описания приложений;
- настроенный объект описания профилей.
Теперь необходимо переместить эти объекты в сеть, и
этим будет смоделирован трафик доступа рабочих станций
к базе данных с небольшой загрузкой. Для этого выполнить
действия:
- найти объект Sm_Application_Config в палитре и
переместить его на рабочую область;
- нажать правую кнопку мыши (чтобы не создавать
больше объектов);
- найти объект Sm_Profile_Config в палитре и
переместить его на рабочую область;
- закрыть палитру.
20
Теперь сеть создана и она приведена на рисунке 1.11.
Рисунок 1.11 – Сеть первого этажа
Далее можно переходить к этапу сбора и обработки

статистических данных. Статистические данные о
функционировании сети можно получить от конкретного
узла сети (object statistics) или же со всей сети (global
statistics). Чтобы определить, какую статистику собирать,
надо ответить на два вопроса.
1. Сможет ли сервер выдержать дополнительную
нагрузку от второй сети?
2. Будут ли приемлемыми задержки в сети при
добавлении второй сети?
Для того, чтобы ответить на эти вопросы, необходимо
оценить текущую производительность сети. Чтобы
получить такую оценку, нужно иметь статистические
данные с конкретного узла (загрузку сервера, Server Load),
и глобальную статистику (задержки Ethernet, Ethernet
Delay).
Загрузка сервера - это ключевая статистика, влияющая
на производительность сети.
21
Сбор статистики, основанной на загрузке сервера
1. Нажать правой кнопкой мыши на сервере
(node_31) и нажать <выбрать
индивидуальную статистику> (Choose
Individual Statistics) из контекстного меню.
Появится окно выбора результата (Choose
Result), как показано на рисунке 1.12.
Рисунок 1.12 – Окно выбора результата
Это окно показывает дерево статистик, которые можно

собрать. Чтобы выбрать статистику загрузки сервера,
нужно выполнить следующие действия:
22
2. нажать знак «+» возле <Ethernet>, чтобы
раскрыть всю ветку статистик Ethernet;
3. поставить галку возле <загрузка (бит/с)>
(Load(bits/sec)) для сбора этой статистики;
нажать Ok.
Рисунок 1.13 – Выбор глобальных статистик
1. Раскрыть дерево <глобальная статистика> (Global

Statistic).
2. Раскрыть ветку <Ethernet>.
3. Поставить галку возле <задержка (с)> (Delay (sec))
для сбора данных.
4. Нажать Ok для закрытия окна.
В процессе работы нужно сохранять проект как можно

чаще. Для сохранения проекта нужно выбрать пункт
<файл> <сохранить> (File Save), а потом нажать Ok
(у проекта уже есть имя и не надо его переименовывать).
Теперь, когда определены статистики для сбора и
проект сохранен на диске, можно начать прогон модели.
Первым делом необходимо убедиться, чтобы свойство
«репозиторий»(Repositories) было задано. «Репозиторий»
включает в себя определенные пользователем компоненты,
23
например сохраненные модели процессов и такую
организацию конвейеров, при которой устанавливается
меньшая задержка перед началом прогона. Для этого
выполнить следующие действия:
- выбираем пункт
<правка> <настройки>
(EditPreferences);
- вводим <репозиторий> (Repositories) в поле
<поиск> (Find) нажатием на одноименную
кнопку;
- если значение репозитория не равно stdmod, то
изменяем поле на stdmod.
Начало прогона модели

1.Выбрать пункт <моделирование> <настроить
моделирование отдельных событий>
Configure Discrete Event Simulation).
(Simulation
Это же окно можно открыть нажатием
кнопки <настройка/прогон> (configure/run
simulation).
2.Ввести 0.5 в поле <продолжительность> (Duration)
для моделирования получаса сетевой активности.
Рисунок 1.14 – Задание длительности прогона
3.Нажать кнопку <начать> (Run) для начала прогона.

Во время прогона появится окно (рисунок 1.15),
показывающее ход его выполнения.
Из этого рисунка видно, что 5 секунд реального
времени было промоделировано за 15 минут 19 секунд
модельного сетевого времени. Этот прогон мог бы
закончиться раньше, но время моделирования всегда
зависит от скорости компьютера. После завершения
24
прогона откроется вкладка <сообщения> (Messages). В
этом случае необходимо нажать кнопку Close.
Если же прогон завершился неудачно (не собраны
статистики), или результаты значительно отличаются, то
необходимо выявить и устранить ошибки моделирования.
Для этого нужно ознакомиться с разделом «Руководство по
устранению ошибок моделирования».
Рисунок 1.15 – Окно выполнения прогона:

1) Elapsed time – длительность прогона в
секундах;
2) Simulated time – модельное время.
Просмотр результатов
Результирующие графики можно просмотреть выбором
пункта <просмотр результатов> (View Result)
выпадающего меню редактора проекта.
25
После каждого прогона необходимо анализировать
собранную статистику. Это можно сделать несколькими
способами. В этом же задании будет использоваться пункт
меню <просмотр результатов> (View Result)
выпадающего меню редактора проекта.
В следующих заданиях будут описаны другие способы
просмотра результатов.
Рассмотрим загрузку сервера Ethernet, для этого:
- щелкнуть правой кнопкой мыши по объекту
сервер, из выпадающего меню выбрать пункт
<просмотр результатов> (View Result) и
откроется окно просмотра результатов объекта;
- раскрыть ветки <Office
network.node_31> <Ethernet>;
- поставить галку возле поля <загрузка (бит/с)>
(Load (bits/sec)) для отображения результатов;
- нажать <показать> (Show), тогда отобразится
трафик на входе сервера (рисунок 1.16).
Результаты моделирования могут отличаться из-за
расположения сервера и длины кабеля. Заметим, что пик
загрузки сервера ниже 6000 бит/с. Это будет точкой
отсчета для сравнения загрузки после добавления второй
сети.
После просмотра результатов нужно закрыть окно с
графиком и окно с выбором типа результата. Если
программа запросит подтверждение закрытия окна, то
нужно нажать кнопку <удалить> (Delete) с панели.
26
Рисунок 1.16 – Трафик на входе сервера:
по оси Х- время в минутах, по Y- загрузка в бит/с.
Также можно посмотреть <глобальные задержки

Ethernet> сети, для этого:
- щелкнуть правой кнопкой мыши по рабочей области и
выбрать пункт <просмотр результатов> (View Result) из
выпадающего меню;
- поставить галку возле <глобальная статистика>
<Ethernet> <задержки> (Global
Ethernet
Statistics Delay) и нажать <показать> (Show).
Заметим, что после стабилизации сети наибольшая
задержка составляет примерно 0,4 мс (рисунки 1.17, 1.18).
После просмотра результатов нужно закрыть оба окна.
27
Рисунок 1.17 – Глобальные задержки Ethernet сети
Рисунок 1.18 – График задержек Ethernet сети
28
1.4 Расширение сети
Теперь, когда точка отсчета создана и собрана

статистика, все готово к расширению сети и оценки
дополнительной загрузки.
Во время сравнения сетей необходимо сохранить
базовую сеть как один сценарий, а экспериментальную сеть
создать в другом сценарии. Необходимо скопировать
существующий сценарий и уже в копии можно делать
изменения топологии.
Для копирования сценария необходимо выполнить
-выбрать пункт меню <сценарии> <продублировать
сценарий> (Scenarios Duplicate Scenario…);
- ввести имя нового сценария – <expansion>;
- нажать кнопку Оk.
Сегмент второго этажа похож на сегмент первого этажа,
но не имеет своего сервера.
Создание нового сегмента сети

1. Выбрать пунт меню <топология> <быстрая
настройка топологии> Rapid
(Topology
Configuration).
2. Выбрать <звезда> (Star) и нажать Оk.
3. Заполнить следующие поля:
- модель центрального узла (Center node model):
3C_SSII_1100_3300_4s_ae52_e48_ge3;
- модель периферийных узлов (Periphery Node Model)-
Sm_Int_wkstn;
- количество (Number)- 15;
- тип связи (Link Model)- 10BaseT;
- X:75, Y:62.5, Радиус (Radius)- 20 (рисунок 1.20).
4. Нажать Оk.
Теперь надо соединить две сети, а для этого открываем

базу ресурсов, если она закрыта.
29
Рисунок 1.19 – Окно настройки
5. Переместить картинку маршрутизатора Cisco 2514

на рабочую область между двух сетей. Нажать правую
кнопку мыши для отмены дальнейшего добавления
объектов.
6. Нажать на объект 10BaseT в палитре ресурсов.
7. Создать связи между маршрутизатором Cisco
(node_50) и коммутаторами 3Com в центре каждой
звезды.
8. Нажать правую кнопку мыши для отмены
дальнейшего добавления объектов.
9. Закрыть палитру.
10. Выбрать пункт меню <файл> <сохранить>
Save ).
(File
В результате всех действий получим сеть, показанную
на рисунке 1.20.
30
Рисунок 1.20 – Сеть после преобразования
Прогон сценария
1. Выбрать пункт меню <моделирование>
<настроить моделирование отдельных событий>
(Simulation Configure Discrete Event Simulation).
2. Длительность прогона должна составить 0.5 часа.
3. Нажать кнопку <прогон> (Run).
После этого откроется окно, показывающее процесс
прогона. Когда открыта вкладка <скорость прогона>
(Simulation Speed), на анимированном графике
показывается текущая и средняя скорость моделирования в
событиях/секунду (рисунок 1.21).
4. После окончания моделирования необходимо
закрыть окно. Если возникли какие-нибудь ошибки, то
нужно смотреть раздел «Руководство по устранению
ошибок моделирования».
31
Рисунок 1.21 – Прогон модели
Сравнение результатов
Для ответа на вопрос, как повлияет добавление
второй сети на существующую сеть, необходимо
сравнить результаты моделирования.
Для этого можно использовать пункт меню <сравнение
результатов>(Compare Results) во всплывающих
контекстных меню рабочей области и объекта. Он
помещает статистики разных сценариев на один график.
Просмотр загрузки сервера в обоих сценариях
1. Нажать правую кнопку мыши на объекте <сервер>
(node 31) для вызова контекстного меню.
2. Выбрать <сравнить результаты> (Compare Results)
(это можно делать из любого сценария в проекте).
Если результаты графика сильно отличаются от
рисунков 22-24, то нужно смотреть раздел «Руководство по
32
устранению ошибок моделирования».
Во время сравнения результатов выбор статистики для
одного сценария влечет показ статистик для всех
сценариев. Для этого необходимо выбрать Office
Network.node_31 Ethernet Load (bits/sec) и нажать
кнопку Show. Результат должен походить (но не совпадать)
на рисунок 1.22.
Рисунок 1.22 – Трафик на входе сервера во времени
Следующий рисунок показывает усредненную загрузку

обоих сценариев, а в следующих заданиях будет показано,
как вывести усредненную загрузку на график.
33
Рисунок 1.23 – Усредненная загрузка
Обратим внимание на то, что в то время как средняя

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

1. Закрыть окно сравнения результатов для сервера.
2. Нажать правую кнопку мыши на рабочей области
и выбрать <сравнить результаты> (Compare
Results) из контекстного меню
3. Выбрать <глобальная статистика> Ethernet
Задержки (с) (Global Statistics
Ethernet Delay(sec))
4. Нажать кнопку <показать> (Show).
График должен походить на рисунок 1.24. Результат
показывает, что нет значительных отличий в задержках
Ethernet. В отличие от загрузки сервера, которая
увеличилась, задержки сети не изменились.
34
Рисунок 1.24 – Задержки Ethernet
Теперь необходимо выбрать пункт

<файл> <закрыть> (File
Close) и сохранить изменения
перед закрытием.
1.5 Руководство по устранению ошибок

моделирования
Если прогон модели закончился не так, как ожидалось,

необходимо определиться, в проекте проблема или в
инсталляции программы?
Каталог <tutorial_ref> содержит полные модели для
каждого задания. Если прогон выполнялся с
использованием только моделей <tutorial_ref>, то это
означает, что проблема заключена в самом проекте.
Рассмотрим эти проблемы более подробно.
Добавление каталога <tutorial_ref>

Сначала необходимо добавить каталог <tutorial_ref> в
список модельных каталогов.
1. Выбрать пункт файл файлы моделей добавить
каталог с моделью (File Model Files Add Model
35
Directory).
2. Выбрать местоположение каталога <tutorial_ref>
<каталог guru>\models\tutoral_ref\itguru.
3. Нажать Ok или <выбрать> (Choose).
4. В диалоговом окне <добавление к модельным
каталогам> (Add to Model Directories) нажать кнопку
<исходный каталог> (Source Directory).
Добавление каталога <tutorial_ref> в mod_dirs

Необходимо убедиться, что этот каталог добавлен в
параметр mod_dirs и что он не первый в списке (не
рабочий).
Модели обычно сохраняются в рабочем каталоге
<op_models>.
1. Выбрать пункт <правка> <настройки> (Edit
Preferences).
2. Ввести mod_dirs в поле <поиск> (Find) и нажать
одноименную кнопку. Выбрать параметр mod_dirs.
3. Просмотреть значения параметра нажатием в поле
<значение> (Value).
4. Найти каталог <tutorial_ref> в списке ( он не должен
быть первым).
Далее необходимо запустить прогон модели <имя
задания>_ref.
1. Выбрать <файл> <открыть> (File Open) и
нажать на модель <имя задания>_ref (например,
Sm_Int_ref).
2. Выбрать требуемый сценарий и запустить прогон.
Если прогон завершится, то проблема в вашей модели.
Вернитесь к первой странице задания и внимательно
сравните инструкции задания и вашу модель. Можно
сравнить с моделью <имя задания>_ref.
Если прогон не завершился, проблема в инсталляции.
Прочтите инструкции к установке и убедитесь, что
программа установлена правильно.
36
2 ОЦЕНКА СОЕДИНЕНИЙ INTERNET ДЛЯ
НЕБОЛЬШОЙ СЕТИ
Содержание лабораторной работы
Лабораторная работа описывает основы использования

OPNET IT Guru. Дружественный интерфейс Guru с
технологией «перетаскивания» дает возможность
эффективно моделировать, управлять, искать и устранять
неполадки в реальных сетевых структурах.
Исследование производительности приложений и
планируемой пропускной способности производится при
помощи изменения скорости соединения между домашней
ЛВС и ее ISP (провайдер услуг Интернет).
OPNET IT Guru предоставляет собой виртуальную
сетевую среду, которая моделирует поведение сетей,
включая маршрутизаторы, коммутаторы, протоколы и
конкретные приложения. Эта среда позволяет IT
менеджерам, проектировщикам сетей, систем и штату
операторов более эффективно решать трудные проблемы,
моделировать изменения прежде, чем они осуществляются,
и планировать будущие сценарии, такие как рост трафика и
выход из строя сегментов сети.
Можно проводить моделирование сценариев
(отдельных схем и планов действий) при проектировании
сетей. В процессе моделирования можно проследить, как
будут изменяться время запаздывания отклика и другие
сетевые характеристики при различных подходах к
конструированию сети.
Чтобы создать модель сети (называемую в IT Guru
проектом), необходимо определиться с узлами сети: с
компьютерами, коммутаторами, маршрутизаторами и т.д.),
соединениями между узлами и приложениями, которые
будут работать на том или ином узле.
Проект для данной лабораторной работы уже создан. По
сценарию это модель домашней сети, которая имеет три
ПК, подсоединенных к Интернет для игр, Web браузинга,
электронной почты, аудио-воспроизведения и т.д.
Целью лабораторной работы является проведение
37
серии имитационных экспериментов для того, чтобы
увидеть, насколько изменяются характеристики сети, если
используется: 1) медленный модем со скоростью загрузки
20 Кб/с; 2) быстрый модем со скоростью 40 Кб/с ; 3)
кабельный модем или DSL линия со скоростью 512 Кб/с ;
4) линия Т1 (обсуждаемая в п.2.7) со скоростью загрузки
1.544 Мб/с.
И хотя модемы, кабельные модемы и DSL соединения
часто рекламируются как более высокоскоростные,
полученные в данной работе цифры более реалистичны и
более похожи на то, что пользователи имеют на практике.
Для каждого сценария необходимо установить скорость
загрузки в имитационной модели, провести прогон модели
и проанализировать результат.
Программа OPNET Modeler состоит из проектов и

сценариев. Все сценарии представляют собой варианты
модели, созданные пользователями. Сценарии могут
содержать различные версии одной и той же сети или
модели различных сетей. Проект состоит из одного или
более сценариев. В данной лабораторной работе будет
создано 4 различных сценария для сравнения
производительности приложений с различными скоростями
соединения к ISP. Для этого необходимо:
2. выбрать пункт <File> <Open…> в выпадающем
списке (рисунок 2.1) и выбрать Project;
3. выбрать пункт <Home_ LAN> из списка и нажать
Оk.
38
Рисунок 2.1 – Выбор проекта.
На рисунке 2.2 показана модельная сеть. Каждый ПК

подсоединен к 100Мб/с Ethernet коммутатору через UTP
соединение. Коммутатор подсоединяется к маршрутизатору
также через UTP (витую пару). Кабельный модем не
показан, он подразумевается в звене соединения домашней
сети к Интернету. Три Интернет-сервера предоставляют
различные услуги для клиентских ПК.
Сверху на рисунке 2.2 показаны два элемента, которые
не являются физическими компонентами: приложения и
профили. Узел приложений содержит данные о
приложениях, используемых в сети, таких как веб-
браузинг. С каждым приложением будет связан свой
трафик, и разница между «Web приложением» и
«Приложением FTP» будет ощутимой. Внутренний трафик
(файл-сервер и сетевая печать) не показан. В профилях
различные приложения ассоциируются с различными ПК.
39
Рисунок 2.2 – Исходный проект.
Полная топология и атрибуты всех объектов заранее

сконфигурированы. Исключением является звено связи
между маршрутизатором и Интернет-провайдером (ISP).
2.3 Установка WAN cвязи на скорость 20 Кб/с
В первом сценарии необходимо настроить WAN связь

на скорость 20 Кб/с. Для этого нужно выполнить
следующие действия (рисунок 2.3):
1. нажать правой кнопкой мыши на WAN связи, затем
выбрать Edit Attributes;
2. щелкнуть справа от атрибута data rate и выбрать
Edit…;
3. ввести 20000, нажать Enter и затем Оk.
40
Рисунок 2.3– Настройка параметров связи
2.4 Настройка, запуск сценария и анализ результатов
Для моделирования сети используется высокоточный

расчет дискретных событий. Эта модель описывает клиент-
серверные приложения, которые воспроизводят реальный
сетевой трафик. Для запуска имитационного эксперимента
1. нажать на кнопку configure/run
simulation;
2. установить время моделирования Duration
на 8 часов;
3. нажать Run;
4. после завершения прогона нажать Close.
Производительность WAN связи

Для просмотра загрузки линии связи с Интернет
1. щелкнуть правой кнопкой мыши по WAN связи и
выбрать пункт View Results (рисунок 2.4);
2. раскрыть дерево «point-to-point» и выбрать пункт
utilization в обоих направлениях;
41
4. выбрать пункт Overlaid Statistics из меню в
нижнем правом углу (рисунок 2.5), чтобы
разместить результаты на одном графике;
Рисунок 2.4 – Результаты моделирования
5. выбрать пункт Show и нажать кнопку Close в окне

View Results.
Производительность компьютера PC2

1. Щелкнуть правой кнопкой мыши по окну PC2
Research и выбрать пункт View Results для
просмотра Web Response Time (время ответа веб-
сервера) и Traffic Received (принятый трафик).
2. Раскрыть Client Http и выбрать пункт <время
загрузки страницы> (Page Response Time (sec)).
3. Нажать Close в окне View Results.
4. Кнопка hide or show all graphs позволяет
спрятать/показать графики (рисунок 2.6).
42
Рисунок 2.5 – Размещение графиков на одной оси
координат
Рисунок 2.6 – Графики полученных результатов
43
Вывод. Из полученных результатов следует, что
среднее значение параметра download link Utilization
(загрузка линии на прием) составляет около 80%, а среднее
значение upload link Utilization (загрузка линии на
передачу) – около 2%. При такой загрузке линии, ширины
полосы пропускания не хватит для новых пользователей
или приложений. Значение Response Time (время отклика)
лежит в диапазоне от 5 до 7.5 секунд, что достаточно
велико. Эта медленная линия связи значительно
перегружена.
2.5 Сценарий соединения на 40 Кб/с
Установим новый быстрый модем для соединения со

скоростью 40 Кб/с. Это реальная пропускная способность
для модема 56Кб/с. Для этого необходимо:
1. выбрать пункт Scenarios > Duplicate Scenario… и
назвать сценарий 40K_dialup_connection;
2. нажать кнопку Оk и тогда в проект будет добавлена
копия существующего сценария;
3.нажать правую кнопку мыши на WAN link и изменить
атрибут data rate на 4000.
После этого нужно запустить прогон модели.
Статистические данные (utilization и Response Time)
можно посмотреть так же, как и в предыдущем сценарии.
Рисунок 2.7 - Графики полученных результатов

44
Вывод.
Параметр связи Utilization (загрузка) уменьшился в два
раза. Параметр Response Time (время ответа) сократился
от 6 секунд до 2.25 секунд. Таким образом, мы получили
значительное повышение производительности сети.
2.6 Сценарий соединения на скорость 512 Кб/с
В третьем сценарии моделируется загрузка со

скоростью 512 Кб/с. Это вполне реальная пропускная
способность при загрузке для кабельного модема или
линии DSL. Для этого необходимо:
1. создать копию сценария и назвать его
512K_Cable_Modem_connection;
2. установить атрибут data rate для WAN link в
512000;
3. запустить прогон модели;
4. ознакомиться с результатами моделирования - с
полученными характеристиками link utilization,
Response Time и Traffic Received. (рисунок 2.8)
Рисунок 2.8 - Графики полученных результатов
45
Вывод.
Параметр загрузки Utilization снизился до 4%, а –
время отклика Response Time уменьшилось до 0.15
секунды. Кабельный модем намного улучшает загрузку и
время отклика данной сети.
2.7 Сценарий связи по выделенному соединению Т1

Интернет – провайдер ISP может предоставлять
выделенное соединение Т1 со скоростью до 1.544 Мб/с в
обоих направлениях. Это и есть реальная пропускная
способность такой линии. Единственной проблемой
является то, что Т1 линия стоит очень дорого. Телефонной
компании нужно протянуть две пары специальных кабелей
для передачи данных и осторожно управлять Т1 линией.
Скорость передачи и доступность линии гарантирована.
Этот сценарий будет содержать преимущества
использования Т1 для связи с ISP. Для моделирования
1. создать копию сценария и назвать его T1_connection;
2. изменить атрибут data rate WAN link на Т1 из
общего меню;
3. запустить прогон модели.
Сравнение результатов
Сравнение результатов Utilization и Response Time для
всех четырех сценариев дает более ясное представление о
результатах смены пропускной способности. Для того,
чтобы сравнить результаты, необходимо:
1. выбрать пункт Results > Compare Results…;
2. выбрать статистику utilization;
3. выбрать пункт All Scenarios (рисунок 2.9);
4. изменить фильтр в правом нижнем углу с As Is на
average, а затем выбрать необходимую статистику и
нажать кнопку Show, и чтобы сравнить
характеристику Response Time необходимо снять
галку с пункта utilization, (рисунок 2.10).
46
Рисунок 2.9 – Сравнение результатов моделирования
Рисунок 2.10 – Сравнение времени ответа
47
2.8 Выводы по лабораторной работе
1. Лабораторная работа посвящена основам

использования OPNET IT Guru. Исследование
производительности приложений и планируемой
пропускной способности производилось при помощи
изменения скорости соединения между домашней ЛВС и ее
ISP (провайдер услуг Интернет).
2. Проведена серия имитационных экспериментов,
позволяющая увидеть, насколько изменяется
производительность сети, если используются каналы от
медленных (модем со скоростью 20 Кб/с; модем со
скоростью 40 Кб/с) до высокоскоростных (кабельный
модем или DSL линия со скоростью 512 Кб/с и линия Т1 со
скоростью 1.544 Мб/с).
3. Для каждого сценария установлена скорость
загрузки в имитационной модели, произведен прогон
модели и проанализирован результат, показывающий, что
чем выше скорость подключения, тем соответственно выше
скорость закачки и меньше время отклика приложений.
4. Однако такие характеристики, как время отклика
Response Time и загрузка Utilization изменяются
незначительно при переходе линии от 512К к Т1. Для
текущего числа пользователей соединение Т1 не дает
значительных преимуществ. Улучшение связи, при
переходе к линии Т1, не является экономически
оправданным для получения тех преимуществ в
пропускной способности, которые оно дает.
2.9 Задания на самостоятельную работу
Сценарий 1. Собирается множество статистик, таких,

как пропускная способность и задержка в очереди на WAN
связи . Анализ результатов для четырех сценариев
послужит основой для выводов по лабораторной работе.
Сценарий 2. Создается дубликат сценария. Изменяется
пропускная способность связи между маршрутизатором и
ISP для подбора среднего времени отклика в 1 секунду.
Сценарий 3. Имеется продолжительный по времени
48
поток данных между музыкальным сервером и PC1,
определяемый объектом трафика по требованию (traffic
demand). Можно просмотреть этот объект, выбрав пункты
View > Demand Object > Show All. Изменить объем
трафика для этого объекта. Как это изменение повлияет на
время отклика?
Сценарий 4. Что случится, если в сеть добавить 2 ПК?
Необходимо скопировать Reseacher PC и вставить два раза.
Подсоединить эти два ПК к коммутатору путем
копирования и вставки связей, соединяющих Reseacher PC
и коммутатор. Запустить имитацию и оценить время
отклика каждого из этих ПК для всех значений data rate.
Сценарий 5. Необходимо добавить приложения на
Reseacher PC и проверить время отклика. Чтобы добавить
приложения на клиент, нужно отредактировать объект
Profile и отредактировать Profile Configuration.
49
3 ПРОЕКТИРОВАНИЕ И МОДЕЛИРОВАНИЕ ЛВС
МНОГОЭТАЖНОГО ЗДАНИЯ
3.1 Содержание лабораторной работы
Цель лабораторной работы заключается в оценке

производительности приложений для двух различных
сетевых архитектур: последовательной сети и жесткой
магистральной сети.
В данной лабораторной работе рассматриваются сети
данных с магистральной архитектурой, в которой имеется
центральный коммутатор в монтажной комнате для
оборудования. Центральный коммутатор подсоединяется
непосредственно к коммутатору рабочей группы на каждом
этаже. Альтернатива состоит в том, что центральный
коммутатор подсоединен к коммутатору первого этажа,
коммутатор первого этажа – к коммутатору второго этажа и
т.д. В лабораторной работе оценивается время задержки,
вводимое подсоединением дополнительных коммутаторов.
Здание банка имеет 10 этажей, на каждом из которых
множество пользователей, подсоединенных к коммутатору
рабочей группы типа 10Base-T. Коммутатор расположен в
специальном помещении для телекоммуникаций.
Пользователи обращаются к серверу Oracle и семи файл- и
принт-серверам.
В сценарии 1 коммутаторы на каждом этаже
последовательно подсоединены к центральному
коммутатору в подвале. Этот подход приведет к большему
времени задержки для пользователей самого верхнего
этажа.
В сценарии 2 топология последовательной цепи
сохраняется, но центральный коммутатор перемещается из
подвала на пятый этаж. Это уменьшит время задержки на
самом верхнем этаже, но увеличит его на самом нижнем.
В сценарии 3 центральный коммутатор находится в
подвале, но применяется топология жесткой магистральной
архитектуры, в которой центральный коммутатор
подсоединяется напрямую к коммутаторам рабочих групп
на каждом этаже.
50
Для начала работы необходимо загрузить файл с

лабораторной работой.
1. Запустить IT Guru.
2. Выбрать пункт меню File > Open…
3. Выбрать проект Multistory_Building_LAN и нажать
Оk.
Рисунок 3.1 – Выбор проекта
Пользователи подсоединены к коммутатору на каждом

из 10 этажей. Они используют сервер Oracle и 7 File, Print
и Email серверы в подвале.
Подсеть (Subnet): Подсеть – это контейнер,
используемый для создания иерархии уровней сети. Для
того, чтобы войти в подсеть, необходимо щелкнуть дважды
по имени подсети 7 File Print & Email Servers. Здесь
серверы сгруппированы вместе. Чтобы перейти к подсети
более высокого уровня, необходимо нажать правой
кнопкой мыши и выбрать Go To Parent Subnet.
51
Рисунок 3.2 – Внешний вид проекта
Значки ЛВС представляют также несколько рабочих

станций, соединенных в коммутированную ЛВС. Число
рабочих станций может быть установлено путем
редактирования атрибутов сети. Пользователи различных
этажей выполняют по 2 приложения Oracle.
52
Рисунок 3.3 – Параметры объекта «сегмент сети»
3.3 Моделирование сети
Предположим, что нам необходимо оценить

характеристики сети за один рабочий час. Для этого нужно
1. нажать на инструментальную кнопку configure/run
simulation;
2. установить длительность прогона Duration на 1 час;
4. после завершения прогона нажать Close.
Просмотр времени отклика приложения Oracle для

пользователей на этажах 1, 5 и 10 выполняется следующим
образом:
1. нажать правой кнопкой мыши на объекте <95 Users
Floor 10> и выберите View Results;
2. развернуть Requesting Client Custom Application и
выбрать Application Response Time (sec.) и Show;
3. нажать Close в окне View Results;
53
4. нажать правой кнопкой мыши на объекте «50 Users
Floor 10» и выбрать View Results;
5. выбрать пункт Requesting Client Custom
Application > Application Response Time (sec.);
6. нажать Add и на графическую панель первого
графика (это делается для отображения статистики для
пользователей на различных этажах на одной и той же
панели);
7. повторить шаги с 5 по 7 для того, чтобы добавить к
графику время отклика приложения для пользователей на
этаже 1.
Рисунок 3.4 – Результаты моделирования
Замечание. Чтобы включать и отключать графики,

можно пользоваться кнопкой hide and show all graphs.
Теперь имеются статистики для пользователей на всех
54
этажах на одном и том же графике.
Рисунок 3.5 – Сравнительные результаты
Анализ полученных результатов

Время отклика (Response Time)_ приложения близко к
6 секундам для пользователей на 10-м этаже. Оно
уменьшается по мере продвижения к нижним этажам.
Пользователи на 1-м этаже имеют наименьшее время
отклика. Это и есть величина задержки, вносимой
коммутаторами.
Пользователи с самого верхнего этажа имеют высокие
значения времени отклика приложения. Поэтому компания
решила снизить это время путем перемещения
центрального коммутатора и серверов на пятый этаж. Для
этого необходимо выбрать Scenarios>Switch To
Scenario>Daisy_Chain_Network_Server_On_Fifth_Floor.
Компания реструктурирует сеть без дополнительных
аппаратных средств для достижения лучшей
производительности приложений для пользователей на
верхних этажах.
55
Запустите заново прогон модели одного рабочего часа,
чтобы увидеть, получили ли пользователи на 10-м этаже
лучшее время отклика.
Теперь сравним время отклика приложения для
пользователей на разных этажах. Ожидается, что
реструктурирование сети должно уменьшить время отклика
для пользователей на верхних этажах. Для сравнения
1. нажать правой кнопкой мыши на <95 Users Floor 10>
и выбрать Compare Results;
2. выбрать <Requesting Clients Custom Application >
Application Response Time (sec.) ;
3. нажать Show и затем нажать Close в окне View
Results;
4. повторить шаги для «50 Users Floor 5» и «70 Users
Floor1».
Рисунок 3.6 – Сравнение результатов
56
Рисунок 3.7 – Полученные результаты
Как и ожидалось, время отклика приложения Oracle

понижается для пользователей на этажах 5 и 10. Но
пользователи на 1-м этаже будут наблюдать увеличение
времени отклика.
Компания решает изменить архитектуру с
последовательной цепи к сети с жесткой магистральной
архитектурой в надежде поддержки приложений для всех
пользователей. Для моделирования этого сценария
необходимо выбрать Scenario > Switch To Scenario >
Collapsed_Backbone-Network.
57
Рисунок 3.9 – Сеть с магистральной архитектурой
Затем необходимо запустить прогон сценария, чтобы

оценить работу сети. Для этого необходимо сравнить
времена отклика для всех 3-х сценариев. Это поможет
выявить наилучшую архитектуру для данного типа сети.
58
1. Лабораторная работа посвящена оценке

производительности приложений двух различных сетевых
архитектур: «последовательная сеть» и «жесткая
магистральная сеть». Показано, как можно изменить
производительность сети и время отклика приложений в
зависимости от архитектуры самой сети.
2. Рассмотрены сети данных с магистральной
59
архитектурой, в которой имеется центральный
коммутатор в монтажной комнате для оборудования.
Время задержки, вводимое подсоединением
дополнительных коммутаторов, в сценарии 1
(коммутаторы на каждом этаже последовательно
подсоединены к центральному коммутатору в подвале)
для пользователей самого верхнего этажа увеличивается.
Время отклика приложения близко к 6 секундам для
пользователей на 10-м этаже и уменьшается по мере
продвижения к нижним этажам (около 5 секунд на пятом
этаже и менее 4-х секунд на первом этаже). Пользователи
на 1-м этаже имеют наименьшее время отклика. Это и
есть величина задержки, вносимой коммутаторами.
3. В сценарии 2 топология последовательной цепи
сохранена, но центральный коммутатор перемещен из
подвала на пятый этаж. Это уменьшило время задержки на
самом верхнем этаже, но увеличило его на самом нижнем,
а именно на 10 этаже порядка 5 секунд, на пятом этаже
около 4-х секунд и менее 5 секунд на первом этаже.
4. В сценарии 3 центральный коммутатор находится в
подвале, но применена топология жесткой магистральной
архитектуры, в которой центральный коммутатор
подсоединяется напрямую к коммутаторам рабочих групп
на каждом этаже. Полученные результаты таковы: на 10
этаже задержка менее 4-х секунд, на 5 этаже порядка 3,5
секунд и на первом этаже порядка 3,5 секунд.
60
4 ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ WAN
ПРИЛОЖЕНИЯ
В лабораторной работе описывается небольшая ЛВС с

20 пользователями для начинающей компании Deltasoft
Technologies. Исследуется производительность приложений
с линией Т1. Также планируется изменить сеть путем
добавления резервной линии связи между ЛВС и ISP
(провайдером).
ЛВС Deltasoft Technologies состоит из 20
пользовательских ПК, которые совместно используют три
принтера, локальный файловый сервер и E-mail серверы.
Пользователи запускают различные приложения, такие как
E-mail, Web браузер, видео, аудио и FTP. Кроме этого
используются локально обслуживаемые приложения, такие
как внутри сетевая E-mail служба, печать и доступ к базам
данных.
Цель лабораторной работы состоит в расчете и
сравнении времени отклика для двух критичных задач:
загрузки по FTP и загрузки Web страницы. Также будет
анализироваться использование линии связи между ЛВС и
ISP.
После первоначальной установки необходимо разделить
ЛВС на два сегмента, соединенных друг с другом и
добавить дополнительную Т1 линию связи между ЛВС и
ISP, чтобы удвоить пропускную способность. Балансировка
нагрузки будет способствовать тому, что обе Т1 связи
будут использоваться равномерно. Затем одно из устройств
по сценарию выходит из строя и производится анализ,
какие же преимущества обеспечит резервная связь.
Для запуска лабораторной работы необходимо:

1. запустить программу IT Guru;
2. выбрать пункт File > Open…;
61
3. выбрать проект Small_Company_LAN
_over_WAN и нажать Оk.
Тем самым мы получили сеть, показанную на рисунке
4.1.
Компания также имеет совместные локальные E-mail и
файл-серверы. Для примера, добавьте сервер из меню
Object Palette и сконфигурируйте его для E-mail и File
Sharing приложений. Это продемонстрирует развертывание
объектов, что важно для модификации моделей сети.
Рисунок 4.1 – Первоначальная сеть
Добавление локального сервера

Для добавления сервера необходимо открыть меню
<база ресурсов> (Object Palette). В ней представлены
компоненты сети. Из верхнего меню необходимо выбрать
группу компонентов, разбитых по протоколам и по
производителям (рисунок 4.2).
62
Рисунок 4.2 – База ресурсов
Далее нужно выбрать меню Ethernet и ethernet-server

и щелкнуть левой кнопкой мыши по рабочей области,
чтобы добавить сервер. Чтобы прекратить добавление
серверов, необходимо нажать правой кнопкой мыши. После
этого добавить связь между сервером и коммутатором, для
чего выбрать из базы ресурсов объект 10BaseT. Затем
нажать на 10BT_Switch, на сервер и закрыть базу
ресурсов.
Настройка локального сервера электронной почты и

файл-сервера
Эти приложения уже определены в объекте
<приложения> (Application Object). Для настройки
щелкнуть правой кнопкой мыши по серверу и выбрать
<параметры> (Edit Attributes).
Установить имя атрибута в <Email & File Server>.
В колонке <значение> (Value) нажать Application:
Supported Services и вместо None выбрать Edit…(рисунок
4.3).
63
Рисунок 4.3 – Настройка приложений
Дальше необходимо настроить приложения. Для этого

установить число строк (Rows) - 2 и в колонке <название>
(Name) нажать на первый ряд и выбрать E-mail (Heavy),
затем нажать на второй ряд и выбрать Database.
Рисунок 4.4 – Выбор приложений
После этого дважды нажать Оk, а для сохранения
64
проекта - File > Save. Так мы получили результирующую
сеть (рисунок 4.5).
Рисунок 4.5 – Результирующая сеть
4.3 Оценка производительности сети
Теперь, когда локальный сервер настроен, необходимо

оценить производительность сети за один рабочий час. Для
этого необходимо:
1. нажать на кнопку <configure/run simulation>;

2. установить продолжительность <Duration> на 1 час;
4. когда прогон закончится, нажать Close.
Далее необходимо оценить такие статистики, как время
отклика веб-приложения, время отклика загрузки файлов
по FTP и загрузки WAN связи. Для такой оценки нужно
выполнить следующую последовательность действий:
1. нажать правой кнопкой мыши по WAN связи и
выбрать <View Results>;
65
2. раскрыть ветвь <point-to-point> и выбрать
<utilization>;
3. выбрать <Show Preview >;
4. нажать Close в окне <View Results>;
5. щелкнуть правой кнопкой мыши на рабочей области
и выбрать меню <View Results>;
6. выбрать пункт <глобальная статистика> (Global
Statistics) <HTTP> <время загрузки страницы>
(Page Response Time) (sec.);
7. нажать Show.
Рисунок 4.6 – Загрузка линии
С теми же выбранными статистиками (время отклика

НТТР) изменить фильтр в правом нижнем углу на
<average> и нажать кнопку Add.
Нажимая на график, который только что был создан,
помещаем усредненную кривую на той же панели.
66
Повторим процедуру для просмотра времени отклика при
загрузке по FTP (Ftp Download Response Time) (sec.). При
этом необходимо закрыть предыдущие статистики перед
выбором новой статистики.
Замечание. Для того, чтобы убрать или вернуть
графики, необходимо использовать кнопку <hide or show
all graphs> .
Рисунок 4.7 – Статистические данные
67
Анализируя полученные статистические данные по
рисункам 4.7, можно сделать следующие выводы:
- использование связи достигает 92% ;
- время отклика веб-приложения близко к 1.3 сек;
- время отклика загрузки FTP близко к 2.5 сек;
- при таком использовании канала связи остается совсем
небольшой процент доступной полосы пропускания для
приложений пользователей.
Теперь проведем еще два эксперимента. Во-первых,
добавим резервную связь Т1, чтобы удвоить пропускную
способность. Будет использоваться балансировка нагрузки
для равномерного распределения трафика между двумя
линиями связи. Затем одно из устройств будет
преднамеренно выведено из строя, чтобы
продемонстрировать преимущество добавления новой
связи.
Для постановки нового сценария необходимо выбрать
пункт меню <Scenarios> <SwitchToScenario>
<Small_Company_LAN_With_Two_Switches_Over_WAN>.
Рисунок 4.8 – Новый сценарий
68
Сеть компании разделена на два сегмента (рисунок 4.8),
каждый из которых подсоединен к коммутатору. ЛВС
подсоединена к Интернету с помощью двух Т1 линий. Для
балансировки нагрузки на двух линиях используется
EIGRP.
Затем необходимо запустить прогон, чтобы убедиться,
что нагрузка сбалансирована на двух линиях связи.
4.4 Сравнительный анализ результатов
Проведем сравнительный анализ использования связей,

времени отклика Web приложения и загрузки FTP. Мы
ожидаем, что добавление дополнительной связи к ISP
(провайдеру) должно уменьшить время отклика
приложения. Для сравнительного анализа необходимо
выполнить следующую последовательность действий:
- щелкнуть правой кнопкой мыши по нижней WAN
связи и выбрать пункт <сравнить результаты>
(Compare Results);
- раскрыть ветвь <point-to-point> в ветви
<Company_LAN.WAN LINK 1[0]> и выбрать
<utilization>, затем нажать кнопку Show, а в окне
View Results нажать Close;
- щелкнув правой кнопкой мыши на верхней WAN связи
выбрать <просмотр результатов> (View Results);
- раскрыв ветвь <point-to-point> выбрать <utilization>
и в окне <View Results> нажать кнопку Close
Сравним времена отклика. Для этого щелкнуть правой

кнопкой мыши и выбрать пункт <сравнить результаты>
(Compare Results).
Выбрать пункт <глобальная статистика> (Global
Statistics) Ftp <время отклика при загрузке>
(Download Response Time) (sec.).
Далее в правом нижнем углу из меню выбрать
<average> и нажать <Show>.
Повторить эти шаги также для статистики <время
отклика страницы> (Page Response Time) (sec.). Для
69
этого необходимо удалить предыдущие статистики до того,
как будет выбрана новая.
Рисунок 4.9 – Загрузка WAN линий
Рисунок 4.10 – Сравнение статистики «загрузка»
70
Рисунок 4.11 – Сравнение времен отклика
В результате сравнительного анализа можно сделать

следующие выводы:
1. как и ожидалось, использование канала связи
снизилось с 92% до 55%, а использование нового канала
связи близко к 40%, т.е. балансировка нагрузки работает
отлично;
2. время отклика Web приложения снизилось от 1.1 сек.
до 0.45 сек;
3. время отклика загрузки по FTP снизилось от 1.25 сек.
до 0.6 сек;
4. полученные результаты показывают значительное
улучшение условий использования канала связи и
Преимущество использования дополнительной Т1
линии можно увидеть при выходе из строя одного из
маршрутизаторов или одной из связей. Для этого
необходимо вывести из строя один маршрутизатор и
сравнить использование канала связи и время отклика
приложения. Для дублирования сценария выбираем
Scenarios > Duplicate Scenario… и введем имя сценария
Small_Company_LAN_Failed_One_Router_Over_WAN, а
затем нажимаем <Оk>. Так будет выведен из строя один из
маршрутизаторов, соединяющих ЛВС и ISP.
71
Для этого необходимо щелкнуть правой кнопкой мыши
по одному из маршрутизаторов и выбрать <вывести из
строя узел> (Fail This Node). На этом маршрутизаторе
появится красный знак «Х», что и проиллюстрировано на
рисунке 4.12. Затем необходимо запустить прогон.
Рисунок 4.12 – Вывод из строя маршрутизатора
4.5 Сравнительный анализ производительности

сети для всех сценариев
Теперь сравним производительность каналов связи и

времен отклика для всех трех сценариев. Для этого
1. выбрать Results > Compare Results…;
2. для того, чтобы сравнить статистики загрузки канала
связи, необходимо выбрать пункт <статистика
объекта> (Object Statistics) > Company_LAN > WAN
LINK 1[0] > <загрузка> (utilization);
3. нажать кнопку Show.
72
Рисунок 4.13 – Сравнение статистик для первой связи
Для того, чтобы сравнить загрузку канала для верхней

Т1 связи, необходимо удалить предыдущие статистики и
выбрать <статистика объекта> (Object Statistics)
Company_LAN> WAN LINK 2[0] <загрузка>
(utilization) и нажать кнопку Show (рисунок 4.14).
Для сравнения времен отклика, необходимо выбрать

пункт <глобальная статистика> (Global Statistics) Ftp>
<время отклика при загрузке> (Download Response
Time) (sec.) и -значение аverage из меню в нижнем правом
углу. Затем нужно нажать кнопку Show и получить
рисунок 4.15.
73
Рисунок 4.14 – Сравнение статистик для второй связи
Рисунок 4.15 – Сравнение времени отклика при загрузке
74
Для сравнения характеристики <время загрузки
страницы HTTP> (HTTP Page Response Time) нужно
повторить ту же процедуру. На рисунке 4.16 приведено
сравнение времени отклика при веб-серфинге.
Рисунок 4.16 - Сравнение времени отклика при веб-

серфинге
75
Рисунок 4.17 – Результирующие графики
1. Время отклика для двух критичных задач (загрузка

по FTP и загрузка Web страницы) в данной лабораторной
работе является основным критерием. В результате
загрузка линии связи достигает, в среднем до 92%. Время
отклика Web приложения близко к 1.3 сек. Время отклика
загрузки FTP близко к 2.5 сек. Полученная загрузка линии
связи говорит о том, что остается мало доступной полосы
пропускания для приложений пользователей
2.Полученные результаты показывают, что
дополнительная связь Т1 дает значительное улучшение
условий исполнении связи и времени отклика приложения.
После добавления второй (резервной) линии связи,
76
загрузка линии связи снизилась с 92% до 55%, а загрузка
новой линии связи близка к 40%. Время отклика Web
приложения снизилось от 1.1 сек. до 0.45 сек. Время
отклика загрузки FTP снизилось от 1.25 сек. до 0.6 сек. Это
говорит о значительном улучшении использования как
самой линии связи, так и уменьшении времени отклика
приложений.
3. Кроме того, если один из маршрутизаторов выходит
из строя, все пользователи все же могут получить доступ к
Интернету за счет более полного исполнения связи и
лучшего времени отклика.
Сценарий 1. Необходимо создать копию сценария

Small_Company_LAN_With_One_Switch_Over_WAN и
изменить скорость передачи данных WAN связи для
получения среднего времени отклика веб-серфинга 0.5 с.
Затем продублировать сценарий
Small_Company_LAN_With_Two_Switches_Over_WAN и
установить скорость WAN связей в T1. После этого
необходимо оценить время отклика при веб-серфинге.
Сценарий 2. Имеется продолжительный поток данных
между музыкальным сервером и несколькими
пользователями, определенный объектом <возникающий
трафик> (Traffic Demand). Можно просмотреть этот
объект, выбрав View > Demand Objects > Show All. Для
редактирования параметров трафика нужно изменить поля
Traffic (packets/sec) и Traffic (bits/sec) объекта
<возникающий трафик> (Traffic Demand).
Сценарий 3. Необходимо скопировать последний
сценарий (не дополнительный). Затем нужно восстановить
работоспособность выведенного из строя маршрутизатора и
вывести из строя одну из WAN связей. Изменятся ли
результаты?
77
5 ВЛИЯНИЕ СКОРОСТИ КАНАЛА PVC FRAME
RELAY НА ПРОИЗВОДИТЕЛЬНОСТЬ ПРИЛОЖЕНИЙ
Лабораторная работа посвящена исследованию

производительности приложений WAN. Исследуется
влияние изменения скорости канала PVC Frame Relay на
производительность приложения.
Банк Standard Chartered имеет 70 филиалов,
административное здание и центр обработки в городе
Ричмонд. Чтобы соединить все филиалы, у банка имеется
трехуровневая сеть. Отдельные филиалы подсоединены к
региональным маршрутизаторам. Региональные
маршрутизаторы подсоединены к системе Frame Relay
Verizon. Эта система имеет внутреннюю жесткую
вертикальную архитектуру АТМ.
Одним из результатов использования такой
архитектуры является то, что каждому филиалу не нужно
иметь отдельный канал PVC от Центра обработки. Во-
первых, между региональными маршрутизаторами и ядром
ATM имеется только соединение PVC. Во-вторых,
использование в цепи ядра АТМ означает, что Центру
обработки нужен единственный канал PVC к ядру АТМ.
Эта схема отличается от чистой сети Frame Relay, которая
требует отдельных каналов PVC от Центра обработки к
каждому филиалу или, по крайней мере, к каждому
региональному маршрутизатору.
Изначально PVC маршрутизаторы филиалов имеют
скорость передачи информации (CIR) 64 Кб/с и могут
пересылать пакеты данных со скоростью до 128 Кб/с.
Соединения между региональными маршрутизаторами и
системой Frame Relay работают со скоростью 256 Кб/с.
Соединение Frame Relay между Центром обработки и
Frame Relay работают со скоростью Т1 (CIR 1 Мб/с).
Цель лабораторной работы - изучение изменения
времени отклика для приложений передачи файлов при
различных соединениях Frame Relay между банком и сетью
Verizon.
78
Для начала работы необходимо:

2. выбрать пункт File > Open…;
3. выбрать проект с именем
Standard_Charetered_Bank_Network и нажать Оk.
Проект указанной сети показан на рисунке 5.1.
Рисунок 5.1 – Сеть Frame Relay
Канал PVC, соединяющий все филиалы к Frame Relay

работают с CIR 64 Кб/с. Провайдер предоставил по
контракту связь 128 Кб/с, но Verizon имеет соединение в
256 Кб/с от региональных маршрутизаторов к Frame Relay
для будущего расширения сети филиалов банка. Канал PVC
от Центра обработки к Frame Relay имеет CIR 1 Мб/с.
Чтобы посмотреть эту конфигурацию, необходимо дважды
кликнуть по любой из подсетей. Затем щелкнуть правой
кнопкой мыши по связи, исходящей из маршрутизатора и
выбрать окно Edit Attributes. Если связь не видна, нужно
выбрать пункт View > Demand Objects > Show All. В окне
Attributes дважды кликнуть по колонке Value для
параметра Contract Parameters. Параметры Frame Relay
79
PVC, установленные между компанией и сетью Verizon,
должны быть сконфигурированы здесь. Чтобы вернуться в
подсеть, необходимо дважды нажать на Cancel.
Оценка производительности приложений за один

час рабочего дня
1. Нажать на кнопку configure/run simulation.
2. Установить Duration на 1 час.
3. Нажать Run.
4. Когда прогон закончится, нажать Close.
После этого выполнить следующие действия:
1. щелкнуть правой кнопкой мыши и выбрать View
Results (рисунок 5.2);
2. выбрать пункт Global Statistics > DB > Response
Time (sec.);
3. нажать кнопку Show;
5. выключить предыдущие статистики;
6. затем выбрать пункт меню Global Statistics > Ftp >
Download Response Time (sec.);
7. нажать Show.
Полученные результаты на рисунках 5.2 и 5.3

показывают, что среднее время отклика совместного
использования файлов составляет примерно 20 секунд, т.е.
время отклика загрузки файлов достаточно высоко. Таким
образом, изменения латентности и загруженности сети
влияют на время отклика.
Чтобы улучшить производительность приложения,
компания решила улучшить параметры связи, а именно на
канале PVC, соединяющим региональные маршрутизаторы
и Frame Relay, установить CIR в 128 Кб/с.
80
Рисунок 5.2 – Время отклика приложения
Замечание. Для того, чтобы подключать и отключать

графики, можно воспользоваться кнопкой hide and show all
graphs.
Рисунок 5.3 – Статистики канала
81
5.3 Изменение параметров связей сети
Анализ последствий изменений

1. Выбрать меню Scenarios > Duplicate Scenario…
2. Установить имя PVCs_With_CIR_128k и нажать Оk.
Затем необходимо настроить PVC, подсоединяющие
филиалы и Frame Relay со значением CIR в 128 Кб/с. Для
этого необходимо выполнить ниже перечисленные
действия.
1. Кликнуть дважды по подсети Phoenix, чтобы войти в
подсеть.
2. Щелкнуть правой кнопкой мыши на пунктирном
соединении, исходящем из маршрутизатора Phoenix,
который представляет собой канал PVC, и выбрать View
> Demand Objects > Show All.
3. Щелкнуть правой кнопкой мыши там же и выбрать
Edit Attributes.
4. Нажать на в колонке Value атрибута Contract
Parameters и выбрать пункт Edit…
5. Установить Outgoing CIR 128000 и Outgoing Bc и Be
на 64000.
Рисунок 5.4 – Установка параметров PVC
4. Установить галку Apply Changes to Selected
Objects и нажать Оk.
Замечание: параметры PVC изменились также и в
82
Центре обработки. Поэтому необходимо установить их
снова на CIR в 1Мб/с.
5. Нажать правой кнопкой мыши на рабочей области и
выбрать Go to Parent Subnet.
6. Кликнуть дважды мышью по подсети Richmond-
Processing Center.
7. Нажать правой кнопкой мыши на канал PVC,
исходящий из маршрутизатора Центра обработки и
выбрать Edit Attributes.
8. Кликнуть дважды в колонке Value для Contract
Parameters.
9. Установить Outgoing CIR на 1024000, Outgoing Bc
на 25000 и Outgoing Be на 256000.
10. Нажать Оk, чтобы закрыть это окно, и затем
закрыть также окно атрибутов.
Теперь каналы PVC перенастроены (рисунок 5.4).
Необходимо запустить прогон заново, чтобы эффект от
обновления связи сказался на производительности
приложения.
После этого необходимо сравнить времена откликов
совместного использования файлов и загрузки файлов.
Ожидается, что дополнительная полоса пропускания с
новыми каналами PVC должна уменьшить времена
откликов.
Оценка производительности приложения

1 Нажать правой кнопкой мыши на рабочей области и
выбрать объект Compare results (рисунок 5.5).
2 Выбрать пункт Global Statistics > DB > Response
Time (sec.).
3 Нажать кнопку Show.
4 Удалить предыдущие статистики и повторить те же
шаги для пункта Ftp Download Response Time
(sec.)(рисунок 5.6) .
5 Нажать Close в окне View Results.
83
84
1.В данной работе исследовались сети Frame Relay и

выполнение приложений по глобальным сетям передачи
данных. А именно, как изменение скорости ретрансляции
кадров воздействует на работу приложения.
Анализировалось изменение времени отклика для
распределения и передачи файлов приложения при
различных скоростях обмена между банком и системой
ретрансляции кадров. Результаты моделирования показали,
что при скорости CIR 64 Kб/с. время отклика приложений
передачи файлов составляет примерно 20 секунд. Время
отклика при загрузке по FTP – различно для разных
пользователей, но в целом велико и составляет от 10 до 50
секунд.
2. С помощью сети Verizon обычно устанавливаются
соединения между филиалами и Frame Relay. Поэтому
компания не в состоянии изменить их. Таким образом,
изменение параметров каналов PVC было бы реальным
решением для компании. Как это было показано во втором
сценарии, такой путь решения проблемы улучшает
производительность приложения.
3. Для улучшения выполнение приложения повысили
контрактные параметры с тем, чтобы канал PVC,
соединяющий региональные маршрутизаторы и систему
ретрансляции, имел скорость CIR в 128 Кб/с. В результате
– время отклика при передаче файлов сократилось до 5-10
секунд. Время отклика при загрузке по FTP – сократилось
до 2-х секунд.
4. Дополнительная ширина полосы пропускания с
новыми PVC уменьшает время отклика приложений, что
подтверждается результатами проведенных исследований.
85
6 ИССЛЕДОВАНИЕ ВЛИЯНИЯ РАЗМЕРА ОКНА ТСР НА
ВЫПОЛНЕНИЕ ПРИЛОЖЕНИЯ
Лабораторная работа посвящена использованию такого важного

параметра ТСР, как размер окна ТСР, который содержится в поле
windows size сегмента ТСР. Предположим, что узел А передает
один TCP сегмент узлу В. Величина поля window size сообщает
узлу В дополнительное количество сегментов данных, которое он
может передать до получения сегмента-подтверждения о доставке
(ACK) ТСР. Узлу А придется ждать после каждого переданного
сегмента ТСР ответа от узла В перед посылкой следующего
сегмента. Необходимость ожидания значительно ухудшает
пропускную способность. С другой стороны, если величина поля
window size слишком большая, узел В сможет передать столько
сегментов, что узел А окажется перегруженным. Поле window size
производит текущий контроль и регулирует скорость обмена между
двумя узлами.
Цель данной лабораторной работы заключается в оценке
влияния размера окна TCP на производительность банковского
Банк Standard Chartered имеет филиал в Сиднее. Оттуда
ежедневно передаются счета и информация о транзакциях
размером в 25 Мб в центр резервного хранилища данных в
Вашингтоне.
Филиал и центр резервного хранилища данных соединены
сетью Frame Relay с временем задержки 5 мс. Время для передачи
файла в 25 Мб через связь Т1 оценивается приблизительно в 130 с.
Для передачи файла требуется очень большое время, поэтому IT
команда решила усовершенствовать связь с Frame Relay путем
перехода к связи Т3, предполагая, что задержка вызвана
недостаточной шириной полосы пропускания. Такое расширение
полосы пропускания не дало желаемых результатов. Тогда
компания решает вернуться к связи Т1 и увеличить размер окна
ТСР с изначальных 8К до 65К. Поскольку расширение WAN связи
дорого, то оптимизация таких параметров, как размер окна TCP
является предпочтительней.
86
Для начала работы необходимо:

1. запустить программу IT Guru;
2. выбрать окно File > Open…;
3. выбрать проект с именем TCP_Windows_Size и нажать Оk.
После этого получим исходный проект (рисунок 6.1).
Рисунок 6.1 – Исходный проект
В исходном проекте уже имеется один из центров банка Standard

Chartered в Вашингтоне, соединенный с одним из филиалов в
Сиднее через сеть Frame Relay.
Теоретически, передача файла 25Мб через связь Т1 не должна
занять более 130 с. Необходимо запустить прогон на час
модельного времени и узнать реальное время передачи файла. Для
этого необходимо выполнить последовательность действий.
1. Щелкнуть по инструментальной кнопке configure/run
simulation .
87
2.Убедиться, что продолжительность имитации Duration
установлена на 1 час.
4. Когда имитация закончится, нажать Close.
Теперь необходимо оценить реальное время отклика для
пересылки файла. Для этого нужно выполнить следующие
действия:
- выбрать окно Results > View Results…;
- выбрать пункт Global Statistics > Ftp > Upload
Response Time (sec.) и нажать кнопку Show.
Как видно из графика на рисунке 6.2, реальное время
отклика близко к 550 с. Это намного больше, чем его
теоретическая оценка и поэтому IT команда сразу же
предположила, что линии Т1 не хватает для пересылки
такого большого файла.
Рисунок 6.2 – Время отклика при загрузке по FTP
Таким образом, планируется изменить связь между

маршрутизаторами и каналом Frame Relay от Т1 к Т3, а
для этого нужно выполнить следующие действия:
- нажать на кнопку hide or show all graphs, чтобы
спрятать график;
- закрыть окно View Results.
Теперь необходимо изменить связь. Для этого
88
- выбрать окно Scenarios > Duplicate Scenario…;
-назвать сценарий Window_Size_8K_WAN_Link_T3.
Изменение связи от маршрутизаторов к Frame Relay
на Т3
1. Щелкнуть правой кнопкой мыши по связи,
соединяющей Центр данных Вашингтона и Frame
Relay и выбрать Select Similar Links.
2. Щелкнуть правой кнопкой мыши на эту же связь и
3. Нажать в колонке Value у значения model и выбрать
FR_T3_int.
Замечание. Обязательно надо поставить галку возле
опции Apply Changes to Selected Objects снизу окна(
рисунок 6.3).
Рисунок 6.3 – Выбор типа связи
После завершения всех изменений в сети, запустим

прогон на один час модельного времени, чтобы увидеть,
ведет ли изменение полосы пропускания к улучшению
После этого необходимо сравнить времена отклика Ftp.
Компания считает, что изменение связи уменьшит время
отклика приложения. Для такого изменения необходимо:
- выбрать окно Results > Compare Results…;
- выбрать пункт Global Statistics > Ftp > Upload
Response Time (sec.);
89
- нажать кнопку Show и выбрать Close в окне View
Results.
Рисунок 6.4 – Результат изменения связи
Как видно из рисунка 6.4, в результате изменения связи

время отклика снизилось приблизительно от 550 с до 475 с.
Однако IT команда подсчитала, что пересылка файла в 25
Мбайт через связь Т3 должна занять примерно 5 с.
Результаты показывают, что полоса пропускания не
является причиной большого времени загрузки.
Компания решает вернуться к связям Т1 и увеличить
размер окна TCP от 8К по умолчанию до 65К. Для этого
необходимо выбрать окно Scenarios > Switch To Scenario >
Window_Size_8K_WAN_Link_T1, а дальше выбрать пункт
Scenario > Duplicate Scenario… и в заключение назвать
сценарий Window_Size_65K_WAN_Link_T1.
Конфигурация сервера центра данных на размер
окна ТСР в 65К
1. Щелкнуть дважды по подсети, помеченной
Washington Backup Station.
2. Щелкнуть правой кнопкой мыши на Backup Server и
3. Нажать на колонку Value для TCP Parameters и
90
выбрать Edit…
Рисунок 6.5 – Выбор размера окна
Для того, чтобы установить размер окна, необходимо

изменить значение Value для Receive Buffer (bytes) на
65535 и выбрать Оk, чтобы закрыть все окна.
Теперь необходимо задать размер окна ТСР для
филиала в Сиднее.
Задание размера окна

1. Нажать правой кнопкой мыши на рабочей области и
выбрать Go To Parent Subnet.
2. Кликнуть дважды по подсети, обозначенной Sydney
Branch.
3. Нажать правой кнопкой мыши на рабочей станции
Sydney Branch и выбрать Edit Attributes.
91
4. Задать размер окна ТСР на 65К тем же самым
способом, что и на сервере.
Затем необходимо убедиться, что WAN связи
установлены на T1, и заново запустить прогон, чтобы
оценить качество функционирования сети.
Сравнение времен отклика для всех трех сценариев
1. Выбрать окно Results > Compare Results…
2. Выбрать пункт Global Statistics > Ftp > Upload
Response Time (sec.).
3. Нажать кнопку Show и затем закрыть окно View
Results.
Результаты моделирования всех сценариев приведены

92
1.В лабораторной работе исследован такой важный

параметр TCP как размер окна. Показано, как не изменяя
пропускной способности линии связи добиться повышения
ее производительности, что является немаловажным на
сегодняшний день, так как это не связано с затратами на
оборудование.
2. Повышение пропускной способности линии связи
приводит к некоторому уменьшению времени отклика
приложений, что подтверждается проведенными
исследованиями. А именно, при размере окна TCP 8К и
скорости подключения T1 имеем время отклика
приложения при загрузке по FTP – 550 секунд. При
изменении скорости подключения до T3 и размере окна
TCP 8К имеем время отклика при загрузке по FTP порядка
475 секунд. Далее при изменении скорости подключения
обратно к T1 и размере окна 65К получаем время отклика
приложения порядка 160 секунд.
3. Полученные результаты показывают, что пропускная
способность каналов связи не была причиной высоких
значений времени отклика. Увеличивая размер окна ТСР от
8К до 65К, и оставляя прежней пропускную способность
линии связи, можно добиться снижения времени отклика
приложения в 3 и более раз!
Сценарий 1. Необходимо продублировать последний

сценарий. Имея размер окна в 65К, изменить пропускную
способность связи на Т3 и посмотреть на эффект,
получаемый по времени отклика Ftp.
Сценарий 2. Необходимо продублировать
дополнительный сценарий 1 и увеличить размер окна ТСР
до 200К. Также необходимо включить параметр ТСР
window scale в параметрах ТСР как для сервера, так и для
клиента. После этого оценить влияние этих изменений на
время отклика FTP.
93
7 ПРИМЕНЕНИЕ МЕЖСЕТЕВОГО ЭКРАНА ДЛЯ
УПРАВЛЕНИЯ ТРАФИКОМ ВЫЧИСЛИТЕЛЬНОЙ
СЕТИ

влияния внедрения политики защиты от
несанкционированного доступа на производительность
приложений и загрузку каналов связи.
Основная сеть Банка Standard Chartered соединяется с
Интернетом через брандмауэр CISCO PIX Firewall.
Пользователи используют различные приложения, включая
электронную почту, веб-браузеры и авторизацию
кредитных карточек. Более того, некоторые пользователи
осуществляют нелегальное копирование файлов для
пиратского тиражирования музыки и видео. Сначала
необходимо оценить выполнение приложений без политики
защиты от несанкционированного доступа. Таким образом,
незаконный трафик не блокируется.
Наиболее критичным приложением для банка Standard
Chartered является авторизация кредитных карточек. Для
этого приложения требуется время отклика менее чем в 2
секунды.
Начало работы
1. Запустить программу IT Guru.
2. Выбрать меню File > Open…
3. Выбрать проект Firewall_Implementation, нажать
Оk и получить исходную сеть, показанную на
рисунке 7.1.
94
Рисунок 7.1 – Исходная сеть
Для того, чтобы оценить выполнение критичного

приложения, необходимо осуществить прогон модели.
Оценку функционирования сети провести для одного
модельного часа. Для этого нужно выполнить
последовательность действий.
1. Нажать на кнопку configuration/run simulation .

2. Установить продолжительность Duration на 1 час.
4. После прогона нажать Close.
Теперь необходимо оценить время отклика приложения
авторизации кредитных карточек для всех пользователей, а
также использование WAN связи. Как отмечалось ранее,
требуется, чтобы критическое время отклика приложения
авторизации кредитных карточек было не больше 2
секунд.
95
Оценка производительности приложения
1. Нажать правой кнопкой мыши и выбрать View
Results.
2. Выбрать пункт Global Statistics > DB Query >
Response Time (sec.) (рисунок 7.2).
Рисунок 7.2 – Оценка производительности приложения
3. Выбрать Show. Теперь необходимо добавить к этому

окну усредненные кривые (рисунок 7.3).
4. Нажать на окно с предыдущим графиком, чтобы
добавить эту кривую на панель (рисунок 7.4).
5 Нажать кнопку Close в окне View Results.
96
Рисунок 7.3 – Усредненные кривые
Рисунок 7.4 – Статистические данные
6.Щелкнуть правой кнопкой мыши по WAN связи и

выбрать View Results, чтобы оценить ее загрузку
7.Выбрать point-to-point > utilization и нажать
Show.
97
Рисунок 7.5 – Загрузка WAN связи
Замечание. Для того, чтобы включить или отключить

графики, необходимо использовать кнопку hide or show
all graphs .
8. Закрыть окно View Results.
Полученные результаты показывают, что: 1) время

98
отклика приложения авторизации кредитных карточек
больше, чем 2 секунды; 2) загрузка WAN связи высока,
что может быть причиной неприемлемого времени отклика
Поэтому компания решила установить и настроить
устройство защиты от несанкционированного доступа,
чтобы заблокировать передачу файлов между клиентскими
компьютерами напрямую. Для этого необходимо:
1.выбрать меню Scenarios > Duplicate Scenario…;
2. назвать сценарий Firewall Implemented.
Теперь надо настроить брандмауэр, чтобы
заблокировать видео-трафик, а для этого - выполнить
ниже перечисленные действия.
1. Щелкнуть правой кнопкой мыши по CISCO PIX
Firewall и выбрать Edit Attributes.
2. Нажать в колонке Value на параметр Proxy Server
Information (рисунок 7.7).
Рисунок 7.7 – Настройка брандмауэра
3. Выбрать значение Voice и изменить значение для
99
Proxy Server Deployed с Yes на No и затем дважды нажать
на Оk (рисунок 7.8).
Рисунок 7.8 – Настройка брандмауэра
Теперь вновь нужно запустить прогон модели, чтобы

оценить эффект от внедрения устройства защиты на
производительность приложения. Для такой оценки
необходимо сравнить время отклика приложения
авторизации кредитных карточек и загрузку WAN связи.
Это достигается выполнением последовательности
действий.
1. Щелкнуть правой кнопкой мыши по рабочей области
и выбрать окно Compare Results.
2. Выбрать пункт Global Statistics > DB Query >
Response Time (sec.) (рисунок 7.9).
3. Нажать кнопку Show и затем в окне View Results
нажать Close.
4. Щелкнуть правой кнопкой мыши по WAN связи и
выбрать пункт Compare Results.
5. Выбрать point-to-point > utilization (рисунок 7.10).
6. Нажать Show и затем закрыть окно View Results.
100
Анализ полученных результатов

Как и ожидалось, результаты, приведенные на рисунке
7.10, показывают, что:
101
1) внедрение устройства защиты от
несанкционированного доступа значительно улучшает
производительность приложения авторизации кредитных
карточек;
2) график загрузки показывает значительное снижение
использования WAN связи;
3) внедрением политики безопасности о прекращении
незаконных передач файлов через пиринговые сети,
компания обеспечила требуемую производительность
приложения авторизации кредитных карточек.
1. В лабораторной работе исследованы результаты

внедрения политики защиты от несанкционированного
доступа и ее влияния на исполнение приложений и
использование линий связи.
2. Результаты исследований показывают, что время
отклика авторизации кредитных карточек больше, чем
требуемый предел в 2 секунды. Загрузка связи ГВС
высока, что может быть из-за времени отклика
неприемлемого приложения. Поэтому было
сконфигурировано устройство защиты от
несанкционированного доступа «фаервол», чтобы
заблокировать передачу файлов, не идущих через главный
сервер, для того чтобы был виден эффект его влияния на
выполнение приложения. Результаты моделирования
показывают, что время отклика приложения составляет
3,75 секунд, а загрузка линии близка к 93,75%, что не
удовлетворяет требованиям в 2 секунды.
3. Проблема решена настройкой «фаервола» таким
образом, чтобы блокировать передачу файлов по каналу
для высвобождения пропускной способности для работы
нужного приложения. В результате настройки имеем время
отклика приложения порядка 0,5 секунды и загрузку линии
порядка 4,1%
Таким образом, показано, что изменением политик
«фаервола» можно добиться требуемой пропускной
способности для работы критичного приложения, такого
102
как авторизация кредитных карт.
Дополнительный сценарий
Сценарий. Необходимо продублировать сценарий

Without_Firewall_Implementation и затем, вместо
внедрения устройства защиты, улучшить WAN связь и
оценить эффект.
103
8 ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ
ПРИЛОЖЕНИЙ ORACLE
Предыдущие лабораторные работы были сосредоточены

на сетях и Интернете (от физического - 1 до транспортного
- 4 уровней OSI). Однако для пользователей не меньший
интерес представляет прикладной уровень -7.
Лабораторная работа использует модуль OPNET`s
Application Characterization Environment (ACE), для
обнаружения и устранения неполадок и оценки времени
отклика для конкретного приложения Oracle.
Модуль АСЕ осуществляет визуализацию и оценку
характеристик, что помогает при анализе приложения.
Менеджеры сетей и разработчики приложений могут
использовать АСЕ для того, чтобы:
- устранить узкие места в сети и приложении;
- диагностировать проблемы приложения;
- исследовать предложенные установки для
существующих приложений;
- прогнозировать выполнение приложения при
различных конфигурациях и условиях работы сети.
Рисунок 8.1 – Общая схема сети
Цель лабораторной работы - решение задачи анализа

производительности двухуровневого (клиент/сервер)
приложения Oracle. Также будут исследованы возможные
104
узкие места, которые могут привести к большому времени
отклика.
Приложение выполняется следующим образом:
клиенты получают доступ к Oracle Server в Центре данных
через сеть Metropolitan Area Network (MAN) с широкой
полосой пропускания и малым временем задержки. Время
отклика клиентского приложения равно 12 секундам.
При решении проблемы производительности
приложения при помощи АСЕ важно выбрать правильный
метод перехвата трафика. Модуль АСЕ сконструирован
таким образом, чтобы можно было анализировать
единственную транзакцию приложения. В лабораторной
работе будут использоваться реальные данные:
трассировочный файл, который содержит трафик
приложения (из сниффера). Необходимо отфильтровать
остальные пакеты, потому что АСЕ считает их частью
субъекта приложения. В идеальном случае задача состоит в
том, что необходимо захватить трассу, которая
представляет собой только одну транзакцию. А в реальном
случае, нужно будет фильтровать посторонние сообщения.
Сообщения в принципе можно отфильтровать в три
момента времени:
- при захвате трассирующего файла из сети;
- во время поступления данных;
- внутри редакторов АСЕ, как показано в данной
лабораторной работе.
В этой работе захваты трасс происходят одновременно
для клиента и для сервера. Эти захваты затем соединяются,
чтобы получить наилучший показатель задержек на
каждом отдельном компьютере и сети в целом.
105
Сначала нужно открыть приложение Прогноз в АСЕ.

Далее необходимо выполнить последовательность
действий.
1. Запустить программу IT Guru.
2. Выбрать меню File > Open…Из меню выбрать пункт
Application Characterization. Скроллировать его до
проекта с названием Oracle_2_Tier_Application, выбрать
его и нажать Оk. Если получено сообщение о том, что нет
возможности открыть файл, то нужно выбрать
Oracle_2_Tier_Application_B и нажать Оk (рисунок 8.2).
Рисунок 8.2 – Окно выбора проекта
Визуализация приложения
После получения «окна выбора проекта» появляется
«карта обмена данных» (рисунок 8.3). Используя эту карту,
необходимо проанализировать приложение в деталях.
106
Рисунок 8.3 – Карта обмена данных
Эта карта показывает данные, перемещаемые между

уровнями приложений Oracle по оси времени. Цвета
сообщений приложения представляют размер сообщения.
Каждая цветовая группа представляет гистограмму
распределения размеров сообщений.
1. Порядок уровней может быть изменен, чтобы
облегчить интерпретацию карты путем перемещения имени
уровня вверх или вниз. В этом случае нужно сохранять
уровни в прежнем порядке – уровень Oracle_Client
наверху, а уровень Oracle_Server внизу.
2. В каждой группе около одной трети сообщений
являются желтыми (101 – 500 байт на сообщение) и около
двух третей – оранжевыми (1 – 100 байт на сообщение).
Это говорит о том, что приложение посылает много
маленьких сообщений.
3. Необходимо разделить сообщения, следующие в
разных направлениях и выбрать пункт View > Split Groups.
4. Теперь сообщения разделены на две группы, и
можно обнаружить больше деталей. Можно увидеть, что:
- верхняя группа представляет сообщения от клиента к
серверу, а правая – от сервера к клиенту;
- в группе сообщений клиент-сервер около половины
сообщений являются оранжевыми;
107
- в группе сообщений сервер-клиент около двух третей
сообщений являются оранжевыми.
5. Следует посмотреть контекстное окно указателя,
поместив мышь над первой группой сообщений. Это окно
показывает, что первая группа сообщений представляет 183
сообщения в каждом направлении (рисунок 8.4).
Рисунок 8.4 - Карта обмена данных после разделения

сообщений
Анализ задержек при помощи модуля AppDoctor

Модуль AppDoctor`s Summary of Delays позволяет
понять причину задержки протокола приложения. Он
разделяет общее время отклика приложения на четыре
компоненты.
1. Задержка обработки уровня – это общее время,
которое затрачивается на обработку приложения на каждом
уровне, включая время на раздумье пользователя.
2. Задержка из-за времени запаздывания – это
компонента задержки, связанная со временем запаздывания
в сети.
3. Задержка из-за полосы пропускания – это компонента
108
задержки, обусловленная ограниченностью полосы
пропускания сети.
4. Задержка «протокол/перегрузка» - это метрика
ограничения сети для прохождения пакета. Это
ограничение может быть вызвано очередью пакетов в сети
или механизмами текущего контроля, установленными
сетевыми протоколами.
Для анализа задержек протокола приложений
необходимо выполнить последовательность действий.
1. Выбрать AppDoctor > Summary of Delays.
2. Поместить курсор на красную часть карты, чтобы
увидеть контекстное окно указателя (рисунок 8.5).
Рисунок 8.5 - Задержки
Вывод. Наиболее значимым фактором, влияющим на

время отклика, является воспроизведение задержки. Для
этой транзакции оно является причиной почти 60%
времен отклика продолжительностью в 12 секунд.
Обзор функции AppDoctor`s Diagnosis
Эта функция проверяет текущую транзакцию по
сравнению с исходами, которые часто вызывают проблемы
выполнения сетевых приложений, сгруппированных по
категориям.
109
Для того, чтобы отобразить данную функцию на экране,
необходимо выбрать функцию AppDoctor > Diagnosis из
меню.
Рисунок 8.6 – Окно функции AppDoctor`s Diagnosis
Нужно исследовать четыре узких места: Protocol

Overhead, Chattiness, Network Effect of Chattiness и
Effect of Latency.
Нажать на пункт Bottleneck, чтобы увидеть описание
diagnosis на нижней панели для каждого узкого места.
Закрыть окно AppDoctor Diagnosis.
Для того, чтобы нельзя было увидеть разделенные
группы на Data Exchange Chart, нужно выбрать пункт
View > Split Groups.
8.3 Моделирование обмена данными
Модуль AppDoctor`s Summary of Delays and Diagnosis

обнаруживает исходы как для сети, так и для обмена
данными между уровнями. Карта обмена данными может
провести дополнительные исследования. Следует изучить
начало транзакции (т.е. между 6.1 и 6.3 секундами
трафика) более внимательно.
Для изменения масштаба к пространству карты, которое
представляет период времени 6.1 – 6.3 секунды, нужно
110
- щелкнуть правой кнопкой мыши по рабочему
пространству карты обмена данных;
- выбрать пункт Zoom to Rectangle из меню и
протащить курсор, чтобы образовать «коробку» вокруг
пространства цели.
Если изначальное изменение масштаба не подходит,
можно выбрать пункт Previous Zoom из меню и попытаться
повторить все действия вновь.
Замечание. После того, как настроен масштабный
уровень, можно использовать клавиши со стрелками для
перемещения во всех направлениях.
Как только будет введен масштаб в карту обмена
данными, группы сообщений превращаются в
индивидуальные сообщения приложения (рисунок 8.7).
Рисунок 8.7 - Карта обмена данными с

индивидуальными сообщениями приложения
Теперь надо изучить индивидуальные приложения.

Стрелка указывает, в каком направлении поступает
сообщение, а само приложение составлено из многих
маленьких сообщений (на рисунке 8.7 они указаны
оранжевым и желтым цветами). Здесь каждое изменение
111
направления называется поворотом приложения –
приложение изменяет направление потока данных.
Приложения с большим количеством поворотов
называются избыточными и являются чувствительными к
задержкам сети. Чувствительность возникает, потому что
каждое сообщение должно быть принято на своем уровне
до того, как посылается соответствующее ответное
сообщение. Таким образом, время задержки сети влияет на
каждое сообщение.
Можно заключить, что визуализация карты обмена
данными подтверждает анализ, предсказанный модулем
Summary of Delays and Diagnosis: приложение избыточно,
и избыточность означает, что задержка в сети значительно
замедляет приложение.
Модуль AppDoctor осуществляет также вычисление
суммарных статистик для транзакции приложения. Можно
просмотреть статистики для этого приложения.
Просмотр суммарных статистик

Две наиболее важные статистики – количество
поворотов приложения и максимальное число обмененных
данных при единственном повороте выбирают из меню
AppDoctor > Statistics (рисунок 8.8).
Нетрудно заметить, что приложение имеет 2.157
поворотов приложения (циклов запрос/ответ), чтобы
обменять 182.056 байт данных.
Также максимальное количество данных, посланных в
одном повороте – 258 байт в одном направлении (А B) и
455 байт в другом (AB). Избыточность является
превалирующей в базах данных и часто является основной
причиной плохого времени отклика.
112
Рисунок 8.8 – Статистики AppDoctor
Здесь одна воспроизведенная задержка, усугубленная

2.157 поворотами, насчитывает около 6.97 секунд общего
времени отклика транзакции. Так время задержки сети
является в основном результатом географического
расстояния и скачков в сети, добавление полосы
пропускания привнесет минимальный эффект на время
отклика. Чтобы минимизировать эту компоненту, нужно
либо уменьшить время задержки в цепи, либо уменьшить
число поворотов приложения. Время задержки в цепи
является физически установленным, поэтому более
практичным является изменение поведения приложения.
Далее нужно закрыть окно AppDoctor Statistics.
Прогноз выполнения приложения

Функция AppDoctor`s Quick Predict является
аналитико - имитационным механизмом, который
предоставляет возможность быстрой проверки выполнения
приложения при различных сетевых условиях. С помощью
Quick Predict можно проверить возможные расширения
сети, чтобы оценить то влияние, которое они могут
113
оказывать на выполнение приложения. Если это
приложение установлено на ГВС, то можно посмотреть, как
задержка в сети повлияет на выполнение приложения. Для
этого нужно выполнить последовательность действий.
1. Выбрать из меню AppDoctor > Quick Predict.
2. Выбрать пункт Latency для X Axis и установить
значения Min Latency на 0ms и Max Latency на 20ms
Рисунок 8.9 – Окно настройки Quick Predict
3. Нажать на кнопку Update Graph.
Рисунок 8.10 – График задержек
Этот график показывает, что задержка прямо

пропорциональна полосе пропускания. То есть, если
114
приложение установлено на ГВС, то очень важно
переписать его, чтобы получить лучшее время отклика.
8.4 Выводы по лабораторным работам
1. Эта лабораторная работа показывает, как может быть

использован модуль АСЕ для визуализации и
диагностирования проблем при оценке производительности
приложения. Изначально было известно только, что
приложение имеет время отклика в 12 секунд. Затем после
моделирования стало известно, что медленный отклик был
вызван избыточностью приложения, усугубленной
запаздыванием в сети. Хотя запаздывание между клиентом
и сервером было только 3.2 мс, в результате многих
поворотов приложения оно стало очень значительным.
Анализ реального трафика приложения из снифера
позволил установить, что приложение отправляет много
маленьких пакетов от 1 до 100 байт (60%) и от 101-500
байт(30%).
В этом случае лучшее решение – это переписать
приложение, чтобы передавать меньше, но «больших»
сообщений. Используя полученные графики, статистики и
декодирование протоколов, производимые АСЕ, вы должны
быть в состоянии убедить разработчиков баз данных
изменить их транзакцию, как это требуется.
2. Лабораторная работа раскрывает процедуру анализа
производительности клиент-серверного приложения Oracle.
Исследована методика поиска критических блоков и
решений, влияющих на параметры качества и
производительности. Исследования проводятся по данным
реального перехвата трафика, что позволяет моделировать
реальные приложения. Все аспекты производительности
(количество пакетов, средний размер и интенсивность
трафика) учитываются при верификации модели. Также
представляется возможным оценить влияние расширения
(преобразования) сети на приложение. Моделирование
позволило определить причины неудовлетворительной
работы приложения в некоторых режимах и позволило
предложить методы улучшения качества работы.
115
После анализа конкретной единичной транзакции было
выявлено, что в ней приложение создает 2157 циклов
запрос/ответ, при этом поток данных составляет 180 кбайт.
Из-за большого количества запросов возникает задержка
почти в 7 секунд. Подобное происходит из-за
суммирования всех задержек на пути следования пакета.
Уменьшить общую задержку можно уменьшением
количества запросов/ответов либо модернизацией линий
связи. Так как уменьшение задержек в линии связи не
всегда возможно, и часто связано с увеличением
пропускной способности, соответственно с ощутимыми
финансовыми издержками, остается только модернизация
116
9 ТЕХНОЛОГИЯ ETHERNET
Технология Ethernet является образцом Carrier Sense,

Multiple Access with Collision Detect (CSMA/CD)
технологии ЛВС. Ethernet - это сеть множественного
доступа (Multiple Access), то есть узлы посылают и
принимают фреймы через общие каналы связи. Carrier
sense в CSMA/CD означает, что все каналы могут быть
разделены на свободные и занятые связи. Collision Detect
означает, что узел «слушает», как он передает фрейм и
может таким образом, установить, когда передаваемый
фрейм искажается фреймом, передаваемым с другого узла.
В этой лабораторной работе будет установлена сеть
Ethernet с 30 узлами шинной топологии, соединенными
коаксиальным кабелем. Коаксиальная связь действует на
скорости передачи данных в 10 Мб/с.
Цель лабораторной работы заключается в
исследовании зависимости пропускной способности сети
от ее загрузки и размеров пакетов.
Создание нового проекта сети

Для создания нового проекта для сети Ethernet,
1. запустить программу OPNET IT Guru Academic
Edition > из меню File и выбрать пункт New;
2. выбрать пункт <Project > и нажать Оk;
3. назвать проект < инициалы>_Ethernet и сценарий
Coax ;
4. нажать кнопку Оk.
При запуске первоначальной топологии в диалоговом
окне необходимо убедиться, что выбрано меню Create
Empty Scenario >. Тогда нужно нажать Next , выбрать
меню Office и нажать Next . Затем - присвоить значение
200 X Span, а Y Span – 100. После этого - дважды нажать
Next, нажать Оk и закрыть диалоговое окно Object Palette.
117
Для создания коаксиального соединения:
1. выбрать Topology > Rapid Configuration, из меню
выбрать пункт Bus и нажать Оk;
2. нажать кнопку Select Models в диалоговом окне
Rapid Configuration и из меню Model List выбрать пункт
ethcoax, затем нажать Оk;
3. в диалоговом окне Rapid Configuration (рисунок 9.1)
установить следующие восемь значений и нажать Оk;
4. для конфигурирования коаксиальной шины нужно
щелкнуть правой кнопкой мыши по горизонтальной связи и
из меню выбрать Advanced Edit Attributes;
5. нажать на значение атрибута модели, из меню
выбрать Edit и выбрать модель eth_coax_adv;
6. присвоить значение 0.05 атрибуту delay, а атрибуту
thickness – 5;
7. нажать кнопку Оk.
Рисунок 9.1 - Диалоговое окно Rapid Configuration
118
Рисунок 9.2 - Настройка коаксиальной шины
Теперь сеть создана. Она должна выглядеть так, как

изображено ниже на рисунке 9.3.
Замечание. При создании проекта необходимо
убедиться, что он сохранен.
Рисунок 9.3 – Проект сети

119
Создание трафика между узлами сети
Воспроизвести трафик, сгенерированный узлами,
можно, выполнив ниже приведенный алгоритм.
1. Щелкнуть правой кнопкой мыши по любому из 30
узлов > Select Similar Nodes. Теперь все узлы в сети
выбраны.
2. Щелкнуть правой кнопкой мыши по любому из 30
узлов > Edit Attributes (Рисунок 9.4).
3. Сопоставить пункт Apply Changes с окном Selected
Objects. Важно избегать перенастройки каждого узла в
отдельности.
4. Раскрыть дерево Traffic Generation Parameters.
5. Изменить значение ON State Time на
exponential(100) >. Изменить значение OFF State Time на
exponential(100).
6. Раскрыть дерево Packet Generation Arguments.
7. Изменить значение атрибута Packet Size на
constant(1024).
8. Щелкнуть правой кнопкой мыши по атрибуту
Interarrival Time и выбрать более высокий уровень для
Promote Attribute.
9. Нажать кнопку Оk, чтобы вернуться в Project Editor.
10.Сохранить проект.
Рисунок 9.4 – Окно конфигурации узлов сети

120
Чтобы изучить работу сети при различных нагрузках,

нужно запустить модель несколько раз, изменяя нагрузки в
сети. Для этого используют простой способ. Ранее был
переведен на более высокий уровень атрибут Intrarrival
Time для генерации пакетов. Присвоение различных
значений этому атрибуту выполняется
последовательностью действий.
1. Нажать на клавишу Configure/Run Simulation.
2. Убедиться, что выбрана вкладка Common и атрибуту
Duration присвоить значение 15 секунд.
3. Выбрать вкладку Object Attributes.
4. Нажать на кнопку Add. Диалоговое окно Add
Attribute должно появиться заполненным улучшенными
атрибутами всех узлов сети (рисунок 9.5).
Рисунок 9.5 – Окно конфигурации моделирования
Нужно добавить атрибут Interarrival Time для всех

узлов. Чтобы сделать это, необходимо выполнить
- нажать на первый атрибут в списке (Office
Network.node_0.Traffic Generation…);
121
- нажать на кнопку Wildcard;
- нажать на node_0 и из меню выбрать звездочку (*);
Теперь сгенерирован новый атрибут, содержащий
звездочку (второй в списке), и его нужно добавить,
щелкнув по соответствующей ячейке под колонкой Add.
Диалоговое окно Add Attribute должно выглядеть так,
как показано ниже на рисунке 9.6. Затем нажать кнопку
Оk.
Рисунок 9.6 - Диалоговое окно Add Attribute
5. В списке атрибутов объекта моделирования появится

Office Network.*.Traffic Generation Parameter… Нужно
нажать на этот атрибут, и чтобы выбрать его > нажать на
кнопку Values диалогового окна.
6. Добавить следующие девять значений функций
распределений времени между пакетами в трафике, как
показано на рисунке 9.7.
Рисунок 9.7 – Настройка Office Network.*.Traffic

Generation Parameter…
122
7. Нажать Оk. Посмотреть на верхний правый угол
диалогового окна Simulation Configuration и убедиться,
что атрибут Number of runs in set установлен на 9
Рисунок 9.8 - Окно конфигурации моделирования
8. Для всех моделей по 9 прогонов каждая, нам нужен

имитатор, чтобы сохранить «скалярное» значение,
которое представляет средняя нагрузка в сети и чтобы
сохранить другое скалярное значение, которое
представляет среднюю пропускную способность сети.
Чтобы сохранить эти скалярные величины в файле,
понадобится имитатор.
9. Присвоить < инициалы>_Ethernet_Coax текстовому
полю Scalar file (рисунок 9.9).
10. Нажать кнопку Оk и затем сохранить проект
123
Рисунок 9.9 – Вкладка Advanced
9.4 Выбор статистик и вычисление их средних

значений
Чтобы выбрать статистики, которые нужно собрать во

время моделирования, необходимо выполнить ниже
перечисленные действия.
1.Щелкнуть правой кнопкой мыши где-либо в рабочем
пространстве проекта (но не на узлах и не на связях) и
выбрать из меню Choose Individual Statistics .
2.Раскрыть дерево Global Statistics.
3.Раскрыть дерево Traffic Sink и щелкнуть по окошку
метки после Traffic Received (packets/sec).
4.Раскрыть дерево Traffic Source и щелкнуть по
окошку метки после Traffic Sent (packets/sec.)
5.Нажать Оk.
Теперь, чтобы собрать средние значения статистик,

перечисленных выше, как скалярные величины, нужно
выполнить последовательность действий.
1. Из меню Simulation выбрать Choose Statistics
(Advanced).
Тестовые пакеты Traffic Sink и Traffic Received
должны появиться под Global Statistic Probes.
2. Щелкнуть правой кнопкой мыши по тестовому пакету
124
Traffic Received > Edit Attributes. Установить атрибут
scalar data. Установить атрибут scalar type, чтобы
усреднить по времени.
3. Повторить предыдущий шаг с тестовым пакетом
Traffic Sink.
4. Выбрать сохранение из меню File в окне Probe model
и затем закрыть окно.
5. Убедиться, что проект сохранен.
Рисунок 9.10 - Окно параметров
Осталось запустить процесс моделирования, для чего

нужно выполнить ниже перечисленные действия.
1. Нажать на кнопку Configure/Run Simulation .
Убедиться, что атрибуту времени - Duration присвоено
значение 15 секунд (не часов) > и нажать Run. В
зависимости от скорости процессора это может занять
несколько минут.
Теперь имитатор завершает девять прогонов, один для
каждого времени генерации трафика. Каждый успешный
прогон занимает для завершения больше времени, потому
что интенсивность трафика возрастает.
2. После того, как 9 прогонов модели завершены,
нажать Close.
125
3. Сохранить проект.
После перезапуска моделирования OPNET IT Guru
«добавит» новые результаты к уже имеющимся в
скалярном файле. Чтобы избежать этого, необходимо
удалить скалярный файл до того, как будет начат новый
прогон. Для удаления скалярного файла нужно:
- перейти к меню File;
- выбрать пункт Model Files > Delete Model Files;
- выбрать пункт Output Scalars;
- выбрать скалярный файл, который нужно стереть (в
данной лабораторной работе это -
<инициалы>_Ethernet_Coax_Scalar ;
- подтвердить удаление путем нажатия Оk;
- нажать кнопку Close.
Для того, чтобы просмотреть и проанализировать

результаты, выполнить последовательность действий.
1. Выбрать View Results (Advanced) из меню Results.
Теперь инструмент Analysis Configuration открыт.
2. Усредненные результаты сохранились в скалярном
файле. Чтобы загрузить этот файл, нужно выбрать Load
Output Scalar File из меню File и выбрать
<инициалы>_Ethernet_Coax из меню.
3. Выбрать Create Scalar Panel из меню Panels и
присвоить атрибуту Horizontal значение Traffic
Source.Traffic Sink (packets/sec.).average .
4.Присвоить атрибуту Vertical значение Traffic
Sink.Traffic Received (packets/sec.) (рисунок 9.11).
5. Нажать кнопку Оk.
Рисунок 9.11 – Параметры трафиков

126
Результирующий график должен выглядеть примерно
так, как это показано на рисунке 9.12.
Рисунок 9.12 - Результирующий график
1. Лабораторная работа раскрывает основы

моделирования сетей общего доступа с коллизионной
средой. Также лабораторная работа показала, как можно
задавать параметры законов распределения генерации
трафика узлами и снимать характеристики сетей с
топологией «шина». Моделирование показало
невозможность широкого использования таких сетей и
ограниченность максимального числа узлов сети.
2. Основная часть работы заключается в
дополнительных заданиях, данных в конце. Сеть из 30
компьютеров с общей шиной исследовалась на
нагрузочную способность. В результате получился график
зависимости между количеством посланных и принятых
пакетов.
При слишком низкой или слишком высокой нагрузке
127
количество принятых пакетов (то есть производительность)
падает, что вызвано работой протокола CSMA/CD. В
идеале график должен представлять прямо-
пропорциональную зависимость, однако в пике
производительности из 700 посланных пакетов дошло
только 220, а при повышенной нагрузке на 1500 посланных
пакетов приходится 150 дошедших. При низкой загрузке на
100 посланных пакетов 50 дошедших. Таким образом,
минимальный процент потерь при наименьшей загрузке –
50%, при нормальной – 69%, при высокой – 90%. Это
очень плохие показатели для сети. Они были получены при
специально заданных параметрах генерации трафика. В
дополнительных заданиях предлагается выяснить причину
такой работы сети, промоделировать разные варианты
решения.
1. Объяснить полученные результаты по графику,

показывающему соотношение между полученными и
посланными пакетами. Почему пропускная способность
падает, когда нагрузка является или слишком низкой, или
слишком высокой?
2. Создать три дубликата сценария имитации,
задействованного в данной лабораторной работе. Назвать
эти сценарии Coax_Q2a, Coax_Q2b и Coax_Q2c.
Установить атрибут Interarrival Time из Packet
Generation Arguments для всех узлов следующим образом:
- сценарий Coax_Q2a: экспоненциальный(0,1);
- сценарий Coax_Q2b: экспоненциальный(0,05);
- сценарий Coax_Q2c: экспоненциальный(0,025).
Во всех перечисленных выше сценариях открыть
диалоговое окно Configure Simulation и из Object
Attributes удалить атрибуты со множественными
значениями.
Выбрать следующую статистику для узла 0: Ethcoax >
Collision Count. Убедиться, что выбрана следующая
статистика: Global Statistics > Traffic Received
(packets/sec.).
128
Запустить имитацию для всех трех сценариев. Получить
два графика: один, чтобы сравнить подсчет коллизий узла
0 в этих трех сценариях и другой график, чтобы сравнить
трафики с трех сценариев. Объяснить графики и
прокомментировать результаты.
3.Чтобы изучить эффект от числа станций,
задействованных в выполнении сегмента Ethernet,
использовать дубликат сценария Coax_Q2c, который был
создан в вопросе 2. Назвать новый сценарий Coax_Q3. В
этом новом сценарии удалить узлы с нечетными номерами,
общее количество которых – 15. Запустить имитацию для
нового сценария. Создать график, который сравнивает
число сбоев в сценариях Coax_Q2c и Coax_Q3. Пояснить
графики и прокомментировать результаты.
4.В имитации использовался пакет размером в 1024
байт. (Каждый пакет Ethernet может содержать до 1500
байт данных). Чтобы изучить влияние размера пакета на
пропускную способность созданной сети Ethernet, создать
дубликат сценария Coax_Q2, созданного в п.2. Назвать
новый сценарий Coax_Q4. В новом сценарии использовать
пакет размером в 512 байт (для всех узлов). Как для
сценария Coax_Q2c, так и для Coax_Q4, выбрать
следующие глобальные статистики: Global Statistics >
Traffic Sink > Traffic Received (bits/sec.). Перезапустить
имитацию сценариев Coax_Q2c и Coax_Q4. Создать
график, который сравнивает пропускную способность как
пакеты/с и другой график, который сравнивает пропускную
способность как бит/с.
129
10 ВНЕДРЕНИЕ И ИСПОЛЬЗОВАНИЕ
КОММУТИРОВАННЫХ ЛВС
Эта лабораторная работа предназначена для того, чтобы

продемонстрировать внедрение и использование
коммутированных ЛВС. Моделирование в этой
лабораторной работе поможет изучить работу различных
ЛВС, соединенных при помощи коммутаторов и
концентраторов.
Существует ограничение на количество узлов, которые
могут быть соединены в сети и на размер площади,
которую может обслужить сеть. ЛВС используют
коммутаторы, чтобы задействовать связь между двумя
компьютерами даже тогда, когда нет прямого соединения
между этими узлами. Коммутатор – это устройство с
несколькими входами и выходами, к которым
присоединены компьютеры. Основная работа коммутатора
состоит в том, чтобы принимать пакеты, которые
прибывают на вход и переправлять их на правильный
выход таким образом, чтобы они могли достичь своего
получателя.
Ключевая проблема, с которой сталкивается
коммутатор - это ограниченная полоса пропускания его
выходов. Если пакеты, предназначенные для определенного
выхода, прибывают на коммутатор и скорость их прибытия
превышает пропускную способность этого выхода, то мы
получим проблему столкновения пакетов. В этом случае
коммутатор выстроит пакеты в очередь или отправит в
буфер до тех пор, пока проблема не устранится.
В этой лабораторной работе будут создаваться
коммутированные ЛВС, с использованием двух различных
коммутирующих устройств: концентраторов и
коммутаторов. Концентратор передает пакет, прибывший
на один из его входов, на все выходы вне зависимости от
назначения пакета. С другой стороны, коммутатор передает
пакет на один или более выходов в зависимости от
назначения пакета.
130
Целью лабораторной работы является исследование
степени влияния конфигурации сети и типов
коммутирующих устройств на пропускную способность
сети.
Создание нового проекта

1.Запустить OPNET IT Guru Academic Edition и из
меню File выбрать New.
2.Выбрать Project, нажать Оk, назвать проект
<инициалы>_SwitchedLAN , сценарий OnlyHub и нажать
Оk.
3. В диалоговом окне Initial Topology выбрать Create
Empty Scenario, нажать Next, выбрать пункт Office из
списка Network Scale, нажать Next три раза и нажать Оk.
4. Закрыть диалоговое окно Object Palette.
Создание сети
Для создания коммутированной сети выполнить
1. Выбрать меню Topology > Rapid Configuration. Из
меню выбрать Star и нажать кнопку Оk.
2. В диалоговом окне Rapid Configuration нажать на
кнопку Select Models. Из меню Model List выбрать
ethernet и нажать Оk.
3. В диалоговом окне Rapid Configuration установить
следующие пять параметров: Center Node Model =
ethernet16_hub, Periphery Node Model = ethernet_station,
Link Model = 10BaseT, Number = 16, Y = 50, Radius = 42 и
нажать Оk (рисунок 10.1).
131
Рисунок 10.1 - Диалоговое окно Rapid Configuration
4. Щелкнуть правой кнопкой мыши по узлу node_16 >

Edit Attributes >, изменить имя атрибута на Hub1 и нажать
кнопку Оk.
Созданная сеть должна выглядеть, как показано на
рисунке 10.2.
Как всегда, нужно убедиться, что проект сохранен.
Рисунок 10.2 - Коммутированная сеть

132
Конфигурирование трафика сети
Для конфигурирования трафика, сгенерированного
станциями, выполнить последовательность действий.
1. Щелкнуть правой кнопкой мыши по любой из 16
станций (от node_0 до node_15) > Select Similar Nodes.
Теперь все станции в сети выбраны.
2. Щелкнуть правой кнопкой мыши по любой из 16
станций и появится Edit Attributes.
3. В проверочном окошке сверить Apply Changes и
Selected Objects.
4. Расширить иерархии атрибута Traffic Generation
Parameters и атрибута Packet Generation Attribute и
установить величины, указанные на рисунке 10.3.
5. Нажать кнопку Оk, чтобы закрыть окно
редактирования атрибутов.
Рисунок 10.3 – Настройка трафика
Выбор статистик
Чтобы выбрать статистики, которые должны быть
собраны во время моделирования, необходимо выполнить
1.Щелкнуть правой кнопкой мыши в любом месте и
133
выбрать из меню Choose Individual Statistics.
2.В диалоговом окне Choose Results выбрать
следующие четыре статистики, показанные на рисунке
10.4.
3.Нажать кнопку Оk.
Для задания длительности моделирования выполнить
1. Нажать на кнопку Configure/Run Simulation.
2. Установить длительность на 2.0 минуты.
Рисунок 10.4 - Диалоговое окно Choose Results
Сеть, которая только что была создана, использует

только один концентратор для соединения 16 станций.
Спроектируем другую сеть, которая использует
коммутатор, и посмотрим, как это отразится на работе
сети. Чтобы сделать это, создадим копию имеющейся сети.
1. Из меню Scenarios выбрать Duplicate Scenario, дать
ему имя HubAndSwitch и нажать Оk.
134
2. Открыть Object Palette нажатием на и убедиться,
что из меню выбран Ethernet.
Теперь разместим в новом сценарии концентратор и
коммутатор (рисунок 10.5).
Чтобы добавить Hub, нужно нажать на его
изображение, передвинуть мышь по рабочему пространству
и щелкнуть там, где нужно разместить узел.
Точно так же добавляется Switch.
3. Закрыть окно Object Palette.
4. Щелкнуть правой кнопкой мыши по новому узлу,
появится Edit Attributes, изменить имя атрибута на Hub2 и
нажать кнопку Оk.
5. Щелкнуть правой кнопкой мыши по коммутатору,
появится Edit Attributes, изменить имя атрибута на Switch
и нажать Оk.
Рисунок 10.5 – Сетевое оборудование
6. Переконфигурировать сеть сценария HubAndSwinch

так, как это показано на рисунке 10.6.
135
Рисунок 10.6 – Новая конфигурация сети
10.3 Моделирование сети по сценариям
Одновременное моделирование обоих сценариев

выполняется ниже приведенной последовательностью
действий.
1. Из меню Scenarios выбрать Manage Scenarios.
2. Изменить значения под колонкой Results на <collect>
(или recollect) для обоих сценариев.
Рисунок 10.7 – Сбор статистики

136
3. Нажать кнопку Оk, чтобы запустить оба сценария. В
зависимости от скорости процессора это может занять
несколько минут.
4. После завершения двух прогонов моделей, по
одному для каждого сценария, нажать Close.
Просмотр и анализ результатов.

1. Из меню Results выбрать Compare Results.
2. Изменить меню в нижней правой части, как
Рисунок 10.8 - Диалоговое окно Compare Results
3. Выбрать статистику Traffic Sent (packets/sec) и

нажать кнопку Show. Результирующий график должен быть
похожим на тот, что представлен ниже на рисунке 10.9.
Полученные трафики в обоих сценариях почти идентичны.
137
Рисунок 10.9 – Отправленный трафик
4. Выбрать Traffic Received (packets/sec) и нажать

кнопку Show. Результирующий трафик должен быть
похожим на представленный ниже. Как видно из рисунка
10.10, трафик, принятый при помощи второго сценария,
HubAndSwitch выше, чем у сценария OnlyHub.
Рисунок 10.10 – Принятый трафик

138
5. Выбрать статистику Delay (packets/sec) и нажать
кнопку Show. Результирующий график должен иметь вид,
как на рисунке 10.11.
Рисунок 10.11 – Задержки
6. Выбрать статистику Collision Count для Hub1 и

нажать Show.
7. На результирующем графике щелкнуть правой
кнопкой мыши, выбрать Add Statistics, Collision Count
статистику для Hub2, изменить As is на time_average и
нажать кнопку Add.
Рисунок 10.12 – Коллизии

139
8. Результирующий график приведен на рисунке 10.13.
Рисунок 10.13 – Результирующий график
1. Лабораторная работа необходима для изучения

функционирования сетей с коммутаторами и основ
проектирования больших коммутируемых сетей. Основное,
что необходимо для качественной коммутируемой сети -
это гарантированная полоса пропускания между узлами.
Проектирование качественной сети заключается именно в
расчете структуры сети с уже гарантированным качеством.
Основной результат лабораторной работы заключается в
тестировании нагрузочной способности и предельных
качественных характеристик коммутируемой сети.
2. Исследуемая проблема - переполнения буфера
приема/передачи в коммутаторе. Для этого создается
интенсивный трафик на 2 порта с помощью двух сетей с
концентраторами. Явление переполнения буфера
проявляется в увеличенной задержке при включении сети
(время наполнение таблиц коммутации). При добавлении
коммутатора средняя задержка в сети падает с 0.14 мс до
140
0.01 мс, количество доставленных пакетов выросло с 720
до 770, т.е. на 7%. Количество коллизий в сегменте с
концентратором сократилось с 2400 до 900, т.е. - в 2.6
раза.
1. Объясните, почему добавление коммутатора

позволяет сети работать лучше в смысле пропускной
способности и задержек.
2.Проанализирован подсчет коллизий на узлах. Можете
вы проанализировать подсчет коллизий на коммутаторе?
Объясните ваш ответ.
3. Создайте два новых сценария. Первый будет таким
же, как и сценарий OnlyHub, но замените в нем узел на
коммутатор. Второй сценарий будет таким же, как и
HubAndSwitch, но замените в нем оба узла на
коммутаторы, удалите старый коммутатор и подсоедините
два коммутатора связью 10BaseT. Сравните исполнение
четырех сценариев в смысле пропускной способности,
задержек и подсчета коллизий. Проанализируйте
результаты.
Замечание. Чтобы заменить узел коммутатором,
щелкните правой мышью по узлу и присвойте атрибуту
модели значение ethernet16_switch.
141
11 ПРОЕКТИРОВАНИЕ И ОПТИМИЗАЦИЯ СЕТИ
Настоящая лабораторная работа демонстрирует

особенности проектирования сети, принимая во внимание
пользователей, услуги и размещение узлов. Главной
задачей является оптимизация схемы сети. Для анализа
концептуальной схемы сети, обычно используют
имитационное моделирование. Изначальная
концептуальная конструкция обычно изменятся несколько
раз, пока не будет принято конечное решение о том, какую
схему следует внедрить. Желательно получить такую
конструкцию, которая максимизирует производительность
сети, принимая во внимание затраты и требуемые услуги,
которые могут быть предложены пользователям различных
типов. После того, как сеть внедрена, нужно периодически
производить оптимизацию сети, чтобы удостовериться, что
она обеспечивает максимальную производительность.
В этой лабораторной работе нужно спроектировать сеть
для компании, которая имеет четыре отдела:
исследовательский, инженерный, коммерческий и отдел
продаж. Будет использована такая модель ЛВС, которая
позволит рассмотреть множество клиентов и серверов на
одном объекте моделирования. Такая модель значительно
уменьшит как размер работ по конфигурации, которые
необходимо выполнить, так и размер памяти, необходимой
для выполнения моделирования.
влияния различных конструкторских решений на работу и
производительность сети.

1. Запустить OPNET IT Guru Academic Edition и из
меню File выбрать New.
142
2. Выбрать Project, нажать кнопку Оk, назвать
проект < инициалы>_NetDesign, сценарий SimpleNetwork
и нажать Оk.
3. В диалоговом окне Initial Topology убедиться, что
выбран Create Empty Scenario, нажать кнопку Next, из
списка Network Scale выбрать Campus, из меню Size
выбрать Miles, присвоить 1 как X Span, так и Y Span, два
раза нажать Next и нажать кнопку Оk.
Создание и настройка сети

Для инициализации сети нужно выполнить ниже
перечисленные действия.
1. В верхней части проектного окна должно появиться
диалоговое окно Object Palette. Если его там нет, то
необходимо открыть его, нажав . Следует убедиться,
что из меню на этом окне выбран пункт internet_toolbox.
2. Добавить к проектному окну следующие объекты:
Application, Config, Profile Config, subnet.
3.Чтобы добавить объект, нужно нажать на его
изображение (знак), передвинуть мышь на рабочую
область и щелкнуть левой кнопкой мыши, чтобы
разместить объект. Затем нажать на правую кнопку мыши.
Рабочее пространство должно содержать следующие три
объекта (рисунок 11.1).
4.Закрыть диалоговое окно Object Palette и сохранить
проект.
Рисунок 11.1 – Рабочее пространство
143
Настройка сервиса
1. Щелкнуть правой кнопкой мыши по узлу
Application Config, появится Edit Attributes , изменить
атрибут name на Applications, изменить атрибут
Application Definitions на Default и нажать кнопку Оk.
2. Щелкнуть правой кнопкой мыши по узлу Profile
Config, появится Edit Attributes, изменить атрибут name
на Profiles, изменить атрибут Profile Configuration на
Sample Profiles и нажать кнопку Оk.
Замечание. Атрибут Sample Profiles подсоединяет
приложения, востребованные такими пользователями, как
инженеры, исследователи, продавцы и пользователи
мультимедиа.
Настройка подсети
1. Щелкнуть правой кнопкой мыши по узлу subnet,
появится окно Edit Attributes, изменить атрибут name на
Engineering и нажать Оk.
2. Два раза щелкнуть мышью по узлу Engineering.
Получится пустое рабочее пространство, указывающее на
то, что подсеть не содержит никаких объектов.
3. Открыть базу рисунков и убедиться, что она все
еще установлена на атрибуте internet_toolbox.
4. Добавить следующие пункты к рабочему
пространству подсети: 10BaseT LAN, ethernet16 Switch и
связь 10BaseT link, чтобы соединить ЛВС с коммутатором
и затем закрыть окно.
5. Щелкнуть правой кнопкой мыши по узлу 10BaseT
LAN > Edit Attributes >, изменить имя атрибута на LAN и
убедиться, что значение атрибута Number of Workstations
равно 10. Нажать на колонку Value для Application:
атрибут Supported Profiles и выбрать Edit. Должна
получиться таблица, в которой необходимо:
- установить число рядов равным 1;
- установить атрибут Profile Name на Engineer.
- дважды нажать кнопку Оk.
Только что созданный объект эквивалентен топологии
«звезда» ЛВС из 10 рабочих станций. Трафик, полученный
144
от пользователей этой ЛВС, напоминает полученный от
engineers.
6. Переименовать ethernet16Switch на Switch.
7. Подсеть будет выглядеть так, как показано на
Рисунок 11.2 – Подсеть
Настройка всех отделов

1. Вернуться в основное окно проекта, нажав на
кнопку Go to the higher level .
Подсети для других отделов компании должны быть
похожими на эту, за исключением поддерживающих
параметров.
2. Сделать три копии только что созданной подсети
Engineering. Нажать на узел Engineering, из меню Edit
выбрать Copy , а из меню Edit три раза выбрать Paste,
помещая подсеть в рабочее пространство после каждого
раза, чтобы создать новые подсети.
3. Переименовать (щелкнув правой кнопкой мыши по
подсети и выбрав Set Name) и организовать подсети, как
показано ниже на рисунке 11.3.
4. Нажать дважды на узел Research > Edit атрибуты его
ЛВС > Edit значение Application: атрибут Supported
Profiles >, изменить значение Profile Name с Engineer на
Researcher >, дважды нажать Оk и перейти на более
высокий уровень, нажав на кнопку .
145
Рисунок 11.3 – Подсети
5. Повторить шаг 4 с узлом Sales и присвоить его

Profile Name параметр Sales person.
6. Повторить шаг 4 с узлом E-Commerce и присвоить
его Profile Name параметр E-commerce Customer.
Настройка серверов
Теперь нужно внедрить подсеть, которая содержит
серверы. Серверы должны поддерживать приложения,
установленные используемыми профилями. Можно
перепроверить эти приложения, редактируя атрибуты узла
Profile. Необходимо проверить каждый ряд под иерархией
Applications, которая, в свою очередь, находится под
иерархией Profile Configuration. Можно увидеть, что
нужны серверы, которые поддерживают следующие
приложения: Web browsing, Email, Telnet, File Transfer,
Database и File Print. Для этого необходимо выполнить
ряд действий.
1. Открыть меню Object Palette и добавить
новую subnet, переименовать новую подсеть как Servers и
дважды щелкнуть по узлу Servers, чтобы войти в его
146
рабочее пространство.
2. Из меню Object Palette добавить три
ethernet_servers, один ethernet16_switch и три 10BaseT
связи, чтобы соединить серверы с коммутатором.
3. Закрыть Object Palette.
4. Переименовать серверы и коммутатор, как показано
ниже на рисунке 11.4.
Рисунок 11.4 – Серверы и коммутатор
5. Нажать правой кнопкой мыши на каждый из

серверов, показанных выше и отредактировать значение
приложения (Application): атрибута Supported Services.
Для этого выполнить:
- для Web Server добавить четыре ряда для поддержки
услуг Web Browsing (Light HTTP1.1), Web Browsing
(Heavy HTTP 1,1), Email (Light) и Telnet Session (Light);
- для File Server добавить два ряда для поддержки
услуг File Transfer (Light) и File Print (Light);
- для Database Server добавить один ряд для поддержки
услуги Database Access (Light).
6. Вернуться в окно проекта, нажав на кнопку Go to
the higher level .

147
Соединение подсетей
1. Открыть меню Object Palette и добавить

четыре связи 100BaseT, чтобы присоединить подсети
отделов к подсети Servers.
Когда создается каждая связь, нужно быть уверенным в
том, что она сконфигурирована так, чтобы подсоединить
«коммутаторы» в обеих сетях один к другому. Это можно
сделать, выбирая их из меню, как показано ниже на
Рисунок 11.5
2. Закрыть меню Object Palette.

3. Полученная сеть должна быть аналогична показанной
Рисунок 11.6 – Полученная сеть

148
Выбор статистики
Чтобы протестировать производительность сети, нужно
собрать одну из множества приемлемых статистик.
1. Щелкнуть правой кнопкой мыши в проектном окне и
выбрать из меню Choose Individual Statistics.
2. В диалоговом окне Choose Results выбрать
статистику, показанную на рисунке 11.7.
Рисунок 11.7 - Диалоговое окно Choose Results
Настройка моделирования
1. Нажать на кнопку Configure/Run Simulation .

2. Установить длительность на 30 минут.
3.Нажать кнопку Оk.
Дублирование сценария
В только что созданной сети предполагалось, что в
связях не имелось фоновых трафиков. В реальных сетях
связи они обычно существуют. Нужно создать дубликат
149
сценария SimpleNetwork, но с использованием фона в
связях 100BaseT.
ему имя BusyNetwork и нажать Оk.
2. Выбрать все связи 100Base одновременно (нажимая
на них и при этом удерживая клавишу Shift), щелкнуть
правой кнопкой мыши по любой из них, появится Edit
Attributes, а в проверочном окошке уточнить соответствие
Apply Changes и Selected Objects.
3. Раскрыть дерево атрибута Background Utilization,
раскрыть ряд 0 дерева и присвоить "99" атрибуту
background utilization (%), как это показано ниже на
Рисунок 11.8 – Фоновая загрузка

150
Запуск процесса моделирования одновременно для

двух сценариев.
1. Перейти к меню Scenarios и выбрать пункт Manage
Scenarios.
2. Изменить значения под колонкой Results на
<collect> (или recollect) для обоих сценариев. Сравнить с
рисунком 11.9.
Рисунок 11.9 – Сбор статистик
3. Нажать кнопку Оk, чтобы запустить два процесса

имитации. В зависимости от скорости используемого
процессора, это может занять несколько секунд.
4. После того, как два прогона моделирования
завершены (по одному для каждого сценария), нажать
Close.
Просмотр результатов моделирования
1. Из меню Results выбрать пункт Compare Results.
2. Поменять меню в правой нижней части диалогового
окна Compare Results с As is на time_average как
151
3. Выбрать статистику Page Response Time и нажать

кнопку Show. Результирующий график после завершения
моделирования приведен на рисунке 11.11.
152
1. В лабораторной работе даны основы проектирования,

деления на сегменты, выделение серверных сегментов и
сегментов передачи данных. Главное здесь - проведение
тестирования различных конфигураций для оптимального
выбора структуры. Этап проектирования - неотъемлемая
часть создания современной сети, без него речь о
сертификации сети даже не идет. Поэтому на этапе
моделирования сразу производят тестирование всех
характеристик разных проектов с разными условиями.
Особенно подвергается тестированию сегмент серверов,
как самый нагруженный. Все тесты прогоняются в
ненагруженном и перегруженном режимах. Моделирование
показало преимущество одного из проектов по всем
показателям, кроме стоимости.
2. Производится реальное проектирование небольшой
сети с выделенным серверным пулом. Создаются подсети,
объединенные центральным коммутатором серверного
пула. Тестирование производится в двух режимах –
ненагруженном и перегруженном (99% загрузки линий
связи). В результате время отклика страницы с сервера
возрастает с 20мс до 35мс. В дополнительных заданиях
предложено оценить процент загрузки серверов при
перегруженной сети, а также замену трех серверов одним.
Если загрузка и времена отклика будут отличаться
незначительно, то на серверах можно значительно
сэкономить.
1. Проанализируйте результат, полученный при

рассмотрении времени отклика страницы НТТР. Соберите
четыре другие статистики по своему выбору и
перезапустите сценарии сетей Simple и Busy. Получите
графики, которые сравнивают собранные статистики.
Прокомментируйте эти результаты.
2. В сценарии BusyNetwork изучите коэффициент
153
использования CPU в серверах (щелкните правой кнопкой
мыши по каждому серверу и выберите <Choose Individual
Statistics > <CPU > <Utilization>).
3. Создайте новый сценарий как дубликат сценария
BusyNetwork. Назовите новый сценарий Q3_OneServer.
Замените три сервера одним, который поддерживает все
требуемые услуги. Изучите % использования CPU этого
сервера. Сравните эту загрузку с загрузкой трех серверов,
которая была получена в предыдущем вопросе.
4. Создайте новый сценарий как дубликат сценария

BusyNetwork. Назовите новый сценарий
Q4_FasterNetwork. В сценарии Q4_FasterNetwork
замените все связи 100BaseT в сети на связи 10Gbps
Ethernet и все связи 10BaseT замените на 100BaseT.
Изучите, как увеличение полосы пропускания влияет на
производительность сети, т.е. сравните время отклика
страницы НТТР в новом сценарии с тем, что было в
BusyNetwork.
154
12 ПАКЕТНО – КОММУТИРОВАННАЯ
ТЕХНОЛОГИЯ АТМ
Целью лабораторной работы является изучение

воздействия уровней адаптации АТМ и классов услуг на
производительность сети.
Режим асинхронной передачи (Asynchronous Transfer
Mode – ATM) – это ориентированная на соединения
пакетно-коммутированная технология. Пакеты, которые
коммутируются в АТМ сети, имеют фиксированную длину
в 53 байта и называются сотами. Размер соты оказывает
влияние на производительность голосового трафика.
Уровень адаптации АТМ (AAL) находится между АТМ и
протоколами пакетов различной длины, такими, как IP и
которые могут использовать АТМ. Заголовок AAL
содержит информацию, нужную для места назначения,
чтобы восстановить исходное сообщение из сот. Так как
технология АТМ была спроектирована для поддержки всех
видов услуг, включая голос, видео и данные, различные
услуги будут иметь различные уровни AAL. Уровни AAL1
и AAL2 были спроектированы для поддержки приложений
типа голоса, а - AAL3/4 и AAL5 осуществляют поддержку
пакетов данных, следующих через АТМ.
АТМ предоставляет QoS возможности с помощью 5
классов услуг: CBR, VBR-rt, VBR-nrt, ABR и UBR. С
помощью CBR (constant bit rate) источник передает трафик
на фиксированной скорости. Класс CBR хорошо
приспособлен к голосовому трафику, который обычно
требует цепной коммутации. Таким образом CBR является
очень важным для телефонных компаний. Класс UBR
(unspecified bit rate) является наилучшей услугой АТМ.
Существует небольшое отличие между UBR и best-effort
моделью. Так как АТМ всегда требует фазу установления
соединения перед тем, как данные посылаются, то UBR
позволяет источнику устанавливать максимальную
скорость, с которой данные будут передаваться.
Коммутаторы могут воспользоваться этой информацией,
155
чтобы решить, принять или отвергнуть новую виртуальную
сеть.
В этой лабораторной работе нужно установить АТМ
сеть, которая имеет три приложения: Voice, Email, FTP и
изучить, как выбирать уровень адаптации и класс услуг.
1. Запустить OPNET IT Guru Academic Edition и из

меню File выбрать пункт New.
2. Выбрать Project и нажать кнопку Оk.
3. В диалоговом окне Startup Wizard: Initial Topology
убедиться, что выбран Create Empty Scenario. Нажать
Next, из списка Network Scale выбрать Choose From Maps
и опять нажать Next . Из карт выбрать USA и нажать Next,
а в списке Select Technologies включить atm_advanced
Model Family, как это показано на рисунке 12.1. Затем
нажать кнопки Next и Оk.
Рисунок 12.1 - Диалоговое окно Startup Wizard
1. Диалоговое окно Object Palette должно быть наверху

проектного окна. Если его там нет, то необходимо открыть
его, нажав . Убедиться, что из меню в базе ресурсов
выбран atm_advanced.
2. Добавить к проектному рабочему пространству
следующие объекты из базы: Application Config, Profile
156
Config, 2 atm8_crossconn_adv коммутатора и subnet.
3. Для того, чтобы добавить объект из базы, нужно
нажать на его изображение в базе рисунков, переместить
мышь на рабочее пространство и нажать на нее, чтобы
разместить объект, затем щелкнуть правой кнопкой мыши,
чтобы выйти из режима создания объекта.
4.Закрыть диалоговое окно Object Palette,
переименовать объекты (щелкнув правой кнопкой мыши
по узлу Set Name), которые были добавлены, как это
показано ниже, на рисунке 12.2 и сохранить проект.
Рисунок 12.2 – Сеть
Настройка приложения
Applications, появится окно Edit Attributes, расширить
атрибут Application Definitions и установить число рядов
на 3, а затем поименовать ряды: FTP, Email и Voice.
2. Перейти на ряд FTP, раскрыть дерево Description и
присвоить FTP значение High Load.
3. Перейти на ряд Email, раскрыть дерево Description
и присвоить E-mail значение High Load.
157
4. Перейти на ряд Voice, раскрыть дерево Description и
присвоить Voice значение PCM Quality Speech (рисунок
12.3).
5. Нажать кнопку Оk и сохранить проект.
Настройка профилей
1. Щелкнуть правой кнопкой мыши по узлу Profiles,

появится окно Edit Attributes, расширить атрибут Profile
Configuration и установить число рядов 3.
2. Назвать и установить атрибуты ряда 0, как это
158
Рисунок 12.4 – Настройка профиля FTP

Рисунок 12.5 - Настройка профиля E-mail
159
Замечание. Для того, чтобы установить
продолжительность Duration на Exponential(60), нужно
присвоить “Not Used” атрибуту “Special Values”) и
закрыть диалоговое окно Object Palette.
Рисунок 12.6 - Настройка профиля Voice
Настройка подсети NorthEast

1. Дважды щелкнуть по узлу подсети Northeast.
Получится пустое рабочее пространство, означающее,
что подсеть не содержит никаких объектов.
2. Открыть базу ресурсов и убедиться, что из меню
выбран atm_advanced.
3. Добавить следующие пункты к рабочему
пространству подсети: один atm8_crossconn_adv
коммутатор, один atm_uni_server_adv,
4atm_uni_client_adv и соединить их при помощи
160
двухсторонних связей atm_adv. Закрыть базу и
переименовать объекты, как показано на рисунке 12.7.
4. Изменить атрибут data rate на DS1.
Рисунок 12.7 - Подсеть Northeast
5. Как для NE_Voice1, так и для NE_Voice2, установить

следующие атрибуты:
- установить ATM Application Parameters только на
CBR;
- раскрыть дерево ATM Parameters и установить
Queue Configuration только на CMR;
- раскрыть дерево Application: Supported Profiles,
установить число рядов на 1, раскрыть дерево row 0
и установить Profile Name на Voice_P;
- установить Application: Supported Services,
отредактировать его значение, установить rows на 1,
установить Name добавленного ряда на Voice и
нажать кнопку Оk;
-раскрыть дерево Application: Transport Protocol >
Voice Transport = AAl2.
6. Для NE_Voice1 выбрать Edit Attributes,
отредактировать значение атрибута Client Address и
записать NE_Voice1.
7. Для NE_Voice2 выбрать Edit Attributes,
записать NE_Voice2.
161
8. Настроить NE_Data Server следующим образом:
- раскрыть дерево Application: Supported Services,
отредактировать его значение, установить rows на 2,
установить Name добавленных рядов на EMAIL и
ftp и нажать Оk;
- раскрыть дерево Application: Transport Protocol
Specification > Voice Transport = AAL2;
- отредактировать значение атрибута Server Address
и записать NE_DataServer.
9. Для NE_Data1 и NE_Data2 установить следующие
атрибуты:
- раскрыть дерево ATM Parameters и установить
Queue Configuration на UBR;
- раскрыть дерево Application: Supported Profiles,
установить rows на 2, установить Profile Name на FTP
(для ряда 0) и на EMAIL_P (для ряда 1).
10. Для NE_Data1 выбрать Edit Attributes,
записать NE_Data1.
11. Для NE_Data2 выбрать Edit attributes,
записать NE_Data2.
Добавление подсетей
1. Вернуться в окно проекта, нажав на кнопку Go to
the higher level.
Подсети других регионов должны быть похожими на
NorthEast, за исключением имен и адресов клиентов.
2. Сделать три копии только что созданной подсети.
3. Переименовать подсети (щелкнув правой кнопкой
мыши по узлу Set Name) и подсоединить их к
коммутаторам при помощи связей atm_adv, как это
4. Изменить data rate для всех связей на DS1.
5. Выбрать и дважды щелкнуть по каждой из новых
подсетей и изменить names, client address и server address
162
узлов внутри подсетей (например, заменить NE на SW для
подсети SouthWest).
Рисунок 12.8 – Соединенная сеть
6. Для всех голосовых станций во всех подсетях (всего

их восемь) отредактировать значение атрибута Application:
Destination Preferences следующим образом:
- установить rows на 1;
- установить Symbolic Name для Voice Destination;
- нажать на (…) под колонкой Actual Name;
-установить rows на 6 и для каждого ряда выбрать
голосовую станцию, которая не находится в текущей
подсети.
Рисунок 12.9 показывает действительные имена для
одной из голосовых станций в подсети NorthEast.
7. Для всех станций данных во всех подсетях (всего их
восемь) сконфигурировать атрибут Application:
Destination Preferences.
163
Для этого выполнить:

- установить Symbolic Name серверу FTP Server для
одного ряда и Email Server для другого ряда;
- для каждого символического имени нажать на (…)
под колонкой Actual Name;
- установить rows на 3 и для каждого ряда выбрать
сервер данных, который не находится в текущей
подсети. Рисунок 12.10 показывает действительные
имена для одной из станций данных подсети
NorthEast.
Рисунок 12.10 – Настройка серверов
164
8. Все коммутаторы в сети (всего их шесть) настроить
так, чтобы Max_Avail_BW очередь СBR была 100%, как
показано ниже на рисунке 12.11, а Min_Guaran_BW была
20%.
9. Выбор результатов моделирования показан на рисунке 12.12.
Рисунок 12.11 – Настройка коммутаторов
165
Рисунок 12.12 – Выбор статистик
1. Нажать на кнопку Configure/Run Simulation.
2. Установить длительность на 10 минут.
3. Нажать Оk. Прогон моделей будет проведен позже.
В только что созданной сети использовались услуги
класса CBR для приложения Voice и услуги класса UBR
для приложений FTP и Email. Чтобы проанализировать
эффект таких различных классов услуг, нужно создать
другой сценарий, который похож на только что созданный
CBR_UBR сценарий, но который использует только один
класс услуг UBR для всех приложений. В дополнение,
чтобы протестировать влияние уровня адаптации АТМ, в
новом сценарии будет использоваться AAL5 для
приложения Voice вместо AAL2. Для этого нужно
выполнить ниже перечисленные действия.
ему имя UBR_UBR и нажать кнопку Оk.
166
2. Все голосовые станции во всех подсетях
перенастроить следующим образом:
- установить ATM Application Parameters только на
UBR;
- выбрать ATM Parameters;
- установить Queue Configuration на UBR;
- выбрать Application: Transport Protocol;
- установить Voice Transport на AAL5.
Замечание. Для выполнения шага 2 можно
воспользоваться браузером сети следующим образом:
- из меню View выбрать Show Network Browser;
- из меню выбрать Nodes и сравнить смотровое
окошко Only Selected, как это показано на рисунке 12.13;
- записать voice в соответствующем поле и нажать
Enter.
- в браузере сети должен быть виден список
выбранных голосовых станций;
- щелкнуть правой кнопкой мыши по любой
голосовой станции из списка, выбрать Edit Attributes и
сравнить Apply Changes с Selected Objects;
Рисунок 12.13 – Браузер сети

167
- выполнить изменения настроек шага 2;
- чтобы спрятать браузер сети, удалить Show Network
Browser из меню View.
12.3 Одновременное моделирование сценариев
Чтобы запустить моделирование для обоих сценариев

одновременно, нужно выполнить последовательность
действий.
1. Перейти в меню Scenarios и выбрать Manage
Scenarios.
<collect> (или recollect) для обоих сценариев.
Рисунок 12.14 – Выбор статистик
3. Нажать кнопку Оk, чтобы запустить два сценария. В

зависимости от скорости используемого процессора это
может занять несколько минут.
4. После того, как два прогона процесса
моделирования завершены, нажать Close.
1. Из меню Results выбрать пункт Compare Results.
2. В правом нижнем углу диалогового окна Compare
Results изменить меню с As is на time_average, как это
168
3. Выбрать голосовую статистику Packet Delay

Variation и нажать кнопку Show. Результирующий график
должен напоминать рисунок 12.16.
169
1. Эта лабораторная работа посвящена технологии

ATM, которая широко используется в магистральных
каналах из-за высокой нагрузочной способности. В работе
спроектирована мультисервисная сеть с поддержкой
голосовых и цифровых услуг. Показаны все этапы
проектирования такой сети, основные параметры ATM,
проведено моделирование работы голосовых и цифровых
услуг.
2. Проведено моделирование сети ATM с
мультисервисным обслуживанием. Голосовой трафик, FTP
и e-mail нагружают каналы связи ATM с разными
параметрами (скорость, QoS). Самый критичный к качеству
трафик – голосовой. Основной показатель качества для
этого трафика – задержки и «джиттер» (колебание значения
задержки). Поэтому исследовалась задержка для
голосового трафика при разных параметрах канала ATM.
Разные значения политики QoS в очередях ATM, такие
как услуги CBR и UBR, позволяют по разному
распределять приоритеты в очереди для обеспечения
качества, минимальных задержек, соблюдения требуемой
полосы пропускания и резервирования канала. Класс CBR
хорош для голосового трафика, но резервирует часть
пропускной способности канала. Он предоставляет
постоянную полосу пропускания под голос. Класс UBR же
не резервирует постоянно канал, он только расставляет
приоритеты в очереди для голоса.
3. Сравнение двух политик показало, что UBR
показывает джиттер от 5мкс до 100мкс, тогда как CBR
показывал значение 5мкс на всей протяженности
испытания.
1. Проанализируйте полученный результат в отношении

времени Packet Delay Variation. Получите графики,
которые сравнивают задержку пакета Voice и времена
откликов загрузки E-mail и FTP для обоих сценариев.
170
Прокомментируйте результаты.
2. Создайте другой сценарий как дубликат сценария
CBR_UBR. Назовите новый сценарий Q2_CBR_ABR. В
новом сценарии нужно использовать ABR класс услуг для
данных, т.е. для FTP и E-mail приложений в станциях
данных. Сравните производительность сценария CBR_ABR
с производительностью СBR_UBR.
3. Отредактируйте приложение FTP, определенное в
узле Applications так, что его File Size вдвое больше
текущего размера (т.е. 100000 байт вместо 50000 байт).
Отредактируйте приложение E-mail, определенное в узле
Applications так, что его File Size в пять раз больше своего
текущего размера (т.е. 10000 байт вместо 2000 байт).
Изучите, как это отразится на производительности
приложения Voice как для сценария CBR_UBR, так и для
UBR_UBR.
171
13 МОДЕЛИРОВАНИЕ ПРОТОКОЛА КОНТРОЛЯ
ПЕРЕДАЧИ TCP
Цель лабораторной работы заключается в

демонстрации алгоритмов контроля перегрузок,
предоставляемые протоколом контроля передачи
Transmission Control Protocol (ТСР) и сравнении их
производительности. Лабораторная работа содержит
большое число сценариев для моделирования этих
алгоритмов и предоставляет возможность сравнения их
производительности.
Протокол ТСР в Интернете гарантирует надежную
доставку потока байтов в нужном порядке. Он включает
механизм текущего контроля для потока байтов, который
позволяет приемнику ввести ограничение, сколько данных
передатчик может передать в данное время. В дополнение,
ТСР предоставляет высокоточный настроенный механизм
контроля перегрузки. Суть этого механизма в том, чтобы
ограничивать скорость пересылки данных с помощью ТСР
для того, чтобы посылающая сторона не перегружала сеть.
Проблема контроля перегрузки ТСР для каждого
источника заключается в том, чтобы определить, какая
пропускная способность доступна в сети, т.е. сколько
пакетов она может безопасно передавать. Протокол задает
параметр, разный для каждого соединения, и который
называется «окном перегрузки». Последнее используется в
качестве источника для ограничения количества данных,
которое разрешается передавать в данное время. Протокол
TCP использует механизм, называемый «аддитивное
увеличение/мультипликативное уменьшение», который
уменьшает окно перегрузки, когда уровень перегрузки
растет, и увеличивает, когда уровень перегрузки падает.
Протокол ТСР интерпретирует «слишком большое» время
доставки как показатель перегрузки. Каждый раз, когда
происходит таймаут, источник устанавливает окно
перегрузки на половину его предыдущего значения. Это
деление пополам относится к части механизма,
172
называемого «мультипликативное уменьшение». Окно
перегрузки не может быть меньше, чем один пакет.
Каждый раз, когда источник успешно посылает окно
перегрузки величиной в несколько пакетов, к окну
перегрузки добавляется один, это - часть механизма под
названием «аддитивное увеличение».
ТСР использует механизм, называемый «медленный
старт», чтобы «быстро» увеличить окно перегрузки с
холодного старта в соединениях протокола. Он
увеличивает окно перегрузки скорее по экспоненте, нежели
линейно. И, наконец, протокол ТСР использует механизм,
называемый «быстрая повторная передача и быстрое
восстановление».
В этой лабораторной работе будет установлена сеть,
которая использует ТСР как протокол передачи от начала
до конца, и будет проведен анализ размера окна
перегрузки при помощи различных механизмов.

1. Запустить программу OPNET IT Guru Academic
Edition > и из меню File выбрать пункт New.
2. Выбрать Project , нажать Оk, назвать проект
<инициалы>_TCP, а сценарий No_Drop и нажать кнопку
Оk.
3. В режиме Startup Wizard: диалоговое окно Initial
Topology, убедиться, что выбран пункт Create Empty
Scenario. Нажать New из списка Network Scale и выбрать
Choose From Maps. После нажать кнопку Next , из списка
Мар выбрать USA, дважды нажать Next и нажать Оk.
Создание, настройка и инициализация сети

1.Диалоговое окно Object Palette должно быть наверху
проектного пространства. Его можно открыть, нажав .
Необходимо убедиться, что из меню на объектной палитре
(базе ресурсов) выбран пункт internet_toolbox.
173
2. Добавить к проектному рабочему пространству
следующие объекты из палитры: Application Config,
Profile Config, ip32_Cloud и две подсети.
Чтобы добавить объект из палитры, нужно нажать на
его изображение на палитре объектов, передвинуть мышь
на рабочее пространство и щелкнуть, чтобы поместить
объект в желаемое место. Затем щелкнуть правой кнопкой
мыши, чтобы завершить создание объектов этого типа.
3. Закрыть палитру.
4. Переименовать добавленные объекты, как показано
на рисунке 13.1, и затем сохранить проект.
Рисунок 13.1 – Исходная сеть
Настройка приложения
Applications, появится окно Edit Attributes и расширить
атрибут Application Definition. Установить rows на 1,
расширить новый ряд и назвать ряд FTP_Application.
После этого раскрыть дерево Description, отредактировать
ряд FTP, как это показано на рисунке13.2.
2. Дважды нажать кнопку Оk и сохранить проект.
174
Настройка профилей
1. Щелкнуть правой кнопкой мыши по узлу Profiles,
появится окно Edit Attributes, расширить атрибут Profile
Configuration и установить rows на 1.
2. Назвать и установить атрибуты ряда 0, как показано
на рисунке 13.3, нажать кнопку Оk.
Рисунок 13.3 – Настройка FTP

175
Настройка подсети West
1. Щелкнуть дважды по узлу подсети West.
Полученное пустое рабочее пространство указывает на то,
что в подсети не имеется никаких объектов.
2. Открыть палитру объектов и убедиться, что из
меню выбран пункт internet_toolbox.
3. К рабочему пространству подсети добавить
следующие объекты: один ethernet_server, один
маршрутизатор ethernet4_slip8_gtwy и подсоединить их к
связи 100 BaseT, закрыть палитру и переименовать
объекты, как это показано на рисунке 13.4.
Рисунок 13.4 – Сеть West

Server_West > Edit Attributes:
- отредактировать Applications: Supported Services,
установить rows на 1, установить Name на FTP_Applicftion
и нажать кнопку Ok;
- отредактировать значение атрибута Server Address и
записать Server_West;
- раскрыть дерево TCP Parameters, установить Fast
Retransmit и Fast Recovery на Disabled.
5. Нажать Оk и сохранить проект.
Замечание. Для того, чтобы вернуться к более высокому
уровню проекта, нужно нажать на кнопку Go to next higher
level .
Настройка подсети East

1. Щелкнуть дважды по узлу подсети East.
2. Открыть палитру объектов и убедиться, что из
меню выбран пункт internet_toolbox.
3. К рабочему пространству подсети добавить
следующие объекты: один ethernet_wkstn, один
176
маршрутизатор ethernet4_slip8_gtwy и подсоединить их к
связи 100BaseT. Затем закрыть палитру и переименовать
объекты, как это показано на рисунке 13.5.
Рисунок 13.5 – Сеть East
4. Щелкнуть правой кнопкой мыши по узлу Client_East

> Edit Attributes.
5. Расширить Application: выбрать иерархию
Supported Profiles, установить rows на 1, раскрыть
дерево row 0 и установить Profile Name на
FTP_Profile.
6. Присвоить атрибутам Client Address значение
Client_East.
7. Отредактировать Application: атрибут Destination
Preferences следующим образом:
- установить Symbolic Name для FTP Server;
- отредактировать Actual Name;
- в новом ряду присвоить колонке Name имя
Server_West.
8. Три раза нажать кнопку Оk и затем сохранить
проект.
9. Чтобы вернуться в окно проекта, необходимо нажать
на кнопку Go to next higher level.
Соединение подсети с IP облаком

1. Открыть палитру объектов .
2. Используя две связи по двум направлениям типа
PPP_DS3, подсоединить подсети East и West к IP
облаку.
3. Появится всплывающее диалоговое окно, в котором
нужно указать, что использовать для подсоединения
177
подсети к IP облаку. Необходимо выбрать
«маршрутизаторы» <routers>.
4. Закрыть палитру, после чего будет получена
результирующая сеть (рисунок 13.6).
Рисунок 13.6 - Результирующая сеть
Выбор статистики
1. Щелкнуть правой кнопкой мыши по Server_West в
подсети West и из всплывающего меню выбрать Choose
Individual Statistics.
2. В диалоговом окне Choose Results выбрать
статистику TCP Connection > Congestion Window Size
(bytes) и Sent Segment Sequence Number.
3. Щелкнуть правой кнопкой мыши по статистике
Congestion Window Size (bytes), выбрать Change
Collection Mode, в диалоговом окне проверить Advanced, а
в ниспадающем меню присвоить все значения режиму
Capture, как это показано на рисунке 13.7 и нажать Оk.
4. Щелкнуть правой кнопкой мыши по статистике Sent
Segment Sequence Number, выбрать режим Change
Collection Mode, в диалоговом окне проверить Advanced
и в ниспадающем меню присвоить все значения режиму
Capture.
5. Дважды нажать Оk и сохранить проект.
6. Нажать на кнопку Go to next higher level .
178
Рисунок 13.7 - Выбор статистики
1. Нажать на , после чего появится окно Configure
Simulation.
5. Установить продолжительность моделирования на
10.0 минут.
Дублирование сценария
Только что созданная сеть является «совершенной»
сетью без отброшенных пакетов. Оставлялись в стороне
методики быстрой повторной передачи и быстрого
восстановления в ТСР. Чтобы проанализировать эффекты
от отброшенных пакетов и этих методик контроля
перегрузки, нужно создать два дополнительных сценария.
ему имя Drop_NoFast и нажать Оk.
2. В новом сценарии щелкнуть правой кнопкой мыши
по пункту IP Cloud > Edit Attributes и присвоить
атрибуту Packet Discard Ratio значение 0.05%.
4. В сценарии Drop_NoFast из меню Scenarios выбрать
Duplicate Scenario и дать ему имя Drop_Fast.
179
5. В сценарии Drop_Fast щелкнуть правой кнопкой
мыши по Server_West, который находится внутри подсети
West > Edit Attributes, раскрыть дерево TCP Parameters,
запустить атрибут Fast Retransmit и атрибуту Fast
Recovery присвоить значение Reno.
6. Нажать кнопку Оk и сохранить проект.
13.3 Одновременное моделирование сценариев
Чтобы запустить моделирование для трех сценариев

одновременно, нужно выполнить ниже перечисленные
действия.
1. Перейти в меню Scenarios и выбрать Manage
Scenarios.
<collect> (или recollect) для трех сценариев. Полученный
результат сравнить с рисунком 13.8 .
3. Нажать Оk, чтобы запустить три прогона имитации.

4. После завершения трех прогонов имитации (по
одному на каждый сценарий) нажать Close и сохранить
проект.
1. Подключиться к сценарию Drop_NoFast и из меню
Results выбрать View Results.
180
2. Полностью раскрыть дерево Object Statistics и
выбрать следующие два результата: Congestion Window
Size (bytes) и Sent Segment Sequence Number (рисунок
13.9).
Рисунок 13.9 – Выбор статистики
3. Нажать кнопку Show. Результирующие графики

приведены ниже на рисунке 13.10.
Рисунок 13.10 - Результирующие графики

181
4. Чтобы изменить масштаб на деталях графиков,
нужно щелкнуть и провести мышью так, чтобы образовать
прямоугольник, как это показано выше.
5. График должен выглядеть так, как это показано на
6. Segment Sequence Number является почти плоским
при каждом скачке в окне перегрузки.
7. Закрыть диалоговое окно View Results и выбрать
Compare Results из меню Result.
8. Полностью раскрыть дерево Object Statistics, как
это показано на рисунке 13.12 и выбрать следующий
результат: Sent Segment Sequence Number.
Рисунок 13.11 – Масштабированные графики
9. Нажать Show. После изменения масштаба

результирующий график должен выглядеть так, как
182
Рисунок 13.13 - Результирующие графики
1. Лабораторная работа рассматривает основные аспекты

функций транспортного уровня и много вариантов работы,
позволяют подробно изучить методы контроля потока,
183
надежной передачи данных, производительности
протокола. К тому же в работе используются
маршрутизаторы, выделенные IP сети, тонкая настройка
протокола TCP, что несомненно является очень
распространенной задачей на сегодняшний день.
Моделирование показало преимущество влияния некоторых
параметров TCP на качество сети.
2. Анализировалась работа протокола TCP в реальных
условиях (связь через IP-облако Интернет) с разными
параметрами. Три сценария сравнивали поведение
протокола с разными значениями параметров
динамического окна, выборочной передачи потерянных
пакетов и с разным процентом потерянных пакетов.
В сценарии с теряющимися пакетами изучено поведения
окна TCP. Сначала при передаче около минуты
вычисляется требуемый размер окна, и в это время окно не
используется. Затем окно начинает увеличиваться до тех
пор, пока не начинают массово теряться пакеты. Тогда
окно перегрузки начинает сбрасываться до
первоначального значения в 1 сегмент. После повторной
передачи потерявшихся пакетов окно снова начинает рост,
но уже медленнее. От окна напрямую зависит скорость
передачи данных, то есть количества пакетов. В работе это
выражается в росте порядкового номера передаваемого
сегмента. Когда окно сбрасывается, рост порядковых
номеров снижается до минимума, то есть количество
переданных пакетов уменьшается. Затем снова начинает
расти, до следующего сброса.
Средний размер окна TCP 50кбайт, окно сбрасывается,
примерно, каждые 5-9 секунд. Однако третий сценарий
предлагает новое средство TCP – Fast Retransmit –
технологию выборочной передачи потерянных пакетов. С
этой технологией окно лишь немного уменьшает свой
размер, скорость передачи падает несущественно.
184
1. Почему Segment Sequence Number остается

неизменным при скачках в окне перегрузки?
2. Проанализируйте график, который сравнивает числа
Segment Sequence трех сценариев. Почему сценарий
Drop_NoFast имеет самый медленный рост в
последовательностях чисел?
3. В сценарии Drop_NoFast примените лежащий сверху
график, который сравнивает Sent Segment Sequence
Number с Received Segment ACK Number для
Server_West. Объясните график.
Подсказка:
- обязательно присвойте все значения режиму Capture
статистики Received Segment ACK Number.
4. Создайте другой сценарий в качестве дубликата
сценария Drop_Fast. Назовите новый сценарий
Q4_Drop_Fast_Buffer. В новом сценарии отредактируйте
атрибуты узла Client_East и присвойте атрибуту Receiver
Buffer (байт) значение 65535. Создайте график, который
показывает, какому воздействию подвергается Congestion
Window Size (bytes) сервера Server_West при увеличении
в приемном буфере (сравните график размера окна
переполнения из сценария Q4_Drop_Fast с
соответствующим графиком из сценария Drop_Fast).
185
14 ПРОЕКТИРОВАНИЕ И МОДЕЛИРОВАНИЕ
СЕТЕЙ КАФЕДРЫ ВУЗа И КАМПУСА

Цель лабораторной работы состоит в создании
имитационных моделей сетей кафедры и кампуса и
проведении экспериментов на них для получения
показателей производительности и информации об узких
местах.
Программная система OPNET Modeler предоставляет
широкие возможности моделирования вычислительной
сети, представленной в графическом виде, что является
одним из основных преимуществ, так как пользователь
имеет возможность видеть как всю сеть в целом, так и при
необходимости отдельные ее участки.
В результате моделирования пользователю
предоставляется информация о узких местах сети ( по
пропускной способности, загрузке устройства или линии
связи), трафике между заданными узлами, задержки между
узлами сети и др. С использованием базы ресурсов (Object
Palette), представленной на рисунке 14.1, построена
имитационная модель сети кафедры (рисунок 14.2).
Рисунок 14.1 – Выбор устройств\линий связи по

типу\производителю
186
Рисунок 14.2 – Схема сети кафедры
187
База ресурсов представляет собой набор моделей

устройств различных производителей сетевого
оборудования, таких как 3Com, CISCO и других
(концентраторы, коммутаторы, маршрутизаторы, мосты и
др.), а также технологий Ethernet, FDDI, Token Ring, STP,
ATM, Frame Relay, VLAN, xDSL, Wireless LAN.
Модель сети кафедры состоит из сервера, 30 рабочих
станций, 6 коммутаторов и концентратора. В базе ресурсов
также имеются наиболее распространенные и известные
протоколы: IP, TCP и протоколы маршрутизации RIP,
OSPF, BGP, EIGRP,IGRP, IS-IS. Также имеется
возможность моделировать линии связи, такие как
10BaseT, 100BaseT, 1000BaseX, Frame Relay (T1,E1,T3),
PPP путем указания их пропускной способности и
задержки распространения. Каждый ресурс имеет
специфические для конкретного класса характеристики,
которые включены в базу ресурсов. Так, например, для
рабочей станции можно задать типы выполняемых
приложений (Email, FTP, HTTP, Print, Database, Remote
Login, Video Conference, Voice), причем не один, а
несколько, производительность, время работы и т.д.
(рисунки 14.3-14.5).
Рисунок 14.3 – Выбор приложений и параметров
188
189
Рисунок 14.5 – Выбор приложений на конкретной
рабочей станции
Используемое приложение можно выбрать из уже

готового набора приложений либо, задав соответствующие
характеристики, создать требуемый нестандартный тип
приложений. Для коммутатора можно задать количество
портов, временные задержки и производительность. Для
каждого приложения необходимо указать сервер, который
выполнял бы соответствующие запросы. В данном случае
один сервер выполняет все запросы приложений. На
рисунке 14.6 представлен выбор приложений,
реализуемых на сервере кафедры.
190
Рисунок 14.6 – Выбор приложений на сервере
В связи с тем, что все процессы функционирования сети

относятся к стохастическим, то для моделирования
необходимо указать законы распределений, сценарии
моделирования, согласно которым генерируются заявки в
сети. В данном случае рассматриваются два закона:
нормальный и пуассоновский.
Для получения результатов, до начала моделирования,
необходимо определиться с теми параметрами, сведения о
которых мы хотим получить в результате моделирования.
Эти параметры можно задать для всей сети, для отдельной
рабочей станции или коммутационного оборудования.
Можно проследить трафик от одного объекта до другого.
Так же необходимо задать время моделирования: 1 час, 1
рабочая смена, 2 рабочие смены и т.д. Моделирование
требует очень больших ресурсов ПК, например, симуляция
одного часа работы занимает на ПК Celeron 1.7 380 Мб
ОЗУ около 20 минут. На рисунке 14.7 представлено окно
выбора параметров, таких как время моделирования,
параметры приложений и др.
191
Рисунок 14.7 – Настройка параметров моделирования
На рисунке 14.8 представлено первое окно результатов

моделирования, где отображается скорость возникновения
событий.
Рисунок 14.8 – Окно моделирования сети

192
Имеется возможность посмотреть требуемые
результаты моделирования, такие как загрузка устройств,
линий связи, количество принятых\отправленных бит
коммутатором, сервером и т.п. (рисунки 14.9 - 14.11).
По показанным графикам предоставляется возможность
рассчитывать загрузку ресурсов, задержки пакетов и
другие характеристики сети.
Рисунок 14.9 – Количество принятых бит коммутатором
193
Рисунок 14.10- Количество байт, принятых рабочей
станцией
Рисунок 14.11 – Количество принятых байт сервером
194
14.4 Модель сети кафедры ВТ
Логическая схема
Локальную вычислительную сеть кафедры ВТ было
решено представить в виде 5-ти подсетей (каждая подсеть
представляет собой компьютерный класс) и одного сервера
(рисунок 14.12). Это сделано в связи с имеющимися
ограничениями в академической версии IT Guru (в сети не
должно быть более 20 объектов). В качестве подсети
используется стандартный объект 100BaseT_LAN,
представляющий собой сеть Fast Ethernet коммутируемой
топологии (Fast Ethernet LAN in a switched topology).
Количество клиентов в сети произвольно, все ПК
обслуживает один сервер. Клиентский трафик направляется
как вовнутрь подсети так и на внешние сервера.
Поддерживаются следующие виды приложений: FTP,
Email, Database, Custom, Rlogin, Video, X windows, HTTP
по TCP или UDP. Количество рабочих станций в подсети
10 по умолчанию.
Сервер предоставляет возможность работы приложений
как по протоколу TCP, так и по UDP. Подключение может
быть 10, 100 и 1000 Мбит и определяется пропускной
способностью подключенного канала связи.
У коммутаторов имеется возможность подключать до 16
Ethernet интерфейсов. Алгоритм связывающего дерева
(Spanning Tree algorithm) используется для обеспечения
топологии без колец. Коммутаторы взаимодействуют
между собой путем посылки BPDU (Bridge Protocol Data
Units) пакетов. Коммутатор может объединять сети только
одного типа (Ethernet - Ethernet, FDDI - FDDI, or Token
Ring - Token Ring).
Структура трафика - Mesh (топология, когда все
элементы напрямую соединены друг с другом) (Рисунок
14.13).
195
Рисунок 14.12 - Локальная вычислительная сеть
кафедры ВТ
Рисунок 14.13 - Структура трафика
196
14.5 Анализ трафика сети
Для адекватного решения задачи анализа
производительности компьютерных сетей в первую очередь
необходима информация о сетевом трафике. Кроме
решения этой задачи, она нужна также и по другим
причинам. Это и аспекты безопасности, поиск узких мест
для оптимизации структуры сети, отладка работы сети,
контроль входящего/исходящего трафика для оптимизации
работы разделяемого подключения к сети Интернет др.
Знание и прогнозирование характеристик потоков важно
также для оптимального или близкого к нему управления
ими в сетях.
При помощи бесплатной демоверсии программы NetFlow
Analyzer был собран трафик в пакетах за периоды - день,
неделя, месяц для его анализа. Один из таких трафиков по
типам протоколов сети кафедры ВТ приведен на рис.14.14.
Рисунок 14.14 – Трафик сети кафедры по протоколам
Из рис. 14.14 следует, что почти 90% (88%) от всего

трафика, поступающего на сервер, составляет внешний
трафик, а 97% трафика сети составляют пакеты,
инициированные протоколами HTTP, FTP и NetBIOS.
Ниже на рис. 14.15 приведен агрегированный трафик
197
сети кафедры в пакетах в минуту за один рабочий день, т.е.
исходный трафик как случайный процесс задан с
поминутной дискретизацией.
Рисунок 14.15 – Агрегированный трафик сети
По собранному трафику с поминутной дискретизацией

(рис.14.15) определяем максимальную интенсивность
поступления пакетов от маршрутизатора к серверу, равную
203 пакета/с (12153/60), где средняя длина пакета – 763
байта. Наружу, т.е. от сервера к маршрутизатору поступает
по максимуму 112 пакетов/с (6744/60).
14.6 Моделирование сети кафедры в системе Opnet

Modeler
Для моделирования данной сети в пакете Opnet

Modeler, задаем в модели сети кафедры (см. рис. 14.12)
полученные выше интенсивности 203 и 112 пак/с трафика в
198
соответствующих направлениях, от маршрутизатора к
серверу и наоборот (рис. 14.16 и 14.17). Длительность
моделирования укажем один рабочий день (модельное
время).
Рисунок 14.16 – Задание входящего трафика сети кафедры
Рисунок 14.17 – Задание исходящего трафика сети кафедры
Затем весь входящий и исходящий трафики делим

поровну между 3-мя подсетями. Это связано с тем, что
количество рабочих станций в классах одинаково, и
получаем интенсивность на входе каждой подсети 67 пак/с,
199
а на выходе - 37 пак/с. Зададим эти значения
интенсивностей трафика в соответствующих направлениях
для всех трех подсетей, как это показано на рис.14.16 и
14.17 для первой подсети.
Очевидно, что здесь мы явно учитываем идентичность
подсетей. Однако в других случаях необходимо учитывать
реальное количество рабочих станций в подсетях и входящий
трафик делить пропорционально их количеству в каждой подсети.
Рисунок 14.18 – Задание входящего трафика в подсети
Рисунок 14.19 – Задание исходящего трафика в подсети

200
В результате прогона модели получаем следующие
данные по загрузкам каналов, как это показано на рис.
14.20.
Рисунок 14.20 – Результаты имитационного

моделирования сети кафедры в системе OPNET Modeler
Эти результаты показывают, что загрузки каналов связи

на 100 Мбит/с малы, т.к. максимальная загрузка составляет
всего 1,5%.
По-видимому, такая ситуация имеет место во всех
подобных ЛВС. Это позволяет сделать следующее
утверждение:
- такие ЛВС имеют большой запас производительности,
т.е. входящий трафик может быть увеличен в несколько
десятков раз при условии, что эта сеть работает автономно
вне связи с другими сетями;
201
- очевидно, что реальные загрузи каналов связи и
узлов, будут еще меньше, т.к. мы рассматриваем поведение
сети при максимальном значении входящего трафика;
- следовательно, существует резерв по пропускной
способности, позволяющий задействовать в сети
дополнительные сетевые приложения.
Примечание
Загрузку канала можно посмотреть, наведя указателем
мыши на каждую связь:
Рисунок 14.21 – Просмотр данных по загрузке канала

Для наглядности отображаем статистику по всем связям
следующим образом:
Выводим панель Annotation:
Используя инструменты панели
202
создаем таблицы следующего вида:
Далее рассмотрим влияние увеличения интенсивностей

входящего и исходящего трафика на загрузки каналов.
Для наглядности на рис. 14.22 приведены результаты
имитации сети при симметричном трафике: входящий и
исходящий трафики равны и составляют 2190 пакетов/с.
Рисунок 14.22 – Результаты имитационного

моделирования сети кафедры при симметричном трафике
Действительно, увеличение трафика в десять с лишним

раз приводит к такому же увеличению нагрузки на все
каналы связи сети.
203
14.7 Моделирование сети кампуса
Нами ставилась задача промоделировать компьютерную

сеть 14-го и 15-го корпусов (двух факультетов),
представляющую собой часть корпоративной сети
Оренбургского государственного университета и
проанализировать полученные результаты на предмет ее
возможной модернизации. Данная сеть состоит из 11
подсетей 2-х факультетов, главного коммутатора, сервера и
маршрутизатора, показанных на рис. 14.23.
Подсети представляют собой отдельные ЛВС кафедр и
деканатов, объединенные в общую сеть каналами связи на
100 Мбит/с. В качестве такой подсети в предыдущем
разделе рассмотрена ЛВС кафедры вычислительной
техники. Следует заметить, что все подсети в основном
отличаются друг от друга только количеством рабочих
станций.
Рисунок 14.23 – Модель сети 2-х факультетов ОГУ
204
При помощи бесплатной демоверсии программы
NetFlow Analyzer был собран трафик в пакетах за периоды
- день, неделя, месяц для всех подсетей и всей сети в целом
для его анализа. Один из таких трафиков исследуемой сети
приведен на рис. 14.24.
Рисунок 14.24 – Трафик сети факультетов в пакетах за один

день
По собранному трафику определяем максимальную

интенсивность поступления пакетов от маршрутизатора к
серверу равную 4030 пакетов/с. Наружу, т.е. от сервера к
маршрутизатору поступает по максимуму 3280 пакетов/с.
Расшифровка трафика по протоколам приведена на рис.
14.25, из которого видно, что 91% трафика составляют
данные, поступающие из Интернета (протокол HTTP).
Тогда только 9% из всех пакетов входящего трафика,
являются внутренними. Результаты анализа трафика за 3
месяца показывают, что все основные потоки проходят или
через центральный коммутатор, или в пределах одного
205
сегмента, ограниченного портом центрального
коммутатора.
Рисунок 14.25 – Структура данных во входящем трафике
Весь трафик между разрозненными пользователями не

превышает 6,5%, причем 5,1% из них – это
широковещательный трафик. Причем 84% всего трафика
проходит через центральный коммутатор к серверам
подразделений.
Для корректной подготовки исходных данных,
воспользуемся известной информацией о подсетях и их
трафике, приведенной в таблице 14.1.
206
Таблица 14.1-Информация о подсетях
Подсеть Количество Вх.трафик, Исх.трафик,
рабочих станций пак/с пак/с
ИН 37 420 340
ИСТ 40 452 375
ВТ 55 210 113
ПОВТ 73 820 654
ПИ 24 280 220
ПТРС 31 370 279
ТЭ 15 190 144
САУ 22 260 203
ТОЭ 22 260 203
Дек_ЕЕФ 12 376 310
Дек_ФИТ 10 32 599
Всего 3670 3440
Имитационное моделирование сети кампуса
Зададим полученные значения интенсивности трафика в

соответствующих направлениях, от маршрутизатора к
серверу и наоборот, как это показано на рис. 14.26.
Рисунок 14.26 – Задание входящего и исходящего трафиков

сети факультетов
Далее весь поступающий трафик распределяем между

подсетями согласно измеренным значениям
207
интенсивностей на входе и выходе каждой из них,
аналогично рис.14.26. Эти значения интенсивностей на
входе и выходе для каждой подсети приведены выше в
таблице 14.1.
После прогона модели (модельное время 46080 с),
отражающей в этом случае 10,8 часа работы реальной сети,
получаем результаты, приведенные на рис. 14.27.
Рисунок 14.27 – Результаты имитационного моделирования сети

2-х факультетов
Для большей убедительности сложим полученные

загрузки линий всех подсетей в обоих направлениях.
Сложение сверху вниз дает 24%
(2,8+3,0+1,4+5,4+1,8+2,4+1,2+1,7+1,7+2,4+0,2=24%).
В тоже время результаты эксперимента показывают
208
загрузку линии сервер - главный коммутатор в 24,1%.
Направление снизу вверх по подсетям (рис. 14.27) дает
результат
2,3+2,5+0,8+4,4+1,5+1,9+1,0+1,4+1,4+2,1+4,1=23,4%, а по
эксперименту получили 22,7%. Как видим, расхождение
составляет всего лишь доли процента.
Это расхождение связано с тем, что в данной
программной системе значения загрузки каналов выводятся
лишь с точностью до 0,1%. Сложение же многих
слагаемых, заданных с такой точностью, и может привести
к такому расхождению.
Разница в загрузках линий маршрутизатор-сервер
(26,3/21,6) и сервер-главный коммутатор (24,1/22,7)
объясняется тем, что сервер, помимо ответов на запросы
пользователей подсетей, еще и сам обменивается данными
с Интернетом. В реальной сети это может быть при
обновлении операционной системы самого сервера, а также
антивирусных программ.
Как видно из рисунка 14.27, максимальная загрузка
каналов связи составляет 26,3% (входящего канала) и
21,6% (исходящего канала), и это при пиковом значении
нагрузки. Следовательно, реальная загрузка каналов и
узлов у этой сети намного меньше и поэтому имеется также
большой запас производительности. Учитывая, что
указанная сеть двух факультетов в свою очередь является
подсетью корпоративной сети ОГУ, куда входят еще сети
остальных 13 корпусов, необходимо дополнительно
исследовать «вклад» остальных корпусов в общую
нагрузку.
Кроме того, необходимо еще проанализировать другие
показатели производительности сети. В их числе
основными являются задержки сети. Как показали
результаты моделирования при максимальном значении
интенсивности входящего трафика, этот показатель для
сети кафедры не превышает 0,1 мс (рис.14.28) и - 0,17 мс
(рис.14.29) для сети факультетов. Эти показатели в системе
OPNET Modeler получены при экспоненциальном законе
распределения интервалов между пакетами.
209
Рисунок 14.28 – Задержки Ethernet для сети кафедры
Рисунок 14.29 – Задержки Ethernet для сети факультетов
210
1. Данная лабораторная работа позволяет на реальном

примере увидеть, как происходит процесс виртуального
тестирования сети и поиск слабых мест, как смоделировать
возможные пути решения по реструктуризации сети, а
также последствия разных организационных и
эксплуатационных решений. С помощью моделирования
можно определить перегруженные каналы связи, причины
перегруза, количественные показатели требуемой
пропускной способности.
2. В работе проанализированы две сети: сеть кафедры
ВУЗа и сеть двух факультетов, занимающих два отдельных
корпуса. Последнюю сеть можно рассматривать как
полноценную сеть кампуса.
Для адекватного исследования показателей
производительности данных сетей использована программа
NetFlow Analyzer 7 для съема реального сетевого трафика.
Полученные показатели производительности: загрузки
каналов связи и задержки пакетов в сети подтверждают,
что эти сети разумно организованы. В обеих сетях имеется
большой «запас» производительности, позволяющий
добавить дополнительные приложения, а также наращивать
их ресурсы.
3. При исследовании указанных сетей имитационным
моделированием, нами явно использован метод
декомпозиции. Метод декомпозиции сети на подсети
упрощает ее исследование, а учет трафика при этом
повышает достоверность моделирования. Таким образом,
результаты моделирования вполне адекватно могут отражать
процессы функционирования реальных сетей.
211
15 ПРОЕКТИРОВАНИЕ КАБЕЛЬНОЙ СИСТЕМЫ
Будем считать, что на этапе проектирования сети тип

кабеля определен. Более того, предполагается, что тип
локальной сети (Ethernet, Fast Ethernet, FDDI или др.)
также выбран. В этом разделе рассматриваются
рекомендации по организации кабельной системы для сетей
на основе проводных соединений (витых пар и
оптоволокна). При этом учитывается преобладание в
настоящее время на практике сетей данного типа и их
заметное отличие от сетей на основе беспроводных
соединений с точки зрения особенностей организации
кабельной системы. При выборе кабеля в первую очередь
надо учитывать требуемую длину, а также защищенность
от внешних помех и уровень собственных излучений. При
большой длине сети и необходимости обеспечить
секретность передаваемых данных или высоком уровне
помех в помещении незаменим оптоволоконный кабель.
Следует отметить, что применение оптоволоконных вместо
электрических кабелей даже при достаточно комфортных
условиях позволяет существенно (на 10-50 процентов)
поднять производительность сети за счет снижения доли
искаженных информационных пакетов [5].
При проектировании кабельных систем для локальных
сетей накоплен большой опыт, на основе которого могут
быть сформулированы общие рекомендации по
организации таких систем. Более того, существуют
стандарты под общим названием "структурированные
кабельные системы (СКС)", которые особенно актуальны
для вновь создаваемых или реконструируемых
относительно больших локальных сетей на уровне
предприятия. Для сравнительно небольших локальных
сетей создание сертифицированной СКС излишне. Ниже
перечислены общие рекомендации по созданию кабельных
систем, являющиеся фактически "подмножеством" не
детализированных требований стандартов СКС.
1. Составить план размещения компьютеров и
других сетевых устройств в помещении (или помещениях).
Этот план следует рассматривать как детализацию
212
принятого ранее решения относительно размера и
структуры сети.
2. Провести анализ возможности перемещения всех
или большей части компьютеров в одно или несколько
соседних помещений. Это существенно упростит
организацию кабельной системы и исключит
необходимость использования излишних активных сетевых
устройств. Следует также принять во внимание расширение
сети в будущем, для чего предусмотреть наличие точек
подключения к сети даже в тех помещениях, где сетевые
компьютеры пока отсутствуют. План размещения не
должен быть абстрактным, не учитывающим хотя бы в
эскизном варианте ограничения, накладываемые
конкретным типом выбранной локальной сети. Так,
например, нельзя рассчитывать в сети типа 100BASE-T4
или 100BASE-TX (Fast Ethernet на витой паре) на
расстояние от абонента (сетевого компьютера или другого
сетевого устройства) до концентратора, превышающее 100
м.
3. Оценить соответствие длины кабельной системы и
ее отдельных частей (сегментов, соединений между данным
абонентом и концентратором и т.д.) требованиям
выбранной разновидности локальной сети. Для сетей
семейства Ethernet необходимо учитывать ограничения на
длины сегментов на разных типах кабелей и задержки
сигналов в кабельной системе в соответствии с правилами
модели 1 или 2. Для сетей другого типа (Token Ring, FDDI
и т.д.) действуют абсолютные ограничения на длины
отдельных участков кабельной системы. В случае, если
рассчитанная таким образом длина кабельной системы в
целом или на отдельных участках превышает предельно
допустимую или близка к ней, следует выбрать одно или
несколько из следующих решений (в порядке предпочтения
по простоте, стоимости и эффективности реализации):
- перейти к более качественному типу кабеля во всей сети
или только на критичных участках (переход от
неэкранированной витой пары к экранированной или
оптоволокну);
- использовать дополнительные репитеры или репитерные
213
концентраторы, позволяющие восстановить амплитуду и
форму сигналов, тем самым повысить длину кабельной
системы;
- применять модемы для связи данной локальной сети из
относительно близко расположенных абонентов с одним
или несколькими удаленными абонентами, если снижение
скорости передачи на данном участке (или участках)
допустимо;
- перейти к другому типу сети, имеющему меньшие
ограничения на длину кабельной системы (то есть от сетей
на витой паре к сетям на оптоволокне).
Таким образом, выбор конфигурации кабельной
системы на данном и предыдущем этапах – итерационный
процесс, который может затронуть и более ранние этапы
проектирования (вплоть до выбора типов локальной сети и
кабеля), если выбор на этих этапах был некорректным.
4. Кабельная система должна быть устойчива к
внешним электромагнитным помехам и, по возможности,
не генерировать заметные собственные излучения. В
противном случае снижается фактическая скорость работы
сети (из-за необходимости повторной передачи
искаженных помехами пакетов), а также нарушаются
требования защиты информации.
Большой уровень помех может быть вызван наличием в
помещении предприятия мощного электрического
оборудования (например, металлообрабатывающих
станков, физических установок). Он может быть также
связан с близким расположением (до 100-200 метров)
высоковольтных линий электропередачи и мощных
радиопередатчиков (радиостанций, ретрансляционных
антенн сотовой телефонии). Иногда высокий уровень помех
вызван всего лишь неправильным размещением кабеля
сети. Например, при прокладке кабеля вдоль силовых
проводов 220 вольт или вдоль рядов светильников с
лампами дневного света количество ошибок передачи резко
возрастает (кстати, последнее решение кажется многим
очень удобным, так как кабель никому не мешает).
5. Кабельная система должна быть защищена от
механических повреждений.
214
Для прокладки кабелей сети лучше всего использовать
специальные подвесные кабельные короба, настенные
кабелепроводы или фальшполы. В этом случае кабели
надежно защищены от механических воздействий. Самое
дорогое решение – это фальшпол, представляющий собой
металлические панели, установленные на подставках, и
покрывающие весь пол помещения. Зато фальшпол
позволяет легко и безопасно проложить огромное
количество проводов, что особенно ценно в научных
лабораториях, где помимо кабелей локальной сети
существует множество других проводов.
Для прокладки кабеля между комнатами или этажами
обычно пробиваются отверстия в стенах или перекрытиях.
По сравнению с прокладкой кабеля через двери комнат и
стены коридоров это позволяет существенно сократить
общую длину кабелей. Однако надо учитывать, что такое
решение усложняет любые дальнейшие изменения в
кабельной системе (замену кабелей, прокладку
дополнительных кабелей, изменение расположения
компьютеров сети и т.д.).
Кабели ни в коем случае не должны самостоятельно
удерживать свой вес, так как со временем это может
вызвать их обрыв. Их следует подвешивать на стальных
тросах, причем для эксплуатации на открытом воздухе
необходимы специально предназначенные для этого кабели
с оболочкой, устойчивой к атмосферным воздействиям. По
возможности надо использовать для соединения далеко
разнесенных зданий подземные коллекторы. Но при этом
необходимо предпринимать меры по защите кабелей от
воздействия влаги.
Следует также избегать чрезмерно малых радиусов
изгиба кабелей (особенно это важно в случае коаксиальных
и оптоволоконных кабелей), чтобы не вызвать разрушения
изоляции или обрыва центральной жилы. По этой же
причине крепежные элементы не должны чересчур
пережимать кабель. Известны случаи, когда подобные
нарушения вызывали полное прекращение связи через
недели, или даже месяцы после начала эксплуатации сети.
215
Часть из перечисленных в данном пункте мер
способствует также защите от помех и защите информации
(из-за ограничения непосредственного доступа к кабельной
системе).
6. Кабельная система должна иметь "прозрачную" и
документированно оформленную структуру. Это
необходимо как для обеспечения возможности внесения
изменений в эту структуру, так и для поиска
неисправностей.
Для объединения концов кабелей часто используются
специальные распределительные шкафы, доступ к которым
должен быть ограничен. Конечно, их применение
оправдано только в том случае, если кабелей много
(несколько десятков). Располагать распределительные
шкафы целесообразно рядом с концентраторами,
коммутаторами или маршрутизаторами. Отдельные кабели
в жгутах, располагающихся в коробах, под вторым полом и
т.д., должны быть одинаковым образом промаркированы с
помощью специальных цветных наклеек.
7. Необходимо проверить целостность кабельной
системы.
В сети на коаксиальном кабеле для этого можно было
использовать непосредственные измерения омметром
сопротивления при наличии и отсутствии согласующих
нагрузок. В более современных сетях на витой паре и
оптоволокне о целостности кабельной системы можно
судить по показаниям индикаторов, расположенных на
сетевых картах вблизи сетевых разъемов. Возможно также
использование для этой цели специальных приборов –
кабельных сканеров.
Стандарты на "Структурированные кабельные системы
(СКС)" представляют собой объемные документы, детально
описывающие и регламентирующие процесс создания
кабельных соединений локальных сетей. Изучение
стандартов СКС – предмет отдельного курса, касающегося
относительно небольшой по численности категории
специалистов (в сравнении с числом пользователей
локальных сетей). Как и в случае сетевого
администрирования, целесообразно рассмотреть лишь
216
общие принципы создания СКС. Конечно, отдельные
рекомендации стандартов СКС могут быть с успехом
использованы при создании кабельной системы
собственными силами (но без возможности официальной
сертификации такой системы).
Структурированная кабельная система (СКС)
представляет собой иерархическую кабельную систему
здания или группы зданий, разделенную на структурные
подсистемы. СКС состоит из набора медных и оптических
кабелей, кросс-панелей, соединительных шнуров,
кабельных разъемов, модульных гнезд, информационных
розеток и вспомогательного оборудования. Все
перечисленные элементы интегрируются в единую систему
и эксплуатируются согласно определенным правилам.
Основные преимущества (или принципы) СКС:
• Универсальность: передача данных в ЛВС,
видеоинформации или сигналов от датчиков пожарной
безопасности либо охранных систем по единой кабельной
системе, организация локальной телефонной сети.
• Гибкость: простота изменения конфигурации
кабельной системы и управления перемещениями внутри и
между зданиями.
• Устойчивость: тщательно спланированная СКС
устойчива к внештатным ситуациям и гарантирует высокую
надежность и защиту данных в течение многих лет. Так
большинство ведущих производителей дают гарантию на
поставляемые ими СКС (при выполнении требуемых
процедур сертификации) до 25 лет.
Основным препятствием широкого внедрения СКС
является, как уже отмечалось, их высокая стоимость, что
делает приемлемым это решение для относительно
масштабных локальных сетей уровня предприятия.
Действительно, стандарты на СКС предусматривают
проведение, наряду с прочими, комплекса дорогостоящих
строительных работ.
Основными стандартами на СКС являются:
• Международный стандарт ISO/IEC 11801 Generic
Cabling for Customer Premises.
217
Европейский
• стандарт EN 50173 Information
technology– Generic cabling systems.
• Американский стандарт ANSI/TIA/EIA 568-В
Commercial Building Telecommunication Cabling Standard.
Стандарты на СКС периодически (примерно раз в пять
лет) пересматриваются в связи с развитием аппаратных
средств локальных сетей (включая совершенствование
медных и оптоволоконных кабелей). Согласно стандартам,
СКС включает следующие три подсистемы:
• магистральная подсистема комплекса;
• магистральная подсистема здания;
• горизонтальная подсистема.
Распределительные пункты (РП) обеспечивают
возможность создания топологии каналов типа "шина",
"звезда" или "кольцо" (см. рис. 15.1) [5].
Рисунок 15.1 - Подсистемы СКС
Магистральная подсистема комплекса включает

магистральные кабели комплекса, механическое окончание
кабелей (разъемы) в РП комплекса и РП здания и
коммутационные соединения в РП комплекса.
Магистральные кабели комплекса также могут соединять
между собой распределительные пункты зданий.
Магистральная подсистема здания включает
магистральные кабели здания, механическое окончание
кабелей (разъемы) в РП здания и РП этажа, а также
коммутационные соединения в РП здания. Магистральные
кабели здания не должны иметь точек перехода,
218
электропроводные кабели не следует соединять сплайсами
(тип непосредственного соединения кабелей без разъемов).
Горизонтальная подсистема включает горизонтальные
кабели, механическое окончание кабелей (разъемы) в РП
этажа, коммутационные соединения в РП этажа и
телекоммуникационные разъемы. В горизонтальных
кабелях не допускается разрывов. При необходимости
возможна одна точка перехода. Точка перехода – это место
горизонтальной подсистемы, в котором выполняется
соединение двух кабелей разных типов (например,
круглого кабеля с плоским) или разветвление
многопарного кабеля на несколько четырехпарных. Все
пары и волокна телекоммуникационного разъема должны
быть подключены. Телекоммуникационные разъемы не
являются точками администрирования. Не допускается
включения активных элементов и адаптеров в состав СКС.
Абонентские кабели для подключения терминального
оборудования не являются стационарными и находятся за
рамками СКС. Однако стандарты определяют параметры
канала, в состав которого входят абонентские и сетевые
кабели.
В целом соединения в СКС образуют систему
интерфейсов СКС. Интерфейсы СКС – это гнездовые
разъемы каждой из подсистем, обеспечивающие
постоянное или коммутируемое подключение оборудования
и кабелей внешних служб. На рис. 15.2 показаны
интерфейсы в виде линий в пределах распределительных
пунктов, схематически обозначающих блоки гнезд на
панелях.
Для подключения к СКС достаточно одного сетевого
кабеля. В варианте коммутации используют сетевой и
коммутационный кабель и дополнительную панель.
Стандарты на СКС по содержанию можно разделить на
три группы – стандарты проектирования, монтажа и
администрирования. Пожалуй, наиболее полезная в
практическом плане группа стандартов монтажа включает
рекомендуемые типы и длины отдельных сегментов
кабелей в различных подсистемах.
219
Рисунок 15.2 - Система интерфейсов СКС
В настоящее время во вновь создаваемых кабельных

системах рекомендуется использовать только витую пару
(симметричный кабель в соответствии с терминологией
стандартов) и оптоволоконный кабель, причем, чем выше
уровень подсистемы, тем предпочтительнее использование
оптоволокна.
Стандарт определяет пять классов приложений. Этим
гарантируется гибкость в выборе различных систем
передачи информации. Классы приложений:
• Класс A – речевые и низкочастотные приложения.
Рабочие характеристики кабельных линий,
поддерживающих приложения Класса A, определены до
100 КГц.
• Класс B – приложения цифровой передачи данных со
средней скоростью. Рабочие характеристики кабельных
линий, поддерживающих приложения Класса B,
определены до 1 МГц.
• Класс C – приложения высокоскоростной цифровой
передачи данных. Рабочие характеристики кабельных
линий, поддерживающих приложения Класса C,
220
• Класс D – приложения сверхвысокой скорости
передачи данных. Рабочие характеристики кабельных
линий, поддерживающих приложения Класса D,
• Класс оптики – приложения с высокой и сверхвысокой
скоростью цифровой передачи. Рабочие характеристики
волоконно-оптических кабельных линий определены для
частот 10 МГц и выше. Ширина полосы обычно не является
ограничивающим фактором в системах на территории
конечных пользователей.
Связь между классами линий и категорией кабелей,
показана в таблице 15.1.
Наиболее серьезной проблемой при создании СКС для
работы высокоскоростных приложений (категория 3 и
выше) является качество монтажа. По данным BICSI
(Building Industry Consulting Service International) –
международной ассоциации профессионалов
телекоммуникационной промышленности, 80% всех
структурированных кабельных систем США, построенных
на компонентах категории 5, не могут быть
квалифицированы как системы категории 5 вследствие
нарушения правил монтажа.
Существуют специальные требования и рекомендации
по монтажу СКС, выполнение которых гарантирует
сохранение исходных рабочих характеристик отдельных
компонентов, собранных в линии, каналы и системы.
Стандарты ISO/IEC 11801 и ANSI/TIA/EIA-568A
устанавливают в качестве требований несколько основных
правил монтажа, предусматривающих методы и
аккуратность выполнения соединения компонентов и
организации кабельных потоков, которые в значительной
степени повышают производительность системы и
облегчают администрирование установленных кабельных
систем.
221
Таблица 15.1 - Связь между классами линий и категорией кабелей
Класс приложений
Тип трассы
Класс A Класс B Класс C Класс D Класс оптики
Категория 3 2000 м 200 м 100 м - -
Категория 4 3000 м 260 м 150 м - -
Категория 5 3000 м 260 м 160 м -
Сбалансированный
3000 м 400 м 250 м -
Многомодовое -волокно- - - 2000 м
Одномодовое волокно
- - - - 3000 м
Уменьшению искажения передаваемого сигнала

способствуют специальные методы подготовки кабеля и
его терминирования (нагружения на согласующее
сопротивление) в соответствии с инструкциями
производителя, а также хорошая организация кабельных
потоков, расположение и монтаж телекоммуникационного
оборудования, обслуживающего кабельную систему.
Эти правила особенно касаются
высокопроизводительных кабелей, как медных, так и
волоконно-оптических. Медные кабели чувствительны к
внешним аномалиям. Например, развитие пары медных
проводников на величину, превышающую максимально
допустимую стандартами, негативно влияет на
характеристики перекрестных помех пары или пар.
Нарушение требований к минимальному радиусу изгиба
кабеля также влияет на его рабочие характеристики.
С увеличением частоты передачи возрастает риск того,
что неправильно смонтированный кабель окажет влияние
на производительность системы. Если полоса частот
меньше 16 МГц, а скорость передачи равна или ниже 10
Мбит/с (например, 10BASE-T Ethernet), можно и не
заметить, что технология монтажа была нарушена. Однако
этот же кабель, работающий при ширине полосы сети более
50 МГц и скорости передачи 100 Мбит/с или выше, может
функционировать неправильно.
Для оценки передающих рабочих характеристик
компонентов СКС используются следующие параметры:
затухание, NEXT (NearEndXtalk – переходные помехи на
222
ближнем конце), обратные потери и сопротивление
постоянному току. Все они чувствительны к нарушениям
непрерывности волновой среды в точках терминирования и
в местах возникновения дефектов, но на NEXT особенно
влияет развитие пары проводников и другие воздействия,
приводящие к нарушению баланса пары и отклонениям
импеданса.
Кроме искажения сигнала, неправильное
терминирование может привести к возникновению эффекта
рамочной антенны, который проявляется в излучении
сигнала с уровнями, превышающими нормативные
требования к излучению.
В таблице 15.2 приведено несколько примеров того, как
качество монтажа может влиять на самый "тонкий" и
"чувствительный" параметр – NEXT.
Общий закон, устанавливаемый стандартами, гласит:
смонтированная кабельная система UTP классифицируется
в соответствии с наихудшими рабочими характеристиками
компонента линии [5].
Таблица 15.2 - Влияние качества монтажа на параметр NEXT

Ухудшение
Тип воздействия
NEXT
Полный канал, правильно установленный Эталон для
сравнения
Кабель, изогнутый 1000 раз в пределах Без изменений
допустимого радиуса
Замена патч-корда длиной 0,6 м категории 5 на 8,0 дБ
патч-корд такой же длины категории 3
Замена патч-корда длиной 0,6 м категории 5 на 13,0 дБ
патч-корд длиной 6 м категории 3
Сворачивание кабеля в бухту с длиной витка 2 Без изменений
м и поперечным сечением 5 см
Жгутование кабелей с помощью кабельных Без изменений
хомутов в соответствии с правилами монтажа
Удаление 2,5 см. оболочки кабеля на 1,2 дБ
станционном конце
Удаление 30 см. оболочки кабеля на 2,0 дБ
станционном конце
223
Развитие пар кабеля 1,2 см на станционном 1,5 дБ
конце
Развитие пар кабеля 5 см на станционном конце 3,8 дБ
Развитие пар кабеля 15 см на станционном 11,6 дБ
конце
Скручивание кабеля радиусом изгиба 3,5 см 1,9 дБ
Скручивание кабеля радиусом изгиба 1,2 см 2,1 дБ
"Изломленный" кабель 2,4 дБ
224
16 КРАТКИЙ ОБЗОР ПРОГРАММНЫХ СИСТЕМ
ДЛЯ СТРУКТУРНОГО МОДЕЛИРОВАНИЯ СЕТЕЙ И
СИСТЕМ ТЕЛЕКОММУНИКАЦИЙ
16.1 Программная система NETWizard
Каждый раз, когда организация переезжает в новый

офис, открывает филиал или просто планирует
модернизацию своей технической инфраструктуры, ей
приходится формировать первичный комплект документов
на проектирование локальной вычислительной сети и
оценивать потенциальные затраты на ее построение.
Обычно, в таких случаях требуется привлечение
специалистов по проектированию сетей, но с некоторых
пор существует еще и возможность сделать это с помощью
бесплатного онлайнового сервиса NetWizard
(www.netwizard.ru).
NetWizard создан несколько лет назад сотрудниками
компании “Тауэр Сети”. В настоящее время он представлен
в своей третьей версии и ориентирован на активное
оборудование подразделения ProCurve Networking
компании HP (а также 3Com, но на платной основе). При
этом, как уверяют создатели ресурса, ассортимент
активного сетевого оборудования и цены на него,
постоянно поддерживаются в актуальном виде, что крайне
важно для решения возникающих у пользователей
практических вопросов.
Работа с системой NetWizard всегда происходит в
интерактивном режиме. При этом опытный инженер может
оперировать многочисленными параметрами в
соответствии с международными стандартами RFC, IEEE и
вручную уточнять предлагаемые системой варианты
оборудования. В простейшем же случае Web-
проектировщик попросит вас ответить на несколько не
сложных вопросов, а затем автоматически сформирует
смету с перечнем подходящего активного оборудования.
NetWizard является единственным в своём роде на
рынке системной интеграции онлайн- мастером
проектирования локальных вычислительных сетей.
225
Он предоставляет пользователям бесплатную
возможность проектирования компьютерных сетей в
первом приближении через Интернет. Расчёт ЛВС в режиме
онлайн происходит посредством пошагового диалога,
понятного любому пользователю персонального
компьютера. Система «не загружает» человека
незнакомыми ему терминами и непонятными вопросами.
Она предлагает уточнить те или иные параметры, чем с
удовольствием воспользуются более опытные
проектировщики.
При выборе Ethernet коммутаторов (свичей) – основных
компонентов мультисервисных сетей, будут
анализироваться требуемые сетевые технологии,
закреплённые в стандартах международных комитетов RFC
и IEEE. Для каждого из коммуникационных узлов
подбирается нужное количество Ethernet коммутаторов, в
зависимости от числа подключённых рабочих станций.
Если последние распределены по зданию неравномерно,
NetWizard оптимизирует количество коммуникационных
узлов и нагрузку на каждый из них.
Ответив на 10-20 несложных вопросов, уже через 30
минут можно получить схему и сметный расчёт
коммутаторов локальной сети. Конечно, эти два документа
не являются исчерпывающими для оценки затрат на ЛВС.
Вместе с тем, производительность и качество
обслуживания будущей компьютерной сети, зависят
именно от коммутаторов. К тому же скорость
технологических изменений в пассивном оборудовании и
ассортименте монтажных работ не бывает столь
стремительна, как в активном оборудовании. Поэтому
возможность быстрого и грамотного подбора коммутаторов
может оказаться весьма ценной.
Привлекательной является и возможность оптимизации
сети. После получения проектных документов, можно
вернуться в любое место диалога и изменить ранее
введённые данные, увеличивая функциональность будущей
сети либо уменьшая её стоимость. Благодаря богатым
инструментам оптимизации, можно добиться
существенного снижения затрат. Рассмотрев несколько
226
вариантов оборудования, можно оценить стоимость сети.
ЛВС на нескольких этажах в рамках одного здания
может быть описана в каждом проекте NetWizard.
Корпоративная сеть в пределах нескольких зданий, может
быть описана с помощью нескольких проектов. Для этого,
в каждом из проектов компьютерной сети здания нужно
указать, что она соединяется с сетями других зданий.
Возможность спроектировать ЛВС через Интернет
может стать первым шагом к планированию и
автоматизации вашего предприятия или бизнеса.
После прохождения регистрации пользователю
предлагается выбор шаблонов проекта: активное
оборудование ЛВС или же пассивное оборудование
Рисунок 16.1 – Выбор шаблона нового проекта
Пользователю в интерактивном режиме задаются
227
вопросы, касающиеся непосредственно характеристик
проектируемой сети. Сюда входят: количество рабочих
станций (рисунок 16.2) и параметры здания, в котором
планируется развернуть локальную вычислительную сеть
Рисунок 16.2 – Выбор количества рабочих станций
Рисунок 16.3 - Параметры здания
228
Далее определяются: распределение рабочих станций по
этажам (рисунок 16.4), количество и расположение
коммуникационных узлов (рисунок 16.5), местоположение
узла здания (к нему подключаются все узлы этажей-
рисунок 16.6).
Рисунок 16.4 - Распределение рабочих станций по этажам
Рисунок 16.5 – Количество и местоположение коммуникационных

узлов
229
Рисунок 16.6 - Местоположение узла здания
После этого определяются приложения, которые будут

использовать операторы рабочих станций (рисунок 16.7),
подключение серверов, их количество и расположение по
этажам (рисунки 16.8,16.9).
Рисунок 16.7 – Приложения, используемые в сети
230
Рисунок 16.8 – Подключение серверов
Рисунок 16. 9 – Количество серверов
Далее можно уточнить особенности проектируемой сети

231
Рисунок 16.10 – Уточнение особенностей сети
NETWizard произведет расчет сети и предложит

изменить при необходимости начальные данные. Затем
предлагается уточнить технические параметры
оборудования сети (рисунок 16.11).
Рисунок 16.11 – Уточнение технических параметров сети
232
Выбор производителя оборудования показан на рисунке
16.12.
Рисунок 16.12 – Выбор производителя оборудования
Далее проводится подбор вариантов оборудования, с

возможностью внесения изменений в исходные данные. В
результате сформируются следующие документы: схема
вычислительной сети (рисунок 16.13)
Рисунок 16.13 – Схема вычислительной сети

и сметный расчет оборудования (рисунок 16.14)
233
Рисунок 16.14 – Сметный расчет оборудования
На этом шаге можно закончить работу с системой или

же перейти к следующему проекту.
Расчет пассивного оборудования происходит
аналогично. В результате пользователь получает
спецификацию (рисунок 16.15) и структурную схему сети
234
Рисунок 16.15 – Спецификация
Рисунок 16.16 – Структурная схема компьютерной сети
235
16.2 Система NetCracker
Программный пакет NetCracker разработан компанией

NetCracker Technology. Он позволяет создавать проекты
вычислительных сетей разной сложности/топологий и
проводить их анализ, используя технологию
имитационного моделирования.
Область применения пакета охватывает создание
проекта сетевого решения, тестирование этого решения и
документирование окончательного варианта. База ресурсов
системы допускает, хотя и с некоторыми ограничениями,
добавление нового оборудования с характеристиками,
задаваемыми пользователем. Эта возможность в частности,
в достаточной мере компенсирует отсутствие оборудования
Gigabit Ethernet, которое пользователь может создать
самостоятельно.
Пакет позволяет качественно оценивать возможность
перегрузки оборудования, каналов передачи данных и
находить «узкие места» сетевого проекта. Требования
пакета к производительности процессора растут по мере
увеличения числа заданных потоков данных. Например, на
машинах Celeron-500МГц симуляция проекта с числом
потоков 15 уже может давать сбои, а для нормальной
работы требует, по крайней мере, Celeron-800МГц. Пакет
делает возможным практическое создание самых
разнообразных сетевых решений почти «вживую» без
дорогостоящей тестовой лаборатории. Такая возможность
чрезвычайно полезна на лабораторных занятиях по сетевым
технологиям, администрированию и проектированию сетей.
Система NetCracker использует технологию
имитационного моделирования сети и позволяет получить
результаты в случаях, когда аналитические расчеты
громоздки, крайне сложны, а нередко и невозможны. Тем
не менее в образовательном плане полезна сверка
получаемых в NetCracker результатов с известными
результатами теории массового обслуживания и
прикладного раздела этой теории – теории телетрафика.
Такие проверки можно проводить в рамках лабораторных
занятий для сетей с элементарными топологиями. Тем
236
более что способ задания трафика в NetCracker совместим с
определениями входного потока заявок в ТМО. Одинаково
задаются и размер блока данных, (Transaction size) и время
между приходами данных (Time Between Transactions).
Поскольку потоки данных имеют стохастическую природу,
для размера данных и времени прихода задаются законы
распределений и соответствующие статистические
характеристики. Свойства обслуживающего прибора в
NetCracker, к сожалению, определяются не достаточно
подробно: в виде фиксированной задержки обслуживания и
абсолютного предела скорости поступления заявок. Размер
буфера «прибора» задать нельзя.
После установки и запуска пакета NetCracker, на экране
появляется главное окно программы (рисунок 16.17).
Рисунок 16.17 - Главное окно NetCracker
Окно NetCracker Professional состоит из трех областей:

браузер баз данных, рабочее пространство проекта Net1, и
область изображения объектов. При запуске NetCracker
237
Professional, рабочее пространство будет содержать пустой
экран Net1. Область окна заполняется изображениями
устройств и приложений в зависимости от объекта,
выбранного из базы данных (здания, университетские
городки и рабочие группы локальной сети).
После выбора команды в меню File > Open: вызывается
диалоговое окно Open для открытия проекта сети из
готовых примеров (рисунок 16.18).
Рисунок 16.18 – Сеть Client_server.net
Окно браузера баз данных содержит список устройств,

отсортированный по производителям (рисунок 16.19).
238
Рисунок 16.19 - Окно браузера баз данных
Для получения информации относительно устройства в

рабочем пространстве, нужно дважды щелкнуть на
устройстве.
Свойства маршрутизатора Cisco 2511 показаны на
рисунке 16.20. Если устройство является модульным, то
можно добавить соответствующие модули в поле
устройства, нажав кнопку Plug-in setup и перетащив
модуль из браузера баз данных, а также указать протоколы,
по которым работает каждый модуль.
239
Рисунок 16.20 – Свойства маршрутизатора 2511
Для отображения видов связей при подключении

устройств, из меню View,нужно выбрать команду Legends
Рисунок 16.21 - Окно-диалог условных обозначений
240
Устройства соединяются с помощью мастера
соединений "Link Assistant". Система NetCracker
проверяет тип интерфейсов устройств и соединяет из них
только совместимые.
Например, в персональных компьютерах
(LanWorkstations\PCs\GenericDevices\PC) в исходном
состоянии есть только последовательные COM-порты,
поэтому для соединения их с сетевым оборудованием
потребуется установить сетевую карту. Теперь создадим
новый проект File\New. Находим компьютер в БД
оборудования (LanWorkstations\PCs\GenericDevices\PC) и
перенесем методом Drag-and-Drop иконку PC в основное
окно проекта TOP.
Затем находим сетевую карту в БД оборудования
(LANadapter\Ethernet\GenericDevices\FastEthernet) и
перенесем иконку "FastEthernetAdapter" методом Drag-and-
Drop на компьютер PC. Для сетей Ethernet можно выбрать и
готовый сетевой компьютер EthernetWorkstation
(LANworkstation\Workstations\Generic
Devices \ EthernetWorkstation). Добавим в основное окно
еще один такой компьютер и коммутатор FastEthernet
(Switches\ Workgroup \Ethernet \GenericDevices \Ethernet
Swich) и приступаем к соединению двух компьютеров
через коммутатор (рисунок 16.22).
Рисунок 16.22 – Соединение устройств
Порядок соединения устройств.

1. Выбрать в панели инструментов инструмент "Link
devices" (рисунок 16.23).
Рисунок 16.23 - Инструмент "Link devices"
241
2. Необходимо убедиться, что модули (компьютеры,
коммутаторы, концентраторы), которые вы планируете
соединить, имеют совместимые сетевые порты, например,
FastEthernet. Это можно сделать, выбрав Properties в
контекстном меню устройства, а затем закладку Ports.
3. Далее щелкнуть левой кнопкой мыши сначала по
источнику, затем по приемнику данного соединения.
4. Затем нажать в диалоге Link Assistant на кнопку
Link, а также задать тип, длину и прочие характеристики
среды (длина линии не учитывается при симуляции
передачи данных в сети).
5. Закрываем диалог, нажав на кнопку Close.
При задании трафика нужно учитывать процессорные
возможности компьютера. Так, при 15 потоках трафика и
включенной анимации, для устойчивой работы программы
требуется процессор не ниже Celeron-800. Проверьте
конфигурацию своего компьютера: My Computer\Properties.
Немного облегчить задачу для компьютера можно, отменив
визуализацию передаваемых данных: Global\ Data Flow\
Uncheck All\ Close. При этом сохраняется возможность
наблюдать результаты моделирования, получаемые через
индикаторы статистики. Трафик в моделируемой сети
задается с помощью мастера, вызываемого кнопкой панели
инструментов Set traffic. Порядок задания трафика
следующий.
1. Выбрать в панели инструментов инструмент Set
traffic:
Рисунок 16.24 – Выбор инструмента «Задание трафика»
2. Щелкнуть левой кнопкой мыши сначала по модулю-

источнику трафика, затем по модулю-приемнику трафика.
3. Навести указатель мыши на один из стандартных
профилей трафиков, например, InterLAN traffic. Затем
щелкнуть правой кнопкой мыши и в контекстном меню
выбрать данный профиль трафика (пункт Select).
При выборе профиля можно изменять характеристики
242
профиля (кнопка Edit), задавая статистику размеров
дейтаграмм Transaction size, статистику моментов прихода
дейтаграмм, пауз Time between transactions, а также
протокол уровня приложения Application Layer Protocol.
Нажав на кнопку Add можно создать свой профиль
трафика с заданными характеристиками. Трафик получит
имя Traffic (номер), которое можно изменить, выбрав в
контекстном меню трафика пункт Rename.
4. Посмотреть на заданные потоки данных в сети
Global\Data Flow. Здесь же можно отредактировать (в том
числе и удалить) свойства потоков и профилей трафиков.
Необходимо учитывать максимальные пропускные
способности каналов передачи данных и не перегружать их
чрезмерно. Замечено, что при перегрузке на порядок,
индикаторы статистики среды NetCracker дают неверные
(произвольные) данные.
5. При выборе трафика клиент-сервер, например,
профиля трафика почтового клиента E-mail (POP),
установить серверное приложение (в данном примере –
почтовый сервер). Для этого, в браузере оборудования
(закладка Devices) нажать группу Network and Enterprise
software. Затем перенести иконку E-mail server методом
Drag-and-Drop на компьютер-сервер. После такой
установки программного обеспечения, можно назначать
клиент-серверные трафики.
Назначать такие трафики нужно от клиента к серверу:
сначала выбирать компьютер-клиент, затем – сервер.
Другие виды серверного трафика можно добавить в
свойствах программного обеспечения сервера: Контекстное
меню компьютера-сервера Configuration\Контекстное меню
серверного программного обеспечения Properties\ Закладка
Traffic. При назначении клиент-серверного трафика, можно
изменять характеристики ответов сервера, задавая
статистику размеров дейтаграмм Transaction size,
статистику моментов прихода дейтаграмм/пауз Time
between transactions, а также протокол уровня приложения
Application Layer Protocol.
В процессе разработки текущего варианта проекта сети
в NetCracker можно получить отчеты о составе проекта.
243
Например, Tools\Reports\Bill of Material можно получить
отчет о номенклатуре оборудования, входящего в проект
сети, ценах каждой единицы оборудования, общей цены
проекта: Tools\Reports\Device Summary или
спецификацию всех единиц оборудования. Подобные
спецификации можно сгенерировать и по отдельным
классам оборудования (например, Workstations, Servers,
Hubs, и т. д.). Полученные таким образом отчеты можно
распечатать или сохранить в файл, воспользовавшись
панелью меню по работе с отчетами (рисунок 16.25).
Рисунок16.25 – Панель меню по работе с отчетами
При выборе опции сохранить появляется окно Export

(рисунок 16.26), в котором можно определить формат
сохраняемого отчета и место его хранения (файл на диске
или отправка по почте).
Рисунок 16.26 – Окно Export
244
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. IT Guru Academic Edition. OPNET Technologies, 2005.

http://www.opnet.com/services/university/itguru_academic_edi
tion.html.
2. OPNET IT Tutorial, http://www.opnet.com/itguru-
academic/mk-setup.html
3. J. Theunis, B. Van den Broeck, P. Leys, J. Potemans1, E.
Van Lil, A. Van de Capelle, “OPNET in Advanced Networking
Education”
http://www.esat.kuleuven.ac.be/telemic/networking/opnetwork
02_johan.pdf
4. The World’s Leading Network Modeling and Simulation
Environment. OPNET Technologies,
http://www.opnet.com/products/modeler/home.html.
5. Университет Информационных Технологий
http://www.lessons-tva.info/edu/e-inf3/m3t1_1.html.
245
ПРИЛОЖЕНИЕ
Инструкция пользователя OPNET Modeler 9.1

1. Скачать с сайта opnet.com файл-инсталляцию программы OPNET
Modeler 9.1 по следующей ссылке:
http://www.opnet.com/services/university/itguru_academic_edition.html.
Рисунок 1 – Сайт Opnet Modeler 9.1
2. Для регистрации использовать ссылку:

https://enterprise37.opnet.com/4dcgi/SIGNUP_NewUserOther.
Заполнить необходимые поля (имя, фамилия, страна, адрес электронной
почты и др.) и нажать кнопку «подтвердить»(рисунок 2). Получить логин и
пароль.
246
Рисунок 2 – Заполнение формы регистрации
3.Зайти по ссылке
https://enterprise37.opnet.com/4dcgi/COMMUNITY_HOME. Ввести
полученные логин, пароль и выйти на сайт
http://enterprise37.opnet.com/4dcgi/DOWNLOAD_HOME (рисунок 3).
247
Рисунок 3 – Страница для скачивания программы
4.Нажать кнопку «скачать», скачать файл

ITG_Academic_Edition_v1996.exe.
5.Для установки OPNET Modeler 9.1 запустить файл
ITG_Academic_Edition_v1996.exe на выполнение (рисунок 4).
Рисунок 4 – Инсталляция OPNET Modeler 9.1
248
6. Выбрать каталог для установки программы.
Рисунок 5 – Выбор каталога для установки
7. Выполнить установку программы, после которой на экране появится

окно, сообщающее об окончании установки.
Рисунок 6 – Окончание установки

249
8. Запустить установленную программу OPNET Modeler 9.1.
Рисунок 7 – Запуск OPNET Modeler 9.1
9. Регистрация программы. Для этого согласиться с условиями

регистрации и нажать на соответствующую кнопку. На экране появится
следующее окно:
Рисунок 8 – Окно начала регистрации программы
250
10. Нажать на кнопку «Next». В появившемся окне нажать кнопку
«копировать код регистрации в буфер обмена», а затем кнопку далее.
Автоматически появляется окно следующего вида:
Рисунок 9 – Копирование кода запроса лицензии
Рисунок 10 – Ввод кода запроса лицензии
251
11. Нажать кнопку «Submit» и получить код регистрации программы
Рисунок 11 – Окно получения регистрационного кода программы

12.Скопировать полученный регистрационный код в буфер обмена и
Рисунок 12 – Ввод регистрационного кода
252
поместить его в соответствующее поле следующей формы:
13. Нажать кнопку Next и на экране появится окно, подтверждающее
успешную регистрацию OPNET Modeler 9.1.
Рисунок 13 – Окно подтверждения успешной регистрации программы
14. Перезапустить OPNET Modeler 9.1 для начала работы.
253
Глоссарий
AAL (ATM Adaptation Layer) Уровень адаптации АТМ, согласовывает ATM с
другими протоколами, у которых другая длина
пакета.
ABR (available bit rate) Доступная скорость передачи в ATM QoS.
Метод передачи, изменяющий скорость
передачи в зависимости от нагрузки на канал.
ACE (Application Среда изучения приложений. Была создана для
Characterization Cisco Systems, широко используется для оценки
Environment) реальных приложений по экспериментальным
данным
ACK (Acknowledgment) Бит в пакете TCP, означающий подтверждение
доставки
Application Response Time Время отклика приложения
Applications Приложение, программа
Apply Changes Применить изменения
As is Как есть (без изменений)
ATM (Asynchronous Метод передачи данных ячейками
Transfer Mode) фиксированной длины
Average Усредненный
Backbone Магистраль
Background Utilization Фоновое использование
Backup Server Резервный сервер
Bottleneck Переполнение (буфера)
Branch Офис
Bridge Мост (2-х портовый коммутатор)
Capture Захватывать (пакеты)
Carrier Несущая (частота, сигнал)
CBR (constant bit rate) Параметр FrameRelay, означает связь с
постоянной скоростью
Chattiness «Болтливость» приложения. Проявляется, когда
части приложения (клиент/сервер)
обмениваются данными в режиме
последовательного диалога, но слишком много
раз происходят циклы запрос/ответ, в каждом из
которых передается очень мало информации.
CIR (Committed Гарантированная скорость передачи
Information Rate)
CMR (Cell misinsertion rate) Допустимая частота возникновения
непередаваемых ячеек (пакетов) в ATM QoS
Collapse Свернуть
Collection Mode Режим сбора (информации)
Collision Коллизия, сетевая ошибка
Collision detect Определение коллизии (детектирование)
254
Compare Results Результат сравнения
Configure Discrete Event Настроить имитационное моделирование
Simulation
Congestion Window Size Вариант TCP окна для предотвращения
перегрузки
CSMA/CD (Carrier Sense, Множественный доступ с контролем несущей и
Multiple Access with обнаружением коллизий
Collision Detect)
Data Exchange Chart График обмена данными
Data rate Скорость передачи данных
Database База данных
Database Access Доступ к базе данных
DB Query Запрос к базе данных
Delay Задержка
Delete Удаление
Demand Object Возникающий (временный) объект
Description Описание
Diagnosis Диагностика
Download link Utilization Загрузка линии на прием
Duplicate Scenario Дублировать сценарий
Duration Продолжительность
Effect of Latency Эффект задержки (латентности)
E-mail Электронная почта
E-mail Server Сервер электронной почты
Ethernet Протокол IEEE 802.3, среда передачи данных
CSMA/CD
Exponential Показательное (распределение)
Fast Recovery Быстрое восстановление
Fast Retransmit Быстрая повторная передача
File Server Файл-сервер
File Sharing Общий доступ к файлам
Find Поиск
Firewall Брандмауэр, межсетевой экран
Firewall Implemented Установка брандмауэра, внедрение
Frame Relay Метод передачи данных, распространен в
западных странах
FTP (File Transfer Protocol) Протокол для передачи файлов по сети
FTP Server Сервер FTP
Heavy Сильно, тяжело
High Load Высокая загрузка
Hub Концентратор
intermediate Межсетевое взаимодействие
Interarrival Time Временной интервал между посылками
255
ISP (Internet Service Провайдер услуг Интернет
Provider)
Latency Задержка, латентность
Light Легко, немного
Link utilization Использование (загрузка) линии связи
Load Загрузка
MAN (Metropolitan Area Сеть масштаба города
Network)
Messages Сообщения, пакеты
Model Files Файлы модели
Network Browser Браузер (смотритель) сети
Network Effect of Chattiness Эффект больших задержек в приложении,
работающем с сетью, когда сама сеть
обеспечивает малый уровень задержек (см.
Chatiness)
Object Palette База компонентов, ресурсов
Object statistics Статистика объекта
Oracle Фирма, выпускающая системы управления
базами данных
OSI Стандарт межсетевых взаимодействий
Outgoing CIR Гарантированная скорость посылки данных
Overlaid Statistics Статистика нескольких процессов на одном
графике
Packet Delay Variation Разность в задержках передачи пакетов
Packet Generation Аргументы генератора пакетов
Arguments
Page Response Time Время отклика страницы
Parent Subnet Родительская подсеть, подсеть с тем же
адресом, но с меньшей маской
PCM Quality Speech Стандарт кодирования голосовой информации
PCM
Periphery Периферия
Point-to-point Соединение точка-точка
Preferences Параметры
Print Server Сервер печати
Profiles Профиль (настройки для конкретного случая)
Project Editor Редактор проекта
Protocol Overhead Перегрузка протокола
Proxy Server «Кеширующий» сервер
Proxy Server Deployed Внедрение кеширующего сервера
PVC (Permanent Virtual Постоянное виртуальное соединение
Circuit) (FrameRelay, ATM)
QoS (Quality of Service) Обеспечение качества услуги
Queue Очередь
256
Radius Радиус
Rapid Configuration Быстрая настройка
Receive Buffer Буфер приемника, входной буфер
Recovery Восстановление
Release 1. Номер версии 2. Освобождение
Repositories Репозиторий, хранилище часто используемых
объектов
Requesting Client Custom Запрос клиента к другому приложению
Application
Response Time Время отклика
Results Результаты
Retransmit Повторная передача
Run Прогон, начало моделирования
Run Simulation Начать прогон имитационной модели
Sample Profile Пример профиля
Scenarios Сценарий
Segment Sequence Number Порядковый номер сегмента
Selected Objects Выделенные объекты
Sent Segment Sequence Посланный порядковый номер сегмента
Number
Server Сервер
Similar Links Похожие линии связи
Simulation Имитационное моделирование
Simulation Speed Скорость моделирования
Special Values Особые значения
Star Звезда (о топологии)
Subnet Подсеть
Switch Коммутатор
Switch To Scenario Переключиться к другому сценарию
SYN (Synchronize) Бит синхронизации соединения (первый пакет в
соединении, запрос на соединение)
System Information Системная информация
Т1 Линяя связи в 1.5 Mbps
ТСР window scale Автоматический подбор размера окна TCP
TCP Parameters Параметры TCP
TCP Window Окно TCP (количество переданных TCP пакетов
без подтверждения доставки)
Telnet Популярный протокол удаленного доступа в
систему
Thickness Тонкий (провод)
ThinNet Толстый (провод)
time_average Усредненный по времени
Topology Топология (физическая структура)
257
Traffic Трафик, поток данных
Traffic Demand Непостоянный, возникающий временами поток
данных
Traffic Received Принятый поток данных
Traffic Sink Уменьшение трафика
Transport Protocol Спецификация протокола TCP
Specification
UBR (unspecified bit rate) Неопределенная скорость передачи в ATM QoS
Upload link Utilization Загрузка линии на передачу
Upload Response Time Время отклика при выгрузке файлов
Utilization Использование, загрузка
UTP (Unshielded Twisted Неэкранированная витая пара
Pair)
VBR – nrt (Variable bit rate Изменяющаяся не в реальном времени скорость
- non-real-time) передачи в ATM QoS. Используется для
ограничения скорости передачи данных при
каких-либо условиях.
VBR – rt (Variable bit rate Изменяющаяся в реальном времени скорость
real-time) передачи в ATM QoS. Используется в IP
телефонии, обеспечивает минимальные
задержки и колебания задержек.
Voice Голосовые данные (IP телефония)
WAN (Wide Area Network) Глобальная сеть
WAN link Линяя связи с глобальной сетью
Web Application response Время отклика Веб-приложения
time
Web Response Time Время отклика Веб-страницы
WLAN (Wireless Area Беспроводные сети
Network)
ГВС см. WAN
Коммутатор Устройство, коммутирующее пакеты по портам
на основе физических адресов получателей.
ЛВС Локальная вычислительная сеть. Сеть с
радиусом не более 1-2 км.
Маршрутизатор Устройство, осуществляющее выбор
оптимального пути следования пакета на основе
сетевого адреса получателя и собственных
таблиц направлений.
Окно TCP см. TCP Window
Пиринговые сети Сети point-to-point, в которых машины
соединяются непосредственно друг с другом
Сниффер Устройство (программа) перехвата сетевого
трафика, часто используется хакерами.
258

УМК Проектир.и Мод.Сетей

Загружено:

Сведения о документе

Описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Описание:

Авторское право:

Доступные форматы

УМК Проектир.и Мод.Сетей

Загружено:

Описание:

Авторское право:

Доступные форматы

В.Н. ТАРАСОВ, Н.Ф.

Рекомендовано ГОУ ВПО

Тарасов В.Н., Бахарева Н.Ф.,

Т 19 Проектирование и моделирование сетей

Учебное пособие предназначено для студентов

©Тарасов В.Н., Бахарева Н.Ф.,

Предлагаемое пособие является фактическим

В данном пособии изложены основы обучения

Вкратце рассмотрим технологию IT Guru, а прежде всего

В первой части показывается, как с Просмотр и

1.1 Редактор проекта

Редактор проекта - это главный инструмент для создания

Окно редактора проекта

Когда открыт какой-либо проект, то экран редактора

Рисунок 1.2 – Окно редактора проекта

Рисунок 1.3 – Панель инструментов

Наиболее часто используемые кнопки при выполнении

Таблица 1 – Кнопки панели инструментов

Если щелкнуть левой кнопкой мыши по картинке справа

Рисунок 1.4 – Всплывающая подсказка

1.2 Проектирование небольших объединенных сетей

1.3 Выполнение задания

Перед созданием новой модели сети необходимо

После этого создается рабочая область заданного

Рисунок 1.6 – Узлы сети

Канал связи (link) – среда передачи данных,

Рисунок 1.7 – Канал связи

Все эти объекты находятся в базе ресурсов (окне с

Рисунок 1.8 – Выбор топологии

3. Определить модели узлов и каналов связи сети.

После этого в окне редактора появится искомая сеть

Рисунок 1.10 - Полученная сеть

2. Найти Sm_Int_server и переместить на рабочую

Рисунок 1.11 – Сеть первого этажа

Далее можно переходить к этапу сбора и обработки

Рисунок 1.12 – Окно выбора результата

Это окно показывает дерево статистик, которые можно

Рисунок 1.13 – Выбор глобальных статистик

1. Раскрыть дерево <глобальная статистика> (Global

В процессе работы нужно сохранять проект как можно

Начало прогона модели

Рисунок 1.14 – Задание длительности прогона

3.Нажать кнопку <начать> (Run) для начала прогона.

Рисунок 1.15 – Окно выполнения прогона:

Также можно посмотреть <глобальные задержки

Рисунок 1.18 – График задержек Ethernet сети

Теперь, когда точка отсчета создана и собрана

Создание нового сегмента сети

Теперь надо соединить две сети, а для этого открываем

5. Переместить картинку маршрутизатора Cisco 2514

Рисунок 1.22 – Трафик на входе сервера во времени

Следующий рисунок показывает усредненную загрузку

Обратим внимание на то, что в то время как средняя

Сравнение задержек Ethernet двух сценариев

Теперь необходимо выбрать пункт

1.5 Руководство по устранению ошибок

Если прогон модели закончился не так, как ожидалось,

Добавление каталога <tutorial_ref>

Добавление каталога <tutorial_ref> в mod_dirs

Содержание лабораторной работы

Лабораторная работа описывает основы использования