Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
Наше новое объединенное сообщество запустится в июле! Взглянуть

Маршрутизация и коммутация Блоги (Routing and Switching)

19 просмотров
2 коммент.

Когда-же  наконец Cisco и все остальные производители откажутся от коммутации пользователей в коммутаторы. Бардак с количеством проводов просто захламляет оборудование. Невозможно просто увидеть коммутатор он весь покрыт проводами. Решения есть но похоже менять никто не хочет!

55 просмотров
0 Комментариев

Когда у вас в сети много коммутаторов и нет по каким либо причинам (которые мы тут обсуждать не будем) ни Cisco Prime ни продуктов от SolarWind и им подобных, а при этом приходится периодический искать к какому порту подключен какой нибудь ПК/камера/телефон, то можно зайти на маршрутизатор, который выполняет функцию Inter VLAN маршрутизации (возможно тоже коммутатор, к примеру 3750) посмотреть ARP таблицу, найти нужный MAC и потом посмотреть где мы его видим по MAC таблице, зайти на тот коммутатор и там найти порт.

Однако это не удобно.

Есть switchmap проект но он не особо развивается.

Я набросал простейший скрипт, который естественно можно модифицировать и сделать поиск по MAC/IP по многим коммутаторам сразу.

Основная идея скрипта такая:

1. На коммутаторах/маршрутизаторах или Radius сервере создаем пользователя с privilege level скажем 10.

2. Разрешаем выполнять show ip arp и show mac address-table для этого privilege level

Сам скрипт принимает 5 параметров.

1. IP адрес маршрутизатора/коммутатора (словом шлюза для наших ПК и прочего) с него мы получаем ARP таблицу

2. IP адрес коммутатора доступа

3. IP адрес DNS сервера, который может разрешать PRT запросы (например домен контроллер)

4. Логин на коммутаторы

5. Пароль на коммутаторы

Выполнение скрипта без параметров выводи подсказку.

Скрипт требует установки нескольких библиотек - вы легко найдете каких в сам начале скрипта.

Пример вывода:

 

switch ip: 192.168.55.20
MAC and IP address table:
000c.2902.7841 1 Gi0/5 VMware, Inc. 
000c.2912.51f9 1 Gi0/5 VMware, Inc. 192.168.55.204 dc01.POWERC.LOCAL.
000c.2934.d727 1 Gi0/5 VMware, Inc. 192.168.55.215 asterisk.powerc.local.
000c.293e.517b 1 Gi0/5 VMware, Inc. 
000c.297f.6357 1 Gi0/5 VMware, Inc. 
000c.299c.1439 1 Gi0/5 VMware, Inc. 192.168.55.203 win-5iq7rejv8qm.powerc.local.
000c.299d.1580 1 Gi0/5 VMware, Inc. 
000c.29e3.e2fc 1 Gi0/5 VMware, Inc. 192.168.55.205 
0019.b985.8bbd 1 Gi0/28 Dell Inc. 
001e.6714.0e4a 1 Gi0/5 Intel Corporate 192.168.55.199 esxi1.powerc.local.
0022.90ba.d707 1 Gi0/44 Cisco Systems, Inc 
0050.5654.0e4a 1 Gi0/5 VMware, Inc. 
00c0.eeb5.6259 1 Gi0/7 KYOCERA CORPORATION 
5026.90a9.0ac1 1 Gi0/6 FUJITSU LIMITED 192.168.55.163 olegfujitsun.powerc.local.
a4e9.752b.1856 1 Gi0/44 Apple, Inc. 
c08c.607b.9df6 1 Gi0/44 Cisco Systems, Inc 192.168.55.1 
c471.feb3.ce22 1 Gi0/44 Cisco Systems, Inc 
000e.5e1a.b819 101 Gi0/1 Raisecom Technology 
c08c.607b.9df6 101 Gi0/44 Cisco Systems, Inc 192.168.55.1 
f07f.0676.ca00 101 Gi0/1 Cisco Systems, Inc 
The End

 

Пришлось py переименовать в txt так ка не получается приложить иначе.

1544 просмотров
1 Комментарии

Часть 1 можно найти тут.

А часть 2 - тут.   

В прошлой статье мы подробно рассмотрели процесс формирования IS-IS соседств между маршрутизаторами. Далее нам необходимо обсудить, как отличаются базы данных топологий в протоколах OSPF и IS-IS.
Как вы наверняка знаете, в протоколе OSPF база данных топологии носит название LSDB (Link State Database) и представляет собой структуру, состоящую из определенных элементов.     Эти элементы носят название LSA (Link State Advertisement), и именно их содержимое описывает какие-то кусочки топологии, в которой работает протокол OSPF. Эти LSA бывают различных типов, и каждый тип придуман специально для описания какого-то определенного аспекта топологии. Например, LSA типа 1 (или Router LSA, как их еще называют) генерируются всеми маршрутизаторами и позволяют им описать присутствие себя самих и подключенных к ним сетей. Но эти LSA не передаются за пределы одной area, поэтому считается, что они описывают топологию одной area. Для описания доступности сетей других area используются LSA типа 3 (Summary LSA), а для описания доступности внешних сетей существуют LSA типа 5 (External LSA). В целом все множество всех LSA различных типов, присутствующее в LSDB каждого маршрутизатора, позволяет этому маршрутизатору представить топологии тех area, участником которых он является, узнать о доступности сетей других area и внешних для домена OSPF сетей.
    Следует отметить, что LSA не являются чем-то очевидным и требуют изучения. «Прочитать» базу данных топологии протокола OSPF, не представляя, какие типы LSA существуют, по каким правилам они генерируются, и какую информацию содержат, невозможно.
    Несколько по-другому обстоят дела с протоколом IS-IS. Инженеры, которые уже знают, как работает OSPF, и только начинающие изучать IS-IS, очень часто стараются понять структуру базы данных топологии IS-IS (кстати, ее в литературе тоже называют просто LSDB), пытаясь провести какие-то аналогии с протоколом OSPF. К сожалению, тут все не так однозначно.

    В протоколе IS-IS составным элементом LSDB является Link State PDU (или сокращенно LSP). Этот элемент является более очевидным, нежели LSA в протоколе OSPF (здесь я выражаю свое собственное мнение, которое может не совпадать с мнением читателя). LSP – это такая структура, которая генерируется каждым маршрутизатором домена маршрутизации IS-IS, и эта структура описывает видение топологии (или участка топологии) с точки зрения маршрутизатора. Все множество этих LSP, сгенерированных разными маршрутизаторами, как раз и дает устройствам представление о топологии в целом. Точно так же в OSPF вся топология может быть описана всем множеством LSA. Если посмотреть содержимое LSDB на конкретном маршрутизаторе домена маршрутизации IS-IS, то мы, прежде всего, увидим, что эта база состоит из отдельных LSP. Попытавшись посмотреть содержимое какой-то LSP, мы увидим, что в ней содержится полная информация о том участке топологии, где находится маршрутизатор, сгенерировавший эту LSP. Можно сказать, что это первое отличие LSP (IS-IS) от LSA (OSPF): в протоколе OSPF разные маршрутизаторы генерируют разные LSA и представить «видение» топологии одним маршрутизатором можно только собрав какие-то (не обязательно все) LSA вместе; в IS-IS это представление получается простым анализом одной LSP.
    Еще одно важное отличие состоит в механизме передачи топологической информации между маршрутизаторами. В протоколе OSPF базы данных топологий синхронизируются благодаря тому, что маршрутизаторы могут передавать друг другу различные LSA. И передача эта ведется с использованием специального сообщения Link State Update (LSU). Таким образом, LSU является неким контейнером, в который маршрутизаторы домена OSPF могут помещать LSA и передавать их друг другу.
    В протоколе IS-IS элемент базы данных топологии (LSP) одновременно является самостоятельным сообщением. Вообще любое сообщение протокола IS-IS называется PDU (Protocol Data Unit), и всего их существует несколько типов. В принципе мы уже знаем, что есть так называемые Hello PDU (они же IS-IS Hello – IIH), которые используются для формирования IS-IS соседств. Как мы уже обсуждали в предыдущей статье, эти PDU бывают трех разных типов в зависимости от типа интерфейса и уровня формируемого соседства. Так вот LSP – это еще один пример PDU в протоколе IS-IS. Мы уже сказали, что они фактически являются элементами базы данных топологии, но также одновременно являются и сообщением протокола IS-IS, которое служит для распространения содержимого баз данных топологий. Таким образом, в принципе можно считать, что LSDB в IS-IS состоит из сообщений. Это, кстати, еще одна причина, почему нельзя сказать, что LSP являются аналогом LSA.
    Тут может возникнуть соблазн провести параллели между LSP в протоколе IS-IS и LSU в OSPF. Однако такое сравнение тоже будет неверным. Дело в том, что в протоколе OSPF сообщения LSU служат транспортом для LSA, но этот транспорт является локальным для одного линка между маршрутизаторами. То есть можно говорить, что LSU не распространяется дальше одного линка. Тут главное не запутаться: в протоколе OSPF есть явная необходимость передавать LSA между всеми маршрутизаторами в топологии, независимо от того, какое место в топологии эти маршрутизаторы занимают (и подключены ли друг к другу напрямую вообще). Транспортом для этих LSA служит сообщение LSU, которое генерируется каждым маршрутизатором, участвующим в передаче LSA, на каждом отдельном линке. Например, пусть есть несложная топология из трех маршрутизаторов, объединенных в одну area.

    Допустим, что в этой топологии запущен протокол OSPF, и маршрутизатор R1 генерирует какой-то набор LSA. Для того чтобы протокол мог нормально работать, эти LSA должны быть переданы другим маршрутизаторам (R2 и R3) и появиться в их локальных LSDB. Протокол OSPF решает эту задачу следующим образом. R1 генерирует сообщение LSU, помещает в него созданные LSA и отправляет это сообщение всем соседям (в данном примере только маршрутизатору R2). R2 это сообщение получит, поместит эти LSA в свою LSDB, после этого сгенерирует новое сообщение LSU, в которые поместит эти LSA, и отправит всем своим соседям (только маршрутизатору R3, поскольку обратно на R1 те же LSA отправлять смысла не имеет). Таким образом, получается, что LSU – это сообщение, которое передается локально на линке между парой маршрутизаторов, что не мешает, однако, LSA, находящимся внутри этого сообщения, передаваться между всеми маршрутизаторами в топологии.
    Если представить, что в той же самой топологии будет работать IS-IS, то процесс будет выглядеть совсем по-другому. R1 генерирует свою LSP, в которой описывает свой участок топологии (как именно это выглядит, посмотрим чуть позже), и далее эту LSP он передает всем IS-IS соседям (тому же R2). R2 эту LSP примет, поместит в свою LSDB, после чего без изменений передаст своим соседям (только R3 по тем же причинам, что и в OSPF). То есть получается, что LSP будет передаваться не на линке, а между маршрутизаторами.
    Также важно заметить, что в LSU протокола OSPF происходит передача совершенно различных LSA. Совершенно не обязательно эти LSA будут сгенерированы одним и тем же маршрутизатором. Это делает сообщения LSU неким универсальным транспортом LSA. В протоколе IS-IS сообщения LSP по-прежнему содержат топологическую информацию, сгенерированную одним и тем же маршрутизатором. Именно по обозначенным выше причинам нельзя сказать, что LSP в IS-IS – это аналог LSU в OSPF.
    Теперь давайте посмотрим на эти LSP более пристально. На рисунке ниже представлен общий формат LSP протокола IS-IS.

    В самом начале мы видим общий заголовок протокола IS-IS. В целом все поля, которые в этом заголовке представлены, достаточно очевидны. Описания заслуживает поле Type. Это поле может принимать различные значения в зависимости от того, какое именно сообщение, то есть какая именно PDU помещается в заголовок IS-IS. Например, в прошлой статье мы уже говорили, что существует три различных типа IIH (IS-IS Hello). Так вот маршрутизаторы отличают их друг от друга именно благодаря этому полю в заголовке протокола IS-IS. Например, для Level 1 LAN Hello стандартизовано значение 0x0f, для L2 LAN Hello – 0x10, для Point-to-point Hello PDU – 0x11. Для сообщений LSP тут тоже есть зарезервированные значения, и этих значений два: 0x12 – для Level 1 LSP и 0x14 – для Level 1 LSP. Действительно, как мы увидим дальше в примере, маршрутизаторы различают LSP первого и второго уровней. Это следствие заложенного в основу протокола принципа разделения топологии на area и введения концепции уровня соседств.
    Далее внимания заслуживает набор полей, который входит в заголовок LSP и позволяет сформировать LSP ID. У каждой LSP, когда-либо сгенерированной в домене маршрутизации IS-IS, есть уникальный идентификатор, и он называется LSP ID. Аналогично дела обстоят и в протоколе OSPF: там тоже у каждой LSA есть свой LSA ID. В IS-IS LSP ID состоит из трех частей:

  1. Source ID. Сюда подставляется System ID маршрутизатора, сгенерировавшего эту LSP. Недаром длина этого поля равна 6 байтам, что явно совпадает с длиной System ID в протоколе IS-IS.
  2. Pseudonode ID. Это поле равно нулю для «обычных» LSP. Под «обычными» мы пока будем понимать те LSP, определение которым дали раннее. Есть еще дополнительные LSP, которые генерируются маршрутизаторами  , выбранными на роль DIS.  В них это поле будет принимать ненулевое значение. Об этом мы детально поговорим чуть позже, разбирая пример LSDB.
  3. LSP number. Это поле равно нулю, если вся топологическая информация, которую маршрутизатор хочет сообщить остальным, помещается в одну LSP. Дело в том, что согласно стандарту,  размер LSP не может превышать 1492 байта. И если весь объем данных о топологии в этот размер не влезает, то маршрутизаторы могут генерировать несколько фрагментов одной LSP. В этом случае в поле LSP Number подставляются номера фрагментов LSP, в которых передается остаток топологической информации, не попавший в первую часть. Очевидно, что поскольку размер LSP number равен 1 байту, таких фрагментов может быть 256.

  Далее стоит обратить внимание на поля Remaining Lifetime и Sequence number. Эти поля используются протоколом для определения актуальности передаваемой топологической информации в каких-нибудь спорных ситуациях. Поле Sequence number является подобием версии LSP. Если маршрутизатору, заметившему изменение в топологии, нужно сообщить всем остальным об этом изменении, он просто заново генерирует свою LSP с уже измененной информацией, и добавляет к Sequence number единицу, сообщая тем самым всем остальным, что в новой LSP информация более актуальная. Кстати, в протоколе OSPF у LSA тоже есть версия, и она тоже называется Sequence number, и тоже занимает 4 байта.
    Поле Remaining lifetime служит для указания того, сколько времени осталось до уничтожения этой LSP из базы данных топологии. Это поле тоже служит для оценки актуальности передаваемых топологических данных (считается, что одного Sequence number недостаточно). Аналогом этого параметра в протоколе OSPF является LSA Age. Напомню, что в OSPF, любой маршрутизатор, сгенерировавший LSA, помещает в параметр LSA Age для этой LSA значение 0. Далее с каждой секундой жизни LSA в базе данных топологии значение LSA Age увеличивается на единицу. При этом он сохраняется при передаче LSA между маршрутизаторами. Таким образом, посмотрев на LSA Age, можно легко узнать, когда именно LSA была сгенерирована. Максимальное время жизни LSA в OSPF составляет один час (3600 секунд). То есть если LSA Age для какой-то LSA достигнет этого значения, такая LSA будет удалена из базы данных топологии. Чтобы этого не происходило, маршрутизаторы обязаны с определенным периодом повторно генерировать свои локальные LSA. Маршрутизаторы Cisco по умолчанию делают это каждые полчаса (1800 секунд).
    В IS-IS ту же функцию выполняет поле Remaining lifetime. Но есть существенная разница в его обработке. Состоит она в том, что когда маршрутизатор генерирует свою локальную LSP, в это поле он помещает не 0, а 1200, имея в виду 1200 секунд, то есть 20 минут. И далее с каждой секундой присутствия этой LSP в базе данных топологии это число будет уменьшаться на 1, стремясь к нулю. Если оно достигнет нуля, то такая LSP будет удалена из LSDB. Чтобы этого не происходило, маршрутизаторы также обязаны повторно генерировать локальные LSP до момента обнуления Remaining lifetime, возвращая этот параметр в начальное значение. Маршрутизаторы Cisco по умолчанию делают это один раз в 900 секунд (15 минут).
    Такая разница в обработке времени жизни элемента LSDB в разных протоколах является существенной. Считается, что IS-IS в этом отношении более гибкий, поскольку администратор может в конфигурации маршрутизатора задать стартовое значение Remaining lifetime. Оно равно 1200 лишь по умолчанию. Поскольку под этот параметр отводится 2 байта, это означает, что его максимальное значение равно 65535. То есть время жизни каждой LSP в топологии может быть принудительно увеличено. Тем самым, можно например, сделать перегенерацию LSP более редкой. В OSPF такого сделать нельзя: там время жизни LSA всегда находится в диапазоне от нуля до 3600 секунд. Однако мне известны и исключения. Вопрос для внимательных читателей: что странного в выводе команды show ospf database, показанном на картинке ниже?


Также стоит в формате LSP отметить байтовое поле с флагами:

  1. P – занимает 1 бит, был придуман в стандарте, сейчас не нужен, поэтому равен 0.
  2. ATT – занимает 4 бита и расшифровывается как Attached. Используется маршрутизаторами L1 для определения устройств, подключенных к backbone. Подробно поговорим о нем позже.
  3. OL – один бит, который называется Overload. Может использоваться, если администратору нужно направить транзитный трафик в обход данного маршрутизатора. Если этот бит в LSP выставлен, то другие маршрутизаторы не будут учитывать присутствие этого устройства в топологии при расчете алгоритмом SPF. Это позволяет временно выводить маршрутизаторы из обслуживания (например, для перезагрузки), обеспечивая при этом перемаршрутизацию транзитного трафика, идущего через эти маршрутизаторы, по альтернативным путям. Кстати, в OSPF подобного механизма не существует.
  4. IS Type – занимает 2 бита, и указывает на то, является ли маршрутизатор, сгенерировавший данную LSP, устройством уровня 1 или также имеет функционал L2.

  Описанные нами поля вместе с полями Checksum и PDU Length формируют заголовок LSP, который присутствует в дополнение к основному заголовку IS-IS.
Далее нам нужно посмотреть на содержимое LSP. Это самое интересное, поскольку именно тут содержится информация о топологии. На рисунке с форматом LSP мы можем увидеть, что после заголовка LSP следуют какие-то TLV. С самими TLV как с составными частями сообщений протокола IS-IS мы уже встречались в прошлой статье, обсуждая сообщения IIH. Там мы видели, что TLV позволяют легко добавлять информацию в сообщения протокола. Тот же принцип мы увидим и тут. Вообще, как мы уже отмечали, использование TLV в сообщениях IS-IS делает протокол гибким и позволяет добавлять в него дополнительный функционал за счет простой стандартизации новых TLV и введения их поддержки в софтах маршрутизаторов. OSPF версии 2 такой гибкости, кстати, не дает.
    Итак, какие TLV нам могут встретиться в составе LSP?

Area address TLV (TLV Type 1)
    Эта TLV всегда помещается перед остальными. В ней маршрутизатор указывает, какой area он принадлежит. Здесь стоит напомнить, что в протоколе IS-IS, согласно дизайну, маршрутизатор всегда целиком принадлежит какой-то определенной area. Формат этой TLV показан ниже:


IS Neighbors TLV (TLV Type 2)
Эта TLV служит для описания всех соседних маршрутизаторов, которые известны устройству, генерирующему TLV. Формат этой TLV показан ниже.


    Поле Virtual Flag не используется и равно 0. За ним следует описание каждого устройства, с которым у локального маршрутизатора есть IS-IS соседство соответствующего уровня. В L1 LSP описываются соседства уровня 1, в L2 – уровня 2. Интересно, что сам сосед описывается с помощью System ID, но помимо этого ему соответствуют 4 разных значения метрики. Дело тут в том, что изначально протокол IS-IS был задуман как поддерживающий разные типы метрик, отражающие какие-то разные свойства линков. Эти метрики называются default, delay, expense и error. По задумке авторов протокола это должно было сделать динамическую маршрутизацию посредством IS-IS более гибкой за счет того, что в разных задачах можно было бы учитывать разные метрики. Однако на практике метрики delay, expense и error нигде не используются и не поддерживаются. Поэтому метрика интерфейса, к которому подключен соседний маршрутизатор , помещается в поле Default metric. Кстати, в протоколе IS-IS метрика любого интерфейса по умолчанию равна 10 и не рассчитывается на основании пропускной способности, как это происходит в OSPF.
    Интересно также отметить, что под значение метрики тут отводится всего 6 бит (1 байт минус два флага 0 и I/E). Это означает, что максимальное значение метрики одного интерфейса в протоколе IS-IS должно быть равно 63. На практике, однако, это не всегда так. 6-битную метрику в протоколе IS-IS называют узкой (narrow metric), и ей есть альтернатива. Совершенно логично, что альтернатива носит название широкой метрики (wide metric) и позволяет задавать численно бо́льшие значения. Однако IS neighbors TLV не позволяет использовать широкую метрику: ее формат предполагает использование всего лишь 6 бит для обозначения метрики интерфейса.

Protocols Supported TLV (TLV Type 129)
    Используется для перечисления протоколов, маршрутизацию которых поддерживает данное устройство. Формат этой TLV достаточно прост:


    В этой TLV маршрутизатор может заявить поддержку, например, IPv6, помимо IPv4. Благодаря этому, маршрутизаторы могут использовать протокол IS-IS для организации маршрутизации как IPv4, так и IPv6 трафика. Напомню, что в OSPF для этого пришлось придумать новую версию протокола.

IP interface address TLV (TLV Type 132)
    В эту TLV маршрутизатор помещает адреса тех интерфейсов, которые включены в работу IS-IS, и через которые будет производиться рассылка LSP. Формат простой:


Dynamic Hostname TLV (TLV Type 137)
    Эта TLV используется для распространения информации о локальном Hostname маршрутизатора. Формат этой TLV достаточно прост и предполагает передачу одного единственного полезного параметра переменной длины – текстового имени маршрутизатора:


    Тут можно возразить, что эта информация не является полезной с точки зрения осознания топологии маршрутизаторами: мы ведь уже говорили, что маршрутизаторы в протоколе IS-IS различают друг друга по System ID, и именно его сообщают в различных служебных сообщениях. Это действительно так. Однако при эксплуатации протокола IS-IS достаточно неудобно читать содержимое базы данных топологии, списки соседних маршрутизаторов и другие данные, всматриваясь именно в 6-байтные System ID. Поэтому для протокола IS-IS была стандартизована Dynamic Hostname TLV, в которой маршрутизатор может сообщить свое имя. Это имя может быть использовано другими устройствами для более человечного отображения LSP ID в виде имени маршрутизатора. Далее в примере мы увидим, как сильно помогает читать выводы различных команд использование этой TLV.
  
    На этом этапе должно стать понятно, как в LSP маршрутизатор может описать себя самого: area, которой он принадлежит, список поддерживаемых протоколов, локальные адреса, всех своих соседей и даже hostname. Однако протокол IS-IS должен обеспечивать динамическую маршрутизацию между какими-то сетями, которые подключены к маршрутизаторам. Поэтому совершенно логично, что в LSP должна попадать информация о сетях, которые терминируются на интерфейсах маршрутизаторов. Для этого тоже существует целый набор TLV.

IP internal reachability TLV (TLV Type 128)
    Эта TLV используется для описания подключенных к маршрутизатору сетей. Все сети, которые настроены на интерфейсах, включенных в работу IS-IS, попадают в эту TLV. Формат ее представлен ниже.


    Подобный формат мы уже видели в IS neighbors TLV. Разница лишь в том, что тут описываются не System ID соседей, а адреса сетей, подключенных к маршрутизатору, и их маски. При этом каждой сети тоже может быть поставлено в соответствие 4 разных метрики, и точно также три типа метрики (delay, expense и error) тут не используются. Поэтому реальное значение метрики, настроенной на интерфейсе, к которому подключена каждая сеть, попадает в поле default metric. Обратите внимание, что длина этого поля составляет всего 6 бит, что опять же означает максимальное значение 63, то есть использование узкой метрики. Стоит запомнить, что эта TLV позволяет анонсировать только узкую метрику.

IP external reachability TLV (TLV Type 130)
    Как и в протоколе OSPF, в IS-IS есть концепция внешних маршрутов. То есть маршрутизатор может переносить маршрутную информацию в домен маршрутизации IS-IS из какого-то другого протокола маршрутизации (OSPF, RIP, BGP, static). Такой маршрутизатор называется ASBR, и его работа в этой роли приводит к появлению внешних маршрутов, то есть маршрутов до сетей, которые попали в протокол не благодаря включению IS-IS на интерфейсе маршрутизатора, а благодаря редистрибьюции из других протоколов. Если маршрутизатор действительно выполняет роль ASBR, то в свою LSP он добавляет IP external reachability TLV, в которой описывает все внешние сети, которые импортирует в домен IS-IS, и метрики маршрутов до этих сетей.



    Как несложно заметить, формат этой TLV повторяет формат IP internal reachability TLV. Разница заключается только в смысле этих TLV: 128 используется для распространения информации о внутренних сетях, а 130 – о внешних.

Extended IP reachability TLV (TLV Type 135)
    Эта TLV является еще одним способом, с помощью которого маршрутизатор может описать подключенные к нему сети, а также внешние сети. Может возникнуть вопрос, для чего она нужна, если уже есть IP internal reachability и IP external reachability. Для того чтобы ответить на этот вопрос, давайте для начала посмотрим на формат этой TLV:


    Как мы видим, формат предполагает возможность указать только адрес сети и длину префикса. То есть эта TLV действительно позволяет описать сеть, не делая акцент на то, внешняя это сеть или внутренняя. Помимо этого мы видим единственное поле Metric длиной 4 байта. Разумеется, это поле используется для обозначения значения метрики интерфейса, к которому подключена внутренняя сеть, или метрики маршрута до внешней сети. И длина этого поля – это первая причина, почему существует Extended IP reachability TLV: это возможность использовать численно бо́льшие значения метрики (больше тех, которые давали TLV 128 и 130). Получается, что при использовании этой TLV для описания сетей, можно оперировать значением метрики до 4 294 967 295. Предположительно, такого диапазона значений должно хватить для всех задач. Это и есть та самая широкая метрика (wide metric) протокола IS-IS. Получается, что если мы хотим включить ее использование в нашей топологии, нам надо заставить маршрутизаторы описывать подключенные сети с использованием Extended IP reachability TLV.
    Вторая причина, по которой нам необходимо использовать эту TLV кроется в использовании sub-TLV, обозначенных на рисунке выше. Да, TLV 135 в IS-IS использует в своем формате другие TLV (так называемые sub-TLV). Получается некая матрешка. Мы сейчас не будем останавливаться на деталях использования этих sub-TLV. Вместо этого скажем лишь только, что эти sub-TLV позволяют описать дополнительные свойства интерфейсов, на которых запущен протокол IS-IS. На практике этими свойствами обычно являются полоса пропускания (bandwidth), принадлежность линка к определенным категориям (affinity class) и еще одна метрика (TE metric). Те читатели, которые имеют представление о MPLS Traffic Engineering, должны узнать эти параметры. Это дополнительные свойства топологии, которые необходимы для обеспечения работоспособности MPLS TE. Именно Extended IP reachability TLV является тем самым расширением протокола IS-IS, которое позволяет ему распространять информацию о TE свойствах топологии.

Extended IS reachability TLV (TLV Type 22)
    Стоит вспомнить, что узкую метрику мы встречали не только в TLV 128 и 130, но и в IS neighbors TLV, которая описывала соседей, напрямую подключенных к маршрутизатору. Достаточно логично, что при необходимости использовать широкую метрику, какие-то корректировки должны быть внесены и в эту информацию тоже. Поэтому собственно и существует TLV 22, которая позволяет описать подключенных соседей, но с использованием широкой метрики. Формат этой TLV показан ниже:


    Как мы видим, в этой TLV точно так же, как и в TLV 2, перечисляются соседние маршрутизаторы, но под метрику теперь отводится больше места. Помимо этого тут также можно заметить использование sub-TLV. Они также используются для целей MPLS TE, поэтому подробно останавливаться на них мы тут не будем.
  
    На этом этапе может возникнуть идея провести аналогию между LSA в протоколе OSPF и отдельными TLV, из которых состоит LSP в протоколе IS-IS. Но такая аналогия тоже не будет верной, поскольку каждая отдельная LSA в протоколе OSPF имеет свой отдельный ID, Sequence number и Max Age. В протоколе IS-IS эти параметры определяются для целой LSP, а не для каждой TLV в отдельности. Получается, что прямого аналога LSA протокола OSPF в протоколе IS-IS назвать нельзя. Это хороший пример того, как эти два протокола, имея в основе один и тот же принцип (link state подход к решению задачи динамической маршрутизации), фактически являются разными, и проведение явных аналогий между ними не всегда возможно.

Итак, мы описали достаточно приличный набор TLV, которые маршрутизаторы могут включать в локально сгенерированные LSP для описания топологии. Чтобы эта информация как-то закрепилась и систематизировалась, давайте на примере несложной сети посмотрим, как эти LSP и их TLV выглядят в LSDB маршрутизаторов.
    Пусть у нас есть 4 маршрутизатора, которые объединены в следующую топологию:



    Для простоты будем представлять, что все маршрутизаторы являются участниками одной и той же area 49.0001. Также будем считать, что на линках используются сети вида 10.x.y.0/24, где x – это номер одного маршрутизатора на линке, а y – номер другого. При этом на каждом маршрутизаторе настроен интерфейс Loopback 0 с адресом вида x.x.x.x/32, где x – это номер маршрутизатора. Этот интерфейс также включен в работу IS-IS. Для начала давайте представим, что между всеми маршрутизаторами (поверх всех линков) установлены IS-IS соседства уровня 1.
    Убедиться в наличии этих соседств достаточно просто:



    Как мы видим, действительно вся система соседств находится в работоспособном состоянии.
    Теперь давайте оценим содержимое базы данных топологии на маршрутизаторах. Например, на R2:


    Можно заметить, что на R2 присутствует две базы данных топологии: одна для уровня 1, другая – для уровня 2. Ранее мы уже упоминали, что маршрутизаторы будут генерировать LSP для обоих уровней. В нашем примере между маршрутизаторами настроены соседства уровня 1, поэтому LDSB уровня 1 выглядит достаточно полной, а LSDB уровня 2 содержит только одну LSP. Так получается потому, что соседств уровня 2 в топологии в принципе нет, и обмена LSP уровня 2 тут не происходило. Маршрутизаторы в нашем примере, однако, имеют обе LSDB. Это связано с тем, при настройке маршрутизаторов уровни соседств задавались на интерфейсе, а не глобально. То есть не использовалась команда is-type level-2 в режиме конфигурации protocol isis. Поэтому маршрутизатор потенциально готовится держать базу данных топологии для каждого уровня. Если бы мы при настройке протокола указали, что маршрутизаторы будут устройствами только уровня 1, то LSDB уровня 2 мы бы не увидели.
    Давайте более пристально посмотрим на LSDB уровня 1. Мы видим тут 9 различных LSP, у каждой из которой свой идентификатор. Обратите внимание, что в LSDB присутствуют 4 LSP вида Rx.00-00 (где x – номер маршрутизатора), то есть LSP, в идентификаторе которых Pseudonode ID равен 00. Это «основные» LSP, описывающие видение топологии с точки зрения каждого маршрутизатора в нашей топологии. Именно их содержимое далее будет представлять для нас особый интерес, потому что именно в них мы найдем те самые TLV, которые уже обсудили выше. Остальные 5 LSP имеют вид Rx.0y-00, где x – номер маршрутизатора, а y – какое-то число. То есть это LSP, у которых идентификатор содержит ненулевой Pseudonode ID. В протоколе IS-IS такие LSP также генерируются маршрутизаторами, выбранными на роль DIS. Здесь, вероятно, стоит напомнить, что DIS – это специальный маршрутизатор, который выбирается при формировании соседств в широковещательных средах. Это примерный аналог DR в протоколе OSPF. Основная роль этого маршрутизатора состоит в оптимизации системы соседств в широковещательных доменах, а также в правильном представлении этой системы в базе данных топологии. В протоколе OSPF маршрутизаторы, выполняющие роль DR генерировали LSA типа 2 (Network LSA), которые отвечали за описание широковещательных сегментов топологии в LSDB. В протоколе IS-IS потребность в таком описании тоже есть. И это описание сводится к генерации дополнительной LSP с ненулевым Pseudonode ID. Эта LSP будет описывать только широковещательный сегмент и перечислять подключенные к этому сегменту маршрутизаторы. За ее создание будет ответственен маршрутизатор, выбранный на роль DIS на данном широковещательном сегменте. Можно сказать, что такие LSP с ненулевым Pseudonode ID являются аналогом LSA типа 2 в протоколе OSPF.
    В нашей топологии для соединения маршрутизаторов используются GigabitEthernet линки, являющиеся широковещательной средой, а значит, на этих линках производится выбор DIS. То есть на каждом линке один из маршрутизаторов будет выбран на роль DIS, и он будет ответственен за генерацию LSP, описывающей этот широковещательный сегмент. Несложно заметить, что в нашей топологии всего 5 линков, поэтому логично, что в LSDB мы видим 5 LSP с ненулевым Pseudonode ID (Rx.0y-00). Мы можем посмотреть в их содержимое. Например, давайте более подробно рассмотрим LSP с идентификатором R1.01-00:


Содержимое достаточно краткое, потому что эта LSP описывает только один широковещательный сегмент, и больше ничего. Можно понять, что речь идет о широковещательном сегменте, где присутствую устройства R1 и R2 (то есть о линке R1-R2). Поскольку эта LSP генерировалась маршрутизатором R1,  можно сделать вывод, что на этом линке R1 был выбран на роль DIS. Кстати, если этот линк мы переведем в режим point-to-point, то потребность выбора DIS на этом линке исчезнет, и эта LSP пропадет из LSDB:


      R1(config)#int g0/1
      R1(config-if)#isis network point-to-point

      R2(config)#int g0/1
      R2(config-if)#isis network point-to-point




    Кстати, тут можно обратить внимание, что удаление LSP из базы данных топологии не происходит мгновенно. Для того чтобы удалить какую-то LSP из LSDB, маршрутизаторы просто выставляют для этой LSP параметр Remaining lifetime, равный нулю. Аналогичным образом в протоколе OSPF производится удаление LSA: для нее просто выставляется LS Age, равный 3600. Однако в IS-IS удаляемая LSP c нулевым Remaining lifetime не удаляется из базы мгновенно: из базы удаляется содержимое LSP, а ее заголовок с нулевым Remaining lifetime хранится в базе еще в течение определенного времени (так называемого Zero Age Lifetime). Обычно этот таймер равен 60 секундам. Его наличие позволяет быть уверенным в том, что все маршрутизаторы узнают о необходимости удаления этой LSP из базы данных. Маршрутизаторы Cisco, однако, пустую LSP с нулевым Remaining lifetime хранят еще 20 минут.
    Как мы видим, содержимое LSP с идентификатором R1.01-00 из LSDB пропало (остался только заголовок):


    Аналогичным образом мы можем поступить с каждым линком в нашей топологии. В результате каждый линк будет переведен в режим работы point-to-point, и база данных топологии перестанет содержать LSP c ненулевыми Pseudonode ID. Например, по прошествии 20 минут LSDB станет выглядеть так:


    Как мы видим, в LSDB остались только LSP с нулевым Pseudonode ID. Давайте посмотрим на их содержимое более детально. Например, на ту, которую сгенерировал R1:


В содержимом этой LSP мы можем заметить следующие TLV:

  1. Area address. Тут мы видим, что R1 представляется как участник area 49.0001, что соответствует действительности.
  2. Protocols Supported. Видим, что заявлен NLPID (Network Layer Protocol ID) 0xCC, что в IS-IS соответствует IPv4.
  3. Dynamic Hostname. Тут комментарии излишни: мы видим, что R1 сообщает свой hostname. Кстати, можно обратить внимание, что все выводы команд, которые мы уже посмотрели, вместо System ID маршрутизаторов содержат их hostname. Это становится возможным как раз благодаря включению этой TLV в LSP на каждом маршрутизаторе.
  4. IS neighbors. R1 заявляет, что его соседями являются R2, R3 и R4, и до каждого он может добраться через интерфейс с метрикой 10.
  5. IP interface addresses. По стандарту сюда должны подставляться IP адреса интерфейсов, через которые происходит рассылка LSP. По умолчанию маршрутизаторы Cisco подставляют сюда адрес, настроенный на интерфейсе Loopback 0.
  6. IP internal reachability. Видно, что к маршрутизатору R1 подключено 4 префикса: 1.1.1.1/32, 10.1.2.0/24, 10.1.3.0/24 и 10.1.4.0/24.

Если попытаться проанализировать какую-то другую LSP в этой LSDB, например, сгенерированную маршрутизатором R4, то мы увидим, что она содержит топологическую информацию с точки зрения маршрутизатора R4:


    Видно, что здесь он описывает свою area, свои подключенные префиксы и своих непосредственных соседей.
    Кстати, в приведенных выше выводах видно, что маршрутизаторы Cisco по умолчанию используют узкую метрику. Это значит, что даже если на каком-то интерфейсе мы зададим значение метрики больше, чем 63, маршрутизатор все равно не сможет ее анонсировать. Например, для интерфейса Gi0/1 маршрутизатора R1:

      R1(config)#int g0/1
      R1(config-if)#isis metric 1000
      Warning: for metrics greater than 63, 'metric-style wide'  should be configured on level-1-2, or it will be capped at 63.


    Уже даже при конфигурации метрики мы видим предупреждение о том, что метрика будет сокращена до 63. Смотрим на содержимое LSP, которую генерирует R1:


    Действительно видно, что, несмотря на то, что метрика была настроена в значение 1000, R1 анонсирует ее равной 63. Эту ситуацию можно поменять, принудительно настроив использование только широкой метрики. Крайне желательно делать это на всех маршрутизаторах в топологии:

      R1(config)#router isis 1
      R1(config-router)#metric-style wide

      R2(config)#router isis 1
      R2(config-router)#metric-style wide

      R3(config)#router isis 1
      R3(config-router)#metric-style wide

      R4(config)#router isis 1
      R4(config-router)#metric-style wide


Ввод данной команды запускает использование Extended IP reachability TLV для описания сетей, подключенных к маршрутизатору, и отключает использование IP internal reachability TLV. Давайте посмотрим на содержимое LSP, которую генерирует R1, после внесенных изменений:


    Как мы видим, произошли некоторые изменения. В Cisco IOS нам в явном виде не показывают, что используется именно Extended IP reachability TLV, но формат отображения префиксов, а также значение метрики больше 63 нам на это намекают. Кстати, можно обратить внимание, что теперь вместо IS reachability TLV используется Extended IS reachability. Об этом можно судить по значению метрики интерфейса в сторону R2, а также по тому, что соседи обозначены с опцией IS-Extended.
    Теперь давайте добавим соседство второго уровня на линках R2-R3 и R3-R4:

      R2(config)#int g0/2
      R2(config-if)#isis circuit-type level-1-2

      R3(config)#int g0/1
      R3(config-if)#isis circuit-type level-1-2
      R3(config-if)#int g0/2
      R3(config-if)#isis circuit-type level-1-2

      R4(config)#int g0/1
      R4(config-if)#isis circuit-type level-1-2


    Теперь можно убедиться, что помимо имеющейся системы соседств уровня 1, появилось два IS-IS соседства уровня 2:


    Как мы видим, соседства уровня 2 между R2, R3 и R4 сформировались. Теперь давайте посмотрим на базы данных топологии на R3:


    Теперь различия между базами данных топологии видны более явно. Мы видим, что на R3 есть отдельная LSDB для уровня 1 (именно эту LSDB, и LSP в ней мы и обсуждали выше), и в этой LSDB есть информация о четырех маршрутизаторах. Это логично, если учесть, что изначально мы говорили о нашей топологии и наличии только соседств уровня 1 в ней. Но после добавления соседств уровня 2, LSDB уровня 2 теперь содержит информацию о трех маршрутизаторах. Это логично, поскольку на R1 соседства второго уровня не настраивались вообще, и он фактически является L1 устройством. Таким образом, мы можем убедиться, что маршрутизаторы домена маршрутизации IS-IS ведут разные базы данных топологии для разных уровней. Напомним, что концепция уровней в IS-IS является следствием возможности разделения топологии на area. Как мы уже знаем, это разделение в link-state протоколах маршрутизации практикуется для лучшего масштабирования протокола. И совершенно логично, что должны быть какие-то правила взаимодействия устройств разных area или разных уровней. Об этих правилах, а также о масштабировании домена маршрутизации IS-IS мы поговорим в следующей статье.

---

Андрей Петрунин,

IT директор УЦ "Fast Lane"

699 просмотров
0 Комментариев

Ни для кого не будет секретом, что в настоящее время IPv6 является уже довольно широко распространенным протоколом. Но не всегда у оператора связи есть возможность реализации IPv6 на своей магистральной сети. Причины могут быть самые разные. Тем не менее, возникают ситуации, когда существующие, либо новые клиенты компании заказывают услугу получения доступа в сеть с помощью IPv6. Как же быть в данном случае, отказывать ли клиенту  в предоставлении услуги?  К счастью, прогресс не стоит на месте, уже довольно давно существуют и применяются на практике различные способы решения данной проблемы, например, передачи IPv6 трафика по сетям IPv4 с помощью туннелирования.

Практически каждый оператор реализует на своей магистральной сети коммутацию с помощью меток (MPLS), чаще всего посредством IGP+LDP.  MPLS позволяет организовать туннелирование IPv6 пакетов, через сеть IPv4. Осуществить  это позволяют две схожие технологии 6PE и 6VPE, реализацию которых на оборудовании Cisco мы рассмотрим в данном блоге.

Сначала немного теории.

6PE описан в RFC4798.

6VPE описан в RFC4659.

6PE

⦁ IPv6 префиксы клиента маршрутизируются в глобальной таблице маршрутизации
⦁ Обмен IPv6 префиксами/метками происходит между IPV4 соседями с помощью добавления дополнительной метки, используется address-family IPv4

6VPE

⦁ IPV6 префиксы клиенты маршрутизируются внутри VRF
⦁ Обмен IPv6 префиксами/метками происходит между IPV4 соседями с помощью добавления дополнительной метки, используется address-family vpnv6

Использование технологии 6PE, как и технология 6VPE  предоставляет провайдеру  ряд следующих преимуществ, при этом 6VPE расширяет данный ряд:

-  реализация предоставления IPV6 без изменения магистральной MPLS сети (6PE, 6VPE);

- нет потребности в реализации дополнительной сигнализации на сети (6PE, 6VPE);

- снижение операционных издержек (6PE, 6VPE);

- улучшенная безопасность путем изоляции клиентского трафика (6VPE);

- логическое разделение клиентского трафика (6VPE);

- возможность реализации Inter-AS и CsC(Carrier-supporting-Carrier) (6VPE).

 

 

 Кратко рассмотрим реализацию 6PE, на примере следующей сети. (см. Схема 1)

Схема 1

На магистральной сети настроен  IPv4, в качестве IGP используется IS-IS. Протокол маршрутизации между CE и PE в сети клиента 1 – OSPFv3, клиента 2 – BGP.

Для достижения большей масштабируемости в сети используется Route Reflector. Остальные особенности конфигурации отражены в схеме и названиях объектов.

Рассмотрим прохождение трафика между CE маршрутизаторами в сети клиента1, CE14 и CE11, а также конфигурацию маршрутизаторов.

CE11#tra

Protocol [ip]: ipv6

Target IPv6 address: 2001::14

Source address: 2001::11

 

  1 2001:DB8:1:1000::1 24 msec 4 msec 5 msec

  2 ::FFFF:10.1.2.2 [MPLS: Labels 23/32 Exp 0] 20 msec 19 msec 17 msec

  3 2001:DB8:1:1000::6 [MPLS: Label 32 Exp 0] 26 msec 8 msec 20 msec

  4 2001:DB8:1:1000::14 7 msec 10 msec 26 msec

 

От CE11 до CE14 трафик проходит.

В обратную сторону тоже.

CE14#ping 2001::11 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::11, timeout is 2 seconds:

Packet sent with a source address of 2001::14

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 9/12/19 ms

 

 

Посмотрим, что происходит на магистральном интерфейсе PE4 (R6),  во время прохождения ICMP с CE14 до CE11.

В дампе Wireshark видно следующее (см. Рис. 1)

Рис.1

Как видно, пакет содержит две MPLS метки, одна транспортная – 25, вторая, «туннельная», 24014.

Посмотрим, как это выглядит с точки зрения маршрутизатора

Сначала посмотрим, как выглядит маршрут до конечного хоста - 2001::11/128

 

R6#sh bgp ipv6 unicast 2001::11/128

BGP routing table entry for 2001::11/128, version 9

Paths: (1 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 2

  Local

    ::FFFF:1.1.1.1 (metric 20) from 7.7.7.7 (7.7.7.7)

      Origin incomplete, metric 1, localpref 100, valid, internal, best

      Originator: 1.1.1.1, Cluster list: 7.7.7.7

      mpls labels in/out nolabel/24014

      rx pathid: 0, tx pathid: 0x0

 

В данном выводе видно метку для передачи IPV6 префикса  - 24014.

Трафик должен идти через роутер с адресом 1.1.1.1, посмотрим транспортную метку до 1.1.1.1.

Сейчас трафик до 1.1.1.1 идет через  10.2.6.2.

R6#sh mpls forwarding-table 1.1.1.1 detail

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

28         25         1.1.1.1/32       0             Gi0/0.26   10.2.6.2

        MAC/Encaps=18/22, MRU=1500, Label Stack{25}

        5000001600005000001200008100001A8847 00019000

        No output feature configured

    Per-destination load-sharing, slots: 0

           24010      1.1.1.1/32       0             Gi0/0.56   10.5.6.5

        MAC/Encaps=18/22, MRU=1500, Label Stack{24010}

        500000010001500000120000810000388847 05DCA000

        No output feature configured

    Per-destination load-sharing, slots: 1

 

 

Также в памяти есть маршрут  до 1.1.1.1 через 10.5.6.5. Попробуем положить интерфейс Gi0/0.26, транспортная метка должна поменяться на 24010. ( См. рис.2)

Рис.2

Все верно.

 

Конфигурация выглядит так.

 

PE1

router ospfv3 1

 default-information originate always

 area 0

  interface Loopback0

   passive

  !

  interface GigabitEthernet0/0/0/1.111

  !

 

RP/0/0/CPU0:R1#sh run int GigabitEthernet0/0/0/1.111

Mon Mar  6 15:13:46.818 UTC

interface GigabitEthernet0/0/0/1.111

 ipv6 address 2001:db8:1:1000::1/64

 encapsulation dot1q 111

!

 

RP/0/0/CPU0:R1#sh run router bgp

Mon Mar  6 15:14:01.297 UTC

router bgp 150

 bgp log neighbor changes detail

 address-family ipv6 unicast

  redistribute ospfv3 1

  allocate-label all

# надо включить распространение меток протоколом BGP для назначения

# туннельных VPN меток

 !

 neighbor 7.7.7.7

  remote-as 150

  update-source Loopback0

  address-family ipv6 labeled-unicast

   next-hop-self

  !

 !

!

 

PE4

R6#sh run | sec router ospfv3

router ospfv3 1

 !

 address-family ipv6 unicast

  default-information originate always

 exit-address-family

 

R6#sh run | sec router bgp

router bgp 150

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 150

 neighbor IBGP update-source Loopback0

 neighbor 7.7.7.7 peer-group IBGP

 !

 address-family ipv4

 exit-address-family

 !

 address-family ipv6

  redistribute connected

  redistribute ospf 1

  neighbor IBGP next-hop-self

  neighbor IBGP send-label

  neighbor 7.7.7.7 activate

 exit-address-family

R6#

 

 

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

( https://supportforums.cisco.com/ru/blog/13236101 )

Ранее мы разбирались, как работает эта технология в сети IPV4, сейчас мы посмотрим, как работает эта опция с AF отличной от IPV4.

  

RR

R7#sh run | sec router bgp

router bgp 150

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 150

 neighbor IBGP update-source Loopback0

 neighbor 1.1.1.1 peer-group IBGP

 neighbor 3.3.3.3 peer-group IBGP

 neighbor 4.4.4.4 peer-group IBGP

 neighbor 6.6.6.6 peer-group IBGP

 !

 address-family ipv4

 exit-address-family

 !

 address-family ipv6

  table-map NO_CLIENTS_ROUTES filter

  neighbor IBGP route-reflector-client

  neighbor IBGP send-label

  neighbor 1.1.1.1 activate

  neighbor 3.3.3.3 activate

  neighbor 4.4.4.4 activate

  neighbor 6.6.6.6 activate

 exit-address-family

 

route-map NO_CLIENTS_ROUTES deny 10

 

В RIB ipv6 и FIB ipv6 информация отсутствует, но между конечными узлами трафик ходит.

R7#sh ipv6 ro bgp

IPv6 Routing Table - default - 1 entries

Codes: C - Connected, L - Local, S - Static, U - Per-user Static route

       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1

       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP

       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination

       NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter

       OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1

       ON2 - OSPF NSSA ext 2, la - LISP alt, lr - LISP site-registrations

       ld - LISP dyn-eid, a - Application

R7#sh ipv6 cef

::/0

  no route

::/127

  discard

FE80::/10

  receive for Null0

FF00::/8

  multicast

FF02::/16

  Receive

 

Уберем table-map и сравним.

R7#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R7(config)#router bgp 150

R7(config-router)# address-family ipv6

R7(config-router-af)#no   table-map NO_CLIENTS_ROUTES filter

 

R7(config-router-af)#do clear ip bgp ipv6 unicast table-map

Обратите внимание, сейчас мы очищаем информацию об IPv6.

 

R7(config-router-af)#do sh ipv6 ro bgp | b B

       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1

       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP

       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination

       NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter

       OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1

       ON2 - OSPF NSSA ext 2, la - LISP alt, lr - LISP site-registrations

       ld - LISP dyn-eid, a - Application

B   2001::1/128 [200/0]

     via 1.1.1.1%default, indirectly connected

B   2001::6/128 [200/0]

     via 6.6.6.6%default, indirectly connected

B   2001::11/128 [200/1]

     via 1.1.1.1%default, indirectly connected

B   2001::14/128 [200/1]

     via 6.6.6.6%default, indirectly connected

B   2001:DB8:1:1000::/64 [200/0]

     via 1.1.1.1%default, indirectly connected

 

R7(config-router-af)#do sh ipv6 cef

::/0

  no route

::/127

  discard

2001::1/128

  nexthop 10.2.7.2 GigabitEthernet1.27 label 25() 24015()

  nexthop 10.5.7.5 GigabitEthernet1.57 label 24010() 24015()

2001::6/128

  nexthop 10.2.7.2 GigabitEthernet1.27 label 23() 30()

  nexthop 10.5.7.5 GigabitEthernet1.57 label 24008() 30()

2001::11/128

  nexthop 10.2.7.2 GigabitEthernet1.27 label 25() 24014()

  nexthop 10.5.7.5 GigabitEthernet1.57 label 24010() 24014()

2001::14/128

  nexthop 10.2.7.2 GigabitEthernet1.27 label 23() 32()

  nexthop 10.5.7.5 GigabitEthernet1.57 label 24008() 32()

2001:DB8:1:1000::/64

  nexthop 10.2.7.2 GigabitEthernet1.27 label 25() 24015()

  nexthop 10.5.7.5 GigabitEthernet1.57 label 24010() 24015()

FE80::/10

  receive for Null0

FF00::/8

  multicast

FF02::/16

  Receive

 

 

 

Эффект очевиден.

 

На этом закончим рассмотрение 6PE  и перейдем к изучению 6VPE.

Рассмотрим на примере уже знакомой нам сети с небольшими изменениями. (см. Схема 2.)

Схема 2.

 

Рассмотрим пример обмена трафиком между сетями Клиента1. Между маршрутизаторами CE14 и CE11 связность есть.

CE14#ping 2001::11 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::11, timeout is 2 seconds:

Packet sent with a source address of 2001::14

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/32 ms

 

Посмотрим, что происходит на PE4.

В отличие от реализации 6PE, в глобальной таблице маршрутизации информации  о  маршруте  до префикса 2001::11/128 нет.

 

R4(config-router-af)#do sh bgp ipv6 unicast 2001::11/128

% Network not in table

 

Все верно, мы «переместили» клиентские префиксы в VRF.

 

 

R6(config-router-af)#do sh bgp vpnv6 unicast vrf CUST1 2001::11/128

BGP routing table entry for [1:1]2001::11/128, version 60

Paths: (1 available, best #1, table CUST1)

  Not advertised to any peer

  Refresh Epoch 1

  Local

    ::FFFF:1.1.1.1 (metric 20) (via default) from 7.7.7.7 (7.7.7.7)

      Origin IGP, metric 1, localpref 100, valid, internal, best

      Extended Community: RT:1:1

      Originator: 1.1.1.1, Cluster list: 7.7.7.7

      mpls labels in/out nolabel/24017

      rx pathid: 0, tx pathid: 0x0

 

И на PE1, соответственно есть маршрут до CE14.

 

RP/0/0/CPU0:R1(config)#do sh bgp vpnv6 unicast vrf CUST1 2001::14/128

Tue Mar  7 07:58:43.138 UTC

BGP routing table entry for 2001::14/128, Route Distinguisher: 1:1

Versions:

  Process           bRIB/RIB  SendTblVer

  Speaker                 40          40

Last Modified: Mar  6 22:00:12.668 for 09:58:30

Paths: (1 available, best #1)

  Not advertised to any peer

  Path #1: Received by speaker 0

  Not advertised to any peer

  Local

    6.6.6.6 (metric 30) from 7.7.7.7 (6.6.6.6)

      Received Label 33

      Origin IGP, metric 1, localpref 100, valid, internal, best, group-best, import-candidate, imported

      Received Path ID 0, Local Path ID 1, version 40

      Extended community: OSPF router-id:6.6.6.6 OSPF route-type:0:2:0x0 RT:1:1

      Originator: 6.6.6.6, Cluster list: 7.7.7.7

      Source AFI: VPNv6 Unicast, Source VRF: CUST1, Source Route Distinguisher: 1:1

 

Судя по выводу, VPN метка равна 33, посмотрим, какая будет транспортная.

Префиксу 6.6.6.6/32 назначено 2 метки, но судя по количеству переданных байтов, сейчас используется метка 23.

 

 

RP/0/0/CPU0:R1#sh mpls forwarding prefix 6.6.6.6/32

Tue Mar  7 08:05:29.240 UTC

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24011  23          6.6.6.6/32         Gi0/0/0/0.12 10.1.2.2        113152

       24008       6.6.6.6/32         Gi0/0/0/0.15 10.1.5.5        0

 

 

 

Посмотрим, что видно в дампе Wireshark на магистральном интерфейсе PE1. (см. рис.3)

 

Рис. 3

 

Top label (транспортная) равна 23, bottom label (туннельная VPN метка) равна 33.

Приведу конфигурацию PE, CE и RR, с комментариями.

PE1

vrf CUST1

address-family ipv6 unicast

#  так как IPV4 не используется, настраиваем только IPV6 AF

  import route-target

   1:1

  !

  export route-target

   1:1

  !

 !

interface GigabitEthernet0/0/0/1.111

 vrf CUST1

 ipv6 address 2001:db8:1:1000::1/64

 encapsulation dot1q 111

!

router ospfv3 1

 router-id 1.1.1.1

 vrf CUST1

  default-information originate always

# Отдаем маршрут по умолчанию на CE

  area 0

   interface GigabitEthernet0/0/0/1.111

   !

router bgp 150

 bgp log neighbor changes detail

 address-family vpnv6 unicast

 !

 neighbor 7.7.7.7

  remote-as 150

  update-source Loopback0

  address-family vpnv6 unicast

# При конфигурации 6VPE используем AF vpvn6

  !

 !

 vrf CUST1

  rd 1:1

  address-family ipv6 unicast

   redistribute ospfv3 1

# Анонсируем маршруты с CE11

  !

 !

!

 

PE4

vrf definition CUST1

 rd 1:1

 !

 address-family ipv6

  route-target export 1:1

  route-target import 1:1

 exit-address-family

!

ipv6 unicast-routing

ipv6 cef

!

interface GigabitEthernet0/1.614

 encapsulation dot1Q 614

 vrf forwarding CUST1

 ipv6 address 2001:DB8:1:1000::6/64

 ospfv3 1 ipv6 area 0

!

router ospfv3 1

 router-id 6.6.6.6

 !

 address-family ipv6 unicast

 exit-address-family

 !

 address-family ipv6 unicast vrf CUST1

  default-information originate always

 exit-address-family

!

router bgp 150

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 150

 neighbor IBGP update-source Loopback0

 neighbor 7.7.7.7 peer-group IBGP

 !

 address-family ipv4

 exit-address-family

 !

 address-family vpnv6

  neighbor IBGP send-community extended

  neighbor 7.7.7.7 activate

 exit-address-family

 !

 address-family rtfilter unicast

# настраиваем RTC для фильтрации «ненужных» префиксов

  neighbor IBGP send-community extended

  neighbor 7.7.7.7 activate

 exit-address-family

 !

 address-family ipv6 vrf CUST1

  redistribute ospf 1

 exit-address-family

!

 

RR

router bgp 150

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 150

 neighbor IBGP update-source Loopback0

 neighbor 1.1.1.1 peer-group IBGP

 neighbor 3.3.3.3 peer-group IBGP

 neighbor 4.4.4.4 peer-group IBGP

 neighbor 6.6.6.6 peer-group IBGP

 !

 address-family ipv4

 exit-address-family

 !

 address-family vpnv6

  neighbor IBGP send-community extended

  neighbor IBGP route-reflector-client

  neighbor 1.1.1.1 activate

  neighbor 3.3.3.3 activate

  neighbor 4.4.4.4 activate

  neighbor 6.6.6.6 activate

 exit-address-family

 !

 address-family rtfilter unicast

  neighbor IBGP send-community extended

  neighbor IBGP route-reflector-client

  neighbor 3.3.3.3 activate

  neighbor 3.3.3.3 default-originate

  neighbor 4.4.4.4 activate

  neighbor 4.4.4.4 default-originate

  neighbor 6.6.6.6 activate

  neighbor 6.6.6.6 default-originate

 exit-address-family

 

 

CE11

ipv6 unicast-routing

ipv6 cef

interface Loopback0

 no ip address

 ipv6 address 2001::11/128

 ospfv3 1 ipv6 area 0

!

interface GigabitEthernet0/0.111

 encapsulation dot1Q 111

 ipv6 address 2001:DB8:1:1000::11/64

 ospfv3 1 ipv6 area 0

!

router ospfv3 1

 router-id 11.11.11.11

 !

 address-family ipv6 unicast

 exit-address-family

!

 

CE14

ipv6 unicast-routing

ipv6 cef

 

interface Loopback0

 no ip address

 ipv6 address 2001::14/128

 ospfv3 1 ipv6 area 0

!

interface GigabitEthernet0/1.614

 encapsulation dot1Q 614

 ipv6 address 2001:DB8:1:1000::14/64

 ospfv3 1 ipv6 area 0

!

router ospfv3 1

 router-id 14.14.14.14

 !

 address-family ipv6 unicast

 exit-address-family

!

 

 

Далее мы рассмотрим настройку Inter-AS 6VPE. Наш Клиент1 рос, рос и вырос, и открыл зарубежное представительство, и подключился к зарубежному оператору,  где у нашего оператора связи точки присутствия нет. Но у зарубежного оператора есть точка присутствия в нашей стране, и мы организуем присоединение к этому оператору по IPV6, для того чтобы объединить филиалы нашего клиента. Для организации присоединения будем использовать Inter-AS VPN Option A (back-to-back VRF), так как использование этой опции в данном случае представляется наиболее оптимальным с точки зрения обеспечения безопасности.

 

Сеть  выглядит следующим образом. (см. Схема 3)

Схема 3.

Разберем конфигурацию ASBR маршрутизаторов.

 

PE2 (R3)

 

vrf definition CUST1

 rd 1:1

 !

 address-family ipv6

  route-target export 1:1

  route-target import 1:1

 exit-address-family

!

!

interface GigabitEthernet1.355

 encapsulation dot1Q 355

 vrf forwarding CUST1

 ipv6 address 2001:10:3:55::3/64

!

R3#sh run | sec router bgp

router bgp 150

 bgp router-id 3.3.3.3

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 150

 neighbor IBGP update-source Loopback0

 neighbor 7.7.7.7 peer-group IBGP

 neighbor 2001:10:3:55::55 remote-as 250

 !

 address-family ipv4

 exit-address-family

 !

 address-family ipv6

  neighbor IBGP send-label

  neighbor 7.7.7.7 activate

  neighbor 2001:10:3:55::55 activate

 exit-address-family

 !

 address-family vpnv6

  neighbor IBGP send-community extended

  neighbor 7.7.7.7 activate

 exit-address-family

 !

 address-family rtfilter unicast

  neighbor IBGP send-community extended

  neighbor 7.7.7.7 activate

 exit-address-family

 !

 address-family ipv6 vrf CUST1

  neighbor 2001:10:3:55::55 remote-as 250

  neighbor 2001:10:3:55::55 activate

 exit-address-family

# Настройка соседа для обмена IPV6 маршрутами

 

 

 

Просмотр состояния соседа

R3(config-router)#do sh bgp vrf CUST1 vpnv6 unicas sum | b Nei

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

2001:10:3:55::55

                4          250      29      40       17    0    0 00:24:15        2

 

 

Несмотря на то, что мы создаем соседа в AF ipv6 vrf CUST1, просмотр осуществляется в vpnv6.

 

Маршруты до CE роутеров находятся в VRF CUST1

R3(config-router)#do sh bgp vrf CUST1 vpnv6 unicast

     Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:1 (default for vrf CUST1)

 *>i 2001::11/128     ::FFFF:1.1.1.1           1    100      0 ?

 *>i 2001::14/128     ::FFFF:6.6.6.6           1    100      0 ?

 *>  2001::15/128     2001:10:3:55::55

                                                1             0 250 ?

 *>i 2001:DB8:1:1000::/64

                       ::FFFF:1.1.1.1           0    100      0 ?

 *                    2001:10:3:55::55

                                                0             0 250 ?

 

 

Сейчас посмотрим, что происходит в AS250.

Маршруты до CE в наличии есть.

 

RP/0/0/CPU0:R55(config-bgp-af)#do sh bgp vpnv6 unicast vrf CUST1 | b Net

Tue Mar  7 11:39:06.601 UTC

   Network            Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:1 (default for vrf CUST1)

*> 2001::11/128       2001:10:3:55::3                        0 150 ?

*> 2001::14/128       2001:10:3:55::3                        0 150 ?

*> 2001::15/128       fe80::5200:ff:fe07:0

                                               1         32768 ?

*> 2001:db8:1:1000::/64

                      ::                       0         32768 ?

*                     2001:10:3:55::3                        0 150 ?

 

Processed 4 prefixes, 5 paths

 

 

 

RP/0/0/CPU0:R55(config-bgp-af)#do sh bgp vpnv6 unicast vrf CUST1 2001::14/128

Tue Mar  7 11:41:25.521 UTC

BGP routing table entry for 2001::14/128, Route Distinguisher: 1:1

Versions:

  Process           bRIB/RIB  SendTblVer

  Speaker                 20          20

    Local Label: 24003

Last Modified: Mar  7 11:24:06.578 for 00:17:19

Paths: (1 available, best #1)

  Not advertised to any peer

  Path #1: Received by speaker 0

  Not advertised to any peer

  150

    2001:10:3:55::3 from 2001:10:3:55::3 (3.3.3.3)

      Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate

      Received Path ID 0, Local Path ID 1, version 20

      Extended community: RT:1:1

 

Конфигурация маршрутизатора.

PE5 (R55)

vrf CUST1

 address-family ipv6 unicast

  import route-target

   1:1

  !

  export route-target

   1:1

  !

 !

!

interface GigabitEthernet0/0/0/0.355

 vrf CUST1

 ipv6 address 2001:10:3:55::55/64

 encapsulation dot1q 355

!

interface GigabitEthernet0/0/0/0.1555

 vrf CUST1

 ipv6 address 2001:db8:1:1000::55/64

 encapsulation dot1q 1555

!

router ospfv3 1

 router-id 55.55.55.55

 vrf CUST1

  default-information originate always

  area 0

   interface GigabitEthernet0/0/0/0.1555

   !

  !

 !

!

router bgp 250

 bgp unsafe-ebgp-policy

 address-family ipv6 unicast

 !

 address-family vpnv6 unicast

 !

 vrf CUST1

  rd 1:1

  bgp unsafe-ebgp-policy

  address-family ipv6 unicast

   redistribute ospfv3 1

  !

  neighbor 2001:10:3:55::3

   remote-as 150

   address-family ipv6 unicast

   !

  !

 !

!

Обратите внимание, трафик между автономными системами в данной конфигурации передается уже без меток, посмотрим дамп Wireshark  ICMP трафика на интерфейсе PE5, который смотрит в AS150. (см. Рис. 4)

Рис.4

 

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

CE15#ping 2001::14 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::14, timeout is 2 seconds:

Packet sent with a source address of 2001::15

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 11/20/33 ms

 

CE15#ping 2001::11 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::11, timeout is 2 seconds:

Packet sent with a source address of 2001::15

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/41/50 ms

CE15#

 

 

CE14#ping 2001::15 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::15, timeout is 2 seconds:

Packet sent with a source address of 2001::14

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 11/23/41 ms

CE14#

 

 

CE11#ping 2001::15 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::15, timeout is 2 seconds:

Packet sent with a source address of 2001::11

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 27/43/58 ms

CE11#

 

Все работает.

 

 

Подведем итог – с помощью применения технологий 6PE и 6VPE оператор связи получает возможность предоставления  своим клиентам присоединения по протоколу IPV6  без реализации IPV6 на магистральной сети. Для пропуска IPV6, трафик туннелируется в сети MPLS, на магистральной сети настраивается только IPV4+LDP.

 

 

 

538 просмотров
0 Комментариев

Довольно часто возникает ситуация, когда две или более разных автономных систем (AS) находятся под одним административным управлением. Очевидно, что для маршрутизации между AS используется BGP, тогда как для маршрутизации внутри AS – IGP, чаще всего это OSPF, либо IS-IS. Соответственно, BGP ничего «не знает» об устройстве другой AS, что может привести к неоптимальной маршрутизации.

Для решения данной проблемы был создан новый атрибут BGP – AIGP (Accumulated IGP Metric Attribute). 

Рассмотрим применение данного атрибута на практике в лабораторной сети.

Предварительно приведу краткий обзор данного атрибута

  • Опциональный (необязательный), не транзитивный (настраивается и работает только между двумя соседями)
  • Позволяет BGP принимать решение о построении кратчайшего маршрута на основании метрик IGP между двумя роутерами в разных AS

  • Основная причина появления атрибута – устранение существующих проблем с масштабированием IGP

  • Основное предназначение атрибута - передавать nexthop префиксы/метки через разные AS находящиеся под одним административным управлением

  • Удаленный PE маршрутизатор принимает решение о выборе оптимального маршрута, используя модифицированный, с учетом AIGP, процесс выбора наилучшего маршрута

  • Отправка/получение атрибута
    • конфигурируется для определенного соседа
    • по умолчанию включен для iBGP
    • по умолчанию выключен для eBGP
    • AIGP атрибут, принимаемый BGP соседом, на котором AIGP не настроен, игнорируется.

  • Способы формирования метрики AIGP
    • путем явной конфигурации
    • редистрибьюция из IGP
    • с помощью политик маршрутизации
    • изменение AIGP запускает перерасчет AIGP для маршрута
    • AIGP передаваемый между несколькими разными IGP доменами может принимать бессмысленные значения. Например, если попытаться использовать AIGP между RIP и EIGRP доменами, используя редистрибьюцию IGP метрики в AIGP, то польза от такого мероприятия будет сомнительна. Делать так не рекомендуется.

  • Модифицированная процедура выбора наилучшего маршрута
    • изменение в способе принятия решения
    • выбор происходит после сравнения local preference
    • Если у префикса присутствует атрибут AIGP
      1. Маршруты без атрибута AIGP удаляются из рассмотрения
      2. Маршруты сравниваются по кумулятивной AIGP метрике

  • Генерация обновлений
    • для соседей с настроенной передачей AIGP и не настроенной передачей AIGP формируются разные update-groups
    • обновление BGP генерируется в случае изменения значения AIGP

  • Существуют следующие возможности передачи AIGP атрибута BGP соседу, который не «понимает» AIGP
    • конвертация AIGP в атрибут cost-community
    • поддерживаются 2 POI (points-of-insertion) перед атрибутом pre-best-path и перед igp-cost. Это дает возможность использовать атрибут cost-community самым первым для вычисления лучшего маршрута до запуска основной процедуры, либо анализировать cost-community прежде igp-cost при выборе маршрута.
    • настройка атрибута cost-community транзитивным, то есть обеспечение возможности его передачи далее  по сети, другим BGP пирам, но только соседу.
    • редистрибьюция BGP (с атрибутом AIGP) в IGP
    • конвертация значения AIGP в BGP метрику (MED)
  •  Рекомендуется использовать опции BGP best-external и additional-path совместно с AIGP для обеспечения оптимальной маршрутизации

Следует отметить, что AIGP не является параметром BGP, согласуемым во время установления сессии, это дополнительный атрибут.

Давайте посмотрим, как это выглядит в дампе Wireshark.

В списке параметров BGP протокола AIGP отсутствует. ( см. рис.1 )

Рис.1

Но присутствует в списке атрибутов.  ( см. рис.2 )

Рис.2

 

Рассмотрим применение AIGP на примере следующей сети.  ( см. рис.3 )

Рис. 3

Приведу конфигурацию маршрутизаторов в нашей сети, попутно комментируя некоторые особенности конфигурации.

R1

router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 23

 neighbor IBGP update-source Loopback0

 neighbor 2.2.2.2 peer-group IBGP

 neighbor 3.3.3.3 peer-group IBGP

 !

 address-family ipv4

  neighbor IBGP aigp

# Опция aigp включает передачу атрибута AIGP между соседями.

  neighbor IBGP soft-reconfiguration inbound

  neighbor 2.2.2.2 activate

  neighbor 3.3.3.3 activate

 exit-address-family

!

 

R2

 router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 1.1.1.1 remote-as 23

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 10.2.12.12 remote-as 1213

 !

 address-family ipv4

  network 100.1.1.1 mask 255.255.255.255 route-map AIGP_METRIC

# маршрут анонсируется с использованием route-map, назначается метрика

# AIGP

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 aigp

  neighbor 1.1.1.1 next-hop-self

  neighbor 1.1.1.1 soft-reconfiguration inbound

  neighbor 10.2.12.12 activate

  neighbor 10.2.12.12 aigp

 exit-address-family

route-map AIGP_METRIC permit 10

 set aigp-metric igp-metric

# метрика AIGP копируется из IGP

 

R3

router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 1.1.1.1 remote-as 23

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 10.3.13.13 remote-as 1213

 !

 address-family ipv4

  network 100.1.1.1 mask 255.255.255.255 route-map AIGP_METRIC

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 aigp

  neighbor 1.1.1.1 next-hop-self

  neighbor 1.1.1.1 soft-reconfiguration inbound

  neighbor 10.3.13.13 activate

  neighbor 10.3.13.13 aigp

 exit-address-family

 

route-map AIGP_METRIC permit 10

 set aigp-metric igp-metric

 

 

XR12

router bgp 1213

 address-family ipv4 unicast

  network 100.4.4.4/32 route-policy SET_AIGP

# маршрут анонсируется с использованием route-map, назначается метрика

# AIGP

 !

 neighbor 4.4.4.4

  remote-as 1213

  update-source Loopback0

  address-family ipv4 unicast

   aigp

# Опция aigp включает передачу атрибута AIGP между соседями.

 

   next-hop-self

   soft-reconfiguration inbound

  !

 neighbor 10.2.12.2

  remote-as 23

  address-family ipv4 unicast

   aigp

   route-policy ALLOW(Lo100_R1) in

# Используется RPL для того чтобы принимать только анонс префикса

# 100.1.1.1

   route-policy RPL_PASS out

prefix-set Lo100_R1

  100.1.1.1/32

end-set

!

route-policy ALLOW($PREFIX)

  if destination in $PREFIX then

    pass

  endif

end-policy

!

# Создание политики с помощью механизма параметризации позволяет

# динамически передавать в политику конкретные значения

 

route-policy RPL_PASS

  pass

end-policy

!

route-policy SET_AIGP

  set aigp-metric igp-cost

end-policy

!

 

 

XR13

router bgp 1213

 bgp unsafe-ebgp-policy

# Как известно, IOX-XR не устанавливает отношения соседства еBGP, если

# отсутствуют политики, привязанные к соседу.

# Использование команды bgp unsafe-ebgp-policy позволяет обойти это

# ограничение и настроить соседа eBGP без использования политик.

# Крайне НЕ РЕКОМЕНДУЕТСЯ использовать где-либо кроме лабораторной

# сети!

 

 address-family ipv4 unicast

  network 100.4.4.4/32 route-policy SET_AIGP

 !

 neighbor 4.4.4.4

  remote-as 1213

  update-source Loopback0

  address-family ipv4 unicast

   aigp

   next-hop-self

  !

 !

 neighbor 10.3.13.3

  remote-as 23

  address-family ipv4 unicast

   aigp

  !

route-policy SET_AIGP

  set aigp-metric igp-cost

end-policy

!

 

 

R4

router bgp 1213

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 1213

 neighbor IBGP update-source Loopback0

 neighbor 12.12.12.12 peer-group IBGP

 neighbor 13.13.13.13 peer-group IBGP

 !

 address-family ipv4

  neighbor IBGP aigp

  neighbor 12.12.12.12 activate

  neighbor 13.13.13.13 activate

 exit-address-family

 

 

 

 

 

Посмотрим, как видят маршруты до друг друга R1 и R4.

 

 

 

R1#show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 32

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 1

  1213, (received & used)

    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)

      Origin IGP, aigp-metric 20, metric 20, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 3

  1213, (received & used)

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, aigp-metric 10, metric 10, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

На R1 меньше стоимость и более предпочтительный маршрут до 100.4.4.4 через R3, что также подтверждается выводом traceroute.

 

 

 

R1#tra 100.4.4.4 so lo100

Type escape sequence to abort.

Tracing the route to 100.4.4.4

VRF info: (vrf in name/id, vrf out name/id)

  1 10.1.3.3 7 msec 11 msec 12 msec

  2 10.3.13.13 9 msec 9 msec 8 msec

  3 10.4.13.4 17 msec *  12 msec

 

 

R4#show bgp ipv4 unicast 100.1.1.1/32

BGP routing table entry for 100.1.1.1/32, version 38

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 1

  23

    13.13.13.13 (metric 20) from 13.13.13.13 (13.13.13.13)

      Origin IGP, aigp-metric 11, metric 11, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 1

  23

    12.12.12.12 (metric 10) from 12.12.12.12 (12.12.12.12)

      Origin IGP, aigp-metric 31, metric 31, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

На R4 маршрут до R1 лучше через R13, так как стоимость меньше.

 

 

 

R4#traceroute 100.1.1.1 source loopback 100

Type escape sequence to abort.

Tracing the route to 100.1.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1 10.4.13.13 9 msec 6 msec 4 msec

  2 10.3.13.3 12 msec 13 msec 7 msec

  3 10.1.3.1 8 msec *  17 msec

 

 

 

Попробуем изменить стоимость IGP на линке между R1 и R3, чтобы трафик с R4 шел через R12. Настроим OSPF cost 50. Предварительно включим debug на R4, и проанализируем, какие обновления придут на роутер.

 

 

 

R4#deb ip bgp ipv4 unicast updates

 

 

 

Как и ожидалось, пришел апдейт, в котором содержится новое значение AIGP метрики.

 

 

 

R4#

*Mar  2 14:18:39.057: BGP(0): 13.13.13.13 rcvd UPDATE w/ attr: nexthop 13.13.13.13, origin i, localpref 100, metric 51, aigp-metric 51, merged path 23, AS_PATH

*Mar  2 14:18:39.057: BGP(0): 13.13.13.13 rcvd 100.1.1.1/32

*Mar  2 14:18:39.058: BGP(0): Revise route installing 1 of 1 routes for 100.1.1.1/32 -> 12.12.12.12(global) to main IP table

R4#

 

 

 

Также поменялся лучший маршрут до R1.

 

 

 

R4#show bgp ipv4 unicast 100.1.1.1/32

BGP routing table entry for 100.1.1.1/32, version 39

Paths: (2 available, best #2, table default)

  Not advertised to any peer

  Refresh Epoch 1

  23

    13.13.13.13 (metric 20) from 13.13.13.13 (13.13.13.13)

      Origin IGP, aigp-metric 51, metric 51, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 1

  23

    12.12.12.12 (metric 10) from 12.12.12.12 (12.12.12.12)

      Origin IGP, aigp-metric 31, metric 31, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

 

 

 

Посмотрим, что происходит, если один BGP сосед передает AIGP, в то время как другой сосед не «понимает» AIGP.

 

 

 

 

Отключим AIGP на R4 и перезапустим BGP сессию на R13, предварительно включив debug на R4

 

 

 

 

R4#deb ip bgp ipv4 unicast updates 13.13.13.13

*Mar  2 11:25:15.770: BGP: 13.13.13.13 Ignoring AIGP attribute because Address family doesn't support

 

 

 

Как ожидалось, R4 игнорирует AIGP.

 

 

 

 

Иногда может возникнуть ситуация когда нам требуется игнорировать атрибут AIGP, который передает нам соседний маршрутизатор. В этом случае, используется команда bgp bestpath aigp ignore. Если роутер получает два маршрута и при этом один из них имеет метрику AIGP, а другой нет, то метрика AIGP при вычислении лучшего маршрута игнорируется. Расмотрим работу этой опции на R1.

 

 

 

router bgp 23

 bgp log-neighbor-changes

 bgp bestpath aigp ignore

 

 

 

Сейчас лучший маршрут на 100.4.4.4 идет через R3, так как AIGP метрика ниже.

 

 

 

R1(config-router)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 43

BGP Bestpath: aigp-ignore

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 1

  1213, (received & used)

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, aigp-metric 30, metric 30, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 3

  1213, (received & used)

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, aigp-metric 60, metric 60, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Отключим передачу AIGP между R1 и R3.

Проверим, согласно метрике IGP в AS23 лучшим маршрутом должен стать маршрут через R2.

 

 

 

R1(config-router-af)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 57

BGP Bestpath: aigp-ignore

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 3

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 30, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 2

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, aigp-metric 60, metric 60, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Вопреки ожиданиям, лучшим маршрутом остался маршрут через R3. Похоже, что ожидания не вполне соответствуют описанному в документации.

В документации сказано следующее

 

 

 

If this knob is enabled, then the BGP does not use AIGP tie-breaking unless both of the paths have the AIGP metric attribute. This means that the AIGP attribute is not evaluated during the best path selection process between two paths when one path does not have the AIGP attribute.

 

 

 

То есть  AIGP не учитывается при вычислении маршрута, если один префикс не имеет атрибута.

В нашем случае, один маршрут приходит с  атрибутом AIGP, другой нет, тем не менее, маршрут с AIGP все равно «выигрывает».

 

 

 

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

 

 

 

R1(config-router)#bgp bestpath ?

  aigp              if both paths doesn't have aigp ignore on bestpath

                    comparision

 

 

 

Маршрутизатор показывает,  что игнорирование AIGP произойдет, если оба маршрута не имеют AIGP, что в-общем логично, так как и нечего сравнивать. Попробуем отключить AIGP и между R1 и R2.

Проверяем.

 

 

 

R1(config-router)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 60

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 3

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 30, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 3

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 60, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Несмотря на то, что IGP метрика до R2 лучше, лучший маршрут до  R4 все равно идет через R3.

Это происходит потому что, BGP метрика через  R3 меньше. Но мы отключили использование AIGP метрики, попытаемся разобраться, почему меняется MED.

Между R2 и R1 AIGP не передается, но передается между XR12 и R2.

 

 

 

 

Посмотрим на дамп трафика между XR12 и R2.  ( см рис.4 )

Рис.4

 

 

 

 

XR12 отправляет MED=60, это значение IGP метрики настроенное между XR12 и R4. Судя по всему,

IOS  копирует значение метрики IGP в атрибут MED по умолчанию, хотя мы и не настраивали такое поведение. Дело в том, что при анонсировании префикса с помощью команды network, как сделано в нашем примере, метрика IGP автоматически копируется в атрибут BGP MED. Попытаемся изменить данное поведение, установив на XR12 значение метрики вручную, путем редактирования route-policy SET_AIGP

 

 

 

RP/0/0/CPU0:XR12(config)#route-policy SET_AIGP

Fri Mar  3 08:16:12.738 UTC

% WARNING: Policy object route-policy SET_AIGP' exists! Reconfiguring it via CLI will replace current definition. Use 'abort to cancel.

RP/0/0/CPU0:XR12(config-rpl)#

 

 

 

 

Ошибка.

 

 

 

 

Дело в том, что редактирование политик в IOS-XR производится несколько другим способом, путем запуска редактора

 

 

 

RP/0/0/CPU0:XR12#edit route-policy SET_AIGP

Fri Mar  3 08:18:29.049 UTC

[OK]

  GNU nano 2.0.2          File: /tmp/rpl_edit.1409188

 

route-policy SET_AIGP

  set aigp-metric igp-cost

  set med 0

end-policy

!

 

                               [ Wrote 5 lines ]

 

Proceed with commit (yes/no/cancel)? [cancel]: yes

Parsing.

74 bytes parsed in 1 sec (72)bytes/sec

Committing.

Prepared commit in 0 sec

 

1 items committed in 1 sec (0)items/sec

 

 

 

Также возможно изменять значение MED при входе в AS, и пожалуй, так даже правильнее, во избежание путаницы. Сделаем это на R3, для маршрутов, полученных с XR13.

 

 

 

 

route-map SET_MED permit 10

 set metric 0

 

router bgp 23

neighbor 10.3.13.13 remote-as 1213

 !

 address-family ipv4

  …

 neighbor 10.3.13.13 activate

  neighbor 10.3.13.13 aigp

  neighbor 10.3.13.13 soft-reconfiguration inbound

  neighbor 10.3.13.13 route-map SET_MED in

 

 

 

 

Проверим маршрут на R1

 

 

 

R1(config-router-af)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 68

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 9

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 0, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 6

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 0, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Сейчас маршрутизируется, так как нам и требовалось, через R2, согласно IGP метрике.

 

 

 

 

Кратко рассмотрим использование атрибута Cost Community. Предположим, что R1 старый роутер, и не поддерживает AIGP, но есть потребность маршрутизировать трафик с учетом метрик IGP.

На R2 и R3 настроим передачу AIGP в атрибуте Cost Community

 

 

 

R2, R3

router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 1.1.1.1 remote-as 23

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 10.2.12.12 remote-as 1213

 !

 address-family ipv4

  network 100.1.1.1 mask 255.255.255.255 route-map AIGP_METRIC

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 send-community both

  neighbor 1.1.1.1 aigp send cost-community 100 poi igp-cost transitive

 

 

 

Так как передача информации осуществляется в расширенной community, надо обратить внимание и не забыть передачу расширенной community соседу, при помощи команды send-community extended или send-community both, как в  нашем примере.

 

 

 

Проверим маршрутизацию на R1.

 

 

 

R1(config-router-af)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 63

Paths: (2 available, best #2, table default)

  Not advertised to any peer

  Refresh Epoch 7

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 60, localpref 100, valid, internal

      Extended Community: Cost(transitive):igp:100:60

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 3

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 30, localpref 100, valid, internal, best

      Extended Community: Cost(transitive):igp:100:30

      rx pathid: 0, tx pathid: 0x0

 

 

 

Значения AIGP копируются в Extended Community и позволяют осуществлять манипуляцию трафиком на основании значения AIGP атрибута.

 

 

Подведем итог –  использование дополнительных атрибутов AIGP и cost-community позволяет осуществлять более гибкое управление трафиком между автономными системами, так как позволяет передавать информацию об IGP метриках в BGP протоколе.

 

778 просмотров
0 Комментариев

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

Существует несколько способов фильтрации нежелательных префиксов в сетях с использованием Route Reflector. Мы разберем два из них.

1. Для префиксов VPNV4/6 будет рассмотрено применение механизма Route Target Constraint
2. Для префиксов IPV4/6 рассмотрим применение механизма Selective RIB download.

1. Route Target Constraint (RTC)

Принципы функционирования данного способа фильтрации описаны в RFC 4684.
Суть проблемы в сети без использования фильтрации заключается в следующем: если в сети MPLS VPN используется Route Reflector(RR), то при отправке маршрутов в сторону PE route reflector передает все полученные префиксы, независимо от того, создан на PE vrf или нет.
Несмотря на то, что PE маршрутизатор определяет, что данные префиксы не нужны и отбрасывает «ненужные» префиксы, тем не менее, процесс отправки всех префиксов повышает как нагрузку на сеть, так и нагрузку на CPU PE и RR.
При использовании механизма RTC RR оправляет на PE только те префиксы, для которых на PE настроен импорт. Для обеспечения данного механизмы была разработана специальная Address Family – rtfilter.
Рассмотрим работу механизма на примере следующей сети

В качестве IGP протокола в нашей сети используется OSPF.
Между PE и CE настроены как OSPF, так и статическая маршрутизация.
Рассмотрим, как работает фильтрация между PE4 и PE1, между маршрутизаторами настроен VPN в котором «ходит» трафик ограниченный VRF GREEN.

Настройка MPLS L3 VPN тривиальна и не таит никаких сюрпризов.

R1
vrf definition GREEN
rd 2:2
!
address-family ipv4
route-target export 2:2
route-target import 2:2
exit-address-family


interface GigabitEthernet1.1245
encapsulation dot1Q 1245
ip address 10.12.45.1 255.255.255.0
!
interface GigabitEthernet2.111
encapsulation dot1Q 111
vrf forwarding GREEN
ip address 10.21.11.1 255.255.255.0
ip ospf 21 area 0
!

router ospf 21 vrf GREEN
default-information originate always
!
router ospf 1
router-id 1.1.1.1
network 0.0.0.0 255.255.255.255 area 0
mpls ldp autoconfig
!
router bgp 1245
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 1245
neighbor 5.5.5.5 update-source Loopback0
!
address-family vpnv4
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family
!
address-family ipv4 vrf GREEN
redistribute connected
redistribute ospf 21
exit-address-family


R4
vrf definition GREEN
rd 2:2
!
address-family ipv4
route-target export 2:2
route-target import 2:2
exit-address-family
!

interface GigabitEthernet1.1245
encapsulation dot1Q 1245
ip address 10.12.45.4 255.255.255.0
!
interface GigabitEthernet1.2414
encapsulation dot1Q 2414
vrf forwarding GREEN
ip address 10.24.14.4 255.255.255.0
ip ospf 21 area 0
!
…..
router ospf 21 vrf GREEN
default-information originate always
!
router ospf 1
router-id 4.4.4.4
network 0.0.0.0 255.255.255.255 area 0
mpls ldp autoconfig
!
router bgp 1245
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 1245
neighbor 5.5.5.5 update-source Loopback0
!
address-family vpnv4
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family
!
address-family ipv4 vrf GREEN
redistribute connected
redistribute ospf 21
exit-address-family

Связность между CE есть.

R11#ping 14.14.14.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 14.14.14.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 15/24/40 ms

RP/0/0/CPU0:XR14#ping 11.11.11.11
Mon Feb 27 08:47:37.102 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 19/25/29 ms

Посмотрим, что произойдет, если мы добавим на PE4 еще vrf и произведем редистрибьюцию маршрутов. Предварительно включим на PE1 debug.

R1#debug ip bgp vpnv4 unicast updates
BGP updates debugging is on for address family: VPNv4 Unicast

PE4
R4(config-router-af)#do sh run vrf RED
Building configuration...

Current configuration : 408 bytes
vrf definition RED
rd 1:1
!
address-family ipv4
route-target export 1:1
route-target import 1:1
exit-address-family
!
interface GigabitEthernet1.1414
encapsulation dot1Q 1414
vrf forwarding RED
ip address 10.14.14.4 255.255.255.0
!
router bgp 1245
!
address-family ipv4 vrf RED
redistribute connected
exit-address-family
!
end

После конфигурации на PE4 vrf RED в логах PE1 видно следующее

R1#
*Feb 27 09:28:36.212: BGP(4): 5.5.5.5 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin ?, localpref 100, metric 0, originator 4.4.4.4, clusterlist 5.5.5.5, extended community RT:1:1
*Feb 27 09:28:36.212: BGP(4): 5.5.5.5 rcvd 1:1:10.14.14.0/24, label 19 -- DENIED due to: extended community not supported;
R1#

Как видно из вывода, Route Reflector отправляет на PE «ненужные» маршруты.
Настроим опцию RTC и сравним результаты. Для работы данного механизма необходимо чтобы оба соседа BGP, как RR так и PE поддерживали AF rtfilter.

Сначала отключим редистрибьюцию в VRF RED на PE4

R4(config-router-af)#address-family ipv4 vrf RED
R4(config-router-af)#no redistribute connected

Добавим на RR, PE1, PE4 address-family rtfilter.


PE1
address-family rtfilter unicast
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family

PE4
address-family rtfilter unicast
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family

RR
address-family rtfilter unicast
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 default-originate
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community extended
neighbor 4.4.4.4 route-reflector-client
neighbor 4.4.4.4 default-originate
exit-address-family

Вернем редистрибьюцию маршрутов на PE4.

PE4
address-family ipv4 vrf RED
redistribute connected
exit-address-family

При этом на PE1, какие либо сообщения о том, что пришли «ненужные» маршруты не видны.

Стоит отметить что, конфигурация на IOS-XR отличается, приведу конфигурацию опции на IOS-XR (PE3)

IOS-XR
router bgp 1245
bgp router-id 3.3.3.3
bgp log neighbor changes detail
address-family vpnv4 unicast
!
address-family ipv4 rt-filter
!
neighbor 5.5.5.5
remote-as 1245
update-source Loopback0
address-family vpnv4 unicast
!
address-family ipv4 rt-filter
!
!
vrf BLACK
rd 4:4
address-family ipv4 unicast
!

Работа данного механизма также возможна при отсутствии поддержки AF rtfilter в коде какого-либо PE маршрутизатора на сети. Например, если в сети есть старый маршрутизатор, на который нет возможности установить современную IOS. Рассмотрим ситуацию, когда на PE1 есть поддержка AF rtfilter, а на PE4 нет.

RR
address-family rtfilter unicast
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 default-originate
exit-address-family

PE1
address-family rtfilter unicast
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family

PE4
address-family vpnv4
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
exit-address-family


Проверим наличие апдейтов на PE1, после того как отключим и обратно включим редистрибьюцию на PE4.


R1(config-router-af)#do sh deb
IOSXE Conditional Debug Configs:

Conditional Debug Global State: Stop

IOSXE Packet Tracing Configs:

IP routing:
BGP updates debugging is on for address family: VPNv4 Unicast
R1(config-router-af)#

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

Перейдем к рассмотрению следующего механизма.

2. Selective RIB download

             Использование данной опции позволяет не осуществлять программирование RIB на route reflector, route reflector в данном случае передает BGP маршруты клиентам, не загружая данные маршруты в свою собственную таблицу маршрутизации.
             Данная опция может быть полезна в случае, если трафик не проходит через route reflector (out of band RR). Также стоит отметить, что в случае если route reflector редистрибьютит маршруты только в сети MPLS VPN, применение данной опции не требуется, так как для MPLS VPN маршрутов опция активна по умолчанию, RR не загружает в RIB MPLS VPN префиксы.
             Для включения данной опции применяется команда table-map. Прежде чем продолжить, следует отметить особенности применения данной команды. Она может применяться как с опцией filter, так и без нее. Если filter НЕ используется, то маршруты всегда загружаются в RIB, независимо от того используется deny в route-map или нет, route-map используется лишь для изменения характеристик префиксов. В случае применения filter, префиксы фильтруются с использованием route-map, либо все, либо только определенные.

            Рассмотрим на примере знакомой нам сети, поменяем конфигурацию, удалим конфигурацию MPLS VPN, оставим IPV4. Следует заметить, что в контексте данной сети, с несколькими AS, наименования маршрутизаторов CE и PE не совсем корректны, но думаю это не вызовет затруднений при анализе схемы.

Связность между различными AS есть, CE маршрутизаторы видят друг друга.

R11(config-router)#do p 13.13.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/26 ms

R11(config-router)#do p 14.14.14.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 14.14.14.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/17/26 ms

RP/0/0/CPU0:XR14#ping 13.13.13.13
Mon Feb 27 12:06:43.814 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/29/59 ms

RP/0/0/CPU0:XR14#ping 11.11.11.11
Mon Feb 27 12:06:52.693 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/9/9 ms

Трафик через RR не проходит, RR в нашей сети является выделенным (dedicated), также используется термин out-of-band.

RP/0/0/CPU0:XR14#traceroute 11.11.11.11
Mon Feb 27 12:08:20.577 UTC

Type escape sequence to abort.
Tracing the route to 11.11.11.11

1 10.24.14.4 9 msec 0 msec 0 msec
2 10.12.45.1 19 msec 29 msec 9 msec
3 10.21.11.11 39 msec * 9 msec

R13#traceroute 14.14.14.14
Type escape sequence to abort.
Tracing the route to 14.14.14.14
VRF info: (vrf in name/id, vrf out name/id)
1 10.43.13.3 11 msec 11 msec 18 msec
2 10.12.45.4 19 msec 42 msec 23 msec
3 10.24.14.14 [AS 414] 26 msec * 34 msec

Тем не менее, RR хранит всю информацию в своих таблицах RIB и FIB.

R5(config-router-af)#do sh ip ro bgp | b Gateway
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
B 10.9.14.0/24 [200/0] via 4.4.4.4, 00:00:13
B 10.13.14.0/24 [200/0] via 4.4.4.4, 00:00:13
B 10.14.14.0/24 [200/0] via 4.4.4.4, 00:00:13
B 10.21.11.0/24 [200/0] via 1.1.1.1, 00:00:13
B 10.24.14.0/24 [200/0] via 4.4.4.4, 00:00:13
B 10.43.13.0/24 [200/0] via 3.3.3.3, 00:00:13
11.0.0.0/32 is subnetted, 1 subnets
B 11.11.11.11 [200/0] via 1.1.1.1, 00:00:13
13.0.0.0/32 is subnetted, 1 subnets
B 13.13.13.13 [200/0] via 3.3.3.3, 00:00:13
14.0.0.0/32 is subnetted, 1 subnets
B 14.14.14.14 [200/0] via 4.4.4.4, 00:00:13


R5#sh ip cef 13.13.13.13
13.13.13.13/32
nexthop 10.12.45.3 GigabitEthernet1.1245

R5#sh ip cef 11.11.11.11
11.11.11.11/32
nexthop 10.12.45.1 GigabitEthernet1.1245
R5#

Настроим фильтрацию на RR.

Создаем route-map для фильтрации всех префиксов.

R5(config)#route-map block-into-rib deny 10

Применяем команду table-map.

R5(config-route-map)#router bgp 1245
R5(config-router)#address-family ipv4 unicast
R5(config-router-af)#table-map block-into-rib filter
R5(config-router-af)#end

Обновляем таблицы BGP используя table-map.

R5#clear ip bgp ipv4 unicast table-map

Проверим наличие информации в памяти маршрутизатора.


R5(config-router-af)#do sh ip ro bgp | b Gateway
Gateway of last resort is not set


R5#sh ip cef 11.11.11.11
0.0.0.0/0
no route
R5#sh ip cef 13.13.13.13
0.0.0.0/0
no route

Память освободили, информации на RR нет, тем не менее, связность между конечными узлами не пропала.

R13#trac 11.11.11.11 so lo0
Type escape sequence to abort.
Tracing the route to 11.11.11.11
VRF info: (vrf in name/id, vrf out name/id)
1 10.43.13.3 13 msec 13 msec 21 msec
2 10.12.45.1 [AS 1245] 30 msec 20 msec 55 msec
3 10.21.11.11 [AS 1245] 30 msec * 10 msec

R13#trac 14.14.14.14 so lo0
Type escape sequence to abort.
Tracing the route to 14.14.14.14
VRF info: (vrf in name/id, vrf out name/id)
1 10.43.13.3 13 msec 6 msec 5 msec
2 10.12.45.4 [AS 1245] 15 msec 25 msec 16 msec
3 10.24.14.14 [AS 1245] 18 msec * 13 msec

RP/0/0/CPU0:XR14#tra 13.13.13.13 source 14.14.14.14
Mon Feb 27 12:54:40.876 UTC

Type escape sequence to abort.
Tracing the route to 13.13.13.13

1 10.24.14.4 9 msec 0 msec 19 msec
2 10.12.45.3 49 msec 29 msec 49 msec
3 10.43.13.13 39 msec * 9 msec


RP/0/0/CPU0:XR14#tra 11.11.11.11 source 14.14.14.14
Mon Feb 27 12:54:55.235 UTC

Type escape sequence to abort.
Tracing the route to 11.11.11.11

1 10.24.14.4 19 msec 19 msec 0 msec
2 10.12.45.1 59 msec 69 msec 19 msec
3 10.21.11.11 19 msec * 9 msec

Для работы данного механизма, также необходимо, чтобы на ASBR маршрутизаторах была включена опция next-hop-self, в нашем случае это PE роутеры.


IOS
PE1
router bgp 1245
bgp log-neighbor-changes
redistribute connected
neighbor 5.5.5.5 remote-as 1245
neighbor 5.5.5.5 update-source Loopback0
neighbor 5.5.5.5 next-hop-self
neighbor 10.21.11.11 remote-as 111

IOS-XR
PE3
router bgp 1245
bgp router-id 3.3.3.3
bgp log neighbor changes detail
address-family ipv4 unicast
redistribute connected
!
neighbor 5.5.5.5
remote-as 1245
update-source Loopback0
address-family ipv4 unicast
next-hop-self
!
!
neighbor 10.43.13.13
remote-as 313
address-family ipv4 unicast
route-policy RPL_PASS in
route-policy RPL_PASS out
!

Данной конфигурацией мы добились фильтрации всех префиксов на RR, но как очевидно из названия опции она позволяет загружать именно выделенные префиксы. Это может потребоваться, в случае если все же RR требуется иметь информацию об определенных маршрутах. Рекомендуется делать это при помощи привязки community к нужным префиксам на ASBR и фильтрации на RR по определенной community.

Кратко рассмотрим избранную фильтрацию. Позволим RR видеть сеть между PE1 и CE1. Сейчас этой информации в таблице маршрутизации RR нет.

R5(config-router-af)#do sh ip ro 10.21.11.1
% Subnet not in table
R5(config-router-af)#do sh ip ro 10.21.11.11
% Subnet not in table


Создадим на ASBR (в нашем случае это PE1) prefix-list и route-map и применим к нужных префиксам


R1(config)#ip prefix-list r1_r11_net permit 10.21.11.0/24

R1(config)#route-map connected_routes permit 10
R1(config-route-map)# match ip address prefix-list r1_r11_net
R1(config-route-map)# set community 1245:100

R1(config-route-map)#router bgp 1245
R1(config-router)# address-family ipv4
R1(config-router-af)#redistribute connected route-map connected_routes

Надо отметить, что как правило, при конфигурации ipv4 соседа, параметр community по умолчанию не добавляется, поэтому необходимо добавить его. Иначе схема работать не будет, так как PE1 не будет отправлять community на RR.

R1(config-router-af)#neighbor 5.5.5.5 send-community extended

На RR отфильтруем префиксы по community 1245:100 и загрузим эти префиксы в RIB.

R5(config)#ip community-list 100 permit 1245:100

R5(config)#route-map routes_r1_r11
R5(config-route-map)#match community 100

R5(config-route-map)#router bgp 1245
R5(config-router)# address-family ipv4
R5(config-router-af)#table-map routes_r1_r11 filter

R5(config-router-af)#do clear ip bgp ipv4 unicast table-map

Как видно нужная информация загрузилась, все остальные, «ненужные» маршруты отсутствуют.

R5(config-router-af)#do sh ip ro 10.21.11.1
Routing entry for 10.21.11.0/24
Known via "bgp 1245", distance 200, metric 0, type internal
Last update from 1.1.1.1 00:00:44 ago
Routing Descriptor Blocks:
* 1.1.1.1, from 1.1.1.1, 00:00:44 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: none

R5(config-router-af)#do sh ip ro bgp | b Gateway
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.21.11.0/24 [200/0] via 1.1.1.1, 00:00:13

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

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

2538 просмотров
1 Комментарии

В прошлой статье мы рассмотрели основные принципы построения домена маршрутизации IS-IS. В этой мы рассмотрим процесс установления IS-IS соседства между маршрутизаторами. Стоит напомнить, что в link state протоколах маршрутизации соседства между маршрутизаторами (или как их еще называют, adjacency), являются фундаментальным компонентом протокола. Ведь именно благодаря тому, что маршрутизаторы "знают", с какими соседними устройствами они взаимодействуют, возможно полное описание топологии в памяти каждого маршрутизатора. В OSPF процесс установления соседских отношений достаточно сложен, и в ходе этого процесса adjacency может находиться в одном из семи состояний (Down, Init, 2Way, ExStart, Exchange, Loading и Full). В период установления OSPF соседства маршрутизаторы обмениваются всеми типами OSPF сообщений, и по окончании процесса их базы данных топологий оказываются полностью синхронными. Собственно поэтому последнее состояние и называется Full - Fully Synchronized или Fully Adjacent. Напомним, что в OSPF формирование соседства между парой маршрутизаторов начинается с обмена сообщениями Hello, которые рассылаются с определенным периодом через интерфейсы, на которых был запущен протокол. Формат этого сообщения строго определен, и значения ряда параметров в Hello от разных маршрутизаторов должны совпадать для того, что чтобы формирование соседства продолжалось.


IS-IS adjacency


 IS-IS также формирует соседства благодаря обмену сообщениями IS-IS Hello (IIH), но в отличие от OSPF, IS-IS имеет три разных типа Hello сообщений. Для рассылки Hello на широковещательных и на Point-to-Point интерфейсах в IS-IS используются разные типы Сообщений. Помимо этого Hello для широковещательных интерфейсов делятся на два типа: Level 1 и Level 2. В итоге можно сказать, что мы имеем дело со следующими типами IS-IS Hello (или как их еще называют IIH):

  1. Point-to-Point
  2. L1 LAN
  3. L2 LAN

 Такой набор IIH, кстати, как раз и делает возможным формирование соседств разных уровней (L1 или L2) на широковещательных интерфейсах между парой устройств. Тут стоит обратить внимание что в протоколе присутствует только один тип IIH для Point-to-Point интерфейсов. Это однако не значит, что на таких интерфейсах невозможно формирование соседств, отличающихся по уровням. Очень даже возможно, просто механизм формирования соседств разных уровней выглядит несколько по-другому. Создатели протокола решили, что по определению через широковещательный интерфейс маршрутизатор может взаимодействовать с несколькими устройствами (другими маршрутизаторами) одновременно (в рамках одного VLAN, например). И с разными устройствами могут понадобиться соседства разных уровней. Поэтому создание двух типов Hello для широковещательных интерфейсов выглядит достаточно логичным. На P2P интерфейсах сосед у маршрутизатора может быть только один, поэтому с созданием разных типов P2P Hello решили не заморачиваться. Формирование либо L1, либо L2 соседства происходит в зависимости от параметров внутри P2P Hello сообщения.
 Какие именно IIH будут рассылаться маршрутизатором через интерфейс, на котором запущен IS-IS, определяется конфигурацией маршрутизатора или интерфейса (в прошлой статье мы рассматривали примеры управления уровнем соседств). Напомним, что на самых распространенных на данный момент (Ethernet) интерфейсах маршуризаторы по умолчанию рассылают L1 LAN и L2 LAN Hello.
 Для наглядности приведем формат сообщений LAN Hello и Point-to-Point Hello.



 Cледует обратить внимание на то, что IIH не содержат значения Hello интервала, в отличие от OSPF. Напомню, что сообщение Hello протокола OSPF содержит значение Hello interval, настроенного на интерфейсе маршрутизатора, и для успешного формирования OSPF соседства значения Hello интервалов разных маршрутизаторов должны совпадать. В Hello сообщениях протокола IS-IS из таймеров присутствует только Holding timer (аналог OSPF Dead interval). В целом это логично: маршрутизатору не нужно знать, насколько часто сосед будет присылать ему Hello. Все что ему нужно знать - это сколько стоит ждать получения следующего IIH.
 Также следует отметить, что формат IIH предусматривает наличие в их структуре различных TLV. Использование этих структур как раз и делает протокол хорошо расширяемым и пригодным для добавления функционала в будущем.
  Рассмотрим, например, как выглядит формирование соседства на широковещательных интерфейсах, и какие TLV при этом используются.
  Итак, как мы уже определились, маршрутизаторы на начальном этапе формирования соседских отношений обмениваются Hello сообщениями. На самом начальном этапе соседство находится в состоянии Down. Это состояние означает, что маршрутизатор рассылает IIH, но пока не получает ни одного IIH от соседа. Такие IIH выглядят так (ниже IIH, сгенерированный маршрутизатором R2 из топологии, показанной выше).



  Когда будет получено первое IIH от соседа, маршрутизатор R1 запоминает МАС адрес отправителя IIH (МАС R2 в данном примере равен c202.1b70.0000) и переводит соседство в состояние Initializing. Это состояние означает, что маршрутизатор "слышит" Hello соседа, но не уверен, что двухстороннее взаимодействие между ним и соседом на данный момент налажено. После этого R1 в свои IIH добавляет в специальный TLV (IS Neighbor TLV) МАС адрес соседа(R2) и результат отправляет обратно:



  Когда R2 получит IIH, в котором присутствует IS Neighbor TLV с его собственным локальным МАС адресом, он может быть уверен, что соседнее устройство дейтсвительно получало его собственные IIH, а значит имеет место двухсторонее взаимодействие между устройствами, что является поводом для перевода соседства в состояние Up. Для того, чтобы R1 тоже мог убедиться в наличии двухстороннего взаимодействия, R2 выполняет те же действия с использованием IS Neighbor TLV (МАС адрес маршрутизатора R1 в нашем примере равен c201.1b50.0000):



  Этот процесс называется трехсторонним рукопожатием (Three-way handshake). Но для того, чтобы все закончилось благополучно, и мы могли утверждать, что соседство сформировалось, маршрутизаторы еще должны согласовать уровень соседства, которое они друг с другом формируют. Поэтому если сосед присылал L1 LAN Hello, то маршрутизатор проверяет значение еще одного TLV, которое включается в IIH - Area Addresses TLV (показано в примерах выше). Если значение Area ID, заявленное в этом TLV, совпадает с локальным значением Area ID маршрутизатора, то формируется соседство уровня 1. Если совпадения нет, соседство L1 не формируется. Интересно, что если входящим IIH являлся L2 LAN, то подобная проверка попросту не производится.
  На Point-to-point линках данный процесс происходит подобным образом с той лишь разницей, что в Point-to-Point IIH не включаются IS Neighbor TLV. Расчет создателей протокола тут, видимо, был основан на том, что P2P линки, поверх которых будет работать IS-IS, будут надежными, и двухсторонее взаимодействие просто допускается. В целом это достаточно смелое допущение, поэтому существует RFC 3373, которая стандартизует Point-to-Point Three-Way Adjacency TLV, которая может включаться маршрутизаторами в P2P IIH для подтверждения возможности двухстороннего обмена между соседями. Формат этой TLV представлен ниже:



 Здесь мы находим поле Neighbor System ID, которое используется для подтверждения двухстороннего взаимодействия. Поддержка этой TLV позволяет соседним маршрутизаторам организовать 3-way handshake на p2p линках.
 Само собой поддержка этой TLV является опциональной, и если один из маршрутизаторов ее не поддерживает, то проблем не возникает: та сторона, которая не поддерживает, просто игнорирует эту TLV во входящих IIH; сторона, которая поддерживает, но не получает, будет работать в режиме Two-way handshake вместо Three-way. Как можно увидеть ниже, на маршрутизаторах Cisco данная TLV поддерживается, но ее формат по какой-то причине отличается от стандартного:



 Проверка уровня взаимодействия на таких линках также производится: видим, что P2P IIH содержат в заголовке поле Circuit type (в нашем примере оно выставлено в Level 1 only), которое как раз и позволяет обозначить уровень соседства, запрашиваемого маршрутизатором.
DR и DIS
 Стоит вспомнить, что при формировании соседств OSPF на широковещательных линках происходят выборы DR и BDR (Designated Router и Backup Designated Router соответственно). Эти выборы необходимы для оптимизации системы соседств и рассылки данных о топологии в случае, если несколько маршрутизаторов подключены к одному широковещательному домену. Поясним на рисунке:



 Совершенно очевидно, что поскольку OSPF Hello имеют мультикастную природу, каждый маршрутизатор широковещательного домена способен принимать Hello, рассылаемые любым другим маршрутизатором. Из-за этого по идее должна сформироваться топология соседств по схеме Full Mesh (левый рисунок), но по факту маршрутизаторы выбирают, кто из них будет выполнять роль DR (выборы происходят на основании сравнения приоритетов интерфейсов устройств), и формируют соседства с ним. Рассчет на то, что именно DR будет ответственен за распространение изменений в топологии между всеми участниками широковещательного домена. На всякий случай также выбирается BDR, с которым соседства тоже устанавливаются. Общее количество соседств в таких топологиях сокращается, оптимизируется рассылка изменений в топологии. Результирующая схема соседств выглядит как показано на правом рисунке.
 Протокол IS-IS тоже производит выбор назначенного маршрутизатора (DIS - Designated Intermediate System) в подобных топологиях. Выбор DIS также производится на основании сравнения приоритетов, настроенных на интерфейсах маршрутизаторов. Если приоритеты одинаковые, то в выборах побеждает маршрутизатор с численно большим МАС адресом. Однако процесс выбора DIS в IS-IS отличается от процесса выбора DR в OSPF следующими деталями:

  1. Не выбирается Backup DIS.
  2. Соседства в таком широковещательном домене все равно формируются по схеме Full Mesh, а не только между DIS и не-DIS.
  3. Выставление приоритета, равного 0, не означает, что маршрутизатор не может быть выбран DIS.
  4. Если в широковещательный домен добавить маршрутизатор с более высоким приоритетом, чем у текущего DIS, то произойдут перевыборы, и новый маршрутизатор возьмет на себя роль нового DIS.
  5. Возможно существование разных DIS на уровне 1 и на уровне 2.

 После формирования adjacency маршрутизаторы начинают обмениваться данными о топологии и наполнять свои базы данных топологий. О структуре этой базы в протоколе IS-IS и о процессе обмена топологической информацией мы поговорим в следующей статье.
---
Андрей Петрунин,
Учебный Центр Fast Lane

5240 просмотров
2 коммент.

   Все, кто имеет представление о динамической маршрутизации трафика в IP сетях, знают, что по принципу работы все существующие протоколы маршрутизации можно разделить на две группы: distance-vector и link state. Особо дотошные люди могут отметить, что есть еще одна группа: path-vector, которой принадлежит протокол BGP, но разговор будет не о нем, поэтому на эту группу мы закроем глаза. В этой статье мы сосредоточим свое внимание на link state протоколах маршрутизации. Как многие из вас знают, таких протоколов всего два: OSPF и IS-IS. Так сложилось, что протокол OSPF является более популярным представителем своего класса. Как иногда говорят, этот протокол лучше изучен, поскольку его реализации встречаются в корпоративных и провайдерских сетях чаще, чем реализации IS-IS, а также потому, что по OSPF написана масса литературы, и логика работы протокола рассматривается во многих официальных тренингах. Когда же речь заходит о втором характерном представителе link state протоколов, многие инженеры и дизайнеры сетей впадают в уныние: действительно, реализаций IS-IS меньше, и неофициально считается, что этот протокол больше подходит для провайдерских инфраструктур, нежели для корпоративных сетей. Однако сказать, что этот протокол не заслуживает внимания, категорически нельзя.
   В этой статье мы рассмотрим принципы работы протокола IS-IS, сравнивая его (там, где возможно) с протоколом OSPF. В целом можно сказать, что эти протоколы настолько же разные, насколько и одинаковые, и их сравнение позволит разобраться с особенностями каждого. Поехали.

 

Основные принципы работы.
   Для начала вспомним, в чем же состоит принцип работы link state протоколов маршрутизации. Здесь все достаточно просто: маршрутизаторы обмениваются друг с другом информацией о топологии. Каждый маршрутизатор сообщает соседним устройствам о том кусочке топологии, о котором знает сам. Соседние маршрутизаторы передают эту информацию другим соседям, и так далее по цепочке возникает распространение данных о топологии между устройствами одного домена маршрутизации. Этот процесс в технической литературе и документации называется flooding (не путать с flooding в широковещательном домене коммутаторами 2 уровня). Благодаря этому самому флудингу каждый маршрутизатор в сети способен понять, как выглядит топология сети: какие другие устройства в топологии есть, как они связаны друг с другом, какие сети к ним подключены. Эта информация хранится на каждом маршрутизаторе в базе данных топологий. В OSPF она называется LSDB, в IS-IS она отдельного названия не имеет, и мы так и будем ее называть "базой данных топологии" (кстати, тоже часто называют LSDB).
   Далее, собрав информацию о топологии, каждый маршрутизатор локально (что немаловажно) запускает некий алгоритм, по которому он просчитывает эту самую базу данных топологии. В результате просчета у маршрутизатора появляется представление о кратчайшем пути от себя самого до каждого другого маршрутизатора (и как следствие до сетей, подключенных к нему). Собственно именно этот результат и попадает в виде записей в таблицу маршрутизации. Сам алгоритм известен нам под названием SPF (Shortest Path First). Общий принцип его работы известен, но не представляет для нас интереса. Важно то, что одним и тем же алгоритмом пользуются оба протокола. То есть просчет данных о топологии с целью определения кратчайших маршрутов и в OSPF, и в IS-IS происходит одинаково. Базы данных топологий этих протоколов имеют разную структуру, но просчет этих баз производится одним и тем же алгоритмом.

Дизайн домена маршрутизации и базовые идентификаторы.
   Те, кто используют протокол OSPF в своих сетях, знают, что OSPF - протокол иерархический. Это значит, что весь домен маршрутизации OSPF можно разделить на отдельные области (area). При этом делать это произвольно нельзя: если топология действительно разбивается на области, в обязательном порядке должна присутствовать область с номером 0 (так называемая backbone area), а все другие области подключаются к нулевой с помощью маршрутизаторов ABR (Area Border Router). В нулевую область обычно выделяют ядро сети (отсюда и название backbone area), в остальные area попадает периферия. При этом граница между областями проходит по маршрутизатору, то есть фактически области принадлежит не маршрутизатор целиком, а какой-нибудь его интерфейс. Например, вот такой дизайн должен быть хорошо знаком любому, кто знает OSPF:


   IS-IS тоже является протоколом иерархическим, с возможностью разделения топологии на area. Но принципы этого разделения совершенно другие. Во-первых, маршрутизаторы IS-IS домена целиком и полностью принадлежат какой-то одной area, то есть граница между областями проходит по линку, а не по маршрутизатору. Во-вторых, в IS-IS нет никакого специального номера area (как area 0 в OSPF). То есть области, на которые разбита топология, могут носить совершенно произвольные номера. Например,


на рисунке выше маршрутизаторы R1, R2 и R3 принадлежат area 49.0123, R4, R5 и R6 - area 49.0589, a R7, R8 и R9 - area 49.4578. Здесь вероятно, стоит пояснить, откуда берутся такие странные номера областей. Area ID является частью так называемого NET (Network Entity Title) адреса, который назначается каждому маршрутизатору после запуска IS-IS процесса. Этот адрес является разновидностью адресов, которые использовались различными протоколами ISO (скажем так) доIPшной эпохи. Сам NET имеет следующий формат:



    • Первая часть NET идентификатора называется AFI (Authority and Format Identifier) и вообще является частью номера области, хотя постоянно изображается отдельно. Подавляющее большинство реализаций IS-IS на маршрутизаторах имеют это поле, равным 49. Дело тут в истории этих самых NET адресов: адреса, у которых AFI был равен 49, относились к классу локальных.

    • Далее NET содержит номер области (Area ID), которой принадлежит маршрутизатор. Это поле переменной длины.

    • За ним следует 6-байтный System ID. Это идентификатор маршрутизатора. У каждого маршрутизатора в топологии он должен быть уникальным, поскольку именно по System ID маршрутизаторы "узнают" друг друга при осознании топологии. В OSPF аналогом System ID является Router ID (однако он имеет другой формат).

    • Последним идет однобайтное поле Selector. Значение Selector, равное 00, обозначало в NET адресах, что адрес принадлежит самому маршрутизатору. Именно поэтому в большинстве конфигураций Selector ставят равным 00.

   При записи этого NET идентификатора используют шестнадцатиричную систему счисления, отдельные части адреса (указанные выше) разделяются точками. Помимо этого точками разделяются 2-байтовые последовательности внутри Area ID и System ID. Например, такой NET адрес:
49.0001.0a45.16df.8700.00
содержит следующие поля:

  1. AFI - 49
  2. Area ID - 0001
  3. System ID - 0a4516df8700
  4. Selector - 00

 На самом деле, как уже упоминалось, AFI маршрутизаторами воспринимается как часть area ID, поэтому в практической реализации при использовании указанного выше NET адреса, можно сказать, что маршрутизатор принадлежит area 49.0001.
   Так вот, возвращаясь к иерархичности протокола. Домен маршрутизации IS-IS можно разделить на области, но в основе иерархичности IS-IS лежат не сами области, а уровни взаимодействия маршрутизаторов друг с другом. Дело в том, что пара IS-IS маршрутизаторов, подключенных друг к другу прямым линком (или через L2 домен), могут сформировать два вида (или два уровня) взаимодействий - Level 1 и Level 2 (L1 и L2 соответственно). Правила для организации соседств разных уровней следующие:

  1. Соседство уровня 1 (L1) формируется только между маршрутизаторами одной area.
  2. Соседство уровня 2 (L2) может быть сформировано как между маршрутизаторами одной area, так и между маршрутизаторами разных area.

   Кстати, такие два уровня взаимодействий позволяют выделить три типа маршрутизаторов в IS-IS домене:
  1. Маршрутизаторы L1 - это те устройства, у которых все взаимодействия с другими маршрутизаторами происходят на 1 уровне.
  2. Маршрутизаторы L2 - это те устройства, у которых все соседства организованы на 2 уровне.
  3. Маршрутизаторы L1/L2 - это устройства, поддерживающие взаимодействия обоих уровней.

   Если в качестве примера взять IS-IS топологию из 9 маршрутизаторов, которую мы показывали выше, то с точки зрения уровней взаимодействия можно построить IS-IS домен двумя способами:

В этом случае все маршрутизаторы выполняют роль L2 устройств, а L2 взаимодействия показаны красным. Либо


   Тут R1, R2, R8 и R9 - это L1 устройства; R3 и R7 - L1/L2; все остальные - L2. Соседства второго уровня показаны красным, первого - зеленым.
Забегая немного вперед, скажу, что эти два варианта будут отличаться объемом топологических данных, которые маршрутизаторы хранят: в первом случае каждый из 9 маршрутизаторов будет владеть полным знанием о всей топологии из 9 устройств; во втором маршрутизаторы area 49.0123 ничего не будут знать о топологии area 49.4578.
   Но вот чего нельзя будет в этой топологии сделать (с точки зрения дизайна протокола), так это следующего:

   Причиной, почему этот дизайн является ошибочным, является требование IS-IS, заключающееся в том, что всё множество L2 взаимодействий между маршрутизаторами должно быть непрерывным. Равно как, например, в OSPF нельзя разрывать area 0 на несколько частей (виртуальные линки не в счет). Собственно тут мы подходим к ответу на один из первых вопросов, который задают те, кто пытается понять IS-IS, зная, как работает OSPF: что в IS-IS является аналогом area 0 в OSPF? Этим аналогом является не какая-то конкретная area с каким-то номером, а все множество соседств второго уровня между отдельными маршрутизаторами. Именно это множество L2 соседств формирует backbone или ядро сети, к которому подключаются остальные части топологии (или остальные area), внутри которых могут быть сформированы соседства уровня 1. В этом контексте маршрутизаторы L1/L2 можно назвать примерным аналогом ABR в OSPF. Примерным потому, что они фактически не находятся на границе между областями (граница все-таки проходит по линку), но тем не менее аналогом, потому что они являются ключевыми устройствами для органичения распространения данных о топологии и, как следствие, инструментом масштабирования доменов маршрутизации IS-IS.

Базовая конфигурация протокола.
  Продолжая наш пример, покажем, как настроить иерархических домен маршрутизации IS-IS. Сделать это совершенно несложно. Для начала стоит отметить, что запуск протокола производится командой router isis [<name>]. Имя IS-IS процесса в IOS не является обязательным, но при запуске протокола надо помнить, задавали вы это имя или нет. От этого будет зависеть синтаксис команды для запуска протокола на интерфейсе. После запуска процесса маршрутизации необходимо в обязательном порядке задать NET идентификатора на каждом маршрутизаторе.
Например, для R1:
router isis 123
net 49.0123.0100.0100.1001.00

Для R4:
router isis
net 49.0589.0100.0100.1004.00

   В примере выше на разных маршрутизаторах протокол IS-IS запущен по-разному (на одном с именем, на другом - без). Это не является ошибкой и не представляет проблему с точки зрения работы протокола.
При этом после запуска маршрутизатор автоматически полагает, что он будет устанавливать соседства обоих уровней. Если вы уверены, что вы настраиваете исключительно L1 или L2 устройство, то командой is-type можно этот факт маршрутизатору обозначить. Например, для R1:
router isis 123
net 49.0123.0100.0100.1001.00
is-type level-1

Для R4:
router isis
net 49.0589.0100.0100.1004.00
is-type level-2

   После запуска протокола глобально, необходимо запустить его на интерфейсе. Например, для R1:
interface FastEthernet0/0
ip address 10.1.2.1 255.255.255.0
ip router isis 123

Для R4:
interface FastEthernet0/0
ip address 10.3.4.4 255.255.255.0
ip router isis

   Вот здесь кроется некая хитрость, благодаря которой часто допускается ошибка в такой простой конфигурации. Если процесс IS-IS был глобально запущен с использованием какого-то имени процесса (как 123 на R1), то и на интерфейсах протокол должен запускаться с указанием этого имени. Если же IS-IS процесс запущен без имени, то команда для старта протокола на интерфейсе будет выглядеть как ip router isis.
   При этом после запуска протокола на интерфейсе маршрутизатор делает допущение, что через этот интерфейс необходимо сформировать соседства обоих уровней (если ранее не использовалась команда is-type, однозначно указывающая уровень взаимодействия глобально на весь маршрутизатор). То есть маршрутизатор может на одном и том же интерфейсе сформировать и соседство уровня 1, и L2 соседство. С точки зрения протокола, это вполне себе штатное поведение. То есть, если тип маршрутизатора не был задан глобально командой is-type, то одна и та же пара маршрутизаторов в результате такой простой конфигурации сформирует между собой соседства обоих уровней. Например, для R8 и R9:
R8#sh run | sec router isis
router isis 456
net 49.4578.0100.0100.1008.00
R8#sh run int f0/1
interface FastEthernet0/1
ip address 10.8.9.8 255.255.255.0
ip router isis 456
end

R9#sh run | sec router isis
router isis
net 49.4578.0100.0100.1009.00
R9#sh run int f0/0
interface FastEthernet0/0
ip address 10.8.9.9 255.255.255.0
ip router isis
end

  Как видно выше, в результате простейшей конфигурации протокола между маршрутизаторами R8 и R9 сформировалось одновременно 2 соседства разных уровней. Для того, чтобы управлять уровнями соседств на per-interface основе можно использовать комаду isis circuit-type:

R8#sh run int f0/1
interface FastEthernet0/1
ip address 10.8.9.8 255.255.255.0
ip router isis 456
isis circuit-type level-1
end

После этого видим, что соседство второго уровня между R8 и R9 пропало:


  Таким образом, манипулируя настройками уровней либо глобально с помощью команды is-type, либо на каждом интерфейсе с помощью isis circuit-type вы можете построить правильный с точки зрения иерархии уровней домен маршрутизации IS-IS.
  В следующей статье мы посмотрим, как выглядит процесс формирования соседств в IS-IS, и чем он отличается от соседств в OSPF. Stay tuned.
---
Андрей Петрунин,
учебный центр Fast Lane

6220 просмотров
1 Комментарии

В этот раз мы рассмотрим такую частую и крайне неприятную ситуацию, как случайная потеря управления коммутатором Cisco Catalyst при неправильном добавлении VLAN в транк на аплинке. Многие инженеры с этой ситуацией сталкивались, и знают, насколько эта ошибка элементарна, обидна и неприятна. Кратко о самой проблеме.
Давайте представим, что у нас есть некая сеть, в которой (например, на уровне доступа) находятся несколько коммутаторов. Графически наш пример можно изобразить так:

Для определенности покажем конфигурации портов коммутаторов:

Access-Switch-2#sh run int f0/1
Building configuration...
Current configuration : 293 bytes
!
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 8,102,103,112,113,122,123,192,193,202,203,212
switchport trunk allowed vlan add 213,222,223,292,293,302,303,312,313,322,323
switchport trunk allowed vlan add 392,393
switchport mode trunk
end
Access-Switch-2#sh run int vl 8
Building configuration...
Current configuration : 63 bytes
!
interface Vlan8
ip address 192.168.5.123 255.255.255.0
end
Access-Switch-2#
Access-Switch-1#sh run int f0/24
Building configuration...
Current configuration : 294 bytes
!
interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 8,102,103,112,113,122,123,192,193,202,203,212
switchport trunk allowed vlan add 213,222,223,292,293,302,303,312,313,322,323
switchport trunk allowed vlan add 392,393
switchport mode trunk
end
Access-Switch-1#sh run int vl8
Building configuration...
Current configuration : 62 bytes
!
interface Vlan8
ip address 192.168.5.16 255.255.255.0
end
Access-Switch-1#

    Обычно один из VLAN на коммутаторе выбирается как VLAN управления. Именно через этот VLAN осуществляется удаленное управление каждым устройством по telnet, SSH, HTTP (нужное подчеркнуть), и именно в этом VLAN коммутатор имеет собственный IP адрес. Для нашего примера VLAN управления имеет VLAN id равный 8. Адреса управления коммутаторами представлены на схеме. Теперь давайте предположим, что какому-то инженеру необходимо добавить какой-то VLAN (например, 62) на этих коммутаторах и затерминировать этот VLAN на каком-то маршрутизаторе. После добавления нового VLAN на нужных коммутаторах нужно не забыть разрешить его на соответствующих транковых портах (дотянуть, так сказать, VLAN от какого-то коммутатора до точки терминации). Собственно в этом процессе наша проблема и кроется. Если инженер, настраивая Access-Switch-1 (через telnet или SSH), создаст на нем новый VLAN, а затем попытается этот VLAN разрешить на аплинке этого коммутатора (порту Fa0/24) не совсем корректной командой, то управление этим коммутатором потеряется:

Terminal_server#telnet 192.168.5.16
Trying 192.168.5.16 ... Open
User Access Verification
Username: admin
Password:
Access-Switch-1>en
Password:
Access-Switch-1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Access-Switch-1(config)#vlan 62
Access-Switch-1(config-vlan)#name NEW_CUSTOMER
Access-Switch-1(config-vlan)#exit
Access-Switch-1(config)#int f0/24
Access-Switch-1(config-if)#sw tr al vl 62

  Дальше в консоли обычно тишина, а в комнате мат.
  Происходит это потому, что забыв в синтаксисе команды switchport trunk allowed vlan дополнительный аргумент add, мы фактически перезаписываем список разрешенных VLAN на данном транковом порту, а не добавляем требуемый VLAN в этот самый список. Связность с коммутатором в VLAN управления пропадает, инженер расстривается. При этом восстановить управление по IP в новом VLAN не представляется возможным, если в новом VLAN не был создан интерфейс с каким-то IP адресом (как в примере выше).
Классический способ решения этой проблемы - это перезагрузка коммутатора. К коммутатору кого-то отправляют, чтобы перезагрузить его по питанию, и в результате свич загружается с прежней конфигурацией, где злополучного изменения еще нет.
  Однако есть способ восстановить управление таким коммутатором более быстрый и не требующий физического присутствия у коммутатора. Способ этот связан с технологией кластеризации коммутаторов. Технологию эту поддерживает подавляющее большинство актуальных на данный момент коммутаторов (с актуальными софтами) семейства Cisco Catalyst, а также модели, которые уже End-of-Life или End-of-Sale, но все еще повсеместно встречаются на сетях и пользуются большой популярностью (включая 2950, 3560, 3750 и прочие).
  Сразу скажу, что эту технологию нельзя путать со стекированием коммутаторов (например, с технологией StackWise). Стек из коммутаторов - это некое множество свичей, объединенных друг с другом с применением специального кабеля, соединяющего коммутаторы через специальные порты. В результате получается возможность управлять всем множеством коммутаторов как одним устройством, и сам стек ведет себя как один большой коммутатор.
  Кластеризация коммутаторов предполагает возможность управления множеством свичей (до 16 штук) с использованием всего одного IP адреса. При этом коммутаторы могут быть подключены друг к другу с использованием любых (по скорости и среде передачи) Ethernet линков. Коммутаторы продолжают вести себя как и ранее, не происходит их объединения в стек: они по-прежнему являются индивидуальными активными устройствами в L2 домене.
  Для начала посмотрим, как эта технология поможет нам решить нашу проблему с потерей управления коммутатором, а потом разберем, как именно она работает.
  Итак, мы потеряли управление одним коммутатором, но у нас осталась возможость открыть сессию управления до вышестоящего коммутатора (Access-Switch-2). Именно в этой сессии мы и будем работать.Для начала на этом коммутаторе мы включим поддержку кластеризации. Для этого служит простая команда cluster enable TEST-CLUSTER, в которой вам нужно задать имя нового кластера (в моем примере TEST-CLUSTER):

Access-Switch-2(config)#cluster enable TEST-CLUSTER
Access-Switch-2(config)#
  После ее ввода вам необходимо посмотреть, какие из соседних для нашего Access-Switch-2 коммутаторов подходят для объединения в кластер. В этом нам поможет команда show cluster candidates:


  В выводе этой команды мы видим, что наш Access-Switch-2 обнаружил одного кандидата на включение в кластер. Собственно поскольку в моем примере другие коммутаторы отсутствуют, нет сомнений, что речь идет именно о Access-Switch-1 (его hostname в графу Name не влезает полностью). Здесь нас больше всего будет интересовать МАС адрес утраченного коммутатора (0016.c819.d080). Его на этом этапе мы запоминаем.
  Как уже упоминалось, мы будем восстанавливать управление потерянным коммутатором со свича Access-Switch-2. Для того, чтобы это получилось, в транке между этими свичами должен быть хотя бы один живой VLAN. На утерянном коммутаторе собственно один единственный такой VLAN и остался (тот самый VLAN 62, добавление которого привело к возникновению проблемы), а вот на коммутаторе Access-Switch-2 этот VLAN в транк нужно добавить:

Access-Switch-2(config)#vlan 62
Access-Switch-2(config-vlan)#name NEW_CUSTOMER
Access-Switch-2(config-vlan)#exit
Access-Switch-2(config)#int f0/1
Access-Switch-2(config-if)#sw tr al vl add 62
Access-Switch-2(config-if)#

  Кстати, в этот момент, инженер уже обычно помнит про необходимость добавления аргумента add в момент добавления VLAN в транк.
  Итак, на данном этапе мы имеем два коммутатора, соединенные друг с другом транковым линком, в котором разрешен один лишь VLAN (в нашем случае 62). Далее в режиме глобальной конфигурации мы даем команду cluster member mac-address <MAC>, где указываем MAC адрес кандидата на включение в кластер (Access-Switch-1):

Access-Switch-2(config)#cluster member mac-address 0016.c819.d080
%ERROR:  member unreachable
Access-Switch-2(config)#

  По факту выполнения этой команды произойдет попытка подключения коммутатора с указанным MAC адресом в наш новосозданный кластер TEST-CLUSTER. Если вы получаете ошибку, которая представлена на примере, это значит, что придется чуть-чуть повозиться. Дело в том, что в этой команде также есть возможность задать VLAN для этого подключения, а также пароль дальнего коммутатора. Поэтому если с первого раза добавление не прошло успешно, можно попробовать выполнить cluster member mac-address <MAC> vlan <VLAN-ID>:

Access-Switch-2(config)#cluster member mac-address 0016.c819.d080 vlan 62
%ERROR:  member unreachable
Access-Switch-2(config)#

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

Access-Switch-2(config)#cluster member mac-adress 0016.c819.d080 password cisco vlan 62        
Access-Switch-2(config)#


  В моем примере это сработало, но если вы по-прежнему получаете ошибку, то нужно попробовать создать на коммутаторе Access-Switch-2 интерфейс в VLAN 62 и присвоить ему какой-нибудь IP адрес (возможно из той сети, которую вы с самого начала хотели присвоить этому VLAN) и повторить попытки с командой cluster member mac-address <MAC> password <password> vlan <VLAN id>.
   В результате ваши попытке должны привести к тому, что Access-Switch-2 просто примет команду к исполнению. Это означает, что ваш утерянный Access-Switch-1 подключен к вашем кластеру TEST-CLUSTER. Проверить это можно командой show cluster members:



  В этой команде нас будет интересовать индекс (или номер), с которым наш Access-Switch-1 добавился в кластер. Тут стоит упомянуть, что свич, на котором был создан кластер (в нашем случае Access-Switch-2) всегда получает индекс 0. После этого в привилегированном режиме нашего Access-Switch-2 выполняете команду rcommand <index> и вуаля:

Access-Switch-2#rcommand 1
Access-Switch-2-1#

  Выскочившее приглашение фактически открывает вам доступ в CLI коммутатора Access-Switch-1. На тот факт, что вы видите странную строчку Access-Switch-2-1 обращать внимания не стоит: так получается, поскольку вы обращаетесь к свичу с индексом 1 с хозяина кластера (Access-Switch-2).
После этого у вас есть возможность на коммутаторе Access-Switch-1 вручную исправить конфигурацию, которая привела к потере управления, и возможно, перерыву сервиса у пользователей. Когда вы восстановите управление по IP коммутатором Access-Switch-1, на коммутаторе Access-Switch-2 можно отключить всю конфигурацию кластера. Сделать это можно простой командой no cluster enable TEST-CLUSTER на коммутаторе Access-Switch-2.

Как это работает.
  Как я уже говорил, кластеризация коммутаторов предоставляет возможность управлять набором до 16 коммутаторов с одного единственного свича. При этом IP связности между этими коммутаторами может не быть, то есть все множество коммутаторов управляется через один и тот же IP адрес. Но вот связность на 2 уровне быть должна. Для того, чтобы организовать кластер из коммутаторов, необходимо распределить роли между ними. Ролей всего две: cluster command switch и cluster member switch. Как нетрудно догадаться, cluster command - это коммутатор, который владеет IP адресом, через который будет осуществляться управление всем кластером. В нашем случае это был коммутатор Access-Switch-2. Собственно когда мы на нем ввели команду cluster enable TEST-CLUSTER, мы его на эту роль и назначили.
  После этого cluster command пытается обнаружить соседние коммутаторы, которых он может подключить к новоиспеченному кластеру, то есть кандидатов. Здесь важно уточнить, что кандидаты - это еще не cluster members. То есть это коммутаторы которые могут быть включены в кластер, но еще не включены. Кандидаты должны удовлетворять следующим требованиям:

    1. Правильный софт, поддерживающий технологию кластеризации (http://cisco.com/go/fn наше все).

    1. Включенный глобально и на траковом порту CDP версии 2.

    1. Отсутствие членства в других кластерах (каждый коммутатор независимо от роли может являться частью только одного кластера).

    1. Подключение к cluster command коммутатору с использованием хотя бы одного VLAN (да-да, тот самый наш VLAN 62).

  При этом обнаружение кандидатов возможно как в топологии звезда, так и в других. Особых ограничений на схему подключения кандидатов, cluster member и cluster command нет.
Обнаружение кандидатов ведется с использованием протокола CDP, поэтому его функционирование критично для решения нашей задачи. Вообще с использованием CDP коммутаторы кластера могут обнаруживать новых кандидатов на расстоянии максимум 7 (но по умолчанию 3) хопов от границы кластера. Границей кластера является тот порт cluster member, через который нет подключения к другому (следующему) cluster member, но есть подключение к кандидату. Например:



  Cluster command коммутатор (Switch1), представленный на рисунке, сможет обнаружить коммутаторы Switch5, 6, 7 и 8 как кандидатов на включение в кластер. Тут мы предполагаем, что коммутаторы Switch2, 3, 4 уже включены в кластер и являются cluster member. Switch 9 не будет обнаружен как кандидат, поскольку он находится на расстоянии 4 хопов от границы кластера, а по умолчанию ограничение на "дальность обнаружения" составляет 3 хопа.
  Кстати, если между свичами, поддерживающими кластеризацию, включен вразрез какой-нибудь тупой хаб, который просто транслирует CDP сообщения, то проблем с обнаружением не будет. Но если между коммутаторами находится свич, который не поддерживает кластеризацию, то потенциальные кандидаты, находящиеся за таким коммутатором, обнаружены не будут. Например:




  Switch 2 на данном рисунке будет нормально обнаружен на cluster command (Switch1), а вот Switch4 - не будет, поскольку Switch3 не поддерживает кластеризацию.
Собственно в нашем примере после того, как мы назначили Access-Switch-2 на роль cluster command, ему при соблюдении всех условий не составляет обнаружить наш Access-Switch-1 как кандидата, что мы и наблюдаем в выводе show cluster candidates. Далее мы делаем из нашего кандидата настоящего cluster member (немного поиграв с конфигурацией), и после этого можем обращаться к нашему новоиспеченному cluster member с нашего cluster command с использованием команды rcommand.
  Кстати, еще одно применение этой прекрасной технологии состоит в том, что она позволяет "цеплять" по управлению абсолютно ненастроенные коммутаторы при подключении их к действующей сети. Например, в ситуации, когда вам нужно установить новый коммутатор где-то на сети доступа, обычно необходимо заранее этот коммутатор настроить для того, чтобы после установки сразу получить к нему удаленное управление. Эта настройка обычно включает в себя конфигурацию VLAN управления, адреса в этом VLAN, шлюза по умолчанию и какой-нибудь учетной записи для аутентификации. Но при использовании кластеризации, эту начальную конфигурацию можно вообще не производить. Коммутатор с завода прямо в коробке может быть отправлен прямо на требуемую площадку для установки. Как только он будет установлен в стойку и подключен к какому-нибудь коммутатору, управление которым у вас есть (по telnet или SSH), то использование этого нехитрого способа позволит вам получить доступ к новому коммутатору вообще без наличия IP связности с ним. Да здравствуют включенный по умолчанию CDP и присутствующий по умолчанию VLAN 1.
---
Андрей Петрунин,
Учебный центр Fast Lane

1093 просмотров
2 коммент.

[toc:faq]

В статье будет рассмотрен вопрос манипуляции значением MED относительно оригинального значения на iBGP и eBGP линках, в частности будет проиллюстрировано, что относительное изменение значения может выглядеть как абсолютное. Так же будет рассмотрен вопрос учёта IGP метрики до машрутизатора, который является next-hop для маршрута, при анонсе маршрута в соседнюю автономную систему.

Что такое MED?

Итак, что такое MED? Из RFC4451, MULTI_EXIT_DISC есть опциональный нетранзитивный атрибут, который предназначен для использования на внешних (inter-AS) линках, чтобы  информировать eBGP-соседей о том, какой путь в автономную систему более предпочтительный.

Топология.

MED на iBGP линках.

Рассмотрим сценарий распространения атрибута MED на iBGP линках. Согласно RFC4451 атрибут MED передается внутри автономной системы и относительное изменение значения MED с помощью route-map будет иметь ожидаемый результат.

 

Маршрутизатор R1 из AS100 анонсирует префикс 192.168.100.0/24 с относительным изменением MED (+111). Так как команда show ip bgp показывает префиксы до обработки route-map мы видим только оригинальное значение MED (22), установленное при редистрибуции.

Конфигурация BGP на R1:

router bgp 100
bgp router-id 11.11.11.11
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
!
address-family ipv4
  redistribute connected metric 22 route-map NET198
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 route-map SET_MED out
route-map NET198 permit 10
match ip address prefix-list NET198
route-map SET_MED permit 10
set metric +111
R1#show ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 4
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (11.11.11.11)
      Origin incomplete, metric 22, localpref 100, weight 32768, valid, sourced, best
      rx pathid: 0, tx pathid: 0x

Итоговое значение MED (22 + 111 = 133) видно уже на соседнем маршрутизаторе ASBR1:

ASBR1#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 2
  Local
    11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
      Origin incomplete, metric 133, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

MED на eBGP линках.

Рассмотрим теперь сценарий с eBGP линком. Cогласно все тому же RFC4451, атрибут MED нетранзитивный и получен по iBGP линку, а значит должен быть отброшен при передаче маршрута в соседнюю автономную систему, что как мы видим и происходит:

ASBR2#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
*>  192.168.100.0    10.10.21.1                             0 100 ?

И в случае, если будет использована route-map с относительным изменением значения MED, то, фактически, это будет означать абсолютное измненение.

ASBR1:

route-map SET_MED permit 10
set metric +55

...
neighbor 10.10.21.2 route-map SET_MED out
...
ASBR2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
*>  192.168.100.0    10.10.21.1              55             0 100 ?

С первого взгляда это может показаться очевидным, однако, иногда факт того, что все происходит на eBGP линке может ускользнуть от внимания и такое поведение может оказаться неожиданным.

Команда set metric-type internal

Если существует необходимость учесть IGP метрику до маршрутизатора, который является next-hop для заданного маршрута, то можно использовать команду `set metric-type internal`.

ASBR1#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 2
  Local
    11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
      Origin incomplete, metric 133, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

Значение IGP метрики до NH маршрута 192.168.100.0/24 - 2 (не путать со значением MED маршрута - 133).

После обработки маршрута route-map с относительным изменением значения MED и командой `set metric-type internal`:

route-map SET_MED permit 10
set metric +55
set metric-type internal

ожидаемым значением, которое будет анонсировано соседу, будет значение 2 + 55 = 57:

ASBR2#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 6
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  100
    10.10.21.1 from 10.10.21.1 (1.1.1.1)
      Origin incomplete, metric 57, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Это бывает полезным, если маршрут присутствует в IGP и на ASBR этот маршрут анонсируется командой network <prefix>. В этом случае MED берется из IGP метрики и относительное изменение MED будет очевидным и ожидаемым результатом:

ASBR1#sh run | sec bgp
router bgp 100
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 10.10.21.2 remote-as 200
neighbor 11.11.11.11 remote-as 100
neighbor 11.11.11.11 update-source Loopback0
!
address-family ipv4
  network 192.168.100.0
  neighbor 10.10.21.2 activate
  neighbor 10.10.21.2 next-hop-self
  neighbor 10.10.21.2 route-map SET_MED out
  neighbor 11.11.11.11 activate
ASBR1#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 5
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  Local
    10.100.21.2 from 0.0.0.0 (1.1.1.1)
      Origin IGP, metric 2, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local
    11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
      Origin incomplete, metric 133, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
ASBR1#show ip route  192.168.100.0
Routing entry for 192.168.100.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Advertised by bgp 100
  Last update from 10.100.21.2 on GigabitEthernet0/2, 00:00:57 ago
  Routing Descriptor Blocks:
  * 10.100.21.2, from 11.11.11.11, 00:00:57 ago, via GigabitEthernet0/2
      Route metric is 2, traffic share count is 1
ASBR2#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 4
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  100
    10.10.21.1 from 10.10.21.1 (1.1.1.1)
      Origin IGP, metric 57, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Ссылки по теме.

819 просмотров
1 Комментарии

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

В первую очередь при обновлении IOS следует обратить внимание на версию ROMMON. Текущую версию можно посмотреть так:

sh platform
Chassis type: ASR1004 Slot Type State Insert time (ago)
--------- ------------------- --------------------- -----------------
...
--------- ------------------- ---------------------------------------
0 09111601 15.3(3r)S
R0 10021901 15.3(3r)S
F0 08041102 15.3(3r)S

или отдельно по модулям:

#sh rom-monitor r0
System Bootstrap, Version 15.3(3r)S, RELEASE SOFTWARE (fc1)
Copyright (c) 1994-2013 by cisco Systems, Inc.

Минимальную и рекомендуемую версию ROMMON для конкретного релиза IOS можно посмотреть здесь. Если ROMMON будет слишком старый, новая прошивка просто не будет применена. Обновляется очень просто командой: 

upgrade rom-monitor filename  bootflash:asr1000-rommon.153-3r.S.pkg  all 


В версии 15.2(04)S5.1 были изменены значения по умолчанию для команды ppp packet throttle.

Ранее были очень большие пороги сброса контрольных пакетов PPP: 

ppp packet throttle 10000 3600 0

В некоторых случаях клиентское оборудование генерировало очень большое количество таких пакетов, что приводило к большой загрузке CPU BRAS-а.

После этой версии пороги были очень сильно занижены:

ppp packet throttle 10 1 30 //После 10 пакетов за 1 секунду хост будет блокироваться на 30 сек.

Для некоторых клиентов (чаще всего это Microsoft Windows 7) эти ограничения слишком сильны, поэтому следует опытным путем подобрать количество пакетов. Нам подошло

ppp packet throttle 100 1 30


В версии 3.11 появился функционал для ограничения ресурсов ESP. Очень рекомендуется настроить:

platform subscriber cac mem qfp 95

При вводе данной команды и достижению лимита по используемой памяти на ESP в 95% (память расходуется для абонентских сессий и сервисов) мы перестаем терминировать дополнительные сессии абонентов и начинаем их отбивать. Логика в том, чтобы обеспечить работу существующих абонентов и отбить несколько новых вместо того, чтобы потерять все. 



В версии 3.13 есть баг CSCux47830 (ASRNAT: Pool leak in PAP mode), который пока что устранен только в инженерном релизе.



Будьте внимательны при обновлениях :-) 

P.S. Буду благодарна за комментарии, особенно если поделитесь, с чем Вам пришлось столкнуться при обновлениях ASR1k.

265 просмотров
2 коммент.

Иногда возникают ситуации, когда модуль установленный в шасси маршрутизатора ASR1000 не запускается. Например, вы получили модуль RP по RMA и заменили им неработающий модуль. Однако, проверка показывает, что и новый модуль  не загрузился. Мы видим следующий вывод:

ASR1006#show platform
Chassis type: ASR1006            

Slot      Type                State                 Insert time (ago)
--------- ------------------- --------------------- -----------------
0         ASR1000-SIP10          ok                    00:10:01     
 0/0      SPA-10X1GE-V2          ok                    00:06:08     
R0                               unknown               00:10:01     
R1        ASR1000-RP1            ok, active            00:10:01     
F0        ASR1000-ESP10          ok, active            00:10:01     
F1        ASR1000-ESP10          ok, standby           00:10:01     
P0        ASR1006-PWR-AC         ok                    00:07:38     
P1        ASR1006-PWR-AC         ok                    00:07:37     

Slot      CPLD Version        Firmware Version                       
--------- ------------------- ---------------------------------------
0         09111601            15.4(2r)S                          
R0        N/A                 N/A                                
R1        11060317            15.4(2r)S                          
F0        09111601            15.4(2r)S                          
F1        09111601            15.4(2r)S    

Как поступить в этой ситуации?

Прежде всего надо проверить состояние незагрузившегося модуля. Для этого надо подключиться консольным кабелем к интерфейсу “Console” с PC и посредством программы терминального доступа (Putty, TeraTerm, SecureCRT) получить доступ к командной строке консоли модуля.

Чаще всего оказывается, что модуль не может загрузиться из-за того, что на нем находится другая версия/образ IOS-XE, который не совпадает с IOS-XE, работающим на активном модуле RP и поэтому находится в режим rommon. В этом случае нужно взять USB flash память, подключить ее к активному модулю RP и скопировать командой copy на нее нужный образ.

После этого переставить USB-flash в неработающий модуль RP и загрузить его вручную по следующему сценарию:

rommon 23 > dev

Devices in device table:

        id  name

bootflash:  Internal flash drive      

     usb0:  External USB drive 0      

rommon 24 > boot usb0:asr1000rp1-adventerprisek9.03.12.00.S.154-2.S-std.bin

После  этого модуль загружается и устройство начинает работать нормально:

ASR1006#show platform
Chassis type: ASR1006            

Slot      Type                State                 Insert time (ago)
--------- ------------------- --------------------- -----------------
0         ASR1000-SIP10          ok                    2d01h        
 0/0      SPA-10X1GE-V2          ok                    2d01h        
R0        ASR1000-RP1            ok, standby           2d01h        
R1        ASR1000-RP1            ok, active            2d01h        
F0        ASR1000-ESP10-N        ok, active            2d01h        
F1        ASR1000-ESP10-N        ok, standby           2d01h        
P0        ASR1006-PWR-AC         ok                    2d01h        
P1        ASR1006-PWR-AC         ok                    2d01h

Slot      CPLD Version        Firmware Version                       
--------- ------------------- ---------------------------------------
0         09111601            15.4(2r)S                          
R0        07062111            15.4(2r)S                          
R1        11060317            15.4(2r)S                          
F0        09111601            15.4(2r)S                          
F1        09111601            15.4(2r)S   


После загрузки не забудьте скопировать образ IOS-XE на flash модуля standby.

ASR1006#copy bootflash:/asr1000rp1-adventerprisek9.03.12.00.S.154-2.S-std.bin stdby-bootflash:/asr1000rp1-adventerprisek9.03.12.00.S.154-2.S-std.bin

Маршрутизатор теперь находится в рабочем состоянии.

4495 просмотров
0 Комментариев

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

На схеме возле имен маршрутизаторов указаны их OSPF router-id. Помимо указанных сетей, в топологии есть еще следующие:
R1 - 192.168.1.0/24
R2 - 192.168.2.0/24
R3 - 192.168.3.0/24
R4 - 192.168.4.0/24
R5 - 192.168.5.0/24
R6 - 192.168.6.0/24
R7 - 192.168.7.0/24
R8 - 192.168.8.0/24
R9 - 192.168.9.0/24

R4 и R8 являются ASBR, выполняющими редистрибьюцию префиксов 172.16.4.0/24 и 172.16.8.0/24 соответственно.

"Штатным" способом фильтрации маршрутной информации является использование area специального типа. Напомню, что в OSPF помимо обычных area, могут быть использованы area четырех разных специальных типов. К ним относятся:

1. Stub area. Внутри этой area запрещено распространение LSA типов 4 и 5. Таким образом, stub area свободны от внешней для домена OSPF маршрутной информации. И как следствие, наличие ASBR в этих area невозможно. Например, маршрутизатор R6 не имеет маршрутов до сетей 172.16.4.0/24 и 172.16.8.0/24:

R6#sh ip route 172.16.4.0
% Network not in table
R6#sh ip route 172.16.8.0
% Network not in table
R6#

Нет этой информации и в LSDB:
R6#sh ip ospf database external

            OSPF Router with ID (6.6.6.6) (Process ID 1)
R6#

2. Totally stub area. Это фактически stub area, в которой запрещено распространение еще и LSA типа 3. В целом можно считать, что это самый строгий (с точки зрения объема LSDB) тип OSPF area. Получается, что внутренние маршрутизаторы totally stub area не имеют внешней маршрутной информации и не знают о маршрутах до сетей других area. Например, маршрутизатор R7 помимо маршрутов до внешних сетей 172.16.4.0/24 и 172.16.8.0/24, также не знает о сетях других area, например, 192.168.4.0/24:

R7#sh ip route 172.16.4.0
% Network not in table
R7#sh ip route 172.16.8.0
% Network not in table
R7#sh ip route 192.168.4.0
% Network not in table
R7#

Также хорошо видно отсутствие соответствующих LSA в LSDB.
R7#sh ip ospf database external

            OSPF Router with ID (7.7.7.7) (Process ID 1)
R7#sh ip ospf database summary 192.168.4.0

            OSPF Router with ID (7.7.7.7) (Process ID 1)
R7#


3. NSSA (Not So Stubby Area). Это stub, в котором разрешено наличие ASBR. Проблема с невозможностью распространять LSA типа 5 решается введением LSA типа 7 в NSSA. Именно они служат для распространения информации о внешних сетях, которые попадают в домен OSPF через ASBR внутри NSSA. Например, маршрутизатор R8 также не знает маршрута до сети 172.16.4.0/24, но в своей LSDB имеет LSA типа 7 про сеть 172.16.8.0/24:

R8#sh ip route 172.16.4.0
% Subnet not in table
R8#sh ip ospf database external

            OSPF Router with ID (8.8.8.8) (Process ID 1)
R8#show ip ospf database nssa-external

            OSPF Router with ID (8.8.8.8) (Process ID 1)

                Type-7 AS External Link States (Area 4)

  LS age: 871
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 172.16.8.0 (External Network Number )
  Advertising Router: 8.8.8.8
  LS Seq Number: 80000001
  Checksum: 0x167B
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 8.8.8.8
        External Route Tag: 0

R8#

4. Totally NSSA. По аналогии с totally stub area, totally NSSA - это NSSA, в которой запрещено распространение LSA типа 3. Но поскольку она все-таки NSSA, в ней не могут распространяться LSA типов 4 и 5, но может присутствовать ASBR, внешние маршруты от которого будут распространяться с использованием LSA типа 7. Например, маршрутизатор R9 не знает маршрутов до сетей других area (192.168.5.0/24), нет их и в LSDB:

R9#sh ip route 192.168.5.0
% Network not in table
R9#sh ip ospf database summary 192.168.5.0

            OSPF Router with ID (9.9.9.9) (Process ID 1)
R9#

При этом в целом должно быть очевидно, что подобные ограничения означают, что маршрутизаторы, находящиеся внутри area специального типа, испытывают недостаток маршрутной информации, то есть не владеют маршрутами до всех сетей домена и внешних сетей. Этот недостаток возмещается благодаря генерации маршрута по умолчанию от ABR, подключенного к area специального типа. В stub, totally stub и totally NSSA этот дефолтный маршрут генерируется ABR-ом автоматически, а в NSSA эту генерацию необходимо включить вручную (команда area <area_number> nssa default-information-originate) на ABR.

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

1. Методы, влияющие на содержимое базы данных топологии на маршрутизаторах OSPF, то есть направленные на изменение процесса обмена LSA или на процесс их генерации.
2. Методы, позволяющие фильтровать маршруты на этапе их помещения в таблицу маршрутизации. При их использовании база данных топологии содержит всю необходимую информацию, то в таблицу маршрутизации эта информация не попадает.

Методы фильтрации LSA.
Первым достаточно простым методом является применение команды ip ospf database-filter all out. Команда предназначена для режима конфигурации интерфейса и приводит к тому, что через интерфейс прекращается распространение LSA даже внутри area. Например, эту команду мы "скажем" на интерфейсе маршрутизатора R5, после чего увидим, что в LSDB маршрутизатора R1 пропали LSA, ранее сгенерированные маршрутизатором R5.

R1#sh ip ospf database router 5.5.5.5

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 1)

  Adv Router is not-reachable
  LS age: 5
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 5.5.5.5
  Advertising Router: 5.5.5.5
  LS Seq Number: 80000005
  Checksum: 0x44F7
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 5.5.5.5
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.5.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.5.1
     (Link Data) Router Interface address: 10.1.5.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 1
R1#
R5(config-if)#no ip ospf database-filter all out 
R1#sh ip ospf database router 5.5.5.5

            OSPF Router with ID (1.1.1.1) (Process ID 1)
R1#


В принципе к такому же эффекту приводит команда neighbor <ip-address> database-filter all out, выполненная в режиме конфигурации процесса маршрутизации. С той лишь разницей, что она включает подобную фильтрацию только для определенного соседства.

Версия классического IOS 12.4(15)T дала нам такую прекрасную фичу, как OSPF prefix suppression. Эта фича заключается в вводе командыprefix-suppression глобально для всего OSPF процесса, либо ip ospf prefix-suppression для отдельного интерфейса. В первом случае все connected сети всех интерфейсов, включенных в работу OSPF не попадут в LSA типа 1. Это, правда, не относится к сетям на интерфейсах loopback, к secondary сетям и сетям passive интерфейсов. Во втором случае произойдет такая же фильтрация, но для сети конкретного интерфейса. Стоит отметить, что эта фича работает только для линков типа 3, то есть stub линков в LSA типа 1. Например, видно, что сеть 192.168.5.0/24 после ввода prefix-suppression на R6 перестает присутствовать в LSA типа 1, которые генерирует маршрутизатор. Линк в эту сеть имеет тип stub.

R1#sh ip ospf database router 6.6.6.6

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 2)

  LS age: 949
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 6.6.6.6
  Advertising Router: 6.6.6.6
  LS Seq Number: 80000004
  Checksum: 0x66C3
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 6.6.6.6
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.6.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.6.6
     (Link Data) Router Interface address: 10.1.6.6
      Number of TOS metrics: 0
       TOS 0 Metrics: 1


R1#
R6(config-if)#ip ospf prefix-suppression
R1#sh ip ospf database router 6.6.6.6

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 2)

  LS age: 949
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 6.6.6.6
  Advertising Router: 6.6.6.6
  LS Seq Number: 80000004
  Checksum: 0x66C3
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 6.6.6.6
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.6.6
     (Link Data) Router Interface address: 10.1.6.6
      Number of TOS metrics: 0
       TOS 0 Metrics: 1


R1#

Следующий метод касается фильтрации LSA типа 3 на границе между area. В этом нам поможет команда area <area-number> filter-list prefix <prefix-list-name> [in | out]. Эта команда должна быть выполнена на ABR, и может фильтровать распространение LSA типа 3 в разных направлениях. Например, мы можем отфильтровать префикс 192.168.7.0/24 таким образом, чтобы он не попал в LSDB area 0:

R4#sh ip ospf database summ 192.168.7.0

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1672
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 192.168.7.0 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x6061
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 2

R4#
R2(config)#ip prefix-list FILTER deny 192.168.7.0/24
R2(config)#ip prefix-list FILTER permit 0.0.0.0/0 le 32
R2(config)#router ospf 1
R2(config-router)#area 0 filter-list prefix FILTER  in
R4#sh ip ospf database summ 192.168.7.0

            OSPF Router with ID (4.4.4.4) (Process ID 1)
R4#


В целом должно быть очевидно, что фильтрация LSA типа 3 на in в area 0 предотвращает появление информации о соответствующей сети в area 0 и во всех остальных area. Если фильтровать в направлении out в сторону какой-то определенной area, то фильтрация коснется только одной area.

Следующий метод состоит в использовании команды area range, а точнее ее аргумента not-advertise. Напомню, что area range используется в основном для суммаризации маршрутной информации на ABR. Однако опция not-advertise позволяет фильтровать LSA типа 3. Например, нам нужно зафильтровать префикс 192.168.8.0/24 таким образом, чтобы он не попал в LSDB area 0.

R1#sh ip ospf database summary 192.168.8.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Summary Net Link States (Area 0)

  Delete flag is set for this LSA
  LS age: MAXAGE(3607)
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 192.168.8.0 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000004
  Checksum: 0x1F9D
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 16777215

R1#
R3(config)#router ospf 1
R3(config-router)#area 4 range 192.168.8.0 255.255.255.0 not-advertise
R1#sh ip ospf database summary 192.168.8.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)
R1#


В целом можно сказать, что эффект очень схож с тем, какой мы получаем, когда используем area <area-id> filter-list prefix <prefix-list-name> out.

Фильтрация маршрутной информации в таблице маршрутизации.
Далее мы посмотрим, как именно можно вмешаться в процесс добавления OSPF записей в таблицу маршрутизации, не влияя на содержимое LSDB. Здесь сразу стоит отметить, что для достижения корректного эффекта эта фильтрация должна применяться на множестве маршрутизаторов, потому что отсутствие маршрутной информации на одних маршрутизаторах и присутствие ее на других может привести к отсутствию связности там, где она должна быть, и наоборот.
Основным методом здесь стоит назвать использование входящих distribute-list. Исходящие distribute-list, настроенные для процесса OSPF контролируют процесс редистрибьюции в OSPF, а вот входящие - процесс помещения записей в таблицу маршрутизации. Например, нам надо, чтобы R8 "забыл" про доступность сети 192.168.1.0/24:

R8#sh ip route 192.168.1.0
Routing entry for 192.168.1.0/24
  Known via "ospf 1", distance 110, metric 3, type inter area
  Last update from 10.3.8.3 on FastEthernet0/0, 00:50:30 ago
  Routing Descriptor Blocks:
  * 10.3.8.3, from 3.3.3.3, 00:50:30 ago, via FastEthernet0/0
      Route metric is 3, traffic share count is 1

R8#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R8(config)#access-list 1 deny 192.168.1.0 0.0.0.255
R8(config)#access-list 1 permit any
R8(config)#router ospf 1
R8(config-router)#distribute-list 1 in
R8(config-router)#^Z
R8#sh ip route 192.168.1.0
% Network not in table
R8#sh ip ospf database summary 192.168.1.0

            OSPF Router with ID (8.8.8.8) (Process ID 1)

                Summary Net Link States (Area 4)

  Routing Bit Set on this LSA
  LS age: 1163
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 192.168.1.0 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0x2A93
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 2

R8#

Хорошо видно, что маршрут до указанной сети из таблицы пропал, а в LSDB соответствующая LSA типа 3 по-прежнему есть.
Функционал этой команды может быть достаточно широким при использовании варианта distribute-list route-map <route-map-name> in. В этом случае фильтрацию можно произовдить с использованием route-map, который, как мы знаем, позволяет "распознавать" маршруты по большому количеству параметров (адрес сети, тип метрики, источник и прочее).

В принципе в качестве еще одного метода можно указать манипуляцию административной дистанцией. Напомню, что для процесса OSPF доступна команда distance, которая позволяет поменять AD для каких-то определенных маршрутов. Задание административной дистанции 255 для какого-нибудь маршрута делает этот маршрут непригодным для использования. Команда позволяет также указать источник маршрутной информации. Например, нам надо избавиться от префикса 192.168.2.0/24 в таблице маршрутизации R4:

R4#sh ip route 192.168.2.0
Routing entry for 192.168.2.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.2.4.2 on FastEthernet0/0, 01:01:20 ago
  Routing Descriptor Blocks:
  * 10.2.4.2, from 2.2.2.2, 01:01:20 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1

R4#
R4(config)#ip prefix-list R2-PREFIX permit 192.168.2.0/24
R4(config)#router ospf 1
R4(config-router)#distance 255 0.0.0.0 255.255.255.255 R2-PREFIX
R4#sh ip route 192.168.2.0
% Network not in table
R4#


Здесь последовательность 0.0.0.0 255.255.255.255 означает, что мы хотим выставить административную дистанции 255 для необходимого маршрута через любого соседа. Подставляя сюда другие значения, можно манипулировать видимостью сети через отдельные маршрутизаторы.

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

Андрей Петрунин, учебный центр Fast Lane

602 просмотров
1 Комментарии

При решении задач маршрутизации мультикастного трафика посредством протокола PIM в режиме sparse есть необходимость назначения каких-то маршрутизаторов на роль Randezvous point (RP). Каждый маршрутизатор, вовлеченный в форвардинг мультикастного трафика, должен знать, какое именно устройство выполняет роль RP. На данный момент существует три механизма, посредством которых происходит назначение маршрутизаторов на роль RP, а также распространение информации об активных RP:
1. Статическая конфигурация.
2. Алгоритм Auto-RP.
3. Механизм Bootstrap router.
В этой статье мы остановимся на рассмотрении последнего механизма, который является встроенным для протокола PIMv2 и который позволяет автоматически выбирать RP из множества кандидатов, балансировать нагрузку между несколькими RP, а также автоматически сообщать всем маршрутизаторам домена PIM об активных RP. Работу механизма bootstrap router мы будем рассматривать на примере топологии, приведенной ниже:
Работа механизма основана на выборе так называемого Bootstrap Router (BSR) из некого множества кандидатов на эту роль (Bootstrap candidate). Выбор BSR важен, поскольку именно он будет собирать (систематизировать) информацию обо всех кандидатах на роль RP и распространять ее всем маршрутизаторам в домене PIM. Таким образом, среди маршрутизаторов домена PIM администратором должны быть выбраны и настроены Bootstrap candidate и PR candidate. При этом в домене могут остаться маршрутизаторы,не назначенные ни на ту, ни на другую роль.
Впоследствии выбранный BSR "расскажет" всем маршрутизаторам PIM домена, какие RP кандидаты существуют, и какие группы они могут обслуживать. Поскольку BSR является критическим элементом, несколько остановимся на процессе его выбора среди множества Bootstrap кандидатов.

Выбор BSR
Каждый маршрутизатор, который был назначен на роль Bootstrap candidate, начинает рассылать со своего адреса специальные сообщения Bootstrap протокола PIMv2. Эти сообщения рассылаются на адрес 224.0.0.13 (зарезервирован за протоколом PIMv2) каждые 60 секунд и содержат информацию о каждом Bootstrap кандидате. В частности там будет указан адрес Bootstrap кандидата и его приоритет. Эти сообщения обрабатываются маршрутизаторами PIM домена следующим образом: каждый маршрутизатор, принявший сообщение Bootstrap, применяет к нему правила RPF check и передает его всем PIM соседям, кроме того, от которого сообщение было только что получено. RPF check сообщений Bootstrap позволяет предотвратить ненужный флудинг этих сообщений и повторную их обработку (сообщения Bootstrap, не прошедшие RPF check маршрутизаторами PIM домена попросту игнорируются).
В результате информация о Bootstrap кандидатах становится известна каждому маршрутизатору, вовлеченному в PIM домен, включая других Bootstrap кандидатов. Одновременно с этим происходит выбор одного из Bootstrap кандидатов на роль BSR. Выбор производится на основании сравнения приоритетов кандидатов. Bootstrap кандидат с наибольшим приоритетом должен стать BSR. Если приоритеты совпадают, то выбор производится в пользу маршрутизатора с наибольшим IP адресом. Кандидаты, принимающие Bootstrap сообщения от других таких же Bootstrap кандидатов, самостоятельно сравнивают приоритет (или IP адрес) другого кандидата со своим локальным. Если алгоритм выбора BSR решает не в пользу локального Bootstrap кандидата, то он (кандидат) перестает рассылать собственные сообщения Bootstrap. Благодаря этому через какое-то время в PIM домене останется только один Bootstrap кадидат, рассылающий сообщения Bootstrap (по-прежнему каждые 60 секунд). Именно он и будет выполнять роль BSR.
Следует отметить, что алгоритм выбора BSR вполне естественным образом позволяет "вытеснить" текущий BSR, если вдруг в сети появится другой маршрутизатор, назначенный на роль Bootstrap candidate, с бОльшим приоритетом или бОльшим IP адресом.

Сбор информации о RP кандидатах
Выбрать BSR на сети нужно для того, чтобы каждый маршрутизатор, назначенный на роль RP кандидата, мог сообщить об этой своей роли, а также о списке групп, которые он собирается обслуживать, маршрутизатору BSR. Происходит это посредством рассылки юникастных сообщений Candidate-RP-Advertisement от каждого RP кандидата на адрес BSR. Рассылка эта имеет периодический характер, и период отправки сообщений составляет 60 секунд по умолчанию. В результате BSR получает список всех RP кандидатов и соответствующих им диапазонов групп. Здесь следует отметить, что нет никаких правил в распределении диапазона мультикастных групп по RP кандидатам. То есть все пространство мультикастных групп 224.0.0.0/4 может быть распределено между RP кандидатами таким образом, чтобы каждый RP кандидат обслуживал какую-то свою и только свою часть этого пространства (то есть диапазоны групп, назначенные на разных RP кандидатов, не будут пересекаться). Или же можно заставить разных RP кандидатов обслуживать одни и те же или пересекающиеся диапазоны групп. Например, все пространство 224.0.0.0/4 может быть назначено для каждого RP кандидата, сколько бы их ни было.
Особенностью механизма Bootstrap router является то, что маршрутизатор, выбранный в качестве BSR, не производит выбора активных RP из всего множества кандидатов. После получения всего множества сообщений Candidate-RP-Advertisement от всех RP кандидатов BSR систематизирует полученную информацию и вносит ее в собственные сообщения Bootstrap, рассылаемые по-прежнему с периодом 60 секунд. Таким образом, все маршрутизаторы PIM домена начинают периодически получать информацию обо всех RP кандидатах и списках их групп.

Назначение активной RP
Далее начинается самое интересное. Маршрутизаторы по специальному алгоритму определяют, какие именно RP кандидаты будут назначены на роль активной RP для каждой мультикастной группы. Алгоритм берет адрес группы и список всех RP кандидатов, которые заявляют о возможности обслуживать эту группу. Далее выполняются следующие шаги:
1. Ищутся те RP кандидаты, которые заявляют наиболее специфичный диапазон групп, включающий рассматриваемую группу.
2. Если в результате остается несколько RP кандидатов, то выбираются те, для которых настроен численно меньший приоритет. Здесь стоит остановиться и сказать, что приоритет в механизме bootstrap router задается не только для Bootstrap кандидатов, но и для RP кандидатов. Именно этот приоритет и является решающим на данном этапе.
3. Если после пунктов 1 и 2 все еще осталось несколько RP кандидатов для конкретного адреса, маршрутизатор вычисляет результат hash функции, которая в качестве входных данных использует адрес группы, адрес RP кандидата и так называемую hash mask. Тот RP кандидат, для которого значение полученного hash получилось численно больше, будет назначен в качестве активной RP для рассматриваемой группы.
4. Если после пункта 3 все равно осталось несколько RP кандидатов, то кандидат с бОльшим IP адресом становится активным RP.
Рассмотрим пример работы этого алгоритма для сети, топология которой приведена выше.
На роль Bootstrap кандидатов назначены R4 и R5. Делалось это следующими командами.

R4:
R4(config)#ip pim bsr-candidate lo0 32 10
R5:
R5(config)#ip pim bsr-candidate lo0 32 5


Синтаксис команды выглядит следующим образом:
ip pim bsr-candidate interface-type interface-number [ hash-mask-length [priority] ]

В качестве интерфейсов заданы loopback0, длина hash mask равна 32 битам (об этом параметре чуть позже), приоритеты заданы 10 и 5 соответственно.
В выборах BSR победит маршрутизатор R4, поскольку для него был задан приоритет 10, а для R5 - всего лишь 5. Это хорошо видно в выводе команды sh ip pim bsr-router.

 
R6#sh ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 4.4.4.4 (?)
Uptime:      01:48:27, BSR Priority: 10, Hash mask length: 32
Expires:     00:01:17
R6#
 
На роль RP кандидатов были назначены следующие маршрутизаторы:
HostnameIP addressGroup rangePriority
R11.1.1.1224.0.0.0/41
R22.2.2.2238.0.0.0/810
R33.3.3.3238.0.0.0/810
Соответствующие команды для этой конфигурации представлены ниже:

R1:
R1(config)#ip pim rp-candidate lo0 group-list 1 priority 1
R2:
R2(config)#ip pim rp-candidate lo0 group-list 1 priority 10
R3:
R3(config)#ip pim rp-candidate lo0 group-list 1 priority 10


Пример конфигурации ACL 1, который используется для обозначения диапазона групп на R3:
R3(config)#access-list 1 permit 238.0.0.0 0.255.255.255

 
Возникает задача определить, какой RP кандидат будет назначен на роль активной RP для, например, группы 238.1.1.1.
В соответствии с первым шагом алгоритма, R1 не подходит, потому что другие кандидаты анонсируют диапазоны групп, более точно подходящие для 238.1.1.1. На основании второго шага определиться с выбором кандидата тоже не удается, поскольку R2 и R3 настроены с одинаковым приоритетом. Далее алгоритму придется посчитать два значения hash функции.
Сама функция выглядит следующим образом
Value(G,M,C(i))=(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31, где
G - адрес рассматриваемой мультикастной группы;
M - hash mask (этот параметр мы обсудим чуть позже);
C(i) - адрес RP кандидата.
Для нашего случая получаются следующие значения хешей:
R2 - 1479713549
R3 - 1916634234
Это хорошо видно из следующего вывода:
 
R6#sh ip pim rp-hash 238.1.1.1
RP 3.3.3.3 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:54:23, expires: 00:00:42
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 1479713549
RP 3.3.3.3, via bootstrap, priority 10, hash value 1916634234
R6#
 
Собственно на этом шаге понятно, что для группы 238.1.1.1 в качестве активного RP будет назначен R3.
В этом примере предполагается, что hash mask имеет длину 32 бита. На этом параметре мы остановимся поподробнее.
Сама длина hash mask, как мы уже видели, задается на Bootstrap кандидатах при их настройке, и после выбора BSR рассылается всем маршрутизаторам в сообщении bootstrap. Этот параметр служит для распределения нагрузки между всеми RP кандидатами. Фактически изменяя длину hash mask можно повлиять на то, сколько групп в среднем будет обслуживать каждый RP кандидат (то есть примерно для скольки групп RP кандидат станет активным RP). Стоит обратить внимание, что в hash функции hash mask и адрес группы объединены логическим "И". Значит, hash mask определяет, сколько первых бит из адреса группы будут взяты в учет hash функцией. Результат работы функции приводит к тому, что все объявленное пространство групп будет распределено между всеми кандидатами, и каждая RP получит примерно 2^[32-hash_mask_length] групп при условии, что количества кандидатов будет достаточно для такого распределения. В нашем примере это означает, что при длине hash mask, равной 32, каждая RP получила бы примерно по 2^[32-32], то есть 1 группе при условии, что у нас есть достаточное количество кандидатов (2^24). Для наших оставшихся после первых двух шагов алгоритма кандидатов произойдет распределение всего пространства заявленных групп (238.0.0.0/8) примерно поровну.
Если посмотреть, какие RP занимаются обслуживанием других групп, то можно увидеть, что группы распределяются по RP действительно примерно поровну.
 
R6#sh ip pim rp-hash 238.1.1.4
RP 2.2.2.2 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:56:15, expires: 00:01:53
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 657697788
RP 3.3.3.3, via bootstrap, priority 10, hash value 220777103
R6#sh ip pim rp-hash 238.1.1.5
RP 3.3.3.3 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:56:16, expires: 00:01:53
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 239255729
RP 3.3.3.3, via bootstrap, priority 10, hash value 1313710622
R6#sh ip pim rp-hash 238.1.1.13
RP 3.3.3.3 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:55:59, expires: 00:02:10
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 285971449
RP 3.3.3.3, via bootstrap, priority 10, hash value 1572032358
R6#sh ip pim rp-hash 238.1.1.14
RP 2.2.2.2 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:56:01, expires: 00:02:06
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 1287682658
RP 3.3.3.3, via bootstrap, priority 10, hash value 155107061
 
Стоит отметить, что по умолчанию длина hash mask равна 0. Это означает, что номер группы функцией вообще не учитывается, и все группы попадают на одну RP.
В качестве итога рассмотрим настраиваемые параметры, влияющие на работу механизма в целом:
1. bsr-candidate priority. Влияет исключительно на выбор BSR.
2. rp-candidate priority. Позволяет более очевидно (нежели воздействие на hash функцию) распределить группы по активным RP.
3. длина hash mask. Позволяет контролировать среднее количество групп, доставшихся каждой RP.
 
---
Андрей Петрунин
заместитель технического директора ООО "Фаст Лейн"

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