Протокол IP : Маршрутизация по запросу (ODR)

Проектирование крупных тупиковых сетей с помощью ODR

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

On-Demand Routing (ODR) – усовершенствованный вариант Cisco Discovery Protocol (CDP), протокола, используемого для обнаружения других устройств в среде, обеспечивающей или не обеспечивающей трансляцию. С помощью CDP возможно найти тип устройства, IP-адрес, Cisco версия IOS�, работающая на соседнем устройстве Сisco, возможностях соседнего устройства, и т.д. В Cisco IOS Software Release 11.2 r CDP был добавлен ODR, чтобы объявлять соединенный IP префикс шлейфа маршрутизатора через CDP. Эта характеристика принимает экстренные 5 байт для каждой сети или подсети, 4 байта для IP-адреса, и один байт для того чтобы разрекламировать <ud>маску подсети вместе с IP. ODR в состоянии перенести информацию по Variable Length Subnet Mask (VLS).

ODR была создана для розничных корпоративных клиентов, которые не хотят использовать пропускную способность сети для обновлений протокола маршрутизации. В среде X.25, например, это является часто очень дорогостоящим для выполнения протокола маршрутизации по той ссылке. Статическая маршрутизация - хороший выбор, но поддержка статических маршрутов вручную связана с большими издержками. ODR не вызывает высокой загрузки процессора и используется для динамической передачи IP-маршрутов на уровне 2.

ODR не является протоколом маршрутизации и не должен быть обработан как таковой при настройке его. Традиционные конфигурации для различных протоколов IP-маршрутизации не будут работать в ODR, так как ODR использует CDP на уровне 2. Для конфигурирования ODR используется команда router odr на центральном маршрутизаторе. Дизайн, реализация и взаимодействие ODR с другими протоколами IP-маршрутизации могут быть трудными.

ODR не будет работать на Cisco 700 series routers или по каналам ATM, за исключением эмуляции LAN (LANE).

Шлейфные и транзитные сети: сравнительный анализ

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

Маршрутизаторы начального уровня, такие как Cisco 2500, 1600 и1000, используются на стороне оконечного устройства. Если информация проходит через лучевые маршрутизаторы по пути в какую-то другую сеть, этот тупиковый маршрутизатор становится транзитным. Когда луч связан с другим маршрутизатором помимо маршрутизатора концентратора, эта конфигурация происходит.

Распространенный интерес – какой размер ODR обновления может отправить конец луча. Обычно периферийные устройства подключены только к концентратору. Если маршрутизаторы на конце луча соединены с другими маршрутизаторами, они уже не являются изолированными и становятся транзитной сетью. Коробки начального уровня обычно имеют один или два интерфейса LAN (локальной сети). Например, Cisco 2500 поддерживает два интерфейса LAN. В обычных ситуациях 10-байтный пакет посылается в составе протокола CDP (если на оконечной стороне есть две сети LAN). CDP включен по умолчанию, поэтому не возникает проблема дополнительной служебной информации. Никогда не будет ситуации, где существует большое обновление ODR. Размер обновления ODR не будет проблемой в реальных условиях звезды.

Сети с топологией звезды и ODR

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

Рис. 1: Топология звезды

odrhs.jpg

Оконечные устройства с единой точкой выхода

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

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

Оконечные устройства с несколькими точками выхода

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

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

Балансировка нагрузки или резервное копирование с одним концентратором

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

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

Примечание: Сегодня, нет никакого другого метода на стороне оконечного устройства для предпочтения одной ссылки по другому в ситуации с одним концентратором, за исключением описанного выше. При использовании IOS версии 12.0.5T или более поздней концентратор автоматически отправляет маршрут по умолчанию через оба канала, и оконечный маршрутизатор не различает два пути, поэтому заносит оба пути в таблицу маршрутизации. Единственный способ предоставить преимущество одному маршруту по умолчанию над другим - это использовать статический маршрут по умолчанию на спице, у которой есть путь с меньшим административным расстоянием. Это автоматически отвергает маршруты по умолчанию, которые прибывают в лучи через ODR. В настоящее время идея обеспечить узел, где он может предпочитать одно соединение другому, находится на этапе разработки.

Рис. 2: Краевые маршрутизаторы с несколькими точками выхода и одним концентратором

/image/gif/paws/13710/odr3.jpg

Распределение нагрузки или дублирование с использованием нескольких концентраторов

Эти конфигурации можно также использовать для распределения нагрузки или резервирования при наличии нескольких концентраторов. Если одна из ссылок от сбоев лучей, назначение может все еще быть достигнуто через второй концентратор, все концентраторы должны быть полностью пойманы в сети так, чтобы. Посмотрите ODR по сравнению с Другим разделом Протоколов маршрутизации этого документа для большего количества подробного объяснения. Точно так же в случае нескольк концентраторов, если IOS 12.0.5T или позже находится в используемом, концентраторы передают маршруты по умолчанию ODR к лучам, и лучи устанавливают обоих в таблице маршрутизации. Будущее Усовершенствование позволит лучу предпочитать один концентратор другому. В настоящее время это может быть сделано через статический маршрут по умолчанию, определенный на маршрутизаторе луча и использовании административного расстояния в команде статического маршрута для предпочтения одного концентратора по другому. Это не влияет на ситуации выравнивания нагрузки.

Рис. 3: Спицы с несколькими выходами и концентраторами

/image/gif/paws/13710/odr4.jpg

ODR по сравнению с Другие протоколы маршрутизации

Самым существенным достоинством ODR в сравнении с IP-маршрутизацией является то, что центральный маршрутизатор узнает IP-префиксы без включения протоколов маршрутизации на третьем уровне. Обновления ODR являются частью CDP на уровне 2.

Сравнение ODR и EIGRP

В реальной среде ядро-конечные устройства нет необходимости пересылать всю маршрутную информацию по всем конечным устройствам. Лучи медленного соединения тратят впустую пропускную способность в отношениях соседей поддержания и обновлениях маршрута. Если на периферийных устройствах включен протокол EIGRP, им отправляются обновления маршрутизации. В крупных сетях такие обновления становятся громоздкими, впустую тратится пропускная способность CPU и может потребоваться больше памяти на конечных маршрутизаторах.

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

Лучшим подходом является устранение служебной информации запросов EIGRP и обслуживание соседей с использованием ODR. Настройка таймеров ODR позволяет увеличить время сходимости.

Сегодня, у нас есть новая характеристика в EIGRP, который масштабирует EIGRP намного лучше в концентраторе и лучевой ситуации. Обратитесь к Маршрутизации с использованием заглушек Расширенного IGRP для получения дополнительной информации о функции EIGRP stub.

Сравнение ODR и OSPF

Протокол OSPF обеспечивает ряд параметров для среды с топологией звезды, и параметр stub no-summary является наименее затратным.

При запуске OSPF на крупномасштабных сетях с топологией "звезда" могут встретиться проблемы. В примерах данного раздела приведен Frame Relay, поскольку это наиболее распространенный пример топологии "звезда".

Шлейфные сети "точка-точка" с протоколом OSPF

В данном примере OSPF включен на 100 лучах, связанных двухточечной конфигурацией. Прежде всего, существует множество незанятых IP-адресов, даже если создается подсеть с маской сети /30. Во-вторых, если все 100 оконечных устройств включить в одну область, то при отключении одного из устройств будет запущен алгоритм SPF, который может привести к интенсивной загрузке CPU. Это достаточно реальная ситуация, особенно для оконечных маршрутизаторов, если канал постоянно перебрасывается. Большее колебание соседей может вызвать проблемы, так как маршрутизаторы спицы связаны.

В OSPF область является ответвлением, а не интерфейсом. Если в тупиковой сети существует 100 маршрутизаторов, на лучах необходимо больше памяти для хранения большой базы данных. Эту проблему можно решить, разделив большую шлейфную зону на маленькие зоны. Однако откидная створка в одной изолированной области все еще вызовет SPF для работы лучей, таким образом, эти издержки не смогут быть исправлены путем создания небольшой изолированной области без сводки и никакого externals.

Другим вариантом является добавление каждого канала в одну область. С этим параметром концентратор должен будет запускать отдельный алгоритм для каждой области и создавать сводное объявление состояния канала (LSA) для маршрутов в области. Этот параметр может ухудшить производительность центрального маршрутизатора.

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

Шлейфные многоадресные сети OSPF

В сетях "точка-многие точки" пространство IP-адресов экономится путем размещения каждого луча в одной и той же подсети. Кроме того, размер LSA-концентратора, создаваемого маршрутизатором, будет уменьшен наполовину, так как он генерирует только один тупиковый канал для всех двухточечных каналов. Сеть "точка-многие точки" приведет к включению всей подсети в одну область. В случае неполадок канала луч использует алгоритм SPF, который может потребовать интенсивной загрузки CPU.

Storm Hello

Пакеты приветствия OSPF не большие, но если соседей слишком много, их размер может стать больше. Поскольку пакеты вызова являются многоадресными, маршрутизатор обрабатывает их. Хаб OSPF передает и получает пакеты приветствия, состоявшие из 20 байтов IP - заголовка, заголовка на 24 байта OSPF, 20 байтов параметров приветствия и 4 байтов для каждого замеченного соседнего узла. Размер пакета приветствия OSPF от концентратора в сети типа "точка-много точек" со 100 соседних узлов может достигать 464 байт и лавинно передаваться на все конечные устройства каждые 30 секунд.

Таблица 1: Пакет приветствия OSPF для 100 соседних узлов

20-байтовый IP - заголовок
24-байтовый заголовок OSPF
20-байтные параметры приветствия
4 байта каждый соседний индикатор маршрутизатора (RID)
. . .
. . .
. . .
. . .
. . .

Издержки разрешаются в ODR, так как дополнительная информация не отсылается от концентратора к концам луча. Маршрутизаторы на конце луча посылают IP префикс из 5 байтов на подсеть центральному маршрутизатору. Учитывая размер тестового пакета, сравните 5 байт в ODR (информация о подключенной подсети, отправленная линией) с 68 байтами OSPF (наименьший размер тестового пакета, включая IP-заголовок, отправленный от линии в концентратор) плюс 68 байт (наименьший размер тестового пакета, отправленного из концентратора на линию) во время 30-ти секундного интервала. Кроме того, OSPF-пакеты hello наблюдаются на третьем уровне, тогда как обновления ODR – на втором. При использовании ODR отправляется гораздо меньше информации, поэтому пропускная способность канала доступна для передачи важных данных.

Сравнение ODR и RIPv2

Протокол маршрутной информации версии 2 (RIPv2) также подходит для среды топологии звезды. Для проектирования RIPv2 отправьте маршрут по умолчанию с концентратора на периферийные устройства. После этого оконечные устройства декларируют подключенные интерфейсы через RIP. RIPv2 может быть использован в случае, когда используются вторичные адреса, которые необходимо объявить, или если эта ситуация не является точной ситуацией концентратора и конечного устройства.

RIPv2 по каналу по требованию

Несмотря на некоторые изменения в версии 2, протокол не был значительно изменен. Этот раздел посвящен усовершенствованиям RIP для каналов по требованию.

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

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

Triggered RIP

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

Запущенные обновления RIP отправляются в том случае, если:

  • Получен запрос на обновление маршрутизации.

  • Получены новые данные.

  • Следующий получатель теперь находится вверх по каналу, а не вниз.

  • Маршрутизатор сначала включен.

Ниже приведен пример конфигурации синхронизируемого RIP:

Spoke# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Spoke(config)# int s0.1 
Spoke(config-if)# ip rip triggered 
Spoke(config)# int s0.2 
Spoke(config-if)# ip rip triggered 
       
interface serial 0 
encapsulation frame-relay 
       
interface serial 0.1 point            /* Primary PVC */ 
ip address 10.x.x.x 255.255.255.0 
ip rip triggered 
frame-relay interface-dlci XX 
       
interface serial 0.2 point       /* Secondary PVC */ 
ip address 10.y.y.y 255.255.255.0 
ip rip triggered 
frame-relay interface-dlci XX 

router rip 
  network 10.0.0.0 
       

Spoke# show ip protocol 
Routing Protocol is "rip" 
  Sending updates every 30 seconds, next due in 23 seconds 
  Invalid after 180 seconds, hold down 180, flushed after 240 
  Outgoing update filter list for all interfaces is not set 
  Incoming update filter list for all interfaces is not set 
  Redistributing: rip 
  Default version control: send version 1, receive any version 
    Interface        Send  Recv    Triggered RIP    Key-chain 
    Ethernet0           1        1 2 
    Serial0.1             1        1 2               Yes 
    Serial0.2             1        1 2               Yes 
  Routing for Networks: 
    10.0.0.0 
  Routing Information Sources: 
    Gateway         Distance      Last Update 
  Distance: (default is 120) 

Команда ip rip triggered должна быть настроена на интерфейсе маршрутизатора концентратора, соединяющемся с лучами.

При сравнении RIPv2 с ODR ODR является лучшим выбором, потому что RIPv2 работает на Уровень 3, и ODR происходит на Уровне 2. При отправке концентратором обновлений RIPv2 более чем 1 000 оконечных устройств необходима репликация пакетов на уровне 3 для каждого оконечного устройства. ODR ничего не пересылает с концентратора, кроме обычных обновлений CDP, передаваемых каждую минуту на уровне 2, что совсем не загружает процессор. Передача связанных данных подсети из луча на уровне 2 меньше загружает CPU, нежели передача RIPv2 на уровне 3.

Схема крупной сети с ODR

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

ODR с протоколом EIGRP, который используется для концентраторов

Во время запуска EIGRP следует присоединить пассивный интерфейс к сети с топологией звезды для того, чтобы по каналу не передавались ненужные приветственные сообщения EIGRP. Если возможно, не следует помещать сетевые инструкции для сетей между концентратором и оконечными устройствами, поскольку в случае прекращения работы канала протокол EIGRP не будет отправлять ненужные запросы основным соседям. Всегда выбирайте фиктивную сеть между концентратором и лучами, таким образом, те ссылки не будут включены в Домен eigrp, потому что вы не поместите инструкции сети в конфигурации.

Резервирование и объединение

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

При использовании нескольких концентраторов очень важно обеспечить наличие соединения между обоими концентраторами и использование между ними протокола EIGRP. Если возможно, этот канал должен представлять уникальную главную сеть, поэтому он не будет пересекаться с другими каналами, идущими на конечные устройства. Эта настройка необходима, потому что EIGRP не может быть включен на конкретном интерфейсе, так что даже если сделать интерфейс пассивным, он все же будет объявляться через EIGRP. В объединенном интерфейсе исходящие запросы отправляются даже в случае потери одного оконечного устройства. Пока ссылка между двумя концентраторами не находится в той же крупной сети как лучи, конфигурация должна работать должным образом.

Рис. 4: Резервирование и объединение: Ядро получает итоговые маршруты

/image/gif/paws/13710/odr7.jpg

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

ODR с OSPF на концентраторах

В этом сценарии OSPF не включен в канале, соединяющем лучи. В обычном сценарии, если OSPF включен на ссылке, и постоянно колеблется одна определенная ссылка, это может вызвать несколько проблем, включая выполнение SPF, регенерацию LSA маршрутизатора (локальный администратор безопасности), регенерацию суммарного объявления о состоянии каналов, и т.д. Когда рабочий ODR, не включайте связанное последовательное соединение в домен OSPF. Основная проблема должна получить информацию о сегменте LAN лучей. Эти сведения можно получить через ODR. Если один канал постоянно меняет значения таблицы маршрутизации, он не будет мешать работе протокола маршрутизации в маршрутизаторе-концентраторе.

Резервирование и объединение

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

Рис. 5: Резервирование и объединение: Основной маршрутизатор получает итоговые маршруты

/image/gif/paws/13710/odr6.jpg

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

NSSA с будущим усовершенствованием

В конце концов будет OSPF-функция Not-So-Stubby Areas (NSSA), которая позволит не только объединить маршруты в ядро, но и передавать другие особые сведения концентратора по каналу NSSA. Преимущество работающего NSSA состоит в том, что итоговые маршруты можно посылать в ядро. Затем, ядро может послать трафик на любой концентратор для достижения пункта назначения на спице. Если канал между одним из концентраторов и каким-либо оконечным узлом разорвется, в каждом из концентраторов появится уточненное объявление LSA типа 7, позволяющее достичь пункта назначения через другой концентратор.

Придерживающееся является примером конфигурации с помощью NSSA:

N2507: Hub 1 

router odr 
  timers basic 8 24 0 1 
! 
router ospf 1 
  redistribute odr subnets 
  network 1.0.0.0 0.255.255.255 area 1 
  area 1 nssa 
       

N2504: Hub 2 

router odr
  timers basic 8 24 0 1 
! 
router ospf 1 
  redistribute odr subnets 
  network 1.0.0.0 0.255.255.255 area 1 
  area 1 nssa 

N2507# show 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, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.3.0 is directly connected, Ethernet0 
o    150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
o    200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
o    200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0

N2504# show 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, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.4.0 is directly connected, TokenRing0 
C    5.0.0.0/8 is directly connected, Loopback0 
C    6.0.0.0/8 is directly connected, Loopback1 
O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0 
O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 
O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 

Краткие сведения и будущее Усовершенствование для NSSA

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

N2504# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
N2504(config)# router ospf 1 
N2504(config-router)# summary-address 200.1.0.0 255.255.0.0 
       

N2504# show ip ospf database external 
       
       OSPF Router with ID (6.0.0.1) (Process ID 1) 
       
       
                Type-5 AS External Link States 
       
  LS age: 1111 
  Options: (No TOS-capability, DC) 
  LS Type: AS External Link 
  Link State ID: 200.1.0.0 (External Network Number ) 
  Advertising Router: 6.0.0.1 
  LS Seq Number: 80000001 
  Checksum: 0x2143 
  Length: 36 
  Network Mask: /16 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 127 
        Metric: 16777215 
        Forward Address: 0.0.0.0 
        External Route Tag: 0

Проблема расстояния

В данном примере более определенная информация получена от обоих концентраторов. Так как расстояние OSPF равняется 110, и расстояние ODR равняется 160, информация вмешается в ODR, когда это будет получено от другого концентратора о той же подсети. Другой концентратор всегда будет предпочтительным для доступа к конечному получателю, что является причиной субоптимальной маршрутизации. Для исправления ситуации уменьшите расстояние ODR к меньше чем 110 с командой расстояния, так, чтобы маршрут ODR был всегда предпочтен по маршруту OSPF. Если маршрут ODR откажет, то внешний маршрут OSPF будет установлен в таблицу маршрутизации от базы данных.

N2504(config)# router odr 
N2504(config-router)# distance 100 
N2504(config-router)# end 

N2504# show 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, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.4.0 is directly connected, TokenRing0 
C    5.0.0.0/8 is directly connected, Loopback0 
C    6.0.0.0/8 is directly connected, Loopback1 
o    150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
o    200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
o    200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
O    200.1.0.0/16 is a summary, 00:04:38, Null0 

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

N2504# show ip ospf database nssa 
       
       OSPF Router with ID (6.0.0.1) (Process ID 1) 
       
       
                Type-7 AS External Link States (Area 1) 
       

  LS age: 7 
  Options: (No TOS-capability, Type 7/5 translation, DC) 
  LS Type: AS External Link 
  Link State ID: 150.0.0.0 (External Network Number ) 
  Advertising Router: 6.0.0.1 
  LS Seq Number: 80000002 
  Checksum: 0x965E 
  Length: 36 
  Network Mask: /16 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.2 
        External Route Tag: 0 

С усовершенствованием до NSSA более конкретное LSA типа 7 будет в базе данных NSSA. Вместо итогового маршрута в выходных данных базы данных отображаются следующие сведения:

LS age: 868 
Options: (No TOS-capability, Type 7/5 translation, DC) 
LS Type: AS External Link 
Link State ID: 200.1.1.0 (External Network Number) 
Advertising Router: 3.3.3.1 
LS Seq Number: 80000001 
Checksum: 0xDFE0 
Length: 36 
Network Mask: /24 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.1 
        External Route Tag: 0 
       
LS age: 9 
Options: (No TOS-capability, Type 7/5 translation, DC) 
LS Type: AS External Link 
Link State ID: 200.1.2.0 (External Network Number) 
Advertising Router: 3.3.3.1 
LS Seq Number: 80000002 
Checksum: 0xFDC3 
Length: 36 
Network Mask: /24 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.2 
        External Route Tag: 0 

Канал требования

Канал требования является Cisco IOS 11.2 функций, которые могут также быть использованы в сетях с топологией звезда. Эта функция обычно полезна для сценариев резервирования выделенной линии с помощью коммутируемых линий и для коммутируемых виртуальных каналов X.25 или Frame Relay. Далее приведен пример конфигурации линии связи по требованию:

router ospf 1 
network 1.1.1.0 0.0.0.255 area 1 
area 1 stub no-summary 

interface Serial0                   /* Link to the hub router  */ 
  ip address 1.1.1.1 255.255.255.0 
  ip ospf demand-circuit 
  clockrate 56000 

Spoke#show ip o int s0 
Serial0 is up, line protocol is up 
  Internet Address 1.1.1.1/24, Area 1 
  Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64 
  Configured as demand circuit. 
  Run as demand circuit. 
  DoNotAge LSA not allowed (Number of DCbitless LSA is 1). 
  Transmit Delay is 1 sec, State POINT_TO_POINT, 
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
    Hello due in 00:00:06 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 130.2.4.2 
  Suppress hello for 0 neighbor(s) 

Использование линии связи по требованию в сети с топологией "звезда" восстанавливает линию связи и формирует новое смежное окружение, если топология меняется. Например, если на спице есть перебрасываемая подсеть, запрошенный канал поднимет вопрос смежности и создаст лавину этой информации. В среде с ответвлениями эта информация будет передана в шлейфную область. ODR устраняет проблему путем непредоставления этой информации другим концентраторам. Дополнительные сведения см. в разделе "Функция "линия связи по требованию" OSPF".

Оптическое считывающее устройство (ODR) в одноранговой сети

В следующей таблице представлены текущие состояния Cisco IOS 12.0 для ограничений блока описания интерфейса (IDB):

Маршрутизатор Предел
1000 300
2600 300
3600 800
4x00 300
5200 300
5300 700
5800 3000
7200 3000
RSP 1000

До IOS 12.0 максимальное число лучей, которые мог поддержать концентратор, было 300 должными к пределам IDB. Если сеть потребовала больше чем 300 лучей, то конфигурация "точка-точка" не была хорошим выбором. Также отдельный пакет CDP был создан для каждого канала. Временная сложность для передачи обновлений CDP на каналах типа точка-точка является n2. Вышеприведенная таблица содержит пределы IDB для различных платформ. Максимальное число оконечных устройств, поддерживаемых на каждой платформе, отличается, но накладные расходы создания отдельного пакета CDP для каждого канала все еще спорны. Поэтому в большом концентраторе и лучевой ситуации, настраивая многоадресный интерфейс (точка-многие точки) лучшее решение, чем интерфейс точка-точка.

ODR для многоточечной сети

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

  • Концентратор может легко поддерживать более 300 оконечных устройств. К примеру, сеть 10.10.0.0/22 будет поддерживать 1024-2 лучей звезды с многоточечным интерфейсом.

  • В многоточечной среде один пакет CDP генерируется для всех соседних узлов и реплицирован в Уровень 2. Временная сложность обновления CDP снижается до n.

  • В конфигурации точка-многие точки можно назначить только одну подсеть на все лучи.

ODR и многочисленные поставщики

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

Рис. 6: Маршрутизация, зависящая от исходящего направления (ODR), при нескольких поставщиках

odr10.jpg

Маршрутизатор концентратора, связанный с этими 98 маршрутизаторами Cisco, получит обновления подсети через ODR и получит обновления протокола маршрутизации от оставления двумя другими маршрутизаторами. Линии, подключающиеся к различным маршрутизаторам, должны находиться на отдельных подсетях "точка-точка" или "точка – многие точки".

Проблемы будущего роста

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

Рис. 7: Дальнейшее наращивание

/image/gif/paws/13710/odr9.jpg

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

Эта ситуация аналогична той, когда ODR запускается на двух концентраторах. Нет никакой служебной нагрузки при смене протоколов. Фактически ODR работает до тех пор, пока маршрутизатор является тупиковым.

Производительность

Более быстрой конвергенции и более высокой производительности при использовании ODR можно добиться, изменив некоторые настройки.

Регулировка таймеров для более быстрой сходимости

В крупных сетях ODR настройте таймеры ODR на более быстрое согласование и увеличьте значения таймеров обновления CDP от концентратора к оконечному устройству, чтобы свести к минимуму загрузку CPU по обработке запросов концентратора.

Центральный маршрутизатор

Для периода срабатывания таймера обновления CDP должно быть установлено стандартное значение 60 с, с целью уменьшения трафика от концентратора к конечным устройствам. Время удержания должно быть увеличено до максимума (255 секунд). Так как центральному маршрутизатору необходимо обслуживать слишком много таблиц смежности CDP, в случае сбоя нескольких соседей не удаляйте записи CDP из памяти в течение 255 секунд (максимальная длительность закрепления). Данная конфигурация обеспечивает гибкость маршрутизатора концентратора, так как если соседний узел вернется в активное состояние в течение четырех минут, то смежность CDP не нужно будет создавать заново. Старую запись таблицы можно использовать, а таймер holddown можно обновлять.

Далее приводится пример шаблона конфигурации IP для центрального маршрутизатора:

cdp holdtime 255 
       
      router odr 
        timers basic 8 24 0 1  /* odr timer's are update, invalid, hold down, flush 
       
        router eigrp 1 
        network 10.0.0.0 
        redistribute odr 
        default-metric 1 1 1 1 1

С каждого удаленного сайта (склад, область и хранилище) есть три постоянных канала (PVC) . Два PVC ведут к двум отдельным центральным маршрутизаторам. Третий PVC идёт на маршрутизатор PayPoint. Необходимо, чтобы канал PVC к маршруту PayPoint использовался для трафика, предназначенного для сети PayPoint. Два других ПВК используют основную и резервную функции для всех других трафиков. На основе этих требований посмотрите шаблон конфигурации ниже для каждого удаленного маршрутизатора.

Для ускорения сходимости очень важно настроить таймеры ODR, такие как invalid, holddown и flush. Хотя CDP не пересылает IP-префикс после настройки odr маршрутизатора, обновление таймера ODR должно соответствовать таймеру обновления CDP соседа, поскольку таймер схождения может быть настроен только в случае, если есть таймер обновлений. Данный таймер отличается от таймера CDP и может использоваться только для более быстрого согласования.

Оконечный маршрутизатор

Поскольку оконечные маршрутизаторы посылают обновления ODR в пакетах CDP, время для обновлений CDP должно быть очень небольшое для более быстрого схождения. В истинной топологии "звезда" нет ограничений на время удержания для соседа по CDP, поскольку луч звезды содержит в своей таблице CDP лишь несколько записей. Максимальное время хранения 255 секунд рекомендуется так, чтобы, если PVC концентратора выключается и возвращается в течение четырех минут, никакое новое соседство CDP не было необходимо, потому что может использоваться старый элемент таблицы.

Придерживающееся является примером шаблона IP - конфигурации для удаленного сайта:

cdp timer 8 
cdp holdtime 255 
       
interface serial 0 
encapsulation frame-relay 
cdp enable 
            
interface serial 0.1 point                      /* Primary PVC */ 
ip address 10.x.x.x 255.255.255.0 
frame-relay interface-dlci XX 
      
interface serial 0.2 point                      /* Secondary PVC */ 
ip address 10.y.y.y 255.255.255.0 
frame-relay interface-dlci XX 
      
       
interface bri 0 
interface BRI0 
description Backup ISDN for frame-relay 
ip address 10.c.d.e 255.255.255.0 
encapsulation PPP 
dialer idle-timeout 240 
dialer wait-for-carrier-time 60 
dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx 
ppp authentication chap 
dialer-group 1 
isdn spid1 xxxxxxx 
isdn spid2 xxxxxxx 
      
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
dialer-list 1 LIST 101 
       
       
/* following are the static routes that need to be configured on the remote routers 
       
ip route 0.0.0.0 0.0.0.0 10.x.x.x 
ip route 0.0.0.0 0.0.0.0 10.y.y.y 
ip route 0.0.0.0 0.0.0.0 bri 0 100 
ip classless 

Статические маршруты по умолчанию не нужны, если используются IOS версии 12.0.5T или более поздней, так как центральный маршрутизатор отправляет маршрут по умолчанию автоматически на все оконечные устройства.

Фильтрация и уплотнение маршрутов с использованием ODR

Маршруты ODR могут быть отфильтрованы до их утечки в ядро. Используйте команду distribute-list in. При утечке в ядро все подключенные подсети оконечных устройств следует сгруппировать. Если суммирование невозможно, ненужные маршруты можно отфильтровать в центральном маршрутизаторе. В сетях несколька концентраторов лучи могут объявить связанный интерфейс, который является ссылкой на другой концентратор.

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

Настройка таймера Telco

Важно настроить таймер Telco для увеличения времени схождения для периферийных устройств. Если PVC со стороны концентратора отключается, то оконечные устройства должны быть в состоянии это быстро определить, чтобы переключиться на второй концентратор.

Пропускная способность центрального процессора

Процесс ODR не берет партию загрузки ЦПУ. ODR был протестирован для приблизительно 1000 соседей при загруженности CPU от трех до четырех процентов. Агрессивный параметр таймера ODR на концентраторе поможет быстрее выполнять согласование. Если используются параметры по умолчанию, загруженность CPU остается на уровне от 0 до 1 процента.

Даже при использовании агрессивных значений таймеров ODR и CDP из приведенных ниже выходных данных видно, что причина не в высокой загруженности CPU. Этот тест был выполнен с 150 Процессорами с частотой МГц на Cisco 7206.

Hub# show proc cpu 
CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
   . 
   . 
  18    11588036  15783316   734   0.73%  1.74%  1.95%   0 CDP Protocol 
   . 
   . 
  48    3864      5736        673  0.00%  0.00%  0.00%   0 ODR Router 
     

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11588484  15783850    734   2.21%  1.83%  1.96%   0 CDP Protocol 
    . 
    . 
   48        3864     5736     673   0.00%  0.00%  0.00%   0 ODR Router 

Hub# show proc cpu 
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11588676  15784090    734   1.31%  1.79%  1.95%   0 CDP Protocol 
  . 
  . 
 48        3864      5736    673   0.00%  0.00%  0.00%   0 ODR Router 
       

Hub# show proc cpu 
CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11588824  15784283    734   0.65%  1.76%  1.94%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11589004  15784473    734   1.96%  1.85%  1.95%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 
       

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11589188  15784661    734   1.63%  1.83%  1.94%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router

Усовершенствования

Версия ODR прежде Cisco IOS 12.0.5T имела несколько ограничений. Далее приведен список усовершенствований в выпуске Cisco IOS 12.0.5T и более поздних:

  • В версиях до CSCdy48736 вторичные подсети объявляются как /32 в обновлении CDP. Это решено в 12.2.13T и более новых версиях.

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

  • Если канал между концентратором и конечным устройством не имеет номера IP, маршрут по умолчанию, по которому выполняет отправку концентратор, может оказаться невидимым для конечных устройств. Эта ошибка, CSCdx66917, исправлена в IOS 12.2.14, 12.2.14T и более поздних версиях.

  • Для увеличения расстояния ODR на лучах, таким образом, они могут предпочесть один концентратор по другому предложение было сделано, который отслеживается через CSCdr35460. Код был уже протестирован и скоро будет доступен клиентам.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 13710