Что такое odr протокол

ODR – On-Demand Routing

1. Введение в ODR – On-Demand Routing

2. Принцип работы ODR

Устройство (маршрутизатор или коммутатор) регулярно рассылает на групповой MAC адрес 01-00-0c-cc-cc-cc специальные CDP (Cisco Discovery Protocol) сообщения. По умолчанию это происходит каждые 60 секунд. Если устройство, понимающее этот протокол получает подобное сообщение, оно заносит информацию, находящуюся в нем в специальную таблицу, и считает отправителя этого сообщения своим «CDP соседом». Если от соседа не поступают сообщения в течении трехкратного интервала рассылки, то информация о нем из этой таблицы удаляется. Таймеры рассылки и удаления настраиваются, о них вы можете почитать в курсе, посвященном CDP протоколу.
Основная цель протокола CDP – дать возможность устройствами, находящимся в одной канальной сети получать информацию друг о друге, даже если на сетевом уровне используются разные протоколы.
Протокол CDP обеспечивает передачу информации в виде TLV (Type/Length/Value — тип/длина/значение) блоков. То есть поле данных имеет переменную длину и зависит от типа и количества TLVблоков включенных в сообщение. При этом возможны ситуации, когда устройства, например в силу разных дат изготовления, «знают» разный набор TVL блоков. Но это не мешает устройствам нормально взаимодействовать, так как формат этих блоков стандартен, и если приходит блок с неизвестным полем «Тип» (Type), то основываясь на поле «Длина» (Length) можно просто пропустить поле «Значение» (Value) и перейти к следующему блоку.
Пример CDP кадра отображен на рисунке 2-1.
Рисунок 2-1. Пример захваченного анализатором трафика кадра CDP.

3. Настройка ODR

Обратите внимание на то, что маршрутизаторы не считают эти интервалы с точностью до секунды, это очевидно было бы слишком ресурсоемко. В системе есть таймер, который «тикает» в соответствии с интервалом рассылки сообщений, по умолчанию раз в минуту. И маршрутизатор просто считает три таких «тика» для того чтобы понять что CDP сообщение было пропущено три раза. И в зависимости от того в какой момент было получено последнее CDP сообщение относительно ближайшего «тика» мы получим задержку чуть большую чем 180 секунд, или приближающуюся к 240 секундам.
Данный вывод был получен путем изучения времени реакции системы на получение CDP сообщений в связке с протоколом ODR, учитывая то, что и операционная система, и эти протоколы носят проприетарный, закрытый характер, информация о точных алгоритмах обработки отсутствует. Вполне может оказаться что на других версиях IOS все будет по-другому.
Не отчаивайтесь, по большому счету это не так принципиально, но данный вариант реализации весьма интересен, особенно учитывая, что идея «тиков» не уникальна и применяется во многих операционных системах.

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

4. Таймеры ODR

Здесь так же маршрутизатор не считает секунды. Исходя из результатов экспериментов можно заключить следующее – он запускает таймер который «тикает» раз в несколько секунд, продолжительность тика определяется параметром Update. Затем система берет целое количество «тиков» входящее в интервал Invalid, и ожидает пока они пройдут. Учитывая, что таймер «тиков» не синхронизирован с приходом CDP сообщений, то и получается, что реально проходит чуть большее время от момента получения последнего CDP сообщения до срабатывания таймера Invalid.

5. Фильтрация маршрутов в ODR

ACL – Access Control List, в этом курсе мы не будем подробно разбирать синтаксис и особенности применения списков доступа, о них вы можете почитать более подробно в курсе посвященном настройке системы безопасности на устройствах Cisco).

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

6. Взаимодействие с другими протоколами маршрутизации.

При необходимости можно также определить фильтр перераспределения в OSPF, применив к команде redistribute маршрутные карты (route-map), о них вы можете почитать в курсе посвященном оптимизации маршрутизации.

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

7. Дополнительная настройка ODR

8. Итоги.

Источник

Что такое административное расстояние?

Параметры загрузки

Об этом переводе

Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.

Содержание

Введение

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

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

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

Основы процесса маршрутизации. См. Основы маршрутизации в Руководстве Internetworking Technologies.

Используемые компоненты

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

Условные обозначения

Выбор оптимального маршрута

Если источник информации от IGRP будет потерян (например, при выключении питания), то ПО будет использовать сведения от OSPF до тех пор, пока информация от IGRP не появится снова.

Таблица значений расстояния по умолчанию

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

* Если административное расстояние равно 255, маршрутизатор не верит источнику этого маршрута и не устанавливает маршрут в таблицу маршрутизации.

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

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

В следующем примере рассматриваются два маршрутизатора (R1 и R2), соединенные через сеть Ethernet. Интерфейсы обратной связи маршрутизаторов также объявляются при помощи RIP и IGRP на обоих маршрутизаторах. Из таблицы маршрутизации видно, что маршруты IGRP имеют приоритет по сравнению с маршрутами RIP, так как административное расстояние для них равно 100.

Для того, чтобы маршрутизатор предпочитал маршруты RIP, а не IGRP, настройте команду distance для R1 следующим образом:

Теперь взгляните на таблицу маршрутизации. Она должна отображать предпочтение маршрутизатором маршрутов RIP. Маршрутизатор получает маршруты RIP с административным расстоянием 90, хотя значение по умолчанию равно 120. Обратите внимание, что новое значение административного расстояния относится только к процессу маршрутизации одного маршрутизатора (в данном случае R1). Таблица маршрутизации R2 по-прежнему содержит маршруты IGRP.

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

Другие применения административного расстояния

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

Например, предположим, что используется таблица маршрутизации от R1. Однако в этом случае существует также линия ISDN, которая применяется в качестве резервной при сбое основного соединения. Вот пример плавающего статического маршрута для данного маршрута:

При сбое или ручном отключении интерфейсов Ethernet в таблицу маршрутизации прописывается плавающий статический маршрут. После этого весь трафик, предназначенный для сети 10.0.0.0/8, маршрутизируется из интерфейса Dialer 1 по резервному каналу. Таблица маршрутизации после сбоя выглядит примерно следующим образом:

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

Источник

ODR – On-Demand Routing

1. Введение в ODR – On-Demand Routing

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

В принципе нельзя сказать что эти недостатки существенны в современных условиях. Навряд ли сети будут переконфигурироваться часто, современные каналы связи достаточно широки, что бы без проблем передавать относительно небольшой трафик, генерируемый протоколами маршрутизации. И даже проблему внешних динамических IP адресов, получаемых от провайдера можно решить путем использования технологии динамического DNS.
Но на самом деле есть еще один недостаток, общий для обоих вариантов – вам нужен обслуживающий персонал в каждой точке, где стоит маршрутизатор. Тот, кто будет прописывать статические маршруты или настраивать протокол динамической маршрутизации.
Именно для таких случаев компания Cisco разработала проприетарный протокол ODR, который по сути даже не является протоколом динамической конфигурации, это расширение еще одного проприетарного протокола – CDP. С помощью протокола ODR маршрутизаторы могут обмениваться маршрутной информацией специфическим образом (в результате объем передаваемой информации существенно меньше, чем у других протоколов динамической маршрутизации), и при этом конфигурация всех маршрутизаторов сети не требуется. Настраивается только один маршрутизатор – основной маршрутизатор компании, все остальные маршрутизаторы не требуют вообще никакой настройки маршрутизации, ни статической, ни динамической.
Таким образом, получается, что ODR не обладает выше указанными недостатками:

Однако есть у ODR и недостаток, точнее ограничение – он может быть применен только в топологии «звезда» (в английской литературе часто применяется термин «hub-and-spoke»). То есть если от центрального маршрутизатора сети филиалов удалены не больше чем на один хоп (прыжок). В более сложных топологиях этот протокол не работает. Пример такой топологии приведен на рисунке 1-1. Маршрутизатор R1 является центральным маршрутизатором («hub»), маршрутизаторы R2 и R3 являются маршрутизаторами удаленных филиалов («spoke»).
Рисунок 1-1. Сеть с топологией «звезда» («hub-and-spoke»).

2. Принцип работы ODR

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

Устройство (маршрутизатор или коммутатор) регулярно рассылает на групповой MAC адрес 01-00-0c-cc-cc-cc специальные CDP (Cisco Discovery Protocol) сообщения. По умолчанию это происходит каждые 60 секунд. Если устройство, понимающее этот протокол получает подобное сообщение, оно заносит информацию, находящуюся в нем в специальную таблицу, и считает отправителя этого сообщения своим «CDP соседом». Если от соседа не поступают сообщения в течении трехкратного интервала рассылки, то информация о нем из этой таблицы удаляется. Таймеры рассылки и удаления настраиваются, о них вы можете почитать в курсе, посвященном CDP протоколу.
Основная цель протокола CDP – дать возможность устройствами, находящимся в одной канальной сети получать информацию друг о друге, даже если на сетевом уровне используются разные протоколы.
Протокол CDP обеспечивает передачу информации в виде TLV (Type/Length/Value — тип/длина/значение) блоков. То есть поле данных имеет переменную длину и зависит от типа и количества TLVблоков включенных в сообщение. При этом возможны ситуации, когда устройства, например в силу разных дат изготовления, «знают» разный набор TVL блоков. Но это не мешает устройствам нормально взаимодействовать, так как формат этих блоков стандартен, и если приходит блок с неизвестным полем «Тип» (Type), то основываясь на поле «Длинна» (Length) можно просто пропустить поле «Значение» (Value) и перейти к следующему блоку.
Пример CDP кадра отображен на рисунке 2-1.
Рисунок 2-1. Пример захваченного анализатором трафика кадра CDP.

При передаче данных от центрального маршрутизатора длинна данных всегда равна 4 байта – IP адрес, который удаленный маршрутизатор должен использовать как шлюз по умолчанию, как следствие вся опция будет длинной 8 байт. Пример такой опции показан на рисунке 2-2.
При передаче данных от удаленного маршрутизатора длинна данных переменная, в сообщении передаются номера одной или нескольких сетей, подключенных к этому маршрутизатору в формате «4 байта IP адрес, и 1 байт маска». Эти сети центральный маршрутизатор добавит себе в таблицу маршрутизации. В результате длинна всей опции будет равна – 4+N*5 (где N – количество сетей подключенных к удаленному маршрутизатору, за исключением той сети, с помощью которой он связывается с центральным). Пример такой опции показан на рисунке 2-3.

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

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

3. Настройка ODR

В первую очередь не следует забывать о том, что ODR работает поверх CDP, и он должен быть включен на всех маршрутизаторах (команда cdp run в режиме глобальной конфигурации).
Включение On-Demand Routing выполняется только на центральном маршрутизаторе путем введения команды router odr в режиме глобальной конфигурации. При этом, в отличии от других протоколов динамической маршрутизации, никаких команд более не требуется (например, network). Пример настройки протокола ODR показан на рисунке 3-1, как видно введена только одна команда router odr.
Рисунок 3-1. Пример настройки протокола ODR.

При этом центральный маршрутизатор на всех своих интерфейсах включает в CDP рассылку ODR опцию, в которой будет указываться IP адрес, который удаленные маршрутизаторы должны использовать как шлюз. Все удаленные маршрутизаторы, которые в пакетах CDP видят эту опцию, и при этом на них не настроен никакой протокол динамической маршрутизации (это обязательное условие), включают в свои CDP такую же опцию с информацией о подключенных сетях (кроме той, которая принадлежит интерфейсу, через который эти объявления рассылаются).
Рисунок 3-2. Таблица маршрутизации центрального маршрутизатора.

В результате на центральном маршрутизаторе через некоторое время (определяется интервалом рассылки CDP пакетов) в таблицу маршрутизации добавляются записи о сетях, подключенных к удаленным маршрутизаторам. Пример таблицы маршрутизации центрального маршрутизатора приведен на рисунке 3-2.
На удаленных маршрутизаторах появляется одна дополнительная запись – маршрут по умолчанию на центральный маршрутизатор. Пример таблицы маршрутизации удаленного маршрутизатора приведен на рисунке 3-2.
Административная дистанция в обоих случаях по умолчанию равна – 160.
Метрика по умолчанию равна – 1 (что вполне логично, учитывая то, что удаленные маршрутизаторы не могут быть отдалены от центрального больше чем на один хоп).
Рисунок 3-3. Таблица маршрутизации удаленного маршрутизатора.

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

Как видно на рисунке 3-5, в таблице маршрутизации центрального маршрутизатора R1 присутствуют только сети, подключенные к ближайшим удаленным маршрутизаторам, а сеть 172.16.3.0/24, подключенная к R4, и описанная на R3 статическим маршрутом в его таблицу маршрутизации не попала.
Рисунок 3-5. Таблица маршрутизации центрального маршрутизатора содержит только «действительно подключенные» к удаленным маршрутизаторам сети.

Рисунок 3-6. Если отключить протокол CDP, то и протокол ORD работать не будет.

Естественно, так как ODR требует для своей работы CDP, то отключение последнего приводит к тому, что маршрутизаторы перестают обмениваться маршрутной информацией. На рисунке 3-6 показано, что если на удаленном маршрутизаторе (в примере на R2) отключить CDP, то он перестанет передавать маршрутную информацию (собственно он перестанет передавать всю информацию, которую раньше передавал с помощью этого протокола). Как следствие, на центральном маршрутизаторе, не будут обновляться таймеры этих сетей в таблице маршрутизации, и по истечению примерно 180 секунд маршруты будут помечены как «possibly down», а по пришествию еще 60 секунд они вовсе исчезнут из таблицы маршрутизации.

Обратите внимание на то, что маршрутизаторы не считают эти интервалы с точностью до секунды, это очевидно было бы слишком ресурсоемко. В системе есть таймер, который «тикает» в соответствии с интервалом рассылки сообщений, по умолчанию раз в минуту. И маршрутизатор просто считает три таких «тика» для того чтобы понять что CDP сообщение было пропущено три раза. И в зависимости от того в какой момент было получено последнее CDP сообщение относительно ближайшего «тика» мы получим задержку чуть большую чем 180 секунд, или приближающуюся к 240 секундам.
Данный вывод был получен путем изучения времени реакции системы на получение CDP сообщений в связке с протоколом ODR, учитывая то, что и операционная система, и эти протоколы носят проприетарный, закрытый характер, информация о точных алгоритмах обработки отсутствует. Вполне может оказаться что на других версиях IOS все будет по-другому.
Не отчаивайтесь, по большому счету это не так принципиально, но данный вариант реализации весьма интересен, особенно учитывая, что идея «тиков» не уникальна и применяется во многих операционных системах.

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

4. Таймеры ODR

Несмотря на то, что время рассылки сообщений определяется настройками CDP, можно ограниченно управлять таймерами обработки сообщений с помощью команды timers basic в режиме настройки маршрутизатора. Но тут следует помнить, что управление будет не полным, так как интервал повторной отправки данных будет зависеть только от настройки CDP, и на него невозможно повлиять с помощью команды timers basic. Важно понимать, что если задать слишком маленькие значения, без изменения таймеров CDP, то это приведет к периодическому пропаданию маршрутов из таблицы маршрутизации. Так же не стоит задавать эти значения слишком большими, так как тогда информация о недостижимых сетях будет находиться в таблицах маршрутизации слишком долго.
Как и в других протоколах динамической маршрутизации, параметры, применяемые в данный момент, и в частности таймеры протокола, можно посмотреть с помощью команды show ip protocols. Вывод данной команды отображен на рисунке 4-1.
Рисунок 4-1. Вывод команды show ip protocols для протокола ODR.

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

При анализе вывода команды show ip protocols видно, что для ODR не применим таймер Holddown, но так как по синтаксису timers basic его пропустить нельзя, указать что-то нужно, но указанное значение ни на что влиять не будет.
Также следует учитывать, что период рассылки сообщений регулируется не параметром Update, а временными настройками протокола CDP (о самом протоколе CDP в общем, и о его таймерах в частности вы сможете прочитать в курсе посвященном этому протоколу). Но в отличии от Holddown, который вообще ни на что не влияет, значение Update используется специфическим образом, ниже будет показано каким образом на примере.
Например, если мы дадим команду timers basic 5 15 25 50 (при этом вместо третьего значения мы могли написать абсолютно любое число), и при этом не будем менять свойств CDP, то период рассылки сообщений останется, как и прежде – одна минута. Это легко увидеть при анализе захваченного на интерфейсе маршрутизатора трафика показанного на рисунке 4-2.
Рисунок 4-2. Захват CDP трафика, интервал рассылки CDP кадров по умолчанию – 1 минута.

Для наглядности включим режим отладки CDP протокола и обработки таблицы маршрутизации (debug cdp packets и debug ip routing), а также отключим правый (fa0/1) интерфейс, что бы наблюдать трафик только одного интерфейса.
Рисунок 4-3. Диагностика взаимодействия протоколов CDP и ODR c помощью команды debug, этап 1.

На рисунке 4-3 видно, что при получении CDP пакета от соседа происходит добавление полученных маршрутов в таблицу маршрутизации (в 25 минут 12 (почти 13) секунд по локальному времени маршрутизатора).
Рисунок 4-4. Диагностика взаимодействия протоколов CDP и ODR c помощью команды debug, этап 2.

По истечению 19-ти секунд (рисунок 4-4) срабатывает таймер Invalid (мы задавали в команде timers basic параметр Invalid равный 15).

Здесь так же маршрутизатор не считает секунды. Исходя из результатов экспериментов можно заключить следующее – он запускает таймер который «тикает» раз в несколько секунд, длинна тика определяется параметром Update. Затем система берет целое количество «тиков» входящее в интервал Invalid, и ожидает пока они пройдут. Учитывая, что таймер «тиков» не синхронизирован с приходом CDP сообщений, то и получается, что реально проходит чуть большее время от момента получения последнего CDP сообщения до срабатывания таймера Invalid.

Система не получая обновления помечает маршруты как «possibly down» — «возможно недостижимые». Но при этом маршрутизатор продолжает успешно отправлять пакеты в эти сети.
Рисунок 4-5. Диагностика взаимодействия протоколов CDP и ODR c помощью команды debug, этап 3.

Еще через 35 секунд, в 26 минут 7 секунд (рисунок 4-5) по локальному времени маршрутизатора, система все еще не получив обновлений удаляет маршруты из таблицы маршрутизации. Это срабатывает таймер Flush, который мы устанавливали в 50 секунд (с момента последнего обновления прошло порядка 55 секунд, но тут также, как и в таймере Invalid, система считает не секунды, а «тики» таймера, в нашем случае пятисекундные, от сюда и небольшое расхождение).
Рисунок 4-6. Диагностика взаимодействия протоколов CDP и ODR c помощью команды debug, этап 4.

И наконец, получив очередное CDP обновление, ровно через минуту (рисунок 4-6) с момента получения предыдущего, маршруты снова появляются в таблице маршрутизации.
Таким образом можно сделать следующие выводы:

Значения timers basic по умолчанию:

5. Фильтрация маршрутов в ODR

В некоторых случаях может возникнуть ситуация в которой на некоторое время будет необходимо исключить определенную сеть, принадлежащую удаленным маршрутизаторам из таблицы маршрутизации центрального маршрутизатора.
Это можно сделать, например, отключив интерфейс или протокол CDP на соответствующем устройстве, но в этом случае мы полностью прекратим взаимодействие с этим устройством или потеряем все сети, подключенные к нему.
Если необходимо убрать из таблицы маршрутизации только одну сеть из нескольких, доступных через переделённый удаленный маршрутизатор такие кардинальные методы не подходят. В этом случае можно воспользоваться командой distribute-list, с помощью которой можно управлять фильтрацией маршрутов принимаемых или отправляемых в объявлениях.
Рисунок 5-1. Таблица маршрутизации центрального маршрутизатора в начале эксперимента, в ней присутствую все сети, подключенные к удаленным маршрутизаторам.

Например, мы хотим временно исключить из таблицы маршрутизации одну из сетей, подключенных к маршрутизатору R2, а именно сеть 172.16.1.0/24. На рисунке 5-1 показаны сети, присутствующие в таблице маршрутизации центрального маршрутизатора в начале эксперимента.
Команда distribute-list требует предварительно настроенного списка доступа с описанными сетями, которые можно и нельзя принимать или передавать в объявлениях.

ACL – Access Control List, в этом курсе мы не будем подробно разбирать синтаксис и особенности применения списков доступа, о них вы можете почитать более подробно в курсе посвященном настройке системы безопасности на устройствах Cisco).

Рисунок 5-2. Создание ACL.

Создание списка доступа показано на рисунке 5-2 и происходит с помощью команды access-list. В нем мы настраиваем, что будем игнорировать объявления, попадающие в диапазон 172.16.1.0/24, и будем принимать все остальные объявления.
Рисунок 5-3. Примирение созданного ACL к команде distribute-list.

После создания листа его необходимо применить distribute-list в режиме конфигурации ODR, как показано на рисунке 5-3. При этом необходимо указать направление — in (входящие объявления), а также при необходимости можно указать интерфейс, для которого будет применяться этот фильтр. Если интерфейс не указан, то фильтрация будет происходить для всех объявлений, приходящих на все интерфейсы.
Рисунок 5-4. Таблица маршрутизации центрального маршрутизатора после применения команды distribute-list.

После этого маршрутизатор перестает обрабатывать входящие объявления о сети 172.16.1.0/24, и по пришествию таймера Flush, она исчезает из таблицы маршрутизации, как показано на рисунке 5-4.

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

6. Взаимодействие с другими протоколами маршрутизации.

Говорить о взаимодействии протокола ODR с другими протоколами динамической маршрутизации имеет смысл только в плане передачи данных о сетях, подключенных к удаленным маршрутизаторам (в контексте ODR), другому протоколу, но не наоборот.
Настройка передачи маршрутной информации из ODR происходит в том протоколе динамической маршрутизации, который должен получить маршрутную информацию, с помощью команды redistribute. В качестве параметров необходимо передать название протокола, чьи маршруты нужно импортировать, в нашем случае – odr, а так же параметр subnets, если в сети присутствуют подсети классовых сетей.
Применение этой команды показано на рисунке 6-1. В режиме конфигурации протокола OSPF дается команда redistribute odr subnets, что приводит к тому, что сети, изученные центральным маршрутизатором с помощью протокола ODR импортируются протоколом OSPF в свою базу и передаются дальше в ту часть сети, которая обслуживается протоколом OSPF. На рисунке 6-1 показана таблица маршрутизации маршрутизатора R4, которые получил информацию о сетях 172.16.0.0/24 и 172.16.2.0/24 от маршрутизатора R1 по протоколу OSPF, но так как эти сети изначально были изучены ODR, а затем импортированы из него в OSPF, то для OSPF эта маршрутная информация является «не родной» и соответствующие маршруты в таблице маршрутизации помечаются символами «E2» – внешние маршруты.
Обратите внимание на то, что передавать данные в обратном направлении не имеет смысла. Маршрутная информация, собранная протоколом OSPF на центральном маршрутизаторе уже имеется, так как этот протокол запущен на нем. А удаленные маршрутизаторы, в любом случае, получают только маршруты по умолчанию. Поэтому применять команду redistribute к протоколу ODR не имеет смысла (хотя эта команда присутствует в его конфигурации), по этому, в примере конфигурации на рисунке 6-1 в конфигурации ODR команды redistribute нет.
Рисунок 6-1. Применение команды redistribute к протоколу OSPF.

В примере так же оставлен фильтр примененный к ODR, исключающий сеть 172.16.1.0/24 из обработки, и в результате на маршрутизаторе R4 в OSPF были переданы только сети 172.16.0.0/24 и 172.16.2.0/24.

При необходимости можно также определить фильтр перераспределения в OSPF, применив к команде redistribute маршрутные карты (route-map), о них вы можете почитать в курсе посвященном оптимизации маршрутизации.

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

7. Дополнительная настройка ODR

Кроме настройки таймеров, фильтрации маршрутов и взаимодействия с другими протоколами маршрутизации для ODR применимо еще несколько конфигурационных команд:

Рисунок 7-1. Протокол ORD поддерживает балансировку нагрузки.

Учитывая, что метрики всех маршрутов будут равны единице, речь не может идти о балансировке по маршрутам с разной стоимостью. Сеть и пример таблицы маршрутизации с несколькими возможными вариантами достижения одной сети показан на рисунке 7-1. Если в режиме конфигурации протокола ORD дать команду maximum-paths 1, произойдет отключение возможности балансировки нагрузки и в таблице маршрутизации останется один путь, который был изучен ранее, как показано на рисунке 7-2.
Рисунок 7-2. Отключение балансировки нагрузки установкой значения maximum-paths в единицу.

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

Рисунок 7-3. Изменение административного расстояния для протокола ODR.

Учитывая, что в CDP сообщениях административное расстояние не передается, то настройка получается локальной только для центрального маршрутизатора, на удаленных маршрутизаторах таким образом изменить административную дистанцию нельзя (команда distance дается в режиме конфигурации маршрутизатора, а команду router odr на удаленных маршрутизаторах давать нельзя, так как они перейдут в режим центрального, перестанут отправлять информацию о своих сетях, и будут игнорировать сообщения от «настоящего» центрального маршрутизатора). Пример изменения административного расстояния показан на рисунке 7-3.

8. Итоги.

И так, для тех кто дочитал до конца, можно подвести итоги по протоколу ODR:

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

EIGRP, OSPF, IPV6 и BGP следующие.
© IDE Academy

Источник