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»).

Как уже писалось выше, 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.

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

• Type – 0x0007
• Length – длинна всей опции, зависит от объема передаваемых данных.

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

• Value – IP адрес шлюза, или набор сетей, в зависимости от того в каком направлении отправляется пакет.

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

Рисунок 2-3. Пример захваченного анализатором трафика кадра CDP c опцией 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 не обладает встроенными средствами безопасности (шифрование, цифровая подпись), что не очень хорошо влияет на его репутацию и ограничивает область применения.

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

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

• Update
• Invalid
• Holddown
• Flush
• Sleep Time (не обязательный параметр)

При анализе вывода команды 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) с момента получения предыдущего, маршруты снова появляются в таблице маршрутизации.
Таким образом можно сделать следующие выводы:

• Значение параметра Update, которое в других протоколах динамической маршрутизации влияет на период рассылки объявлений, косвенно влияет на расчет таймеров invalid и flush, и должно быть не меньше таймера рассылки объявлений протокола CDP, что бы исключить преждевременное удаление маршрутной информации из таблицы маршрутизации
• Значение параметра Invalid, работает так же как и в других протоколах динамической маршрутизации и определяет период времени если по истечению которого для определенной сети не приходит обновление, она помечается как «возможно недостижимая» (possibly down). Должен быть больше чем update, рекомендовано в три раза, чтобы даже если три подряд обновления потеряются, так как они передаются без гарантии доставки, маршрут не считался недостижимым.
• Значение параметра Flush, работает так же как и в других протоколах динамической маршрутизации и определяет период времени если по истечению которого для определенной сети не приходит обновление, она считается недостижимой и удаляется из таблицы маршрутизации. Должен быть больше чем invalid, хотя бы на один интервал периода рассылки обновлений.

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

• update: 60
• invalid: 180
• holddown: 0
• flush: 240
• sleeptime: 0

В некоторых случаях может возникнуть ситуация в которой на некоторое время будет необходимо исключить определенную сеть, принадлежащую удаленным маршрутизаторам из таблицы маршрутизации центрального маршрутизатора.
Это можно сделать, например, отключив интерфейс или протокол 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 не работает. Собственно, центральный маршрутизатор рассылает только маршрут по умолчанию, поэтому фильтровать особо и нечего.

Говорить о взаимодействии протокола 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 происходит аналогичным способом.

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

• maximum-paths – изменяет количество маршрутов, инсталлируемых в таблицу маршрутизации при наличии нескольких путей. По умолчанию значение равно четырем. Может быть изменено в диапазоне от 1 до 6.

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

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

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

• Distance – изменяет административное расстояние.

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

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

• default – команда установки какого-либо параметра в значение по умолчанию. Фактически идентична отмене настроек с помощью приставки no.

• passive-interface – не влияет на работу.
• redistribute – не имеет смысла, так как удаленным маршрутизаторам передается маршрут по умолчанию, и импортировать что-либо из других протоколов бессмысленно
• network – не влияет на работу.
• neighbor – не имеет смысла, CDP сообщения рассылаются на канальном уровне, задавать соседей на сетевом уровне бессмысленно.
• default-metric – не имеет смысла, так как влияет только на перераспределенные маршруты из других протоколов, а это перераспределение не работает.

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

• Работает только на устройствах Cisco, так как является проприетарным.
• Работает поверх протокола CDP и практически не нагружает линии дополнительным трафиком.
• Работает только в топологии «звезда» («hub-and-spoke»).
• Требует минимальной конфигурации – включается командой router odr на центральном маршрутизаторе.
• Обязательным условием работы является отсутствие других протоколов динамической маршрутизации на удаленных маршрутизаторах.
• Обрабатывает только подключенные маршруты, статические маршруты не обрабатываются.
• Нет встроенных средств безопасности.
• Возможно ограниченное управление рассылками маршрутов.
• Изученные сети можно передавать в другие протоколы маршрутизации.
• Управление таймерами также может потребовать изменения настроек протокола CDP.

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

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

Автор: IDEAcademy

Источник