Маршрутизаторы объединяют сегменты сетей или отдельные локальные сети в составную (распределенную) сеть. Маршрутизаторы функционируют в дейтаграммных сетях с коммутацией пакетов, где все возможные маршруты уже существуют. Поэтому пакету нужно лишь выбрать наилучший путь, на основе метрики протокола маршрутизации. Процесс прокладывания пути производится последовательно от одного маршрутизатора к другому. Этот процесс маршрутизации (routing ) является функцией Уровня 3 модели OSI. При прокладывании пути пакета маршрутизатор анализирует сетевой адрес узла назначения, заданный в заголовке пакета, вычленяет из него адрес сети, чтобы идентифицировать сеть адресата в пределах сети Интернет. Адреса сетей назначения хранятся в таблице маршрутизации. Поэтому маршрутизатор должен создавать и поддерживать таблицы маршрутизации, а также извещать другие маршрутизаторы о всех известных ему изменениях в топологии сети.

Совокупность сетей, представленных набором маршрутизаторов под общим административным управлением, образует автономную систему (рис. 9.1). Автономные системы нумеруются и в некоторых протоколах (IGRP, EIGRP) эти номера используются.

Рис. 9.1. Взаимодействие автономных систем

Маршрутизацию, т.е. прокладывание маршрута внутри автономных систем, осуществляют маршрутизирующие протоколы внутреннего шлюза (Interior Gateway Protocols - IGP s), к которым относятся RIP, RIPv2, IGRP, EIGRP, OSPF, Intermediate System-to-Intermediate System (IS-IS). Маршрутизацию между автономными системами производят протоколы внешнего шлюза (Exterior Gateway Protocols - EGP s). Примером протокола внешнего шлюза является протокол BGP, который работает на граничных маршрутизаторах автономных систем (рис. 9.1).

Маршрутизирующие протоколы, работающие внутри автономных систем, в свою очередь, подразделяются на протоколы вектора расстояния (distance - vector ) и протоколы состояния канала (link - state ). Протоколы distance-vector определяют расстояние и направление, т.е. вектор некоторого соединения в составной сети. Расстояние может быть выражено в количестве маршрутизаторов или переходов (hop count ) в соединении на пути от узла источника к адресату назначения или других значениях метрики. При использовании алгоритма distance-vector маршрутизаторы посылают всю или часть таблицы маршрутизации соседним (смежным) маршрутизаторам через определенные интервалы времени. В таких протоколах как RIP, обмен обновлениями (update ) или модификациями происходит, даже если в сети нет никаких изменений , на что затрачивается довольно большая часть полосы пропускания. Получив обновление маршрутной информации, маршрутизатор может заново вычислить все известные пути и произвести изменения в таблице маршрутизации.

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

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

- функцию определения пути с использованием сетевой части адреса,

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

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

Полосу пропускания,

Задержку,

Надежность,

Загрузку,

Обобщенную стоимость и другие параметры сетевого соединения.

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

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

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

RIP (Routing Information Protocol)

IGRP (Interior Gateway Routing Protocol)

EIGRP (Enhanced Interior Gateway Routing Protocol)

OSPF (Open Shortest Path First).

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

Протоколы и устройства Уровня 2 и Уровня 3 модели OSI постоянно взаимодействуют при передаче данных по сети (рис. 9.2).

Рис.9.2. Взаимодействие протоколов и устройств

Это проявляется в виде взаимодействия таблиц ARP (табл.9.1), функционирующих на Уровне 2, и таблиц маршрутизации протоколов Уровня 3 модели OSI. Каждый компьютер и порт маршрутизатора поддерживает таблицы ARP, каждая строка которых содержит пару соответствующих IP- и MAC-адресов и функционируют только в пределах широковещательного домена, т.е. в пределах сети или подсети.

Таблица 9.1

Таблица ARP маршрутизатора А

	МАС адрес

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

Таблица 9.2

Таблица маршрутизации маршрутизатора А

	Адрес сети назначения	Число переходов	Интерфейс

На Уровне 2 модели OSI функционируют коммутаторы, которые соединяют сегменты одной локальной сети или подсети, используя МАС-адреса. Для соединения с хостами вне локальной сети коммутатор продвигает кадр на маршрутизатор. Хост использует МАС-адрес входного интерфейса маршрутизатора как адрес назначения. Неизвестный МАС-адрес хост узнает из таблицы ARP. Маршрутизатор cверяет IP-адрес сети назначения с таблицей маршрутизации и продвигает пакет на выходной порт в соответствие с найденной строкой таблицы маршрутизации.

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

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

Тип протокола , который идентифицирует протокол маршрутизации, который создавал каждый вход (строку) таблицы.

Следующий переход (Next-hop) – указывает адрес входного интерфейса следующего маршрутизатора на пути к адресату назначения.

Метрику , которая различается для разные протоколов.

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

Маршрутизаторы поддерживают таблицы маршрутизации через обмен обновлениями или модификациями (update ). Некоторые протоколы передают обновления периодически, например, протоколы RIP, IGRP. Другие протоколы посылают модификации только когда происходят изменения в сетевой топологии, например, OSPF, EIGRP.

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

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

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

Полоса пропускания (Bandwidth) – способность соединения передавать данные с некоторой скоростью, например, соединения сети Ethernet предпочтительней линии со скоростью 64 кбит/с.

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

Надежность (Reliability) – надежность определяется интенсивностью ошибок на каждом сетевом соединении.

Количество переходов (Hop count) – это количество маршрутизаторов, через которые пакет должен пройти на пути к адресату назначения (число переходов от маршрутизатора к маршрутизатору).

Стоимость (Cost) –это обобщенный параметр затрат на передачу пакета к адресату назначения. Обычно стоимость имеет произвольное значение, назначенное администратором. Часто стоимость базируется на полосе пропускания.

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

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

Эти протоколы делятся на следующие группы:

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

2. С маршрутизацией от источника (Sonra Routing). Это многошаговый подход. Узел-источник задает в отправляемом пакете полный маршрут, через все промежуточные узлы. При таком подходе не нужны таблицы маршрутизации для промежуточных узлов, их работа ускоряется, но возрастает нагрузка на конечные узлы. Этот способ трудно применять в больших сетях.

Одношаговые алгоритмы в зависимости от способа формирования таблиц делятся на три класса:

1. Алгоритмы фиксированной (статической) маршрутизации.

2. Алгоритмы простой маршрутизации.

3. Алгоритмы адаптивной (или динамической) маршрутизации.

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

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

1. Случайная маршрутизация , когда прибывший пакет посылается в первом попавшемся случайном направлении, кроме исходного направления (аналогично обработке кадров с неизвестным адресом);

2. Лавинная маршрутизация, когда пакет широковещательно посылается по всем возможным направлениям, кроме исходного направления (аналогично обработке мостами кадров с неизвестным адресом);

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

Все описанные алгоритмы не подходят для больших сетей.

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

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

Адаптивные протоколы в свою очередь делятся на:

1. Дистанционно-векторные алгоритмы (Distance Vector Algorithms – DVA)

2. Алгоритмы состояния связей (Link State Algorithms – LSA)

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

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

Наиболее распространенный протокол описанного типа – RIP, существующий в версиях для протоколов IP и IPX.

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

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

Чтобы понять, в каком состоянии находятся линии связи, подключенные к его портам, маршрутизатор периодически обменивается короткими пакетами HELLO со своими ближайшими соседями. Этот служебный трафик также засоряет сеть, но не в такой степени, как, например, пакеты протокола RIP, так как пакеты HELLO имеют намного меньший объем.

Протоколы, использующие алгоритм состояния сетей – это OSPF (Open Shortest Path First) стека TCP/IP, IS-IS (Intermediate System to Intermediate System) стека OSI, и недавно реализованный протокол NLSP стека Novell.

Виды маршрутизации. Группы протоколов.

Реализуется на сетевом уровне сети. За нее отвечает протокол маршрутизации. При выборе стратегии маршрутизации могут быть поставлены разные цели, например:

Минимизация времени доставки пакетов;

Минимизации стоимости доставки пакетов;

Обеспечение максимальной пропускной способности сети и т.д.

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

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

Статическими или динамическими;

Одномаршрутными или многомаршрутными;

Одноуровневыми или иерархическими;

Внутридоменными или междоменными;

Одноадресными или групповыми.

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

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

Одномаршрутные протоколы предлагают только один маршрут для передачи пакета (который не всегда является оптимальным).

Многомаршрутные алгоритмы предлагают несколько маршрутов. Это позволяет передавать информацию получателю по нескольким маршрутам одновременно.

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

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

Одноадресные протоколы предназначены для передачи информации (по одному или нескольким маршрутам) только одному получателю. Многоадресные – способны передавать данные сразу многим абонентам.

Выделяют три основные группы протоколов маршрутизации в зависимости от используемого типа алгоритма определения оптимального маршрута:

Протоколы вектора расстояния;

Протоколы состояния канала;

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

Протоколывектора расстояния – самые простые и распространенные. Это, например, RIP, RTMP, IGRP.

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

Протоколысостояния канала были впервые предложены в 1970 году Эдсгером Дейкстрой. Здесь вместо рассылки содержимого таблиц маршрутизации, каждый маршрутизатор производит широковещательную рассылку списка маршрутизаторов, с которыми он имеет непосредственную связь, и списка напрямую подключенных к нему локальных сетей. Такая рассылка может производиться либо при изменении состояния каналов, либо периодически. Примеры протоколов: OSPF, IS-IS, Novell NLSP.

Протоколыполитики (правил)маршрутизации наиболее часто используются в сети Интернет. Они опираются на алгоритмы вектора расстояния. Информация о маршрутизации получается от соседних операторов на основании специальных критериев. На основе такого обмена вырабатывается список разрешенных маршрутов. Примеры: протоколы BGP и EGP.

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

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

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

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

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

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

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

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

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

Статей и видео о том, как настроить 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

сети для самых маленьких

Добавить метки