Просмотр исходного текста страницы On-Demand маршрутизация

== Резюме ==
*Статические маршруты необходимо конфигурировать и обновлять в ручную при изменении топологии.
*Недостаток динамических протоколов, что они используют полосу пропускания и ресурсы маршрутизатора (память и процессор).
*Динамическая маршрутизация может быть требовательна к ресурсам.
*Третий путь - использовать Cisco On-Demand Routing (ODR)
*ODR использует миньше ресурсов в сравнении с протоколами динамической маршрутизации и требует меньше ручного конфигурирования, чем статические маршруты.
*Подходит для использования '''только''' в топологии hub-and-spoke (каждый spoke примыкает только к hub).
*ODR использует протокол [[CDP]] для передачи маршрутной информации между маршрутизаторами spoke (или, как его ещё называют, stub) и hub.
*Цетральный маршрутизатор (hub) рассылает spoke'ам стандартный маршрут, указывающий на него самого и вносит в свою таблицу маршрутизации информацию о stub-сетях, которые ему сообщил ODR (Центральный маршрутизатор может затем быть сконфигурирован для редистрибьюции маршрутов ODR в какой-либо [[динамическая маршрутизация | динамический протокол маршрутизации]]). То есть, другими словами, в таблице маршрутизации каждого spoke содержаться только его напрямую подключённые сети и статический маршрут, полученный по ODR от центрального маршрутизатора.
*Поддерживает [[VLSM]]
*Обновления [[CDP]] рассылаются [[multicast|мультикастом]]. Используются SNAP-фреймы. Стандартный интервал рассылки 60 сек (настраивается командой '''cdp timer''').
*Не является, в полном смысле слова, протоколом маршрутизации.
*Конфигурируется
**CDP на всех маршрутизаторах должен быть включён (должен быть запущен на линках между центральным и spoke-маршрутизаторами);
**На центральном должен быть запущен глобальной командой '''router odr''';
**На stub-маршрутизаторах не должна быть запущена маршрутизация.
**(Опционально) команда '''timers basic''' { ''update'' | ''invalid'' | ''holddown'' | ''flush'' | ''sleeptime'' } для настройки таймеров ODR.
*В таблице маршрутизации помечается буквой '''o''', имеет [[административная дистанция | административную дистанцию]] 160.
*Не сообщает [[метрика|метрику]] маршрута (на центральном маршрутизаторе всегда '''1''' хоп до spoke).

== Подробно ==
ODR (On Demand Routing) - проприетарном решении Cisco, которое позволяет решать проблемы маршрутизации в некоторых специфических случаях без применения протоколов внутренней маршрутизации, таких как RIP/OSPF/ISIS/EIGRP.
Фактически ODR не протокол маршрутизации, это расширение CDP для переноса ограниченной маршрутной информации. Как известно формат CDP пакета базируется на TLV подходе, т.е. каждая "порция" информации представлена в виде трех полей: Type, Lenght, Value. Тип указывает, что именно передается, длина указывает как много информации передается (включая и поля Type и само поле Lenght), Value содержит собственно информацию. Подобный подход применяется для передачи IPv4 опций, TCP опций, DHCP/BOOTP опций и т.д., преимущество такого подхода вместо фиксации в заголовке полей для передачи каждого типа информации в том, что TLV подход, во-первых, легко расширяем, т.е. можно легко добавить новые опции, во-вторых, если получатель не поддерживает какой-то Type, то базируясь на поле Lenght может просто пропустить такую опцию и начать декодировать следующую, а в-третьих такой подход экономнее, так как обычно конкретный пакет CDP (как и DHCP к примеру), содержит далеко не все возможные поля.
Для функционирования ODR Cisco добавила в CDP новый Type (0х00 07), с помощью которого маршрутизаторы могут весьма специфическим способом, о котором сейчас пойдет речь, ограниченно обмениваться маршрутами. В этом смысле ODR действительно не протокол маршрутизации, а всего лишь один из возможных TLV в CDP сообщении, кроме того, как станет ясно ниже, слова "весьма специфическим" и "ограничено" выделены не зря: полноценного обмена маршрутами, как в классических IGP, ODR не позволяет. 
Область применения ODR весьма ограничена, вы можете применить эту технологию только в hub-and-spoke топологии, причем spoke маршрутизаторы должны быть строго тупиковыми, иными словами не должны иметь никаких других линков с маршрутизаторами за исключением линков в хабом/хабами. Ответ на вопрос "почему только в этой ситуации" крайне прост :) достаточно понять, как работает технология, что мы сейчас и сделаем.
В качестве примера рассмотрим топологию, представленную на рисунке:

[[Файл:OnDemand_topology.png|center|]]

Изначально таблица маршрутизации Hub содержит информацию о подключенных сетях и не содержит сведений о loopback на маршрутизаторах SpokeA и SpokeB, для того, чтобы соответствующие маршруты оказались в таблице маршрутизации Hub, нужно либо запустить IGP между маршрутизаторами, либо настроить статическую маршрутизацию. Соответственно, таблица маршрутизации spoke также содержит только сведения о подключенных сетях, в частности SpokeA не имеет маршрутов к loopback SpokeB и линку между Hub и SpokeB.

 Hub>sh ip route 
 Gateway of last resort is not set
     192.168.0.0/30 is subnetted, 2 subnets
 C       192.168.0.0 is directly connected, Serial1/0
 C       192.168.0.4 is directly connected, Serial1/1

 SpokeA#sh ip route 
 Gateway of last resort is not set
      192.168.0.0/30 is subnetted, 1 subnets
 C       192.168.0.0 is directly connected, Serial1/0
 C    192.168.1.0/24 is directly connected, Loopback0
 C    192.168.2.0/24 is directly connected, Loopback1

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

 Router(config)#router odr
 Router(config-router)#network 192.168.0.0

Первая команда переводит консоль в режим конфигурирования ODR, а вторая команда указывает (как это принято в OSPF/EIGRP/ISIS/RIP) интерфейсы, на которых должен стартовать ODR. Посмотрим теперь, как выглядит пакет CDP, посылаемый Hub:

[[Файл:cdp1.jpg|center|250px|]]

Через интерфейс s1/0 Hub посылает CDP сообщение с TLV "ODR Default gateway", чем сообщает spoke, что для него маршрутом по умолчанию является адрес 192.168.0.1, аналогично через интерфейс s1/1 будет послано подобное сообщение, но адрес будет 192.168.0.5. Как видим, Hub не сообщает spoke точные маршруты, вместо этого передает только информацию о шлюзе по умолчанию. 
Что нужно сделать на Spoke, чтобы активировать ODR, и, тем самым принять передаваемый маршрут по-умолчанию? НИЧЕГО! На Spoke ВООБЩЕ ничего не нужно делать, получение CDP пакета с Типом 0х00 07 автоматически активирует на маршрутизаторе ODR. Но! При этом на spoke должно выполняться следующее условие (разумеется, помимо поддержки ODR):  на spoke не должно быть настроено никаких протоколов маршрутизации, настройка любого протокола маршрутизации на spoke автоматически отключает ODR. 
SpokeA, получая показанный выше CDP пакет, добавляет в свою таблицу маршрутизации запись о маршруте по умолчанию:

 SpokeA#sh ip route 
 Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
     ..................
        o - ODR, P - periodic downloaded static route
  
 Gateway of last resort is 192.168.0.1 to network 0.0.0.0
      192.168.0.0/30 is subnetted, 1 subnets
 C       192.168.0.0 is directly connected, Serial1/0
 C    192.168.1.0/24 is directly connected, Loopback0
 C    192.168.2.0/24 is directly connected, Loopback1
 o*   0.0.0.0/0 [160/1] via 192.168.0.1, 00:00:31, Serial1/0

Отметим, что код записи в таблице маршрутизации o - ODR (не путать с O - OSPF). 
Ясно, маршрута у spoke устройств недостаточно, помимо этого Hub должен от каждого Spoke получить маршруты в подключенные сети spoke. Рассмотрим, как это происходит. 
Когда spoke получает CDP пакет с опцией типа 0х00 07 (и spoke поддерживает ODR + не имеет настроенных протоколов маршрутизации), он в свою очередь тоже включает в свои сообщения опцию с тем же типом, но формат поля Value в этой опции отличается от того, который использует Hub. 
Hub, как мы видели выше, в качестве данных в опции указывает 4-х байтовое значение собственного IP адреса, который следует использовать для маршрутизации по умолчанию. 
Spoke в качестве данных передает некоторое количество 5-ти байтовых порций данных, каждая из которых состоит из 4-х байтового номера сети, подключенной (это очень важно!) к spoke и однобайтового префикса этой сети. В нашем примере таких 5-ти байтовых порций SpokeA передает 2, по количеству подключенных loopback:

[[Файл:cdp2.jpg|250px|center|]]

Таким образом в этом CDP пакете SpokeA сообщил Hub о том, что через этот spoke (т.е. через Source IP address в этом CDP пакете) можно отправлять пакеты в сети 192.168.1.0/24 и 192.168.2.0/24. После получения такого пакета, таблица маршрутизации Hub принимает следующий вид:

  Hub>sh ip route 
  Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ..................
         o - ODR, P - periodic downloaded static route
  
  Gateway of last resort is not set
  
       192.168.0.0/30 is subnetted, 2 subnets
  C       192.168.0.0 is directly connected, Serial1/0
  C       192.168.0.4 is directly connected, Serial1/1
  o    192.168.1.0/24 [160/1] via 192.168.0.2, 00:00:22, Serial1/0
  o    192.168.2.0/24 [160/1] via 192.168.0.2, 00:00:22, Serial1/0

Как видно из иллюстрации, у Hub появляются точные записи о маршрутах сообразно количеству объявлений в CDP пакете, посланном spoke. Если сконфигурировать и SpokeB, то таблица маршрутизации Hub примет окончательный вид:

  Hub>sh ip route 
  Gateway of last resort is not set
       192.168.0.0/30 is subnetted, 2 subnets
  C       192.168.0.0 is directly connected, Serial1/0
  C       192.168.0.4 is directly connected, Serial1/1
  o    192.168.1.0/24 [160/1] via 192.168.0.2, 00:00:49, Serial1/0
  o    192.168.2.0/24 [160/1] via 192.168.0.2, 00:00:49, Serial1/0
  o    192.168.3.0/24 [160/1] via 192.168.0.6, 00:00:17, Serial1/1
  o    192.168.4.0/24 [160/1] via 192.168.0.6, 00:00:17, Serial1/1

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

Подведем итоги:
* У всех маршрутизаторов сформированы таблицы маршрутизации, позволяющие полноценно обмениваться трафиком
* У Spoke маршрутизаторов в таблицах маршрутизации присутствуют только маршруты по-умолчанию
* У Hub в таблице присутствуют точные маршруты ко всем удаленным сетям
* Никаких настроек spoke маршрутизаторов вообще не нужно для работы ODR


[http://net-itstep.blogspot.com/2011/09/cisco-ondemand-routing.html Источник]