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

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

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


IS-IS adjacency


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

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

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



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



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



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



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



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



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



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

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

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

Продолжение уже есть?

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