По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье вы познакомитесь с основами 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).
В 2013 году была опубликована версия OSPF для маршрутизации IPv6. Известный как OSPFv3, он был первоначально указан в RFC 2740, который позже был заменен на RFC 5340 и обновлен более поздними стандартами.
Маршаллинг данных в OSPF
Как и многие другие протоколы, разработанные на заре проектирования сетей, OSPF был разработан для минимизации вычислительной мощности, памяти и полосы пропускания, необходимых для передачи информации о маршрутизации IPv4 по сети. Два конкретных выбора, сделанных на ранних этапах процесса проектирования OSPF, отражают эту озабоченность по поводу использования ресурсов:
OSPF использует поля фиксированной длины для упорядочивания данных, а не TLV. Это экономит накладные расходы на перенос дополнительных метаданных в виде заголовков Type Length Value (TLV), снижает требования к обработке, позволяя сопоставлять структуры данных фиксированного размера в памяти с пакетами по мере их приема с канала связи, и уменьшает размер данных OSPF на линии.
OSPF разбивает базу данных топологии на несколько типов данных, а не полагается на один LSP с TLV. Это означает, что каждый вид информации - доступность, топология и т. д. - передается в уникальном формате пакета.
Каждый тип информации, которую OSPF может нести, переносится в разном типе Link State Advertisement (LSA). Вот некоторые из наиболее примечательных типов LSA:
Тип 1: код 0x2001, Router LSA
Тип 2: код 0x2002, Network LSA
Тип 3: код 0x2003, Inter-Area Prefix LSA
Тип 4: код 0x2004, Inter-Area Router LSA
Тип 5: код 0x4005, AS-external LSA
Тип 7: код 0x2007, Type-7 (NSSA) LSA
Существует ряд других типов LSA, включая непрозрачные данные, членство в группе многоадресной рассылки и LSA с лавинной рассылкой (например, для одного соседа, одного канала или одного домена лавинной рассылки).
Каждый маршрутизатор OSPF генерирует ровно один Router LSA (тип 1). Этот LSA описывает любых соседей, примыкающих к объявляемому маршрутизатору, а также любые подключенные достижимые пункты назначения. Состояние каналов связи на этих соседей и пунктов назначения определяется из объявления соседей и пункта назначения. Несмотря на фразу «состояние канала», каналы не объявляются как отдельная «вещь» (это часто вызывает путаницу). Если Router LSA становится слишком большим, чтобы поместиться в один IP-пакет (из-за MTU канала), он будет разделен на несколько IP-фрагментов для передачи от маршрутизатора к маршрутизатору. Каждый маршрутизатор повторно собирает весь Router LSA перед его локальной обработкой и лавинно рассылает весь Router LSA, если он изменяется.
OSPF также использует несколько разных типов пакетов - они не совпадают с типами LSA. Скорее, их можно рассматривать как разные «службы» в OSPF или, возможно, как разные «номера портов», выполняемые поверх протокола User Datagram Protocol (UDP) или протокола Transmission Control Protocol (TCP).
Hello - это тип 1. Они используются для обнаружения и сохранения соседей.
Database Descriptor (DBD) относится к типу 2. Они используются для описания таблицы локальной топологии.
Link State Request (LSR) относится к типу 3. Они используются для запроса определенных объявлений состояния канала от соседнего маршрутизатора.
Link State Update (LSU) относится к типу 4. Они используются для передачи объявлений состояния канала.
Link State Acknowledgment - это тип 5. Это просто список заголовков LSA. Любой LSA, указанный в этом пакете, подтверждается как полученный передающим маршрутизатором.
Обнаружение соседей и топологии
В качестве протокола состояния канала OSPF должен гарантировать, что каждый маршрутизатор в пределах области (flooding domain) имеет одну и ту же базу данных для расчета loop-free путей. Любое изменение в базе данных общей топологии может привести к возникновению зацикливания маршрутизации, который будет длиться до тех пор, пока существует изменение в базе данных общей топологии. Таким образом, одной из целей формирования соседей OSPF является обеспечение надежной flooding рассылки информации о топологии через сеть. Вторая причина формирования соседей OSPF - обнаружение топологии сети путем определения того, какие маршрутизаторы находятся рядом с локальным маршрутизатором. На рисунке 1 показан процесс формирования соседей OSPF.
На рисунке 1:
B отправляет пакет приветствия к A.
Поскольку приветствие B содержит пустой список видимых соседей, A переводит B в состояние инициализации и добавляет B в список видимых соседей.
A передает приветствие B в списке видимых соседей.
B получает приветствие от A и отправляет приветствие с A в списке видимых соседей.
A получает это приветствие. Поскольку сам A находится в списке соседей, A помещает B в двустороннее состояние. Это означает, что A проверил наличие двусторонней связи между собой и B.
Если по этой линии избираются DR и BDR, то выборы происходят после шага 5. Как только выборы завершены, DR и BDR переводятся в состояние exstart. Во время этого состояния ведущий и ведомый выбираются для обмена DBDS и LSA. По сути, мастер управляет потоком DBDS и LSA между новыми соседними маршрутизаторами. Соседние маршрутизаторы на канале point-to-point технически переходят непосредственно в состояние full state в этой точке.
B переведен в состояние обмена.
A отправляет B набор DBD с описанием своей базы данных. B отправляет набор DBD с описанием своей базы данных в A.
A отправляет запрос состояния канала B для каждого LSA, описанного B, и A не имеет его копии в своей локальной таблице топологии.
B отправляет LSA для каждого запроса Link State (LS) от A.
11. Как только базы данных синхронизируются, B переводится в full state.
Процесс формирования соседей OSPF проверяет MTU на обоих концах линии связи, передавая MTU исходящего интерфейса в hello сообщении. Если два hello-пакета не совпадают по размеру MTU, два маршрутизатора OSPF не образуют смежности.
Надежная лавинная рассылка.
OSPF должен не только гарантировать завершение первоначального обмена информацией о топологии, но также гарантировать, что текущие изменения в топологии сети будут переданы на каждый маршрутизатор во flooding domain. На рисунке 2 показан заголовок LSA OSPF. Изучение этого заголовка поможет нам понять, как OSPF надежно массово рассылает информацию о топологии и доступности через сеть.
На рисунке 2:
LS Age - это (примерно) количество секунд с момента создания Link State Advertisement. Это число идет увеличивается, а не уменьшается. Когда LS Age достигает значения MAXAGE (на любом маршрутизаторе, а не только на исходном маршрутизаторе), маршрутизатор увеличивает порядковый номер на 1, устанавливает для LS Age максимальное число и повторно загружает LSA по всей сети. Это позволяет удалить старую информацию о топологии и доступности, которая не обновлялась некоторое время. Маршрутизатор, который инициирует какой-либо конкретный LSA, обновит свои LSA за некоторое количество секунд до того, как это поле LSA Age достигнет максимума- это интервал обновления LS.
Link State Identifier - это уникальный идентификатор, присвоенный исходным маршрутизатором для описания этого LSA. Обычно это адрес канала или какой-либо адрес локального уровня канала (например, Ethernet Media Access Control (MAC-адрес).
Advertising Router - это идентификатор маршрутизатора-отправителя. Его часто путают с IP-адресом, поскольку он часто является производным от локально настроенного IP-адреса, но это не IP-адрес.
Link State Sequence Number указывает версию LSA. Как правило, более высокие числа означают более новые версии, хотя существуют более ранние версии OSPF, в которых используется круговое числовое пространство, а не абсолютно увеличивающееся. Реализации, которые используют абсолютно увеличивающееся числовое пространство, перезапускают процесс OSPF, если достигнут конец числового пространства.
Link State Checksum - это контрольная сумма, вычисляемая для LSA, используемая для обнаружения ошибок при передаче или хранении информации.
Рисунок 3 используется для изучения процесса flooding рассылки.
На рисунке 3:
Линия связи на 2001: db8: 3e8: 100 :: / 64 настроена, запущена, подключена и т. д.
A перестраивает свой Router LSA (тип 1), чтобы включить эту новую информацию о доступности, упаковывает его в LSU (который может быть фрагментирован при размещении в IP-пакеты) и лавинно рассылает его B.
B получает это LSA и подтверждает его получение подтверждением состояния канала (link state acknowledgment). A повторно отправит LSA, если B не подтвердит его достаточно быстро.
Теперь B проверит свою таблицу топологии, чтобы определить, является ли этот LSA новым или копией уже имеющегося. B определяет это в первую очередь путем изучения порядкового номера, включенного в сам LSA. Если это новый (или обновленный) LSA, B инициирует тот же процесс для лавинной рассылки измененного LSA в C.
Подведение итогов об OSPF
OSPF можно описать как:
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол)
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в домене лавинной рассылки (протокол состояния канала)
Расчет путей без петель с использованием алгоритма SPF Дейкстры
Проверка двусторонней связи при формировании соседей путем переноса списка «видимых соседей» в своих пакетах приветствия.
Проверка MTU при формировании смежности путем переноса MTU в приветственном пакете
OSPF широко используется в малых и крупных сетях, включая розничную торговлю, поставщиков услуг, финансовые и многие другие предприятия.
Общие элементы OSPF и IS-IS
В предыдущих лекциях были рассмотрены аспекты, отличающие OSPF и IS-IS друг от друга. Однако есть ряд вещей, которые OSPF и IS-IS реализовали достаточно схожими способами, чтобы рассматривать их решения как простые варианты. К ним относятся обработка каналов с множественным доступом, концепция Shortest Path Tree и способ way two-way.
Каналы с множественным доступом
Каналы с множественным доступом, такие как Ethernet, - это каналы, по которым подключенные устройства «совместно используют» доступную полосу пропускания, и каждое устройство может отправлять пакеты напрямую любому другому устройству, подключенному к тому же каналу. Каналы с множественным доступом создают особые проблемы для протоколов, которые синхронизируют базу данных по каналу.
Рассмотрим рисунок 3 для понимания.
Один из вариантов, который протокол может использовать при работе по каналу с множественным доступом, - это просто сформировать смежности, как это обычно происходит по каналу «точка-точка» (point-to-point). Например, на рисунке 3:
A может образовывать смежность с B, C и D.
B может образовывать смежность с A, C и D.
C может образовывать смежность с A, B и D.
D может образовывать смежность с A, B и C
Если используется этот шаблон формирования смежности, когда A получает новый фрагмент LSP (IS-IS) или LSA (OSPF) от некоторого маршрутизатора, не подключенного к совместно используемому каналу:
A передаст новый фрагмент или LSA по отдельности B, C и D.
Когда B получает фрагмент или LSA, он передаст новый фрагмент или LSA в C и D отдельно.
Когда C получает фрагмент или LSA, он передает новый фрагмент или LSA D.
Учитывая передачу каждого фрагмента или LSA, а также следующий CSNP или подтверждение, чтобы гарантировать синхронизацию локальной базы данных на каждом маршрутизаторе, большое количество пакетов должно пересекать совместно используемый канал, чтобы гарантировать синхронизацию базы данных каждого устройства. Чтобы уменьшить переполнение каналов множественного доступа, IS-IS и OSPF выбирают одно устройство, которое отвечает за обеспечение того, чтобы каждое устройство, подключенное к каналу, имело синхронизированную базу данных. На рисунке 3 для IS-IS:
Одно устройство выбрано для управления лавинной рассылкой по каналу. В IS-IS это устройство называется выделенной промежуточной системой (Designated Intermediate System - DIS).
Каждое устройство с новой информацией о состоянии канала отправляет фрагмент на адрес многоадресной рассылки, чтобы каждое устройство в общем канале получило его. Ни одно из устройств, подключенных к каналу, не отправляет никаких подтверждений при получении обновленного фрагмента.
DIS регулярно отправляет копию своего CSNP на один и тот же адрес многоадресной рассылки, поэтому каждое устройство в канале множественного доступа получает его копию.
Если какое-либо устройство на общем канале обнаружит, что в нем отсутствует какой-то конкретный фрагмент, на основе описания базы данных DIS в CSNP, оно отправит PSNP в канал, запрашивая недостающую информацию.
Если какое-либо устройство в общем канале обнаружит, что у него есть информация, которой нет у DIS, на основе описания базы данных DIS в CSNP, оно перенаправит недостающий фрагмент в канал.
Таким образом, новая информация о состоянии канала передается по линии минимальное количество раз. На рисунке 3 для OSPF:
Для управления лавинной рассылкой по каналу выбирается одно устройство, называемое назначенным маршрутизатором (Designated Router - DR). Также выбирается резервное устройство, называемое резервным назначенным маршрутизатором (Backup Designated Router - BDR).
Каждое устройство с новой информацией о состоянии канала пересылает ее на специальный адрес многоадресной рассылки, контролируемый DR и BDR (маршрутизаторами, работающими только как DR).
DR получает этот LSA, проверяет его, чтобы определить, содержит ли он новую информацию, а затем повторно загружает его на многоадресный адрес, который прослушивают все маршрутизаторы OSPF на канале (все маршрутизаторы SPF).
Однако выбор DIS или DR не влияет только на лавинную передачу информации по каналу множественного доступа. Это также влияет на способ вычисления SPF через канал. Рисунок 4 показывает это.
На рисунке 4 A выбран в качестве DIS или DR для схемы множественного доступа. A не только гарантирует, что каждое устройство в канале имеет синхронизированную базу данных, но также создает псевдоузел или p-узел и объявляет его, как если бы это было реальное устройство, подключенное к сети. Каждый из маршрутизаторов, подключенных к совместно используемому каналу, объявляет о возможности подключения к p-узлу, а не к каждой из других подключенных систем.
В IS-IS A создает LSP для p-узла. Этот p-узел объявляет канал с нулевой стоимостью обратно каждому устройству, подключенному к каналу множественного доступа. В OSPF A создает Network LSA (тип 2).
Без этого p-узла сеть выглядит как full mesh (полная сетка) для других промежуточных систем в домене лавинной рассылки, как показано в левой части рисунка 4. С p-узлом сеть выглядит как hub-and-spoke с p-узлом в качестве концентратора. Каждое устройство объявляет канал на p-узел, при этом стоимость канала устанавливается равной стоимости локального интерфейса для совместно используемого канала. В свою очередь p-узел возвращает канал с нулевой стоимостью обратно на каждое устройство, подключенное к общему каналу. Это снижает сложность вычисления SPF для крупномасштабных каналов с множественным доступом.
Концептуализация связей, узлов и достижимости в протоколах состояний каналов
Один сбивающий с толку аспект протоколов состояния каналов - это то, как узлы, каналы и достижимость взаимодействуют друг с другом. Рассмотрим рисунок 5.
И в OSPF, и в IS-IS узлы и каналы используются как Shortest Path Tree, как показано более темными сплошными линиями. Пунктирные линии показывают, как информация о доступности прикрепляется к каждому узлу. Каждый узел, подключенный к конкретному достижимому пункту назначения, объявляет пункт назначения - не только один из двух узлов, подключенных к каналу точка-точка, но и оба. Почему так?
Основная причина в том, что это просто самое простое решение для объявления доступных мест назначения. Если вы хотите создать протокол маршрутизации, который объявлял бы каждое достижимое назначение только как подключенное к одному устройству, вам нужно было бы найти способ выбрать, какое из подключенных устройств должно объявлять достижимое назначение. Кроме того, если выбранное устройство выйдет из строя, то какое-то другое устройство должно взять на себя объявление достижимого пункта назначения, что может занять время и негативно повлиять на конвергенцию. Наконец, позволяя каждому устройству объявлять о доступности для всех подключенных пунктов назначения, вы фактически можете найти кратчайший путь к каждому пункту назначения.
Проверка двустороннего подключения в SPF
Двусторонняя связь является проблемой для плоскостей управления в двух разных местах: между соседними устройствами и при вычислении путей без петель через сеть. И IS-IS, и OSPF также обеспечивают двустороннюю связь при вычислении путей без петель.
Существенным элементом является проверка обратной связи.
Рисунок 6 используется для демонстрации этого.
На рисунке 6 направление каждого звена обозначено стрелкой (или набором стрелок). Связь [A,B] является однонаправленной по отношению к A. Остальные связи являются двусторонними (двунаправленными). При вычислении SPF D будет делать следующее:
При обработке информации о состоянии связи C обратите внимание, что C утверждает, что он подключен к B. D найдет информацию о состоянии связи B и проверит, чтобы убедиться, что B также утверждает, что он подключен к C. В этом случае B действительно утверждает, что подключен к C, поэтому D будет использовать канал [B, C].
При обработке информации о состоянии связи B обратите внимание, что B утверждает, что он подключен к A. Однако, изучая информацию о состоянии связи A, D не может найти никакой информации от A, утверждающего, что он подключен к B. Из-за этого D не будет использовать канал [A, B].
Эта проверка обычно выполняется либо до того, как линия связи будет перемещена в TENT, либо до того, как линия связи будет перемещена из TENT в PATH.
Вопрос о балансировке нагрузки на WAN-линках встает довольно часто, и, к сожалению, в отличие от некоторых других вещей, которые можно настроить на оборудовании MikroTik быстро и безболезненно - в случае настройки Load Balancing придется немного постараться. Тема относительно сложная, наличие нескольких WAN-линков и задача по настройке балансировки нагрузки включает в себя настройку нескольких шлюзов и маршрутов по умолчанию, множество правил трансляции NAT и так далее.
Настройка маршрутизатора
Итак, в наличие у нас имеется один маршрутизатор MikroTik, который подключен к двум провайдерам - Тарс Телеком и Милайн на портах ether1 и ether2 соответственно, и локальной сетью на порту ether3. Трафик из локальной сети будет NATирован из обоих WAN портов и будет сбалансирован по нагрузке. Топология ниже:
Настраиваем локальные IP-адреса:
/ip address
add address=1.1.1.199/24 interface=ether1 comment="Tars"
add address=2.2.2.199/24 interface=ether2 comment="Meeline"
add address=192.168.1.1/24 interface=ether3 comment="LAN Gateway"
Настраиваем шлюзы по умолчанию:
/ip route
add dst-address=0.0.0.0/0 check-gateway=ping gateway=1.1.1.1,2.2.2.1
Настраиваем NAT на WAN портах для исходящего направления:
/ip firewall nat
add action=masquerade chain=srcnat comment="Tars" out-interface=ether1
add action=masquerade chain=srcnat comment="Meeline" out-interface=ether2
Если на данном этапе перестать настраивать роутер, то это будет являть собой пример настройки отказоустойчивости. Если один из линков “отвалится”, то вместо него будет использоваться второй. Однако, никакой балансировки нагрузки здесь нет и в помине, и, с экономической точки зрения, это является плохой идеей - вряд ли найдется компания, которая захочет платить абонентскую плату за второй канал и использовать его только в случае аварии.
Исходящая и входящая Mangle маркировка
Одной из типичных проблем при использовании более одного WAN-соединения является то, что пакеты принятые на одном WAN интерфейсе, могут тут же быть отправлены через другой WAN-интерфейс, что может, к примеру, сломать VPN-based сеть. Нам нужно чтобы пакеты “принадлежащие” одному и тому же соединению принимались и отправлялись через один и тот же WAN порт. В случае аварии у одного из провайдеров, все подключения на порту “умрут” и затем будут переподключены на другом WAN порту. Для этого необходимо промаркировать соединения:
/ip firewall mangle
add action=mark-connection chain=input comment="Tars Input" in-interface=ether1 new-connection-mark="Tars Input"
add action=mark-connection chain=input comment="Meeline Input" in-interface=ether2 new-connection-mark="Meeline Input"
Это поможет маршрутизатору отслеживать порт для каждого входящего подключения.
Теперь мы будем использовать отметку подключения для входящих пакетов для вызова отметки маршрутизации. Это отметка маршрутизации будет использована позднее на маршруте, который будет сообщать подключению через какой WAN-порт необходимо слать пакеты наружу.
add action=mark-routing chain=output comment="Tars Output" connection-mark="Tars Input" new-routing-mark="Out Tars"
add action=mark-routing chain=output comment="Meeline Output" connection-mark="Meeline Input" new-routing-mark="Meeline Telecom"
Помеченные подключения затем получают метку маршрута, так что роутер сможет маршрутизировать пакеты так, как нам необходимо. В следующем шаге мы настроим роутер таким образом, чтобы помеченные пакеты отправлялись наружу из корректного WAN-подключения.
Маркировка LAN маршрута
Понадобится также настроить несколько Mangle правил - они необходимы, чтобы сообщить роутеру о необходимости балансировки пакетов, которые отправляются из локальной сети. Сам механизм балансировки в этой статье не описывается, можно только сказать что происходить много операций хеширования - если же интересно копнуть глубже, то вы можете обратиться к официальной документации MikroTik. В соответствии с этими правилами маршрутизатор будет балансировать трафик приходящий на порт ether3 (LAN-порт), который направлен на любой нелокальный адрес в Интернете. Мы захватываем трафик в цепочке предварительной маршрутизации для перенаправления его на необходимый нам WAN-порт в соответствии с меткой маршрутизации.
Следующие команды балансируют трафик на LAN-интерфейсе через две группы:
add action=mark-routing chain=prerouting comment="LAN load balancing 2-0"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Tars" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/0
add action=mark-routing chain=prerouting comment="LAN load balancing 2-1"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Meeline" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/1
Настройка меток маршрутизации выше была выполнена точно такие же как и в предыдущем шаге и соответствуют тем маршрутам, которые будут созданы в следующем шаге.
Особые маршруты по умолчанию.
В данный момент у нас должны быть помечены соединения поступающие на WAN-порты и эти метки были использованы для создания меток маршрутизации. Балансировка нагрузки в LAN, описанная в предыдущем шаге, также создает метки маршрутизации в соответствии со следующим шагом, в котором будут созданы маршруты по умолчанию, которые будут захватывать трафик с данными метками маршрутизации.
/ip route
add distance=1 gateway=1.1.1.1 routing-mark="Out Tars"
add distance=1 gateway=2.2.2.1 routing-mark="Out Meeline"
Данные маршруты используются только при наличии необходимой метки маршрутизации. Непомеченные пакеты используют обычный маршрут по умолчанию.
Маршруты, относящиеся к Тарс Телеком получают метку подключения, которая вызывает метку маршрутизации. Эта метка маршрутизации совпадает с меткой в маршруте выше и обратный пакет выходит из того же интерфейса, на котором был получен изначальный пакет.
Заключение
Итого, какие шаги по настройке роутера были выполнены:
Маркировка новых подключений в WAN
Соединения с этой маркировкой получают метку маршрутизации
Исходящий из локальной сети трафик балансируется с теми же метками маршрутизации
Метки маршрутизации соответствуют маршрутам по умолчанию и отправляются из соответствующего интерфейса
Если количество WAN-линков более 2 - необходимо проделать такие же действия для остальных подключений.
Итого, теперь у вас настроена балансировка трафика для двух WAN-соединений.