Назначение BGP, автономные системы, типы сессий

Всем добрый день еще раз. Приветствую вас на уроке номер 2. И сегодня мы будем рассматривать основы протокола BGP. Начнем мы, пожалуй, с общего понимания, что это за протокол, когда он был разработан и для каких целей он используется на текущий момент. Итак, по сути, BGP расшифровывается как Border Gateway Protocol, то есть некий протокол пограничного шлюза. То есть это некий протокол маршрутизации, который призван обеспечить маршрутизацию между разными автономными системами. При этом протокол в BGP было несколько версий. Первая, вторая, третья, четвертая. Наиболее актуальна эта версия 4.

Она описана в соответствующем RFC номер 4271. При этом я хочу обратить ваше внимание, что RFC датируется январем 2006 года. То есть нам это говорит о том, что протокол очень хорошо изучен, он очень стандартизирован. В нем, наверное, почти нету так называемых серых мест. И я надеюсь, что почти все вендоры реализовали его одинаково. Соответственно, поскольку протокол используется для связи различных автономных систем друг с другом, то у этого протокола должны быть несколько иные характеристики по сравнению, например, с протоколом OSPF. Если окунемся в историю, не то чтобы в историю, а в историю своей памяти,

когда вы вспомните некую информацию про OSPF, вы поймете, что OSPF – это протокол внутреннего шлюза. То есть он относится к протоколу IGP, Interior Gateway Protocol. То есть OSPF предназначен для работы внутри одной автономной системы. Есть ли какая-либо принципиальная разница между протоколом, который работает между автономными системами, и между протоколом, который работает внутри одной автономной системы? На самом деле, чтобы ответить на этот вопрос, нужно прежде всего ответить на вопрос, что такое автономная система. Есть RFC, номер 1913, в котором сказано, что автономная система – это некая группа устройств, либо префиксов, которые находятся, по сути, под единым административным управлением.

Соответственно, политики маршрутизации внутри такой автономной системы, они понятны и они, скажем так, консистентны. То есть некая группа сетевых администраторов настраивает политики так, как хочется конкретно им, либо так, как нужно бизнес. По сути, вы можете считать, что автономная система – это некая одна независимая организация. Поэтому, когда мы говорим о протоколе, который позволяет нам амортизировать сети между разными автономными системами, это, наверное, в 90-95% случаев указывает на то, что будет запущена амортизация между независимыми организациями. К чему это приводит? Смотрите. Во-первых, у организаций могут быть разные цели. Ну, например, скажем, две организации связаны между собой, скажем, двумя каналами связи.

Одна организация хочет использовать для связи первый канал, второй организация, а второй организация хочет использовать второй канал. Как им быть? Если бы обе эти организации были под единым административным управлением, и, скажем, там бы работал успех, то не было никаких проблем. Например, вы могли бы повесить, скажем, я не знаю, задрать где-нибудь успех кост и пустить трафик по одному линку. Между разными автономными системами получается так, что каждый администратор может решать, как будет бегать трафик только внутри своей зоны ответственности, только внутри своей системы. Как трафик побежит внутри другой автономной системы, он на это повлиять не может, очевидно. Это должны решать администраторы, собственно говоря, партнеры.

Это первая проблема, которая возникает. По сути, весь мир, на самом деле, тот же интернет, он состоит из большого-большого количества абсолютно разрозненных автономных систем, которые и законы, скажем так, муртизации внутри одной АЭС, могут совершенно не совпадать с законами муртизации в другой АЭС. Собственно говоря, BGP был призван как раз таки решить проблему, как муртизировать трафик внутри вот такой разрозненной инфраструктуры. Это первое. Второе. BGP обладает огромнейшей масштабированностью. То есть, если вы на самом деле сейчас, если вы посмотрите на какой-нибудь публичный RAL сервер, то увидите, что в мире на текущий момент, я так думаю, там порядка восьми сотен тысяч префиксов. Мак гуляет. И чтобы обрабатывать такое количество маршрутной информации,

нужен какой-то другой алгоритм, нежели, например, тот же OSPF. Технически, конечно, в OSPF, в OSPF, наверное, запихнуть восемь сотен тысяч префиксов сможете. То есть, протокол-то сам, ну, протоколу без разницы, сколько префиксов обрабатывать, да, там, какое дерево считать. Вопрос только в цене таких расчетов. Ну, я, честно говоря, не уверен, что какая-либо современная железка сможет переварить вот эти все маршруты интернета. Ну, я имею в виду с точки зрения OSPF. Да, то есть, потому что внутри какой-то одной автономной системы требования у нас обычно какие? То есть, там, скажем, максимальная, а, скажем, минимальная скорость восстановления, минимальное время восстановления сети после сбоев, да, то есть, максимально быстрая реакция на конвергенцию.

То есть, максимально быстрая конвергенция. Очевидно, что, если посмотреть на амортизацию, скажем так, с сего земного шара, да, то такой подход не очень подойдет, да, потому что префиксов очень много. BGP, да, знаете, он конвергирует, то есть, он реагирует на изменения в топологии не так быстро. То есть, если вы видите, скажем, сходимость BGP в минуты, либо, там, скажем, даже в десятки минут, в целом, в целом, это, наверное, нормально. Ну, потому что, по сути, скорость принесли в жертву его масштабируемость. Вот. Но при этом, при этом масштабируемость BGP, она определяется не только количеством маршрутной информации, которая может передаваться между маршрутизаторами, но и, скажем так, типом этой информации. То есть, если, скажем, OSPF умеет передавать только IP маршруты, да, то в BGP могут быть разные маршруты.

То есть, там, скажем, могут передаваться так называемые VPN маршруты. Поэтому эти маршруты могут быть, скажем, как IPv4, так и IPv6. Могут передаваться различные, скажем, и VPN маршруты. Более подробно, более подробно о таких вот, скажем так, не совсем стандартных типах префиксов, вы можете узнать из курсов MPLS и VPN VXLAN. В данном курсе мы с вами сосредоточимся исключительно на передаче IPv4 информации между маршрутизаторами. Ок. Итак, мы с вами определились, что такое автономная система. То есть, по сути, это некий набор устройств, которые находятся под единым административным управлением. Соответственно, все автономные системы можно разделить, наверное, на две-две большие категории. Это транзитная автономная система и это тупиковая.

Что это такое? Тупиковая автономная система – это чаще всего сеть, скажем, предприятий. То есть, у вас есть некая организация, вы подсоединяетесь к сервис-провайду. То есть, вы потребляете трафик, то есть, к вам трафик либо приходит, либо трафик от вас уходит. Но он уходит, как бы, порожденный от ваших, например, серверов, от ваших маршрутизаторов. Транзитная автономная система – это когда есть некая АЭС, у которой есть, как минимум, два соединения с другими автономными системами. То есть, пакет пролетает на вход, бежит, бежит, бежит где-то внутри нашей автономной системы и дальше выходит из нашей автономной системы и бежит дальше. Это транзит. Чаще всего, чаще всего, все подключения организаций, все подключения Enterprise – это тупиковая автономная система.

Потому что, ну, обычно компании нет никакого смысла гонять трафик через себя транзитом. Транзитная автономная система в основном принадлежит сервис-провайдеру. Да, конечно, есть некие организации, которые такие полуэнтерпрайз, полуэнтерпрайз, полуэнтерпрайз. Это сервис-провайдер. Но более фундаментально это разделение. То есть, Enterprise – тупиковая АЭС, и сервис-провайдер – это транзитная. Хорошо. Вот я сказал, что у нас есть Enterprise, есть сервис-провайдер. Возникает вопрос, всегда ли нам нужен BGP для соединения между Enterprise и сервис-провайдером. Давайте с вами рассмотрим парочку примеров, буквально парочку примеров, и я думаю, что после этого станет все понятно.

Позвольте мне открыть NikiPaint, который мы будем использовать для рисования. Давайте рассмотрим самого простейшего случая. У нас есть случай А. Есть некая организация. У нее есть муристизатор. То есть это border. Это некая выходная точка из сети. У нас есть сервис-провайдер – ASP. Дальше за этим ASP где-то скрывается наш интернет. ВВВ, условно. У ASP также есть пограничный амортизатор, который используется для подключения клиентов. То есть в первом случае есть соединение просто точка-точка, одно соединение между Enterprise организацией и интернетом, и между сервис-провайдером.

Так вот, вопрос. Целесообразно ли применять в этом случае какую-то динамическую амортизацию? В данном случае ответ будет нет. Почему? Дело в том, что чтобы обеспечить доступ сети организации в интернет, в принципе достаточно на вот этом амортизаторе прописать дефолтный маршрут через сеть провайдера. Соответственно, со стороны провайдера прописывается некий специфичный маршрут, скажем, предположим, некий маршрут 1, 2, 3, 4. Ну, 1, 2, 3, 0, например, слэш 24, да, via Enterprise. Пожалуй, для такого типа подключения обычно всегда используется статическая амортизация.

Далее. Вариант B. Вариант B. У нас есть Enterprise. Есть амортизация. Амортизация. И, скажем, есть два сервис провайдера. ASP1 и ASP2. И, соответственно, подключение у нас происходит вот таким образом. Здесь уже, в принципе, можно задуматься над тем, нужна ли нам какая-то динамическая амортизация, либо же нет. Это все будет зависеть исключительно от того, как вы собираетесь использовать ваши каналы в интернет. В простейшем случае, в простейшем случае, да, очень часто вот сервис провайдер 1, например, это может быть дешевый. А сервис провайдер 2, это может быть, например, какой-то дорогой канал связи.

Поэтому в этом случае что можно сделать? Мы прописываем дефолт. При этом ставим административную дистанцию маленькую, скажем административную дистанцию единичку. Через второй интерфейс мы также прописываем, например, дефолт. Но административную дистанцию ставим побольше, скажем 10. В этом случае по умолчанию весь трафик будет ходить через дешевый сервис провайдера. Как только связанность между интерпрайзом и сервис провайдером теряется, этот синий маршрут пропадает из таблицы муртизации и переключается на красный. То есть здесь можно в большинстве случаев, в большинстве случаев здесь можно обойтись статической муртизацией.

Вариант номер 3, вариант номер 3, вариант номер В. Итак, у нас уже есть более сложная схема подключения. У нас есть, например, два независимых муртизатора в интерпрайзе. И, например, каждый муртизатор подключен к своему сервис провайдеру. В принципе, каждый муртизатор может иметь вот такие еще подключения, крест на крест. В данный момент это будет совершенно не актуально. Что же делать? Обойтись просто дефолтными маршрутами, маршрутами по умолчанию, в такой ситуации будет несколько тяжелее. Почему? Потому что, конечно, вы можете прописать маршрут вот здесь, например, 0.0. Вы можете прописать вот здесь маршрут 0.0.

Но вы должны понимать, что эти маршруты будут… Амортизация она locally significant. То есть, вам эти дефолты нужно будет поместить внутрь вашей сети организации. Соответственно, настроить, например, здесь какую-то redistribuição. Но все в том, что вам нужен некий динамический… В любом случае потребуется некий динамический обмен между вашими border-устройствами. Это ваш border-устройство. Так вот, ситуация, когда у вас есть несколько стыков с различными организациями, либо есть несколько стыков с одним и тем же, с одной и той же организацией. Пожалуй, вот это, скажем так, наилучший кандидат на использование динамической маршрутизации в данном случае.

О деталях подключения, конечно, мы с вами еще поговорим чуть побольше здесь. Как эта маршрутизация настраивается. Сейчас же я хочу, чтобы вы просто поняли, почему… Почему, скажем так, в случаях А и В чаще всего никакая динамическая маршрутизация не нужна, а в случае В она бывает необходима. Давайте чуть-чуть подробнее остановимся про автономные системы. Прежде всего, вы должны понять, что автономная система – это на самом деле просто некое число. То есть это число, которое кодируется точно так же, как номер вашего успеха в процессе. С одним лишь отличием. С одним лишь отличием.

Первое отличие, скажем так, с несколькими отличиями. Первое отличие – то, что длина или размерность автономной системы, она может быть либо двухбайтной длины, либо двухоктетной, либо четырехоктетной. Здесь дело просто в том, что первоначально все автономные системы были двухоктетной, то есть они могли принимать значения от 0 до 65535. При этом некоторые из них зарезервированы. В частности, вы не можете использовать такие значения, как 0, то есть это зарезервированное значение. Число 65535 плюс здесь затесалось некое число 23456. Видите, оно так стоит немножко особнячком.

Мы чуть-чуть попозже на этом моменте остановимся. Вот этот весь диапазон от 0 до 65000 делится на две категории. Первая категория – это публичная автономная система и это приватная, либо частная. Так вот, публичная автономная система – это система, которая видна в интернете. Чтобы иметь легитимное право использовать номер публичной автономной системы на вашем амортизаторе, вы должны это право купить. В частности, этим занимается, я думаю, вам уже известная организация ИАНа. Через своих лиров она эти публичные автономные системы продает. В мире ведется учет всех занятых автономных систем.

То есть, в принципе, это открытая информация, например, через BGP Looking Glass. Вы всегда можете узнать, за какой организацией закреплена та или иная автономка. Далее. Частные автономные системы занимают диапазон от 64512 до 65534. Они могут использоваться вами, если вы, скажем, настраиваете BGP внутри вашей организации и, например, не перейтись, скажем, с сервис-провайдерами. То есть, у вас нет взаимодействия с сервис-провайдерами. Это раз. Либо есть еще один вариант использования приватных автономных систем – это следующий сценарий. Это сеть организаций.

Предположим, что у вас есть два бордера. Но так сложилось, скажем, вот этот бордер может находиться в условном Хабаровске. Скажем, в Москве вы используете Ростелеком. Предположим. Вот так сложилось. А в Хабаровске вы тоже используете Ростелеком. То есть, по сути, у вас просто есть два независимых соединения. Два независимых соединения. Но при этом вы имеете связанность с одним и тем же сервис-провайдером. В этом случае можно договориться с сервис-провайдером и сказать так. Я, например, буду использовать приватную автономную систему, скажем, 64512.

Ростелеком использует автономную систему, скажем, номер 100, которая у него куплена. В этом случае Ростелеком здесь настраивает связанность с вашей и здесь настраивает связанность с вашей приватной автономной системой. То есть, использовать приватную автономную систему можно либо, если вы используете BGP исключительно внутри своей организации. Это раз. Второе. Если вы используете BGP на стыке с одним сервис-провайдером. Это второй use case. И третий use case. Когда вы используете BGP, скажем, вы строите какую-нибудь частную облаку, скажем, у себя. И вы используете внутри себя или для связи с вашими партнерами. Например, автономки 64513. Вот здесь вот.

64514. Скажем, это все ваши автономки, которые… Скажем, вы взяли 512-ю и поместили в Москву. Автономку 513-ю поместили в Санкт-Петербург. 514-ю в Хабаровске, например. И вот у вас здесь такие вот connectivity есть. Но при этом маршетизация не выходит во внешний мир. В этом случае тоже совершенно допустимо использовать номера приватных автономных систем. В какой-то момент публичных автономных систем стало просто не хватать. То есть произошла, примерно, такая же ситуация, как с IPv4-адресами. Поэтому придумали так называемые четырехактейльные автономные системы. Соответственно, их теперь доступно примерно 4 миллиарда возможных значений. И они умеют принимать вид от 65 тысяч до 4 миллиардов с небольшим.

При этом они точно также делятся на частные и публичные. Вот это диапазон публичных, вот это диапазон частных. При этом не всем удобно работать с такими большими числами. Например, 4 миллиарда. Так вот, отображаться автономные системы могут в двух видах. Первый вариант отображения, так называемый Ice Plane. То есть это просто число от 0 до 4 миллиардов. И второе, так называемое Ice Dot. То есть это значение от 0.0 до 65535.65535.

По умолчанию в операционной системе Cisco EOS используется изображение Ice Plane. Давайте с вами в этом сейчас и посмотрим. Это мы убедимся. Так, откроем мое консоль. Итак, у меня есть подключение на мастеризатор R1. Далее, создаем BGP процесс. Создать его можно командой router BGP. Далее, можно ввести номер автономной системы. То есть, как видите, я его могу ввести либо вот в таком формате, либо я его могу ввести вот в таком формате. То есть, вот это Ice Plane, вот это изображение Ice Dot. Например, я введу, скажем, давайте там какое-нибудь там, какое-нибудь такое число.

Теперь, если я скажу show run include BGP, то у меня процесс BGP так вот, собственно говоря, в таком формате Ice Plane будет записан. Если я хочу его перевести в изображение Ice Dot, то есть через точку, то я даю команду BGP, далее Ice Notation и Dot. Что теперь получается? Обратите внимание, до этого у меня было вот такое. вот такое. Сейчас изображение выглядит вот так. То есть, 9738.14275. Какой вариант вы будете использовать? На самом деле, не так важно. Усключительно по вашему удобству. Если вы хотите вернуться к изображению Ice Plane,

нужно ввести команду BGP Ice Notation Dot, но с ключевым словом Note. Ну, то есть, название поменялось. Есть важный нюанс. Смотрите, если, как вы знаете, вы можете создать довольно-таки много протоколов, муртизации, таких как OSPF, EGRP, RIP, но создать, например, несколько BGP процессов у вас не получится. То есть, вам муртизации скажут, что BGP is already running. Номер авциональной системы такой-то. Не получится. Давайте семся аск ing olmuşе. И самое главное про курицы Natalie Мы сейчас зах rebellion. И повbie technical Theater tier обоих короче пути этот тусим ст иでб worlds напомнить