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

Полезные советы

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

Рис. 2.24

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

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

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

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

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

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

К внешним протоколам относятся Exterior Gateway Protocol (EGP) и < Protocol Gateway>.

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

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

К внутренним протоколам относятся протоколы Routing Information Protocol (RIP), HELLO, Intermediate System to Intermediate System (ISIS), Shortest Path First (SPF) и Open Shortest Path First (OSPF).

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

В основу алгоритма маршрутизации по протоколу RIP положена простая идея: чем больше шлюзов надо пройти пакету, тем больше времени требуется для прохождения маршрута. При обмене сообщениями маршрутизаторы сообщают в сеть IP-номер сети и число "прыжков" (hops), которое надо совершить, пользуясь данным маршрутом. Надо сразу заметить, что такой алгоритм справедлив только для сетей, которые имеют одинаковую скорость передачи по любому сегменту сети. Часто в реальной жизни оказывается, что гораздо выгоднее воспользоваться оптоволокном с 3-мя шлюзами, чем одним медленным коммутируемым телефонным каналом.

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

К сожалению, многовариантную маршрутизацию поддерживает не очень много систем. Различные клоны Unix и NT, главным образом ориентированы на протокол RIP. Достаточно посмотреть на программное обеспечение динамической маршрутизации, чтобы убедится в этом. Программа routed поддерживает только RIP, программа gated поддерживает RIP, HELLO, OSPF, EGP и BGP, в Windows NT поддерживается только RIP.

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

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

Динамическая маршрутизация выполняется независимо от сетевого администратора.

Протоколы динамической маршрутизации позволяют маршрутизаторам автоматически выполнять следующие операции:

· находить другие доступные маршрутизаторы в остальных сетевых сегментах;

· определять с помощью метрик кратчайшие маршруты к другим сетям;

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

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

· повторно находить маршрутизатор и сетевой путь после устранения сетевой проблемы в этом пути.

Мосты-маршрутизаторы

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

Рис. 3 Мост-маршрутизатор

Например, такое устройство может работать как мост для определенных протоколов, таких как NetBEUI (поскольку тот является немаршрутизируемым), и как маршрутизатор для других протоколов, например, для TCP/IP.

Мост-маршрутизатор может выполнять следующие функции:

· эффективно управлять пакетами в сети со многими протоколами, включая протоколы, которые являются маршрутизируемыми, и протоколы, которые маршрутизировать нельзя;

· уменьшать нагрузку на каналы, изолируя и перенаправляя сетевой трафик;

· соединять сети;

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

Мосты-маршрутизаторы используются в сетях, работающих с несколькими протоколами, например, с NetBEUI, IPX/SPX и TCP/IP, поэтому они также называются многопротокольными маршрутизаторами.

Функции (маршрутизация или пересылка), выполняемые ими по отношению к некоторому протоколу, зависят от двух причин:

· от директив сетевого администратора, заданных для этого протокола;

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

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

Это существенная возможность для сети, в число протоколов которой входит NetBEUI (поскольку этот протокол нельзя маршрутизировать). Для маршрутизируемых протоколов, таких как TCP/IP, мост-маршрутизатор пересылает пакеты в соответствии с адресной информацией и данными о маршрутизации, содержащимися на сетевом уровне.

Коммутаторы

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

Рис. 4 Коммутатор

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

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

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

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

· в процессе коммутации с промежуточным хранением (store-and-forward switching) (также называемой коммутацией с буферизацией) передача фрейма не начинается до тех пор, пока он не будет получен полностью. Как только коммутатор получает фрейм, он проверяет его контрольную сумму (CRC) перед тем, как отправлять целевому узлу. Затем фрейм поминается (буферизируется) до тех пор, пока не освободится соответствующий порт и коммуникационный канал (они могут быть заняты другими данными).

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

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

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

Коммутаторы локальных сетей поддерживают следующие стандарты:

· Fast Ethernet;

· Gigabit Ethernet;

· 10 Gigabit Ethernet;

· Fast Token Ring;

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

Поскольку каждый порт подключен к сегменту, содержащему только один узел, то этот узел и сегмент получают в свое распоряжение всю полосу пропускания (10 или 100 Мбит/с, 1 или 10 Гбит/с), т. к. другие узлы отсутствуют; при этом вероятность конфликтов уменьшается.

Другой распространенной областью применения коммутаторов являются сети с маркерным кольцом. Коммутатор Token Ring может выполнять только функции моста на канальном уровне или работать как мост с маршрутизацией от источника на Сетевом уровне.

Переключаясь непосредственно к тому сегменту, который должен получать данные, коммутаторы могут значительно увеличить пропускную способность сети без модернизации, существующей передающей среды. Рассмотрим для примера не имеющий возможности коммутации концентратор Ethernet, к которому подключены восемь сегментов 10 Мбит/с. Скорость работы этого концентратора никогда не превысит 10 Мбит/с, поскольку каждый момент времени он может передавать данные только в один сегмент. Если концентратор заменить коммутатором Ethernet, общая пропускная способность сети увеличится в восемь раз, т. е. до 80 Мбит/с, поскольку коммутатор может посылать пакеты в каждый сегмент практически одновременно. В настоящее время коммутаторы не намного дороже концентраторов, поэтому с их помощью проще всего повысить скорость работы сети с высоким трафиком.

Выпускаются управляемые коммутаторы, которые, как и управляемые концентраторы, имеют “интеллектуальные” способности. Для многих сетей имеет смысл потратить дополнительные средства на приобретение управляемых коммутаторов, поддерживающих протокол SNMP, что позволит повысить степень управления и мониторинга сети. Некоторые коммутаторы также могут поддерживать технологию виртуальных локальных сетей (Virtual LAN, VLAN).

Эта технология, описанная стандартами IEEE 802.1q, представляет собой программный метод деления сети на подсети, не зависящие от ее физической топологии и содержащие логические группы. Члены рабочей группы VLAN могут располагаться в физически удаленных сетевых сегменте однако их можно объединить в один логический сегмент с помощью программного обеспечения и коммутаторов VLAN, маршрутизаторов и других сетевых устройств. Лучше всего для реализации сетей VLAN использовать маршрутизирующие коммутаторы, поскольку они позволяют уменьшить издержки на управление сетью, что объясняется их умением маршрутизировать пакеты между подсетями. Коммутаторы Уровня 2 в сети VLAN требуют, чтобы порты коммутаторов были связаны с МАС-адресами, что усложняет управление сетью VLAN.

Шлюзы

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

Рис. 5 Шлюз

Например, с помощью шлюза можно выполнять следующие операции:

· преобразовывать широко используемые протоколы (например, TCP/IP) в специализированные (например, в SNA);

· преобразовывать сообщения из одного формата в другой;

· преобразовывать различные схемы адресации;

· связывать хост-компьютеры с локальной сетью;

· обеспечивать эмуляцию терминала для подключений к хост-компьютеру;

· перенаправлять электронную почту в нужную сеть;

· соединять сети с различными архитектурами.

Шлюзы имеют множество назначений, поэтому могут работать на любом Уровне OSI.

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

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

Сетевой шлюз может с одной стороны принять пакет, сформатированный под один протокол (например Apple Talk) и конвертировать в пакет другого протокола (например TCP/IP) перед отправкой в другой сегмент сети. Сетевые шлюзы могут быть аппаратным решением, программным обеспечением или тем и другим вместе, но обычно это программное обеспечение, установленное на роутер или компьютер. Сетевой шлюз должен понимать все протоколы, используемые роутером. Обычно сетевые шлюзы работают медленнее, чем сетевые мосты, коммутаторы и обычные маршрутизаторы.

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

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

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

Компьютеры под Windows обычно используют встроенный мастер подключения к сети, который по указанным параметрам сам устанавливает соединение с локальной или глобальной сетью. Такие системы могут также использовать DHCP-протокол.

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

Основные виды передающего оборудования глобальных сетей:

· мультиплексоры;

· группы каналов;

· частные телефонные сети;

· телефонные модемы;

· адаптеры ISDN;

· кабельные модемы;

· модемы и маршрутизаторы DSL;

· серверы доступа;

· маршрутизаторы.

Мультиплексоры

Мультиплексоры (multiplexer, MUX) – это сетевые устройства, которые могут принимать сигнал от множества входов и передавать их в общую сетевую среду.

Рис.1 Мультиплексор

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

· в телефонии для коммутации физических линий;

· при коммутации телекоммуникационных виртуальных цепей для создания множества каналов в одной линии (например, в Т-линиях);

· в последовательных каналах для подключения нескольких терминалов к одной линии (в локальных или глобальных сетях), для чего эта линия делится на несколько каналов;

· в технологиях Fast Ethernet, X.25, ISDN, ретрансляции кадров, АТМ других (для создания множества коммуникационных каналов в одной кабельной передающей среде).

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

Методы электрической коммутации: множественный доступ с уплотнением каналов (TDMА), множественный доступ с частотным разделением каналов (FDMA) и статистический множественный доступ.

При передаче по оптической среде применяется спектральное разделение (уплотнение) каналов (wavelength division multiplexing, WDM). Световую волну можно представить как спектр, состоящий из волн различной длины, изменяемой в ангстремах. Ангстрем равен 10-10 м, а световая волна состоит из отдельных волн длиной от 4000 до 7000 ангстрем. При использовании спектрального разделения несколько входящих соединений преобразуются в набор волн различной длины в пределах спектра света, передаваемого по оптоволоконному кабелю.

Группы каналов

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

Рис. 2 Группы каналов

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

Таким образом, группа каналов – это крупный мультиплексор, объединяющий телекоммуникационные каналы в одном месте, называемом точкой присутствия (point of presence, POP). Эти каналы могут представлять собой частные линии Т-1, полные линии Т-1 и Т-3, каналы ISDN или каналы с ретрансляцией кадров. Первые группы каналов типа D-1 состояли из мультиплексоров Т-1.

Усовершенствования групп каналов привели к появлению D-4 и менее дорогих систем цифрового доступа и коммутации (DACS). Там, где интенсивно используются выделенные линии, существуют также группы каналов Т-3, ISDN и с ретрансляцией кадров.

В пределах точки присутствия (POP) несколько групп каналов связываются Между собой для того, чтобы входящий трафик из одной группы каналов можно было переключать на другую группу каналов и отправлять к точке Назначения. Все каналы во входящей линии (например, линии Т-1) объединяются и могут быть перенаправлены в другую группу каналов. Можно так же перенаправить в другую группу только один из входящих каналов. Для соединения групп каналов существуют два метода маршрутизации, которые, по сути, напоминают динамическую и статическую маршрутизацию в сетях. Таким образом, современные группы каналов располагают таблицами маршрутизации, которые либо поддерживаются автоматически, либо настраиваются администраторами.

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

Частные телефонные сети

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

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

В результате усовершенствований появились автоматические учрежденческие телефонные системы, называемые частными АТС без выхода в общую сеть (private automatic exchange, PAX) и частными АТС с исходящей и входящей связью (private automatic branch exchange, PABX).

Рис. 3 Private automatic branch exchange, PABX

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

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

Телефонные модемы

Модемы долго играли важную роль в становлении глобальных сетей. Термин модем представляет собой сокращение от термина “модулятор/демодулятор”.
Модем преобразует выходящий компьютерный (цифровой) сигнал в аналоговый, который может быть передан по телефонной линии. Кроме того, модем преобразует входящий аналоговый сигнал в цифровой, понятный компьютеру.

Рис. 4 Телефонный модем

Модемы для компьютеров бывают внутренние и внешние. Внутренний модем вставляется в компьютерный слот расширения на материнской плате.

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

Существуют три основных типа разъемов: устаревший разъем DB-25 с 25 штырьками (контактами), похожий на разъем параллельного принтерного порта (однако непригодный для работы с параллельным портом); разъем DB-9 на 9 контактов и круглый разъем PS/2 для последовательной связи (такой как на IBM PC).

Также для последовательных соединений используется универсальная последовательная шина (Universal Serial Bus USB). Стандарт USB позволяет соединять любые типы периферийных устройств (например, принтеры, модемы и ленточные накопители) и во многих случаях заменяет обычные параллельные и последовательные порты. И внутренние, и внешние модемы подключаются к телефонной розетке с помощью обычного телефонного шнура, имеющего на обоих концах разъемы RJ-11.

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

Основное влияние на модемные технологии оказала компания Microcom, первая разработавшая протокол Microcom Network Protocol (MNP). Этот стандарт описывает классы коммуникационных служб (классы MNP со 2-й по 6-й, а также класс 10-й для передачи с использованием сотовых телефонов) и обеспечивает эффективную работу с помощью методов коррекции ошибок и сжатия данных.

Союз ITU также разработал стандарты на модемную связь, включив в свой стандарт V.42 многие классы MNP.

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

Адаптеры ISDN

Для подключения компьютера к линии ISDN необходимо устройство, напоминающее цифровой модем и называемое терминальным адаптером (terminal adapter, ТА).

Рис. 5 Адаптер ISDN

Существующие терминальные адаптеры имеют почти такую же стоимость, как и высококачественные асинхронные или синхронные модемы, однако их быстродействие выше (например, от 128 до 512 Кбит/с).

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

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

Модемы и маршрутизаторы DSL

Другой высокоскоростной службой передачи цифровых данных, конкурирующей с ISDN и кабельными модемами, является технология Digital Subscriber Line, DSL (цифровая абонентская линия).

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

Рис.1 Интеллектуальный адаптер, подключенный к сети DSL

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

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

Максимальная скорость восходящего канала равна 1 Мбит/с, а нисходящая может достигать 60 Мбит/с. Максимальное расстояние без повторителя (усиливающего сигнал) от пользователя к телекоммуникационной компании равняется 5,5 км (что совпадает с требованиями ISDN).

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

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

Серверы доступа

Сервер доступа (access server) совмещает в себе функции нескольких устройств, применяемых для глобальной связи.

Например, один сервер доступа может выполнять передачу данных с использованием модемных коммуникаций, Х.25, линий Т-1, Т-3 и ISDN, а также ретрансляции кадров. Некоторые серверы доступа разработаны для небольших и средних по размеру сетей.

Такие серверы для подключения к сети имеют адаптер Ethernet или Token Ring. Также у них существуют несколько синхронных и асинхронных портов для подключения терминалов, модемов, телефонов-автоматов, линий ISDN и Х.25. У небольших серверов доступа обычно бывает от 8 до 16 асинхронных портов и один-два синхронных порта.

Мощные серверы доступа имеют модульную конструкцию со слотами (от 10 до 20) для подключения коммуникационных плат, как показано на рис. 4.14. Одна плата, к примеру, может иметь 8 асинхронных портов и один синхронный. Другая плата может предназначаться для подключения к линии Т-1, а еще одна – для работы с линией ISDN.

Рис. 2 Серверы доступа

Также могут быть модульные платы со встроенными модемами, например, с 4-мя модемами на одной плате. Некоторые серверы доступа модульной конструкции способны поддерживать почти 70 модемов. Для обеспечения отказоустойчивости серверы снабжаются также дополнительными источниками питания.

Маршрутизаторы

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

Рис. 3 Маршрутизатор

Удаленные маршрутизаторы соединяют сети, использующие ATM, ISDN, технологии ретрансляции кадров и передачи данных по скоростной последовательной линии, а также Х.25. Удаленный маршрутизатор, как и локальный, может поддерживать множество протоколов, позволяя соединять удаленные сети различных типов. Аналогичным образом удаленный маршрутизатор может работать как брандмауэр, ограничивающий доступ к определенным сетевым ресурсам.

Некоторые удаленные маршрутизаторы имеют модульную конструкцию, что позволяет вставлять в слоты расширения различные интерфейсы (например, Интерфейс для ISDN-линии и интерфейс для ретрансляции кадров).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 172.16.2.130 35 msec 8 msec 5 msec

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

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

EIGRP

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

Мы решили перевести одну из записей блога Ивана Пепельняка, в которой разбирается ряд популярных мифов про 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-го типа (External), то есть они были введены в процесс 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. за логотип сайта. Добавить метки

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

Протокол динамической маршрутизации RIP - понятие и виды. Классификация и особенности категории "Протокол динамической маршрутизации RIP" 2017, 2018.

- The Anglo-Saxon script and peculiarities of the Old English alphabet

The earliest records of English that have come down to us are dated in the 7th century. The period preceding this date is called pre-written. The Old English written monuments represent two types of script – the so called runic alphabet and Latin alphabet. The Runic alphabet was adopted by Anglo-Saxons on the continent before coming to the Island. It is a special type of script used by all Germanic tribes before they became Christians. They adopted Christianity in the 7th century. In the year... .

- Post scriptum 1 страница

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

- P. Post scriptum

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

- Homo triplex и три квинтета

Прежде чем изучать структуру Адулруны, рассмотрим представления Буреуса о трёхчастности. Как человек, так и мир состоят из трёх уровней бытия. Это общее представление герметизма и неоплатонизма. Существует божественный уровень, материальный уровень, а между ними - некий... .

- Маршрутизация в глобальной сети. Метрики. Протокол RIP.

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

- Лабораторная работа №7. Настройка протокола RIP в корпоративной сети.

Создайте схему, представленную на рис.6.2. Рис.6.2. Схема сети. В четырех сетях: 11.0.0.0/8, 12.0.0.0/8, 13.0.0.0/8 и 14.0.0.0/8 установлены компьютеры с адресами: Comp1 – 11.0.0.11, маска 255.0.0.0 Comp2 – 12.0.0.12, маска 255.0.0.0 ... ..

- PostScript Type1

Каждый символ шрифта можно представить как совокупность фрагментов некоторых кривых. С математической точки зрения для описания фрагмента кривой достаточно указать небольшое количество параметров. Например, кривая второго порядка - квадратичная парабола у = ах2+ bх... .

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

EIGRP

соседство

Практика EIGRP

Настройка передачи маршрутов между различными протоколами

Маршрут по умолчанию

Полезные команды для траблшутинга

EIGRP

соседство

Практика EIGRP

Настройка передачи маршрутов между различными протоколами

Маршрут по умолчанию

Полезные команды для траблшутинга

Популярные статьи

Последние статьи

Разделы

Страницы

Спецпроекты

Контакты