close

Вход

Забыли?

вход по аккаунту

Гуков Артем Андреевич. Разработка проекта модернизации ЛВС ВУЗа с использованием технологии программно-определяемых сетей

код для вставки
Powered by TCPDF (www.tcpdf.org)
Powered by TCPDF (www.tcpdf.org)
Powered by TCPDF (www.tcpdf.org)
Powered by TCPDF (www.tcpdf.org)
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
5
1 АНАЛИЗ ОСНОВНЫХ СУЩЕСТВУЮЩИХ КОНЦЕПЦИЙ ПОСТРОЕНИЯ
КОМПЬЮТЕРНЫХ СЕТЕЙ
8
1.1 Компьютерные сети с традиционной архитектурой
8
1.2 Программно-определяемые сети
16
2 МОДЕЛИРОВАНИЕ СУЩЕСТВУЮЩЕГО УЧАСТКА КОМПЬЮТЕРНОЙ
СЕТИ ОБРАЗОВАТЕЛЬНОЙ ОРГАНИЗАЦИИ
37
2.1 Выбор инструментального средства для моделирования компьютерной сети
традиционной архитектуры
37
2.2 Выбор программного средства для моделирования проектируемой
компьютерной сети
43
2.3 Модель сети образовательной организации
49
2.4. Выбор метрик для проведения исследования
58
3 ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ТРАДИЦИОННОЙ И
ПРОГРАММНО-ОПРЕДЕЛЯЕМОЙ СЕТИ
60
3.1 Измерение задержки в традиционной и программно-определяемой сети
67
3.2 Измерение пропускной способности традиционной и программноопределяемой сети
74
3.3 Измерение гибкости программно-определяемой сети
78
3.4 Измерение производительности традиционной и программно-определяемой
сети при генерации трафика
80
3.5 Выводы по результатам исследования
82
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЕ А – ПРОГРАММНЫЙ КОД
85
86
91
УДОСТОВЕРЯЮЩИЙ ЛИСТ
104
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА ДОКУМЕНТА НА
ЭЛЕКТРОННОМ НОСИТЕЛЕ
105
5
ВВЕДЕНИЕ
Современные тенденции, такие как рост числа подключенных к Интернету
устройств, экспоненциальный рост объемов информации, развитие облачных
технологий, использование больших данных, на глазах меняют корпоративный
телеком. Наблюдается тенденция к наращиванию объемов сетевого трафика, и у
организаций
все
чаще
возникает
необходимость
конфигурировать
вычислительные компьютерные сети.
Помочь в решении этой задачи призваны технологии программноопределяемых сетей SDN (Software-Defined Networking) и функциональной
виртуализации сетей NFV (Network Function Virtualization), которые позволяют
перевести сетевые устройства под контроль настраиваемого программного
обеспечения, сделать их более интеллектуальными и облегчить управление ими.
Традиционное управление сетями обычно требует настройки каждого
подключаемого к сети устройства по отдельности. Например, конфигурирование
списка контроля доступа виртуальной части локальной сети (VLAN access control
list) на нескольких коммутаторах Cisco, неизбежно влечёт за собой процедуру
аутентификации на каждом из устройств и выполнение необходимых настроек.
Подобный подход успешно работал в прошлом, но в настоящее время может
потребовать значительных временных затрат, так как большинство организаций
добавляют в свою сеть устройства, принесенные сотрудниками, и разворачивают
многочисленные корпоративные облачные сервисы.
Философия программно-определяемых сетей основывается на том, что
главная цель управления сетью – это возможность подключения к корпоративной
сети
различных
устройств
(неважно
—
принадлежащих
ли
компании,
сотрудникам, а также устройств от различных производителей) и совместного
использования общих сетевых ресурсов. Такая концепция требует постоянных
применений
политик
на
всех
устройствах.
В
дальнейшем,
системный
администратор, меняющий политики, не будет вынужден затрачивать время,
6
внося изменения на каждом из устройств по отдельности, другими словами, все
изменения в конфигурации сети будут производиться централизованно из единой
консоли управления. В этом заключается ключевая особенность программноопределяемых сетей.
Также важно отметить, что механизм виртуализации сетей построен на базе
свободного программного обеспечения, что позволяет сетевым администраторам
быстрее и эффективнее управлять большими потоками данных из одной консоли.
Использование свободного программного обеспечения для централизованной
настройки всей сети с помощью специализированных открытых протоколов,
таких как OpenFlow, позволяет решить проблему администрирования сетевых
устройств от различных производителей, делая весь процесс максимально
прозрачным. Одним из побочных факторов внедрения данной технологии может
являться ухудшение пропускной способности всей сети, однако на текущий
момент
приоритетным
аспектом
является
возможность
неограниченного
масштабирования корпоративных сетей, устранения их изоляции, увеличения их
надежности,
и
предоставления
прозрачных
средств
управления.
Любая
организация, заинтересованная в этом, должна присмотреться к технологиям
виртуализации сетей и программно-определяемым сетям. Отслеживая динамику
развития и внедрения концепции программно-определяемых сетей можно сделать
прогноз о том, что в ближайшие пять лет все производители сетевого
оборудования адаптируют к программно-определяемым сетям свои решения, а
через семь-десять лет использование программно-определяемых сетей станет
обычным явлением.
Целью
магистерской
диссертации
является
разработка
проекта
модернизации существующей локальной вычислительной сети образовательной
организации с использованием программно-определяемых сетей.
Основными задачами можно выделить следующие пункты:
–
анализ существующих концепций к построению компьютерных сетей;
7
–
анализ
распространенных
инструментальных
средств
для
проектирования и моделирования компьютерных сетей;
–
разработка
плана
модернизации
существующей
локальной
вычислительной сети образовательной организации;
–
проведения
производительности
исследования,
между
текущей
направленного
локальной
на
измерение
вычислительной
сетью
образовательной организации и ее модернизированным вариантом и апробация
результатов;
Научная новизна работы состоит в:
–
применении современного подхода построения компьютерных сетей
для модернизации существующей компьютерной сети;
–
проведении
комплексного
исследования
производительности
традиционной и программно-определяемой сетей;
Практическая
ценность
работы
заключается
в
разработке
проекта
модернизации существующей локальной вычислительной сети образовательной
организации, внедрение которого позволит улучшить характеристики сетевой
инфраструктуры образовательной организации.
8
1 АНАЛИЗ ОСНОВНЫХ СУЩЕСТВУЮЩИХ КОНЦЕПЦИЙ
ПОСТРОЕНИЯ КОМПЬЮТЕРНЫХ СЕТЕЙ
Перед тем как непосредственно перейти к изучению предметной области и
постановке задачи, проведем анализ основных существующих сетевых парадигм,
дадим их характеристику и выявим преимущества и недостатки каждой из них.
1.1 Компьютерные сети с традиционной архитектурой
На сегодняшний день вычислительная сеть является неотъемлемой частью
любого предприятия, в независимости от его масштабов, а её отсутствие
рассматривается как анахронизм, существенно снижающий эффективность
работы
всего
штата
сотрудников.
Особенно
важно
наличие вычислительной сети в образовательной организации, так как без
использования
информационных и компьютерных технологий становится
невозможным обеспечивать и поддерживать учебные и научные процессы.
В таких случаях, главным сетевым устройством уровня ядра является
современный управляемый коммутатор второго (L2) или третьего (L2+) уровня
модели OSI. Компьютерная сеть строится по определенным топологиям, наиболее
распространенными из которых являются: древовидная топология, топология
типа «кольцо», и топология типа «звезда».
1) Кольцо - базовая топология компьютерной сети, в которой рабочие
станции подключены последовательно друг к другу, образуя замкнутую сеть
(рисунок 1.1);
Рисунок 1.1 – Кольцевая топология
9
В кольце не используется конкурентный метод посылки данных, компьютер
в сети получает данные от соседа и перенаправляет их дальше, если они
адресованы не ему. Для определения того, кому можно передавать данные обычно
используют маркер. Данные ходят по кругу, только в одном направлении.
Достоинства:

Простота установки;

Практически полное отсутствие дополнительного оборудования;

Возможность устойчивой работы без существенного падения скорости
передачи данных при интенсивной загрузке сети, поскольку использование
маркера исключает возможность возникновения коллизий.
Недостатки:

Выход из строя одной рабочей станции, и другие неполадки (обрыв
кабеля), отражаются на работоспособности всей сети;

Сложность конфигурирования и настройки;

Сложность поиска неисправностей.
2) Топология типа «звезда» - базовая топология компьютерной сети, в
которой все компьютеры сети присоединены к центральному узлу (рисунок 1.2);
Рисунок 1.2 – Топология типа «звезда»
10
Когда источник передает сигналы в сетевую среду, данные посылаются
центральному
сетевому
устройству
(концентратору),
затем
концентратор
переправляет их устройству в соответствии с адресом, содержащимся в данных.
Достоинства:

Выход из строя одной рабочей станции не отражается на работе всей
сети в целом;

Хорошая масштабируемость сети;

Лёгкий поиск неисправностей и обрывов в сети;

Высокая производительность сети;

Гибкие возможности администрирования.
Недостатки:

Выход из строя центрального узла обернётся неработоспособностью
сети в целом;

Конечное число рабочих станций, т.е. число рабочих станций
ограничено количеством портов в центральном концентраторе.
3) Древовидная топология (топология типа «расширенная звезда») образуется
в
основном
в
виде
комбинаций
вышеназванных
топологий
вычислительных сетей. Основание дерева вычислительной сети располагается в
точке (корень), в которой собираются коммуникационные линии информации
(ветви дерева) (рисунок 1.3).
Рисунок 1.3 – Древовидная топология
11
Подавляющее число современных компьютерных сетей строится по
топологии расширенная звезда, в некоторых сегментах которой присутствуют
отдельные управляемые коммутаторы, маршрутизаторы или серверы. Стоит
отметить, что высокобюджетное управляемое сетевое оборудование размещается
обычно только на уровне ядра или уровне распределения. Остальные участки сети
обычно построены на неуправляемых коммутаторах, иногда даже без учета
соображений латентности и магистральных потоков (корпуса в полном объеме
подключаются в обычный порт какого-либо простого коммутатора) (рисунок 1.4).
Динамически масштабируясь, такие сети оказываются подвержены огромной
дополнительной нагрузке, как по объемам трафика, так и по их управлению.
Рисунок 1.4 – Типичная сеть масштаба одного здания
Большинство сетей структурировано
на центральном агрегирующем
коммутаторе с помощью технологии 802.1q VLAN (VirtualLAN), как показано на
рисунке 1.5. Использование этой технологии обеспечивает сегментацию общей
сети на множество автономных подсетей, потоки данных между которыми могут
проходить только через маршрутизатор.
12
Рисунок 1.5 – Разделение сети на автономные подсети с помощью
VirtualLAN
Главное требование, предъявляемое ко всем компьютерным сетям в
независимости от способа их построения, - это выполнение их основной функции
- предоставление пользователям возможности доступа к разделяемым ресурсам
сети. Все остальные требования связаны с качеством выполнения основной
функции. Для разных логических типов сетей приоритетными параметрами могут
являться
производительность,
защищенность,
расширяемость,
надежность,
совместимость,
масштабируемость
и
управляемость,
совокупность
этих
параметров.
В традиционных аппаратно-ориентируемых сетях коммутаторы второго
уровня представляют собой изолированную систему, в которой основные
функции устройства выделены в три категории, называемые уровнями – уровень
данных, уровень контроля и уровень управления.
Уровень данных состоит из множества портов, отвечающих за прием и
передачу кадров и таблицы пересылки, определяющей логику процесса передачи.
Уровень данных берет на себя ответственность за буферизацию кадров,
постановку кадров в очередь, модификацию заголовка кадра и процесс передачи.
Если кадр поступил на порт, и данные в его заголовке уже присутствуют в
таблице передачи, то он будет отправлен по адресу назначения без участия двух
13
других уровней, в противном случае кадр будет обработан вышестоящим уровнем
контроля.
Уровень
контроля
главным
образом
необходим
для
поддержания
актуальной информации в таблице передачи, для того чтобы уровень данных мог
самостоятельно обрабатывать максимально высокий процент поступающего
трафика. Уровень контроля также координирует работу большинства протоколов
этого уровня, таких как STP (протокол связующего дерева) и SPB (протокол
мостового соединения по кратчайшему пути), которые взаимодействуют с
таблицей передачи и формируют активную топологию сети.
Уровень управления используется для конфигурирования устройства,
собирая и/или модифицируя данные от нижестоящих уровней. Взаимодействие
сетевого администратора с уровнем управления коммутатора происходит с
помощью специализированной системы управления сетевым устройством.
Как
было
отмечено
ранее,
к
недостаткам
технологии
аппаратно-
ориентируемых сетей можно отнести недостаток управляемости, гибкости и
масштабируемости. Также разработка и внедрение новых сетевых протоколов
(или новых версий уже существующих протоколов) потребует полную замену
сетевого оборудования в целом.
Обобщенная схема взаимодействия уровней данных, контроля и управления
представлена на рисунке 1.6.
Рисунок 1.6 – Аппаратно-определяемая архитектура коммутатора
14
На сегодняшний день большинство экспертов уверены в том, что
технология Ethernet станет основой для построения единой конвергентной
сетевой инфраструктуры центров обработки данных и крупных корпоративных
сетей. Институт IEEE разрабатывает стандарты, которые должны обеспечить
гарантированную полосу пропускания и контроль потока для трафика с учетом
его приоритета, а также более усовершенствованные механизмы управления
потоками. С этими нововведениями Ethernet сможет заменить в центрах
обработки данных существующие сети FibreChannel и Infiniband, а также
существенно повысить производительность работы новых систем хранения
данных на основе протокола iSCSI, необходимого для установки взаимодействия
с ними и их управления.
Постоянно совершенствуясь, Ethernet превратился сегодня в наиболее
масштабируемую и экономически эффективную технологию для построения
сетей на базе стека TCP/IP. Благодаря своей гибкости, Ethernet сегодня
доминирует в большинстве сетевых сред. Современные технологии обеспечивают
пропускную способность в 10 Гбит/с (на один канал), в ближайшем будущем
прогнозируется возрастание скорости до 100 Гбит/с, а в более отдаленной
перспективе возможно появление терабитного варианта Ethernet.
Традиционные Ethernet сети обладают архитектурными недостатками,
связанными с принципом доступа к среде: непредсказуемым временем задержки,
увеличением нагрузки на центральные процессоры серверов, снижением
производительности существующей инфраструктуры в результате использования
части пропускной способности сети для передачи трафика сети хранения;
проблемами с обеспечением безопасности передаваемого трафика. Традиционная
технология Ethernet не пригодна для передачи критичного к потерям трафика, а
также не может играть роль надежного транспорта канального уровня (велика
вероятность появления коллизий).
Усилиями многих организаций на протяжении ряда лет велись работы над
усовершенствованием традиционного протокола Ethernet. Итогом их совместной
15
работы стал набор усовершенствований, получивших название Converged
Enhanced Ethernet (CEE), Data Center Bridging (DCB) и Cisco Data Center Ethernet
(DCE). В их основе положены одни и те же базовые спецификации. Вместе с тем
необходимо учитывать, что DCE содержит расширенный набор возможностей по
сравнению с CEE и DCB. Data Center Ethernet представляет собой архитектуру на
базе набора открытых стандартов расширений Ethernet, которая предназначена
для улучшения и расширения функционала классического Ethernet в соответствии
с требованиями, предъявляемыми к Ethernet как к конвергентному транспорту
современного ЦОД.
DCE включает в себя два основных компонента: набор расширений
Ethernet и аппаратные
средства,
обеспечивающие
внутреннюю передачу
трафика без потерь (Lossless Ethernet Switch Fabric).
Одним из прогрессивных методов канальной коммутации в Интернет
является
технология
многопротокольной
коммутации
на
основе
меток
(Multiprotocol Label Switching — MPLS). В сети MPLS, пакетам данных
присваиваются особые метки. Решение о передаче пакета данных другому узлу
сети осуществляется только на основании метки без необходимости изучения
пакета данных. Такая технология сделала возможным создание виртуального
канала связи, использующего любой протокол канального и сетевого уровней
независимо от среды передачи. Классификация трафика по нескольким
параметрам позволяет маршрутизировать трафик каждого класса по специально
оптимизированному пути сетевым администратором. При точном планировании
маршрутов и правил технология MPLS обеспечивает высокий уровень контроля
над трафиком. В свою очередь это обстоятельство является предпосылкой к более
производительной работе
сети,
позволяет гарантировать
качество
услуг,
позволяющее адаптировать сеть к потребностям пользователей. Критерии,
применимые в MPLS сетях для классификации пакетов, различаются в
зависимости от задач.
16
1.2 Программно-определяемые сети
Базовые идеи программно-определяемых сетей были сформулированы
специалистами
университетов Стэнфорда
и Беркли еще
в 2006 г., и
инициированные ими исследования нашли поддержку у крупных операторов и
интернет-компаний (Google, Deutsche Telekom, Facebook, Microsoft, Verizon и
Yahoo). Это привело к тому, что в марте 2011 г. был образован консорциум Open
Networking Foundation (ONF), занимающийся стандартизацией и развитием
протокола OpenFlow – протокола, определяющего взаимодействие между
уровнем управления и уровнем данных в программно-определяемых сетях.
Состав консорциума быстро расширяется, в 2013 г. в него вошли более 100
компаний, включая Brocade, Citrix, Oracle, Dell, Ericsson, HP, IBM, Marvell, NEC,
VMware и др. Из российских компаний в ONF входит только компания Brain4Net
(Программируемые сети).
Заинтересованность
ИТ-компаний
в
программно-определяемых
сетях
обуславливается тем, что эта технология позволяет повысить эффективность
использования
сетевого
оборудования
на
25–30%,
снизить
затраты
на
эксплуатацию сетей на 30%, максимально возможно упростить процесс
администрирования сети, повысить сетевую безопасность и предоставить
пользователям возможность программно создавать новые сервисы и оперативно
загружать их в сетевое оборудование.
В части исследований и разработок ключевые заделы в развитии технологии
программно-определяемых сетей связаны с развиваемой в США программой
GENI (Global Environment for Network Innovations) - Программой исследования
будущего Интернета, объединяющей около 40 ведущих университетов США;
деятельностью объединенного центра Стэнфорда и Беркли (Open Network
Research Center), выполняющего исследования и разработки в области проекта
Internet2; а также с Седьмой рамочной программой научных исследований,
технологического развития и демонстрационной деятельности Европейского
17
Союза (The Seventh Framework Programme
for Research, TechnoLogicaL
DeveLopment and Demonstration) Ofelia и проектом FEDERICA.
В отличие от аппаратно-определяемых сетей, в которых уровни данных и
контроля
неразрывно
связаны
между
собой,
технология
программно-
определяемых сетей предполагает отделение уровня данных от уровня контроля.
Процесс пересылки кадра, который включает в себя логику обработки
поступившего кадра, основываясь на его MAC-адресе, IP-адресе или VLAN ID,
остается
закрепленным
за
уровнем
данных.
Применительно
к
новому
поступившему кадру могут быть применены следующие операции: отправить
кадр, отбросить кадр (например, при переполнении буфера коммутатора),
уничтожить кадр или сделать копии кадра (если у получателя мультикастовый
MAC-адрес). Алгоритмы, с помощью которых формируется таблицы пересылки,
относятся к уровню контроля. В рамках технологии программно-определяемых
сетей уровень контроля также определяет, по какому принципу таблицы
пересылки и логика работы уровня данных должны быть сконфигурированы.
Стоит
отметить
важный
момент,
так
как
в
традиционной
аппаратно-
ориентируемой сети каждому устройству сопоставлен свой уровень контроля,
одной из главных задач уровня контроля, реализованного в программноопределяемой сети в виде отдельного контроллера, является обеспечение
синхронизации всех таблиц на всех сетевых устройствах в одной сети.
Такой подход с одной стороны упрощает управление сетью и повышает ее
масштабируемость (контроллер может быть размещен как на физическом, так и
виртуальном сервере), с другой – позволяет отказаться от дорогостоящего
сетевого оборудования в пользу более дешевых моделей с поддержкой протокола
OpenFlow.
Благодаря
управления,
снятию
с
коммутаторов
программно-определяемая
нагрузки
сеть
по
позволяет
обработке
этим
тракта
устройствам
направить все свои ресурсы на ускорение перемещения трафика, что существенно
повышает производительность всей сети. При этом за счет виртуализации
18
управления сетью снижаются расходы на их построение и сопровождение. По
результатам тестов, проведенных на базе крупнейших провайдеров США,
использование программно-определяемых сетей позволяет на 20–30% увеличить
утилизацию ресурсов центров обработки данных и в несколько раз снизить
эксплуатационные расходы.
Обобщенная
схема
архитектуры
программно-определяемой
сети
представлена на рисунке 1.7.
Рисунок 1.7 – Архитектура программно-определяемых сетей
Как видно из рисунка 1.7, архитектура программно-определяемых сетей
предполагает разбиение компонентов на 3 уровня - уровень приложений, уровень
контроля и уровень сетевой инфраструктуры.
Отметим
недостатки данной архитектуры.
К
ним
можно отнести
сосредоточение всего инструментария конфигурирования и управления сетью на
одном устройстве – контроллере, и как следствие, связанными с этим вопросами
безопасности и отказоустойчивости всей сети в целом.
19
Рисунок 1.8 – Общий принцип работы программно-определяемой сети
На рисунке 1.8 представлен общий принцип работы программноопределяемой сети. Устройства программно-определяемой сети (SDN devices)
имеют функционал отправки (Forwarding) для принятия решения как поступать с
каждым полученным кадром (рисунок 1.9). Устройства также хранят специальные
данные, которые влияют на принятие решения как обработать и отправить
полученный кадр. Данные представляются в виде потоков и задаются
специальным выделенным устройством для управления сетью - контроллером.
Рисунок 1.9 – Структура OpenFlow кадра
Поток описывает набор кадров, отправленных из одной конечной точки
сети (или множества точек) в другую. Конечные точки могут быть определены
парой IP-адрес – TCP/UDP порт, VLAN конечные точки, туннели третьего уровня
и др. Один набор правил устанавливает действия, которые устройство должно
выполнить для всех кадров, принадлежащих определенному потоку. На каждом
сетевом устройстве существует таблица потоков, которая хранит все потоки и
20
соответствующие им действия, которые устройство должно будет выполнить,
когда кадр, соответствующий определенному потоку, придет на порт. Если кадр
не имеет соответствий ни с одним из типов потоков, определенных в таблице,
коммутатор может отбросить кадр или отправить его контроллеру в сообщении
packet-in. Затем контроллер определяет соответствующее правило потока и
посылает его коммутатору в сообщении packet-out и flow_mod. Взаимодействие
сетевого устройства с контроллером происходит с помощью Southbound API и
протокола
OpenFlow.
Процесс
передачи
сообщения
через
коммутатор
программно-определяемой сети представлен на рисунке 1.10.
Рисунок 1.10 – Процесс передачи сообщения через коммутатор в
программно-определяемой сети
Контроллер в программно-определяемой сети отвечает за абстрагирование
сети из устройств, которые он контролирует, и предоставление этой абстракции
вышестоящему уровню приложений. Связь с уровнем приложений реализуется
через
Northbound
API,
использующий
API
высокоуровневых
языков
программирования. Контроллер позволяет приложениям задавать потоки на
сетевых устройствах и берет на себя работу по обработке кадров, которые ему
посылают сетевые устройства. Хранение актуальной сетевой топологии дает
контроллеру возможность просчитывать оптимальные маршруты доставки кадров
в сети предсказуемым образом.
Архитектура контроллера программно-определяемой сети представлена на
рисунке 1.11.
21
Рисунок 1.11 – Архитектура контроллера в программно-определяемой сети
В настоящее время существует большое количество различных реализаций
контроллеров, начиная от простых С-подобных (NOX) и заканчивая Javaподобными, такими как Beacon и Floodlight. Интерфейсы этих контроллеров
могут быть реализованы как на языке, на котором написан сам контроллер, либо с
использованием альтернативных языков – REST или Python. В качестве opensource решения существует возможность использования Open Network Operating
System
(ONOS)
контроллера,
поддерживающего
актуальные
версии
спецификации, и имеющего гибкий функционал для работы.
В программно-определяемых сетях все сетевые устройства объединяются
под управлением единой сетевой операционной системы (СОС), которая
обеспечивает приложениям доступ к управлению всей сетью и постоянно
отслеживает конфигурацию сетевых устройств.
В отличие от традиционного толкования термина СОС как операционной
системы, интегрированной со стеком сетевых протоколов, в данном случае под
сетевой операционной системой мы понимаем программную систему, которая
обеспечивает мониторинг, и управление ресурсами всей сети, а не конкретного
узла. Операционная система не управляет сетью, она предоставляет программный
22
интерфейс (API) для управления сетью. Таким образом, фактически решение
задачи управления сетью выносится на уровень приложений, реализованных на
основе API сетевой операционной системы.
Сетевая операционная система формирует данные о состоянии всех
ресурсов сети и обеспечивает доступ к ним для приложений управления сетью.
Эти приложения управляют разными аспектами функционирования сети, включая
построение топологии, принятие маршрутизирующих решений, балансировку
нагрузки и др.
Для реализации этого подхода был разработан открытый протокол
OpenFlow для управления сетевым оборудованием, не ориентированный на
продукты какого-то отдельного производителя. С помощью этого протокола
сетевые администраторы сами могут определять и контролировать, какие узлы,
при каких условиях и с каким качеством могут взаимодействовать в сети.
Приложения
в
программно-определяемой
сети
работают
поверх
контроллера, взаимодействуя с сетью через доступный Northbound API
контроллера. Приложения отвечают за конфигурирование типов потоков, которые
хранятся в таблице потоков на сетевых устройствах. Используя API контроллера
приложения могут:
1)
конфигурировать
потоки
для
отправки
кадров
между
двумя
конечными устройствами по наилучшему пути;
2)
балансировать нагрузку трафика по нескольким путям или для набора
конечных точек;
3)
реагировать на изменения топологии сети, такие как сбои каналов и
добавление новых устройств и путей;
4)
перенаправлять
трафик
для
целей
проверки,
аутентификации,
сегрегации и аналогичных задач, связанных с безопасностью.
Наиболее важной задачей приложения в программно-определяемой сети
является выполнение любой функции, для которой оно было спроектировано,
будь то балансировка нагрузки, межсетевой экран или какая-либо другая
23
операция. Как только контроллер завершил работу по инициализации устройств и
передал данные о топологии сети приложению, приложение тратит большую
часть времени обработки, отвечая на события. Несмотря на то, что основные
функциональные возможности приложения могут варьироваться от одного
приложения к другому, поведение приложения определяется событиями,
исходящими от контроллера, а также внешними входами. Внешние входы могут
включать в себя системы сетевого мониторинга, такие как Netflow, IDS или узлы
BGP. Приложение оказывает влияние на сеть, отвечая на события, как показано на
рисунке
1.12.
Приложение
представляется
в
сети
как
слушатель
для
определенных событий, а контроллер при возникновении такого события
вызывает метод обратного вызова приложения. Некоторые примеры событий,
обрабатываемых приложением программно-определяемой сети:

End-user Device Discovery (обнаружение устройства конечного
пользователя);

Network Device Discovery (обнаружение сетевого устройства);

Incoming Packet (входящий кадр).
В первых двух случаях, события отправляются в приложение при
обнаружении нового конечного пользователя (по его MAC-адресу) или нового
сетевого
устройства
(например,
коммутатор,
маршрутизатор
или
точка
беспроводного доступа). События входящего кадра отправляются приложению
программно-определяемой сети, в тот момент, когда кадр принят с сетевого
устройства, либо из-за правила, предписывающего сетевому устройству переслать
кадр контроллеру, либо потому что на сетевом устройстве в таблице потоков
отсутствует правило, применимое к этому потоку.
24
Рисунок 1.12 – Схема взаимодействия приложения с контроллером
Протокол OpenFlow определяет API для связи между контроллером и
коммутаторами. Из этого следует логичный вывод, что и контроллер, и
коммутаторы должны понимать протокол OpenFlow. Контроллер управляет
таблицами потоков коммутатора, добавляя, обновляя и удаляя записи потока. Это
происходит реактивно (когда контроллер получает пакет от коммутатора) или
проактивно в соответствии с реализацией контроллера OpenFlow. Контроллер
связывается с коммутаторами через защищенный канал. Коммутатор OpenFlow
поддерживает пересылку на основе потока, сохраняя одну или несколько таблиц
потоков.
Таблицы
потоков
используются
для
определения
того,
как
обрабатываются данные пакеты. Каждая запись таблицы потоков содержит набор
полей пакетов для соответствия (например, Ethernet-адресов и IP-адресов) и набор
действий, которые должны применяться после сопоставления (например, порт
отправки, изменение поля или падение). Элементы потока также поддерживают
счетчики для сбора статистики для определенных типов потоков (например,
количества переданных байтов). Когда коммутатор получает пакет, который
вызывает пропуски в процессе сопоставления таблицы переадресации, действие,
которое необходимо предпринять, зависит от записи потока пропущенных
таблиц. Этот пакет может быть перенаправлен на контроллер, передан в
25
следующую таблицу потоков или удален. Когда пакет пересылается контроллеру,
контроллер затем решает, как обрабатывать этот пакет. Контроллер может
отбросить пакет, или он может добавить запись потока, которая дает направление
переключателя о том, как перенаправить аналогичные пакеты в будущем.
Обобщенно все сообщения, которые поддерживает протокол OpenFlow можно
поделить на три группы:

Controller-to-switch
–
сообщения,
инициируемые
контроллером,
которые используются для непосредственного контроля и управлением состояния
коммутатора. Сообщения данного типа могут использоваться контроллером для
установки параметров конфигурации коммутатора, для сбора статистики, для
добавления, удаления и модификации записей в таблицах потоков;

Асинхронные сообщения – сообщения, инициируемые коммутатором,
которые используются для уведомления контроллера о сетевых событиях и
изменениях состояния коммутатора;

Синхронные
сообщения
–
сообщения,
инициируемые
как
контроллером, так и коммутатором.
К сообщениям типа Controller-to-switch относятся следующие типы
сообщений:
1)
Configuration - контроллер устанавливает и запрашивает параметры
конфигурации
коммутатора.
Коммутатор
только
отвечает
на
запросы
контроллера;
2)
Modify-State – сообщение отправляется контроллером для управления
состоянием коммутаторов. Их главная цель заключается в добавлении/удалении и
модификации правил
в OpenFlow
таблицах и
установке
характеристик
(параметров) порта коммутатора;
3)
Packet-out - сообщение используется контроллером для отправки
пакетов из определенного порта на коммутаторе и пересылке пакетов,
полученных с помощью сообщения Packet-in;
26
4)
Role-Request - сообщение используется для изменения текущей роли
контроллера на коммутаторе (для повышения роли с Slave до Master) (для версии
OpenFlow 1.3);
5)
Read-State – сообщение, используемое контроллером при сборе
статистических данных;
6)
Features – сообщение, которым контроллер запрашивает состояние
коммутатора; коммутатор должен ответить с помощью features-ответа;
7)
Asynchronous-Configuration – сообщение используется для установки
фильтра на асинхронные сообщения от коммутаторов;
8)
Barrier – сообщение используется в случае, когда необходима
обработка сообщений в определенном порядке.
К сообщениям второй группы относятся следующие некоторые типы
сообщений:
1)
данное сообщение коммутатор генерирует для всех
Packet-in -
пакетов, которые не имеют соответствующих правил в таблице коммутатора.
Затем коммутатор отправляет это сообщение контроллеру. Для всех пакетов,
пересылаемых в виртуальный порт CONTROLLER, сообщение Packet-in
отправляется в контроллер. Packet-in сообщение содержит некоторую часть
заголовка пакета (по умолчанию 128 байт), который будет использоваться
контроллером, когда коммутатор будет готов к пересылке пакета;
2)
коммутатор
Flow-Removed - когда правило для нового потока добавляется в
с
помощью
сообщения
flow-mod,
для
него
автоматически
устанавливается значение тайм-аута. После окончания тайм-аута правило должно
быть удалено из-за неиспользуемости правила. Также может быть указан жесткий
тайм-аут, когда запись должна быть удалена независимо от активности потока.
Сообщение flow-mod также определяет, должен ли коммутатор отправлять
сообщение об удалении потока контроллеру, когда поток закончится;
3)
Port-status
–
коммутатор
отправляет
контроллеру при изменении конфигурации порта;
сообщение
Port-status
27
4)
Error – сообщение, с помощью которого коммутатор сигнализирует
контроллеру об ошибке.
Симметричные сообщения могут инициироваться коммутатором или
контроллером без запроса и используются при установлении соединения, а также
при измерении пропускной способности соединения контроллер-коммутатор или
для проверки состояния соединения. К симметричным сообщениям относят:
1)
Hello – сообщение, которыми коммутатор и контроллер обмениваются
при установлении соединения;
2)
Echo – сообщение типа запрос/ответ может отправлять любой
коммутатор или контроллер, и в этом случае обязательно должен быть получен
ответ;
3)
Experimenter
–
сообщение,
для
обеспечения
дополнительной
функциональности при проведении тестовых исследований.
Начиная с версии 1.1, протокол OpenFlow поддерживает несколько таблиц
потоков и обработку конвейера. Поэтому продолжение процесса сопоставления в
следующей таблице потоков может быть одним из вариантов для несовпадающих
пакетов. Были выпущены различные версии OpenFlow, а функции каждой версии
следующие. Версия 1.2 поддерживает более гибкую структуру сопоставления,
которая использовалась как статическая структура с фиксированной длиной, и
больше протоколов, таких как IPv6. Версия 1.3 обеспечивает большую поддержку
таких протоколов, как бит MPLS BoS и заголовки расширений IPv6. Он также
включает в себя
лучшее
выражение
возможностей коммутатора
(т.
е.
согласование возможностей рефакторинга) и улучшает возможности измерения
(например,
для
измерения
потока).
Версия
1.4
улучшает
расширяемое
соответствие OpenFlow, представленное в версии 1.2, которое дает пользователю
более гибкие возможности классификации для соответствия полям заголовков
пакетов и классификации потоков. Версия 1.4 также поддерживает оптические
порты. В таблице 1 представлены сетевые коммутаторы от крупнейших
производителей с поддержкой протокола OpenFlow.
28
Таблица 1 – Сетевые коммутаторы с поддержкой OpenFlow
Фирма-производитель
Модель
Поддерживаемая версия
протокола
IBM
RackSwitch G8264
v 1.0
Juniper
Junos MX- Series
v 1.0
NEC
PF5820
v 1.0
Brocade
NetIron CES 2000 Series
v 1.0
Hewlett-Packard
8200zl,
6600,
6200zl, v 1.0
публично
выпущены
5400zl
На
сегодняшний
день
различные
OpenFlow-
совместимые контроллеры. Рассмотрим наиболее распространенные из них и
дадим им оценочную характеристику.
Контроллер NOX представляет собой платформу управления сетью,
обеспечивающую высокоуровневый программируемый интерфейс, использование
которого позволяет управлять сетью и/или создавать приложения для управления
сетью. Так как NOX является контроллером с поддержкой OpenFlow, то
управление сетью производится на уровне потоков и подразумевается, что
контроллер определяет, как каждый поток маршрутизируется в сети.
В отличие от стандартных средств построения сети NOX позволяет
централизованно программировать модель для всей сети. Благодаря своим
особенностям NOX может использоваться для поддержки как крупных
корпоративных сетей с сотнями коммутаторов (с поддержкой многих тысяч
узлов), так и небольших сетей, состоящих из нескольких узлов. Ядро NOX
предоставляет приложениям абстрактное представление сетевых ресурсов,
включая топологию сети и расположение всех обнаруженных узлов.
Основные цели NOX:
1)
обеспечить
платформу,
которая
позволяет
разработчикам
и
исследователям вводить новшества в домашних или корпоративных сетях,
29
используя реальные сетевые аппаратные средства. Разработчики, использующие
NOX контроллер, могут управлять всеми подключениями в сети, включая
передачу, маршрутизацию, контроль узлов и пользователей, которым разрешается
связь.
2)
предоставить нужное сетевое программное обеспечение операторам.
На текущий момент с помощью NOX можно централизованно управлять
всеми коммутаторами в сети, разрешением на уровне пользователей и на уровне
узлов с помощью механизма политик.
Maestro – сетевая операционная система для организации приложений для
управления сетью. Maestro предоставляет интерфейсы для реализации модульных
приложений управления сетью, для доступа и изменения состояния сети, а также
для координации их взаимодействия.
Платформа Maestro предоставляет интерфейсы для:
1)
внедрения новых пользовательских функций управления путем
добавления построенных из модулей компонентов управления;
2)
поддержания состояния сети от имени управляющих компонентов;
3)
компоновки компонентов управления, определяя последовательность
исполнения и общее состояние компонентов сети.
Кроме того, Maestro использует параллелизм на одной машине, чтобы
улучшить производительность системы. Основной особенностью программноопределяемой сети является то, что OpenFlow контроллер отвечает за начальную
установку каждого потока, связываясь с подчиненными коммутаторами. Таким
образом, производительность контроллера может быть узким местом. Maestro
пытается уменьшить усилия программистов по управлению распараллеливанием,
выполняет большую часть утомительного и сложного управления распределением
рабочей нагрузки и планирования рабочих потоков. Проект Maestro переносим и
масштабируем, поскольку разработан с использованием платформы Java и
поддерживает многопоточность.
30
Beacon – быстрый кроссплатформенный модульный контроллер OpenFlow,
который поддерживает работу на основе событий и на основе потоков.
К главным особенностям контроллера Beacon можно отнести:
1)
устойчивость – Beacon разрабатывался в течение двух лет и
использовался в нескольких научно-исследовательских проектах. Beacon в
настоящее время функционирует на 100 виртуальных и 20 физических
коммутаторах в экспериментальном центре обработки данных и работал в течение
многих месяцев без сбоев;
2)
кроссплатформенность – контроллер Beacon написан на Java и
работает на многих платформах от высококачественных многоядерных серверов
Linux до телефонов на ОС Android;
3)
динамичность
–
пакеты
Beacon
запущены/остановлены/обновлены/установлены
во
время
могут
быть
выполнения
не
прерывая другие независимые пакеты.
Trema – платформа контроллера OpenFlow, которая включает все
необходимое для самостоятельной разработки контроллеров OpenFlow на языке
Ruby и/или C. Дерево исходных кодов включает все основные библиотеки и
функциональные модули, которые работают с интерфейсами коммутаторов
OpenFlow. Также включено несколько примеров контроллеров OpenFlow,
разработанных с помощью Trema, а для отладки имеется плагин для Wireshark.
Helios – расширяемый контроллер OpenFlow, разработанный корпорацией
NEC и рассчитанный на исследователей в области программно-определяемых
сетей. Он включает в себя специализированную программную оболочку,
позволяющую производить различные экспериментальные исследования.
BigSwitch
–
контроллер
OpenFlow
с
закрытым
исходным
кодом,
основанный на контроллере Beacon. Контроллер BigSwitch использует удобную в
использовании консоль централизованного управления сетью, что позволяет
использовать контроллер в условиях развитой инфраструктуры крупного
предприятия.
31
POX контроллер – open-source проект, разрабатываемый на языке Python
под лицензией GNU License (официально поддерживает Windows, Mac OS, Linux).
POX в настоящий момент поддерживает OpenFlow 1.0 (частично присутствует
поддержка Openflow 1.1), также имеется поддержка Open vSwitch/Nicira extensions
(специальное расширение протокола OpenFlow, для создания более гибких
настроек для маршрутизаторов). Контроллер POX никак не управляет трафиком –
его функциональность создается запуском отдельных компонент вместе с
контроллером. POX в основном используется для исследований программноопределяемых сетей, так как он предоставляет простое и удобное Northbound API
для решения небольших задач. Основная цель этого проекта – разработка и
исследование парадигмы программно-определяемых сетей - для полноценных
коммерческих приложений данный контроллер не подходит из-за ограниченного
API и медленной работы.
Floodlight - Контроллер, разрабатываемый на Java 1.7+ под лицензией
Apache 2.0. (рисунок 1.13). Данный контроллер поддерживает только топологии
без циклов между различными компонентами связности. Имеет модульную
структуру, то есть перед запуском в специальный конфигурационный файл
добавляются названия сервисов, которые будут использованы.
Рисунок 1.13 – Архитектура контроллера Floodlight
32
Данный контроллер поддерживает следующие сервисы:

Forwarding – стандартный модуль, обеспечивающий реактивное
конфигурирование OpenFlow маршрутизаторов;

Static Flow Entry Pusher – специальное приложение для добавления
flow записей в выбранный маршрутизатор;

Firewall – применение ACL правил, для ограничения трафика
(настраивается через Rest API);

Learning Switch – L2 маршрутизатор (возможна настройка через Rest

Load Balancer (балансировщик нагрузки) – балансировка tcp, ping, udp
API);
трафика.
Для разработки приложений на базе данного контроллера, предоставляется
RestFull Java API.
Модули контроллера реализуют общие функции для использования в
большинстве приложений, такие как:
1)
Обнаружение, выявление и предоставление информации о состоянии
элементов сети и событий от них (топология, устройства, потоки);
2)
Обеспечение взаимодействия контроллера с коммутаторами сети
(через OpenFlow протокол);
3)
Управление модулями FloodLight и распределение ресурсов таких как
память, потоки, тесты;
4)
Web-интерфейс и сервер для отладки (Jython).
OpenDaylight - open-source проект с гибкой модульной платформой для
встраивания различных плагинов (рисунок 1.14). Проект разрабатывается под
лицензией EPL v1.0 (Eclipse public license) при поддержке Linux Foundation. Так
как проект разрабатывается на языке Java (Java 1.7), он, следовательно, является
кроссплатформенным. Последний релиз OpenDaylight полностью поддерживает
протокол OpenFlow 1.3, BGP-LS, протокол OVSDB, PCEP, SNMP.
К архитектурным принципам OpenDaylight можно отнести:
33
1)
Модульность
и
расширяемость
–
модульный,
расширяемый
контроллер поддерживает установку, удаление и обновление используемых служб
во время работы (без выключения);
2)
Множественная поддержка Southbound протоколов – использование
различных сетевых протоколов (OpenFlow, BGP и др.);
3)
Служебный абстрактный уровень (Service Abstraction Layer) –
уровень, предоставляющий использование различных Northbound протоколов;
4)
Разделяемость – управление различными частями сети, при помощи
разных компонент контроллера.
Рисунок 1.14 – Архитектура OpenDaylight платформы
В состав платформы входят:

Модульный, масштабируемый SDN-контроллер, соответствующий
спецификации OSGi (Open Services Gateway Initiative);

Плагин для интеграции поддержки протокола OpenFlow через
абстрактный SAL-интерфейс SDN-контроллера (Service Abstraction Layer);

Библиотека с реализацией протокола OpenFlow 1.3;

Компонент с поддержкой протокола для управления и конфигурации
Open vSwitch (Open vSwitch Database) и другими серверами OVSDB;
34

YANG Tools - управляющие утилиты netconf и yang, написанные на
языке Java;

Система управления трафиком с использованием BGP-LS (топология,
в которой используется протокол BGP) и PCEP (протокол вычисления путей).
Сравнительная характеристика контроллеров программно-определяемых
сетей представлена в таблице 2.
Таблица 2 – Сравнительные характеристики наиболее распространенных
Язык разработки
Поддержка
графического
интерфейса
Открытость
исходного кода
Southbound API
Northbound API
Балансировка
нагрузки
Мониторинг сети
Маршрутизация
Многопоточность
контроллеров
1
2
3
4
5
6
7
8
9
10
NOX
C++/Python
Python +
Открытый
OF 1.0
REST
-
Частич
-
Поддерживается
Qt4
ный
API
Maestro
Java
-
Открытый
OF 1.0
REST API
+
+
-
Поддерживается
Beacon
Java
Веб-
Открытый
OF 1.0
REST
+
-
-
Поддерживается
-
Частич
+
Поддерживается
+
Не
форма
Trema
C/Ruby
-
API
Открытый
OF 1.0
REST
ный
API
Helios
C
-
Закрытый
OF 1.0
REST
-
-
поддерживается
API
BigSwit
ch
Java
-
Закрытый
OF 1.0
REST
API
-
-
+
Не
поддерживается
35
Продолжение таблицы 2
1
2
3
4
5
6
7
8
9
10
POX
Python
Python +
Открытый
OF 1.0
REST
-
Частичны
-
Поддерживается
Qt4
Floodlight
Java
Веб-
Открытый
форма
OpenDaylight
Java
Веб-
й
API
Открытый
форма
OF 1.0,
REST
1.3
API
OF 1.0, 1.4,
REST
BGP/LS,
API
-
+
+
Поддерживается
+
+
+
Поддерживается
LISP,
SNMP
Проанализировав таблицу номер 2, можно выделить несколько ключевых
особенностей современных контроллеров. Закрытость исходного кода, присущая
контроллерам Helios и BigSwitch не позволяет вносить в контроллер какие-либо
изменения, что не соответствует поставленной задаче по дальнейшему развитию
сетевой операционной системы. Отсутствие хорошей документации по сетевой
операционной системе не позволяет эффективно расширять ее возможности, как
следствие, контроллеры Trema и Maestro, которые мало документированы, также
необходимо исключить из дальнейшего рассмотрения.
POX
контроллер
используется
для
проверки
производительности
программно-определяемых сетей на различных топологиях сетей и тестирования
протокола OpenFlow. Контроллеры Floodlight и OpenDaylight можно объединить в
одну категорию, как два проекта, разрабатываемых на языке Java. Хотя Floodlight
можно назвать переходным между POX и OpenDaylight, так как последний
поддерживает любые топологии сетей и большое количество протоколов
маршрутизации, Floodlight является более гибким и лучше подходит для решения
реальных бизнес-задач. Эти три контроллера с успехом могут применяться в
программно-определяемой сети корпоративной организации, в независимости от
ее масштабов.
Среди
рассмотренных
проектов
заметно
выделяется
контроллер
OpenDaylight. Есть поддержка распределенной модели, OSGi фреймворк
36
позволяет загружать модули не вызывая перегрузки контроллера, активная
поддержка Linux-сообщества (спонсоры: IBM, Cisco, Nicira, OpenFlow Network
Foundation).
37
2 МОДЕЛИРОВАНИЕ СУЩЕСТВУЮЩЕГО УЧАСТКА
КОМПЬЮТЕРНОЙ СЕТИ ОБРАЗОВАТЕЛЬНОЙ ОРГАНИЗАЦИИ
2.1 Выбор инструментального средства для моделирования
компьютерной сети традиционной архитектуры
Существует множество инструментальных средств для построения и
настройки компьютерных сетей. Рассмотрим некоторые из них:

UNetLab;

Cisco packet tracer;

GNS3.
Рисунок 2.1 – UNetLab
UNetLab — (Unified Networking Lab, UNL) это мультивендорная и
многопользовательская платформа для создания и моделирования самых
различных
лабораторий
и
дизайнов,
которая
позволяет
смоделировать
виртуальную сеть из маршрутизаторов, коммутаторов, устройств безопасности и
других сетевых устройств (рисунок 2.1).
UNetLab — полностью бесплатное ПО. Есть возможность использования
неограниченного количества экземпляров сетевого оборудования (роутеров,
коммутаторов, устройств безопасности и т.д.) в зависимости от требуемых задач.
Для сравнения, Cisco VIRL Personal Edition имеет ограничение на количество
используемых устройств (от 10 до 20 в различных редакциях). Набор
поддерживаемых устройств в VIRL достаточно ограничен, - нет поддержки
38
аппаратных межсетевых экранов (Cisco ASA), равно как и маршрутизаторов с
Serial-интерфейсом.
Платформа UNetLab предоставляет широкий спектр сетевого оборудования
для возможного использования, например, Cisco IOL-образы, образы из VIRL
(vIOS-L2 и vIOS-L3), образы ASA Firewall (как портируемые 8.4(2), 9.1(5), так и
официальные ASAv), образ Cisco IPS, образы XRv и CSR1000v, образы Dynamips
из GNS, образы Ciscо vWLC и vWSA, а также образы других производителей,
таких как Juniper, HP, Checkpoint и т.д.
Кроме
того,
начиная
с
версии
0.9.54
в
UNetLab
появился
многопользовательский функционал. На одной и той же виртуальной машине,
каждый авторизованный пользователь может создавать свои исследовательские
стенды независимо друг от друга, а также совместно работать с общим стендом,
который
разделяют
несколько
пользователей
одновременно.
При
этом
пользователи запускают общий стенд независимо друг от друга.
Самые существенные плюсы UNetLab:

полностью бесплатен;

практически полноценная поддержка L2 уровня (за счет EOS-
коммутатора, который по своему функционалу полностью повторяет Ciscoкоммутатор);

широкая поддержка Cisco оборудования;

число запускаемых узлов ничем не ограничено, кроме ресурсов
рабочей станции (CPU, RAM);

мультивендорность;

многопользовательский функционал;

низкие требования к ресурсам рабочей станции.
Данная платформа подойдет как новичкам для подготовки к CCNA/CCNP,
так и профессионалам для подготовки CCIE Routing and Switching, CCIE Security,
CCIE Service Provides, CCIE Data Centers и т.д., а также для выполнения других
разнообразных инженерных задач.
39
Cisco Packet Tracer — симулятор сети передачи данных, выпускаемый
фирмой Cisco Systems (рисунок 2.2). Cisco Packet Tracer позволяет моделировать
работоспособные макеты сетей, настраивать (с использованием команд Cisco IOS)
маршрутизаторы
и
коммутаторы,
пользователями
(через
облако).
взаимодействовать
В
симуляторе
между
несколькими
реализованы
серии
маршрутизаторов Cisco 800, 1800, 1900, 2600, 2800, 2900 и коммутаторов Cisco
Catalyst 2950, 2960, 3560, а также межсетевой экран Cisco ASA 5505.
Беспроводные устройства представлены маршрутизатором Linksys WRT300N,
точками доступа и сотовыми вышками. Кроме того, есть серверы DHCP, HTTP,
TFTP, FTP, DNS, AAA, SYSLOG, NTP и EMAIL, рабочие станции, различные
модули,
добавляемые
к
компьютерам
и
маршрутизаторам,
смартфоны,
концентраторы, а также облако, эмулирующее WAN. Объединять сетевые
устройства можно с помощью различных типов кабелей, таких как прямые и
обратные патч-корды, оптические и коаксиальные кабели, последовательные
кабели и телефонные пары.
Рисунок 2.2 – Cisco Packet Tracer
Cisco Packet Tracer имеет два рабочих пространства: логическое и
физическое.
Логическое
логическую
топологию
пространство
сети,
позволяет
размещать,
пользователям
подключать,
строить
кластеризировать
40
виртуальные сетевые устройства. Физическое пространство позволяет графически
увидеть логическую сеть, давая понятие о масштабах и трудоустройствах
оборудования, таких как маршрутизаторы, коммутаторы, хосты, которые будут в
работать реальной среде. Физическое пространство 18 также дает представление
сети, в том числе нескольких городов, зданий, сооружений, монтажных шкафов.
Cisco Packet Tracer успешно позволяет создавать даже сложные макеты
сетей, проверять на работоспособность топологии. Однако, стоит заметить, что
реализованная функциональность устройств ограничена и не предоставляет всех
возможностей реального оборудования.
GNS3 — Graphical Network Simulator — это графический симулятор сети,
который позволяет смоделировать виртуальную сеть из маршрутизаторов и
виртуальных машин (рисунок 2.3).
Рисунок 2.3 – GNS 3
В зависимости от аппаратной платформы, на которой будет использоваться
GNS3,
возможно
построение
комплексных
проектов,
состоящих
из
маршрутизаторов Cisco, Cisco ASA, Juniper, а также серверов под управлением
сетевых операционных систем. При отсутствии возможности получить доступ к
реальному оборудованию, GNS3 способен заменить полноценную лабораторию.
41
Кроме того, лабораторные работы, выполняемые в GNS3, могут стать
дополнением к занятиям в реальной лаборатории.
Единственным недостатком данного программного обеспечения является
отсутствие возможности полноценной симуляции коммутаторов второго уровня
Cisco. Этот недостаток не будет исправлен в новых версиях, так как его причиной
является кардинальное различие в аппаратной платформе маршрутизаторов и
коммутаторов Cisco. В некоторых случаях данный недостаток получается обойти
при помощи сетевого модуля NM-16ESW. К сожалению, листинг команд немного
отличается в случае использования NM-16ESW и реальных коммутаторов Cisco,
но вполне подходит для образовательных целей.
В состав GNS3 не входят образы IOS/IPS/PIX/ASA/JunOS, так как они
являются частью коммерческих продуктов соответствующих компаний, и
никакого прямого отношения к проекту GNS3 не имеют.
Одной из самых интересных особенностей GNS3 является возможность
соединения проектируемой топологии с реальной сетью. Это дает уникальную
возможность проверить на практике какой-либо проект, без использования
реального
оборудования.
Использование
WireShark
позволяет
провести
мониторинг трафика внутри проектируемой топологии, что дает дополнительную
информацию для понимания изучаемых технологий.
GNS3 абсолютно бесплатен. Это открытое программное обеспечение, и
любой желающий может скачать его с официального сайта проекта в разделе
Download. На данный момент есть версии для Linux, MS Windows XP и Windows
7, а также для Macintosh.
NS3 – Network Simulator 3 - является мощным сетевым симулятором для
моделирования
телекоммуникационных
лицензией GNU GPLv2.
систем
и
распространяется
под
Симулятор решает одну из главных проблем
моделирования сетей – проблему стоимости оборудования. Сетевые симуляторы
являются программными продуктами, позволяющими выполнять имитационное
моделирование телекоммуникационных систем. Применение имитационного
42
моделирования позволяет проводить эксперименты, не разворачивая реальную
сеть, что является трудоемким, дорогостоящим и, как правило, протяженным во
времени процессом. В NS3 разработаны модели беспроводных сетей различных
типов, позволяющие проводить моделирование с движущимися объектами в
трёхмерном пространстве. Кроме того, реализованы модели проводных и
смешанных топологий различной сложности, в том числе, Mesh-сетей на основе
стека протоколов 802.11s. Разработан фреймворк под названием FlowMonitor,
предоставляющий различные, а главное гибкие методы сбора самых различных
показаний с моделируемых сетевых узлов и каналов связи. Симулятор «по
умолчанию» не имеет собственного графического интерфейса, однако с
использованием таких средств как NetAnimator и PyViz, появляется возможность
отображения схемы на экран для наблюдения за работой протокола. Таким
образом, функциональность NS3 превосходит многие коммерческие симуляторы.
В таблице 3 представлена сравнительная таблица программных средств для
моделирования компьютерных сетей с традиционной архитектурой.
Таблица 3 – Сравнительная таблица инструментальных средств прототипирования
и моделирования компьютерных сетей
Cisco Packet GNS 3
UNetLab
NS-3
Tracer
Открытость
Закрытый
Открытый
Закрытый Открытый код
исходного кода
код
код
код
Поддерживаемые ОС MS Windows, MS Windows, Linux
Linux
Поддержка
коммутаторов
Catalyst
Linux
Linux
+
-
+
-
43
Продолжение таблицы 3
ISR маршрутизаторы
+
+
+
+
межсетевой
+
+
-
+
Wi-fi
+
-
+
+
VOIP
+
+
-
+
RADIUS
+
+
+
-
SNMP агент
+
+
+
-
ASA
экран
2.2 Выбор программного средства для моделирования проектируемой
компьютерной сети
Mininet — это эмулятор компьютерной сети. Под компьютерной сетью
подразумеваются простые компьютеры — хосты, коммутаторы, а также
OpenFlow-контроллеры. С помощью простейшего синтаксиса в примитивном
интерпретаторе команд можно разворачивать сети из произвольного количества
хостов, коммутаторов в различных топологиях и весь этот функционал доступен в
рамках одной виртуальной машины. На всех хостах можно изменять сетевую
конфигурацию, пользоваться стандартными утилитами (ipconfig, ping и др.) и
даже получать доступ к терминалу. На коммутаторы можно добавлять различные
правила и маршрутизировать трафик.
Начиная с версии 2.6.24, ядром Linux поддерживаются механизмы
виртуализации и изоляции – Cgroups, которые позволяют обеспечить сетевыми
интерфейсами, таблицами маршрутизации и ARP-таблицами процессы в рамках
одной операционной системы. Это один из видов виртуализации на уровне ОС,
позволяющий запустить множество однотипных процессов в изолированном и
ограниченном по ресурсам окружении. Подобные техники позволяют Mininet
создавать в пространстве ядра или пользователя коммутаторы, OpenFlowконтроллеры и хосты, и взаимодействовать в рамках моделируемой сети. В
44
качестве виртуальных коммутаторов используется адаптированная реализация
Open vSwitch.
Основная функциональность Mininet реализована на языке Python, за
исключением некоторых утилит, написанных на Си. Практически любая
произвольная топология может быть описана с помощью специального
синтаксиса на Python.
Некоторые особенности, которыми характеризуется Mininet:

гибкость - новые топологии и новые функции могут быть
установлены
в
программном
обеспечении,
с
использованием
языков
программирования и общих операционных систем;

применимость - правильная реализация прототипа сети, также должна
легко переноситься на реальную сеть без каких-либо изменений в исходном коде;

интерактивность - управление и запуск имитируемой сети должны
происходить в реальном времени, как если бы это происходило в реальной сети;

масштабируемость - среда прототипирования должна быть способна
масштабироваться на большие сети с сотнями или тысячами коммутаторов только
на одной машине;

реализм поведения - поведение прототипа должно представлять собой
поведение в режиме реального времени с высокой степенью достоверности,
поэтому стеки приложений и протоколов должны использоваться без изменения
кода;

совместно создаваемые прототипы должны быть легко доступны
другим сотрудникам, которые затем могут запускать и модифицировать
прототипы.
Эмулятор Mininet имеет подключаемый модуль для визуализации MiniEdit –
MiniEdit (рисунок 2.4) имеет простой пользовательский интерфейс, который
представляет собой холст с рядом значков инструментов в левой части окна и
панель меню в верхней части окна.
45
Рисунок 2.4 – Рабочая область эмулятора Mininet с включенным модулем
MiniEdit
Несмотря на то, что эмулятор Mininet считается одним из самых
распространенных инструментальных средств для быстрого прототипирования
программно-определяемых сетей, он имеет несколько ограничений. Самым
значительным
ограничением
Mininet
является
отсутствие
верности
производительности, поскольку эмулятор не гарантирует, что эмулированный
хост, готовый отправить пакет, выполнит это действие сразу же по указанию
операционной системы; также Mininet не гарантирует, что все программные
OpenFlow-коммутаторы в эмулируемой среде будут передавать пакеты с
одинаковой скоростью. Скорость пересылки пакетов программного OpenFlowкоммутатора в Mininet непредсказуема и варьируется в каждом эксперименте, так
как это зависит от скорости процессора, пропускной способности основной
памяти,
количества
эмулируемых
хостов
и
программных
OpenFlow-
коммутаторов, которые должны быть мультиплексированы процессором в
Mininet, а также текущую активность и нагрузку системы. В результате Mininet
может использоваться только для изучения поведения контроллера OpenFlow, но
46
не может использоваться для изучения производительности сети или приложений,
привязанных ко времени.
EstiNet – эмулятор программно-определяемых сетей, сочетающий в себе
преимущества
как
симуляции,
так
и
подходов
к
эмуляции
без
их
соответствующих недостатков. Как и в эмуляции, в EstiNet реальный OpenFlowконтроллер может легко запускаться без последующих модификаций для
управления имитируемыми OpenFlow-коммутаторами, а реальные приложения
могут легко запускаться на хостах, работающих под управлением реальной
операционной системы, для генерации реалистичного сетевого трафика. Однако в
эмулируемой
среде
взаимодействие
между
приложениями,
OpenFlow-
контроллером, OpenFlow-коммутаторами и хостами планируется механизмом
моделирования EstiNet на основе его часов синхронизации, а не с помощью
мультиплексирования и выполнения непредсказуемым образом операционной
системой, как это заложено в Mininet. По этой причине, отличаясь от Mininet,
EstiNet
корректно
генерирует
результаты
производительности
OpenFlow,
привязанные ко времени, и эти результаты могут быть повторно получены.
В
таблице
4
приведена
сравнительная
характеристика
средств
моделирования программно-определяемых сетей EstiNet, Ns-3 и Mininet в
соответствии с их последними разработками.
Таблица 4 - Сравнительная характеристика средств моделирования программноопределяемых сетей
Поддерживаемая
версия
EstiNet
Ns-3
Mininet
1
2
3
1.1.0/1.0.0
0.8.9
1.0.0
+
+
-
протокола
OpenFlow
Режим симуляции
47
Продолжение таблицы 4
1
2
3
+
-
+
+
-
+
+
+
-
Масштабируемость
Высокая
Высокая
Средняя
Корректность
Высокая
Нет
Средняя
Режим эмуляции
Совместимость
с
реальными
контроллерами
Возможность
получения
повторяемых
результатов
получаемых
совместимости
результатов
с
реальными
контроллерами
Графический
Визуализация,
интерфейс
конфигурирова визуализации
ние
Только
для Только
визуализации
для (Python
(C++
для
для
конфигурирова конфигурирован
ния)
ия)
Остановимся более подробно на двух критериях, по которым проводилось
сравнение - масштабирование и графический интерфейс. EstiNet использует
методологию повторного ввода ядра для использования одного ядра для
поддержки нескольких хостов, а его механизм моделирования может имитировать
несколько
OpenFlow-коммутаторов.
Как
итог,
EstiNet
обладает
высокой
масштабируемостью. Инструмент моделирования Ns-3 также обладает высокой
масштабируемостью, поскольку его имитируемые хосты, OpenFlow-коммутаторы
и контроллер все реализованы как модули C++ и связаны друг с другом как один
48
процесс. Напротив, Mininet должен запускать процесс оболочки (например,
/bin/bash) для эмуляции каждого хоста, а также должен запускать два
пользовательских пространства для Open vSwitch процессов (один для пути
данных, а другой для пути управления) для эмуляции каждого OpenFlowкоммутатора. В результате Mininet менее масштабируемый, чем EstiNet и Ns-3.
Стоит отметить, что Open vSwitch также может быть запущен в режиме ядра. В
таком режиме для пути управления должен быть запущен только один процесс.
Однако, согласно проводимым исследованиям, Open vSwitch, работающий в
режиме ядра, делает Mininet менее масштабируемым и менее надежным.
Что касается поддержки графического интерфейса пользователя (GUI), GUI
EstiNet можно использовать для простой настройки и настройки случая
моделирования и наблюдения за воспроизведением пакетов в режиме симуляции.
С другой стороны, GUI Ns-3 можно использовать только для наблюдения за
результатами, и пользователю необходимо написать скрипт на C++ для запуска и
конфигурации сценария моделирования. В Mininet графический интерфейс может
использоваться
только
для
целей
наблюдения,
таким
образом
перед
пользователем возникает задача написания скрипта на Python для настройки
сценария моделирования. Одна уникальная и полезная функция GUI EstiNet
заключается в том, что он может повторно воспроизводить поток OpenFlowпакетов
управления
после
завершения
моделирования.
Благодаря
этой
возможности разработчик OpenFlow-контроллера может более легко тестировать
и отлаживать свой скрипт для OpenFlow-контроллера, визуализируя поведение
пакетов с помощью EstiNet. На рисунке 2.5 показана топология сети OpenFlow,
построенная при помощи графического интерфейса EstiNet.
49
Рисунок 2.5 – EstiNet
2.3 Модель сети образовательной организации
В рамках данной работы по модернизации локальной вычислительной сети
образовательного учреждения рассмотрим существующую сетевую топологию.
Для исследования и модернизации нами был выбран один из корпусов
образовательного учреждения – четырехэтажное здание, характеризующееся
достаточно разветвлённой сетевой инфраструктурой. Работоспособность сети
поддерживается и развивается ремонтно-сервисной службой института. Цель
объединения компьютеров в локальную сеть имеет производственный и
образовательный
характер.
Для
студентов
сеть
является
средством
интерактивного взаимодействия, общения, обучения, а также средой при
совместном
решении различных учебных задач.
Для
преподавателей
и
административных работников сеть в первую очередь служит для доступа к
информационным корпоративным ресурсам образовательной организации, таким
как главная веб-страница университета, электронная библиотека, система
электронного документооборота, система автоматизации работы структурных
подразделений образовательной организации,
участвующих в управлении
учебным процессом и многих других.
За 3 года своего существования, существующая компьютерная сеть
претерпела множество качественных изменений. На данный момент она
50
территориально охватывает 4 этажа. Число рабочих станций, подключенных к
сети растет и в настоящий момент составляет 234 компьютерных рабочих места,
расположенных в одном домене. Рассматриваемая сеть построена на технологии
Ethernet и поддерживает стандарты 10/100/1000 Base-T. Сеть имеет тип топологии
иерархическая звезда, на каждом из этажей установлен кроссовый коммутатор
уровня распределения, являющийся узловым элементом сети. На третьем этаже
здания располагается серверная, в которой установлен центральный коммутатор
уровня ядра. В крупных кабинетах где число рабочих мест обычно превышает три
установлены более экономичные коммутаторы уровня доступа. Структурная
схема исследуемой топологии локальной сети образовательной организации
приведена на рисунке 2.6.
Рисунок 2.6 – Структурная схема топологии сети корпуса университета
Как следует из рисунка на каждом этаже располагаются по два коммутатора
уровня распределения, непосредственно с серверной и коммутатором уровня ядра
напрямую связан только один из них (Кросс 3.2). Рассмотрим подробнее
используемое
активное
сетевое
оборудование
и
дадим
его
основные
характеристики.
Уровень
доступа
представлен
управляемыми
коммутаторами
3Com
OfficeConnect Dual Speed Switch 16 (рисунок 2.7). Основные особенности этих
51
коммутаторов - 16 портов, поддерживающих скорость 10/100 Мбит/сек,
поддержка протокола удаленного доступа Telnet, работа в режиме полудуплекса и
полного дуплекса, а также поддержка автосогласования скорости и режима
работы. Размер таблицы MAC-адресов составляет 4000 записи, потребляемая
мощность устройства – 15 Вт.
Рисунок 2.7 – Коммутатор уровня доступа 3Com OfficeConnect Dual Speed
Switch 16
На уровне распределения установлены управляемые коммутаторы HPE
OfficeConnect
1820-48G
(рисунок
2.8).
К
основным
особенностям
этих
коммутаторов можно отнести наличие 48 портов, поддерживающих скорость
10/100/1000
Мбит/сек,
поддержка
протокола
удаленного
доступа
Telnet,
протокола сетевого управления SNMP, а также стандартов Jumbo Frame (стандарт
увеличенного размера кадра), IEEE 802.1p (Priority tags), IEEE 802.1q (VLAN),
IEEE 802.1d (Spanning Tree) (протокол расширенного дерева), Link Aggregation
Control Protocol (LACP). Также на коммутаторах присутствуют 4 SFP-порта, для
подключения оптоволоконного кабеля, поддерживающие скорость 10/100/1000
Мбит/сек. Размер таблицы MAC-адресов составляет 16384 записи, потребляемая
мощность устройства – 38 Вт.
52
Рисунок 2.8 – Коммутатор уровня распределения HPE OfficeConnect 182048G
На третьем уровне ядра установлен управляемый коммутатор Cisco WSC3650-24PS-L
(рисунок
2.9).
Этот
коммутатор
относится
к
категории
управляемых коммутаторов уровня L3, и таким образом обладает весьма
широким набором поддерживаемых технологий. У коммутатора Cicso 3650 24
порта, поддерживающих скорость 10/100/1000 Мбит/сек, и 4 SFP-порта, для
подключения оптоволоконного кабеля, поддерживающие скорость 10/100/1000
Мбит/сек. Управление коммутатором происходит либо через консольный порт,
либо с использованием протокола удаленного доступа Telnet, либо протокола
сетевого управления SNMP. Из дополнительных особенностей можно выделить
поддержку мультистекирования, IPv6, а также стандартов Auto MDI/MDIX, Power
Over Ethernet, Jumbo Frame, IEEE 802.1p (Priority tags), IEEE 802.1q (VLAN), IEEE
802.1d (Spanning Tree), IEEE 802.1s (Multiple Spanning Tree), Link Aggregation
Control Protocol (LACP). Внутренняя пропускная способность равна 88 Гбит/сек,
размер таблицы MAC-адресов составляет 32768 записи, потребляемая мощность
устройства – 38 Вт.
Рисунок 2.9 – Коммутатор уровня ядра Cisco WS-C3650-24PS-L
53
К пассивному сетевому оборудованию относятся сетевые розетки 8P8C,
проведенные в каждой аудитории корпуса образовательного учреждения, и
служащие для обеспечения контакта одного компьютера или другого активного
устройства с передающей средой. Такие розетки повышают отказоустойчивость
всей кабельной системы корпуса, созданной с использованием кабеля типа «витая
пара». К пассивному оборудованию также относятся коммутационные панели
(патч-панели), установленные рядом с каждым кроссовым коммутатором,
служащие для облегчения монтажа кабельной системы и структуризации
разъёмов в монтажном шкафу.
Клиентские машины представляют собой автоматизированные рабочие
места, под управлением MS Windows 7 (реже – MS Windows XP). Аппаратные
характеристики всех АРМ в целом имеют незначительные различия. Общим для
всех АРМ, используемых преподавателями и административными работниками
является набор установленного программного обеспечения – офисный пакет MS
Office Professional 2010, система антивирусной защиты Kaspersky Endpoint
Security,
клиентская
подразделений
часть
системы
образовательной
автоматизации
организации,
работы
клиентская
структурных
часть
системы
электронного документооборота.
Более детально сетевая модель рассматриваемого корпуса образовательной
организации представлена на рисунках 2.10, 2.11, 2.12 и 2.13.
54
Рисунок 2.10 – Сетевая модель корпуса образовательной организации (1 этаж)
55
Рисунок 2.11 – Сетевая модель корпуса образовательной организации (2 этаж)
56
Рисунок 2.12 – Сетевая модель корпуса образовательной организации (3 этаж)
57
Рисунок 2.13 – Сетевая модель корпуса образовательной организации (4 этаж)
58
2.4. Выбор метрик для проведения исследования
Проводимое исследование производительности модели традиционной
сети в паре с предлагаемой моделью программно-определяемой сети опирается
на выбор критериев (метрик) оценки производительности сети, которые и
составляют основу для исследования. Рассмотрим некоторые метрики,
подходящие для оценки компьютерной сети и кратко опишем каждую из них.
Производительность вычислительной сети может быть оценена с разных
позиций. С точки зрения пользователя сети, важным числовым показателем
производительности сети является время реакции системы, особенно в той
части, которая относится к работе сети. Время реакции — это время между
моментом возникновения запроса и моментом получения ответа. Время
реакции зависит от многих факторов, таких как используемая служба сети,
степень загруженности сети или отдельных сегментов и др.
Задержка передачи определяется как задержка между моментом
поступления пакета на вход какого-либо сетевого устройства или части сети и
моментом появления его на выходе этого устройства.
Задержка распространения появляется в результате ограничения скорости
распространения фотонов или электронов в среде передачи (волоконнооптический кабель или медная витая пара)
Пропускная способность сети определяется количеством информации,
переданной через сеть или ее сегмент в единицу времени. Пропускная
способность сети характеризует, насколько быстро сеть может выполнить свою
основную задачу передачи информации. Пропускная способность определяется
в битах в секунду. Пропускная способность может быть мгновенной,
максимальной и средней.
Максимальная пропускная способность - это наибольшая мгновенная
пропускная способность, зафиксированная в течение периода наблюдения.
59
Общая пропускная способность - определяется как среднее количество
информации, переданной между всеми узлами сети в единицу времени. Этот
показатель характеризует качество сети в целом, не дифференцируя его по
отдельным сегментам или устройствам
Средняя пропускная способность вычисляется путем деления общего
объема переданных данных на время их передачи, причем выбирается
достаточно длительный промежуток времени — час, день или неделя.
В отличие от средней пропускной способности для мгновенной
пропускной способности для усреднения выбирается очень маленький
промежуток времени, например, 10 мс или 1 с.
Надежность работы вычислительной сети определяется надежностью
работы всех ее компонентов. Для повышения надежности работы аппаратных
компонентов обычно используют дублирование, когда при отказе одного из
элементов функционирование сети обеспечат другие.
На основе проведенного изучения и анализа всех метрик в рамках
исследования был сделан выбор в пользу общей пропускной способности сети
и задержки передачи, как двух наиболее распространенных метрик для оценки
производительности компьютерных сетей.
60
3 ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ТРАДИЦИОННОЙ
И ПРОГРАММНО-ОПРЕДЕЛЯЕМОЙ СЕТИ
В данном разделе непосредственно перед проведением исследования
производительности традиционной сети на
основе
IP и программно-
определяемой сети на основе OpenFlow были изучены основные сетевые
топологии с использованием инструментов моделирования с открытым
исходным кодом. Затем в ходе исследования был проведен сравнительный
анализ производительности традиционной и программно-определяемой сети на
основе ранее изученных топологий. Анализ производительности выполнялся
путем сравнения сети OpenFlow с традиционной сетью на основе задержки
распространения между конечными узлами и максимальной пропускной
способностью. Для проведения исследования были выбраны инструментальное
средство Mininet, в котором была разработана сетевая топология для
традиционной и для программно-определяемой сетей.
Симулятор Mininet поддерживает пять встроенных сетевых топологий.
По умолчанию стандартная топология - это минимальная топология, состоящая
из одного OpenFlow-коммутатора уровня ядра, подключенного к двум хостмашинам, и OpenFlow-контроллера, расположенного над коммутатором.
Рассмотрим три основные топологии сети, - одиночную топологию, линейную
топологию и древовидную топологию. Так как программно-определяемая сеть
имеет
централизованно
управляемую
архитектуру,
число
центральных
элементов управления равно единице, тогда как число машин с поддержкой
OpenFlow и хост-компьютеров может быть подключено столько, сколько
требуется для пользователей.
1)
Одиночная топология
Одиночная
топология
в Mininet
схожа
с
топологией
звезды
в
традиционной сети. В топологии «звезда» все хост-машины соединены с
61
центральным
коммутатором,
аналогично
этому,
в Mininet
реализуется
одиночная топология сети с поддержкой OpenFlow, в которой центральный
элемент топологии заменяется коммутатором с поддержкой OpenFlow,
коммутатор, в свою очередь, подключается к центральному контроллеру
OpenFlow (сетевое устройство уровня контроля). Одиночная топология в
традиционной сети и программно-определяемой сети, имеющая 16 хост-машин,
показана соответственно на рисунках 3.1 и 3.2.
Рисунок 3.1 – Одиночная топология традиционной сети
Рисунок 3.2 – Одиночная топология программно-определяемой сети
62
Как показано на рисунке 3.2, плоскость управления и плоскость данных
отделены от сетевого устройства уровня ядра по сравнению с традиционным
сетевым дизайном на рисунке 3.1.
2)
Линейная топология
Линейная топология в Mininet схожа на топологию шины в традиционных
сетях с некоторыми изменениями. В топологии шины традиционной сети все
узлы подключены к одному магистральному кабелю, называемому шиной, с
помощью
интерфейсных
разъемов.
Все
рабочие
станции
могут
взаимодействовать друг с другом с использованием общей шины. В линейной
топологии Mininet вместо единого магистрального кабеля и интерфейсных
разъемов для узлов используется OpenFlow-коммутатор и отдельные кабели.
Кроме того, центральный OpenFlow-контроллер (плоскость управления)
иерархически располагается над OpenFlow-коммутаторами для управления
потоками данных. Линейная топология для традиционной и программноопределяемой сети с 16 хост-машинами показана на рисунках 3.3 и 3.4.
Рисунок 3.3 – Линейная топология традиционной сети
63
Рисунок 3.4 – Линейная топология программно-определяемой сети
В линейной топологии Mininet для традиционной сети, как показано на
рисунке 3.3 вместо обычного магистрального кабеля и интерфейсного разъема
для
отдельных
хост-машин
используется
отдельный
коммутатор,
а
коммутаторы связаны друг с другом. Кроме того, в программно-определяемой
сети на рисунке 3.4, традиционные коммутаторы заменяются OpenFlowкоммутаторами, и эти коммутаторы, в свою очередь, подключаются к
OpenFlow-контроллеру с централизованным управлением по защищенной
ссылке.
3)
Древовидная топология
Древовидная топология в Mininet является более сложной топологией чем
одиночная и линейная топологии. Этот тип топологии характеризуется
степенью глубины и N-арностью разветвлений узлов, то есть числом уровней
коммутаторов и количеством выходных портов, доступных для всех узлов.
Топология дерева для традиционной сети и программно-определяемой сети с 16
хостами показана на рисунках 3.5 и 3.6.
64
Рисунок 3.5 – Древовидная топология традиционной сети
Рисунок 3.6 – Древовидная топология программно-определяемой сети
Как уже было замечено выше, древовидная топология зависит от глубины
и N-арности разветвлений узлов. Древовидная топология для традиционной
сети, изображенная на рисунке 3.5, имеет глубину равную 2, то есть два 2
65
уровня коммутаторов. На уровне 1 расположен коммутатор S1, на уровне 2 - 4
коммутатора S2, S3, S4 и S5. Ниже уровня 2 располагается уровень хостов,
соединенных с коммутатором. Для данной топологии число разветвлений
принято
равным
4,
поэтому количество выходных портов для
всех
коммутаторов на каждом уровне равно 4, как показано на рисунках.
В древовидной топологии программно-определяемой сети, как и в
предыдущих
топологиях,
все
традиционные
коммутаторы
заменяются
OpenFlow-коммутаторами, а коммутаторы, в свою очередь, подключаются к
OpenFlow-контроллеру по защищенному каналу, как показано на рисунке 3.6.
Наконец, можно сказать, что для проектирования древовидной топологии,
имеющей 16 хост-машин, требуется настройка конфигурации для сети. В
древовидной топологии Mininet все узлы связаны друг с другом в определенной
иерархии.
4)
Исследуемая сетевая модель:
Для создания исследуемой сетевой модели корпуса образовательного
учреждения был написан скрипт, на языке Python, формирующий сетевую
топологию по мере необходимости, выполняющий команды на нескольких
узлах и отображающий необходимые результаты. Исследуемая модель состоит
из 8 OpenFlow-коммутаторов уровня распределения, подключенных к одному
контроллеру, 30 OpenFlow-коммутаторов уровня доступа, подключенных к
коммутаторам уровня распределения и 243 виртуальных хостов, подключенных
к коммутаторам в соответствии со схемами на рисунках 2.10 – 2.13. Листинг
скрипта, строящего исследуемую топологию представлен в приложении А.
66
Рисунок 3.7– Фрагмент исследуемой топологии программноопределяемой сети корпуса образовательного учреждения
Чтобы запустить настраиваемую сетевую модель, следующая команда
должна быть написана в командной строке Mininet:
sudo mn — custom filename.py —topo toponame —mac
После выполнения указанной команды создается сетевая модель со
следующими параметрами:

243 виртуальных хоста, каждому из которых назначен отдельный IP
адрес, как описано в скрипте;

8 OpenFlow-коммутаторов уровня распределения с необходимым
количеством портов;

30
OpenFlow-коммутаторов
уровня
доступа
с
необходимым
количеством портов;

Хосты соединяются с коммутаторами на основании правил,
изложенных в скрипте, максимальная пропускная способность линий связи
между хостами и коммутаторами уровня доступа устанавливается равной 100
67
Мбит/сек, между коммутаторами уровня распределения и коммутатором
уровня ядра – 1000 Мбит/сек;

Каждому хосту автоматически присваивается MAC-адрес;

OpenFlow-коммутаторы
настраиваются
на
подключение
к
контроллеру.
При проведении исследования были выбраны две метрики, по которым
происходит оценка производительности – гибкость (масштабируемость) и
эффективность:
1)
Гибкость -
эта метрика проверяет функциональность устройств
после последовательных изменений конфигурации с помощью OpenFlow путем
выполнения нескольких тестовых сценариев;
2)
Эффективность - эта метрика оценивает производительность
программно-определяемой сети и включает в себя измерение задержки и
пропускной способности.
3.1 Измерение задержки в традиционной и программно-определяемой
сети
Сравнительный анализ производительности между традиционной сетью и
программно-определяемой сетью для вышеопределенной сетевой модели
осуществляется путем проведения теста сетевого подключения между
конкретными узлами в сети и путем вычисления средней пропускной
способности сети. Простая сетевая связь проверяется путем выполнения
команды ping, которая отправляет сообщение запроса эхо-сигнала ICMP и ждет
ответа, чтобы проверить IP-соединение между определенными узлами. Тест
Ping между двумя узлами – h2, подключенными к коммутатору kross12 и h30,
подключенным к коммутатору s211, показан на рисунке 3.8.
68
Рисунок 3.8 - Тест соединения между узлами h2 и h30
Здесь, как показано на рисунке 3.8, передаются 3 пакета запроса эхосигнала, которые успешно принимаются в определенном узле h30, и также
показана статистика ping. Теперь мы проверяем, что хосты могут пинговать
друг друга, а узлы видят точный трафик. Для этого мы создадим xterms для
нескольких хостов и проанализируем сгенерированный ICMP-трафик в каждом
терминале. Терминал xterm подключается к хостам в виртуальной сети. Этот
терминал в основном используется для запуска интерактивных команд и
просмотра вывода отладки. На основании вышеприведенного примера, pingтест
выполняется
между
хостами
h2
и
h30
и
анализируется
его
производительность. Кроме того, анализируется производительность хостов в
сети, отличной от h2 и h30 (в этом примере показана производительность хоста
h10 и h20). Xterms для хостов h2, h10, h20 и h30 показан на рисунках 3.9, 3.10,
3.11 и 3.12.
Рисунок 3.9 – Xterm для хоста h2
69
Рисунок 3.10 – Xterm для хоста h10
Рисунок 3.11 – Xterm для хоста h20
В xterms хостов h10, h20 и h30 мы выполнили команду tcpdump, которая
является утилитой для печати пакетов, просматриваемых хостом. При
выполнении теста ping путем отправки сообщения запроса эха пакеты, видимые
выбранными хостами (h10, h20 и h30), отображаются в окнах xterms, как
показано на соответствующих рисунках. Пакет ping будет перемещаться до
контроллера, который, в свою очередь, выводит их на все интерфейсы, кроме
отправляющего. Прежде чем получить логическую связь между хостами,
сначала устанавливается физическая связь между хостами, путем разрешения
физического адреса с логического адреса с использованием протокола ARP
(Address Resolution Protocol). Сообщение с ARP запросом транслируется всем
устройствам в сети, и ответное сообщение ARP приходит от одного
отправителя. В xterms хостов h10, h20 и h30 на рисунках 3.10, 3.11 и 3.12
хорошо видно широковещательное сообщение запроса ARP, возникшее из
хоста h2, запрашивающее физическую связь с хостом h30. В пакетном формате
сообщения запроса присутствует исходный и целевой логический адрес вместе
70
с физическим адресом отправителя, запрашивающего физический адрес
получателя. После того, как на запрошенном хосте в сети выполняется
сопоставление логического адреса, запрошенный хост (или хост назначения
(h30)) отправит юникастовое сообщение-ответ в сети на запрос хоста (h2).
После того, как разрешение адреса между хостами выполнено, сообщение
запроса ICMP передается исходным хостом h2, на хост назначения h30,
который показан на рисунке 3.11, и хост h30 отвечает на это сообщение запроса
отправляя сообщение ответа ICMP, которое также хорошо видно на том же
рисунке 3.12. В случае разрешения адреса контроллер также будет добавлять
записи потока в таблицу потоков коммутатора OpenFlow, чтобы повысить
производительность за счет уменьшения конечной задержки с некоторым таймаутом.
Рисунок 3.12 - Xterm для хоста h30
Теперь мы выполняем тест на подключение для хоста, который не
существует в сети, и анализируем производительность запрашивающего хоста
и других хостов в сети. В этом случае xterms одного и того же хоста
рассматриваются, как обсуждалось выше (для хостов h2, h10, h20 и h30). Xterm
71
для хостов h2, h10, h20 и h30 показан на рисунках 3.13, 3.14, 3.15 и 3.16. Здесь
проверка ping выполняется между хостом h2 и недоступным хостом h40 в сети.
Рисунок 3.13 - Xterm для хоста h2
Рисунок 3.14 - Xterm для хоста h10
Рисунок 3.15 - Xterm для хоста h20
72
Рисунок 3.16 - Xterm для хоста h30
Как и в предыдущем случае, первый физический адрес запрашиваемого
хоста (h40) разрешается путем запроса хоста (h2) путем отправки сообщения
запроса ARP. Поскольку сообщение запроса ARP транслируется, все остальные
хосты в сети получат сообщение запроса, кроме запрашивающего узла. Всякий
раз, когда исходный узел создает сообщение запроса, он запускает свой
внутренний предопределенный таймер для приема ответного сообщения в
определенный период времени ожидания. Если ответ не поступит в этот период
времени, источник будет отображать сообщение «запрос времени» в своем
терминале. Сообщение запроса транслируется на все хосты, и требуемый хост
должен предоставить ответ, но если мы проверим тест подключения для
недоступного хоста в сети, то, как и в предыдущем случае, запрос будет
передан всем хостам, и если ответ из определенного хоста не поступает в
предопределенный период таймаута, то запрос повторно будет ретранслирован
три раза, и если подобная ситуация повторится, то появится сообщение,
сигнализирующее о потере переданных пакетов, и отображающее статистику
для потерянных пакетов.
Проведя серию похожих экспериментов вычислим среднее время приемапередачи для традиционной и программно-определяемой сетей для всех
73
рассмотренных выше топологий. Результаты представлены в таблице 5 и на
рисунке 3.17.
Таблица 5 – Время приема-передачи между узлами
Среднее время приема-передачи (rtt) между узлами
Традиционная сеть
Программноопределяемая сеть
Одиночная топология
7.2 мс
4.6 мс
Линейная топология
57.8 мс
41.7 мс
Древовидная топология
14.4 мс
8.8 мс
Исследуемая топология
10.1 мс
7.83 мс
Рисунок 3.17 – Среднее время приема-передачи между конечными узлами
Проанализировав полученные данные, можно сделать вывод что задержка
распространения между узлами в программно-определяемой сети меньше по
сравнению с традиционной сетью для любой топологии сети.
74
3.2 Измерение пропускной способности традиционной и программноопределяемой сети
Далее,
проведем
тест
пропускной
способности
традиционной
и
программно-определяемой сети для вышеописанных топологий. Пропускная
способность сети определяется как количество данных, передаваемых от
исходного узла до целевого узла за данный период времени и измеряется в
битах в секунду (бит/с). Аналитически пропускная способность определяется,
как отношение максимальной пропускной способности принимающей стороны
к времени прохождения между узлами:
Пропускная способность = максимальная пропускная способность
принимающей стороны / время приема-передачи
Для проведения данного теста будем использовать инструмент Iperf. Iperf
- широко используемый инструмент сетевого тестирования, который может
создавать потоки данных TCP и UDP и измерять пропускную способность сети,
которая их переносит. Iperf - это инструмент для измерения максимальной
ширины полосы пропускания TCP, позволяющий настраивать различные
параметры и характеристики UDP. Iperf сообщает о пропускной способности,
задержке джиттера, потери датаграммы. Iperf - это инструмент командной
строки для проверки скорости между двумя компьютерами. Для выполнения
теста iperf требуется установить как клиентский, так и серверный узлы.
Различные анализы итераций выполняются между конечными хостами h1
и h32 для анализа используемой полосы пропускания TCP. Выполнение
команды iperf между виртуальными хостами зависит от скорости процессора
машины только для хоста (физической машины). Для фактически созданной
сети исключительная пропускная способность между хостами изменяется из-за
процессов, выполняющихся на машине только для хоста, которые в конечном
счете зависят от загрузки ЦП и косвенно влияют на пропускную способность
75
между виртуальных хостов в сети. Чтобы установить соединение с клиентом и
сервером, требуется снова xterm для хостов.
Зададим хост h32 в качестве узла сервера и размещаем h1 в качестве
клиентского узла. Анализ производительности пропускной способности TCP и
UDP между сервером и клиентом показан на рисунке 3.18.
Рисунок 3.18 – Xterm сервера (h32) и клиентского узла (h1) в процессе
установления TCP-соединения
Команда, выполняемая на xterm хоста h32 и хоста h1, как показано на
рисунке 3.18, запускает iperf-сервер и iperf-клиент для TCP-соединения
соответственно. Сервер начинает прослушивать порт 5001 по умолчанию,
имеющий размер окна TCP по умолчанию, равный 85,3 КБ. В этом примере
99,9 МБ данных передаются между клиентом и сервером через 10 с временного
интервала. Таким образом, доступная пропускная способность составляет 83,4
Мбит/с. Пропускная способность может увеличиваться за счет увеличения
размера окна TCP.
В отличие от TCP, в пропускной способности UDP влияют различные
параметры сети. Поскольку UDP является ненадежным протоколом, факторы,
влияющие на пропускную способность, не соответствуют доставке пакетов,
76
сетевому дрожанию и потере пакетов во время передачи и т. д. Для проведения
теста UDP iperf-клиент и iperf-сервер запускаются путем выполнения команд в
xterms сервера (h32) и клиента (h1), как показано на рисунке 3.19.
Рисунок 3.19 – Xterm сервера (h32) и клиентского узла (h1) в процессе
установления UDP-соединения
Здесь сервер прослушивает соединение UDP на одном и том же порту
5001 по умолчанию, а размер буфера по умолчанию составляет 208 КБ, как
показано на рисунке 3.19. В этом примере ключ -u используется для указания
UDP-соединения, также мы используем опцию -b на узле клиента, чтобы
указать пропускную способность для использования, 700 Мбит/с для этого
случая, потому что iperf использует только 1 Мбит/с полосы пропускания по
умолчанию для UDP-соединения. Поскольку UDP - это протокол без
установления соединения и ненадежный протокол, синхронизация между
сервером и клиентскими узлами отсутствует, поэтому 370 МБ данных,
77
отмеченных на сервере, и 400 МБ данных, отмеченных на клиентском сайте,
передаются через 9,5с временного интервала, что дает пропускную способность
327 и 335 Мбит/с на сайте сервера и на сайте клиента соответственно. Сетевой
джиттер, определяемый как отклонение во времени для периодического
поступления граммов данных, составляет 0,004 мс, что незначительно, поэтому
не требует внимания. Кроме того, 1721 датаграммы получены не по порядку,
которые могут быть перегруппированы на конце приемника. Скорость потери
пакетов во время связи составляет 7,5%, что может быть улучшено за счет
снижения перегрузки, вызванного нежелательной сетевой нагрузкой.
Схожие эксперименты с использованием утилиты iperf были проведены с
сетью, построенной на основе традиционной архитектуры. После проведения
экспериментов были собраны статистические данные, и вычислена средняя
пропускная способность традиционных и программно-определяемых сетей для
всех рассмотренных выше топологий. Результаты отражены на рисунке 3.20,
исходя из которого можно сделать вывод что средняя пропускная способность
между заданными узлами больше в сети с поддержкой OpenFlow по сравнению
с традиционной сетью для всех топологий. Это означает, что между узлами в
течение определенного периода времени в программно-определяемой сети
проходит большее количество переданных данных, чем между узлами в
традиционной
сети.
Однако
немаловажно
отметить,
что
пропускная
способность программно-определяемых сетей зависит от того, в каком режиме
работает контроллер – проактивном или реактивном.
78
Рисунок 3.20 - Сравнение пропускной способности между программноопределяемой и традиционной сетью
3.3 Измерение гибкости программно-определяемой сети
Тестирование гибкости программно-определяемой сети с получением
численных
единственное
результатов
решение
представляется
которой –
достаточно
трудной
задачей,
смоделировать несколько сценариев
функционирования устройств и добавить еще один OpenFlow-коммутатор.
С протестированными сценариями функционирования можно сделать
вывод, что контроллер ведет себя одинаково во всех сценариях, хотя после
нескольких запусков контроллер больше не мог связываться с оборудованием, в
связи с чем происходила перезагрузка контроллера и остального необходимого
оборудования. Это был единственный заметный дефект в функционировании
контроллера, но следует отметить, что контроллер относился к типу
программно-реализованных
и
запускался
на
тестовом
персональном
компьютере.
Перед
представлением
функционирования
также
результатов
необходимо
было
нескольких
показать
сценариев
разницу
между
реактивным и проактивным режимом. Проведенные испытания соответствуют
испытаниям рассмотренным ранее. Как можно видеть, анализируя рисунок
79
3.21, проактивный режим работы ведет себя аналогично традиционным сетям
из-за установки записей таблицы потоков в начале обмена данными.
Рисунок 3.21 – График задержки в проактивном режиме
Как показано на рисунке 3.22, в реактивном режиме задержка намного
выше, потому что каждый пакет должен обрабатываться контроллером,
поскольку в коммутаторах нет установки входа в таблицу потоков, что
приводит к проблеме узких мест.
Рисунок 3.22 – График задержки в реактивном режиме
80
3.4 Измерение производительности традиционной и программноопределяемой сети при генерации трафика
Измерение характеристик производительности включает в себя два
разных сценария, в первом из которых измерение пропускной способности и
задержки пакетов будет осуществляться, как и ранее, пределах взаимодействия
клиента и сервера на основе протокола TCP, - второй сценарий будет вычислять
аналогичные параметры на основе протокола UDP. Основным отличием от
предыдущего эксперимента будет задействование генератора трафика. Трафик
генерируется в течение 5 минут распределенным генератором интернеттрафика (D-ITG) на всех клиентских машинах. В качестве исследуемой модели
выступает
сетевая
модель
корпуса
образовательной
организации,
рассмотренная ранее.
Результаты измерений для двух сценариев показаны в таблице 6 и
таблице 7. Результаты первого измерения показывают, что программноопределяемая сеть предлагает равные характеристики, если заданные условия
идентичны. Существует небольшое различие в числах, так как, поскольку
топология известна заранее, первые пакеты на первоначальном этапе в
программно-определяемой сети будут отправляться быстрее, чем в обычной
сети. Разница заключается в том, что коммутаторы должны сначала изучить
существующую топологию, и это создает задержку в производительности
программно-определяемой сети. Несмотря на то, что условия были идентичны,
а используемое программное обеспечение реальное, эти результаты в
реальности могут быть дифференцированы и варьироваться в зависимости от
влияния таких факторов, как расстояние, линии связи и, конечно же,
используемое оборудование.
81
Таблица 6 – Результаты измерения первого сценария
Параметры
Традиционная сеть
Программноопределяемая сеть
Всего пакетов
209
218
Средняя задерка
0,0047
0,0043
Байт получено
214,266,01
220,176,12
Средний битрейт (Кбит/с)
5,714
6,344
Средняя скорость передачи 690
735
пакетов (пакеты/с)
Таблица 7 – Результаты измерения второго сценария
Параметры
Традиционная сеть
Программноопределяемая сеть
Всего пакетов
265
285
Средняя задерка
0,0026
0,0027
Байт получено
271,785,15
300,456,1
Средний битрейт (Кбит/с)
7,248
8,625
Средняя скорость передачи 884
952
пакетов (пакеты/с)
Пакетов отброшено
59920 (18,42%)
544 (0,19%)
Второй сценарий показал более высокую разницу в результатах. В то
время как для программно-определяемой сети потеря пакетов составила всего
0,19%, для обычной сети - 18,42%. Разница в реальности может колебаться, но
программно-определяемая сеть, безусловно, покажет лучшие результаты. Зная
топологию, контроллер знает, куда направлять пакет, если связь нарушена или
какой-то порт закрыт, а его производительность очень быстрая. В обычных
коммутационных устройствах топология должна быть в основном изучена,
82
поскольку коммутатор работает только с ближайшим блоком и не знает о
текущем состоянии в сети. STP имеет четыре условия: блокирование,
прослушивание, обучение и переадресация. Как только порт заблокирован, он
остается в этом состоянии в течение следующих 20 секунд. Затем он проводит
следующие 15 секунд в состоянии обучения. Если эти два состояния
суммируются вместе с временем приветствия равным 2 секундам, суммарное
время простоя коммутатора в традиционной сети составляет 52 секунды. Таким
образом разница в результатах измерений является высокой, потому что
коммутаторы в традиционной сети должны изучать топологию, которая не
нужна в случае программно-определяемой сети, и эта особенность безусловно
является дополнительным аргументом в пользу использования программноопределяемой сети.
3.5 Выводы по результатам исследования
В результате вышеприведённого исследования производительности
традиционной
и
программно-определяемой
сети
по
выбранным
ранее
метрикам, имеющих в своей основе описанную ранее сетевую модель корпуса
образовательной организации было выявлено, что программно-определяемая
сеть не уступает в производительности традиционной сети, а зачастую и
превосходит ее, а также превосходит ее в масштабируемости. Помимо
параметров задержки распространения и пропускной способности каналов,
однозначно характеризующих, насколько производительна сеть, нельзя не
учитывать
определяет
масштабируемость,
насколько
удобно
которая
и
с
является
меньшими
важным
фактором,
трудозатратами
и
может
происходить разрастание сетевой инфраструктуры – процесса, динамика
которого в образовательной организации все более возрастает. К этому
процессу можно отнести подключение новых кабинетов и аудиторий к
компьютерной
вычислительной
сети,
запуск
новых
корпоративных
83
внутриобразовательных сервисов, и как следствие, увеличение объема
передаваемого сетевого трафика между корпусами университета, постепенный
переход на виртуализацию серверной инфраструктуры (например, прокси или
DNS-сервер). На наш взгляд, вышеуказанный процесс и его составляющие не
могут идти в отрыве от современной модернизированной компьютерной сети,
фундаментом для которой была бы технология программно-определяемых
сетей. Таким образом, корпус образовательной организации для которого была
спроектирована новая сетевая модель, при ее успешном внедрении, мог бы
стать испытательной площадкой для централизованного мониторинга и
управления всей разветвленной сетевой инфраструктурой образовательной
организации.
В ходе исследования также было выявлено, что использование протокола
OpenFlow
для
настройки
коммутационного
оборудования
позволяет
динамически конфигурировать компоненты сетевой инфраструктуры и задавать
оптимальные параметры передачи данных для различных типов сетевого
трафика.
В ходе работы были выделены следующие отличительные преимущества
протокола:

Удобство администрирования и отладки;

Открытость протокола OpenFlow, позволяющая не привязываться к

производителям сетевых адаптеров;

Гибкая настройка коммутатора;

Сокращение времени на настройку сетей.
Предлагаемая сетевая модель корпуса образовательной организации
представлена на рисунке 3.23.
84
Рисунок 3.23. – Предлагаемая схема локальной вычислительной сети
корпуса образовательной организации
По
итогам
исследования
производительности
традиционной
и
программно-определяемых сетей предлагается провести замену этажных
коммутаторов
уровня
распределения
на
аналогичные
коммутаторы,
поддерживающие протокол OpenFlow, а также развертывание кластера из
OpenFlow-контроллеров – 4 контроллеров, управляющих коммутаторами
уровня
распределения,
а
также
вышеуказанными 4 контроллерами.
master-контроллера,
управляющего
85
ЗАКЛЮЧЕНИЕ
В ходе выполнения выпускной квалификационной работы был проведен
анализ существующих концепций построения компьютерных сетей, подробно
рассмотрена
технология
программно-определяемых
сетей,
проведено
исследование производительности двух сетевых архитектур и разработан
проект
модернизации
локальной
вычислительной
сети
корпуса
образовательной организации с использованием технологии программноопределяемых сетей:
1.
Описана традиционная архитектура компьютерных сетей;
2.
Описана технология архитектура программно-определяемых сетей;
3.
Выявлены цель, задачи и основные требования для модернизации
существующей локальной сети образовательной организации;
4.
Проанализированы инструментальные средства для моделирования
компьютерных сетей двух архитектур;
5.
Проанализирована
существующая
сетевая
модель
корпуса
образовательного учреждения;
6.
Проведено исследование производительности компьютерных сетей
двух архитектур;
7.
Разработан
проект
модернизации
существующей
локальной
вычислительной сети корпуса образовательной организации;
В рамках данной выпускной квалификационной работы разработка
проекта модернизации локальной вычислительной сети образовательной
организации считается законченным.
86
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1.
N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and
S. Shenker. NOX: towards an operating system for networks. SIGCOMM Computer
Communication Review 38, 3 (2008), 105-110.
2.
POX
[Электронный
ресурс].
–
Режим
доступа:
http://www.noxrepo.org/pox/about-pox/. – Дата доступа: 01.06.2018.
3.
[Электронный
Beacon
ресурс].
–
Режим
доступа:
https://openflow.stanford.edu/display/Beacon. – Дата доступа: 01.06.2018.
4.
Floodlight
[Электронный
ресурс].
–
Режим
доступа:
http://Floodlight.openflowhub.org/. – Дата доступа: 01.06.2018.
5.
Mul
[Электронный
ресурс].
–
Режим
доступа:
http://sourceforge.net/p/mul/wiki/Home/. – Дата доступа: 01.06.2018.
6.
Zheng Cai, Maestro: Achieving Scalability and Coordination in
Centralized Network Control Plane, Ph.D. Thesis, Rice University, 2011.
7.
Ryu
[Электронный
ресурс].
–
Режим
доступа:
http://osrg.github.com/ryu/. – Дата доступа: 01.06.2018.
8.
FlowER
[Электронный
ресурс].
–
Режим
доступа:
https://github.com/travelping/flower. – Дата доступа: 01.06.2018.
9.
Trema
[Электронный
ресурс].
–
Режим
доступа:
Режим
доступа:
http://trema.github.com/trema/. – Дата доступа: 01.06.2018.
10.
Nettle
[Электронный
ресурс].
–
http://haskell.cs.yale.edu/nettle/. – Дата доступа: 01.06.2018.
11.
Big Switch Networks OFTest [Электронный ресурс]. – Режим
доступа: http://www.projectfloodlight.org/oftest/. – Дата доступа: 04.06.2018.
12.
Amin Tootoonchian, Sergey Gorbunov, Martin Casado, Rob Sherwood.
On Controller Performance in Software-Defined Networks. In Proc. Of HotIce, April
2012.
87
13.
Cbench
[Электронный
ресурс].
–
Режим
http://docs.projectfloodlight.org/display/floodlightcontroller/Cbench.
доступа:
–
Дата
доступа: 04.06.2018.
14.
Graphical Network Simulator 3 [Электронный ресурс]. – Режим
доступа: http://www.gns3.com. – Дата доступа: 04.06.2018.
15.
A. Pušeljić: “Analysis of Characteristics and Application of Software
Defined Networks”, Master thesis, Faculty of Transport and Traffic Sciences,
University of Zagreb, Zagreb, 2015.
16.
Mininet
emulator
[Электронный
ресурс].
–
Режим
доступа:
http://www.mininet.org. – Дата доступа: 05.06.2018.
17.
Ns-3
[Электронный
ресурс].
–
Режим
доступа:
https://www.nsnam.org/news/release-3-1/. – Дата доступа: 05.06.2018.
18.
EstiNet
[Электронный
ресурс].
–
Режим
доступа:
http://www.estinet.com/. – Дата доступа: 05.06.2018.
19.
Гольдштейн Б. С., Кучерявый А. Е. Сети связи пост-NGN. СПб.:
БХВ Петербург, 2013. 160 с.
20.
Кучерявый А. Е., Киричек Р. В., Парамонов А. И., Прокопьев А. В.
Эволюция исследований в области беспроводных сенсорных сетей //
Информационные технологии и телекоммуникации. 2014. № 4. С. 29–41.
21.
Kirichek R., Koucheryavy A. Internet of Things Laboratory Test Bed //
Lecture Notes in Electrical Engineering. 2016. Vol. 348. pp. 485–494.
22.
Kirichek R., Golubeva M., Kulik V., Koucheryavy A. The home network
traffic models investigation // 18th International conference on advanced
communication technology (ICACT). 2016. pp. 97–100.
23.
Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S.,
Uhlig, S. Software-Defined Networking: A Comprehensive Survey // Proceedings of
the IEEE. 2015. Vol. 103. Iss. 1. pp. 14–76.
88
24.
Xia, W., Wen, Y., Foh, C., Niyato, D., Xie, H. A Survey on Software-
Defined Networking // IEEE Communications Surveys &Tutorials. 2015. Vol. 17. Iss.
1. pp. 27–51.
25.
Владыко А. Г., Киричек Р. В., Великоречин М. А., Думин Д. И.
Комплексная методика тестирования фрагмента программно определяемой сети
// Информационные технологии и телекоммуникации. 2015. № 2. С. 20–29.
26.
Васильев А. Б., Тарасов Д. В., Андреев Д. В., Кучерявый А. Е.
Тестирование сетей связи следующего поколения. М.: Изд-во ФГУП ЦНИИС,
2008. 140 с.
27.
S. Paul, J. Pan and R. Jain, “Architectures for the Future Networks and
the Next Generation Internet: A Survey,” Computer Communications, vol. 34, no. 1,
pp. 2-42, January 2011, Elsevier.
28.
A. Gavras, A. Karila, S. Fdida, M. May and M. Potts, “Future Internet
Research and Experimentation: The FIRE Initiative,” ACM SIGCOMM Computer
Communication Review, vol. 37, no. 3, pp. 89-92, July 2007.
29.
J. Pan, S. Paul and R. Jain, “A Survey of the Research on Future Internet
Architectures,” IEEE Communications Magazine, vol. 49, no. 7, pp. 26-36, July
2011.
30.
M. Jammal, T. Singh, A. Shami, R. Asal and Y. Li, “Software-Defined
Networking: State of the Art and Research Challenges,” Computer Networks, vol. 72,
pp. 74-98, October 2014.
31.
A. Lara, A Kolasani and B. Ramamurthy, “Network Innovation using
OpenFlow: A Survey,” IEEE Communication Surveys and Tutorials, vol. 16, no. 1,
pp. 493-512, First 2014.
32.
N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J.
Rexford, S. Shenker and J. Turner, “OpenFlow: Enabling Innovation in Campus
Networks, ” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp.
69-74, April 2008.
89
33.
OpenFlow Switch Specification, Version 1.1.0 (Wire Protocol 0x02)
[Электронный
ресурс].
–
Режим
доступа:
http://archive.openflow.org/documents/openflow-specv1.1.0.pdf. – Дата доступа:
05.06.2018.
34.
I. Z. Bholebawa, R. K. Jha and U. D. Dalal, “Performance Analysis of
Proposed OpenFlow-based Network Architecture Using Mininet,” Wireless Personal
Communication, vol. 83, no. 4, pp. 1-18, July 2015, Springer.
35.
B. Lantz, B. Heller and N. McKeown, “A Network in a Laptop: Rapid
Prototyping for Software-Defined Networks,” in Hotnets-IX Proceedings of the 9th
ACM SIGCOMM Workshop on Hot Topics in Networks, New York, NY, USA,
October 2010.
36.
Dr. R. K. Jha, P. Kharga, I. Z. Bholebawa, S. Satyarthi, Anuradha, and S.
Kumari, “OpenFlow Technology: A Journey of Simulation Tools,” International
Journal of Computer Network and Information Security (IJCNIS), vol. 6, no. 11, pp.
49-55, October 2014.
37.
Малахов, С.В. Исследование производительности контроллера в
программно-определяемых сетях / В.Н. Тарасов, С.В Малахов // Системы
управления и информационные технологии. -2013. -№3 (53). -С. 64-67.
38.
Малахов, С.В. Теоретическое и экспериментальное исследование
задержки в программного-кофигурируемых сетях / С.В. Малахов, В.Н.Тарасов //
Инфокоммуникационные технологии. -2015. -№4.
39.
Технологии SDN и NFV: новые возможности для телекоммуникаций
[Электронный ресурс]. – Режим доступа: http://arccn.ru/media/1132. – Дата
доступа: 05.06.2018.
40.
Tavakoli, A. Applying nox to the datacenter / A. Tavakoli, M. Casado, T.
Koponen // In Proceedings of HotNets, 2009. -issue 8. -p. 42-48.
90
41.
Curtis, A. Devoflow: scaling flow management for high-performance
networks / A. Curtis, J. Mogul, J. Tourrilhes, P. Yalagan-Dula, P. Sharma // In
Proceedings of the ACM SIGCOMM, 2011. -vol. 1. -p. 127-133.
91
ПРИЛОЖЕНИЕ А
(обязательное)
ПРОГРАММНЫЙ КОД
#!/usr/bin/python
from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSController
from mininet.node import CPULimitedHost, Host, Node
from mininet.node import OVSKernelSwitch, UserSwitch
from mininet.node import IVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info
from mininet.link import TCLink, Intf
from subprocess import call
def myNetwork():
net = Mininet( topo=None,
build=False,
ipBase='10.0.0.0/8')
info( '*** Adding controller\n' )
c0=net.addController(name='c0',
controller=Controller,
protocol='tcp',
port=6633)
info( '*** Add switches\n')
s424 = net.addSwitch('s 424', cls=OVSKernelSwitch)
s420 = net.addSwitch('s 420', cls=OVSKernelSwitch)
s410 = net.addSwitch('s 410', cls=OVSKernelSwitch)
kross42 = net.addSwitch('kross 4.2', cls=OVSKernelSwitch)
s415 = net.addSwitch('s 415', cls=OVSKernelSwitch)
s405 = net.addSwitch('s 405', cls=OVSKernelSwitch)
s402 = net.addSwitch('s 402', cls=OVSKernelSwitch)
s422 = net.addSwitch('s 422', cls=OVSKernelSwitch)
s417 = net.addSwitch('s 417', cls=OVSKernelSwitch)
kross41 = net.addSwitch('kross 4.1', cls=OVSKernelSwitch)
s310 = net.addSwitch('s 310', cls=OVSKernelSwitch)
s311 = net.addSwitch('s 311', cls=OVSKernelSwitch)
s312 = net.addSwitch('s 312', cls=OVSKernelSwitch)
s304 = net.addSwitch('s 304', cls=OVSKernelSwitch)
s307 = net.addSwitch('s 307', cls=OVSKernelSwitch)
kross32 = net.addSwitch('kross 3.2', cls=OVSKernelSwitch)
s319 = net.addSwitch('s 319', cls=OVSKernelSwitch)
s325 = net.addSwitch('s 325', cls=OVSKernelSwitch)
kross31 = net.addSwitch('kross 3.1', cls=OVSKernelSwitch)
92
s211 = net.addSwitch('s 211', cls=OVSKernelSwitch)
s214 = net.addSwitch('s 214', cls=OVSKernelSwitch)
s212 = net.addSwitch('s 212', cls=OVSKernelSwitch)
s215 = net.addSwitch('s 215', cls=OVSKernelSwitch)
kross22 = net.addSwitch('kross 2.2', cls=OVSKernelSwitch)
s204 = net.addSwitch('s 204', cls=OVSKernelSwitch)
s209 = net.addSwitch('s 209', cls=OVSKernelSwitch)
s201 = net.addSwitch('s 201', cls=OVSKernelSwitch)
s203 = net.addSwitch('s 203', cls=OVSKernelSwitch)
s205 = net.addSwitch('s 205', cls=OVSKernelSwitch)
s208 = net.addSwitch('s 208', cls=OVSKernelSwitch)
kross21 = net.addSwitch('kross 2.1', cls=OVSKernelSwitch)
s107 = net.addSwitch('s 107', cls=OVSKernelSwitch)
s103 = net.addSwitch('s 103', cls=OVSKernelSwitch)
s155 = net.addSwitch('s 155', cls=OVSKernelSwitch)
s164 = net.addSwitch('s 164', cls=OVSKernelSwitch)
kross11 = net.addSwitch('kross 1.1', cls=OVSKernelSwitch)
s113 = net.addSwitch('s 113', cls=OVSKernelSwitch)
s110 = net.addSwitch('s 110', cls=OVSKernelSwitch)
kross12 = net.addSwitch('kross 1.2', cls=OVSKernelSwitch)
info( '*** Add hosts\n')
h418d1 = net.addHost('h 418.1', cls=Host, ip='10.0.0.5', defaultRoute=None)
h410d1 = net.addHost('h 410.1', cls=Host, ip='10.0.0.6', defaultRoute=None)
h410d4 = net.addHost('h 410.4', cls=Host, ip='10.0.0.7', defaultRoute=None)
h417d1 = net.addHost('h 417.1', cls=Host, ip='10.0.0.8', defaultRoute=None)
h423d1 = net.addHost('h 423.1', cls=Host, ip='10.0.0.9', defaultRoute=None)
h426d2 = net.addHost('h 426.2', cls=Host, ip='10.0.0.10', defaultRoute=None)
h402d5 = net.addHost('h 402.5', cls=Host, ip='10.0.0.11', defaultRoute=None)
h402d6 = net.addHost('h 402.6', cls=Host, ip='10.0.0.12', defaultRoute=None)
h402d3 = net.addHost('h 402.3', cls=Host, ip='10.0.0.13', defaultRoute=None)
h420d2 = net.addHost('h 420.2', cls=Host, ip='10.0.0.14', defaultRoute=None)
h424d4 = net.addHost('h 424.4', cls=Host, ip='10.0.0.15', defaultRoute=None)
h422d4 = net.addHost('h 422.4', cls=Host, ip='10.0.0.16', defaultRoute=None)
h402d7 = net.addHost('h 402.7', cls=Host, ip='10.0.0.17', defaultRoute=None)
h420d4 = net.addHost('h 420.4', cls=Host, ip='10.0.0.18', defaultRoute=None)
h414d2 = net.addHost('h 414.2', cls=Host, ip='10.0.0.19', defaultRoute=None)
h419d1 = net.addHost('h 419.1', cls=Host, ip='10.0.0.20', defaultRoute=None)
h402d10 = net.addHost('h 402.10', cls=Host, ip='10.0.0.21', defaultRoute=None)
h420d3 = net.addHost('h 420.3', cls=Host, ip='10.0.0.22', defaultRoute=None)
h415d5 = net.addHost('h 415.5', cls=Host, ip='10.0.0.23', defaultRoute=None)
h402d9 = net.addHost('h 402.9', cls=Host, ip='10.0.0.24', defaultRoute=None)
h415d3 = net.addHost('h 415.3', cls=Host, ip='10.0.0.25', defaultRoute=None)
h420d5 = net.addHost('h 420.5', cls=Host, ip='10.0.0.26', defaultRoute=None)
h415d6 = net.addHost('h 415.6', cls=Host, ip='10.0.0.27', defaultRoute=None)
h404d2 = net.addHost('h 404.2', cls=Host, ip='10.0.0.28', defaultRoute=None)
h426d1 = net.addHost('h 426.1', cls=Host, ip='10.0.0.29', defaultRoute=None)
h410d3 = net.addHost('h 410.3', cls=Host, ip='10.0.0.30', defaultRoute=None)
93
h418d2 = net.addHost('h 418.2', cls=Host, ip='10.0.0.31', defaultRoute=None)
h410d2 = net.addHost('h 410.2', cls=Host, ip='10.0.0.32', defaultRoute=None)
h422d2 = net.addHost('h 422.2', cls=Host, ip='10.0.0.33', defaultRoute=None)
h403d1 = net.addHost('h 403.1', cls=Host, ip='10.0.0.34', defaultRoute=None)
h425d2 = net.addHost('h 425.2', cls=Host, ip='10.0.0.35', defaultRoute=None)
h422d3 = net.addHost('h 422.3', cls=Host, ip='10.0.0.36', defaultRoute=None)
h422d1 = net.addHost('h 422.1', cls=Host, ip='10.0.0.37', defaultRoute=None)
h417d6 = net.addHost('h 417.6', cls=Host, ip='10.0.0.38', defaultRoute=None)
h424d1 = net.addHost('h 424.1', cls=Host, ip='10.0.0.39', defaultRoute=None)
h405d3 = net.addHost('h 405.3', cls=Host, ip='10.0.0.40', defaultRoute=None)
h406d2 = net.addHost('h 406.2', cls=Host, ip='10.0.0.41', defaultRoute=None)
h423d2 = net.addHost('h 423.2', cls=Host, ip='10.0.0.42', defaultRoute=None)
h420d1 = net.addHost('h 420.1', cls=Host, ip='10.0.0.43', defaultRoute=None)
h425d1 = net.addHost('h 425.1', cls=Host, ip='10.0.0.44', defaultRoute=None)
h422d5 = net.addHost('h 422.5', cls=Host, ip='10.0.0.45', defaultRoute=None)
h415d2 = net.addHost('h 415.2', cls=Host, ip='10.0.0.46', defaultRoute=None)
h419d2 = net.addHost('h 419.2', cls=Host, ip='10.0.0.47', defaultRoute=None)
h408d4 = net.addHost('h 408.4', cls=Host, ip='10.0.0.48', defaultRoute=None)
h403d2 = net.addHost('h 403.2', cls=Host, ip='10.0.0.49', defaultRoute=None)
h417d4 = net.addHost('h 417.4', cls=Host, ip='10.0.0.50', defaultRoute=None)
h417d3 = net.addHost('h 417.3', cls=Host, ip='10.0.0.51', defaultRoute=None)
h408d3 = net.addHost('h 408.3', cls=Host, ip='10.0.0.52', defaultRoute=None)
h417d2 = net.addHost('h 417.2', cls=Host, ip='10.0.0.53', defaultRoute=None)
h402d4 = net.addHost('h 402.4', cls=Host, ip='10.0.0.54', defaultRoute=None)
h408d2 = net.addHost('h 408.2', cls=Host, ip='10.0.0.55', defaultRoute=None)
h401d1 = net.addHost('h 401.1', cls=Host, ip='10.0.0.56', defaultRoute=None)
h407d1 = net.addHost('h 407.1', cls=Host, ip='10.0.0.57', defaultRoute=None)
h406d1 = net.addHost('h 406.1', cls=Host, ip='10.0.0.58', defaultRoute=None)
h404d1 = net.addHost('h 404.1', cls=Host, ip='10.0.0.59', defaultRoute=None)
h407d2 = net.addHost('h 407.2', cls=Host, ip='10.0.0.60', defaultRoute=None)
h402d2 = net.addHost('h 402.2', cls=Host, ip='10.0.0.61', defaultRoute=None)
h401d2 = net.addHost('h 401.2', cls=Host, ip='10.0.0.62', defaultRoute=None)
h405d1 = net.addHost('h 405.1', cls=Host, ip='10.0.0.63', defaultRoute=None)
h424d2 = net.addHost('h 424.2', cls=Host, ip='10.0.0.64', defaultRoute=None)
h402d8 = net.addHost('h 402.8', cls=Host, ip='10.0.0.65', defaultRoute=None)
h424d6 = net.addHost('h 424.6', cls=Host, ip='10.0.0.66', defaultRoute=None)
h405d2 = net.addHost('h 405.2', cls=Host, ip='10.0.0.67', defaultRoute=None)
h424d3 = net.addHost('h 424.3', cls=Host, ip='10.0.0.68', defaultRoute=None)
h417d5 = net.addHost('h 417.5', cls=Host, ip='10.0.0.69', defaultRoute=None)
h424d5 = net.addHost('h 424.5', cls=Host, ip='10.0.0.70', defaultRoute=None)
h416d1 = net.addHost('h 416.1', cls=Host, ip='10.0.0.71', defaultRoute=None)
h402d1 = net.addHost('h 402.1', cls=Host, ip='10.0.0.72', defaultRoute=None)
h414d1 = net.addHost('h 414.1', cls=Host, ip='10.0.0.73', defaultRoute=None)
h408d1 = net.addHost('h 408.1', cls=Host, ip='10.0.0.74', defaultRoute=None)
h409d2 = net.addHost('h 409.2', cls=Host, ip='10.0.0.75', defaultRoute=None)
h416d2 = net.addHost('h 416.2', cls=Host, ip='10.0.0.76', defaultRoute=None)
h409d1 = net.addHost('h 409.1', cls=Host, ip='10.0.0.77', defaultRoute=None)
h415d4 = net.addHost('h 415.4', cls=Host, ip='10.0.0.78', defaultRoute=None)
h415d1 = net.addHost('h 415.1', cls=Host, ip='10.0.0.79', defaultRoute=None)
h310d1 = net.addHost('h 310.1', cls=Host, ip='10.0.0.80', defaultRoute=None)
h310d2 = net.addHost('h 310.2', cls=Host, ip='10.0.0.81', defaultRoute=None)
94
h310d3 = net.addHost('h 310.3', cls=Host, ip='10.0.0.82', defaultRoute=None)
h310d4 = net.addHost('h 310.4', cls=Host, ip='10.0.0.83', defaultRoute=None)
h310d5 = net.addHost('h 310.5', cls=Host, ip='10.0.0.84', defaultRoute=None)
h311d1 = net.addHost('h 311.1', cls=Host, ip='10.0.0.85', defaultRoute=None)
h311d2 = net.addHost('h 311.2', cls=Host, ip='10.0.0.86', defaultRoute=None)
h311d3 = net.addHost('h 311.3', cls=Host, ip='10.0.0.87', defaultRoute=None)
h311d4 = net.addHost('h 311.4', cls=Host, ip='10.0.0.88', defaultRoute=None)
h311d5 = net.addHost('h 311.5', cls=Host, ip='10.0.0.89', defaultRoute=None)
h312d1 = net.addHost('h 312.1', cls=Host, ip='10.0.0.90', defaultRoute=None)
h312d2 = net.addHost('h 312.2', cls=Host, ip='10.0.0.91', defaultRoute=None)
h312d3 = net.addHost('h 312.3', cls=Host, ip='10.0.0.92', defaultRoute=None)
h312d4 = net.addHost('h 312.4', cls=Host, ip='10.0.0.93', defaultRoute=None)
h312d5 = net.addHost('h 312.5', cls=Host, ip='10.0.0.94', defaultRoute=None)
h301d1 = net.addHost('h 301.1', cls=Host, ip='10.0.0.95', defaultRoute=None)
h301d2 = net.addHost('h 301.2', cls=Host, ip='10.0.0.96', defaultRoute=None)
h304d1 = net.addHost('h 304.1', cls=Host, ip='10.0.0.97', defaultRoute=None)
h304d2 = net.addHost('h 304.2', cls=Host, ip='10.0.0.98', defaultRoute=None)
h304d3 = net.addHost('h 304.3', cls=Host, ip='10.0.0.99', defaultRoute=None)
h304d4 = net.addHost('h 304.4', cls=Host, ip='10.0.0.100', defaultRoute=None)
h304d5 = net.addHost('h 304.5', cls=Host, ip='10.0.0.101', defaultRoute=None)
h304d6 = net.addHost('h 304.6', cls=Host, ip='10.0.0.102', defaultRoute=None)
h307d1 = net.addHost('h 307.1', cls=Host, ip='10.0.0.103', defaultRoute=None)
h307d2 = net.addHost('h 307.2', cls=Host, ip='10.0.0.104', defaultRoute=None)
h307d3 = net.addHost('h 307.3', cls=Host, ip='10.0.0.105', defaultRoute=None)
h307d4 = net.addHost('h 307.4', cls=Host, ip='10.0.0.106', defaultRoute=None)
h307d5 = net.addHost('h 307.5', cls=Host, ip='10.0.0.107', defaultRoute=None)
h306d1 = net.addHost('h 306.1', cls=Host, ip='10.0.0.108', defaultRoute=None)
h306d2 = net.addHost('h 306.2', cls=Host, ip='10.0.0.109', defaultRoute=None)
h309d1 = net.addHost('h 309.1', cls=Host, ip='10.0.0.110', defaultRoute=None)
h309d2 = net.addHost('h 309.2', cls=Host, ip='10.0.0.112', defaultRoute=None)
h317d1 = net.addHost('h 317.1', cls=Host, ip='10.0.0.113', defaultRoute=None)
h317d2 = net.addHost('h 317.2', cls=Host, ip='10.0.0.114', defaultRoute=None)
h319d1 = net.addHost('h 319.1', cls=Host, ip='10.0.0.115', defaultRoute=None)
h319d2 = net.addHost('h 319.2', cls=Host, ip='10.0.0.116', defaultRoute=None)
h319d3 = net.addHost('h 319.3', cls=Host, ip='10.0.0.117', defaultRoute=None)
h319d4 = net.addHost('h 319.4', cls=Host, ip='10.0.0.118', defaultRoute=None)
h319d5 = net.addHost('h 319.5', cls=Host, ip='10.0.0.119', defaultRoute=None)
h325d1 = net.addHost('h 325.1', cls=Host, ip='10.0.0.120', defaultRoute=None)
h325d2 = net.addHost('h 325.2', cls=Host, ip='10.0.0.121', defaultRoute=None)
h325d3 = net.addHost('h 325.3', cls=Host, ip='10.0.0.122', defaultRoute=None)
h325d4 = net.addHost('h 325.4', cls=Host, ip='10.0.0.123', defaultRoute=None)
h318d1 = net.addHost('h 318.1', cls=Host, ip='10.0.0.124', defaultRoute=None)
h318d2 = net.addHost('h 318.2', cls=Host, ip='10.0.0.125', defaultRoute=None)
h323d1 = net.addHost('h 323.1', cls=Host, ip='10.0.0.126', defaultRoute=None)
h323d2 = net.addHost('h 323.2', cls=Host, ip='10.0.0.127', defaultRoute=None)
h324d1 = net.addHost('h 324.1', cls=Host, ip='10.0.0.128', defaultRoute=None)
h324d2 = net.addHost('h 324.2', cls=Host, ip='10.0.0.129', defaultRoute=None)
h211d1 = net.addHost('h 211.1', cls=Host, ip='10.0.0.130', defaultRoute=None)
h211d2 = net.addHost('h 211.2', cls=Host, ip='10.0.0.131', defaultRoute=None)
h211d3 = net.addHost('h 211.3', cls=Host, ip='10.0.0.132', defaultRoute=None)
h211d4 = net.addHost('h 211.4', cls=Host, ip='10.0.0.133', defaultRoute=None)
95
h211d5 = net.addHost('h 211.5', cls=Host, ip='10.0.0.134', defaultRoute=None)
h211d6 = net.addHost('h 211.6', cls=Host, ip='10.0.0.135', defaultRoute=None)
h214d1 = net.addHost('h 214.1', cls=Host, ip='10.0.0.136', defaultRoute=None)
h214d2 = net.addHost('h 214.2', cls=Host, ip='10.0.0.137', defaultRoute=None)
h214d3 = net.addHost('h 214.3', cls=Host, ip='10.0.0.138', defaultRoute=None)
h214d4 = net.addHost('h 214.4', cls=Host, ip='10.0.0.139', defaultRoute=None)
h214d5 = net.addHost('h 214.5', cls=Host, ip='10.0.0.140', defaultRoute=None)
h214d6 = net.addHost('h 214.6', cls=Host, ip='10.0.0.141', defaultRoute=None)
h212d1 = net.addHost('h 212.1', cls=Host, ip='10.0.0.142', defaultRoute=None)
h212d2 = net.addHost('h 212.2', cls=Host, ip='10.0.0.143', defaultRoute=None)
h212d3 = net.addHost('h 212.3', cls=Host, ip='10.0.0.144', defaultRoute=None)
h212d4 = net.addHost('h 212.4', cls=Host, ip='10.0.0.145', defaultRoute=None)
h212d5 = net.addHost('h 212.5', cls=Host, ip='10.0.0.146', defaultRoute=None)
h212d6 = net.addHost('h 212.6', cls=Host, ip='10.0.0.147', defaultRoute=None)
h215d1 = net.addHost('h 215.1', cls=Host, ip='10.0.0.148', defaultRoute=None)
h215d2 = net.addHost('h 215.2', cls=Host, ip='10.0.0.149', defaultRoute=None)
h215d3 = net.addHost('h 215.3', cls=Host, ip='10.0.0.150', defaultRoute=None)
h215d4 = net.addHost('h 215.4', cls=Host, ip='10.0.0.151', defaultRoute=None)
h204d1 = net.addHost('h 204.1', cls=Host, ip='10.0.0.152', defaultRoute=None)
h204d2 = net.addHost('h 204.2', cls=Host, ip='10.0.0.153', defaultRoute=None)
h204d3 = net.addHost('h 204.3', cls=Host, ip='10.0.0.154', defaultRoute=None)
h204d4 = net.addHost('h 204.4', cls=Host, ip='10.0.0.155', defaultRoute=None)
h204d5 = net.addHost('h 204.5', cls=Host, ip='10.0.0.156', defaultRoute=None)
h204d6 = net.addHost('h 204.6', cls=Host, ip='10.0.0.157', defaultRoute=None)
h210d1 = net.addHost('h 210.1', cls=Host, ip='10.0.0.158', defaultRoute=None)
h209d1 = net.addHost('h 209.1', cls=Host, ip='10.0.0.159', defaultRoute=None)
h209d2 = net.addHost('h 209.2', cls=Host, ip='10.0.0.160', defaultRoute=None)
h209d3 = net.addHost('h 209.3', cls=Host, ip='10.0.0.161', defaultRoute=None)
h209d4 = net.addHost('h 209.4', cls=Host, ip='10.0.0.162', defaultRoute=None)
h209d5 = net.addHost('h 209.5', cls=Host, ip='10.0.0.163', defaultRoute=None)
h209d6 = net.addHost('h 209.6', cls=Host, ip='10.0.0.164', defaultRoute=None)
h209d7 = net.addHost('h 209.7', cls=Host, ip='10.0.0.165', defaultRoute=None)
h209d8 = net.addHost('h 209.8', cls=Host, ip='10.0.0.166', defaultRoute=None)
h209d9 = net.addHost('h 209.9', cls=Host, ip='10.0.0.167', defaultRoute=None)
h209d10 = net.addHost('h 209.10', cls=Host, ip='10.0.0.168', defaultRoute=None)
h209d11 = net.addHost('h 209.11', cls=Host, ip='10.0.0.169', defaultRoute=None)
h209d12 = net.addHost('h 209.12', cls=Host, ip='10.0.0.170', defaultRoute=None)
h201d1 = net.addHost('h 201.1', cls=Host, ip='10.0.0.171', defaultRoute=None)
h201d2 = net.addHost('h 201.2', cls=Host, ip='10.0.0.172', defaultRoute=None)
h201d3 = net.addHost('h 201.3', cls=Host, ip='10.0.0.173', defaultRoute=None)
h201d4 = net.addHost('h 201.4', cls=Host, ip='10.0.0.174', defaultRoute=None)
h201d5 = net.addHost('h 201.5', cls=Host, ip='10.0.0.175', defaultRoute=None)
h201d6 = net.addHost('h 201.6', cls=Host, ip='10.0.0.176', defaultRoute=None)
h203d1 = net.addHost('h 203.1', cls=Host, ip='10.0.0.177', defaultRoute=None)
h203d2 = net.addHost('h 203.2', cls=Host, ip='10.0.0.178', defaultRoute=None)
h203d3 = net.addHost('h 203.3', cls=Host, ip='10.0.0.179', defaultRoute=None)
h203d4 = net.addHost('h 203.4', cls=Host, ip='10.0.0.180', defaultRoute=None)
h203d5 = net.addHost('h 203.5', cls=Host, ip='10.0.0.181', defaultRoute=None)
h203d6 = net.addHost('h 203.6', cls=Host, ip='10.0.0.182', defaultRoute=None)
h205d1 = net.addHost('h 205.1', cls=Host, ip='10.0.0.183', defaultRoute=None)
h205d2 = net.addHost('h 205.2', cls=Host, ip='10.0.0.184', defaultRoute=None)
96
h205d3 = net.addHost('h 205.3', cls=Host, ip='10.0.0.185', defaultRoute=None)
h205d4 = net.addHost('h 205.4', cls=Host, ip='10.0.0.186', defaultRoute=None)
h210d1 = net.addHost('h 210.1', cls=Host, ip='10.0.0.187', defaultRoute=None)
h208d1 = net.addHost('h 208.1', cls=Host, ip='10.0.0.188', defaultRoute=None)
h208d2 = net.addHost('h 208.2', cls=Host, ip='10.0.0.189', defaultRoute=None)
h208d3 = net.addHost('h 208.3', cls=Host, ip='10.0.0.190', defaultRoute=None)
h208d4 = net.addHost('h 208.4', cls=Host, ip='10.0.0.191', defaultRoute=None)
h208d5 = net.addHost('h 208.5', cls=Host, ip='10.0.0.192', defaultRoute=None)
h208d6 = net.addHost('h 208.6', cls=Host, ip='10.0.0.193', defaultRoute=None)
h103d1 = net.addHost('h 103.1', cls=Host, ip='10.0.0.194', defaultRoute=None)
h103d2 = net.addHost('h 103.2', cls=Host, ip='10.0.0.195', defaultRoute=None)
h103d3 = net.addHost('h 103.3', cls=Host, ip='10.0.0.196', defaultRoute=None)
h103d4 = net.addHost('h 103.4', cls=Host, ip='10.0.0.197', defaultRoute=None)
h103d5 = net.addHost('h 103.5', cls=Host, ip='10.0.0.198', defaultRoute=None)
h155d1 = net.addHost('h 155.1', cls=Host, ip='10.0.0.199', defaultRoute=None)
h155d2 = net.addHost('h 155.2', cls=Host, ip='10.0.0.200', defaultRoute=None)
h155d3 = net.addHost('h 155.3', cls=Host, ip='10.0.0.201', defaultRoute=None)
h164d1 = net.addHost('h 164.1', cls=Host, ip='10.0.0.202', defaultRoute=None)
h164d2 = net.addHost('h 164.2', cls=Host, ip='10.0.0.203', defaultRoute=None)
h164d3 = net.addHost('h 164.3', cls=Host, ip='10.0.0.204', defaultRoute=None)
h164d4 = net.addHost('h 164.4', cls=Host, ip='10.0.0.205', defaultRoute=None)
h164d5 = net.addHost('h 164.5', cls=Host, ip='10.0.0.206', defaultRoute=None)
h107d1 = net.addHost('h 107.1', cls=Host, ip='10.0.0.207', defaultRoute=None)
h107d2 = net.addHost('h 107.2', cls=Host, ip='10.0.0.208', defaultRoute=None)
h107d3 = net.addHost('h 107.3', cls=Host, ip='10.0.0.209', defaultRoute=None)
h107d4 = net.addHost('h 107.4', cls=Host, ip='10.0.0.210', defaultRoute=None)
h107d5 = net.addHost('h 107.5', cls=Host, ip='10.0.0.211', defaultRoute=None)
h107d6 = net.addHost('h 107.6', cls=Host, ip='10.0.0.212', defaultRoute=None)
h107d7 = net.addHost('h 107.7', cls=Host, ip='10.0.0.213', defaultRoute=None)
h107d8 = net.addHost('h 107.8', cls=Host, ip='10.0.0.214', defaultRoute=None)
h107d9 = net.addHost('h 107.9', cls=Host, ip='10.0.0.215', defaultRoute=None)
h107d10 = net.addHost('h 107.10', cls=Host, ip='10.0.0.216', defaultRoute=None)
h107d11 = net.addHost('h 107.11', cls=Host, ip='10.0.0.217', defaultRoute=None)
h107d12 = net.addHost('h 107.12', cls=Host, ip='10.0.0.218', defaultRoute=None)
h107d13 = net.addHost('h 107.13', cls=Host, ip='10.0.0.219', defaultRoute=None)
h111d1 = net.addHost('h 111.1', cls=Host, ip='10.0.0.220', defaultRoute=None)
h100d1 = net.addHost('h 100.1', cls=Host, ip='10.0.0.221', defaultRoute=None)
h100d2 = net.addHost('h 100.2', cls=Host, ip='10.0.0.222', defaultRoute=None)
h113d1 = net.addHost('h 113.1', cls=Host, ip='10.0.0.223', defaultRoute=None)
h113d2 = net.addHost('h 113.2', cls=Host, ip='10.0.0.224', defaultRoute=None)
h113d3 = net.addHost('h 113.3', cls=Host, ip='10.0.0.225', defaultRoute=None)
h113d4 = net.addHost('h 113.4', cls=Host, ip='10.0.0.226', defaultRoute=None)
h113d5 = net.addHost('h 113.5', cls=Host, ip='10.0.0.227', defaultRoute=None)
h113d6 = net.addHost('h 113.6', cls=Host, ip='10.0.0.228', defaultRoute=None)
h113d7 = net.addHost('h 113.7', cls=Host, ip='10.0.0.229', defaultRoute=None)
h113d8 = net.addHost('h 113.8', cls=Host, ip='10.0.0.230', defaultRoute=None)
h113d9 = net.addHost('h 113.9', cls=Host, ip='10.0.0.231', defaultRoute=None)
h113d10 = net.addHost('h 113.10', cls=Host, ip='10.0.0.232', defaultRoute=None)
h110d1 = net.addHost('h 110.1', cls=Host, ip='10.0.0.233', defaultRoute=None)
h110d2 = net.addHost('h 110.2', cls=Host, ip='10.0.0.234', defaultRoute=None)
h110d3 = net.addHost('h 110.3', cls=Host, ip='10.0.0.235', defaultRoute=None)
97
h110d4 = net.addHost('h 110.4', cls=Host, ip='10.0.0.236', defaultRoute=None)
h110d5 = net.addHost('h 110.5', cls=Host, ip='10.0.0.237', defaultRoute=None)
h110d6 = net.addHost('h 110.6', cls=Host, ip='10.0.0.238', defaultRoute=None)
h108d1 = net.addHost('h 108.1', cls=Host, ip='10.0.0.239', defaultRoute=None)
h108d2 = net.addHost('h 108.2', cls=Host, ip='10.0.0.240', defaultRoute=None)
h143d1 = net.addHost('h 143.1', cls=Host, ip='10.0.0.241', defaultRoute=None)
h143d2 = net.addHost('h 143.2', cls=Host, ip='10.0.0.242', defaultRoute=None)
info( '*** Add links\n')
net.addLink(h405d1, s405, cls=TCLink)
net.addLink(h405d2, s405, cls=TCLink)
net.addLink(h405d3, s405, cls=TCLink)
net.addLink(h409d2, kross42, cls=TCLink)
net.addLink(h409d1, kross42, cls=TCLink)
net.addLink(h408d4, kross42, cls=TCLink)
net.addLink(h408d3, kross42, cls=TCLink)
net.addLink(h408d2, kross42, cls=TCLink)
net.addLink(h407d1, kross42, cls=TCLink)
net.addLink(h407d2, kross42, cls=TCLink)
net.addLink(h406d1, kross42, cls=TCLink)
net.addLink(h406d2, kross42, cls=TCLink)
net.addLink(h401d1, kross42, cls=TCLink)
net.addLink(h401d2, kross42, cls=TCLink)
net.addLink(h402d2, s402, cls=TCLink)
net.addLink(h402d5, s402, cls=TCLink)
net.addLink(h402d3, s402, cls=TCLink)
net.addLink(h402d7, s402, cls=TCLink)
net.addLink(h402d6, s402, cls=TCLink)
net.addLink(h402d9, s402, cls=TCLink)
net.addLink(h402d1, s402, cls=TCLink)
net.addLink(h402d8, s402, cls=TCLink)
net.addLink(h402d10, s402, cls=TCLink)
net.addLink(h402d4, s402, cls=TCLink)
net.addLink(s402, kross42, cls=TCLink)
net.addLink(h417d1, s417, cls=TCLink)
net.addLink(h417d2, s417, cls=TCLink)
net.addLink(h417d3, s417, cls=TCLink)
net.addLink(h417d4, s417, cls=TCLink)
net.addLink(h417d5, s417, cls=TCLink)
net.addLink(h417d6, s417, cls=TCLink)
net.addLink(h410d1, s410, cls=TCLink)
net.addLink(h410d2, s410, cls=TCLink)
net.addLink(h410d3, s410, cls=TCLink)
net.addLink(h410d4, s410, cls=TCLink)
net.addLink(s417, kross42, cls=TCLink)
net.addLink(h403d1, kross42, cls=TCLink)
net.addLink(h403d2, kross42, cls=TCLink)
net.addLink(h415d1, s415, cls=TCLink)
net.addLink(h415d2, s415, cls=TCLink)
net.addLink(h415d3, s415, cls=TCLink)
98
net.addLink(h415d4, s415, cls=TCLink)
net.addLink(h415d5, s415, cls=TCLink)
net.addLink(h415d6, s415, cls=TCLink)
net.addLink(h404d1, kross42, cls=TCLink)
net.addLink(h404d2, kross42, cls=TCLink)
net.addLink(h414d1, kross41, cls=TCLink)
net.addLink(h414d2, kross41, cls=TCLink)
net.addLink(h416d2, kross41, cls=TCLink)
net.addLink(h416d1, kross41, cls=TCLink)
net.addLink(h418d1, kross41, cls=TCLink)
net.addLink(h418d2, kross41, cls=TCLink)
net.addLink(h419d1, kross41, cls=TCLink)
net.addLink(h419d2, kross41, cls=TCLink)
net.addLink(s420, h420d1, cls=TCLink)
net.addLink(s420, h420d2, cls=TCLink)
net.addLink(s420, h420d4, cls=TCLink)
net.addLink(s420, h420d3, cls=TCLink)
net.addLink(s420, h420d5, cls=TCLink)
net.addLink(s420, kross41, cls=TCLink)
net.addLink(kross42, s405, cls=TCLink)
net.addLink(kross42, s415, cls=TCLink)
net.addLink(h426d1, kross41, cls=TCLink)
net.addLink(h426d2, kross41, cls=TCLink)
net.addLink(h425d2, kross41, cls=TCLink)
net.addLink(h425d1, kross41, cls=TCLink)
net.addLink(kross41, h423d2, cls=TCLink)
net.addLink(kross41, h423d1, cls=TCLink)
net.addLink(kross41, s422, cls=TCLink)
net.addLink(s422, h422d1, cls=TCLink)
net.addLink(s422, h422d2, cls=TCLink)
net.addLink(s422, h422d3, cls=TCLink)
net.addLink(s422, h422d4, cls=TCLink)
net.addLink(s422, h422d5, cls=TCLink)
net.addLink(h424d1, s424, cls=TCLink)
net.addLink(h424d2, s424, cls=TCLink)
net.addLink(h424d3, s424, cls=TCLink)
net.addLink(h424d4, s424, cls=TCLink)
net.addLink(h424d5, s424, cls=TCLink)
net.addLink(h424d6, s424, cls=TCLink)
net.addLink(s424, kross41, cls=TCLink)
net.addLink(s410, kross42, cls=TCLink)
net.addLink(kross42, h408d1, cls=TCLink)
net.addLink(kross41, kross42, cls=TCLink)
net.addLink(h310d1, s310, cls=TCLink)
net.addLink(h310d2, s310, cls=TCLink)
net.addLink(h310d3, s310, cls=TCLink)
net.addLink(h310d4, s310, cls=TCLink)
net.addLink(h310d5, s310, cls=TCLink)
net.addLink(h311d1, s311, cls=TCLink)
net.addLink(h311d2, s311, cls=TCLink)
net.addLink(h311d3, s311, cls=TCLink)
99
net.addLink(h311d4, s311, cls=TCLink)
net.addLink(h311d5, s311, cls=TCLink)
net.addLink(h312d1, s312, cls=TCLink)
net.addLink(h312d2, s312, cls=TCLink)
net.addLink(h312d3, s312, cls=TCLink)
net.addLink(h312d4, s312, cls=TCLink)
net.addLink(h312d5, s312, cls=TCLink)
net.addLink(h304d1, s304, cls=TCLink)
net.addLink(h304d2, s304, cls=TCLink)
net.addLink(h304d3, s304, cls=TCLink)
net.addLink(h304d4, s304, cls=TCLink)
net.addLink(h304d5, s304, cls=TCLink)
net.addLink(h304d6, s304, cls=TCLink)
net.addLink(h301d1, kross32, cls=TCLink)
net.addLink(h301d2, kross32, cls=TCLink)
net.addLink(h307d1, s307, cls=TCLink)
net.addLink(h307d2, s307, cls=TCLink)
net.addLink(h307d3, s307, cls=TCLink)
net.addLink(h307d4, s307, cls=TCLink)
net.addLink(h307d5, s307, cls=TCLink)
net.addLink(h306d1, kross32, cls=TCLink)
net.addLink(h306d2, kross32, cls=TCLink)
net.addLink(h309d1, kross32, cls=TCLink)
net.addLink(h309d2, kross32, cls=TCLink)
net.addLink(h317d1, kross32, cls=TCLink)
net.addLink(h317d2, kross32, cls=TCLink)
net.addLink(h319d1, s319, cls=TCLink)
net.addLink(h319d2, s319, cls=TCLink)
net.addLink(h319d3, s319, cls=TCLink)
net.addLink(h319d4, s319, cls=TCLink)
net.addLink(h319d5, s319)
net.addLink(h325d1, s325)
net.addLink(h325d2, s325)
net.addLink(h325d3, s325)
net.addLink(h325d4, s325)
net.addLink(h323d1, kross31)
net.addLink(h323d2, kross31)
net.addLink(h324d1, kross31)
net.addLink(h324d2, kross31)
net.addLink(h318d1, kross31)
net.addLink(h318d2, kross31)
net.addLink(s310, kross32)
net.addLink(s311, kross32)
net.addLink(s312, kross32)
net.addLink(s304, kross32)
net.addLink(s307, kross32)
net.addLink(s319, kross31)
net.addLink(s325, kross31)
net.addLink(kross32, kross31)
net.addLink(h214d1, s214)
net.addLink(h214d2, s214)
100
net.addLink(h214d3, s214)
net.addLink(h214d4, s214)
net.addLink(h214d5, s214)
net.addLink(h214d6, s214)
net.addLink(h211d1, s211)
net.addLink(h211d2, s211)
net.addLink(h211d3, s211)
net.addLink(h211d4, s211)
net.addLink(h211d5, s211)
net.addLink(h211d6, s211)
net.addLink(h212d1, s212)
net.addLink(h212d2, s212)
net.addLink(h212d3, s212)
net.addLink(h212d4, s212)
net.addLink(h212d5, s212)
net.addLink(h212d6, s212)
net.addLink(h215d1, s215)
net.addLink(h215d2, s215)
net.addLink(h215d3, s215)
net.addLink(h215d4, s215)
net.addLink(s215, kross22)
net.addLink(s212, kross22)
net.addLink(s211, kross22)
net.addLink(s214, kross22)
net.addLink(h209d1, s209)
net.addLink(h209d2, s209)
net.addLink(h209d3, s209)
net.addLink(h209d4, s209)
net.addLink(h209d5, s209)
net.addLink(h209d6, s209)
net.addLink(h209d7, s209)
net.addLink(h209d8, s209)
net.addLink(h209d9, s209)
net.addLink(h209d10, s209)
net.addLink(h209d11, s209)
net.addLink(h209d12, s209)
net.addLink(h201d1, s201)
net.addLink(h201d2, s201)
net.addLink(h201d3, s201)
net.addLink(h201d4, s201)
net.addLink(h201d5, s201)
net.addLink(h201d6, s201)
net.addLink(h203d1, s203)
net.addLink(h203d2, s203)
net.addLink(h203d3, s203)
net.addLink(h203d4, s203)
net.addLink(h203d5, s203)
net.addLink(h203d6, s203)
net.addLink(h205d1, s205)
net.addLink(h205d2, s205)
net.addLink(h205d3, s205)
101
net.addLink(h205d4, s205)
net.addLink(h208d1, s208)
net.addLink(h208d2, s208)
net.addLink(h208d3, s208)
net.addLink(h208d4, s208)
net.addLink(h208d5, s208)
net.addLink(h208d6, s208)
net.addLink(h204d1, s204)
net.addLink(h204d2, s204)
net.addLink(h204d3, s204)
net.addLink(h204d4, s204)
net.addLink(h204d5, s204)
net.addLink(h204d6, s204)
net.addLink(s209, kross21)
net.addLink(s201, kross21)
net.addLink(s203, kross21)
net.addLink(s205, kross21)
net.addLink(s208, kross21)
net.addLink(s204, kross21)
net.addLink(h210d1, kross21)
net.addLink(kross22, kross21)
net.addLink(h103d1, s103)
net.addLink(h103d2, s103)
net.addLink(h103d3, s103)
net.addLink(h103d4, s103)
net.addLink(h103d5, s103)
net.addLink(h155d1, s155)
net.addLink(h155d2, s155)
net.addLink(h155d3, s155)
net.addLink(h164d1, s164)
net.addLink(h164d2, s164)
net.addLink(h164d3, s164)
net.addLink(h164d4, s164)
net.addLink(h164d5, s164)
net.addLink(h107d1, s107)
net.addLink(h107d2, s107)
net.addLink(h107d3, s107)
net.addLink(h107d4, s107)
net.addLink(h107d5, s107)
net.addLink(h107d6, s107)
net.addLink(h107d7, s107)
net.addLink(h107d8, s107)
net.addLink(h107d9, s107)
net.addLink(h107d10, s107)
net.addLink(h107d11, s107)
net.addLink(h107d12, s107)
net.addLink(h107d13, s107)
net.addLink(s103, kross11)
net.addLink(s155, kross11)
net.addLink(s164, kross11)
net.addLink(s107, kross11)
102
net.addLink(h113d1, s113)
net.addLink(h113d2, s113)
net.addLink(h113d3, s113)
net.addLink(h113d4, s113)
net.addLink(h113d5, s113)
net.addLink(h113d6, s113)
net.addLink(h113d7, s113)
net.addLink(h113d8, s113)
net.addLink(h113d9, s113)
net.addLink(h113d10, s113)
net.addLink(h110d1, s110)
net.addLink(h110d2, s110)
net.addLink(h110d3, s110)
net.addLink(h110d4, s110)
net.addLink(h110d5, s110)
net.addLink(h110d6, s110)
net.addLink(s113, kross12)
net.addLink(s110, kross12)
net.addLink(h108d1, kross12)
net.addLink(h108d2, kross12)
net.addLink(h143d1, kross12)
net.addLink(h143d2, kross12)
net.addLink(h111d1, kross12)
net.addLink(h100d1, kross12)
net.addLink(h100d2, kross12)
net.addLink(kross12, kross11)
net.addLink(kross12, kross22)
net.addLink(kross11, kross21)
net.addLink(kross22, kross32)
net.addLink(kross21, kross31)
net.addLink(kross42, kross32)
net.addLink(kross41, kross31)
info( '*** Starting network\n')
net.build()
info( '*** Starting controllers\n')
for controller in net.controllers:
controller.start()
info( '*** Starting switches\n')
net.get(s424).start([c0])
net.get(s420).start([c0])
net.get(s410).start([c0])
net.get(s415).start([c0])
net.get(s405).start([c0])
net.get(s402).start([c0])
net.get(s422).start([c0])
net.get(s417).start([c0])
net.get(kross41).start([c0])
net.get(kross42).start([c0])
103
net.get(s310).start([c0])
net.get(s311).start([c0])
net.get(s312).start([c0])
net.get(s304).start([c0])
net.get(s307).start([c0])
net.get(s319).start([c0])
net.get(s325).start([c0])
net.get(kross31).start([c0])
net.get(kross32).start([c0])
net.get(s211).start([c0])
net.get(s212).start([c0])
net.get(s215).start([c0])
net.get(s214).start([c0])
net.get(s204).start([c0])
net.get(s209).start([c0])
net.get(s201).start([c0])
net.get(s203).start([c0])
net.get(s205).start([c0])
net.get(s208).start([c0])
net.get(kross21).start([c0])
net.get(kross22).start([c0])
net.get(s103).start([c0])
net.get(s155).start([c0])
net.get(s164).start([c0])
net.get(s107).start([c0])
net.get(s113).start([c0])
net.get(s110).start([c0])
net.get(kross11).start([c0])
net.get(kross12).start([c0])
info( '*** Post configure switches and hosts\n')
CLI(net)
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
myNetwork()
Powered by TCPDF (www.tcpdf.org)
Powered by TCPDF (www.tcpdf.org)
Powered by TCPDF (www.tcpdf.org)
Powered by TCPDF (www.tcpdf.org)
1/--страниц
Пожаловаться на содержимое документа