Border Gateway Protocol

Финальный рывок в нашем курсе по роутингу — это протокол BGP, Border Gateway Protocol. Можно сказать, король всех сетевых протоколов, потому что он из всех протоколов, которые мы в курсе изучали, самый мощный, самый функциональный, самый настраиваемый, самый гибкий. Но у него задачи были своего рода как раз адаптироваться под совершенно произвольные условия среды, и поэтому действительно вырос он в такого большого толстого монстра. Мы в рамках нашего курса не будем изучать все фичи BGP, даже близко. Мы не будем изучать не то что все фичи, мы не будем изучать даже три четверти фич. Но даже той одной четверти, которая у нас будет, я думаю, вам будет достаточно для ситуации, когда вы в сети предприятия захотите зачем-то запустить BGP. Давайте смотреть, что же это такое, что это за протокол, откуда он взялся. Для BGP есть основная задача —

это обмен маршрутной информацией между разными автономными системами. Почему у нас вообще есть задача делать какой-то отдельный протокол для такого взаимодействия? Есть у нас, например, OSPF — чем OSPF хорош, чем OSPF плох? Почему есть у нас RIP — чем RIP хорош, чем плох? И так далее. Это всё протоколы IGP, Interior Gateway Protocol. Они все настраиваются условно говоря одними и теми же людьми. И если вдруг у нас какой-то роутер начинает присылать какой-то неправильный маршрут, это ошибка администратора, который позволил роутеру неправильный маршрут отправить. И эта ошибка фактически администратора, который производил настройку сети. Такого быть не должно, и в нормальной ситуации, пока администратор ошибок не делает, таких вещей происходить не будет. В то же время в BGP у нас разные автономные системы находятся под разным административным контролем. И если вы настраиваете из своей стороны BGP-роутер, а сосед — другой администратор, у которого другое начальство, у которого

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

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

Если говорить про сегодняшнее актуальное состояние, то сейчас в интернете порядка 700 тысяч маршрутов. Плюс к тому есть ещё дополнительные маршруты, которые могут в таблице маршрутизатора присутствовать, которые не интернетовские, а какие-то частные, клиентские и прочее. Поэтому, если вы работаете в интернете, вы должны будете ожидать, что у вас в таблице порядка миллиона записей может быть. Обычные протоколы динамической маршрутизации — обычные я имею в виду какой-нибудь условный RIP или OSPF — они под такое количество маршрутов просто в принципе не предназначены. И если вы попытаетесь условно в OSPF запихать маршруты всего интернета, у вас OSPF-роутеры, скорее всего, просто перестанут работать. Они не смогут корректно работать, на них такую нагрузку не дать. Они неплохо работают, когда у вас в сети немного маршрутов. Но как только вы начинаете неразумного размера нагрузку на них давать, они начинают плохо себя чувствовать.

BGP, с которым мы будем работать, он специально предназначен для работы в интернете. Он специально предназначен под большое количество маршрутов. У него есть огромное количество твиков, хаков и прочего, которые позволяют ему стабильно существовать в интернете, где множество сетей, множество префиксов постоянно принимается, отправляется, постоянно изменяет своё состояние. И BGP — протокол, который заточен под наиболее стабильную работу в абсолютно нестабильной среде. Актуальная версия протокола BGP — это BGP версии 4. Есть и другие версии, но они, как и в случае, например, с IP, особо не выходили за пределы лабораторий, в которых их пытались создавать. И предшественником протокола BGP был протокол EGP. Он назывался Exterior Gateway Protocol, но это не Exterior Gateway Protocol как антоним Interior Gateway Protocol. Вы знаете, у нас протоколы делятся на IGP и EGP. А это именно протокол, у которого было само название Exterior Gateway Protocol, RFC 827.

Не путайте, пожалуйста: аббревиатуры одинаковые, названия одинаковые, но EGP и EGP — это разные вещи. EGP, который протокол, именно само название протокола — это предшественник протокола BGP, классовый протокол, который даже не протокол маршрутизации, а протокол обмена маршрутной информацией. На самом деле есть определённая разница между этими двумя понятиями. А EGP, который мы сегодня понимаем как аббревиатуру, EGP — это Exterior Gateway Protocol, протокол, который просто предназначен для обмена маршрутами между разными автономными системами. Очень часто здесь возникает путаница. И вполне понятно, что путаница здесь очевидно должна возникать, когда аббревиатура одинаковая, расшифровка этих аббревиатур тоже по факту одинаковая. Но это две разные вещи. BGP сегодня, этот самый BGP версии 4, используется в сценарии, когда у нас ставятся сессии между двумя роутерами, и дальше там передаются маршруты разных, назовём это, адресных семейств.

Как у нас есть OSPFv3, который может передавать маршруты IPv4 и IPv6, так же BGP может передавать маршруты IPv4 и IPv6. Делается это с помощью практически обязательного на сегодня расширения Multiprotocol Extensions. И BGP, который может передавать маршруты одновременно разных адресных семейств, будет называться MP-BGP. Иногда бывают люди, которые пытаются расшифровывать эту аббревиатуру как Multipoint BGP или что-то ещё. Нет, Multiprotocol. BGP будет использовать TCP для транспорта, и этим он будет резко выделяться по сравнению со всеми остальными протоколами, которые мы изучали, потому что все протоколы, которые мы изучали, использовали так или иначе мультикаст для обнаружения соседей или для рассылки маршрутной информации. В IGP-протоколах это норма, потому что внутри вашей автономной системы случайные какие-то роутеры ниоткуда не возьмутся, левые, а те роутеры, которые вы добавляете,

они автоматически обнаруживаются, и автоматически с ними устанавливаются соседские отношения, автоматически со всеми роутерами, которые проходят базовую проверку, вы будете обмениваться маршрутами в условном OSPF или в EIGRP. В BGP у вас в принципе не может быть ситуации, когда на каком-то роутере внезапно обнаружится какой-то лишний сосед. BGP — это протокол для обмена маршрутной информацией между автономными системами. У вас количество стыков между автономными системами — есть, например, автономка провайдера, есть ваша автономка. Случайно зародиться роутер на стыке этих автономок не может. Точнее, не один роутер, а два. Один с одной стороны, другой с другой, и между ними есть связь. Связи между автономками просто так не появляются. Это штучные, единичные случаи, когда у вас такая штука появляется. И обнаружить соседа автоматически — это задача, которая для BGP неинтересна. Потому что для BGP интересна стабильная работа. И если вдруг в BGP вы хотите сказать, что у нас есть какое-то соседство,

вы это соседство должны прописать статически. Вы на своём роутере говорите: у нас есть линк в сторону соседа на вот такой айпишник соседа. На соседе вы говорите: у нас есть такой линк в сторону другого соседа, айпишник соседа вот такой. Вы статически прописываете все соседства, и для этого как раз TCP может быть использован вполне. TCP будет предполагать стабильную работу. Если что-то потеряется, TCP переотправит все нужные данные, убедится, что данные дошли до получателя. И TCP будет использоваться подключением на 179-й порт. BGP — протокол, который создавался изначально для решения двух задач. Первая задача — это безопасность, чтобы наиболее стабильную работу можно было ожидать от сети, построенной на его основе. BGP не ориентируется на скорость. Он никоим образом не быстрый протокол. EIGRP — когда мы говорим про то, чем хорош EIGRP, мы говорим, это в первую очередь очень быстрый протокол.

Мы не говорим про то, что он надёжный или стабильный, или безопасный. Мы говорим — он очень быстрый. У него всегда наготове запасной маршрут. Если можно пользоваться этим маршрутом — отлично, а если нет, то он запускает алгоритм DUAL, в котором тоже достаточно быстро выясняет, есть ли какая-то сетка в сети или нет, если у нас был один маршрут, потом стал другой. Он действительно во многих ситуациях EIGRP будет работать очень быстро. BGP вообще никоим образом не быстрый. Он может в определённых ситуациях тупить и ждать применения изменений, когда эти изменения в сети происходят. И таблица маршрутизации будет обновляться только через достаточно большое время. Это время может исчисляться минутами. И дальше — BGP создан для того, чтобы быть масштабируемым в интернете, где большое количество роутеров, супер большое количество маршрутов. BGP должен чувствовать себя как рыба в воде.

И поэтому BGP сам способен выдержать очень много маршрутов в таблице BGP, в таблице маршрутизации. Другой разговор, что железо, которое BGP поддерживает, совершенно не факт, что может такое количество маршрутов выдержать, потому что, допустим, если вы возьмёте какие-нибудь старые Cisco Catalyst свичи или старые семитысячные роутеры, может быть такое, что у них, например, кэш аппаратного ускорителя CEF не может работать больше чем с 512 тысячами маршрутов. А сегодня в интернете их 700 тысяч. Поэтому может быть такое, что BGP позволит создать на железку такую нагрузку, которую железка переживать не сможет. BGP будет способен обработать большое количество маршрутов. BGP будет способен с этими маршрутами стабильно работать, даже если вдруг приходят какие-то маршруты, которым вы не верите — вы с ними можете что-то сделать. Вы можете, например, сказать,

что у нас есть сосед, и этот сосед в другой автономке, мы ему не верим, мы ему не доверяем, и мы в первую очередь всё, что от него приходит, проверяем на вшивость и проверяем по какой-то определённой политике. И если он нам что-то присылает, мы это внимательно изучаем, инспектируем, и находим, что это безопасный маршрут, что им можно пользоваться, мы его добавляем в таблицу. А если нет, если мы не верим ему, то мы этот маршрут не принимаем и просто сразу его отбрасываем. Так что BGP — это такой универсальный протокол для всех случаев жизни. Сегодня у этого протокола есть одно ещё забавное применение. Его начинают использовать даже внутри сети. Дело в том, что за счёт его масштабируемости, за счёт его гибкости — а он действительно очень гибкий протокол, потому что с его помощью с маршрутами можно делать всё что угодно — BGP становится интересен даже внутри сети, внутри автономной системы. И его начинают уже использовать, в кавычках, не совсем по назначению. Его начинают использовать в качестве IGP-протокола,

или его начинают использовать вместе с каким-то другим IGP-протоколом для перетаскивания маршрутов внутри автономной системы. Дело в том, что если запустить, например, внутри автономки условный OSPF, то OSPF — хороший протокол. Он топологию считает, он кратчайшие маршруты считает, он очень быстро реагирует на изменения, но он плохо ориентируется в сети, где много-много маршрутов. А BGP, напротив, хорошо работает, когда много маршрутов. И связка OSPF плюс BGP на самом деле решает вообще все возможные проблемы. Там и link-state поведение, что у нас внутри связи между роутерами рассчитываются кратчайшие маршруты по link-state принципу, и то, что все маршруты пользовательские, с пользовательскими сетями, они появляются не в OSPF, который под такие маршруты не очень хорошо заточен, а в BGP. И дальше BGP перетаскивает маршруты, а OSPF делает так, чтобы эти маршруты были кратчайшими. Это поведение очень часто встречается в современных сетях,

даже в сетях предприятия. Очень часто оно встречается в дата-центрах. И актуальная, скажем, мода пошла, которая заключается в том, что BGP сейчас внутри сетей предприятия, внутри дата-центровых сетей, начинает использоваться вообще без OSPF. Там чистый BGP, и там, скажем, предполагается использование определённых костылей, которые не совсем элегантные, но тем не менее в определённых ситуациях способны сослужить достаточно неплохую службу. Я не рекомендую вам без должного опыта использовать BGP внутри сети предприятия без OSPF, но тем не менее в определённых ситуациях BGP плюс OSPF вам вполне могут пригодиться всегда. Так, почему BGP у нас особый протокол в рамках нашего курса? BGP создан для того, чтобы не доверять соседу.

Внутри автономки у нас все устройства доверенные, поэтому BGP, в отличие от OSPF, не будет ожидать, что сосед всегда присылает только то, что нужно. Если вдруг сосед может присылать какой-то левый маршрут, то мы должны будем использовать протокол класса EGP, то есть протокол, который сегодня будет BGP. Альтернатив сегодня BGP особо и нет. Дальше. В таблице маршрутизации у нас может находиться ограниченное количество маршрутов. Мы всегда ограничены способностями железа. Мы не можем просто сказать: давайте мы принимаем от соседа все префиксы и будем их ставить в таблицу маршрутизации. Мы верим соседу, пусть он будет хороший, белый, пушистый. Пусть мы не будем проверять все префиксы на вшивость и будем добавлять их в таблицу маршрутизации. Вы можете словить ситуацию, при которой соседний роутер будет присылать вам слишком много маршрутов. Особенно если это на стыке с провайдерским роутером будет,

потому что провайдерский роутер знает про все маршруты в интернете. Он вам может выгрузить все маршруты в интернете. Если вы будете принимать вообще все маршруты от соседнего роутера, вы рискуете переполнить свою таблицу. Просто тупо по количеству, потому что устройств, которые поддерживают большое количество маршрутов в таблице маршрутизации, их не так много. И они дорогие. Вы в сети предприятия, как правило, такие устройства держать не будете. Дальше. Трафик в сценарии стыка с другими автономными системами должен ходить по правильному маршруту. Здесь написано слово «оптимальному», но это надо, наверное, в кавычки взять, потому что это не будет всегда самый короткий маршрут или какой-то ещё. Это маршрут, который посчитан с учётом каких-то правил, которые вы для него задаёте. Иногда вам важен самый дешёвый маршрут, иногда вам важен самый быстрый, иногда вам важен тот маршрут, который с наибольшей производительностью будет, то есть самый толстый. Поэтому «оптимальный» здесь он, конечно, в кавычках.

И важно ещё то, что трафик не ходит по тем маршрутам, которые вы не хотите, чтобы он ходил. Например, у вас есть два провайдера. Провайдер 1, ASP 1, провайдер 2, ASP 2. И, соответственно, есть ваша сетка, сеть предприятия. И у вас есть стыки с этими двумя провайдерами. Есть, конечно, весь остальной интернет. И у этих провайдеров есть какие-то аплинки в него. Соответственно, провайдер за что платит? За свой аплинк. Он платит за мегабиты полосы, которые он эксплуатирует. Если провайдер скажет вам, что вы можете через него ходить до всех сетей в интернете. 0.0.0.0 по нулевой маске. Он вам присылает такой маршрут. Этот маршрут попадает в таблицу маршрутизации. И дальше вы его случайно анонсируете в сторону провайдера 2. Провайдер 2 в этой ситуации может сказать: когда мне нужно выйти в интернет, я могу по своему платному аплинку трафик пустить, или я могу его по тому линку, за которое платите вы, пустить трафик в интернет.

Этот трафик пройдёт до провайдера 1. И по факту у нас на провайдере 2 возникает вопрос: как трафик пускать — за деньги или бесплатно? За деньги по своему аплинку, а бесплатно через вас. Чтобы вы нагрузили провайдер 1, и он уже пустил этот трафик по своему аплинку. В этой ситуации вы вполне можете сказать: я не хочу, чтобы трафик ходил через меня, я не хочу анонсировать маршрут по умолчанию в сторону провайдера 2. И в этой ситуации вы должны будете прописать политику, какие маршруты вы провайдеру анонсируете — не всё подряд, что у вас в таблице есть, а рассказываете только то, что должно быть, только то, что вам выгодно. Дальше, внутри сети предприятий у нас, как правило, таких проблем нету. Если у нас где-то есть какая-то сетка внутри сети предприятия, мы рассказываем про неё всем железкам, но опять же — всем своим подконтрольным устройствам. У нас очень редко возникает ситуация, при которой мы половине устройств своей сети хотим рассказать про какую-то сетку, а другой половине не хотим.

В BGP-протоколах это абсолютная норма — мы всегда будем контролировать, что мы принимаем, какие маршруты от соседа, что мы отправляем. Иногда нужно будет смотреть на то, какие маршруты приходят, причём это будет не про префиксы, которые приходят, не про сами маршруты, а про то, какие они. Например, может быть такое, что мы говорим: у нас есть наша сеть, у нас есть наш провайдер, у этого провайдера вообще все маршруты в интернете есть, но он их нам не выгружает. Он говорит: я тебе буду выгружать только дефолтный маршрут. Но нам как клиенту провайдера хочется, чтобы провайдер присылал нам маршруты, которые подключены непосредственно к самому провайдеру. И он будет говорить: у меня здесь есть сетка 1.1.1.1/24, здесь 2.2.2.0/24 — это connected-сетки к самому провайдеру. И нам хочется, чтобы те сетки, которые находятся близко к провайдеру, он нам присылал. Он прислал бы default и прислал бы набор сетей, которые подключены непосредственно к нему.

Заранее список этих IP-адресов мы не знаем, но мы можем по каким-то признакам определить, что это сетки, которые подключены к провайдеру, именно к нашему. Равным образом у нас может быть другой стык с другим провайдером — это будет ASP 2 — и он будет нам свои подключённые сетки посылать. Плюс к тому, есть, конечно, весь остальной интернет, и в этом остальном интернете огромная туча префиксов. И мы говорим: нам не важно, какие именно префиксы в интернете, все они в любом случае складываются в 0.0.0.0, и нам уже всё равно — трафик до этих префиксов пойдёт ли через провайдера 1 или пройдёт через провайдера 2. При таком раскладе мы должны будем на префиксы, которые приходят нам от провайдеров, внимательно смотреть и пытаться понять, хотим ли мы такие префиксы принимать или нет. И мы это должны смотреть не по IP-адресам, не по маскам, а по каким-то другим свойствам. BGP будет работать с помощью так называемых автономных систем. У нас каждый роутер будет принадлежать какой-то автономной системе.

Автономные системы, напомню, это совокупность устройств, которые находятся под единым административным началом, и плюс к тому она обязательно неразрывная. Если у нас просто железка роутер R1 и где-то в совершенно другом месте просто железка роутер R2, и настраивал их один и тот же человек — это не роутеры под единым административным началом. Если они проводом соединены, они друг другу могут трафик посылать — это уже автономная система. И все роутеры, которые рядышком находятся, которые находятся под единым административным началом, настроены в одной логике — они все составляют одну автономную систему. В BGP, для того чтобы показать, что некоторые роутеры используют одинаковые правила, одинаковую логику настройки, каждый участник BGP-взаимодействия должен получить свой номер автономной системы — своё число. Изначально это было 16-битное число, диапазон от 0 до 65535. И каждый участник взаимодействия в интернете должен был получить один такой номер.

Естественно, что тут не так много этих номеров, поэтому очень быстро это пространство закончилось. В 2007 году было предложено использовать 32-битные номера автономок. С 2010 года поддержка этих 32-битных автономок обязательна на любом оборудовании, которое работает с интернетом. И стал возникать вопрос: раньше номера автономок записывались просто как число, например, 65000 — это число, или 12345 — тоже число, и по нему сразу видно номер автономки. Если у нас 32-битные номера автономок будут, то это будет 2 миллиарда 147 миллионов 534 тысячи 941 — это много, это слишком большая, слишком неудобная запись. Поэтому для того чтобы записывать номера автономок в 32-битном формате, было предложено два варианта нотации.

Первая нотация — это когда мы пишем такую длинную колбасу и говорим: это номер автономки, и он вот такой большой. Мы будем их выдавать, начиная с самых маленьких, и потом будем расти. Но в любом случае первое время эти номера автономок будут, например, шести-семизначными, они не будут десятизначными. Но если вдруг нам нужно будет использовать какие-то номера автономных систем, которые, например, ближе к концу диапазона находятся, чтобы не писать 4 миллиарда с чем-то миллионов, мы можем сказать: давайте разделим это 32-битное число на два 16-битных. Как IP — мы разделяем одно 32-битное на четыре 8-битных. То же самое здесь. Нотация asdot будет предполагать, что автономная система у нас записывается в виде двух 16-битных чисел, разделённых точкой. Например, одна и та же автономная система, которая в обычном привычном виде записывается как 65550, она может быть записана и в нотации asdot, в виде двух чисел, разделённых через точку.

65550 — это 65536 плюс 14, это 65550. Если в двоичном виде записывать, там сначала идёт куча нулей, потом единицы, соответствующие двойке в шестнадцатой степени плюс 14. Это что у нас: 2 в третьей степени — восьмёрка, плюс 2 во второй степени — четвёрка, плюс 2 в первой степени. То есть это 00001, дальше 2 в 15 нету, 2 в 14 нету, 2 в 13 нету, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 — вот такое число. И мы соответственно делим эту большую колбасу на две половинки: левая половинка, правая половинка. Левая половинка — здесь 16 разрядов, и правая половинка — тоже 16 разрядов.

И соответственно мы записываем каждую из этих половинок в обычном привычном десятичном виде. Левое число — это просто число 1, здесь всего один битик. Правое число — это число 14. Так что в обычной привычной нотации число 65550, в нотации asdot — 1.14. Странно, что не решили делать нотацию такую же, как в IP, когда у нас число записывается в виде четырёх чисел, разделённых точкой, и каждое по 8 бит. Ну так исторически сложилось, видимо для того, чтобы обычные нормальные 16-битные автономки у нас превращались — допустим, была автономка 12345, это была бы автономка в новой нотации 0.12345. Есть некоторые зарезервированные номера автономных систем. Соответственно, зарезервировано число 0, автономную систему с номером 0 использовать нигде нельзя.

Зарезервирована самая последняя двухбайтовая, 16-битная — номер автономки 65535. И самая последняя четырёхбайтовая автономка — 65535.65535, 4 миллиарда 295 миллионов с чем-то. Для использования в документации есть номера автономных систем — это 512 номеров в 16-битном диапазоне и 15 номеров в четырёхбайтном диапазоне. Запоминать это не надо, но примерно это в районе 64500. Здесь некоторый набор. И соответственно, здесь номера автономных систем, которые можно использовать для частного какого-то взаимодействия, но нельзя выпускать в интернет. Так же как и в случае с частными IP-адресами, тоже были предусмотрены. Смысл этих частных номеров заключается в том, что иногда нужно BGP поднять, но вы не хотите покупать полноценную автономку.

Все автономки, которые IANA распределяет — весь этот диапазон, и 16-битный, и 32-битный — они вообще-то платные, за них надо деньги платить. Но если вам нужно просто по-быстренькому BGP поднять, вы можете поднять BGP сами с собой или со своими товарищами, и вы для этого должны использовать номера, которые не встречаются в интернете — это как раз те самые частные номера автономных систем. Это с 64512 по 65534 — 1024 номера вы получаете под своё взаимодействие, именно частные. Здесь достаточно много, этого вполне хватит для задач частного взаимодействия.

И плюс с 4 миллиардов 200 миллионов — это тоже будут частные. Если вдруг вы хотите в нотации asdot, это число 4 миллиарда 200 миллионов будет вот таким. Но запоминать это, конечно, тяжело. В принципе вы можете запомнить для себя просто для души, что с 64512 всё доступно. И если вы будете использовать нотацию asdot, то 64512 и дальше в первых двух разрядах, и неважно, что в оставшихся двух разрядах — это тоже заведомо частные номера. Эту кривую запись 64086 запомнить, конечно, сложно, но если вдруг вам понадобится указывать номер автономки именно в таком виде — берите 64512, не ошибётесь. Так, как будет BGP работать? BGP — это distance-векторный протокол, иногда его называют path vector. И эта особенность будет подчёркивать, что он будет обмениваться не столько маршрутами и рассказывать, какие он знает маршруты, сколько он будет рассказывать, что известен путь или известное свойство определённого маршрута или определённых маршрутов, и дальше будет рассказывать, какие именно маршруты известны с определёнными свойствами.

Это немножко инвертирует логику. Например, RIP — у нас есть такой протокол RIP, в котором каждый роутер рассказывает: я знаю сетку 10.1.1.0 за 4 прыжка. BGP рассказывает: я знаю некоторые сети за 4 прыжка, в том числе сеть 10.1.1.0. Или в EIGRP у нас есть рассказ, что сетка 192.168.10.0 известна с таким-то delay, таким-то reliability. По каждому префиксу EIGRP рассказывает: эта сетка с такими свойствами, эта сетка с другими свойствами, эта с пятыми, эта с десятыми. BGP на самом деле чаще всего будет строить трассы до одних и тех же, плюс-минус километр, роутеров. Когда у нас те самые 700000 маршрутов, некоторые из этих маршрутов могут быть одинаковыми — они проходят по одинаковому пути, свойства этих маршрутов будут одинаковыми. У нас есть какой-то роутер, который говорит: я знаю сети A, B, C, D, E и F. И дальше у нас есть какая-то трасса между роутерами, и все эти сетки на самом деле идентичны — у них префиксы разные, но маршрут, которым они проходят, абсолютно одинаков.

Поэтому BGP при обмене маршрутной информацией он будет говорить не «я знаю сеть A с такими свойствами, сеть B с такими свойствами, сеть C с такими свойствами», он скажет: я знаю трассу с такими свойствами, и через неё доступны 6 сетей. Единица обмена информации получается — путь, path, а не отдельный префикс. В RIP и в EIGRP — distance-векторных протоколах, которые мы с вами изучали — единица обмена это префикс. В BGP это путь. Тем не менее, как мы понимаем, от перестановки мест слагаемых сумма не меняется — в итоге всё равно все маршруты, все пути, все префиксы попадут в некую таблицу, и дальше из этой таблицы мы будем выбирать лучший маршрут и вставлять его в таблицу маршрутизации. BGP всегда стремится выбрать один лучший маршрут. И на самом деле это важно, потому что в EIGRP, например, у нас нет такого, что мы хотим выбрать один маршрут. Мы хотим всегда сделать так, чтобы у нас наиболее выгодно ходил трафик. EIGRP стремится наиболее быстро сделать обмен взаимодействий, поэтому если у нас два одинаковых маршрута, мы говорим: окей, прекрасно, ни один из этих маршрутов не содержит петли, поэтому мы балансируем трафик — направляем часть трафика налево, часть направо.

В BGP это поведение будет приводить к неприятным последствиям, потому что если у нас есть роутер, у которого есть вариант куда направить трафик — налево или направо — эти пути будут проходить через разные автономные системы. А каждая автономная система она достаточно большая может быть. Здесь может быть всего один роутер, а здесь может быть целая цепочка роутеров, эта автономка протягивается через несколько континентов. Получится, что до конечной точки они всё равно все выйдут, трасса, которая проходит через лево, и трасса, которая проходит через право — они всё равно сольются в одну и ту же итоговую точку, к AS, который анонсирует этот префикс. Но пути, которыми пройдёт трафик, могут быть очень сильно разными, в случае если мы направляем трафик в разные аплинки, которые через разные автономные системы проходят. Поэтому BGP стремится всегда, во всех случаях, выбрать один лучший маршрут. И алгоритм, по которому это надо будет делать — это best path selection.

Есть аббревиатура, которую я ненавижу — BPS, best path selection. Если хотите, можете запомнить. Я никогда не могу запомнить, когда мне говорят «расскажи мне про BPS в BGP», я говорю, что никогда не слышал такую аббревиатуру, расскажите мне про неё сами подробнее. Но тем не менее аббревиатура такая есть, и это просто выбор лучшего пути. Этот самый алгоритм best path selection будет осуществляться с использованием свойств маршрута, свойств пути. И дальше вы должны будете выбрать один самый выгодный маршрут, исходя из этих самых свойств маршрута. Свойства не содержат информацию о физических каких-то параметрах линков, через которые проходит трафик. В BGP свойства — это то, что может повлиять на политику обработки трафика, но эти политики никакого отношения могут не иметь к bandwidth, delay и количеству прыжков между роутерами. Это факт.

RIP у нас оперирует количеством прыжков между роутерами — это физическое свойство сети. Мы можем исходить из предпосылки, что 4 прыжка лучше, чем 5. И да, в большинстве ситуаций, если мы строим какую-то реальную сеть, это действительно будет так. Дальше EIGRP, у него, соответственно, есть bandwidth — это физическое свойство маршрута, через который проходит трафик. Delay тоже — секунды какие-то, их можно пощупать, можно измерить. BGP не оперирует ни производительностью сети, ни задержкой, ни количеством прыжков между роутерами. BGP будет говорить про то, что у него есть вариант, как добраться до какой-то сети. И эти свойства, как добраться до сети, — чисто политические. Типа того, сколько денег вы хотите заплатить за отправку трафика по одному маршруту или по второму. Вы должны будете прописать политику, сказать, что на один префикс мы тратим столько денег — сами прописываем. На другой префикс мы потратим столько денег.

Вам никто про это не расскажет, потому что если расскажет — это будет уже физическое свойство. Вы должны сами эти свойства придумать зачастую. Дальше. Когда вы будете выбирать, как вы хотите направить трафик до какой-то сети, вы должны будете всегда понимать два момента. Когда вы запускаете BGP, он у вас обменивается маршрутной информацией. И маршруты всегда идут в противоположную сторону по отношению к трафику, который потом пойдёт по этим маршрутам. Сначала вы говорите: через меня можно добраться до какой-то сети, отсылаете это своим соседям, те отсылают эти маршруты своим соседям, информация распространяется как бы в сторону от вас. Маршрутная информация. Когда пакеты пойдут по этим маршрутам, они пойдут в вашу сторону. Поэтому вы должны будете понимать, что одно дело — это то, как вы раздадите маршруты. И второе дело — как трафик потом по этим маршрутам пойдёт в вашу сторону. Вы должны анонсировать свои префиксы, которые у вас есть.

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

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

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

Здесь, здесь, здесь. И, соответственно, так или иначе до каких-то внешних автономок дойдёт указание, что эта сеть 192.0.2.0/24 будет доступна. Единственное, что физически пройдёт информация о том, что есть какой-то путь, по которому трафик может пройти, и к нему будет подвязана сеть 192.0.2.0. Путь у нас может быть такой: от нашей автономки трафик пойдёт вот сюда, потом он пойдёт вот так и вот так. Он мог бы, наверное, пойти по такой трассе, мог бы пойти по такой трассе. Но мы принимаем решение, что маршрут идеальный, оптимальный с точки зрения BGP, должен пойти именно так. На самом деле автономка 64500 не видит всего, что происходит внутри этой автономки, внутри этой автономки, внутри этой автономки. И на самом деле она говорит: мы посылаем трафик в эту автономку, мы видим, как у нас сеть устроена, и мы принимаем решение, что из всех вариантов, как добраться до сети 192.0.2.0, самый выгодный способ — направить этот трафик в автономку 64501.

А дальше уже она говорит, что у неё тоже эта сетка есть — 192.0.2.0, и она принимает решение, что самый выгодный способ добраться до этой сети — направить трафик в автономку 64502. А та, в свою очередь, уже говорит, что самый выгодный способ добраться — вот так. Но в любом случае каждый раз, когда оптимальный маршрут будет строиться, мы немножко информации о том, почему мы приняли такое маршрутное решение, рассказываем про свойства выбранного нами лучшего пути своим соседям. Когда в автономке 64502 принимается решение, что самый выгодный способ доставить трафик — это через 64504 пройти, мы рассказываем, что мы посмотрели среди всех возможных вариантов, как дойти до сетки 192.0.2.0, и что это через именно автономку 64504 маршрут проходит. Дальше 64501 тоже из возможных вариантов — либо через 503, либо через 502 — она говорит: самый выгодный вариант это через 502. И соответственно она рассказывает, что самый выгодный вариант через 502, и дальше анонсирует своим соседям.

Ребята, у нас есть выход в сетку, самый лучший, который у нас есть — это по пути с определёнными свойствами. И среди прочего, там как раз рассказывается список автономных систем, через которые проходит путь до удалённой сети. Физически это выглядит так: у нас есть сетка 192.0.2.0, и дальше мы говорим — путь до удалённой сети проходит через автономку 64501, 64502, 64504. И дальше он там зарождается. То, что список автономок мы видим, не означает, что путь с меньшим количеством автономок будет заведомо лучше. Потому что автономка — это просто число. Сколько роутеров, как они соединены и прочее — это никоим образом не раскрывает. Может быть такое, что вся автономка 64501 — это один роутер.

Так получилось, что трафик нашёл, дошёл до роутера автономки 64501 и сразу из него вышел. Просто потому что у нас есть какой-то один border-роутер, который на всех клиентов смотрит и на который же аплинк приходит. А вот эта автономка 64502 — это какой-нибудь условный Ростелеком. И у него тут целая гирлянда роутеров по пути будет. Соответственно, это тоже всё одна и та же автономка, но она намного более сложная. И по внешнему виду номера этой автономной системы непонятно, насколько тяжело пройти эту автономную систему. Или насколько легко, насколько там задержка большая будет, насколько большая полоса пропускания, насколько большие потери. Этого всего BGP не знает. Он говорит: я оперирую терминами автономных систем. И самые важные свойства маршрута — это как раз список автономных систем, через которые проходит путь до удалённой сети. Этот путь будет состоять из номеров автономок, которые будут просто упорядочены. Мы в автономке 64500 будем понимать, что сначала мы должны пустить трафик в автономку 64501.

Та выпустит его в 64502. Та выпустит его в 64504, где префикс и зародился. Кстати, если вы будете рассказывать про эту сетку кому-нибудь ещё, у вас тоже есть какие-то возможные даунлинки, то вы рассказываете, что через вас можно добраться до этой сети. И вы свой номер автономной системы приклеиваете в начало. Поэтому в анонсах в сторону ваших соседей будет указание, что вы знаете, как добраться до удалённой сети. Трафик пойдёт через вас, автономка 64500. Потом выйдет в 64501. Потом в 64502. И потом в 64504. Те, в свою очередь, если тоже будут кому-то анонсировать, будут уже дальше свой номер автономки добавлять. Добавляется свой номер автономки всегда в начало строки. BGP будет, как уже говорилось, использовать TCP. 179-й порт.

Соседей по TCP мы мультикастом обнаруживать не можем. Поэтому надо вручную прописывать соседство. В Cisco есть такая штука, как Dynamic BGP Neighborship. Мы можем автоматически обнаруживать соседей, которые статически прописали нас. Очень интересная штука, например, в DMVPN, когда у вас есть хаб и вы хотите автоматически обнаруживать всех споков. Вы не хотите их вручную прописывать. В этом случае вы говорите: у нас есть облачко DMVPN, и на каждом споке мы вручную прописываем хаба. А на хабе мы говорим: все, кто к нам подключается из определённого диапазона адресов — это все наши хорошие соседи, их надо воспринимать, как будто мы их ручками прописали. Но это именно фирменная Cisco-специфика. В подавляющем большинстве реализаций BGP такого нет. И вы везде должны прописывать соседство ручками. На экзамене тоже нужно говорить, что ручками надо прописывать. Про Dynamic Neighbors там такого нет. BGP будет использовать специальные Keepalive-сообщения для того, чтобы проверять соседство. В OSPF, в EIGRP у нас использовались специальные Hello-пакеты.

И мы, когда от соседа приходили Hello-пакеты, говорили: сосед живой, с ним все хорошо. В RIP у нас не было механизмов Keepalive, но там сами апдейты приходили. Покуда апдейты приходят, мы понимаем — сосед живой. Как только апдейты перестают приходить, мы говорим: Раз апдейты не приходят, значит сосед, который был у нас Next Hop, — труп. Значит мы его выкидываем из таблицы соседей, объявляем его инвалидом. В BGP используется TCP-сессия. И один раз поставили мы сессию, и дальше, если сосед ничего не присылает, у нас есть сомнения. Означает ли это, что сосед ничего нам не присылает, потому что у него ничего не происходит? Или означает ли это, что сосед, например, сдох? Потому что когда у соседа просто питание выключается, он не успевает нам ничего послать. И в TCP штатно никакого Keepalive особо нету. Если сосед ничего нам не присылает и ничего не хотел послать, или если сосед ничего нам не присылает и он сдох и ничего нам не может послать —

это два разных сценария. И мы должны каким-то образом убедиться, что сосед всё ещё живой. И периодически, для того чтобы убедиться в живости соседа, мы должны будем посылать ему специальные сообщения. Мы будем формировать эти самые Keepalive-сообщения внутри BGP-сессии, которые будут по TCP отправляться до соседа. И сам факт того, что вы получаете Acknowledge на сообщение, которое вы отправляете, он будет подтверждать, что сосед живой. Вы отправляете Keepalive, и на него не надо даже отвечать. То, что сосед на уровне TCP-сессии подтвердил, что он получил Keepalive, уже само по себе означает, что соседство у вас живо. Но тем не менее вы отправляете эти Keepalive, получаете Acknowledge и ожидаете эти Keepalive от соседа, для того чтобы он в свою очередь получал подтверждение, что вы всё ещё живы. Так, дальше. Внутри BGP у нас будут передаваться пути. И этот путь будет иметь некий набор атрибутов.

Когда мы говорим, что BGP — это протокол дистанционно-векторный, у каждого пути будет огромный вектор метрик передаваться. Самый важный — это атрибут AS Path. Каждая метрика, каждое свойство маршрута будет называться словом «атрибут» в BGP. И все они вместе называются набор атрибутов пути, или вектор метрик. Вектор метрик — такой универсальный термин. Набор атрибутов — BGP-шный, фирменный термин. Вы будете расставлять разные приоритеты маршрутам. Можно расставить приоритет, например, Local Preference. Это внутри вашей автономной системы. Вы можете сказать, что у нас есть способ добраться до сети такой и есть способ добраться до этой же сети эдакий, и они через разные наборы роутеров проходят. Вы говорите, что один маршрут BGP-шный будет лучше, чем другой. Вы этому маршруту выставляете лучший приоритет. Вы можете проставить приоритеты, на которые вы сами не ориентируетесь,

но ориентируется сосед, которому вы присылаете такие маршруты. Если у вас есть ваша автономная система, автономная система соседа, у вас есть два шнурка, которыми вы отправляете маршруты на два разных роутера соседа, вы должны будете им сказать, что один шнурок хотите использовать, а другой шнурок хотите использовать только в случае резерва, только в случае, если вдруг случится какая-то катастрофа. Потому что за другой шнурок, например, Non-Radio Link. У вас есть основной провод оптический и другой резервный провод радио. И вы хотите сказать: дорогой сосед, пожалуйста, используй радио только в случае крайней необходимости. В этом случае вы можете проставить такой приоритет, который не вы будете читать, а сосед будет читать. Он будет называться Multi-Exit Discriminator, или MED. Но про все эти атрибуты мы потом дальше будем говорить. Ещё один важный атрибут будет Next Hop. Это атрибут — именно свойство маршрута. Когда вы получаете какой-то маршрут, вы с этим атрибутом будете дальше уже работать

и будете в таблицу маршрутизации пытаться добавить маршрут именно с этим Next Hop. Совершенно не факт, что Next Hop, который прописан в апдейте, будет совпадать с тем IP-адресом, от которого вы получили этот маршрут. Вполне может быть такое, что у вас есть несколько роутеров: один роутер, второй роутер, третий роутер. Один другому говорит: посылай трафик через меня. У него, соответственно, IP-адрес 1.1.1.1, и у Next Hop стоит 1.1.1.1. А второй роутер перешлёт этот же апдейт своему соседу и оставит атрибут Next Hop такой же, какой он был. И в таблице маршрутизации этот роутер должен будет направить маршрут на 1.1.1.1. И этот маршрут в таблице маршрутизации должен резолвиться в connected-сетку, которая направит трафик на другой роутер, чтобы тот, в свою очередь, переслал этот трафик дальше. В IGP-протоколах у нас всегда соседство было в пределах канала. В нормальной ситуации Next Hop совпадал с тем, кто прислал нам маршрут.

В BGP это совершенно не так. Более того, чаще всего атрибут Next Hop будет указывать на не-connected-сетку. Так, для того чтобы всё работало, мы должны будем прописать IP-адреса соседей. Для того чтобы понимать, находятся соседи с нами в одной автономке или нет — это будет очень важно для BGP. Мы должны будем сразу же с IP-адресами соседей прописать и номера автономок. И мы будем проверять, что сосед, к которому мы подключаемся, должен будет сказать, в какой автономке он живёт. И если вдруг его автономка не совпадает с тем, что прописано у нас в конфиге, то соседство у нас не установится. Когда у нас устанавливается TCP-сессия для BGP, которая будет необходима, потому что BGP работает поверх TCP, BGP заказывает установление TCP-сессии. Эта сессия поднимается до 179-го порта. И дальше BGP внутри этой сессии будет обмениваться определёнными типами сообщений. Самое первое сообщение будет очень простое.

Оно будет называться Open. В BGP сосед, который посылает сообщение Open, рассказывает про то, как он настроен. Если вы ожидаете устанавливать TCP-сессию с соседом, то вы видите, что идёт сначала SYN-пакет, потом SYN+ACK — обычная TCP-сессия из-под IP-адреса, который у вас прописан. Вы сразу понимаете: IP-адрес 172.16.1.1, это значит роутер с провайдером таким-то. И когда поднимается сессия, вы ожидаете, что роутер соседа пришлёт вам Open-сообщение, в котором он представится. И он, в частности, расскажет про то, как он настроен. И среди прочего он расскажет про свой номер автономной системы. И если вдруг у вас в конфиге прописано, что роутер с таким IP-адресом сидит в одной автономной системе, а он представляется сообщением Open и рассказывает, что он совсем в другой автономной системе, то вы говорите: извини, товарищ, но мы не можем подтвердить, что ты именно тот, с кем мы настроены дружить.

Два роутера посылают друг другу сообщение Open в открытой TCP-сессии. Если всё хорошо, то роутеры считают, что да, замечательно, сессия установлена. Сосед объявляется так называемый Established. И дальше начинается обмен маршрутами. Если вдруг что-то идёт не по плану — либо в течение процедуры передачи Open-сообщения, либо в процедуре потом уже нормальной работы — у вас возникает какое-то сомнение в корректности установленной сессии, что с соседом что-то не так. Либо он начинает вам присылать какие-то совсем левые маршруты, и вы хотите его забанить. Либо вы хотите сказать, что у него номер автономки не тот, с которым вы можете дружить. Либо, например, вы хотите сказать, что вы собираетесь перезагрузиться, поэтому вам нужно погасить TCP-сессию, поверх которой BGP работает. В любом случае последнее предсмертное сообщение будет называться сообщение Notification. Звучит как будто какое-то уведомление,

что мы хотим соседа чем-то уведомить. Ничего страшного, казалось бы. Но это на самом деле предсмертная агония. Сессия открывается всегда сообщением Open и закрывается сообщением Notification. Это сообщение о том, что всё, это конец. Дальше ничего не передаётся после Notification. Про Keepalive всё понятно. Они периодически бегают по таймеру. И если у нас ничего нету того, что мы хотели бы в рамках типичной сессии передать, но мы хотим убедиться, что сосед живой, мы передаём Keepalive. И от соседа тоже эти самые Keepalive периодически ожидаем. Когда у нас возникает желание отправить соседу какую-нибудь ценную, полезную информацию, для этого у нас есть сообщение типа Update. Всего четыре типа сообщений. Меньше, чем в OSPF, меньше, чем в EIGRP. Ладно, не меньше, чем в RIP. В RIP всего один апдейт. Соответственно, сообщение Open открывает сессию, Notification закрывает, Keepalive ничего не делает — только служит для того, чтобы сессия не поломалась. А Update передаёт, собственно, мясо.

BGP, когда будет передавать маршруты, может передавать маршруты роутерам в своей или в чужой автономной системе. Протокол BGP ориентирован на то, чтобы работать между автономками. Но внутри конкретной автономной системы может быть ситуация, когда у нас есть два роутера и они находятся в одной автономной системе. Здесь рядышком другая автономка, здесь какая-то третья. Здесь используется BGP, здесь используется BGP. Но BGP должен использоваться и между нашими роутерами тоже, чтобы реплицировать таблицы маршрутизации на роутерах R1 и R2, чтобы маршруты, полученные из одной автономной системы, пошли в другую автономную систему. И у нас получится, что маршруты передаются через нашу автономку. Для того чтобы это работало, нам нужно роутеры R1 и R2 тоже связать по BGP. Из того, что BGP — это EGP-протокол, который умеет работать между разными автономками, не следует, что обязательно любые два роутера, которые дружат по BGP, обязаны быть в разных автономках.

Они могут быть в одной и той же автономной системе. Вот пример того, как у нас роутеры могут быть. Они могут быть в разных автономках, и тогда здесь всё понятно. Действительно, здесь BGP нужно использовать, потому что роутеры в разных автономных системах, они друг другу не доверяют. И роутеры в одной автономной системе. Здесь не совсем очевидно, может быть, почему надо использовать BGP. Для того чтобы маршруты, полученные по BGP здесь, и маршруты, полученные по BGP здесь, не остались двумя разомкнутыми частями BGP, надо эти два BGP-куска соединить в один. Здесь тоже надо запустить BGP, даже несмотря на то, что это роутеры внутри одной автономки. Если у вас сосед действительно по-честному из другой автономной системы, BGP в этом случае напрягается максимально. Он говорит: я сейчас буду политикой проверять маршруты, которые ко мне приходят. Бьёт себя пяткой в грудь, говорит: я не пропущу ничего. Товарищ Сухов мимо нас не пролетит и муху не пронесёт.

И сценарий, при котором у вас есть сосед в чужой автономной системе, будет называться EBGP. Вы всегда знаете с каждым соседом, находится ли он в чужой автономке или нет, потому что вы знаете номер своей автономной системы, и вы на каждого соседа прописываете IP-адрес соседа и его автономную систему. Если вы видите в конфиге, что у вас автономка сотая, а у соседа автономка двухсотая, то когда идёт попытка подключения из-под IP-адреса, прописанного на соседа, вы понимаете, что этот сосед из чужой автономки, с ним надо держать ухо востро. Этот сценарий, когда сосед в чужой автономке, называется EBGP — Exterior BGP. Но это не какой-то специальный отдельный протокол, это режим работы BGP, при котором BGP полностью напряжён и полностью старается не пропустить ничего лишнего. Сценарий, при котором два роутера находятся под вашим началом и настроены вами, будет называться IBGP. Они находятся в одной автономной системе. Между ними используется тот же самый BGP, что и в случае с EBGP,

но IBGP означает, что роутеры в одной автономке, и они друг другу в какой-то степени могут доверять. А что значит доверять с точки зрения BGP? Это значит, что некоторые проверки можно не выполнять, когда роутер R1 посылает маршруты на роутер R2. В этой ситуации, зная, что роутер R1 уже проверил все маршруты, R2 может сказать: я чуть-чуть, капелюшечку R1 доверяю. Всем остальным не доверяю совсем, а ему доверяю. Он в моей автономке. И поэтому IBGP-взаимодействие с точки зрения настроек безопасности чуточку более расслабленное, чуточку более доверительное. Это именно разные режимы работы одного и того же протокола. В одном случае мы полностью напрягаем булки, в другом случае мы говорим: а, это Вася. Он уже сам проверил всё, что нужно, и нам присылает только те маршруты, которые прошли проверку. Пожалуйста, не думайте, что EBGP и IBGP — это какие-то разные протоколы

или они предназначены для работы один в EGP, другой в IGP. Нет. IBGP и IGP — семейство протоколов — это очень разные вещи, пожалуйста, не путайте их. Это один и тот же протокол BGP, созданный для решения задач EGP, но у него просто два режима работы. У EBGP есть… Exterior BGP, да. Есть некоторые предпосылки к тому, что два роутера будут дружить по EBGP. Это роутеры, как правило, на границе нашей автономной системы. У нас есть какая-то автономная система, у неё на границе находится наш роутер. У соседа тоже есть какая-то своя автономная система, там может быть много роутеров, но мы дружим не с кем попало, а с роутером, который находится на границе автономных систем.

И наш пограничный роутер, border router, его пограничный роутер, border router, дружат между собой, и у нас прямой канал между ними. Потому что если здесь есть транзитный роутер, то это роутер кому-то принадлежащий. Он принадлежит либо нам, либо им, и у нас получается, что граница на самом деле должна быть где-то здесь. И получится, что мы не из border router строим эту EBGP-связь, а с кого-то ещё. EBGP предполагает, что связь с соседом строится именно с пограничного роутера. И для этого выполняются определённые проверки, в том числе проверки по TTL. Пакеты, которые вы отправляете, они отправляются по умолчанию с TTL равным единице в EBGP-связи. И если здесь транзитный роутер будет, то TCP-сессия у вас просто не установится. Потому что транзитный роутер будет видеть, что TTL единица, и все пакеты, которые с TTL 0 после маршрутизации будут получаться, он их просто будет выкидывать.

Альтернативный вариант — вы можете включить такую штуку, как TTL Security. Вы можете отправлять пакеты с TTL 255 и ожидать пакеты с TTL 255. Потому что пакеты, которые будут приходить с другим TTL, не 255, это значит, что они прошли через какие-то роутеры. Но это опциональная вещь. Она нужна для того, чтобы убедиться, что то, что вы отправляете с TTL единица, оно могло бы быть перехвачено. А то, что вам кто-то пытается вбросить какие-то левые пакеты — он может это сделать, только имея роутер-отправитель или BGP-сервис отправителя непосредственно в одном канале с вами. С помощью TTL, например, можно будет убедиться, что маршруты приходят от роутера, который находится в одном канале с нами. Поэтому мы говорим, что когда маршруты приходят от кого-то, кто находится в одном канале с нами, мы можем ожидать, что никого здесь между нами не будет. Если у нас есть полная картина интернета,

полный BGP Full View здесь, и есть полная картина BGP Full View, полная картина всего интернета здесь, то при отправке пакетов на канал в сторону соседнего роутера мы понимаем, что любые пакеты, которые идут в сторону интернета, они до интернета в итоге дойдут, что они нигде не потеряются. Потому что если здесь был бы какой-то ещё один роутер, мы бы, устанавливая BGP-соседство между двумя роутерами, которые BGP поддерживают, не знали бы ничего про этот транзитный роутер, и у него в таблице маршрутизации непонятно, что бы творилось. Если мы отправляем пакеты в канал, соответственно, у него, если нет полной таблицы интернета, он часть пакетов будет терять. Поэтому BGP в E-BGP-шном взаимодействии предполагает, что у нас есть прямое подключение роутеров друг к другу, что роутер один на границе автономной системы подключается к роутеру в другой автономной системе, тоже на границе автономной системы. Оба роутера должны быть в одном канале. Отправитель маршрутов, когда посылает апдейт, модифицирует атрибуты при отправке по E-BGP-шному соседству.

В первую очередь добавляет в ASPath, в список автономных систем, через которые проходит маршрут, свой номер автономной системы. Если, допустим, у нас есть роутер R1, и он говорит, что я получаю какие-то маршруты по E-BGP, здесь номера автономок 65000 сотая, 65000 ровно, 650001, 650002. Он в этом случае, пересылая такой апдейт дальше в сторону роутера R2, добавляет в начало свою автономку. Он говорит, я тебе отправлю маршрут, который проходит через сотую автономку, потом прыгает в 65000, потом в 650001, потом в 650002. Свой номер автономки E-BGP-шный отправитель дописывает в начало атрибута ASPath. Кроме того, он проставляет атрибут NextHop, потому что роутер, который получит такой маршрут, может пакет кинуть напрямую на тот IP-шник, с которого идёт дружба, которая находится с ним в одном канале. Как раз идеальный здесь был бы вариант,

при котором NextHop совпадал бы с тем адресом, из-под которого пришёл маршрут. Это то поведение, которое мы наблюдали в OSPF, в EIGRP, в RIP и так далее, когда приходит какой-то маршрут от соседа, и мы IP-шник соседа считаем NextHop. В E-BGP это поведение по умолчанию. Там есть ещё некоторые особенности, но эти две — наиболее важные, что у нас атрибуты модифицируются: ASPath модифицируется, NextHop модифицируется. В случае с IBGP у нас ситуация будет хуже, потому что, если у нас есть роутеры, которые находятся внутри автономной системы, то у нас может быть такое, что соседство внутри автономки происходит между роутерами, которые не соединены прямым проводом. В E-BGP мы соединяемся прямым проводом, потому что роутеры на границе автономок, у них прямой провод действительно есть. Внутри автономной системы у вас может быть гирлянда между двумя роутерами, и, соответственно, мы должны будем пириться между всеми-всеми роутерами.

Внутри автономной системы вам требуется так называемый full mesh соседство. У нас роутер R1 должен попириться с R3, с R2, R2 должен попириться с R3, и получается, что у нас, если три роутера, должно быть три пары соседств. Если там четыре роутера, это будет уже шесть пар соседств. И много начинает появляться соседств, если у вас роутеров много. Это действительно иногда вызывает проблемы. В случае с очень большими сетями есть костыли, как эту штуку обойти, но, в целом, внутри автономной системы, если у вас много роутеров, то вам придётся прописывать много-много-много-много-много соседств. Почему такая штука требуется? Почему нужно прописывать всех соседей в случае с IBGP? Дело в том, что при отправке IBGP-шному соседу маршрутов атрибуты не модифицируются. И, соответственно, не модифицируется атрибут ASPath. Поэтому не модифицируется ASPath, не модифицируется NextHop.

Поэтому у вас может случиться петля, при которой R1 скажет, что я могу добраться до какой-то сетки, которая ко мне пришла. Он отправит это указание R2, тот отправит R3. R3 скажет, я могу добраться до какой-то сетки и расскажет про это R1. Потом R1 про это перестаёт знать, и у нас получается петля. Поэтому роутеры, которые по IBGP-связи получают какие-то маршруты, они их другим IBGP-шным роутерам не отдают. Если есть полносвязные взаимодействия, то тот роутер, который получает какой-то внешний маршрут, он про этот маршрут рассказывает вообще всем, кому он непосредственно подключён. Поэтому, если у нас есть какой-то роутер, к которому подключён исходный отправитель маршрута, то, соответственно, он этот маршрут получит. Если есть какой-то роутер, который не получает такой маршрут, то это проблема этого роутера. Мы в любом случае от IBGP-шных соседей маршруты полученные другим IBGP-шным соседям не отдаём.

Требуется полносвязное соседство, и сразу возникает вопрос: если нам нужно R1 и R3 связать по BGP, как мы это сделаем? Потому что нам нужно знать IP-шники этих роутеров. Более того, эти IP-шники не должны быть прописаны каким-то статическим образом. Если у нас просто гирлянда, здесь всё просто. А представьте себе, что у нас есть какая-то топология, типа кольцо. И у нас есть вариант, как добраться от R1 до R3. У нас есть вариант пойти вот так, либо пойти в обход. У нас получается как минимум два IP-шника, на которые можно подключаться. И что будет, если, например, мы скажем, давайте подключаться на тот, который в норме ближе. А потом интерфейс, на котором этот IP-шник висит, дохнет. IP-шник сам дохнет в этом случае. Мы должны будем переподключиться, но мы не хотим прописывать два разных соседства. Мы хотим в этом случае дружить, как правило, по лупбекам. Мы поднимаем виртуальные интерфейсы и дружим через них. И соседства все устанавливаем через них. Но опять же, возникает вопрос, а где эти лупбеки взять в таблице маршрутизации? Поэтому чаще всего,

если у нас есть BGP с IBGP взаимодействием, то рядышком с ним работает какой-то IGP протокол. Например, OSPF. У вас OSPF поднимает связи, обнаруживает всех соседей автоматически, принимает лупбеки всех роутеров. Дальше, внутри автономной системы, вы через эти самые лупбеки дружите уже полносвязную топологию вручную. И в этой ситуации BGP у нас работает в связке с IGP. IGP ответственен за построение кратчайших путей, BGP ответственен за протягивание маршрутов. Если у нас есть IBGP, то, как уже говорилось, при отправке маршрутов IBGP-шному соседу атрибуты маршрута не меняются. Мы принимаем какой-то апдейт снаружи. Вот у нас есть роутер R1. Он рассказывает, что у него есть сетка 203.0.13.0. Он присылает апдейт роутеру R2. Поскольку это EBGP-шная связь, то, соответственно, атрибуты меняются. У нас там проставляется атрибут ASPath

и у нас проставляется атрибут NextHop. И R1 говорит, если ты хочешь ходить до этой сетки через меня, то направляй трафик мне на IP-шник. Они дружат между собой через 10.001 сетку на 10.001 отправляй мне пакеты. То есть пропиши себе в таблицу маршрутизации NextHop для этой сетки 10.001. R2 говорит, окей, я в таблицу маршрутизации прописал. Если что, я буду посылать трафик на этот IP-шник. Но дальше возникает вопрос. Вот когда мы IBGP-шному соседу рассказываем про эту сетку, мы не меняем атрибуты по умолчанию. И, соответственно, атрибут у нас остается 10.001 NextHop. И R3 для того, чтобы добраться до какой-то внешней сети 203.0.113.1 должен поставить NextHop в таблицу маршрутизации вот этот вот IP-шник. Он принимает такой апдейт, смотрит на атрибут NextHop, говорит, что за херня. У меня нет в таблице маршрутизации такого IP-шника. И это как бы действительно такая достаточно популярная штука. Так или иначе

ее решать надо всем, кто работает с IBGP. Если у вас есть IBGP-шные соседи, то NextHop от других автономных систем, которые приходят, вот вы должны будете знать. Вы должны будете либо в какой-нибудь условный OSPF, который у вас здесь рядышком работает, запихать вот эту вот сетку, либо вы должны будете поменять адрес NextHop перед отправкой маршрута IBGP-шным соседям. То есть оба варианта довольно популярны. Либо импортируем адреса IBGP-шных соседей в OSPF, либо меняем атрибут NextHop. То есть говорим, да, в нормальной ситуации не меняем, но вот именно этой ситуации мы меняем и говорим, что у нас здесь, допустим, отправляй трафик мне 112, 168, 168, 0, 1, NextHop должен быть. И тогда такой маршрут уже может быть добавлен в таблицу маршрутизации. Так, далее. Если у нас есть IBGP-шные соседства,

то возникает вопрос, как мы будем дружиться. Вот я уже рассказал, на самом деле, что для того, чтобы не зависеть от каких-то физических IP-шников, которые зависят от физических интерфейсов, есть роутер R1 и R3. У них, например, два интерфейса есть. То есть каждый интерфейс это отдельный IP-шник и возникает вопрос. Вот R3 и R1 должны между собой подружиться, какие IP-шники им использовать. Если R1 скажет, у меня есть сосед R3, то он должен прописать адрес. Вот он может прописать 10.0.113.1 или там 3. 10.0.213.3. Какой адрес им использовать? Вот в этой ситуации поднимаются лупбеки. Эти лупбеки запихиваются в OSPF. У нас OSPF протаскивает и вот эти сети все, и вот эти, и самое главное, пропихивает лупбеки. И дальше связи мы строим уже через лупбеки. Лупбеки анонсируется в OSPF. OSPF протаскивает эти лупбеки, строит маршруты до них наивыгодным образом. Он это делает профессионально. Это linkstate протокол, и он очень небольшое количество маршрутов может в пределах топологии

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

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

когда в разных автономных системах у нас есть два роутера, оба роутера пограничники, и они хотят дружить между собой через два интерфейса. Вот в этом случае можно прописать либо два соседства, но это на самом деле достаточно неплохая такая нагрузка будет на роутеры, либо можно сказать, опять же, давайте поднимем loopback'и, и дальше связь по loopback'ам организуем. Когда у нас loopback'и эти будут синхронизированы между собой, вот в этом случае мы ставим одну сессию на роутеры, дальше мы говорим ставь nexthop'ом в таблицу маршрутизации айпишник моего loopback'а и дальше сделай так, чтобы в таблице маршрутизации айпишник был известен из двух разных проводов, чтобы у тебя балансировка на уровне CF'а шла и вот R2 в сторону loopback'а nexthop'а трафик посылал под обоим проводом одновременно. Вот эта вот штука, она, соответственно, будет предполагать, что у вас сессия строится из-под loopback'ов, но есть нюанс. Если мы используем оборудование циска, то в этой ситуации

проблема будет вот какого характера. Роутер R1 посылает пакет с TTL-ом единичка. Он посылает со своего loopback'а на адрес loopback'а R2. Такой пакет доходит по какому-то проводу до роутера R2. Вот в тот момент, когда этот пакет приземляется на роутер R2, чип первым делом проверяет, какой там TTL. Если там TTL-1, то сам интерфейс проверяет, не мой ли IP-шник в качестве получателя там указан. Если мой, он сразу направляет пакет на процессор, он не отправляет его на таблицу с маршрутизацией. Если там какой-то другой IP-шник, отличающийся от IP-шника на самом интерфейсе, такой пакет сразу убивается. Это поведение циски, но на самом деле многие роутеры себя подобным образом ведут. Если бы там был TTL какой-нибудь другой, не единичка, то в этой ситуации мы бы его направили на движок маршрутизации, тот бы поискал выходной интерфейс,

вычел бы TTL-1 и, соответственно, обработал бы. Ну вот по факту, да, TTL можно считать, что сначала идет проверка, нашли IP-шник получателя, потом убирается TTL, проверяется, что TTL не 0, не 0, и после этого только запускается движок маршрутизации. Вот в ситуации, когда у вас связь идет по лупбекам и пакеты отправляются с TTL-1, пакеты приходят на физический интерфейс роутера R2, а IP-шник получателя не совпадает с физическим интерфейсом роутера R2, и такие пакеты убиваются. Для того, чтобы это сделать, вам нужно отправлять пакеты с TTL-2, или тройкой, чтобы пакет прошел через фильтр, пакет дошел до движка маршрутизации, он обнаружил, что выходной интерфейс это наш собственный лупбек, я направил бы трафик на процессор на то, чтобы он этот пакет прочитал. Это, скажем, достаточно характерная особенность для многих роутеров,

что реализация проверки на TTL устроена вот таким вот образом. Вы должны будете использовать настройку, которая позволит вашему роутеру R1 отправлять пакеты с TTL-2, не единичка. В целом, она называется EBGP Multihop. Если говорить про ЦИСКу, то вы, как правило, когда прописываете EBGP Multihop, указываете, с каким именно TTL-ем можно будет отправлять пакеты. Вот, ну, например, вы скажете там EBGP Multihop 2, значит, вы отправляете пакеты с TTL-ем двойкой. Штатно не проверяется, какой TTL будет у вас. То есть, достаточно, чтобы он просто был, ну, чтобы он был хотя бы какой-то такой, чтобы пакеты дошли до вашего роутера. Но будет ли он единичка, или будет ли он двойка, или будет ли он семерка, или будет ли он 254, роутер, получатель, в общем, все равно. Если вам не все равно, какой будет TTL на получателе, то в этом случае вы можете включить фичу, которая называется TTL Security. Включается она только с обеих сторон. И заключается она в том, что вы отправляете пакеты

всегда с TTL-ем 255. TTL-255. И если вы отправляете пакеты с TTL-ем 255, и вы дружите по физическим IP-шникам, то в этом случае получатель роутер, получателя, обязательно ожидает, что получение пакетов тоже будет с TTL-255. И это, если вдруг пакеты приходят с TTL-ем, например, 254, 253 и так далее, то это нарушение безопасности. Это означает, что роутер находится дальше, чем в одном канале с нами. Гарантированно. Если, соответственно, мы говорим, что мы дружим по лупбекам, и мы включаем TTL Security, то мы все равно отправляем пакеты с TTL-255. Больше нельзя. А дальше мы говорим, что вот у нас есть лупбек, и мы разрешаем принимать пакеты с TTL-ем, например, 254 на этом лупбеке. То есть, мы получаем какой-то пакет, направляем его на таблицу маршрутизации, та вычитает копеечку, посылает данные на лупбек, и мы говорим, да, вот TTL Security с TTL-ем 254

это все еще не нарушение безопасности на прием. То есть, EBGP Multihop позволяет вам указывать в исходящих пакетах TTL-е отличные от единички. Прием штатно пакетов осуществляется с любимым TTL-ем. Если вы хотите защититься от того, чтобы кто-то вам вбросил какие-то левые пакеты, вы можете включить фичу TTL Security, тогда отправляться пакета бот с TTL-ем всегда 255, а приниматься с каким скажете. В принципе, во многих механизмах, во многих протоколах это такая вот защита есть, она называется Generalized TTL Security механизм, есть отдельный стандарт на то, как она реализуется. То есть, не только в BGP это есть, это можно в том же самом SPF включить. Ну, соответственно, да, надо включать с обеих сторон. Дальше. Когда у нас есть два роутера, будет ли это eBGP-шная связь с Multihop или Бизонова, будет ли это iBGP-шная связь по лупбэкам или по физическим IP-шникам.

В любом случае, у нас есть роутер соседа, который, IP-шник, которого мы знаем, автономка, которого мы знаем. Мы еще с ним, может быть, не дружим. То есть, мы только что включились, мы еще ни с кем не установили соседские отношения, но мы уже знаем, с кем мы собираемся подружиться. И в такой ситуации у нас есть табличка соседей, и каждый сосед находится в определенном состоянии. Начинается все с того, что соседи все находятся в состоянии idle, что мы не пытаемся установить соседство. Либо нет маршрута, либо мы его забанили, потому что он нам не понравился, либо еще какая-то фигня. То есть, мы не то, что не пытаемся, а мы активно не хотим устанавливать соседство с этим соседом. Если вдруг сравнивать с SPF, то это будет состояние down. То самое состояние, когда IP-шник соседа мы знаем, но мы даже не пытаемся ничего делать для того, чтобы подключиться к нему. Дальше состояние active будет означать, что мы отправили

TCP-syn пакет, но мы пытаемся с ним установить соседские отношения, мы отправили TCP-syn для установления TCP-шной сессии, но нам не пришел правильный, корректный акт. Это, в принципе, состояние attempt. Мы попытаемся подружиться с соседом, но сосед нам вообще ничего не отвечает. То есть, никаких ни hello, ничего. Вот в SPF attempt будет означать, что у нас есть маршрут до IP-шника соседа, но мы не можем вообще ничего с ним сделать. Вот мы отправляем ему сообщение hello и ничего от него не принимаем. Вот в BGP это active. Мы отправляем syn и ничего от него не получаем. Даже syn плюс акт. Connect. третье состояние будет означать, что мы получили от него syn и отправили ему syn плюс акт и ждем конкретный акт. Корректный акт для него. То есть, напоминаю, что TCP-шная сессия у нас ставится. Сначала один роутер посылает syn флаг, потом ответный флаг идет syn плюс акт

и третий, соответственно, акт. Это вот трехэтапный только пожатие три-вэй-хэнд-шэйк. В active мы отправили syn и ждем syn плюс акт. Syn плюс акт. В случае, соответственно, с Connect мы получили syn и отправили syn плюс акт и ждем ответный акт. Третье. Вот в этом состоянии у нас вот этот вот роутер отправил syn плюс акт и ждет акт от соседа. Если у вас почему-то роутер висит в состоянии Connect, то это очень странно. Значит, он вам прислал syn, но не видит от вас акки ваши. Дальше. OpenSend состояние, при котором вы установили сессию, отправили Open, но если вы видите, что сессия у вас долго висит в OpenSend, это может быть, например, происходить, потому что вы подключились на 179 порт

к соседу, отправили ему Open, а там что-то кроме BGP на 179 порту другое висит. Ну, не просто кроме, вместо 179 порта слушает не BGP, а, не знаю, телнет. Вот какой-то урод повесил телнет на 179 порт. В этом случае вы поднимаете сессию, у вас флаги syn, акт нормально проходят, вы отправляете сообщение Open, и там сосед не понимает, что с ним делать. Он вам ответный Open не посылает. Вот, вы отправили Open и не получаете в ответ ничего. Это будет состояние OpenSend. В нормальной ситуации, естественно, на Open ваше должно прийти практически немедленно Open соседское. И вот если вы отправили Open, получили Open, ну да, Если вы получили, то вы наверняка его отправили. И дальше нужно дождаться хотя бы одного Keepalive. Это нормальное взаимодействие, как только первый Keepalive получите, у вас состояние перейдет в Established.

Естественно, что Open Confirm это такое чисто техническое состояние, которое в нормальной сети наблюдаться долго не должно. Вы проверили, что там TCP-шная сессия есть, что IP-шник соседа отвечает, что там с той стороны сосед, этот сосед BGP-шный, настроен он именно так, как мы ожидаем. Нет ни одной причины, почему мы не можем получить Keepalive. Поэтому OpenSent это может быть стабильное состояние, сравнительно стабильное состояние, потому что там вместо BGP слушает условный TELNET. Connect может быть такое стабильное состояние, если у нас не проходят наши пакеты в сторону соседа, но наоборот от соседа к нам приходят, если у нас, например, односторонний отказ оптики есть. Active. Очень частая штука, что мы посылаем SYN-пакеты соседу, а сосед молчит. Если у вас либо сосед неправильно прописан, либо что-то еще, нормальный Active часто будет встречаться, с соседом просто нет связи. Idle тоже, соответственно, редко

можно будет встретить. Если мы попытались установить соседство, он повисел немножко в Active и отвалился в Idle, чтобы потом снова немножко повисеть в Active. OpenConfirm редко встречается в реальной сети, потому что это сугубо техническое состояние. Такого, чтобы у нас TCP-шная сессия поставилась, Open'ами обменялись мы, а дальше Keepalive не проходит, это редкость. И наконец, Established. Это значит, что все в порядке, соседство установлено, Open'ами мы обменялись, Keepalive прошли, хотя бы одни, и, соответственно, мы можем направлять апдейты и можем знать, что с соседом все в порядке. Если соседство не устанавливается, это может происходить по следующим причинам. Первое. Мы неправильно прописали IP-шник соседа. Если у нас есть роутер и второй роутер, и мы связаны между собой, допустим, даже прямым проводом, и у нас вот здесь IP-шник 10.0.0.1, а здесь у нас IP-шник 10.0.0.2, и мы прописываем соседство

и говорим, что соседом у нас будет там 10.0.0.12. Мы смотрим совершенно не туда, мы посылаем такие пакеты, которые позволят нам установиться с IP-шником 10.0.0.12. В сети такого нету. Естественно, что у нас этот сосед не сможет установиться. В то же время у нас не сможет установиться равный 10.0.0.2. Он-то нам пакеты будет присылать из-под IP-шника 10.0.0.2, который у нас не прописан в табличке соседей. Поэтому мы его пакеты будем совершенно смело сбрасывать. И у нас соседство, естественно, не установится. Может быть такое, что вы неправильно пропишете IP-шник источника. И это на самом деле очень интересная штука. Может быть такое, что у вас 10.0.0.1, 10.0.0.2 физические IP-шники есть. Рядышком есть еще другие интерфейсы. Там 10.0.1.1, 10.0.1.2. Два провода, два физических интерфейса. И есть лупбеки. И мы, соответственно, в лупбеках будем ставить 192.168.0.1.

Здесь тоже лупбек. 192.168.0.2. И мы прописываем соседа. Вот здесь. Прописываем, что сосед у нас будет 192.168.0.2. Вроде все хорошо, вроде все правильно. Прописываем IP-шник соседа. Здесь прописываем IP-шник соседа. Тут 192.168.0.1. Все замечательно? Нет. Не замечательно это потому, что вы при попытке установить соседские отношения с IP-шником 192.168.0.2, пакеты будете направлять по одному из физических интерфейсов. И для TCP-шной сессии вы будете выбирать IP-шник источника. Один из вот этих. Либо 10.0.0.1, либо 10.0.1.1. И вы сессию будете ставить с правильным адресом из-под неправильного адреса. Эти адреса у вас не прописаны в табличке соседей. Вы думаете, что вы сейчас будете дружить на лупбеках, но вы из-под лупбеков не дружите. Вы дружите с физических

IP-шников, пытаетесь установить TCP-шную сессию, в качестве адреса источника указываете адрес, который там случайно подставился. И он у вас в табличке соседей не прописан. Сосед, который будет получать пакеты на адрес 192.168.0.2, он их ожидает получать из-под IP-шника, который прописан в качестве соседа. 192.168.0.1. И вам нужно правильно прописать IP-шник источника. Вы должны будете указать, что пакеты отправляются с адреса лупбека на адрес лупбека. Не доверяйте стандартному выбору адреса источника, который автоматически вам подберет физические IP-шники. Может быть такое, что вы пропишете, что сосед, у нас вот здесь 65001 автономка, 65002. И вы скажете, что у вас сосед 192.168.0.2 в 65001 автономке. И когда Open сообщение, сессия поставится, вопросов нет, дальше Open сообщение проходит, и номер автономки здесь, номер автономки, заявленный в сообщении Open, совпадать не будут.

Вот в этой ситуации у вас соседство немедленно перейдет в Idle, и потом, через некоторое время, попытается переустановиться. Open принимается только с правильных IP-шников и только с правильных номеров автономных систем. Если вдруг сосед заявляет, что IP-шник у него другой или номер автономки другой, вы с ним дружить не будете. Давайте попробуем базово поднять BGP на...