отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

IS-IS для тех, кто понимает OSPF (часть 3)

New Member

Часть 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"

1 Комментарий
New Member

Кстати, на счёт отсутствия механизма OL в OSPF я бы не согласился. Просто он реализуется по другому. Ставим cost всех транзитных линков прегруженного роутера в 0xffff. Как результат, этот роутер не будет транзитным, при этом его stub линки будут доступны. Может быть менее грациозно, но результат тот же.

11
Просмотры
5
Полезный материал
1
Комментарии