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 рассылаются мультикастом. Используются 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 маршрутизаторы должны быть строго тупиковыми, иными словами не должны иметь никаких других линков с маршрутизаторами за исключением линков в хабом/хабами. Ответ на вопрос "почему только в этой ситуации" крайне прост :) достаточно понять, как работает технология, что мы сейчас и сделаем. В качестве примера рассмотрим топологию, представленную на рисунке:
Изначально таблица маршрутизации 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:
Через интерфейс 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:
Таким образом в этом 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
