По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье вы познакомитесь с основами BGP и узнаете о его различных типах сообщений и состояниях.
Все статьи из цикла про BGP:
Построение маршрута протоколом BGP
Формирование соседства в BGP
Оповещения NLRI и политики маршрутизации BGP
Масштабируемость протокола BGP
Работа протокола BGP с IPv6
Полное руководство по BGP в PDF
Ох как мы любим PDF 🙃 Для вашего удобства, весь цикл статей по BGP (Border Gateway Protocol) мы "упаковали" в документ формата PDF.
Книга по BGP в PDF | 2.07 MB
Видео: Основы BGP за 7 минут
Обзор BGP
Давайте посмотрим правде в глаза - Border Gateway Protocol невероятно уникален, особенно когда мы сравниваем его с другими протоколами маршрутизации. Самое первое, что делает BGP таким уникальным, - это то, что он наш единственный внешний шлюзовой протокол (EGP), широко используемый сегодня. Мы знаем, что у нас есть Interior Gateway Protocols (IGPs), и похожий на OSPF, работающий внутри автономной системы. Но BGP - это EGP, а это означает, что он (как правило) будет принимать префиксы, которые находятся внутри автономной системы, и отправлять их в другие автономные системы.
На рисунке 1 показан пример топологии BGP.
Именно поэтому протокол BGP является протоколом, который обеспечивает функционирование сети. Интернет-провайдеры (ISP) могут использовать BGP для перемещения префиксной информации между другими Интернет-провайдерами. Однако уникальные характеристики BGP на этом не заканчиваются. Одна из вещей, которая очень уникальна в протоколе, заключается в том, что он формирует пиринги (*равноправный информационный обмен) точка-точка с другими спикерами BGP, и вы должны создавать эти пиринги вручную.
С протоколом пограничного шлюза (BGP) нет такой вещи, как автоматическое формирование соседства с целой кучей устройств на одном сегменте. Для каждого из устройств, с которыми BGP должен пиринговать, он делает это с помощью одного однорангового отношения, которое мы предпочитаем называть пирингом BGP.
Еще одно очень уникальное свойство заключается в том, что BGP - это протокол прикладного уровня. По общему признанию, большинство сетевых инженеров поспорили бы, что это протокол сетевого уровня – и они проиграли бы этот спор!
Как компонент прикладного уровня, BGP делает что-то блестящее. Он использует протокол управления передачей (TCP) для своих операций. Если мы рассмотрим EIGRP в качестве примера, то создателям пришлось приложить большие усилия, чтобы встроить надежность в сам протокол. Например, спикер EIGRP будет передавать многоадресные передачи, и, если это не сработает, он вернется к одноадресным передачам, чтобы попытаться обеспечить надежность.
С помощью Border Gateway Protocol разработчики решили не включать в протокол все эти типы контроля надежности. Они просто полагаются на чудесную надежность коммуникаций TCP. В частности, BGP использует TCP- порт 179.
Когда мы думаем о наших протоколах маршрутизации, мы знаем, что будет некоторое значение, которое будет служить метрическим значением для измерения расстояния. Например, в случае OSPF мы знаем, что метрикой является стоимость, а стоимость напрямую зависит от пропускной способности.
BGP не работает таким образом. Протокол BGP использует атрибуты, а не только одного показателя. Одним из главных атрибутов протокола BGP называется атрибута AS_PATH. Это список всех автономных систем (AS), которые префикс должен был передать на своем пути, скажем, в вашу автономную систему.
AS_PATH - это фактически запись всей информации о пути AS. Путь AS настолько важен для функции BGP, что протокол часто называют протоколом маршрутизации вектора пути. Обратите внимание, что это не протокол вектора расстояния (Distance Vector), а вектор пути (Path Vector). AS_PATH используется не только для определения наилучшего пути к месту назначения (т.е. более короткого пути AS), но и в качестве механизма предотвращения петель.
Когда автономная система видит свой собственный номер AS в AS_PATH, она очень обеспокоена тем, что в коммуникациях может быть петля. Что- то еще, что делает BGP невероятно уникальным, - это тот факт, что, когда мы формируем пиринги внутри автономной системы, они называются внутренними пирингами BGP, а правила, которым следуют, являются внутренними правилами BGP (IBGP).
Когда мы формируем пиринг между автономными системами, это называется протоколом внешнего пограничного шлюза (EBGP). (Примечание: в некоторых литературных источниках EBGP пишется как eBGP.) Помните, что причина, по которой BGP различает пиринг IBGP и пиринг EBGP, заключается в том, что эксплуатационные характеристики должны изменяться в зависимости от того, как выполняется пиринг. Например, мы заявили, что существует путь AS, который записывает автономные системы, которые передаются. Очевидно, что при пиринге EBGP, когда префикс передается от одного AS к другому AS, отправляющий AS должен поместить свою автономную систему в путь. Но с IBGP, префикс остается в AS, поэтому протокол BGP не обновляет значение AS. Вы можете вернуться к рисунку 1, чтобы увидеть эти различные типы пиринга в действии.
Таким образом, правила меняются, когда мы говорим о IBGP против EBGP, чтобы быть последовательным и безошибочными. И уникальные свойства BGP просто не заканчиваются на этом.
Типы сообщений BGP, форматы и соседние типы сообщений состояния соседства BGP
Многие люди описывают протокол пограничного шлюза (BGP) как чрезвычайно сложный протокол, но я не согласна с этим. Видите ли, установка политик BGP и контроль распространения префиксов внутри BGP-это может быть довольно сложно. Но сам протокол, хотя и уникален, в основном прост в своей работе.
В этом части статьи мы рассмотрим типы сообщений BGP. На рисунке 2 показаны различные типы сообщений BGP.
Запомните первый шаг. Когда два спикера BGP хотят сформировать пиринг, они будут полагаться на протокол управления передачей (TCP). И, конечно, мы знаем, что будет three-way handshake (трехстороннее рукопожатие) с TCP, чтобы начать этот надежный сеанс связи.
Что же происходит дальше? Так это то, что эти устройства будут обмениваться открытыми сообщениями. Открытое сообщение содержит очень важную информацию, основным компонентом которой является номер автономной системы однорангового узла. Это будет определять, является ли это пиринг IBGP или пиринг EBGP.
Когда происходит обмен открытыми сообщениями, то спикеры BGP далее начинают обмениваться сообщениями Keepalive. Это, простой механизм, чтобы убедиться, что другой прибор жив, счастлив и здоров, и что пиринг в состоянии up. После этого спикеры BGP получают обновления для совместного использования, называемое сообщением Update.
Если в какой-то момент времени что-то пойдет не так, спикеры BGP могут использовать простое сообщение Notification. Данное сообщение прерывает пиринг в результате ошибки, которая может произойти с BGP.
Одним из очень интересных типов сообщений BGP является тип сообщения Route Refresh (обновления маршрута). Хотя этот тип сообщений не был включен в исходный стандарт BGP, большинство наших основных сетевых вендоров поддерживают Route Refresh. Route Refresh позволяют соседям обновлять, скажем, информацию о маршруте BGP или даже обновлять вещи после довольно серьезной реконфигурации политики, не разрушая пиринг и не влияя на пиринг каким- либо большим негативным образом.
Рисунок 3 показывает эти типы сообщений в действии благодаря захвату Wireshark’ом обмена сообщениями BGP в нашем примере топологии из рисунка 1.
Форматы сообщений BGP
В этом части статьи мы еще больше узнаем об эксплуатационных характеристиках Border Gateway Protocol, более подробно рассмотрев типы сообщений BGP.
Каждый тип сообщения имеет заголовок BGP. Этот заголовок показан на рисунке 4. Вы видите, что заголовок BGP имеет большое поле маркера. Можно подумать, что это чрезвычайно важно. Он имеет размер 16 октетов. Как оказалось, это поле будет заполнено у всех.
Это связано с тем, что использование этого поля маркера было прописано в устаревшем стандарте. Первоначальная идея этого поля состояла в том, что его можно было бы использовать для обнаружения таких событий, как потеря синхронизации между двумя одноранговыми узлами, и также считалось, что это будет область, в которой может храниться аутентификационная информация.
Почему это поле вообще имеется в BGP? Иногда, в очень редком случае, когда необходимо иметь обратную поддержку с каким-то действительно старым устройством BGP, которое ожидает эту информацию из поля маркера.
Важными полями в заголовке, будут длина (Length) (то есть длина всего сообщения) и поля типа (Type). Поле Тип указывает, с каким типом сообщения BGP мы имеем дело.
Если, например, в этом поле 1, вы имеете дело с открытым (Open) сообщением BGP. Значение 2 указывает на сообщение об обновлении (Update). А 3 означает уведомление (Notification). Значение 4 будет иметь сообщение Keepalive. 5 указывает на необязательное Route Refresh.
То, что следует за информацией заголовка, конечно же, является данными, за одним важным исключением- это сообщение Keepalive. По определению, в сообщении Keepalive нет никаких данных.
Теперь я надеюсь вы понимаете, что, когда ваша система хочет сформировать BGP-пиринг с другим устройством, она собирается отправить открытое сообщение. На рисунке 5 показан формат этих сообщений.
Когда мы смотрим на формат открытого (Open) сообщения, мы замечаем, что там есть номер версии. Именно так BGP указывает на версию BGP, которую вы используете.
Ваша система также отправит свой номер AS в открытом сообщении. Это очень важно для такого поведения IBGP по сравнению с EBGP. Существует значение Hold Time. Что же такое Hold Time? Когда маршрутизатор, с которым вы хотите свериться, получает Open сообщение, он смотрит время удержания (Hold Time), смотрит на свое собственное настроенное Hold Time, а затем использует меньшее из двух значений. Hold Time должно быть либо нулевым, либо не менее трех секунд.
Есть поле BGP Identifier. Это Ваш BGP Router ID, и это уникальное значение, которое будет однозначно отличать вашу систему в пирингах BGP.
Наконец, у нас есть дополнительные параметры (Optional Parameter), которые можно задать с помощью открытого сообщения. Там есть необязательная длина параметра (Optional Parameter Length), а затем сами параметры, дающие дополнительную гибкость работы с протоколом.
Еще одно действительно важное сообщение, которое у нас есть, - это сообщение об обновлении (Update) BGP. На рисунке 6 показана эта структура сообщения.
Сообщение об обновлении BGP содержит индикатор длины отозванных маршрутов (Withdrawn Routes Length). Это гарантирует, что сообщение обновления является средством для маршрутов, которые будут удалены из таблицы BGP соседа. Примечание: затем в сообщение об обновлении вставляется список изъятых маршрутов.
Сообщение об обновлении содержит поля, которые используются для обмена информацией о префиксах сети с соседями и включают в себя очень важную атрибутивную информацию, связанную с префиксами. Помните, что эти атрибуты позволяют Вам принимать важные решения о том, как BGP будет фактически маршрутизировать информацию в сети.
Хорошо известный атрибут, о котором мы уже упоминали, - это путь. Вы помните, что это список автономных систем, которые префикс передал на своем пути по всей инфраструктуре BGP. AS Path будет примером атрибута, который должен быть в сообщении об обновлении, когда он используется для отправки префиксов. Там может быть много атрибутов, которые мы используем, и это является причиной для Total Path Attribute Length в сообщении об обновлении.
Сама информация о префиксе сети находится в поле NLRI. Это означает информацию о достижимости сетевого уровня (Network Layer Reachability Information). Вы можете вернуться к рисунку 3 и увидеть эти поля в реальном пакете, а также их содержимое.
Создатели BGP сделали гениальную вещь. Они создали протокол для передачи NLRI таким образом, чтобы он был гибким по мере изменения сетей и необходимости передачи новой информации. BGP создан для того, чтобы сразу же запускать для нас такие вещи, как IPv6. Он также может легко переносить префиксы VPN IPv4 внутри чего-то вроде MPLS VPN.
На рисунке 7 показаны поля сообщения уведомления (Notification).
Самое первое поле - это код ошибки (Error Code). Затем поле Подкод ошибки (Error Subcode). Эти поля дают нам общий тип ошибки, а затем еще больше информации. Например, если в Error Code у нас есть значение 3, а затем в Error Subcode у нас есть значение 3, это указывает на то, что существует сообщение об ошибке обновления.
Соседство BGP
Точно так же, как мы можем многое узнать о работе BGP, изучая сообщения BGP и их форматы, мы также можем многое узнать о BGP, изучая различные состояния, через которые проходит пиринг BGP. На самом деле, они имеют решающее значение при устранении неполадок. Когда вы проанализируете протокол BGP, вы не удивитесь, узнав, что существует множество встроенных механизмов для обеспечения стабильности.
Многие IGP спроектированы так, чтобы быть максимально быстро сходящимися. Это происходит потому, что в момент, когда происходит изменение внутри сети вашей организации, мы хотим sub-second сходимости других устройств, чтобы мы знали об этом изменении. BGP спроектирован по-другому. Таймеры имеют гораздо большую продолжительность, чем мы привыкли бы с нашим IGP, потому что мы хотим стабильности, жертвуя скоростью сходимости. В конце концов, BGP имеет дело с общедоступными таблицами маршрутизации интернета в развертываниях поставщиков услуг. Эти таблицы маршрутизации очень массивны. Нестабильность в этой среде приведет к катастрофе всего публичного Интернета.
Когда вы изучите состояние соседства BGP, вы поймете для чего это. Относительно большое число состояний соседства BGP, показанных на рисунке 8, свидетельствует о тщательных усилиях по обеспечению стабильности протокола маршрутизации.
Обратите внимание, что есть состояние простоя, когда устройство не инициирует ни одно из других состояний, и есть установленное состояние, когда оно полностью установлено со своим узлом. Что несколько удивительно, так это то, что есть все эти “промежуточные” состояния подключения, активного, открытого подтверждения (OpenConfirm) и активного.
Состояние — подключения-это состояние, в котором устройство BGP ожидает завершения TCP- соединения с соседним устройством.
В активном состоянии он пытается инициировать TCP - соединение со своим соседом. В состоянии OpenSent, как вы можете догадаться, он отправляет свое открытое сообщение и ждет ответа от своего соседа с его открытым сообщением. В режиме OpenConfirm, спикер BGP на самом деле ждет, Keepalive на основе успешного обмена открытыми сообщениями. Будем надеяться, что устройство BGP получит Keepalive. Если будет ошибка, он получит уведомление.
Используя в Cisco CLI специальные команды, можно узнать все о состоянии BGP. Пример 1 показывает использование команды show ip bgp summary для проверки соседнего состояния.
TPA1#show ip bgp summary
BGP router identifier 10.10.10.1, local AS number 100
BGP table version is 3, main routing table version 3
Neighbor V AS MsgRcvd MsgSent TblVer InQ QutQ Up/down State/PfxRcd
10.10.10.2 4 200 0 0 1 0 0 00:00:00 Idle
Обратите внимание на пример 1. Этот пиринг BGP находится в состоянии ожидания (параметр State/PfxRcd в состоянии Idle). Как только произойдет соединение значение IDLE заменится на 1 (Если ATL использует только один префикс с TPA 1).
В этой серии лекций продолжается рассмотрение распределенных плоскостей управления, добавляя к изучению еще три протокола маршрутизации. Два из них являются протоколами состояния канала, а третий – единственный, широко распространенный протокол вектора пути, Border Gateway Protocol (BGP) v4.
В этих лекция мы уделим внимание тому, почему каждый из этих протоколов реализован именно так. Очень легко увлечься и запутаться в изучении мельчайших деталей работы протоколов, но нам гораздо важнее помнить о проблемах, для решения которых эти протоколы были разработаны, и о диапазоне возможных решений. Каждый изучаемый вами протокол будет представлять собой комбинацию умеренно ограниченного набора доступных решений: существует очень мало доступных новых решений. Существуют различные комбинации решений, реализованных иногда уникальными способами для решения конкретных наборов проблем.
Изучая эти принципы работы протокола, вы должны попытаться выбрать общие решения, которые они реализуют. Затем отразить эти решения обратно в набор проблем, которые должна решить любая распределенная плоскость управления, чтобы устранить проблемы в реальных сетях.
Краткая история OSPF и IS-IS
Протокол Intermediate System to Intermediate System (IS-IS или IS to IS) был разработан в 1978 году.
Open Shortest Path First (OSPF) изначально задумывался как альтернатива IS-IS, предназначенная специально для взаимодействия с сетями IPv4. В 1989 году первая спецификация OSPF была опубликована Internet Engineering Task Force, а OSPFv2, значительно улучшенная спецификация, была опубликована в 1998 году как RFC2328. OSPF, безусловно, был более широко используемым протоколом, причем ранние реализации IS-IS практически не применялись в реальном мире. Были некоторые аргументы за и против, и многие функции были «позаимствованы» из одного протокола в другой (в обоих направлениях).
В 1993 году компания Novell, в то время крупный игрок в мире сетевых технологий, использовала протокол IS-IS как основу для замены собственного протокола маршрутизации Netware. Протокол транспортного уровеня Novell, Internet Packet Exchange (IPX), в то время работал на большом количестве устройств, и возможность использования одного протокола для маршрутизации нескольких транспортных протоколов была решающим преимуществом на сетевом рынке (EIGRP, также может маршрутизировать IPX). Этот протокол замены был основан на IS-IS. Чтобы реализовать новый протокол Novell, многие производители просто переписали свои реализации IS-IS, значительно улучшив их в процессе. Это переписывание сделало IS-IS привлекательным для крупных провайдеров Интернет-услуг, поэтому, когда они отказались от протокола RIP, они часто переходили на IS-IS вместо OSPF.
Intermediate System to Intermediate System Protocol
В протоколе Intermediate System to Intermediate System (IS-IS) маршрутизатор называется Intermediate System (Промежуточной системой (IS), а хост- End System (Конечной системой (ES). Оригинальный дизайн набора состоял в том, чтобы каждое устройство, а не интерфейс, имело один адрес. Службы и интерфейсы на устройстве будут иметь точку доступа к сетевым службам (Network Service Access Point - NSAP), используемую для направления трафика к определенной службе или интерфейсу. Таким образом, с точки зрения IP, IS-IS изначально был разработан в рамках парадигмы маршрутизации хоста. Промежуточные и конечные системы связываются непосредственно с помощью протокола End System to Intermediate System (ES-IS), позволяющего IS-IS обнаруживать службы, доступные в любой подключенной конечной системе, а также сопоставлять адреса нижних интерфейсов с адресами устройств более высокого уровня.
Еще один интересный аспект дизайна IS-IS - он работает на канальном уровне. Разработчикам протокола не имело большого смысла запускать плоскость управления для обеспечения доступности транспортной системы через саму транспортную систему. Маршрутизаторы не будут пересылать пакеты IS-IS, поскольку они параллельны IP в стеке протоколов и передаются по локальным адресам связи. Когда была разработана IS-IS, скорость большинства каналов была очень низкой, поэтому дополнительная инкапсуляция также считалась расточительной. Каналы связи также довольно часто выходили из строя, теряя и искажая пакеты. Следовательно, протокол был разработан, чтобы противостоять ошибкам при передаче и потере пакетов.
Адресация OSI
Поскольку IS-IS был разработан для другого набора транспортных протоколов, он не использует адреса Internet Protocol (IP) для идентификации устройств. Вместо этого он использует адрес взаимодействия открытых систем (Open Systems Interconnect - OSI) для идентификации как промежуточных, так и конечных систем. Схема адресации OSI несколько сложна, включая идентификаторы для органа, распределяющего адресное пространство, идентификатор домена, состоящий из двух частей, идентификатор области, системный идентификатор и селектор услуг (N-селектор). Многие из этих частей адреса OSI имеют переменную длину, что еще больше затрудняет понимание системы. Однако в мире IP используются только три части этого адресного пространства.
Authority Format Identifier (AFI), Initial Domain Identifier (IDI), High-Order Domain Specific Part (HO-DSP) и область, где все обрабатывается как одно поле.
Системный идентификатор по-прежнему рассматривается как системный идентификатор.
N Selector, или NSAP, обычно игнорируется (хотя есть идентификатор интерфейса, который похож на NSAP, используемый в некоторых конкретных ситуациях).
Таким образом, промежуточные системные адреса обычно принимают форму, показанную на рисунке 1.
На рисунке 1:
Точка разделения между системным идентификатором и остальной частью адреса находится в шестом октете или если отсчитать двенадцать шестнадцатеричных цифр с правой стороны. Все, что находится слева от шестого октета, считается частью адреса области.
Если N-селектор включен, это один октет или две шестнадцатеричные цифры справа от идентификатора системы. Например, если для адреса A был включен N-селектор, это могло бы быть 49.0011.2222.0000.0000.000A.00.
Если в адрес включен N-селектор, вам нужно пропустить N-селектор при подсчете более шести октетов, чтобы найти начало адреса области.
A и B находятся в одном домене flooding рассылки, потому что у них одни и те же цифры от седьмого октета до крайнего левого октета в адресе.
C и D находятся в одном flooding domain.
A и D представляют разные системы, хотя их системный идентификатор одинаков. Однако такая адресация может сбивать с толку и поэтому не используется в реальных развертываниях IS-IS (по крайней мере, вдумчивыми системными администраторами).
Вы посчитать эту схему адресации более сложной, чем IP, даже если вы регулярно работаете с IS-IS в качестве протокола маршрутизации. Однако есть большое преимущество в использовании схемы адресации, отличной от той, которая используется на транспортном уровне в сети. Гораздо проще различать типы устройств в сети и гораздо проще отделить узлы от адресатов, если продумать алгоритм Дейкстры по кратчайшему пути (SPF).
Маршаллинг данных в IS-IS
IS-IS использует довольно интересный механизм для маршалинга данных для передачи между промежуточными системами. Каждая IS генерирует три вида пакетов:
Hello-пакеты
Пакеты с порядковыми номерами (PSNP и CSNP)
Одиночный пакет состояния канала (Link State Packet - LSP)
Единый LSP содержит всю информацию о самой IS, любых доступных промежуточных системах и любых доступных адресатах, подключенных к IS. Этот единственный LSP форматируется в Type Length Vectors (TLV), которые содержат различные биты информации. Некоторые из наиболее распространенных TLV включают следующее:
Типы 2 и 22: достижимость к другой промежуточной системе
Типы 128, 135 и 235: достижимость до пункта назначения IPv4
Типы 236 и 237: достижимость к адресату IPv6
Существует несколько типов, потому что, IS-IS изначально поддерживал 6-битные метрики (большинство процессоров на момент появления протокола могли хранить только 8 бит за раз, и два бита были «украдены» из размера поля, чтобы нести информацию о том, был ли маршрут внутренним или внешним, а также другую информацию). Со временем, по мере увеличения скорости связи, были введены различные другие метрические длины, включая 24 - и 32-битные метрики, для поддержки широких метрик.
Одиночный LSP, несущий всю информацию о доступности IS, IPv4 и IPv6, а также, возможно, теги MPLS и другую информацию, не поместится в один пакет MTU. Для фактической отправки информации по сети IS-IS разбивает LSP на фрагменты. Каждый фрагмент рассматривается как отдельный объект в процессе лавинной рассылки. Если изменяется один фрагмент, лавинной рассылкой по сети распространяется только измененный фрагмент, а не весь LSP. Благодаря этой схеме IS-IS очень эффективен при лавинной рассылке информации о новой топологии и достижимости без использования полосы пропускания, превышающей минимальную требуемую.
Обнаружение соседей и топологии
Хотя IS-IS изначально был разработан, чтобы узнать о доступности сети через протокол ES-IS, когда IS-IS используется для маршрутизации IP, он «действует так же, как протоколы IP», и узнает о достижимых местах назначения через локальную конфигурацию каждого из них. устройства и путем перераспределения из других протоколов маршрутизации. Следовательно, IS-IS - это проактивный протокол, который изучает и объявляет достижимость без ожидания пакетов, которые будут переданы и переадресованы через сеть.
Формирование соседей в IS-IS довольно просто. Рисунок 2 иллюстрирует этот процесс.
На рисунке 2:
IS A передает приветствие в сторону B. Это приветствие содержит список соседей, от которых получен сигнал, который будет пустым. Настройку времени удержания (hold time) B следует использовать для A, и добавляется к максимальному блоку передачи (MTU) локального интерфейса для канала связи. Пакеты приветствия дополняются только до завершения процесса формирования смежности. Не каждый пакет приветствия дополняется MTU канала.
IS B передает приветствие к A. Это приветствие содержит список соседей, от которых получен ответ, который будет включать A. Настройку времени удержания A следует использовать для B. Добавляется к MTU локального интерфейса.
Поскольку A находится в списке «слышимых соседей» B, A рассмотрит B и перейдет к следующему этапу формирования соседей.
Как только A включил B в список «услышанных соседей» хотя бы в одно приветствие, B рассмотрит A и перейдет к следующему этапу формирования соседа.
B отправит полный список всех записей, которые он имеет в своей таблице локальной топологии (B описывает LSP, которые он имеет в своей локальной базе данных). Этот список отправляется в Complete Sequence Number Packet (CSNP).
A проверит свою локальную таблицу топологии, сравнив ее с полным списком, отправленным B. Любые записи в таблице топологии (LSP), которых он не имеет, он будет запрашивать у B с использованием Partial Sequence Number Packet (PSNP).
Когда B получает PSNP, он устанавливает флаг Send Route Message (SRM) для любой записи в его локальной таблице топологии (LSP), запрошенной A.
Позже процесс лавинной рассылки будет проходить по таблице локальной топологии в поисках записей с установленным флагом SRM. Он заполнит эти записи, синхронизируя базы данных в A и B.
Примечание. Описанный здесь процесс включает изменения, внесенные в RFC5303, который определяет трехстороннее рукопожатие, и дополнение приветствия, которое было добавлено в большинство реализаций примерно в 2005 году.
Установка флага SRM отмечает информацию для лавинной рассылки, но как на самом деле происходит лавинная рассылка?
Надежная лавинная рассылка.
Для правильной работы алгоритма SPF Дейкстры (или любого другого алгоритма SPF) каждая IS в flooding domain должна совместно использовать синхронизированную базу данных. Любая несогласованность в базе данных между двумя промежуточными системами открывает возможность зацикливания маршрутизации. Как IS-IS гарантирует, что подключенные промежуточные системы имеют синхронизированные базы данных? В этой лекции описывается процесс создания point-to-point каналов. Далее будут описаны модификации, внесенные в процесс flooding domain по каналам с множественным доступом (например, Ethernet).
IS-IS полагается на ряд полей в заголовке LSP, чтобы гарантировать, что две промежуточные системы имеют синхронизированные базы данных. Рисунок 3 иллюстрирует эти поля.
На рисунке 3:
Длина пакета (packet length) содержит общую длину пакета в октетах. Например, если это поле содержит значение 15 , длина пакета составляет 15 октетов. Поле длины пакета составляет 2 октета, поэтому оно может описывать пакет длиной до 65 536 октетов - больше, чем даже самые большие MTU канала.
Поле оставшегося времени жизни (remaining lifetime) также составляет два октета и содержит количество секунд, в течение которых этот LSP действителен. Это вынуждает периодически обновлять информацию, передаваемую в LSP, что является важным соображением для старых технологий передачи, где биты могут быть инвертированы, пакеты могут быть усечены или информация, передаваемая по каналу связи, может быть повреждена. Преимущество таймера, который ведет обратный отсчет, а не на увеличение, состоит в том, что каждая IS в сети может определять, как долго ее информация должна оставаться действительной независимо от каждой другой IS. Недостаток в том, что нет четкого способа отключить описанный функционал. Однако 65 536 секунд - это большое время - 1092 минуты, или около 18 часов. Повторная загрузка каждого фрагмента LSP в сети примерно каждые 18 часов создает очень небольшую нагрузку на работу сети.
LSP ID описывает сам LSP. Фактически, это поле описывает фрагмент, поскольку оно содержит идентификатор исходной системы, идентификатор псевдоузла (функцию этого идентификатора рассмотрим позже) и номер LSP, или, скорее, номер фрагмента LSP. Информация, содержащаяся в одном фрагменте LSP, рассматривается как «один блок» во всей сети. Отдельный фрагмент LSP никогда не «рефрагментируется» какой-либо другой IS. Это поле обычно составляет 8 октетов.
Порядковый номер (Sequence Number) описывает версию этого LSP. Порядковый номер гарантирует, что каждая IS в сети имеет одинаковую информацию в своей локальной копии таблицы топологии. Это также гарантирует, что злоумышленник (или «кривая» реализация) не сможет воспроизвести старую информацию для замены новой.
Контрольная сумма (Checksum) гарантирует, что информация, передаваемая во фрагменте LSP, не была изменена во время передачи.
Лавинная рассылка описана на рисунке 4.
На рисунке 4:
А подключен к 2001: db8: 3e8: 100 :: / 64. A создает новый фрагмент, описывающий этот новый достижимый пункт назначения.
A устанавливает флаг SRM на этом фрагменте в сторону B.
Процесс лавинной рассылки в какой-то момент (обычно это вопрос миллисекунд) проверит таблицу топологии и перезальет все записи с установленным флагом SRM.
Как только новая запись будет помещена в свою таблицу топологии, B создаст CSNP, описывающий всю свою базу данных, и отправит его в A.
Получив этот CSNP, A удаляет свой флаг SRM в направлении B.
B проверяет контрольную сумму и сравнивает полученный фрагмент с существующими записями в своей таблице топологии. Поскольку нет другой записи, соответствующей этой системе и идентификатору фрагмента, он поместит новый фрагмент в свою таблицу локальной топологии. Учитывая, что это новый фрагмент, B инициирует процесс лавинной рассылки по направлению к C.
А как насчет удаления информации? Есть три способа удалить информацию из системы IS-IS flooding:
Исходящая IS может создать новый фрагмент без соответствующей информации и с более высоким порядковым номером.
Если весь фрагмент больше не содержит какой-либо действительной информации, исходящая IS может заполнить фрагмент с оставшимся временем жизни (lifetime) равным 0 секунд. Это приводит к тому, что каждая IS в домене лавинной рассылки повторно загружает фрагмент zero age и удаляет его из рассмотрения для будущих вычислений SPF.
Если таймер lifetime во фрагменте истекает в любой IS, фрагмент заполняется лавинной рассылкой с zero age оставшегося времени жизни. Каждая IS, получающая этот фрагмент с zero age, проверяет, что это самая последняя копия фрагмента (на основе порядкового номера), устанавливает оставшееся время жизни для своей локальной копии фрагмента на ноль секунд и повторно загружает фрагмент. Это называется удалением фрагмента из сети.
Когда IS отправляет CNSP в ответ на полученный фрагмент, она фактически проверяет всю базу данных, а не только один полученный фрагмент. Каждый раз, когда фрагмент лавинно рассылается по сети, вся база данных проверяется между каждой парой промежуточных систем.
Подведение итогов об IS-IS
IS-IS можно описать как:
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в flooding domain (протокол состояния канала).
Расчет loop-free -путей с использованием алгоритма SPF Дейкстры.
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол).
Проверка двусторонней связи при формировании соседей путем переноса списка «замеченных соседей» в своих пакетах приветствия.
Удаление информации из домена лавинной рассылки с помощью комбинации порядковых номеров и полей оставшегося времени жизни (lifetime) в каждом фрагменте.
Проверка MTU каждой линии связи путем заполнения первоначально обмененных пакетов приветствия.
Проверка правильности информации в синхронизированной базе данных с помощью контрольных сумм, периодического перезапуска и описаний базы данных, которыми обмениваются промежуточные системы.
IS-IS - это широко распространенный протокол маршрутизации, который доказал свою работоспособность в широком диапазоне сетевых топологий и эксплуатационных требований.
В данной статье будет описан модуль для FreePBX – Asterisk Phonebook.
Настройка телефонной книги
Находится он по следующему пути: Admin – Asterisk Phonebook
Для внесения записи в телефонную книгу необходимо нажать на кнопку «Add Phonebook Entry».
Возникнет окно создания записи
Рассмотрим поля:
Name – имя контакта, можно ввести кириллицей
Number - номер контакта, должен совпадать с Caller ID полученным из сети
Speed Dial Code – номер быстрого набора, короткий номер, который заменит номер выше
Set Speed Dial – если установить «Yes», номер быстрого набора будет установлен автоматически. Если номер был указан в поле выше, данная опция не будет иметь никакого эффекта.
Далее необходимо нажать на Submit и появится следующее поле
Важно:
Для редактирования нужно нажать на иконку «Карандаш»
Для удаления нужно нажать на иконку «Корзина»
Импорт/Экспорт контактов
Важнейшей опцией является возможность экспорта в формат CSV и импорта из этого формата. Если необходимо сделать импорт из CSV файла, самым простым вариантом будет создать 1-2 контакта, сделать экспорт и в полученную таблицу добавить данные из вашего файла с общим списком контактов (то есть экспорт необходим для понимания требуемого формата).
Для загрузки требуется нажать Import from CSV, нажать Browse, выбрать корректный CSV файл, нажать Upload и, как заключительный шаг, нажать Apply Config вверху страницы.