Часть 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 состоит из трех частей: Source ID. Сюда подставляется System ID маршрутизатора, сгенерировавшего эту LSP. Недаром длина этого поля равна 6 байтам, что явно совпадает с длиной System ID в протоколе IS-IS. Pseudonode ID. Это поле равно нулю для «обычных» LSP. Под «обычными» мы пока будем понимать те LSP, определение которым дали раннее. Есть еще дополнительные LSP, которые генерируются маршрутизаторами  , выбранными на роль DIS.  В них это поле будет принимать ненулевое значение. Об этом мы детально поговорим чуть позже, разбирая пример LSDB. 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 отметить байтовое поле с флагами: P – занимает 1 бит, был придуман в стандарте, сейчас не нужен, поэтому равен 0. ATT – занимает 4 бита и расшифровывается как Attached. Используется маршрутизаторами L1 для определения устройств, подключенных к backbone. Подробно поговорим о нем позже. OL – один бит, который называется Overload. Может использоваться, если администратору нужно направить транзитный трафик в обход данного маршрутизатора. Если этот бит в LSP выставлен, то другие маршрутизаторы не будут учитывать присутствие этого устройства в топологии при расчете алгоритмом SPF. Это позволяет временно выводить маршрутизаторы из обслуживания (например, для перезагрузки), обеспечивая при этом перемаршрутизацию транзитного трафика, идущего через эти маршрутизаторы, по альтернативным путям. Кстати, в OSPF подобного механизма не существует. 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: Area address. Тут мы видим, что R1 представляется как участник area 49.0001, что соответствует действительности. Protocols Supported. Видим, что заявлен NLPID (Network Layer Protocol ID) 0xCC, что в IS-IS соответствует IPv4. Dynamic Hostname. Тут комментарии излишни: мы видим, что R1 сообщает свой hostname. Кстати, можно обратить внимание, что все выводы команд, которые мы уже посмотрели, вместо System ID маршрутизаторов содержат их hostname. Это становится возможным как раз благодаря включению этой TLV в LSP на каждом маршрутизаторе. IS neighbors. R1 заявляет, что его соседями являются R2, R3 и R4, и до каждого он может добраться через интерфейс с метрикой 10. IP interface addresses. По стандарту сюда должны подставляться IP адреса интерфейсов, через которые происходит рассылка LSP. По умолчанию маршрутизаторы Cisco подставляют сюда адрес, настроенный на интерфейсе Loopback 0. 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" ... View more

  c Андреем Петруниным   Во время презентации были рассмотрены возможности Cisco TelePresence Server, логика его конфигурации, различные сценарии интеграции с CUCM и VCS, а также роль Cisco Telepresence Conductor в этой интеграции. В результате презентации слушатели получили представление о логике работы и настройки Cisco TelePresence Server для разных сценариев использования. Также был предложен процесс поиска неисправностей при работе TelePresence Server.   Хотите узнать больше информации об этом событии?            ... View more

Прежде всего хотели бы поблагодарить всех, кто принял участие в конкурсе.   Правильный ответ: Cisco ClearPath   Победители: 1) Евгений Зуевский 2) Никита Соколов 3) Павел Клёнов   Поздравляем! И ждем вашего участия в наших дальнейших конкурсах! ... View more

В прошлой статье мы рассмотрели основные принципы построения домена маршрутизации 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): Point-to-Point L1 LAN 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 следующими деталями: Не выбирается Backup DIS. Соседства в таком широковещательном домене все равно формируются по схеме Full Mesh, а не только между DIS и не-DIS. Выставление приоритета, равного 0, не означает, что маршрутизатор не может быть выбран DIS. Если в широковещательный домен добавить маршрутизатор с более высоким приоритетом, чем у текущего DIS, то произойдут перевыборы, и новый маршрутизатор возьмет на себя роль нового DIS. Возможно существование разных DIS на уровне 1 и на уровне 2.  После формирования adjacency маршрутизаторы начинают обмениваться данными о топологии и наполнять свои базы данных топологий. О структуре этой базы в протоколе IS-IS и о процессе обмена топологической информацией мы поговорим в следующей статье. --- Андрей Петрунин, Учебный Центр Fast Lane ... View more

   Все, кто имеет представление о динамической маршрутизации трафика в 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 содержит следующие поля: AFI - 49 Area ID - 0001 System ID - 0a4516df8700 Selector - 00  На самом деле, как уже упоминалось, AFI маршрутизаторами воспринимается как часть area ID, поэтому в практической реализации при использовании указанного выше NET адреса, можно сказать, что маршрутизатор принадлежит area 49.0001.    Так вот, возвращаясь к иерархичности протокола. Домен маршрутизации IS-IS можно разделить на области, но в основе иерархичности IS-IS лежат не сами области, а уровни взаимодействия маршрутизаторов друг с другом. Дело в том, что пара IS-IS маршрутизаторов, подключенных друг к другу прямым линком (или через L2 домен), могут сформировать два вида (или два уровня) взаимодействий - Level 1 и Level 2 (L1 и L2 соответственно). Правила для организации соседств разных уровней следующие: Соседство уровня 1 (L1) формируется только между маршрутизаторами одной area. Соседство уровня 2 (L2) может быть сформировано как между маршрутизаторами одной area, так и между маршрутизаторами разных area.    Кстати, такие два уровня взаимодействий позволяют выделить три типа маршрутизаторов в IS-IS домене: Маршрутизаторы L1 - это те устройства, у которых все взаимодействия с другими маршрутизаторами происходят на 1 уровне. Маршрутизаторы L2 - это те устройства, у которых все соседства организованы на 2 уровне. Маршрутизаторы 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 ... View more

В этот раз мы рассмотрим такую частую и крайне неприятную ситуацию, как случайная потеря управления коммутатором 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,20 3,212 switchport trunk allowed vlan add 213,222,223,292,293,302,303,312,313,322,3 23 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,20 3,212 switchport trunk allowed vlan add 213,222,223,292,293,302,303,312,313,322,3 23 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. То есть это коммутаторы которые могут быть включены в кластер, но еще не включены. Кандидаты должны удовлетворять следующим требованиям: Правильный софт, поддерживающий технологию кластеризации (http://cisco.com/go/fn наше все). Включенный глобально и на траковом порту CDP версии 2. Отсутствие членства в других кластерах (каждый коммутатор независимо от роли может являться частью только одного кластера). Подключение к 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 ... View more

Hello. I'm facing a very interesting problem with the standart CUCM corporate directory. The issue is that all the phones in the enterprise have Russian user and network locales installed (and it works just fine: all menus are in russian), but the corporate directory search still remains in english. I mean, when the user presses Directory Button, he sees "Directory search" phrase in english. The directory itself contains the First and Last names as they are in LDAP (in russian), but it is the corporate directory menu that remains in english. I haven't found any usefull hints for this in community. Could anyone please suggest some way to solve this? Thanks in advance. P.S. CUCM is really old one (7.1.5.35901-1), and most of the phones are 9.3.1 (SCCP). ... View more