Динамическая маршрутизация. Протокол RIP. Протокол OSPF. Протоколы маршрутизации

Компьютер в сети TCP/IP может иметь адреса трех уровней (но не менее двух):

Локальный адрес компьютера. Для узлов, входящих в локальные сети – это МАС-адрес сетевого адаптера. Эти адреса назначаются производителями оборудования и являются уникальными адресами.
IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов.
Символьный идентификатор-имя (DNS), например, www.сайт

Сетевые протоколы

Сетевой протокол - набор правил, позволяющий осуществлять обмен данными между составляющими сеть устройствами, например, между двумя сетевыми картами (рис. 1).

Рис. 1. Иллюстрация к понятию Сетевой протокол

Стэк- это набор разноуровневых протоколов, объединенных в группу.

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

Маршрутизируемый сетевой протокол IPv4. В протоколе этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 32 бита (т.е. 4 октета или 4 байта).
IPv6 позволяет адресовать значительно большее количество узлов, чем IPv4. Протокол Интернета версии 6 использует 128-разрядные адреса, и может определить значительно больше адресов.

IP-адреса версии v6 записываются в следующем виде:X:X:X:X:X:X:X:X, где X является шестнадцатеричным числом, состоящим из 4-х знаков(16 бит), а каждое число имеет размер 4 бит. Каждое число располагается в диапазоне от 0 до F. Вот пример IP-адреса шестой версии: 1080:0:0:0:7:800:300C:427A. В подобной записи незначащие нули можно опускать, поэтому фрагмент адреса: 0800: записывается, как 800:.

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

10100000010100010000010110000011
записывается как

10100000.01010001.00000101.10000011 = 160.81.5.131

Рис. 2 Перевод адреса из двоичной системы в десятичную

IP-адрес хоста состоит из номера IP-сети, который занимает старшую область адреса, и номера хоста в этой сети, который занимает младшую часть.
160.81.5.131 – IP-адрес
160.81.5. – номер сети
131 – номер хоста

Базовые протоколы (IP, TCP, UDP)

TCP/IP – собирательное название для набора (стека) сетевых протоколов разных уровней, используемых в Интернет. Особенности TCP/IP:

Открытые стандарты протоколов, разрабатываемые независимо от программного и аппаратного обеспечения;
Независимость от физической среды передачи;
Система уникальной адресации;
Стандартизованные протоколы высокого уровня для распространенных пользовательских сервисов.

Рис. 3 Стек протоколов TCP/IP

Стек протоколов TCP/IP делится на 4 уровня:

Прикладной
Транспортный
Межсетевой
Физический и канальный.

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

Рис. 4 Пример инкапсуляции пакетов в стеке TCP/IP

Физический и канальный уровень.
Стек TCP/IP не подразумевает использования каких-либо определенных протоколов уровня доступа к среде передачи и физических сред передачи данных. От уровня доступа к среде передачи требуется наличие интерфейса с модулем IP, обеспечивающего передачу IP-пакетов. Также требуется обеспечить преобразование IP-адреса узла сети, на который передается IP-пакет, в MAC-адрес. Часто в качестве уровня доступа к среде передачи могут выступать целые протокольные стеки, тогда говорят об IP поверх ATM, IP поверх IPX, IP поверх X.25 и т.п.

Межсетевой уровень и протокол IP.

Основу этого уровня составляет IP-протокол.

IP (Internet Protocol) – интернет протокол.

Первый стандарт IPv4 определен в RFC-760 (DoD standard Internet Protocol J. Postel Jan-01-1980)

Последняя версия IPv4 – RFC-791 (Internet Protocol J. Postel Sep-01-1981).

Первый стандарт IPv6 определен в RFC-1883 (Internet Protocol, Version 6 (IPv6) Specification S. Deering, R. Hinden December 1995)

Последняя версия IPv6 – RFC-2460 (Internet Protocol, Version 6 (IPv6) Specification S. Deering, R. Hinden December 1998).

Основные задачи:

Адресация
Маршрутизация
Фрагментация датаграмм
Передача данных

Протокол IP доставляет блоки данных от одного IP-адреса к другому.

Программа, реализующая функции того или иного протокола, часто называется модулем, например, “IP-модуль”, “модуль TCP”.

Когда модуль IP получает IP-пакет с нижнего уровня, он проверяет IP-адрес назначения.

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

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

Если модуль IP по какой-либо причине не может доставить IP-пакет, он уничтожается. При этом модуль IP может отправить компьютеру-источнику этого IP-пакета уведомление об ошибке; такие уведомления отправляются с помощью протокола ICMP, являющегося неотъемлемой частью модуля IP. Более никаких средств контроля корректности данных, подтверждения их доставки, обеспечения правильного порядка следования IP-пакетов, предварительного установления соединения между компьютерами протокол IP не имеет. Эта задача возложена на транспортный уровень.

Рис. 5 Структура дейтограммы IP. Слова по 32 бита.

Версия – версия протокола IP (например, 4 или 6)

Длина заг. – длина заголовка IP-пакета.

Тип сервиса (TOS – type of service) – Тип сервиса ().

TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует за-прашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP).

Идентификатор дейтаграммы, флаги (3 бита) и указатель фрагмента – используются для распознавания пакетов, образовавшихся путем фрагментации исходного пакета.

Время жизни (TTL – time to live) – каждый маршрутизатор уменьшает его на 1, что бы пакеты не блуждали вечно.

Протокол – Идентификатор протокола верхнего уровня указывает, какому протоколу верхнего уровня принадлежит пакет (например: TCP, UDP).

Маршрутизация

Протокол IP является маршрутизируемый, для его маршрутизации нужна маршрутная информация.

Маршрутная информация, может быть:

Статической (маршрутные таблицы прописываются вручную)
Динамической (маршрутную информацию распространяют специальные протоколы)

Протоколы динамической маршрутизации:

RIP (Routing Information Protocol) – протокол передачи маршрутной информации, маршрутизаторы динамически создают маршрутные таблицы.
OSPF (Open Shortest Path First) – протокол “Открой кротчайший путь первым”, является внутренним протоколом маршрутизации.
IGP (Interior Gateway Protocols) – внутренние протоколы маршрутизации, распространяет маршрутную информацию внутри одной автономной системе.
EGP (Exterior Gateway Protocols) – внешние протоколы маршрутизации, распространяет маршрутную информацию между автономными системами.
BGP (Border Gateway Protocol) – протокол граничных маршрутизаторов.
Протокол ICMP
ICMP (Internet Control Message Protocol) – расширение протокола IP, позволяет передавать сообщения об ошибке или проверочные сообщения.
Другие служебные IP-протоколы
IGMP (Internet Group Management Protocol) – позволяет организовать многоадресную рассылку средствами IP.
RSVP (Resource Reservation Protocol) – протокол резервирования ресурсов.
ARP (Address Resolution Protocol) – протокол преобразования IP-адреса и адреса канального уровня.

Транспортный уровень

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

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

На транспортном уровне работают два основных протокола: UDP и TCP.

Протокол надежной доставки сообщений TCP

TCP (Transfer Control Protocol) – протокол контроля передачи, протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений.

Первая и последняя версия TCP – RFC-793 (Transmission Control Protocol J. Postel Sep-01-1981).

Основные особенности:

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

Контрольная сумма – включает псевдо заголовок, заголовок и данные.

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

URG – флаг срочности, включает поле “Указатель срочности”, если =0 то поле игнорируется.

ACK – флаг подтверждение, включает поле “Номер подтверждения, если =0 то поле игнорируется.

PSH – флаг требует выполнения операции push, модуль TCP должен срочно передать пакет программе.

RST – флаг прерывания соединения, используется для отказа в соединении

SYN – флаг синхронизация порядковых номеров, используется при установлении соединения.

FIN – флаг окончание передачи со стороны отправителя

Протокол UDP

UDP (Universal Datagram Protocol) – универсальный протокол передачи данных, более облегченный транспортный протокол, чем TCP.

Первая и последняя версия UDP – RFC-768 (User Datagram Protocol J. Postel Aug-28-1980).

Основные отличия от TCP:

Отсутствует соединение между модулями UDP.
Не разбивает сообщение для передачи
При потере пакета запрос для повторной передачи не посылается

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

Рис.7 Структура дейтограммы UDP. Слова по 32 бита.

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

Протокол реального времени RTP

RTP (Real Time Protocol) – транспортный протокол для приложений реального времени.

RTCP (Real Time Control Protocol) – транспортный протокол обратной связи для приложения RTP.

Протоколы маршрутизации

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

Рисунок 4.8

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

Для определения маршрута внутри AS применяют внутренние протоколы маршрутизации IGP (Interior GatewayProtocols). Наиболее распространенными протоколами внутренней маршрутизации являются протоколы RIP (Routing Information Protocol), OSPF (Open Shortest Path First), IGRP (Interior Gateway Routing Protocol), разработанный компанией CISCO, как альтернативный RIP, а затем и его улучшенный вариант EIGRP (Enhanced Interior Gateway Routing Protocol).

Автономные системы объединяются между собой при помощи внешних или пограничных (Border) маршрутизаторов, используя протоколы внешней маршрутизации BGP (Border Gateway Protocol). Два соседних маршрутизатора, которые обмениваются информацией внутри AS, называются внутренним и внешним, если они обмениваются информацией, принадлежащей разным системам (рис. 4.8). Связь между разными автономными системами осуществляется с помощью высокоскоростной магистральной или опорной сети (Backbone).

В соответствии с терминологией международного института стандартов ISO используется понятие конечных ES и промежуточных систем IS. Промежуточная система IS (Intermedia Systems) – передающий узел между 2 подсетями. Устройство сети, которые не обладают способностью пересылать пакеты, называется оконечным. В это же время сетевое устройство, обладающее такой возможностью – промежуточной системой IS. Промежуточные системы, которые могут сообщаться внутри домена маршрутизации (эквивалент AS), называются внутридоменные AS и системы, которые общаются с другими доменами, называются междоменными.

Процесс взаимодействия и уровни взаимодействий в соответствии с OSI показан на рис. 4.9.

Рисунок 4.9

Протокол внутренней маршрутизации RIP (Routing Information Protocol) предназначался для небольших сетей. Для нахождения оптимального пути используется алгоритм вектора расстояния DVA (Distance Vector Algorithm) – алгоритм Беллмана-Форда. Маршрут в данном алгоритме характеризуется вектором расстояния до пункта назначения (пункт назначения – направление вектора, метрика – модуль вектора). Маршрутизаторы, которые используют протокол RIP в режиме широковещания, передают список сетей, с которыми они могут связаться, и метрику, содержащую информацию о том, за сколько пересылок, шагов (hops) каждая из этих сетей может быть достигнута.

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

Таблица маршрутизации содержит по одной записи на каждый маршрут.

Такая запись имеет следующие поля: поле IP адреса пункта назначения, IP-адрес ближайшего (соседнего) маршрутизатора, метрику маршрута – до 15 шагов, таймеры (счетчики времени). Каждый маршрутизатор передает такую широковещательную информацию каждые 30 сек, генерируя достаточно большой трафик. RIP работает на сетевом уровне стека TCP/IP, используя протокол UDP (порт 520).

Каждый маршрут содержит счетчики тайм-аута и «сборщики» маршрутов. Счетчик тайм-аута сбрасывается в нуль при коррекции или инициализации маршрута. Если к моменту последней коррекции прошло 3 мин, маршрут закрывается, однако запись о нем в таблице сохраняется до наступления времени «сборка маршрута».

Формат сообщения протокола RIP имеет вид (рис. 4.10). Поле «Команда» определяет вид сообщения:

Код 1 – запрос на получение информации, код 2 – отклик, содержащий информацию о расстояниях из маршрутной таблицы отправителя, код 3 - включение режима трассировки, код 4 – выключение режима трассировки. Поле «Версия» для протокола RIP-1 равно 1. Номер протоколов, которые используются в соответствующей сети (для Интернет поле имеет значение, равное 2). Поле стоимость – число шагов. В одном сообщении может иметься информация до 25 маршрутов.

Рисунок 4.10

1. Таймер обновления – 70 сек (посылается всем соседям);

2. Таймер устаревшего маршрута – 90 сек;

3. Таймер удаления маршрута - 240 сек.

В протоколе RIP реализовано правило расщепления горизонта при модификации (Split Horizon Updates), которое препятствует появлению маршрутных петель в две пересылки, однако петли, включающие три и больше пересылок могут возникать.

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

Протокол маршрутизации внутренних шлюзов IGRP(Interior Gateway Routing Protocol) работает на основе использования алгоритма вектора расстояния DVA. Протоколы маршрутизации с вектором расстоянии требуют от каждого маршрутизатора отправления через определенные интервалы времени соседним маршрутизаторам всей или части своей таблицы маршрутизации, используя сообщения о корректировки маршрута. После того, как маршрутная информация распределиться по сети, маршрутизатор может вычислить расстояние до всех узлов объединенной сети.

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

1. Расстояние – число в диапазоне от 1 до 255.

2. Задержка. Измеряется кратно 10 мс. Для сетей E задается показателем 100.

3. Полоса от 1200 бит/с до 10 Гбит/с.

4. Надежность. Оптимальное значение составляет 255.

5. Загруженность канала в долях числа 255.

Для регулирования производительности применяются следующие таймеры:

1. Таймер обновления (по умолчанию 90с) – задает период передачи сообщения.

2. Таймер устаревшего маршрута. Столько времени ожидает маршрутизатор обновления, прежде чем объявить маршрут устаревшим (задается три периода обновления).

3. Таймер блокировки (по умолчанию 10 с).

4. Таймер удаления маршрута (семь периодов обновления).

Протокол предусматривает три типа маршрутов:

системные – ведущие в сети в рамках AS,

внешние – маршруты в сети вне AS.

Внешние, связанные с наличием граничного пути

Структура таблицы маршрутизации имеет вид, показанный на рис. 4.11

Рисунок 4.11

Первое поле в заголовке таблицы маршрутизации – номер версии,

затем следует поле операционного кода (OP Code). Это поле обозначает вид пакета. Код, равный 1, определяет пакет корректировки, код 2 – пакет запроса. Пакеты запроса использует маршрутизатор для получения информации о маршрутных таблицах других маршрутизаторов. Эти пакеты состоят только из заголовка, операционного кода и номера AS. Пакеты корректировки содержат заголовок, за которым следует записи данных маршрутных таблиц. Этот пакет не должен превышать 1500 байт. Далее следует поле редактирование, которое содержит последовательный номер, указывающий, когда маршрутная таблица изменялась. Далее следует номер автономной системы AS. Следующие поля определяют номер внешних сетей, главных сетей и подсетей. Последнее поле в заголовке – поле контрольной суммы. Сообщения о корректировке содержит семь полей данных для каждой записи данных маршрутной таблицы. Первое поле – 3 байта адреса IP, следующее – задержка, выраженная в десятках микросекунд, далее – поле ширины полосы в единицах 1 Кбит/с, затем идет поле размера блока данных MTU, поле надежности в процентах. Следующим является поле – загрузка, указывающее в процентах занятость канала. Последнее поле – число пересылок (счетчик шагов).

Протокол внешнего шлюза EGP (Exterion Gateway Protocol) – используется алгоритм вектора расстояния DVA для соединения AS через центральную сеть (ядро). Маршрутизатор выполняет следующие функции: выделяет соседей, с которыми обменивается информацией о достижении тех или иных сетей, посылает сообщения о их работоспособности, передает сообщения об обновлении, указывает информацию о доступности сетей для данной AS.

Типы сообщений:

1. Проверочные, если нужно установить работают ли соседние маршрутизаторы.

2. Сообщения о достижимости соседа (не выключен ли соседний маршрутизатор).

3. Сообщения о неисправности.

Протокол граничного шлюза BGP (Border Gateway Protocol) предназначен для обеспечения взаимодействий разных AS. Этот протокол можно использовать для организации связей не только между AS, но и внутри их. В BGP – нет ядра. Когда маршрутизатор подключается к сети, он получает от соседей полную таблицу маршрутизации, хранит информацию обо всех маршрутах, ведущих до пункта назначения.

Открытый протокол с алгоритмом поиска кратчайшего пути OSPF {Open Shortest Path First) – это протокол внутренних маршрутизаторов. Он гораздо сложнее RIP-протокола, однако OSPF может функционировать в сетях любой сложности и не имеет ограничений, характерных для RIP. Время, используемое на построение таблиц маршрутизации и загрузки сети служебной информацией, в среднем меньше по сравнению с тем, что потребовал бы протокол RIP для такой же системы. Кроме этого, переходные процессы в OSPF завершаются быстрее, чем в RIP. OSPF представляет собой протокол учета состояния канала LSA (Link State Algorithm), в котором маршрутизация выполняется по алгоритму Дийкстры. В качестве метрики используется коэффициент качества обслуживания QoS (Quality of Service). Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов всех маршрутизаторов (узлов коммутации) автономной системы. Протокол OSPF реализован программным модулем - демоном маршрутизации gated, который поддерживает также RIP и внешний протокол маршрутизации BGP. Качество обслуживания (QoS) характеризуется следующими параметрами: пропускной способностью канала, задержкой (временем распространения пакета), загрузкой канала, требованиями безопасности, типом трафика, числом шагов до места назначения, надежностью передачи пакетов.

Доминирующими являются три характеристики: задержка, пропускная способность и надежность. На практике чаще всего метрика связи в OSPF определяется как количество секунд, требуемых для передачи 100 Мбит по каналу, через который проложен маршрут. Например, метрика сети на основе 10BASE-T Ethernet равна 10, метрика канала модемной связи со скоростью 56 кбит/с составляет 1785, а канала со скоростью 100 Мбит и выше равна 1.

Для транспортных целей OSPF применяет протокол IP непосредственно, т.е. не привлекая протоколы UDP или TCP. OSPF имеет свой код в протокольном поле IP-заголовка. Код типа обслуживания ToS {type of service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение типа обслуживания ToS здесь задается в самих пакетах OSPF.

Маршрутизация в протоколе OSPF определяется IP-адресом и типом сервиса. В связи с тем, что протокол не требует инкапсуляции пакетов, существенно облегчается управление сетями с большим количеством мостов и сложной топологией (исключается циркуляция пакетов, сокращается транзитный трафик). Автономная система может быть разделена на отдельные области, каждая из которых становится объектом маршрутизации, а внутренняя структура снаружи не видна. Этот прием позволяет значительно сократить необходимый объем маршрутной базы данных. В OSPF используется термин магистральная сеть {backbone), обозначающий среду для коммуникаций между выделенными областями. Протокол OSPF работает лишь в пределах автономной системы.

В стеке протоколов TCP/IP протокол OSPF находится непосредственно над протоколом IP, его код равен 89. Поэтому если значение поля "Протокол" IP-дейтаграммы равно 89, то данные дейтаграммы являются сообщением OSPF и передаются OSPF-модулю для обработки. Соответственно размер OSPF сообщения ограничен максимальным размером дейтаграммы.

При передаче OSPF-пакетов фрагментация не желательна, но не запрещается. Для передачи статусной информации OSPF использует широковещательные сообщения Hello. Повышение безопасности обеспечивается авторизацией процедур. Протокол OSPF требует резервирования двух групповых адресов: адрес 224.0.0.5 - предназначен для обращения ко всем маршрутизаторам, поддерживающим этот протокол; адрес 224.0.0.6 - служит для обращения к специально выделенному маршрутизатору. Любое сообщение OSPF начинается с 24-октетного заголовка (рисунок 4.12).

Рисунок 4.12

Поле "Версия" определяет версию протокола. Поле "Тип" идентифицирует функцию сообщения, в частности: код 1- Hello (используется для проверки доступности маршрутизатора); код 2 - Описание базы данных (топология); код 3 - Запрос состояния канала; код 4 - Изменение состояния канала; код 5- Подтверждение получения сообщения о статусе канала.

Поле "Длина сообщения" указывает длину блока в октетах, включая заголовок. "Идентификатор области" - 32-битный код, задающий область, которой данный пакет принадлежит. Все OSPF-пакеты ассоциируются с той или иной областью. Большинство из них не преодолевает более одного шага. Пакеты, перемещающиеся по виртуальным каналам, помечаются идентификатором опорной (магистральной) области {backbone).

Поле "Контрольная сумма" содержит проверочную сумму IP-пакета, включая поле типа идентификации. Поле "Тип идентификации" может принимать значения 0 при отсутствии контроля доступа, и 1 при его наличии. В дальнейшем функции поля предполагается расширить.

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

Структура пакетов этого типа показана на рисунке 4.13.

Рисунок 4.13

Особую роль в поле "Опции" играют младшие биты Е и Т: Бит Е характеризует возможность внешней маршрутизации и имеет значение только в сообщениях типа Hello, в остальных сообщениях этот бит должен быть обнулен. Если Е=0, то данный маршрутизатор не будет посылать или принимать маршрутную информацию от внешних автономных систем. Бит Т определяет сервисные возможности маршрутизатора. Если Т=0, это означает, что маршрутизатор поддерживает только один вид услуг (тип сервиса ToS=0) и он не пригоден для маршрутизации с учетом вида услуг. Такие маршрутизаторы, как правило, не используются для транзитного трафика.

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

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

Рисунок 4.14

Если размер базы данных велик, ее содержимое может пересылаться по частям. Для реализации этого используются биты I и М. Бит I устанавливается в 1 в стартовом сообщении, а бит М принимает единичное состояние для сообщений, которые являются продолжением. Бит S определяет, кем послано сообщение (S=l для сервера, S=0 для клиента, этот бит иногда имеет имя MS).

Поле "Порядковый номер сообщения" служит для контроля пропущенных в процессе обмена информацией блоков. Первое сообщение содержит в этом поле случайное целое число М, последующие: М+1, M+2,...M+L. Поле "Тип канала" содержит коды, определяющие состояние каналов, а именно, его интерфейсов, описание внешних связей автономных систем.

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

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

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

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

Маршрутная таблица OSPF включает следующие поля:

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

К преимуществам протокола маршрутизации OSPF следует отнести:

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

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

Маршрутизация является одной из важнейших операций в объединенных сетях IP. Маршрутизацией называется процесс построения, сравнения и выбора маршрута в сети к произвольному IP-адресу. Устройства, выполняющие эти функции, называют маршрутизаторами. Основные функции маршрутизаторов следующие:

· обмен информации о локально подключенных хостах и сетях;

· сравнение альтернативных путей;

· согласование топологии сети.

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

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

Статическая маршрутизация основана на статических, заранее запрограммированных маршрутах. Преимущества статической маршрутизации заключаются:

· в повышении надежности сети;

· эффективном расходовании ресурсов;

· возможности применения для диагностики и временного разрешения проблем в сети;

· обеспечении безопасности сети.

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

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

Недостатки дистанционно-векторной маршрутизации следующие:

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

· маршрутизатор ничего не знает о фактической топологии сети и других маршрутизаторах;

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

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

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

менений в сети. Топологическая маршрутизация обладает двумя существенными недостатками:

1) на стадии сбора первоначальной информации по сети передается большой объем информации, существенно снижая возможности сети по передаче данных;

2) топологическая маршрутизация требует больших затрат памяти и процессорных ресурсов.

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

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

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

· шлюз (gateway) – компьютер, выполняющий преобразование протоколов. Шлюзы работают на уровнях модели OSI с 4 по 7 (например, шлюз электронной почты). Шлюзы очень часто выполняют преобразование нескольких протоколов в зависимости от сетевых подключений, например, также они могут выполнять шифрование/дешиф-рование данных;

· мост (bridge) – компьютер, соединяющий две сети и более, использующий один протокол. Мост работает на уровне 2 модели OSI и использует адреса канального уровня (а не адреса IP);

· маршрутизатор (router) – компьютер, пересылающий дейтаграммы в сети. Маршрутизаторы работают на уровне 3 модели OSI и дополнительно могут выполнять другие функции, например, преобразование сетевых адресов (NAT) или обеспечение безопасности.

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

Итак, приступим.

Статей и видео о том, как настроить OSPF горы. Гораздо меньше описаний принципов работы. Вообще, тут такое дело, что OSPF можно просто настроить согласно мануалам, даже не зная про алгоритмы SPF и непонятные LSA. И всё будет работать и даже, скорее всего, прекрасно работать - на то он и рассчитан. То есть тут не как с вланами, где приходилось знать теорию вплоть до формата заголовка.
Но инженера от эникейщика отличает то, что он понимает, почему его сеть функционирует так, а не иначе, и не хуже самогo OSPF знает, какой маршрут будет выбран протоколом.
В рамках статьи, которая уже на этот момент составляет 8 000 символов, мы не сможем погрузиться в глубины теории, но рассмотрим принципиальные моменты.
Очень просто и понятно, кстати, написано про OSPF на xgu.ru или в английской википедии .
Итак, OSPFv2 работает поверх IP, а конкретно, он заточен только под IPv4 (OSPFv3 не зависит от протоколов 3-го уровня и потому может работать с IPv6).

Рассмотрим его работу на примере вот такой упрощённой сети:

Для начала надо сказать, что для того, чтобы между маршрутизаторами завязалась дружба (отношения смежности) должны выполниться следующие условия:

1) в OSPF должны быть настроены одинаковые Hello Interval на тех маршрутизаторах, что подключены друг к другу. По умолчанию это 10 секунд в Broadcast сетях, типа Ethernet. Это своего рода KeepAlive сообщения. То есть каждые 10 секунд каждый маршрутизатор отправляет Hello пакет своему соседу, чтобы сказать: “Хей, я жив”,
2) Одинаковыми должны быть и Dead Interval на них. Обычно это 4 интервала Hello - 40 секунд. Если в течение этого времени от соседа не получено Hello, то он считается недоступным и начинается ПАНИКА процесс перестроения локальной базы данных и рассылка обновлений всем соседям,
3) Интерфейсы, подключенные друг к другу, должны быть в одной подсети ,
4) OSPF позволяет снизить нагрузку на CPU маршрутизаторов, разделив Автономную Систему на зоны. Так вот номера зон тоже должны совпадать,
5) У каждого маршрутизатора, участвующего в процессе OSPF есть свой уникальный индентификатор - Router ID . Если вы о нём не позаботитесь, то маршрутизатор выберет его автоматически на основе информации о подключенных интерфейсах (выбирается высший адрес из интерфейсов, активных на момент запуска процесса OSPF). Но опять же у хорошего инженера всё под контролем, поэтому обычно создаётся Loopback интерфейс, которому присваивается адрес с маской /32 и именно он назначается Router ID. Это бывает удобно при обслуживании и траблшутинге.
6) Должен совпадать размер MTU

1) Штиль. Состояние OSPF - DOWN
В это короткое мгновение в сети ничего не происходит - все молчат.

2) Поднимается ветер: маршрутизатор рассылает Hello-пакеты на мультикастный адрес 224.0.0.5 со всех интерфейсов, где запущен OSPF. TTL таких сообщений равен одному, поэтому их получат только маршрутизаторы, находящиеся в том же сегменте сети. R1 переходит в состояние INIT .

В пакеты вкладывается следующая информация:

Router ID
Hello Interval
Dead Interval
Neighbors
Subnet mask
Area ID
Router Priority
Адреса DR и BDR маршрутизаторов
Пароль аутентификации

Нас интересуют пока первые четыре или точнее вообще только Router ID и Neighbors.
Сообщение Hello от маршрутизатора R1 несёт в себе его Router ID и не содержит Neighbors, потому что у него их пока нет.
После получения этого мультикастного сообщения маршрутизатор R2 добавляет R1 в свою таблицу соседей (если совпали все необходимые параметры).

И отправляет на R1 уже юникастом новое сообщение Hello, где содержится Router ID этого маршрутизатора, а в списке Neigbors перечислены все его соседи. В числе прочих соседей в этом списке есть Router ID R1, то есть R2 уже считает его соседом.

3) Дружба. Когда R1 получает это сообщение Hello от R2, он пролистывает список соседей и находит в нём свой собственный Router ID, он добавляет R2 в свой список соседей.

Теперь R1 и R2 друг у друга во взаимных соседях - это означает, что между ними установлены отношения смежности и маршрутизатор R1 переходит в состояние TWO WAY .

Общий совет по всем задачам:

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

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

Прежде чем мы перейдём к тестированию резервных линков и скорости, сделаем ещё одну полезную вещь.
Если бы у нас была возможность отловить трафик на интерфейсе FE0/0.2 msk-arbat-gw1, который смотрит в сторону серверов, то мы бы увидели, что каждые 10 секунд в неизвестность улетают сообщения Hello. Ответить на Hello некому, отношения смежности устанавливать не с кем, поэтому и пытаться рассылать отсюда сообщения смысла нет.
Выключается это очень просто:

msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2

Такую команду нужно дать для всех интерфейсов, на которых точно нет соседей OSPF (в том числе в сторону интернета).
В итоге картина у вас будет такая:

*Не представляю, как вы до сих пор не запутались*

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

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

msk-arbat-gw1#sh ip OSPF neighbor

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Питер, Кемерово, Красноярск и Владивосток - непосредственно подключенные.

msk-arbat-gw1#sh ip route
172.16.0.0/16 is variably subnetted, 25 subnets, 6 masks

S 172.16.2.4/30 via 172.16.2.2

O 172.16.2.160/30 via 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:04:18, FastEthernet1/0.911

S 172.16.16.0/21 via 172.16.2.2
S 172.16.24.0/22 via 172.16.2.18
O 172.16.24.0/24 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 via 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:04:18, FastEthernet0/1.8
via 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:04:28, FastEthernet1/0.911

Все обо всех всё знают.
Каким маршрутом трафик доставляется из Москвы в Красноярск? Из таблицы видно, что krs-stolbi-gw1 подключен напрямую и это же видно из трассировки:

1 172.16.2.130 35 msec 8 msec 5 msec

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

msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Known via «OSPF 1», distance 110, metric 4, type intra area
Last update from 172.16.2.197 on FastEthernet1/0.911, 00:00:53 ago
Routing Descriptor Blocks:
* 172.16.2.197, from 172.16.255.80, 00:00:53 ago, via FastEthernet1/0.911
Route metric is 4, traffic share count is 1
Vld-gw1#sh ip route 172.16.128.0
Routing entry for 172.16.128.0/24
Known via «OSPF 1», distance 110, metric 3, type intra area
Last update from 172.16.2.193 on FastEthernet1/0, 00:01:57 ago
Routing Descriptor Blocks:
* 172.16.2.193, from 172.16.255.80, 00:01:57 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1
Msk-arbat-gw1#traceroute 172.16.128.1
Type escape sequence to abort.
Tracing the route to 172.16.128.1
1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 msec
3 172.16.2.161 15 msec 13 msec 6 msec

То есть теперь Красноярска трафик достигает таким путём:

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

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

EIGRP

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

Итак, чем хорош EIGRP?
- прост в конфигурации
- быстрое переключение на заранее просчитанный запасной маршрут
- требует меньше ресурсов роутера (по сравнению с OSPF)
- суммирование маршрутов на любом роутере (в OSPF только на ABR\ASBR)
- балансировка трафика на неравноценных маршрутах (OSPF только на равноценных)

Мы решили перевести одну из записей блога Ивана Пепельняка, в которой разбирается ряд популярных мифов про EIGRP:
- “EIGRP это гибридный протокол маршрутизации”. Если я правильно помню, это началось с первой презентации EIGRP много лет назад и обычно понимается как «EIGRP взял лучшее от link-state и distance-vector протоколов». Это совершенно не так. У EIGRP нет никаких отличительных особенностей link-state. Правильно будет говорить «EIGRP это продвинутый distance-vector- протокол маршрутизации».
- “EIGRP это distance-vector протокол”. Неплохо, но не до конца верно тоже. EIGRP отличается от других DV способом, которым обрабатывает потерянные маршруты (или маршруты с возрастающей метрикой). Все остальные протоколы пассивно ждут обновления информации от соседа (некоторые, например, RIP, даже блокируют маршрут для предотвращения петель маршрутизации), в то время как EIGRP ведет себя активнее и запрашивает информацию сам.
- “EIGRP сложен во внедрении и обслуживании”. Неправда. В свое время, EIGRP в больших сетях с низкоскоростными линками было сложновато правильно внедрить, но ровно до того момента, как были введены stub routers. С ними (а также несколькими исправлениями работы DUAL-алгоритма), он не чуть не хуже, чем OSPF.
- “Как и LS протоколы, EIGRP хранит таблицу топологии маршрутов, которыми обменивается”. Просто удивительно, насколько это неверно. EIGRP не имеет вообще никакого понятия о том, что находится дальше ближайших соседей, в то время как LS протоколы точно знают топологию всей области, к которой они подключены.
- “EIGRP это DV протокол, который действует, как LS”. Неплохая попытка, но по-прежнему, абсолютно неверно. LS протоколы строят таблицу маршрутизации, проходя через следующие шаги:
- каждый маршрутизатор описывает сеть, исходя из информации, доступной ему локально (его линки, подсети, в которых он находится, соседи, которых он видит) посредством пакета (или нескольких), называемого LSA (в OSPF) или LSP (IS-IS)
- LSA распространяются по сети. Каждый маршрутизатор должен получить каждую LSA, созданную в его сети. Информация, полученная из LSA, заносится в таблицу топологии.
- каждый маршрутизатор независимо анализирует свою таблицу топологии и запускает SPF алгоритм для подсчета лучших маршрутов к каждому из других маршрутизаторов
Поведение EIGRP даже близко не напоминает эти шаги, поэтому непонятно, с какой стати он «действует, как LS»
Единственное, что делает EIGRP - это хранит информацию, полученную от соседа (RIP сразу же забывает то, что не может быть использовано в данный момент). В этом смысле, он похож на BGP, который тоже хранит все в таблице BGP и выбирает лучший маршрут оттуда. Таблица топологии (содержащая всю информацию, полученную от соседей), дает EIGRP преимущество перед RIP – она может содержать информацию о запасном (не используемом в данный момент) маршруте.
Теперь чуть ближе к теории работы:
Каждый процесс EIGRP обслуживает 3 таблицы:
- Таблицу соседей (neighbor table), в которой содержится информация о “соседях”, т.е. других маршрутизаторах, непосредственно подключенных к текущему и участвующих в обмене маршрутами. Можно посмотреть с помощью команды show ip eigrp neighbors
- Таблицу топологии сети (topology table), в которой содержится информация о маршрутах, полученная от соседей. Смотрим командой show ip eigrp topology
- Таблицу маршрутизации (routing table), на основе которой роутер принимает решения о перенаправлении пакетов. Просмотр через show ip route
Метрика.
Для оценки качества определенного маршрута, в протоколах маршрутизации используется некое число, отражающее различные его характеристики или совокупность характеристик- метрика. Характеристики, принимаемые в расчет, могут быть разными- начиная от количества роутеров на данном маршруте и заканчивая средним арифметическим загрузки всех интерфейсов по ходу маршрута. Что касается метрики EIGRP, процитируем Jeremy Cioara: “у меня создалось впечатление, что создатели EIGRP, окинув критическим взглядом свое творение, решили, что все слишком просто и хорошо работает. И тогда они придумали формулу метрики, что бы все сказали “ВАУ, это действительно сложно и профессионально выглядит”. Узрите же полную формулу подсчета метрики EIGRP: (K1 * bw + (K2 * bw) / (256 - load) + K3 * delay) * (K5 / (reliability + K4)), в которой:
- bw это не просто пропускная способность, а (10000000/самая маленькая пропускная способность по дороге маршрута в килобитах) * 256
- delay это не просто задержка, а сумма всех задержек по дороге в десятках микросекунд * 256 (delay в командах show interface, show ip eigrp topology и прочих показывается в микросекундах!)
- K1-K5 это коэффициенты, которые служат для того, чтобы в формулу “включился” тот или иной параметр.
Страшно? было бы, если бы все это работало, как написано. На деле же из всех 4 возможных слагаемых формулы, по умолчанию используются только два: bw и delay (коэффициенты K1 и K3=1, остальные нулю), что сильно ее упрощает - мы просто складываем эти два числа (не забывая при этом, что они все равно считаются по своим формулам). Важно помнить следующее: метрика считается по худшему показателю пропускной способности по всей длине маршрута .
Интересная штука получилась с MTU: довольно часто можно встретить сведения о том, что MTU имеет отношение к метрике EIGRP. И действительно, значения MTU передаются при обмене маршрутами. Но, как мы можем видеть из полной формулы, никакого упоминания об MTU там нет. Дело в том, что этот показатель принимается в расчет в довольно специфических случаях: например, если роутер должен отбросить один из равнозначных по остальным характеристикам маршрутов, он выберет тот, у которого меньший MTU. Хотя, не все так просто (см. комментарии).
Определимся с терминами, применяемыми внутри EIGRP. Каждый маршрут в EIGRP характеризуется двумя числами: Feasible Distance и Advertised Distance (вместо Advertised Distance иногда можно встретить Reported Distance, это одно и то же). Каждое из этих чисел представляет собой метрику, или стоимость (чем больше-тем хуже) данного маршрута с разных точек измерения: FD это “от меня до места назначения”, а AD- “от соседа, который мне рассказал об этом маршруте, до места назначения”. Ответ на закономерный вопрос “Зачем нам надо знать стоимость от соседа, если она и так включена в FD?”- чуть ниже (пока можете остановиться и поломать голову сами, если хотите).
У каждой подсети, о которой знает EIGRP, на каждом роутере существует Successor- роутер из числа соседей, через который идет лучший (с меньшей метрикой), по мнению протокола, маршрут к этой подсети. Кроме того, у подсети может также существовать один или несколько запасных маршрутов (роутер-сосед, через которого идет такой маршрут, называется Feasible Successor). EIGRP- единственный протокол маршрутизации, запоминающий запасные маршруты (в OSPF они есть, но содержатся, так сказать, в “сыром виде” в таблице топологии- их еще надо обработать алгоритмом SPF), что дает ему плюс в быстродействии: как только протокол определяет, что основной маршрут (через successor) недоступен, он сразу переключается на запасной. Для того, чтобы роутер мог стать feasible successor для маршрута, его AD должно быть меньше FD successor’а этого маршрута (вот зачем нам нужно знать AD). Это правило применяется для того, чтобы избежать колец маршрутизации.
Предыдущий абзац взорвал мозг? Материал трудный, поэтому еще раз на примере. У нас есть вот такая сеть:
С точки зрения R1, R2 является Successor’ом для подсети 192.168.2.0/24. Чтобы стать FS для этой подсети, R4 требуется, чтобы его AD была меньше FD для этого маршрута. FD у нас ((10000000/1544)*256)+(2100*256) =2195456, AD у R4 (с его точки зрения это FD, т.е. сколько ему стоит добраться до этой сети) = ((10000000/100000)*256)+(100*256)=51200. Все сходится, AD у R4 меньше, чем FD маршрута, он становится FS. *тут мозг такой и говорит: “БДЫЩЬ”*. Теперь смотрим на R3- он анонсирует свою сеть 192.168.1.0/24 соседу R1, который, в свою очередь, рассказывает о ней своим соседям R2 и R4. R4 не в курсе, что R2 знает об этой подсети, и решает ему рассказать. R2 передает информацию о том, что он имеет доступ через R4 к подсети 192.168.1.0/24 дальше, на R1. R1 строго смотрит на FD маршрута и AD, которой хвастается R2 (которая, как легко понять по схеме, будет явно больше FD, так как включает и его тоже) и прогоняет его, чтобы не лез со всякими глупостями. Такая ситуация довольно маловероятна, но может иметь место при определенном стечении обстоятельств, например, при отключении механизма “расщепления горизонта” (split-horizon). А теперь к более вероятной ситуации: представим, что R4 подключен к сети 192.168.2.0/24 не через FastEthernet, а через модем на 56k (задержка для dialup составляет 20000 usec), соответственно, добраться ему стоит ((10000000/56)*256)+(2000*256)= 46226176. Это больше, чем FD для этого маршрута, поэтому R4 не станет Feasible Successor’ом. Но это не значит, что EIGRP вообще не будет использовать данный маршрут. Просто переключение на него займет больше времени (подробнее об этом дальше).
соседство
Роутеры не разговаривают о маршрутах с кем попало - прежде чем начать обмениваться информацией, они должны установить отношения соседства. После включения процесса командой router eigrp с указанием номера автономной системы, мы, командой network говорим, какие интерфейсы будут участвовать и одновременно, информацию о каких сетях мы желаем распространять. Незамедлительно, через эти интерфейсы начинают рассылаться hello-пакеты на мультикаст- адрес 224.0.0.10 (по умолчанию каждые 5 секунд для ethernet). Все маршрутизаторы с включенным EIGRP получают эти пакеты, далее каждый маршрутизатор-получатель делает следующее:
- сверяет адрес отправителя hello-пакета, с адресом интерфейса, из которого получен пакет, и удостоверяется, что они из одной подсети
- сверяет значения полученных из пакета K-коэффициентов (проще говоря, какие переменные используются в подсчете метрики) со своими. Понятно, что если они различаются, то метрики для маршрутов будут считаться по разным правилам, что недопустимо
- проверяет номер автономной системы
- опционально: если настроена аутентификация, проверяет соответствие ее типа и ключей.
Если получателя все устраивает, он добавляет отправителя в список своих соседей, и посылает ему (уже юникастом) update-пакет, в котором содержится список всех известных ему маршрутов (aka full-update). Отправитель, получив такой пакет, в свою очередь, делает то же самое. Для обмена маршрутами EIGRP использует Reliable Transport Protocol (RTP, не путать с Real-time Transport Protocol, который используется в ip-телефонии), который подразумевает подтверждение о доставке, поэтому каждый из роутеров, получив update- пакет, отвечает ack -пакетом (сокращение от acknowledgement- подтверждение). Итак, отношение соседства установлены, роутеры узнали друг у друга исчерпывающую информацию о маршрутах, что дальше? Дальше они будут продолжать посылать мультикаст hello-пакеты в подтверждение того, что они на связи, а в случае изменения топологии- update-пакеты, содержащие сведения только об изменениях (partial update).
Теперь вернемся к предыдущей схеме с модемом.
R2 по каким-то причинам потерял связь с 192.168.2.0/24. До этой подсети у него нет запасных маршрутов (т.е. отсутствует FS). Как всякий ответственный роутер с EIGRP, он хочет восстановить связь. Для этого он начинает рассылать специальные сообщения (query- пакеты) всем своим соседям, которые, в свою очередь, не находя нужного маршрута у себя, расспрашивают всех своих соседей, и так далее. Когда волна запросов докатывается до R4, он говорит “погодите-ка, у меня есть маршрут к этой подсети! Плохонький, но хоть что-то. Все про него забыли, а я-то помню”. Все это он упаковывает в reply-пакет и отправляет соседу, от которого получил запрос (query), и дальше по цепочке. Понятное дело, это все занимает больше времени, чем просто переключение на Feasible Successor, но, в итоге, мы получаем связь с подсетью.
А сейчас опасный момент: может, вы уже обратили внимание и насторожились, прочитав момент про эту веерную рассылку. Падение одного интерфейса вызывает нечто похожее на широковещательный шторм в сети (не в таких масштабах, конечно, но все-таки), причем чем больше в ней роутеров, тем больше ресурсов потратится на все эти запросы-ответы. Но это еще пол-беды. Возможна ситуация и похуже: представим, что роутеры, изображенные на картинке- это только часть большой и распределенной сети, т.е. некоторые могут находится за много тысяч километров от нашего R2, на плохих каналах и прочее. Так вот, беда в том, что, послав query соседу, роутер обязан дождаться от него reply. Неважно, что в ответе- но он должен прийти. Даже если роутер уже получил положительный ответ, как в нашем случае, он не может поставить этот маршрут в работу, пока не дождется ответа на все свои запросы. А запросы-то, может, еще где-нибудь на Аляске бродят. Такое состояние маршрута называется stuck-in-active. Тут нам нужно познакомится с терминами, отражающими состояние маршрута в EIGRP: active\passive route. Обычно они вводят в заблуждение. Здравый смысл подсказывает, что active значит маршрут “активен”, включен, работает. Однако тут все наоборот: passive это “все хорошо”, а состояние active означает, что данная подсеть недоступна, и маршрутизатор находится в активном поиске другого маршрута, рассылая query и ожидая reply. Так вот, состояние stuck-in-active (застрял в активном состоянии) может продолжатся до 3 минут! По истечение этого срока, роутер обрывает отношения соседства с тем соседом, от которого он не может дождаться ответа, и может использовать новый маршрут через R4.
История, леденящая кровь сетевого инженера. 3 минуты даунтайма это не шутки. Как мы можем избежать инфаркта этой ситуации? Выхода два: суммирование маршрутов и так называемая stub-конфигурация.
Вообще говоря, есть еще один выход, и он называется фильтрация маршрутов (route filtering). Но это настолько объемная тема, что впроу отдельную статью под нее писать, а у нас и так уже пол-книги получилось в этот раз. Поэтому на ваше усмотрение.
Как мы уже упоминали, в EIGRP суммирование маршрутов можно проводить на любом роутере. Для иллюстрации, представим, что к нашему многострадальному R2 подключены подсети от 192.168.0.0/24 до 192.168.7.0/24, что очень удобненько суммируется в 192.168.0.0/21 (вспоминаем binary math). Роутер анонсирует этот суммарный маршрут, и все остальные знают: если адрес назначения начинается на 192.168.0-7, то это к нему. Что будет происходить, если одна из подсетей пропадет? Роутер будет рассылать query-пакеты с адресом этой сети (конкретным, например, 192.168.5.0/24), но соседи, вместо того, чтобы уже от своего имени продолжить порочную рассылку, будут сразу в ответ слать отрезвляющие реплаи, мол, это твоя подсеть, ты и разбирайся.
Второй вариант- stub- конфигурация. Образно говоря, stub означает “конец пути”, “тупик” в EIGRP, т.е., чтобы попасть в какую-то подсеть, не подключенную напрямую к такому роутеру, придется идти назад. Роутер, сконфигурированный, как stub, не будет пересылать трафик между подсетями, которые ему стали известны от EIGRP (проще говоря, которые в show ip route помечены буквой D). Кроме того, его соседи не будут отправлять ему query-пакеты. Самый распространенный случай применения- hub-and-spoke топологии, особенно с избыточными линками. Возьмем такую сеть: слева- филиалы, справа- основной сайт, главный офис и т.п. Для отказоустойчивости избыточные линки. Запущен EIGRP с дефолтными настройками.
А теперь “внимание, вопрос”: что будет, если R1 потеряет связь с R4, а R5 потеряет LAN? Трафик из подсети R1 в подсеть главного офиса будет идти по маршруту R1->R5->R2(или R3)->R4. Будет это эффективно? Нет. Будет страдать не только подсеть за R1, но и подсеть за R2 (или R3), из-за увеличения объемов трафика и его последствий. Вот для таких-то ситуаций и придуман stub. За роутерами в филиалах нет других роутеров, которые вели бы в другие подсети, это “конец дороги”, дальше только назад. Поэтому мы с легким сердцем можем сконфигурировать их как stub’ы, что, во-первых, избавит нас от проблемы с “кривым маршрутом”, изложенной чуть выше, а во-вторых, от флуда query-пакетов в случае потери маршрута.
Существуют различные режимы работы stub-роутера, задаются они командой eigrp stub:
R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

По умолчанию, если просто дать команду eigrp stub, включаются режимы сonnected и summary. Интерес представляет режим receive-only, в котором роутер не анонсирует никаких сетей, только слушает, что ему говорят соседи (в RIP есть команда passive interface, которая делает то же самое, но в EIGRP она полностью отключает протокол на выбранном интерфейсе, что не позволяет установить соседство).
Важные моменты в теории EIGRP, не попавшие в статью:
В EIGRP можно настроить аутентификацию соседей

Концепция graceful shutdown

Практика EIGRP
“Лифт ми Ап” купили фабрику в Калининграде. Там производят мозги лифтов: микросхемы, ПО. Фабрика очень крупная - три точки по городу - три маршрутизатора соединены в кольцо.
Но вот незадача - на них уже запущен EIGRP в качестве протокола динамической маршрутизации. Причём адресация конечных узлов совсем из другой подсети - 10.0.0.0/8. Все другие параметры (линковые адреса, адреса лупбэк интерфейсов) мы поменяли, но несколько тысяч адресов локальной сети с серверами, принтерами, точками доступа - работа не на пару часов - отложили на потом, а в IP-плане зарезервировали на будущее для Калининграда подсеть 172.16.32.0/20.
Сейчас у нас используются такие сети:

Как настраивается это чудо? Незамысловато, на первый взгляд:
router eigrp 1
network 172.16.0.0 0.0.255.255
network 10.0.0.0

В EIGRP обратную маску можно задавать, указывая тем самым более узкие рамки, либо не задавать, тогда будет выбрана стандартная маска для этого класса (16 для класса B - 172.16.0.0 и 8 для класса 8 - 10.0.0.0)
Такие команды даются на всех маршрутизаторах Автономной Системы. АС определяется цифрой в команде router eigrp, то есть в нашем случае имеем АС №1. Эта цифра должна быть одинаковой на всех маршрутизаторах (в отличии от OSPF).
Но есть в EIGRP серьёзный подвох: по умолчанию включено автоматическое суммирование маршрутов в классовом виде (в версиях IOS до 15).
Сравним таблицы маршрутизации на трёх калининградских маршрутизаторах:
Сеть 10.0.0.1/24 подключена у нас к klgr-center-gw1 и он о ней знает:
klgr-center-gw1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:35:23, Null0
C 10.0.0.0/24 is directly connected, FastEthernet1/0

Но не знает о 10.0.1.0/24 и 10.0.2.0/24/
Klgr-balt-gw1 знает о своих двух сетях 10.0.1.0/24 и 10.0.2.0/24, но вот сеть 10.0.0.0/24 он куда-то спрятал.
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:42:05, Null0
C 10.0.1.0/24 is directly connected, FastEthernet1/1.2
C 10.0.2.0/24 is directly connected, FastEthernet1/1.3

Они оба создали маршрут 10.0.0.0/8 с адресом next hop Null0.
А вот klgr-center-gw2 знает, что подсети 10.0.0.0/8 находятся за обоими его WAN интерфейсами.
D 10.0.0.0/8 via 172.16.2.41, 00:42:49, FastEthernet0/1
via 172.16.2.45, 00:38:05, FastEthernet0/0

Что-то очень странное творится.
Но, если вы проверите конфигурацию этого маршрутизатора, то, вероятно, заметите:
router eigrp 1
network 172.16.0.0
network 10.0.0.0
auto-summary

Во всём виновато автоматическое суммирование. Это самое большое зло EIGRP. Рассмотрим более подробно, что происходит. klgr-center-gw1 и klgr-balt-gw1 имеют подсети из 10.0.0.0/8, они их суммируют по умолчанию, когда передают соседям.
То есть, например, msk-balt-gw1 передаёт не две сети 10.0.1.0/24 и 10.0.2.0/24, а одну обобщённую: 10.0.0.0/8. То есть его сосед будет думать, что за msk-balt-gw1 находится вся эта сеть.
Но, что произойдёт, если вдруг на balt-gw1 попадёт пакет с адресатом 10.0.50.243, о котором тот ничего не знает? На этот случай и создаётся так называетмый Blackhole-маршрут:
10.0.0.0/8 is a summary, 00:42:05, Null0
Полученный пакет будет выброшен в эту чёрную дыру. Это делается во избежание петель маршрутизации.
Так вот оба эти маршрутизатора создали свои blackhole-маршруты и игнорируют чужие анонсы. Реально на такой сети эти три девайса друг друга так и не смогут пинговать, пока… пока вы не отключите auto-summary.
Первое, что вы должны сделать при настройке EIGRP:
router eigrp 1
no auto-summary

На всех устройствах. И всем будет хорошо:
Klgr-center-gw1:

C 10.0.0.0 is directly connected, FastEthernet1/0
D 10.0.1.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 via 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1
10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 is directly connected, FastEthernet1/1.2
C 10.0.2.0 is directly connected, FastEthernet1/1.3

klgr-center-gw2:
10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
Настройка передачи маршрутов между различными протоколами
Наша задача организовать передачу маршрутов между этими протоколами: из OSPF в EIGRP и наоборот, чтобы все знали маршрут до любой подсети.
Это называется редистрибуцией (перераспределением) маршрутов.
Для её осуществления нам нужна хотя бы одна точка стыка, где будут запущены одновременно два протокола. Это может быть msk-arbat-gw1 или klgr-balt-gw1. Выберем второй.
Из EIGRP в OSPF:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

Смотрим маршруты на msk-arbat-gw1:
msk-arbat-gw1#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 198.51.100.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2 10.0.0.0/8 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 via 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 is variably subnetted, 30 subnets, 5 masks
O E2 172.16.0.0/16 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
O E2 172.16.2.36/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
O 172.16.2.160/30 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 is directly connected, FastEthernet1/0.911
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
O 172.16.24.0/24 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 via 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 is directly connected, Loopback0
O 172.16.255.48/32 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
via 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 via 198.51.100.1
Вот те, что с меткой Е2 - новые импортированные маршруты. Е2 - означает, что это внешние маршруты 2-го типа (), то есть они были введены в процесс OSPF извне
Теперь из OSPF в EIGRP. Это чуточку сложнее:
klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500

Без указания метрики (вот этого длинного набора цифр) команда выполнится, но редистрибуции не произойдёт.
Импортированные маршруты получают метку EX в таблице маршрутизации и административную дистанцию 170, вместо 90 для внутренних:
klgr-gw2#sh ip route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 30 subnets, 4 masks
D EX 172.16.0.0/24 [170 /33280] via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [90 /30720] via 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 is directly connected, FastEthernet0/0
D 172.16.2.40/30 via 172.16.2.37, 00:38:59, FastEthernet0/0
via 172.16.2.46, 00:38:59, FastEthernet0/1
….
Вот так, казалось бы незамысловато это делается, но простота поверхностная - редистрибуция таит в себе много тонких и неприятных , когда добавляется хотя бы один избыточный линк между двумя разными доменами.
Универсальный совет - старайтесь избегать редистрибуции, если это возможно. Тут работает главное жизненное правило - чем проще, тем лучше.
Маршрут по умолчанию
Теперь самое время проверить доступ в интернет. Из Москвы он прекрасно себе работает, а вот если проверить, например из Петербурга (помним, что мы удалили все статические маршруты):
PC>ping linkmeup.ru
Pinging 192.0.2.2 with 32 bytes of data:

Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Ping statistics for 192.0.2.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Это связано с тем, что ни spb-ozerki-gw1, ни spb-vsl-gw1, ни кто-либо другой в нашей сети не знает о маршруте по умолчанию, кроме msk-arbat-gw1, на котором он настроен статически.
Чтобы исправить эту ситуацию, нам достаточно дать одну команду в Москве:
msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information originate

После этого по сети лавинно распространяется информация о том, где находится шлюз последней надежды.
Интернет теперь доступен:
PC>tracert linkmeup.ru
Tracing route to 192.0.2.2 over a maximum of 30 hops:
1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2
Полезные команды для траблшутинга
1) Список соседей и состояние связи с ними вызывается командой show ip ospf neighbor
msk-arbat-gw1:
Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Или для EIGRP: show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) С помощью команды show ip protocols можно посмотреть информацию о запущенных протоколах динамической маршрутизации и их взаимосвязи.
Klgr-balt-gw1:
Routing Protocol is «EIGRP 1 »

Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: EIGRP 1, OSPF 1
Automatic network summarization is in effect
Automatic address summarization:
Maximum path: 4
Routing for Networks:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distance: internal 90 external 170
Routing Protocol is «OSPF 1»
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.255.64
It is an autonomous system boundary router
Redistributing External Routes from,
EIGRP 1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.2.32 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.255.64 110 00:00:23
Distance: (default is 110)

4) Для отладки и понимания работы протоколов будет полезно воспользоваться следующими командами:
debug ip OSPF events
debug ip OSPF adj
debug EIGRP packets
Попробуйте подёргать разные интерфейсы и посмотреть, что происходит в дебаге, какие сообщения летят.
Задача №7
На последок комплесная задачка.
На последнем совещании Лифт ми Ап было решено, что сеть Калининграда необходимо также переводить на OSPF.
Переход должен быть совершен без разрывов связи. Было решено, что лучшим вариантом будет параллельно с EIGRP поднять OSPF на трёх маршрутизаторах Калининграда и после того, как будет проверено, что вся информация о маршрутах Калининграда распространилась по остальной сети и наоборот, отключить EIGRP. за логотип сайта.
OSPF

EIGRP

route redistribution

packet tracer

сети для самых маленьких
Добавить метки

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

Дистанционно-векторные протоколы маршрутизации

Дистанционно-векторные протоколы маршрутизации иногда именуются протоколами Беллмана-Форда (Bellman-Ford) в честь изобретателей алгоритма вычислений кратчайших маршрутов2, которые впервые описали механизм распределенного применения этого алгоритма3. Термин дистанционный вектор (distance vector) возник ввиду того, что в протоколе имеется вектор (список) расстояний (счетчик переприемов или другие параметры), который связан с каждым префиксом получателя, содержащимся в сообщении о маршруте.

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

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

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

При использовании RIP-1 маршрутизатор RTA выберет прямое соединение между RTA и RTB, чтобы достичь сети 192.10.5.0. Маршрутизатор RTA выбирает это соединение потому, что при непосредственном соединении для того, чтобы достичь заданной сети, используется лишь один переприем через узел RTB, против двух переприемов при выборе маршрута через узлы RTC и RTB. Однако маршрутизатор RTA "знает" о том, что канал RTA- RTB имеет меньшую производительность и большое время задержки, а канал RTC-RTB обеспечит более высокое качество обслуживания.

С другой стороны, при использовании протокола OSPF и метрик при выборе

маршрута, помимо подсчета количества переприемов, маршрутизатор RTA обнаружит, что путь к маршрутизатору RTB через RTC (вес: 60 + 60 = 120; 2 переприема) является более оптимальным, чем прямой путь (вес: 2000; 1 переприем).

Еще при подсчете переприемов следует учитывать ограничения, налагаемые на

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

характеристик дистанционно-векторных протоколов, хотя более новые протоколы этой категории (RIP-2 и EIGRP) не столь строги.

Еще один недостаток - способ обмена маршрутной информацией. Для традиционных дистанционно-векторных протоколов в настоящее время применяется следующая концепция: маршрутизаторы ведут обмен всеми IP-адресами, которые могут быть достигнуты при периодическом обмене данными посредством широковещательных анонсов дистанционных векторов. Эти широковещательные сообщения рассылаются согласно "таймеру обновлений" (refresh timer), установленному для каждого сообщения. Таким образом, если истекает срок работы "таймера обновлений" и при этом поступает новая маршрутная информация, требующая пересылки соседям, этот таймер сбрасывается, и маршрутная информация не пересылается до тех пор, пока срок работы таймера снова не истечет. Теперь рассмотрим, что бы произошло, если бы соединение или определенный маршрут вдруг стали недоступны по каким-либо причинам сразу после обновления маршрутов. Распространение маршрутной информации со сведениями о нерабочем маршруте было бы задержано на время до окончания срока работы "таймера обновления", следовательно, возникло бы значительное замедление при обновлении маршрутной информации.

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

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

Конвергенция (convergence) - это интервал времени, за который обновляются все

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

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

Еще один серьезный недостаток дистанционно-векторных протоколов первого

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

если интерфейс принадлежит сети, которая разбита на подсети с помощью масок переменной длины) и неправильной интерпретации принимаемых обновлений маршрутов. В новейших дистанционно-векторных протоколах, таких как RIP-2 и EIGRP, указанные недостатки устранены.

С целью исправления недостатков старых дистанционно-векторных протоколов маршрутизации было разработано несколько их модификаций. Так, например, протоколы RIP-2 и EIGRP уже поддерживают работу с VLSM и CIDR. К тому же протоколы IGRP и EIGRP способны воспринимать сложные метрики, которые используются для представления характеристик, соединений составляющих маршрут (таких как полоса пропускания, текущая нагрузка, задержки, размер передаваемого блока (MTU) и т.д.), с помощью которых можно вычислить более оптимальный маршрут, чем при простом подсчете числа переприемов.

Простота и завершенность дистанционно-векторных протоколов стала причиной их

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

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