Isis lan adjacency sid advertisement это
1. Основы IGP протокола OSPF класса Link-State или базовая настройка динамической маршрутизации на роутере Cisco
OSPF, как и любой другой порядочный протокол, используемый в компьютерных сетях, очень легко настроить, но под пальто у этого джентльмена скрывается очень много процессов, которые хороший инженер должен знать и понимать, как эти процессы проходят и почему они проходят именно так, а не как иначе. Да вы и сами в этом убедитесь, в каждой публикации по протоколу OSPF десятая часть будет посвящена командам, а всё остальное будет про то, что происходит в нашей сети после этих команд.
1.1 Введение
Первым протоколом динамической маршрутизации, о котором хотелось бы рассказать является OSPF. Почему OSPF? Потому что именно этот протокол применяется в локальных сетях для обмена маршрутной информацией чаще всего. Дело в том, что старичка RIP используют в основном некрофилы и микротикофилы, EIGRP — проприетарный протокол Cisco и для его работы вся сеть должна быть построена на оборудование этого вендора, BGP — хороший, гибкий, управляемый протокол, но заточен он не для маршрутизации внутри автономной системы, а между автономными системами, время сходимости у BGP значительно выше, нежели у трех других.
1.2 Основы протокола OSPF
На данный момент в мире две версии протокола OSPF: OSPFv2 и OSPFv3. Первая используется для динамической маршрутизации IPv4 (RFC 2328), вторая для IPv6 (RFC 2740). Вне зависимости от версии протокола OSPF относится к группе IGP протоколов, а это означает, что используется он в пределах одной автономной системы. Когда мы разберемся с тем, как работает OSPF, вы поймете, что этот протокол не применим для глобальной маршрутизации в силу естественных причин, связанных с производительностью роутеров, им просто не хватит вычислительной мощности, чтобы просчитать все маршруты Интернета по алгоритмам, применяющимся в OSPF.
В основе работы протокола OSPF лежит Алгоритм Дейксты или алгоритм поиска кратчайшего пути, отсюда, собственно и вытекает SPF (shortest path first). Для обмена информацией о маршрутах, а также для обмена дополнительной информацией, использует несколько разных типов пакет. Какие? Потом разберемся. Сейчас нам нужно для себя отметить, что пакеты OSPF инкапсулируются в IP-пакеты. Вы должны помнить, что у IP-пакета есть код вложения, увидев этот код, роутер поймет, что находится внутри IP-пакета, для OSPF зарезервирован код 89. Передача OSPF пакета может происходить как unicast, так и multicast, при этом используется два multicast адреса:
Ну и еще одна важна вещь, о которой стоит сказать. OSPF относится к протоколам типа Link-State, а это означает, что каждый маршрутизатор внутри автономной системы обладает полным представлением о том, как устроена его сеть на уровне IP протокола (то есть на сетевом уровне моделей TCP/IP и OSI 7), в дальнейшем мы убедимся, что это не так и поймем, почему это не так, опять же, всё упирается в производительность железок.
1.3 Терминология протокола OSPF
Терминология в OSPF, как и у любого сложного протокола, довольно объемная, буду рад, если в комментариях появятся дополнения. Термины я приведу сразу, чтобы потом каждый раз к ним не возвращаться.
ПРЕДУПРЕЖДЕНИЕ: не пытайтесь заучить эти термины, лучше при прочтении возвращается к этому месту, если какое-то слово покажется вам незнакомым, смысла заучивать нет, все необходимое запомнится само по мере погружения в тему.
Для облегчения задачи мы разделим термины на три группые. Стоит добавить, что терминология OSPF является устоявшейся, но все равно некоторые вендоры могут вводить что-то свое, в этом случае рекомендую обращаться к документации вендора или в Google, там ответ вы точно найдете.
1.3.1 Основные термины протокола OSPF
Начнем с основных терминов, которые так или иначе есть практически во всех протоколах динамической маршрутизации.
Это были общие термины, относящиеся к протоколу OSPF
1.3.2 Соседи и отношения соседства в OSPF
Компьютерные сети бывают большими и с огромным количеством роутеров, и этим роутерам нужно как-то взаимодействовать друг с другом в большой сети. Для описания взаимодействия роутеров по протоколу OSPF есть несколько терминов.
- Сосед/соседи (neighbor/neighbors) – это два маршрутизатора, которые находятся в одной канальной среде, но это еще не всё. На интерфейсах этих маршрутизаторов, смотрящих друг на другу, должен быть включен и правильно настроен OSPF, то есть настройки должны быть консистентные с обеих сторон.
- Отношение соседства (adjacency) – маршрутизаторы в OSPF должны постоянно синхронизировать свои базы данных, в которых хранится информации о сети, если два маршрутизатора нормально обмениваются такой информацией, то можно сказать, что они имеют соседские отношения.
- Hello-протокол (hello-protocol) – для поиска соседей, установления соседства, а также для поддержания соседских отношений маршрутизаторы используют hello-пакеты.
- База данных соседей (neighbors database) – маршрутизатор должен знать всех своих соседей, чтобы в случае чего потыкать в них палочкой и что-нибудь уточнить или что-нибудь сообщить своим соседям, например, если появилась новая сеть. Для этих целей у маршрутизаторов есть список соседей, иногда этот список называется neighbors table.
Это основные термины, которыми можно описать взаимоотношения между роутерами в рамках протокола OSPF.
1.3.3 Виды пакетов в OSPF
Последний блок терминов, который мы рассмотрим, касается пакетов в OSPF, их довольно много и у каждого типа свое назначение. Тут главное не запутаться пакетов много.
Теперь вы знаете пакеты, которыми обмениваются маршрутизаторы при взаимодействие по протоколу OSPF.
1.4 Как работает протокол OSPF: краткая теория и практика на примере маршрутизаторов Cisco.
Сейчас мы очень коротко, хотя так может и не показаться, поговорим о том, как работает протокол OSPF на маршрутизаторах Cisco и рассмотрим его самые базовые настройки, потом от этого материала мы сможем отталкиваться, чтобы разбираться с деталями и более глубоко изучить этот протокол. В общем, нам нужно получить общее понимание о том, как работает OSPF.
1.4.1 Схема для демонстрации и настройки IP-протокола на маршрутизаторе
Начнем с того, что я покажу вам схему, с которой мы будем работать и IP-адреса, которые будем использовать. Схему я собирал в EVE-NG, дамп трафика делал при помощи Wireshark, в качестве Telnet клиента я использую SecureCRT. Сама схема показана ниже.
1.1 Схема для демонстрации базовой настройки протокола OSPF на оборудование Cisco
Да, вот так незамысловато. Два роутера, два интерфейса, они подписаны на рисунке. На физическом интерфейсе RO1 я буду использовать IP-адрес 10.0.0.1/24, а на физическом интерфейсе RO2 10.0.0.2/24, у каждого роутера есть Loopback интерфейс, цель которых – имитировать клиентские сети. Если вам так неудобно, то представьте, что к роутеру RO1 подключен компьютер с IP-адресом 1.1.1.1, а к роутеру RO2 подключен компьютер с адресом 2.2.2.2.
Сначала обсудим отдельные элементы.
Как известно, в IS-IS есть 2 типа L2-соединений: LAN и P2P. Исторически сложилось так, что LAN использовался по умолчанию для broadcast-сетей (Ethernet), а P2P – для протоколов сетей традиционных телекоммуникаций (например, PPP или Frame Relay). Но на сегодняшний день протокол Ethernet является стандартом де-факто и при установке отношений соседства между устройствами можно указать необходимый тип сети. Важно также знать, что на обоих маршрутизаторах типы сетей должны совпадать, иначе соседства не будет.
В IIH маршрутизатор сообщает о себе всю необходимую информацию, которая проверяется соседом на соответствие его собственным таймерам и настройкам. В далеко не полный перечень входят: AreaID, поддерживаемый протокол адресации, тип сети, префикс сети, поддержка дополнительных capabilities и т.д. Если параметры не совпадают, то отношения соседства не будут установлены.
Для идентификации отдельных устройств IS-IS использует NET (Network Entity Title), который является наследником CLNS (протокол адресации подобный IP, использовался в стеке протоколов OSI, который планировалось внедрить вместо TCP/IP, но что-то пошло не так). Типичный NET-адрес представляется в виде 49.0001.0000.0000.0001.00, где AreaID – 49.001, а интересующий нас SystemID – 0000.0000.0001. Как правило, он назначается администратором вручную, но есть возможность его назначить и автоматически (в последнем случае в поле SystemID подставляется mac-адрес маршрутизатора).
DIS (Designated Intermediate System) – выделенный маршрутизатор сегмента. Выбирается в LAN-сегменте и отправляет в другие части своей area информацию о своих сетях, а также сетях соседа, представляясь всем остальным устройствам так, что как-будто сети его соседа подключены к нему напрямую. DIS выбирается на основе настроенного приоритета. Если приоритет одинаковый, то побеждает маршрутизатор с самым старшим mac-адресом интерфейса, подключенного к текущему LAN-сегменту. Самый близкий аналог – это DR в OSPF и LSA type 2. Но они похожи только на первый взгляд, на самом деле DIS и DR очень сильно отличаются друг от друга.
С отдельными кусочками мы разобрались. Теперь попробуем из них собрать мозаику.
Изначально считалось, что P2P-линки являются более надежными, поэтому при установке отношений соседства использовался механизм 2Way-Handshake.
Пока все просто, не так ли?
С течением времени выяснилось, что все-таки P2P-линки не такие надежные, как хотелось бы, поэтому для них был разработан механизм 3Way-Handshake.
R1, отправляя IIH, сообщает R2 свое состояние как Down. R2 проверяет все параметры IIH R1 и убедившись, что они совпадают с его собственными, переводит свое состояние в Init и сообщает R1 в своем IIH о своем состоянии. R1 приняв IIH от R2 тоже проводит сверку параметров и при их совпадении переводит свое состояние в Up. Далее R1 уведомляет в ответном IIH, что его состояние Up, а R2, приняв этот IIH, тоже переходит в состояние Up.
Между прочим, если у двух маршрутизаторов все параметры совпадают, но отношения соседства не устанавливаются, то имеет смысл проверить, а включены ли у них одинаковые механизмы? Если у одного устройства стоит 2Way, а у второго 3Way, то adjacency они не достигнут. Такая ситуация, как правило, возникает при соединении маршрутизаторов разных вендоров, где по умолчанию включены разные механизмы рукопожатий.
Установка отношений соседства на LAN-сети
Для их установки используется все тот же механизм 3Way-Handshake, описанный выше. Поэтому с двумя устройствами, соединенными прямым линком все будет также. И это неинтересно. Добавим щепотку специй в наше блюдо и рассмотрим установку отношений соседства между тремя маршрутизаторами, соединенными через коммутатор (т.е. через единый броадкастовый домен). Особенность заключается в том, что после обмена IIH и отработкой 3Way-Handshake, выбирается DIS для этого сегмента.
Дело в том, что после установки отношений соседства, маршрутизаторы смотрят на приоритеты соседей в IIH, а т.к. на LAN-сети DIS выбирается всегда, то после установки adjacency определяется, кто будет DIS. На рисунке выше схема упрощена в том месте, что не отображается отработка механизма 3Way-Handshake. Да мы и так уже это знаем. Все маршрутизаторы устанавливают adjacency по принципу “каждый с каждым”, т.е. у нас имеется full-mesh топология. Сначала каждый маршрутизатор считает, что он главный и отправляет свой IIH, сообщая всем соседям, что он DIS. Постепенно все соседи узнают, у кого самый высокий приоритет, перестают в своих IIH указывать себя в роли DIS и сообщают, что DIS теперь R3.
Хммм… Что-то мне это сильно напоминает… Ах да! Подобным же образом выбирается Root Bridge в STP.
Ну вот собственно и все, что необходимо знать в базовом варианте об установке отношений соседства. За кадром осталось то, как работает DIS, как происходят его перевыборы, синхронизация LSDB и многое многое другое. Но это, как говорится, совсем другая история…
IS-IS adjacency
Какие именно IIH будут рассылаться маршрутизатором через интерфейс, на котором запущен IS-IS, определяется конфигурацией маршрутизатора или интерфейса (в прошлой статье мы рассматривали примеры управления уровнем соседств). Напомним, что на самых распространенных на данный момент (Ethernet) интерфейсах маршуризаторы по умолчанию рассылают L1 LAN и L2 LAN Hello.
Когда будет получено первое 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 представлен ниже:
Сегментная маршрутизация (Segment Routing, SR) может или не может считаться туннельным решением, в зависимости от конкретной реализации и того, насколько строго вы хотите придерживаться определения туннелей, представленного ранее в статье "Виртуализация сетей". В этой статье будет рассмотрена основная концепция сегментной маршрутизации и две возможные схемы реализации: одна с использованием меток потока IPv6, а другая с использованием меток многопротокольной коммутации по меткам (Multiprotocol Label Switching -MPLS) .
Каждому устройству в сети с поддержкой SR присваивается уникальная метка. Стек меток, описывающий путь в терминах этих уникальных меток, может быть присоединен к любому пакету, заставляя его принимать определенный указанный путь. Рисунок 5 демонстрирует это.
Каждый маршрутизатор на рисунке 5 объявляет IP-адрес в качестве идентификатора вместе с меткой, прикрепленной к этому IP-адресу. В SR метка, прикрепленная к идентификатору маршрутизатора, называется идентификатором сегмента узла (SID узла). Поскольку каждому маршрутизатору в сети присваивается уникальная метка, путь через сеть может быть описан с использованием только этих меток. Например:
Набор меток, используемых для описания пути, называется стеком меток. Между D и H есть две связи; как это можно описать? В SR доступно несколько опций, в том числе:
- Стек меток может включать в себя только идентификаторы SID узла, описывающие путь через сеть в терминах маршрутизаторов, как показано ранее. В этом случае, если бы стек меток включал пару [103,107], D просто перенаправлял бы H в обычном режиме на основе информации локальной маршрутизации, поэтому он будет использовать любой локальный процесс, который он будет использовать для пересылки любого другого пакета, например, распределение нагрузки между двумя каналами для пересылки трафика с меткой SR.
- Стек меток может включать явную метку для загрузки общего ресурса по любому доступному набору путей, доступных в этой точке сети.
- H может назначить метку для каждого входящего интерфейса, а также SID узла, привязанный к его локальному идентификатору маршрутизатора. Эти метки будут объявляться так же, как SID узла, но, поскольку они описывают смежность, они называются SID смежности ( adjacency ). SID смежности уникален локально; он уникален для маршрутизатора, объявляющего сам SID смежности.
Третий вид SID, префиксный SID, описывает конкретный достижимый пункт назначения (префикс) в сети. SID узла может быть реализован как SID префикса, привязанный к loopback адресу на каждом маршрутизаторе в сети.
Не обязательно, чтобы весь путь описывался стеком меток. Например, стек меток [101,103] будет направлять трафик в B, затем в D, но затем позволит D использовать любой доступный путь для достижения IP-адреса назначения в K. Стек меток [105] обеспечит прохождение трафика через сеть к K будет проходить через F. Не имеет значения, как трафик достиг этой точки в сети и как он был перенаправлен после того, как достигнет F, если он проходит через F, будучи направленным к K.
Каждая метка в стеке представляет собой сегмент. Пакеты переносятся от метки к метке через каждый сегмент в сети, чтобы быть транспортированными от головной части пути к хвостовой части пути.
МАРШРУТИЗАЦИЯ СЕГМЕНТОВ С МНОГОПРОТОКОЛЬНОЙ КОММУТАЦИЕЙ МЕТОК
MPLS был изобретен как способ сочетать преимущества асинхронного режима передачи (ATM) , который больше не используется широко, с IP-коммутацией. В первые дни сетевой инженерии наборы микросхем, используемые для коммутации пакетов, были более ограничены в своих возможностях, чем сейчас. Многие из используемых наборов микросхем были Field Programmable Gate Arrays (FPGA) , а не Application-Specific Integrated Circuits (ASIC) , поэтому длина поля, в котором коммутировался пакет, напрямую коррелировала со скоростью, с которой пакет мог коммутироваться. Часто было проще переработать пакет или обработать его дважды, чем включать в заголовок много сложной информации, чтобы пакет можно было обработать один раз.
Примечание: повторное использование пакетов по-прежнему часто используется во многих наборах микросхем для поддержки внутренних и внешних заголовков или даже для обработки различных частей более длинного и сложного заголовка пакета.
MPLS инкапсулирует исходный пакет в заголовок MPLS, который затем используется для коммутации пакета по сети. На рисунке 6 показан заголовок MPLS. Весь заголовок состоит из 32 бит, метка 20 бит. Устройство пересылки MPLS может выполнять три операции:
- Текущая метка в заголовке MPLS может быть заменена другой меткой ( SWAP ).
- В пакет можно вставить новую метку ( PUSH ).
- Текущая метка может быть очищена, а метка под текущей меткой обработана ( POP ).
Операции PUSH и POP переносятся непосредственно в SR: операция SWAP реализована в SR как CONTINUE, что означает, что текущая метка заменяется той же меткой (т. е. заголовок с меткой 100 будет заменен меткой 100), и обработка этого текущего сегмента будет продолжена. Проще всего понять процесс обработки на примере. Рисунок 7 демонстрирует это.
На рисунке 7 каждому маршрутизатору присвоена глобально уникальная метка из глобального блока сегментной маршрутизации ( Segment Routing Global Block -SRGB ). Они объявляются через протокол маршрутизации или другую плоскость управления. Когда A получает пакет, предназначенный для N, он выбирает путь через сеть, используя некоторый локальный механизм. В этот момент:
Концепция стека меток в MPLS реализована в виде серии заголовков MPLS, уложенных друг на друга. Pop метки означает удаление самой верхней метки, push метки означает добавление нового заголовка MPLS в пакет, а continue означает замену метки идентичной меткой. Когда вы работаете со стопкой меток, понятия внутреннего и внешнего часто сбивают с толку, особенно, поскольку многие люди используют идею метки и заголовка как взаимозаменяемые. Возможно, лучший способ уменьшить путаницу - использовать термин " заголовок " для обозначения всего стека меток и исходного заголовка, переносимого внутри MPLS, при этом обращаясь к меткам как к отдельным меткам в стеке. Тогда внутренний заголовок будет исходным заголовком пакета, а внешний заголовок будет стеком меток. Внутренняя метка будет следующей меткой в стеке в любой момент прохождения пакета по сети, а внешняя метка будет меткой, по которой пакет фактически переключается.
Хотя в приведенном здесь примере используются IP-пакеты внутри MPLS, протокол MPLS предназначен для передачи практически любого протокола, включая Ethernet. Таким образом, SR MPLS не ограничивается использованием для передачи одного типа трафика, но может также использоваться для передачи кадров Ethernet по сети на основе IP / MPLS. Это означает, что SR можно использовать для поддержки первого варианта использования, обсуждаемого в этой статье, - предоставления услуг Ethernet по IP-сети.
MPLS - ЭТО ТУННЕЛЬ?
Много написанных и произнесенных слов были пролиты на вопрос о том, является ли MPLS протоколом туннелирования. Здесь туннелирование определяется как действие, а не протокол; это намеренная попытка отделить идею протокола туннелирования от концепции туннелирования как действия, предпринимаемого при передаче трафика через сеть. В случае MPLS это означает, что он может быть, а может и не быть протоколом туннелирования, в зависимости от того, как он используется - как и любой другой протокол. Например, если у вас есть стек меток, помещенных поверх пакета с IP-заголовком, внешняя метка, на которую коммутируется пакет, не является (технически) туннелем. Этот внешний заголовок в сети MPLS фактически является локальным для сегмента, поэтому он либо выталкивается, либо отправляется на каждом маршрутизаторе. Это аналогично заголовку Ethernet для каждого канала. Однако внутренний заголовок переносится в пакете MPLS и, следовательно, технически туннелируется. Внутренняя метка не используется на текущем устройстве для коммутации пакета; он просто переносится как часть пакета.
Это определение не идеально. Например, в случае MPLS SWAP или SR CONTINUE, используется ли метка для коммутации пакета или нет? Кроме того, в отличие от заголовка Ethernet в пакете, заголовок MPLS фактически используется при принятии решения о пересылке. Заголовок Ethernet, напротив, просто используется для достижения следующего перехода, а затем отбрасывается. Возможно, более подходящим сравнением было бы следующее: Заголовок MPLS подобен заголовку Ethernet, который используется для достижения перехода за пределы устройства, на которое маршрутизатор в настоящее время передает.
Независимо от этих ограничений, этого определения обычно достаточно, чтобы мысленно управлять различием между туннелированием и не туннелированием в MPLS, а также в большинстве других протоколов.
Читайте также: