Протокол маршрутизации. Что будем делать с полученным материалом

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

Маршрутизируемый против маршрутизирующего

Меня всегда очень сильно привлекали сетевые протоколы (networking protocol). Я не знаю, почему они всегда меня так очаровывали, но они очень сильно интересовали меня. Большое количество моего времени было потрачено на изучение и работу с протоколами, которые входят в состав протокола TCP/IP. Общим во всех этих протоколах является то, что все они являются маршрутизируемыми протоколами. В результате этого возникает вопрос, а что маршрутизирует их? В самом деле очень хороший вопрос, и об этом было написано немало книг.

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

Преимущества и недостатки

Мы уже знаем, что пакеты, которые формируются на наших компьютерах, являются частью маршрутных протоколов. В свою очередь, чтобы пакеты дошли до своих получателей, эти протоколы должны быть маршрутизированы. Как пакет придет к получателю? Это достаточно сложно, т.к. он маршрутизируется несколькими маршрутизаторами, а это в свою очередь в основном происходит благодаря IP адресу, который находится в IP заголовке. Благодаря такому упрощенному объяснению мы попробуем рассмотреть две категории маршрутизирующих протоколов.

Сами по себе маршрутизирующие протоколы разбиваются на две категории. Это Interior Gateway Protocols (внутренние протоколы шлюза IGP) и Exterior Gateway Protocols (внешние протоколы шлюза EGP). Как можно догадаться из названия, первая группа используется внутри, а вторая снаружи. Например, серия IGP маршрутизирующих протоколов используется во внутренних сетях (internal networks), а серия EGP марштизирующих протоколов используется в самом интернет. Что же это в действительности означает? Это означает, что когда вы выполняете начальную конфигурацию всеми вами любимого маршрутизатора Cisco router, то вы должны выбрать какой тип маршрутизирующего протокола вы будете устанавливать и настраивать.

Теперь пришло время привести список различных типов маршрутизирующих протоколов для каждой группы. Interior Gateway Protocols (внутренние протоколы шлюза) подразделяются на:

• IGRP: Interior Gateway Routing Protocol (внутренний маршрутизирующий протокол шлюза)
• EIGRP: Enhanced Interior Gateway Routing Protocol (улучшенный IGRP)
• OSPF: Open Shortest Path First (сначала открывать самый короткий путь)
• RIP: Routing Information Protocol (протокол для маршрутизирующей информации)
• IS-IS: Intermediate System – Intermediate System

Внешние протоколы шлюза (Exterior Gateway Protocol) подразделяются:

• EGP: Exterior Gateway Protocol (внешний протокол шлюза)
• BGP: Border Gateway Protocol (пограничный протокол шлюза)

Внутренние протоколы шлюза

Из приведенных выше примеров протоколов IGP (Interior Gateway Protocols) мы можем заключить, что существует несколько из них. Все ли из них используются в современных внутренних сетях? Я предполагаю, что они должны бы использоваться, но наиболее часто на сегодняшний день встречаются OSPF и RIP. Помня это, давайте рассмотрим RIP. RIP называют динамическим маршрутизирующим протоколом (dynamic routing protocol). Это значит, что он автоматически определяет маршрутные таблицы на свое усмотрение. Другими словами системному администратору не нужно вручную вводить все возможные маршруты. А это достаточно большая работа!

Итак, RIP автоматически вычисляет маршруты, а также вторичные маршруты, которые будут использоваться в случае аварии на основных. Если вы думаете, что это похоже на балансирования нагрузки “load balancing”, то вы в принципе будете правы. Еще одна вещь, которую нужно знать и помнить о RIP, что это протокол удаленного вектора “distance vector”. Т.к. эта статья является лишь обзором протоколов, то я лишь скажу удаленный вектор (distance vector) включает в себя метод определения маршрутов. Чтобы получить более подробную информацию по этой очень важной теме, пожалуйста, нажмите здесь. Также о протоколе RIP необходимо помнить, что он использует порт 520 и протокол UDP в качестве транспортного протокола (transport protocol).

OSPF – это другой часто используемый протокол IGP. Основное различие между RIP и OSPF заключается в том, что OSPF – это протокол состояния канала (link state protocol). Это просто означает, что он использует другой способ для построения маршрутных таблиц (routing tables). Маршрутизаторы OSPF сообщают величины, которые содержат информацию о том, какой маршрутизатор OSPF будет использоваться для построения маршрутных таблиц. Это одновременно и просто и сложно Основные вещи, которые необходимо помнить про OSPF – это то, что он поддерживает многоканальную передачу (multicasting) и подсети (subnets). И наконец, OSPF использует IP, а не TCP или UDP.

Внешние протоколы шлюза

Итак, мы поверхностно обсудили два основных протокола IGP, а как насчет протоколов EGP(Exterior Gateway Protocols)? Действительно, давайте взглянем на них тоже. Прокол BGP или Border Gateway Protocol – это маршрутный протокол, который используется на сегодняшний день маршрутизаторами, формирующими интернет. Под этим я понимаю маршрутизаторы, которые, например, используются вашим ISP. Также как и протокол RIP, BGP использует протокол или алгоритм удаленного вектора (distance vector). Один примечательный факт, касающийся BGP, заключается в том, что он использует TCP в качестве транспортного протокола и общается по порту 179. Другими словами, маршрутные таблицы передаются по протоколу TCP и по порту 179. Мы немного поговорили о BGP, а что можно сказать о EGP? В действительности о нем можно сказать немного, т.к. реально он нигде не используется. Он был заменен BGP.

Резюме

Итак, как вы могли увидеть, я не шутил, когда сказал, что лишь приведу обзор маршрутных протоколов. Только по одному протоколу BGP было написано несколько толстых книг. Поэтом было бы невозможно рассказать обо всех этих протоколах подробно в одной статье. Целью этой статьи было показать разнообразие маршрутных протоколов и различие между ними и маршрутизируемыми протоколами. Что вы должны сделать, чтобы больше узнать об этих маршрутных протоколах? Я всегда очень много надежд возлагал на практику. По моему мнению, это лишь единственный способ для закрепления полученных знаний.

С этой точки зрения, если у вас есть финансовые возможности, попытайтесь использовать несколько сетевых устройств Cisco. Они не очень дорого стоят, и вполне окупятся для вас полученными знаниями о трафике, который они маршрутизируют. После покупки нескольких сетевых устройств я бы посоветовал воспользоваться вам программой под названием Nemesis, которая позволит вам выделить RIP, OSPF и IGMP среди других. Способность выделения пакетов некоторых маршрутных протоколов позволит вам также увидеть, как они реагируют на определенные ситуации. Работа с пакетами позволяет гораздо лучше разобраться с протоколом. Благодаря этому вы сможете больше узнать о самом протоколе и о принципах его работы. И последнее, как было упомянуто выше, работа с сетевыми устройствами является ключевой, т.к. настройка протокола должна быть произведена с помощью этого аппаратного обеспечения. Но если вы ограничены бюджетом, то вы можете купить один из симуляторов, которых сейчас полно на рынке.

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

Иcточник: netdocs.ru

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

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

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

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

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

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

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

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

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

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

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

10100000.01010001.00000101.10000011 = 160.81.5.131

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Протокол UDP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Указанные протоколы маршрутизации следует отличать от собственно протокола сетевого уровня модели OSI для стека TCP/IP – IP. Протокол IP, выполняя функции сетевого уровня модели OSI, принимает участие в доставке пакетов адресату через разнородную составную сеть. Если протоколы маршрутизации RIP и OSPF собирают и передают по сети сугубо служебную информацию, то IP передает пользовательские данные, как протоколы канального уровня. Протоколы маршрутизации используют сетевой уровень протокола IP как транспортное средство.

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

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

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

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

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

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

В алгоритмах фиксированной маршрутизации все записи в таблице маршрутизации являются статическими. Администратор сети сам решает на какие маршрутизаторы требуется передавать пакеты с теми или иными адресами пунктов назначения и при этом вручную с помощью утилиты route (для UNIX-подобных сетевых ОС и Windows) заносит соответствующие записи в таблицу маршрутизации. Таблица как правило создается в процессе загрузки и остается без изменений до ее ручной корректировки (причинами такой корректировки могут быть, например, отказ одного маршрутизатора сети или когда его функции необходимо возложить на другой маршрутизатор). Различают одномаршрутные (для любого адреса сети назначения задается всегда один путь) и многомаршрутные таблицы (может быть определено несколько путей для каждого адресата). Для крайнего случая должно быть задано правило для выбора одного из указанных маршрутов. Чаще всего – один путь основной, остальные – резервные. Рассматриваемый алгоритм маршрутизации приемлем в небольших сетях с простой топологией (в силу большого количества рутинных операций для сетевого администратора). В алгоритмах простой маршрутизации таблица маршрутизации либо совсем не используется либо строится без участия протоколов маршрутизации. Выделяют 3 типа простой маршрутизации:

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

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

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

На сегодняшний день самыми распространенными являются алгоритмы адаптивной (динамической) маршрутизации. Эти алгоритмы обеспечивают автоматическое обновление таблиц маршрутизации после изменения конфигурации составных сетей. Протоколы, которые построены на основе адаптивных алгоритмов позволяют всем маршрутизаторам собирать всю информацию о топологии связи в составной сети. Оперативно отрабатывать все изменения конфигурации этих связей. В таблицах маршрутизации при адаптивной маршрутизации указывается информация об интервале времени, в течении которого данный маршрут будет действительным, это время называют временем жизни маршрута (TTL , Time To Live). Все адаптивные протоколы маршрутизации должны отвечать следующим требованиям:

1. Должны обеспечивать рациональность маршрута продвижения пакета (здесь речь не идет об оптимальности маршрута)

2. Адаптивные алгоритмы не должны требовать слишком большого объема вычислений и порождать интенсивный служебный траффик.

3. Адаптивные алгоритмы должны обладать свойством сходимости

4. Всегда приводить к однозначному результату за приемлемое время

Все адаптивные протоколы построенные на адаптивных алгоритмах обмена маршрутной информацией делятся на 2 группы: дистанционно-векторные алгоритмы (Distance Vector Algorithms, DVA) и алгоритмы состояния связей (Link State Algorithms, LSA).

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

Алгоритм состояния связей (LSA) обеспечивает каждый маршрутизатор информацией, которая является достаточной для построения точного графа связей составной сети. При этом все маршрутизаторы работают на принципе одинаковых графов. Это делает процесс маршрутизации более устойчивым к изменению конфигурации. Вершинами графа являются как маршрутизаторы, так и объединяемые ими сети. Распространяемая по сети (составной сети) информация состоит из описания связей типов: маршрутизатор-маршрутизатор, маршрутизатор-сеть. Чтобы понять в каком состоянии находятся линии связи, подключенные к его портам, маршрутизатор периодически обменивается короткими пакетами («HELLO») со своими ближайшими соседями. Несомненно, что эти пакеты являясь служебным траффиком, засоряют составную сеть, но не в такой степени как RIP-пакеты, поскольку пакеты «HELLO» имеют куда меньший объем. Примером протокола маршрутизации из TCP/IP, работа которого основана на использовании алгоритма состояния связей (LSA) является протокол OSPF .

Конец работы -

Эта тема принадлежит разделу:

Типы компьютерных сетей

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

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

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Твитнуть

Все темы данного раздела:

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

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

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

Сетевые протоколы физического и канального уровней OSI
Мир сетей обязан своим успехом развитию стандартов, а в частности тех стандартов, разработанных международным институтом по электричеству и технологии IEEE (Institute of Electrical

Стандарт IEEE 802.3 и строение сетей Ethernet
Стандарт IEEE 802.3 реализован в таком числе вариантов, что для их различия была введена система обозначений – название спецификаций стандарта состоит из 3 частей: 1. Число

Стандарт 10BASE5
………………………………. Узел сети (рабочая станция/сервер) подключается к толстому коаксиалу RJ-11/RJ-8 при помощи приемо-передатчика – трансивера. Трансивер устанавливается непосре

Стандарт 10Base2
Указанный стандарт использует в качестве передающей среды коаксиальный кабель с диаметром центрального медного провода 0,89мм и внешним диаметром 5мм (0,5дюйма – «тонкий» Ethernet).

Стандарт 10BaseT
Сети 10BaseT используют в качестве среды передачи две не экранированные витые пары. Unshielded Twisted Pair, UTP, много парный витой кабель на основе витой пары медный, в отличие от

Физический уровень технологии Token Ring
Стандарт Token Ring фирмы IBM предусматривает построение связей в сети с помощью концентраторов, называемых MAU (Multistation Access Unit), т.е. устройствами многостанционного доступа. В общ

Физический уровень технологии Fast Ethernet
Все отличия технологии Fast Ethernet от Ethernet сосредоточены на физическом уровне. Подуровни MAC и LLC модели OSI остались без изменений. Физический уровень технологии Fast Ethernet использует 4

Построение сегментов Fast Ethernet при использовании повторителей
В качестве устройства DTE (Data Terminal Equipment) может выступать любой источник кадров данных для сети: сетевая карта узла сети (устройства DTE), порт моста, пор

Технология 100VG-AnyLan
Кадры данных передаются одновременно по кабелям UTP Cat3, причем, в каждой паре 25 Мбит/с (в сумме 4х25 = 100 Мбит/с). В отличии от Fast Ethernet, в данных сетях нет коллизий

Высокоскоростная технология Gigabit Ethernet
Основная идея стандарта стоит в максимальном сохранении идеи классической технологии Ethernet при достижении скорости передачи 1 000 Мбит/с, поэтому в данной технологии сохранены вс

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

Отказоустойчивость технологии FDDI
Для реализации отказоустойчивости создаются 2 оптоволоконных кольца: первичное и вторичное. Если узел сети одновременно подключен к двум кольцам, то это называется двойным п

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

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

Уровень сетевого протокола
Сетевой протокол извлекает из пакета содержимое его заголовка (заголовок сетевого уровня) и анализирует содержимое его полей. Проверяется его контрольная сумма и если пакет пришел поврежденным, то

Уровень межсетевого взаимодействия
… С помощью спец пакетов протокол SCNP сообщает о невозможности доставки пакета, о превышении TTL или продолжительности сборки из пакетов. протокол SCNP использует IP в качестве транспорта

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

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

Уровень сетевых интерфейсов
Идеологическим отличием архитектуры TCP/IP от многоуровневой организации других стеков является интерпретация функций самого нижнего уровня – уровня сетевых интерфейсов. Сеть TCP/IP должна иметь ср

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

Типы адресов стека TCP/IP
В стеке TCP/IP используют 3 типа адресов: · Локальные (аппаратные, физические), IP-адреса и символьные доменные имена В контексте TCP/IP под локальным понимается такой тип адреса,

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

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

Структуризация подсети с использованием масок одинаковой длины
Пусть для IP-сети класса «B» 129.44.0.0 сисадмин выбрал маску 255.255.192.0 . После представления IP-адреса сети в двоичном виде и наложении на адрес сети, число двоичных разрядов, интерпретируемых

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

Суть технологии CIDR
Каждому поставщику интернета должен назначаться непрерывный пул (диапазон) в пространстве IP-адресов. При таком подходе адреса сетей для каждого поставщика услуг имеют общую старшую

МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ

Курсовая работа

по дисциплине «Локальные Вычислительные Сети»

на тему

«Внутренние протоколы маршрутизации RIP и OSPF »

Назначение

Протокол маршрутизации RIP (Routing Information Protocol) относится к алгоритмам класса «distance vector» (алгоритм Белмана-Форда). Этот алгоритм является одним из первых алгоритмов маршрутизации, которые были использованы в информационно – вычислительных сетях вообще и в сети Internet – в частности. Однако он до сих пор чрезвычайно распространен в вычислительных сетях. Помимо версии RIP для сетей TCP/IP, существует также версия RIP для сетей IPX/SPX компании Novell.

Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей. Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC UNIX (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. С 1988 года RIP был повсеместно принят производителями персональных компьютеров для использования в их изделиях передачи данных по сети.

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

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

RIP работает на основе UDP‑протокола и использует порт 520. На каждом хосте, использующем RIP, должно быть установлено программное обеспечение, обрабатывающее RIP‑пакеты. Настроить работу протокола на маршрутизаторе можно с помощью того же HyperTerminal с рабочей станции, имеющей на это право и доступ. Настройки производится с помощью команд в соответствии с документацией к маршрутизатору.

Пример корректной работы протокола

(на рисунке: маршрутизаторы 1-6, сегменты сетей A..F; приведена изначальная информация в маршрутизаторе 2 и информация в нем после двух итераций обмена маршрутными пакетами RIP; после определенного числа итераций маршрутизатор будет знать о расстояниях до всех сегментов, а также альтернативные маршруты)

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

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

Пример неустойчивой работы по протоколу (отслеживание изменений в топологии)

(на рисунке: маршрутизаторы M1..M3; при работоспособном состоянии в таблице маршрутов каждого маршрутизатора есть запись о сети 1 и о соответствующем расстоянии до нее; далее рассмотрим случай обрыва линии связи между сетью 1 и маршрутизатором M1).

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

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

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

Пример неустойчивой работы по протоколу (возникновение циклических маршрутов – процедура splithorizon).

В исходном состоянии все каналы передачи данных функционируют нормально и, поэтому, маршруты из узлов D и C к сети N лежат через маршрутизатор B и имеют метрику 2.

Предположим, что в некоторый момент времени канал, который связывает маршрутизаторы A и В, выходит из строя. Маршрутизатор B в этом случае перестает принимать update для сети N от маршрутизатора A и по истечении установленного интервала времени маршрутизатор B определяет сеть N в качестве недостижимой и исключает её из своих массивов update.

Однако из-за того, что эти массивы передаются в сети асинхронно вполне возможно, что вскоре после этого маршрутизатор C получит массивов update от маршрутизатора D, который пока ещё считает, что маршрут из B до сети N существует. Получив такую информацию, маршрутизатор C включит в свою таблицу маршрутизации новый маршрут до сети N – через маршрутизатор D с метрикой 3. После того, как истечет время существования исходного маршрута в маршрутизаторе D, эта ситуация повторится совершенно аналогичным образом.

В результате маршрутизатор D скорректирует свою таблицу маршрутизации и внесет в неё маршрут до сети N через шлюз C с метрикой 4. Подобная ситуация будет таким образом возобновляться снова и снова с периодом, который соответствует времени существования маршрута (3 T Update). Этот цикл, который называется «счет до бесконечности», будет продолжаться до тех пор, пока метрика циклического маршрута не достигнет значения 15, после чего он разорвется автоматически.

Правило split horizon (предотвращение возникновения циклических маршрутов)

Алгоритм split horizon является неотъемлемой частью протокола маршрутизации RIP и предназначен для предотвращения появления циклических маршрутов в сети. Для предотвращения возникновения подобных ситуаций достаточно использовать следующее правило:

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

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

Правило split horizon with poisoned reverse

Правило split horizon может быть использовано с незначительной модификацией. Правило split horizon with poisoned reverse «расщепленный горизонт с отравленным обратным путем» – разрешает передачу update для потенциально опасных, с точки зрения возникновения циклов, маршрутов. В данном случае для таких маршрутов устанавливается метрика, которая соответствует бесконечности – 15.

Пример неустойчивой работы по протоколу (процедура triggeredupdate – управляемые модификации)

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

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

Использование процедуры Split horizon не сможет предотвратить появление такой петли, поскольку сообщения о маршруте поступают не от того маршрутизатора, которому передаются сообщения update. Следовательно, эта петля будет разорвана только тогда, когда метрика циклического маршрута достигает бесконечности. Для того чтобы уменьшить время переходных процессов в сети, можно использовать процедуру управляемых модификаций ( triggered update ).

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

Пример неустойчивой работы по протоколу
(счетчик времени timeout – timer)

Возможно возникновение ситуации, когда периодическое обновление будет просто потеряно в сети из-за возникновения краткосрочной перегрузки или временной неработоспособности канала передачи данных. Для того чтобы в этой ситуации маршруты не были ошибочно удалены из таблицы маршрутизации, каждому маршруту ставится в соответствие специальный счетчик времени, который называется timeout – timer . В тот момент времени, когда данный маршрут включается в таблицу маршрутизации, или когда для него приходит очередное обновление значение счетчика timeout – timer устанавливается равным T timeout max. = 180 секунд и этот счетчик начинает обратный отсчет времени. В том случае, если счетчик timeout – timer какого либо маршрута достигнет значения 0, этот маршрут должен быть исключен из числа активных маршрутов.