Вычислительные сети, теория и практика.

BC/NW 2018 № 2 (33):4.3

ИССЛЕДОВАНИЕ ЗАВИСИМОСТИ ВРЕМЕНИ ПЕРЕХОДНОГО ПРОЦЕССА ОТ ПРОТОКОЛА МАРШРУТИЗАЦИИ В СЕТЯХ

Балк В.А.

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

1.Переходной процесс в компьтерной сети

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

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

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

Причины возникновения переходного процесса

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

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

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

Процессы протекающие в маршрутизаторе

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

Таблицы маршрутизации всех маршрутизаторов сформированы и в процессе работы сети в них не вносится никаких изменений. В этих условиях в сети возникает неисправность, переводящая сеть в состояние нестабильности. Для восстановления нормальной работы в маршрутизаторах запускается механизм обновления таблиц маршрутизации.

В качестве примера рассмотрим процессы, протекающие в одном маршрутизаторе сети.

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

После этого, обнаруживший неисправность маршрутизатор производит формирование специального служебного сообщения, которое будет передано всем непосредственным соседям маршрутизатора, обнаружившего неисправность или получившего подобное сообщение от своего соседа. Размер служебного сообщения и тип содержащейся в нем информации зависит от используемого протокола маршрутизации. Чем больше будет сообщение, сложнее алгоритм его формирования и слабее вычислительные мощности маршрутизатора, тем больше процессорного времени потребуется для его формирования, и тем дольше оно будет передаваться по сети. Обозначим время формирования служебного сообщения как t_L.

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

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

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

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

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

Влияние трафика на переходные процессы в сети

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

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

Принимаемые допущения при расчете времени переходных процессов

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

Сделаем первое допущение. Будем учитывать только пять компонентов переходных процессов, происходящих в маршрутизаторах: время обнаружения неисправности t_D, время формирования служебных сообщений t_L, время распространения по сети служебных сообщений t_F, время пересчета таблицы маршрутизации t_S и временя обновления таблиц маршрутизации t_RIB. Это допущение было сделано из расчета на то, что эти три компонента в наибольшей степени зависят от типа используемого протокола маршрутизации. Остальные компоненты в основном, определяются вычислительной мощностью маршрутизатора.

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

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

2.Packet Tracer – средство для моделирования сети

Packet Tracer — симулятор сети передачи данных, выпускаемый фирмой Cisco Systems. Позволяет делать работоспособные модели сети, настраивать (командами Cisco IOS) маршрутизаторы и коммутаторы, взаимодействовать между несколькими пользователями (через облако). В симуляторе реализованы серии маршрутизаторов Cisco 800, 1800, 1900, 2600, 2800, 2900 и коммутаторов Cisco Catalyst 2950, 2960, 3560, а также межсетевой экран ASA 5505.

Cisco Packet Tracer – это эмулятор сети, созданный компанией Cisco. Программа позволяет строить и анализировать сети на разнообразном оборудовании в произвольных топологиях с поддержкой разных протоколов. В ней вы получаете возможность изучать работу различных сетевых устройств: маршрутизаторов, коммутаторов, точек беспроводного доступа, персональных компьютеров, сетевых принтеров и т.д. Данное приложение является наиболее простым и эффективным среди своих конкурентов. Так, например, создание нового проекта сети в Cisco Packet Tracer занимает существенно меньше времени, чем в аналогичной программе - GNS3, Packet Tracer проще в установке и настройке.

3 Проведение эксперементов

Режимы моделирования

Одной из самых важных особенностей данного симулятора является наличие в нем «Режима симуляции» (рисунок 4.1) и работы в реальном времени сети. В данном режиме все пакеты, пересылаемые внутри сети, отображаются в графическом виде. Эта возможность позволяет сетевым специалистам наглядно продемонстрировать, по какому интерфейсу в данные момент перемещается пакет, какой протокол используется и т.д.

Рисунок 3.1 Режим «Симуляции» в Cisco Packet Tracer

Однако, это не все преимущества Packet Tracer: в «Режиме симуляции» сетевые инженеры могут не только отслеживать используемые протоколы, но и видеть, на каком из семи уровней модели OSI данный протокол задействован (рисунок 3.2).

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

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

Рисунок 3.2 Анализ семиуровневой модели OSI в Cisco Packet

Анализ сети в режиме реального времени протокола RIP

Все события связанные с работой данного протокола (рассылка обновлений, добавление/удаление маршрутов) происходят с определенной периодичностью. Эти периодичности называются таймерами протокола RIP. У протокола RIP существуют следующие виды таймеров:

Update - данный таймер отвечает за периодичность рассылки обновлений протокола RIP;

Invalid - данный таймер определяет временной интервал между получением последнего нормального анонса о некоторой сети, и тем что маршрутизатор посчитает сеть временно недоступной и пометит её метрикой 16;

Hold Down - таймер запускаемый после перехода маршрута в состояние Invalid.

Flush - данный таймер определяет временной интервал между получением последнего нормального обновления о сети, до момента исключения данной сети из таблицы маршрутизации (Вот тут есть пара вопросов, например при работе в Packet Tracer, данный интервал считается от момента срабатывания таймера Invalid).

Узнать значения данных таймеров можно при помощи команды:

Router#show ip protocols

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 6 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Таким образом мы получаем что таймеры протокола RIP имеют по умолчанию следующие значения: таймер Update - 30 секунд, таймер Invalid - 180 секунд, таймер Hold Down - 180 секунд, таймер Flush - 240 секунд.

Router(config)#service timestamps debug datetime msec

Router#debug ip rip

*??? 01, 00:24:15.2424: IP: sending v1 update to 255.255.255.255 via FastEthernet1/0 (172.20.20.1)

*??? 01, 00:24:15.2424: IP: build update entries

*??? 01, 00:24:15.2424: network 192.168.1.0 metric 1

*??? 01, 00:24:15.2424: network 192.168.4.0 metric 1

*??? 01, 00:24:16.2424: IP: received v1 update from 192.168.4.2 on FastEthernet0/1

*??? 01, 00:24:16.2424: 192.168.2.0 in 2 hops

*??? 01, 00:24:16.2424: 192.168.5.0 in 1 hops

*??? 01, 00:24:27.2424: IP: received v1 update from 172.20.20.2 on FastEthernet1/0

*??? 01, 00:24:27.2424: 192.168.2.0 in 1 hops

*??? 01, 00:24:27.2424: 192.168.5.0 in 1 hops

*??? 01, 00:24:42.2424: IP: received v1 update from 192.168.4.2 on FastEthernet0/1

*??? 01, 00:24:42.2424: 192.168.2.0 in 2 hops

*??? 01, 00:24:42.2424: 192.168.5.0 in 1 hops

*??? 01, 00:24:44.2424: IP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.1.1)

*??? 01, 00:24:44.2424: IP: build update entries

*??? 01, 00:24:44.2424: network 172.20.0.0 metric 1

*??? 01, 00:24:44.2424: network 192.168.2.0 metric 2

*??? 01, 00:24:44.2424: network 192.168.4.0 metric 1

*??? 01, 00:24:44.2424: network 192.168.5.0 metric 2

*??? 01, 00:24:44.2424: IP: sending v1 update to 255.255.255.255 via FastEthernet0/1 (192.168.4.1)

*??? 01, 00:24:44.2424: IP: build update entries

*??? 01, 00:24:44.2424: network 172.20.0.0 metric 1

*??? 01, 00:24:44.2424: network 192.168.1.0 metric 1

*??? 01, 00:24:44.2424: network 192.168.2.0 metric 2

*??? 01, 00:24:44.2424: IP: sending v1 update to 255.255.255.255 via FastEthernet1/0 (172.20.20.1)

Как видим интервал между рассылкой обновлений приблизительно равен 30 секундам (для таймера рассылки обновлений, допустимы отклонения по времени +-5 секунд).

Теперь проиллюстрируем работу таймера Invalid. Давайте погасим интерфейс Fa0/1 маршрутизатора . И после этого начнем постоянно выполнять команду show ip route на маршрутизаторе. Через 180 секунд после получения последнего обновления о сети 192.114.145.0/24, таблица маршрутизации маршрутизатора 0 будет иметь следующий вид:

R 192.11.198.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.12.198.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.13.198.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.14.198.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

C 192.18.31.0/24 is directly connected, GigabitEthernet0/0

R 192.19.31.0/24 [120/1] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.20.31.0/24 [120/2] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.26.18.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.30.18.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.31.18.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.33.18.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.34.18.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.35.18.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.36.18.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.37.18.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.38.18.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.39.18.0/24 [120/2] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.40.18.0/24 [120/2] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.70.7.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

192.114.145.0/24 is variably subnetted, 2 subnets, 2 masks

R 192.114.145.0/24 is possibly down, routing via 192.18.31.4, GigabitEthernet0/0

R 192.114.145.0/30 [120/5] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.160.3.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.163.13.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.164.13.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 192.168.1.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

C 192.168.88.0/24 is directly connected, GigabitEthernet1/0

R 192.170.10.0/24 [120/5] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 193.169.0.0/24 [120/5] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 198.14.67.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 198.15.66.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 198.16.66.0/24 [120/3] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 198.16.67.0/24 [120/4] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

R 199.156.0.0/24 [120/5] via 192.18.31.4, 00:00:23, GigabitEthernet0/0

Как мы видим по истечении 180 секунд, сеть 192.168.2.0 стала помеченной как возможно недоступная. Задать свои значения таймеров можно при помощи команды:

Router(config)#router rip

Router(config-router)#timers basic 5 60 60 240

Анализ сети в симуляции протокола RIP

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

Рисунок 3.3 Рассылка сообщений в момент включения питания в сети

Рисунок 3.4 Рассылка сообщений Update к соседям

Анализ сети в режиме реального времени протокола OSPF

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

Convergence = Failure_Detection_Time + Event_Propagation_Time + SPF_Run_Time + RIB_FIB_Update_Time

1) Failure_Detection_Time — Время, необходимое для обнаружения проблем на физическом уровне. Например обрыв канала

2) Event_Propagation_Time — Время, необходимое для распространения LSA пакетов нашим соседям в сети

3) SPF_Run_Time — Время, необходимое для запуска расчета алгоритма SPF, после получения новых данных

4) RIB_FIB_Update_Time — Время, необходимое для обновления таблиц маршрутизации (RIB/FIB)

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

Router#show ip ospf

Routing Process "ospf 1" with ID 7.7.7.7

Supports only single TOS(TOS0) routes

Supports opaque LSA

It is an area border router

SPF schedule delay 5 secs, Hold time between two SPFs 10 secs

Failure_Detection_Time

Безусловно данный параметр является одним из самых важных. Раньше обнаружили, что сосед недоступен — раньше начали искать альтернативный маршрут. Определяется доступность соседей отправкой пакетов Hello. По умолчанию, в broadcast сетях, пакет отправляется каждые 10 секунд, каждым маршутизатором, каждым соседом. Если сосед не ответил на 4 подряд Hello пакета (40 секунд), сосед помечается как недоступный – начинается поиск альтернативного пути.

Hello-интервал, можно изменить следующей командой на интерфейсе маршрутизатора

Router(config-if)#ip ospf hello-interval <1-65535>

Dead-интервал, можно изменить следующей командой на интерфейсе маршрутизатора

Router(config-if)#ip ospf dead-interval <1-65535>

Также и эти временные интервалы мы можем уменьшить, для этого используются Fast Hello-пакеты

OSPF FAST hello-пакеты — это hello-пакеты, которые отправляются с интервалом меньше 1 секунды. Для этого необходимо установить dead-интервал равным 1 секунде (множитель равен 4 по умолчанию, тоесть в секунду будут отправлено 4 hello пакета).

Более частая отправка hello-пакетов позволяет увеличить скорость обнаружения соседей –> скорость сходимости сети.

Когда на интерфейсе настроена отправка hello-пакетов, с интервалом менее 1 секунды, то внутри hello-пакета, hello-интервал будет равен 0. Hello-интервал полученный в hello-пакетах, которые приходят на этот интерфейс, игнорируется, Dead-интервал должен быть одинаковым, для корректной работы протокола OSPF

Настройка dead-интервала равным 1 и изменение множителя множитель 5 обозначает, что будет отправлено 5 hello-пакетов в секунду:

router(config-if)# ip ospf dead-interval minimal hello-multiplier 5

Event_Propagation_Time

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

LSA generation delay

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

Три таймера управляют процессом регулировки рассылки LSA сообщений:

1) initial interval –время задержки перед отправкой LSA

2) hold – время, по истечению которого LSA будет отправлено другим маршрутизаторам, если изменений не произошло

3) max_wait – время, по истечению которого таймеру hold будет возвращено первоначально заданное значение.

Данные параметры задаются в настройках протокола OSPF

router(config-router)#timers throttle lsa initial hold max_wait

router(config-router)#timers pacing flood <5-100>

SPF_Run_Time

Таймер регулирует процесс запуска процесса расчета алгоритма SPF

Данный таймер задается в настройках протокола OSPF

router(config-router) #timers throttle spf initial hold max_wait

RIB_FIB_Update_Time

После того как завершен расчет SPF, необходимо произвести обновление в таблице маршрутизации. Соответственно, чем быстрей будут обновлены таблицы RIB и FIB тем быстрей мы сможем начать передачу трафика.

Уменьшить количество распространяемых префиксов командой:

router(config-router) #prefix-suppression

Router#show ip route ospf

O IA 192.52.3.0 [110/5] via 195.1.10.3, 03:31:32, GigabitEthernet4/0

O IA 192.89.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O IA 192.89.11.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O IA 192.89.12.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O IA 192.89.13.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O IA 193.15.1.0 [110/6] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O IA 193.57.10.0 [110/4] via 195.1.10.3, 03:31:32, GigabitEthernet4/0

O IA 193.165.1.0 [110/5] via 195.1.10.3, 03:31:22, GigabitEthernet4/0

O IA 193.166.1.0 [110/5] via 195.1.10.3, 03:31:22, GigabitEthernet4/0

O 195.2.10.0 [110/2] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.3.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O IA 195.4.10.0 [110/5] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.5.10.0 [110/4] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.6.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.7.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.8.10.0 [110/3] via 195.1.10.3, 03:31:32, GigabitEthernet4/0

O IA 195.9.10.0 [110/4] via 195.1.10.3, 03:31:32, GigabitEthernet4/0

O 195.10.10.0 [110/4] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.11.10.0 [110/4] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.12.10.0 [110/4] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.13.10.0 [110/3] via 195.1.10.3, 03:31:32, GigabitEthernet4/0

O 195.14.10.0 [110/2] via 195.1.10.3, 03:31:32, GigabitEthernet4/0

O 195.15.10.0 [110/2] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.16.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.17.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.18.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.19.10.0 [110/4] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.20.10.0 [110/4] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.21.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

O 195.22.10.0 [110/3] via 195.1.10.3, 03:31:42, GigabitEthernet4/0

Далее …

O IA 193.166.1.0/24 [110/5] via 195.4.10.3, 03:38:30, GigabitEthernet0/0

O IA 195.1.10.0/24 [110/5] via 195.4.10.3, 00:00:07, GigabitEthernet0/0

O IA 195.2.10.0/24 [110/5] via 195.4.10.3, 03:38:50, GigabitEthernet0/0

O IA 195.3.10.0/24 [110/5] via 195.4.10.3, 03:38:50, GigabitEthernet0/0

C 195.4.10.0/24 is directly connected, GigabitEthernet0/0

O IA 195.5.10.0/24 [110/2] via 195.4.10.3, 03:39:00, GigabitEthernet0/0

Анализ сети в симуляции протокола OSPF

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

Рисунок 3.5 Рассылка сообщений при возникновении неисправности на корневом уровне

Рисунок 3.6 Рассылка сообщений при возникновении неисправности на уровне агрегации.

Рисунок 3.7 Рассылка сообщений при возникновении неисправности на уровне доступа.

Заключение

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

Можно сделать вывод о целесообразности применения протокола OSPF в крупных сетях нуждающееся в быстром, оперативном обновлении топологии сети. В небольших сетях с отсутствуем повышенных требований ко времени обновления таблиц маршрутизации можно использовать более дешевый и простой в настройке протокол RIP.

Так же при моделировании были выявлены нюансы в исследовании протокола RIP, такие как огромное количество служебных сообщений посылаемых при обновлении таблиц

Литература

1. Таненбаум Э., Уэзеролл Д. Компьютерные сети. — 5-е изд — СПб.: ”Питер”, 2016 – 960 с.

2. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. – 5-е изд — СПб.:”Питер”, 2016 – 992 с.

3. Албахари Д., Албахари Б. C# 6.0. Справочник. Полное описание языка. – 6-е изд — М.:”Вильямс”, 2016 – 1040 с.

4.Moy J. / Multicast Extensions to OSPF / J. Moy. – Network

Working Group, 1994.

5. Malkin G. / RIP Version 2 MIB Extension / G. Malkin, F.

Baker. – Network Working Group, 1994.

6. Время обновления таблиц маршрутизации [Электронный ресурс] URL http://www.ciscolab.ru/security/27-how_nat_work.html (дата обращения 17.05.2018)

7. Требования, предъявляемые к современным вычислительным сетям маршрутизации [Электронный ресурс] URL http://bourabai.ru/einf/Glava101-2.htm (дата обращения 04.06.2018)

8. Сети передачи данных [Электронный ресурс] URL http://www.it-building.ru/?/rus/solution/datanetwork (дата обращения 04.06.2017)

9. Дибров М.В. Маршрутизаторы . Краснояркс.: ”СФУ”, 2008 – 389 с.

10. Макаренко С.И. Время сходимости протоколов маршрутизации при отказах в сети // Научный рецензируемый сетевой электронный журнал ”Системы управления, связи и безопасности” № 2 2015. – С. 45–98

11. Сорокин А. А., Дмитриев В. Н., Чан Куок Тоан, Резников П. С. Оценка результатов использования протокола RIP в системах связи с динамической топологией сети методом имитационного моделирования // Вестник АГТУ.. № 4 2014. -С. 85-93.

12. Graph# is a graph layout framework. [Электронный ресурс] URL https://graphsharp.codeplex.com/ (дата обращения 12.06.2018)

13. P. Francois, C. Filsfils, O. Bonaventure, and J. Evans. Achieving Sub-Second IGP Convergence in Large IP Networks. ACM SIGCOMM Computer Communication Review, July 2005