BGP

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

но классические протоколы IGP, то есть OSPF и EIGRP, для этого не подходят. Роутеры в пределах своей автономной системы безусловно доверяют соседям. Когда сосед присылает какой-то маршрут, этот маршрут ставится в таблицу маршрутизации без каких-либо сомнений. Дальше следующим соседям информация, которую прислал нам сосед, передаётся без изменений. В то же время при передаче данных между автономными системами может быть ситуация, при которой соседний роутер прислал нам маршрут, и мы этому маршруту не верим. Это нормально. Например, если мы подключаемся к нашему провайдеру, провайдер согласен с нами обмениваться маршрутами динамически, и он рассказывает нам, что знает, как добраться до сети 192.168.1.0, которая у нас используется где-то в сети управления, например. Никогда так не делаете? Ну, гипотетически. И он говорит: для того чтобы добраться до сети управления, посылай трафик мне, а я дальше разберусь. Понятное дело, мы этому верить ни в коем случае не должны. Если мы отправляем трафик нашему провайдеру, мы ожидаем,

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

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

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

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

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

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

заведомо знают адреса друг друга до того, как они устанавливают соседские взаимоотношения, то TCP использовать никаких проблем не составляет. Опять же, крайне редко в BGP будет ситуация такая, что у нас в одном канале будет несколько роутеров. В IGP это норма. Когда у нас есть несколько роутеров в пределах одного канала, и они автоматически обнаруживают друг друга, и автоматически друг с другом реплицируют свои таблицы маршрутизации. При этом они активно используют мультикаст. В BGP всё взаимодействие идёт, как правило, юникастом. TCP может работать только по юникасту, тут всё просто. Используется 179-й порт, и если вы подключаетесь к своему провайдеру, вы должны будете не забыть этот самый 179-й порт разрешить. Иначе, если у вас будет прописан access-list, который висит на выход в интернет или на вход из интернета, вы рискуете, что этот access-list

не пропустит трафик TCP на 179-й порт на IP-адрес самого роутера. Не предполагается, что вы настраиваете совершенно новые подключения BGP в рамках этого курса, а в рамках тех курсов, где мы настраиваем BGP с нуля, там это, конечно, будет обязательно указано. У BGP есть одна большая задача, великая миссия, если хотите. По сравнению с OSPF и EIGRP, у которых такие миссии тоже есть, и они предназначены для максимально быстрой работы, BGP никоим образом не стремится работать быстро. Он работает масштабируемо и безопасно. Безопасно и масштабируемо. Если у OSPF есть задача как можно быстрее среплицировать таблицы, а EIGRP говорит: а я ещё быстрее буду реплицировать таблицы маршрутизации, то BGP говорит: подождите, подождите. Когда вы реплицируете быстро 10, 100 маршрутов, тысячу маршрутов, вы это можете делать быстро. А когда речь идёт про миллион маршрутов таблицы маршрутизации,

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

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

который дал нам первый провайдер. И в случае, если у нас откажет канал до первого провайдера, мы можем сказать: давайте пустим трафик через второго провайдера. Но в эти IP-адреса мы NAT-ить уже право не имеем. Такое подключение, такие пакеты — мы должны будем NAT-ить их в эти IP-адреса. И получается, что у нас так не работает, что мы не можем взять и на лету с сохранением всей сессии поменять внезапно IP-адреса. Потому что узлы, которые будут в интернете находиться, они будут получать пакеты с двух разных адресов. Для того чтобы этого не происходило, вы можете взять и использовать провайдеронезависимые адреса. Эта аббревиатура PI-IP — это не шутка. Иногда бывает такое: PI-адреса. PI-адреса — это provider-independent адреса. Они не принадлежат провайдеру. Вы напрямую их получаете. И вы можете пользоваться ими где угодно, с каким угодно провайдером. Но вам нужно будет каким-то образом анонсировать их через вашего провайдера.

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

позволяет подключиться к двум провайдерам и анонсировать им ваши публичные адреса, которые у вас имеются. Для того чтобы это всё работало, вам нужно будет иметь эти самые PI-адреса, provider-independent адреса, то есть те сети, которые у вас будут анонсироваться. Задача BGP — это чаще всего, если мы говорим про предприятие, анонсировать своему провайдеру некие сетки. В принципе, если бы вы были сами провайдером в BGP, ещё нужно было бы понять, какие сети вы согласны принимать. В случае же, если мы говорим про обычную сеть предприятия, как правило, мы принимаем либо всё, что нам присылает сосед-провайдер, но при этом говорим «много лишнего не присылай», либо мы просто в явном виде говорим, что присылай нам только маршрут по умолчанию, что все сети в интернете доступны через провайдерский роутер. Здесь есть несколько нюансов, но мы в эти нюансы сейчас углубляться не будем. Второй момент заключается в том,

что помимо тех IP-адресов, которые вы должны будете анонсировать, вам нужно будет указать, что эти IP-адреса именно ваши. И для того чтобы у вас был какой-то идентификатор, вам нужно будет также заиметь номер автономной системы. Это просто число, которое зафиксировано именно за вами. Так же, как IP-адреса — это просто число, только эти IP-адреса принадлежат разным узлам под вашим контролем. Номер автономной системы указывает именно на вашу сеть, если хотите, на вашу неразрывную область влияния. И по сути своей он получается так же, как и IP-адреса. Вы идёте к своему любимому региональному регистратору, в случае с Европой это RIPE, и говорите, что вам нужны IP-адреса и вам нужен номер автономки. Автономную систему получить намного проще, чем IP-адреса, фактически это просто номер. Вы платите за него какую-то небольшую сумму,

и дальше он в вашем распоряжении. IP-адреса — существенно более дорогая штука, если вдруг вы захотите их иметь, то вам нужно будет, если говорить про получение именно PI-адресов или чего-то очень похожего на них, вы должны будете получить спонсорство LIR-а, спонсорство большого провайдера, который скажет, что он действительно согласен с вами дружить по BGP, он действительно согласен следить за тем, что вы всё правильно делаете. В общем, с адресами всё несколько сложнее, чем с номером автономки. Помимо того, что вы должны будете купить эти самые номера автономных систем и IP-адреса, вам нужно будет ещё договориться с двумя провайдерами о том, что вы будете с ними действительно дружить. Во-первых, вы должны будете знать адреса маршрутизаторов провайдера, с которыми вы будете дружить, и вы должны будете знать номера их автономных систем. При установлении BGP-сессии вы должны будете указать,

с каким IP-адресом вы дружите и какой у него будет номер автономной системы. Если не укажете правильно, то дружба не получится. В роутерах Cisco для того, чтобы запустить процесс BGP, если мы говорим про операционную систему Cisco IOS, вы можете на одном роутере запустить только один экземпляр BGP. Если мы говорим про OSPF, например, OSPF можно запустить много. И мы указываем там router OSPF 1, router OSPF 100, router OSPF 10 000. И мы тем самым запускаем несколько разных процессов OSPF, и это, как правило, приводит только к проблемам из-за того, что мы потом запутаемся, где какой экземпляр мы использовали. Поэтому мы говорим в OSPF, что надо запускать только один экземпляр, потому что так будет проще для всех. И этот экземпляр может иметь любой номер, и номер этот должен быть единичка. В BGP вы можете запустить только один экземпляр BGP, вы не можете в принципе запустить два разных router BGP. Но вы должны будете указать здесь номер автономной системы, и этот номер автономной системы

должен быть именно тот самый, который вы купили. Если у вас номер автономной системы 100, вы должны будете указать router BGP 100. Есть частные диапазоны автономных систем. Это последние 1024 номера из 16-битного диапазона. Всего у нас в 16 бит влезают числа от 0 до 65 535. С 64 512 начинаются номера автономных систем, которые нельзя использовать в интернете. Так же, как частные адреса, 192.168 или 10-ку нельзя выпускать в интернет, маршруты BGP с такими номерами автономных систем тоже нельзя выпускать в интернет. Первая половина из этого диапазона, последних 1024 номеров, будет использоваться для документации,

а вторая для служебных задач. Или наоборот, первая для документации, вторая для всяких служебных задач. Если вам нужно будет взять какой-то случайный номер из этого диапазона, в принципе, никто ругаться не будет. Вы можете взять любой из них. Например, 65 000, пожалуйста, берите. Можете взять 65 500. По-хорошему, первая половина вплоть до 65 023. Это номера для документации. А 65 024 по 65 535 — это номера, которые вы можете использовать для любых своих нужд. После того, как вы запустили экземпляр router BGP с правильным номером автономной системы, дальше мы должны будем прописать соседей, и мы должны будем сказать, что анонсируем. Если вы подключаетесь по BGP, то вы должны будете что-то анонсировать. BGP имеет смысл только,

если вы его делаете для анонса своей сети. Если вы просто говорите, а давайте будем принимать маршруты, то проще статику прописать, что все маршруты в интернете доступны через провайдерский роутер. Поэтому основная задача здесь у нас будет — указать соседа, которому мы будем что-то анонсировать, и указать, что именно анонсируем. Сосед прописывается следующим образом. Neighbor. IP-адрес соседа. Тот, с которым вы находитесь в одной сети. Здесь довольно важно, что в eBGP-взаимодействии у вас IP-адрес должен быть connected. Если у нас, например, здесь 192.0.2.1, наш IP-адрес, то мы должны будем дружить с IP-адресом 192.0.2.2, который находится с нами в одной сети. Нельзя взять и сказать, а давайте мы здесь ещё в серединке поставим роутер и будем дружить с каким-то другим узлом, который будет находиться где-то ещё. В очень редких случаях такую штуку сделать можно, но не нужно. В подавляющем большинстве случаев вы должны будете дружить напрямую с роутером,

который находится рядышком с вами. Затем вы указываете номер автономной системы соседа, remote-as и его номер. Ваш роутер будет проверять при установлении соседства, действительно ли у соседа такой номер автономной системы. Если он будет отличаться, соседство не установится и маршрутами вы не обменяетесь. Затем, после того как соседство установлено, указали IP-адрес соседа, указали номер его автономки, указываем, что мы будем анонсировать. Команда network, дальше IP-адрес, слово mask и дальше маска. В отличие от всех остальных протоколов, которые мы с вами проходили до сих пор, от RIP, от OSPF, от EIGRP, здесь слово network имеет прямой смысл. Мы берём из таблицы маршрутизации ровно сетку с таким IP-адресом, с такой маской. Если она в таблице маршрутизации есть, она анонсируется всем соседям. Если ровно такой сетки, ровно с такой маской

в таблице маршрутизации нет, она соседям не анонсируется. Вы не можете указать любую сеть, которую здесь укажете, хоть 8.8.8.8 с маской 255.255.255.255. Если в таблице маршрутизации она есть, вы её будете рассказывать. Если в таблице маршрутизации ровно такой сетки, ровно с таким IP-адресом, ровно с такой маской нету, а есть какая-то другая, например, маршрут по умолчанию или 8.8.8.0, то команда network не сработает. Анонсировать можно только и исключительно сети, которые у вас есть в таблице маршрутизации. Если в таблице маршрутизации сети нет, даже за деньги анонсировать её не получится. Естественно, анонсировать вы можете только сети, которые принадлежат именно вам. Нехорошо будет, если вы начнёте анонсировать, например, Google DNS, правда?

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

Вас сейчас не должно интересовать, как именно это происходит, но, как правило, если провайдер вдруг от вас не принимает какие-то префиксы, он вам расскажет, почему именно он не принимает и что нужно сделать для того, чтобы это поправить. Как правило, надо в базе RIPE кое-что прописать. Прописали neighbor, указали его IP-адрес, номер автономки, прописали в network, что анонсируем и с какой маской. Прописали ровно так, как оно есть в таблице маршрутизации, никаких исключений. И дальше можно уже бурно радоваться жизни. Есть команда, которая покажет нам, как именно бурно радуемся мы этой самой жизни. Команда show ip bgp summary. Когда у вас поднялся neighbor, вы можете взять и посмотреть, что у вас, во-первых, запустился протокол BGP, show ip protocols вам покажет, что действительно есть маршрутный источник соответствующий.

Во-вторых, show ip bgp summary покажет, что BGP у вас запустился с таким router ID, так же, как и у EIGRP, так же, как и у OSPF. У BGP есть router ID, назначается он по тем же самым правилам. Покажет local AS number — это номер автономной системы наш, сотый. Покажет, какой у нас есть neighbor. 192.0.2.2. Если neighbors будет много, то на каждого будет отдельная строчка. В нашем случае есть neighbor 192.0.2.2. Он находится в автономной системе двухсотой. Он находится с нами в одной сети. Связь установлена. И самое важное для нас — это последняя колонка. State/PfxRcd. Если там показывается что-то отличное от циферки, то это означает, что у вас связи с этим соседом нет. Если там показывается Idle или Active, или что-то ещё, любое слово — это плохо. Слова там не должны встречаться. Если встречаются, значит, всё плохо.

А если показывают циферку, значит, с соседом мы установили полные соседские взаимоотношения и обмениваемся уже боевыми маршрутами. В нашем случае мы видим, что State/PfxRcd имеет циферку 1 напротив соседа, значит, сосед прислал нам один префикс. BGP обменивается, строго говоря, не совсем префиксами. Он обменивается путями трафика, а по каждому пути трафика рассказывает, какие именно префиксы будут доступны. Но в нашем случае Cisco показывает вывод этой команды в логике, что BGP, хоть он и не совсем чистый distance-vector протокол, всё-таки у него единица измерения полезной нагрузки — это маршрут. Поэтому он показывает prefix received, что он нам прислал один префикс. Хотя на самом деле он прислал не префикс, он прислал путь. Можно будет посмотреть, что конкретно с этим соседом у нас работает. Какие конкретно согласовались свойства BGP,

какие конкретно дополнительные механизмы работают, в каком состоянии сосед находится, какой у него router ID, и разные многие другие штуки. Команда show ip bgp neighbors, и дальше вы указываете конкретно IP-адрес соседа, с которым вы дружите. Там показывается огромная простыня. Я не буду сейчас всю простыню вам показывать, но там действительно много всего. Для нас будет важно знать IP-адрес соседа, его номер автономки. External link означает, что сосед с нами не в одной автономке. Если у нас номер автономки такой же, как у него, то тогда это будет internal link. И там BGP будет работать немножко с расслабленными булками, если так можно выразиться. Он будет в части безопасности себя вести совсем иначе. Когда мы работаем со внешним соседом, который находится в другой автономной системе, BGP работает прям очень жёстко, как классический КГБ-шник, говорит, ничего нельзя, всё, что не разрешено в явном виде, всё запрещено. Затем показывается router ID соседа.

Router ID, в общем, не сильно важен, но иногда бывает нужен. И BGP state Established. Это означает, что с соседом всё хорошо, мы прошли все фазы установления соседства и с соседом обмениваемся маршрутами. А uptime — как давно мы установили соседские взаимоотношения. Можно посмотреть, чем конкретно роутеры обмениваются, что именно они синхронизируют между собой. Для того чтобы посмотреть таблицу маршрутов BGP, есть команда show ip bgp. И вам покажут здесь таблицу BGP-маршрутов. Показано, что здесь у нас есть маршрут по умолчанию, который прислал нам сосед 192.0.2.2. Точнее, не показывается, кто прислал, показывается, куда маршрут смотрит. Чаще всего, если мы говорим про eBGP, про взаимодействие с соседом из другой автономки, next hop будет как раз тот, кто прислал маршрут. В последней колонке

показывается, откуда такой маршрут пришёл. В нашем случае мы видим, что маршрут пришёл через 200-ю автономную систему, и он там зародился. Этот path — это строчка, которую можно читать, через какие автономные системы прошёл маршрут. В нашем случае мы видим, что здесь показано, что маршрут пришел из 200-й автономной системы. Если бы маршрут прошел через много автономных систем, то здесь был бы, сначала он пришел из 200-й, потом следующий он будет через 300-ю, потом через 400-ю и так далее. Он показал бы список всех номеров автономных систем, которые прошел этот маршрут. Судя по всему, маршрут по умолчанию, просто роутер-провайдер сказал, я знаю все сети в мире, и он сам такой маршрут придумал. В то же время мы ему анонсируем эту сетку 203.0.1.13.0 и показан NextHop 0.0.0.0. Это такой специальный хитрый NextHop, означающий, что мы в BGP сами такую сетку придумали и рассказываем про нее своим соседям. Здесь показано,

что маршрут зародился в нашей автономной системе, ни через какие external link этот маршрут не проходит. Каждый маршрут должен быть в таблице маршрутизации поставлен только если он будет самый лучший. И BGP будет из всех-всех-всех маршрутов до одной и той же сети пытаться выбрать самый хороший маршрут, а дальше будет пытаться самый хороший маршрут вставить в таблицу маршрутизации. У него это может не получиться. Если у вас маршрут был выбран в качестве лучшего и попытался вставиться в таблицу маршрутизации, то вот такой символ у вас — звездочка и угловая скобка. Будет показывать, что все хорошо. Звездочка означает, что маршрут корректный, что его можно поставить в таблицу маршрутизации, а угловая скобка означает, что маршрут лучший. Может быть такое, что вам два разных роутера BGP рассказали, что знают, как добраться до какой-то сети. В случае, например, с OSPF или с EIGRP мы бы, не особо мучаясь, попытались бы понять, есть ли маршруты получше, есть ли маршруты похуже.

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

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

А BGP не может балансировать трафик между разными автономными системами, потому что если у нас есть маршрут, который можно пустить через условный Билайн или через условный Мегафон до одной и той же сети, мы же не можем сказать, давайте пускать трафик и туда, и туда, в рамках одного и того же приложения, в рамках одной и той же сети. У нас будет тогда прямо гарантированный и страшный resequencing в том смысле, что пакеты, которые пойдут через разных провайдеров, по сети будут прямо гарантированно бежать разное время. И задержки, которые будут при прохождении трафика через сети разных провайдеров, будут различаться очень и очень сильно. Поэтому, чтобы этого не происходило, BGP всегда стремится трафик пропускать только по одному маршруту до одной и той же сети. И поэтому он имеет этот самый продвинутый алгоритм выбора лучшего маршрута. Он называется Best Path Selection. Давайте попробуем BGP в наших условиях поднять.

У нас есть центральный роутер. Мы сейчас сделаем вид, что он провайдерский. А дальше к этому роутеру будем подключать наши маленькие роутеры, которые будут пытаться чего-то центральному прислать. И посмотрим на то, что у нас в итоге получится. Давайте я сначала настрою центральный роутер, чтобы было понятно, в какой логике мы настраиваем наши маленькие. Enable. Enable. Conf. No. Router. OSPF 1. Нам OSPF сейчас не нужен. Он, прямо скажем, будет вредить. Выключил OSPF. Router. BGP. 65500. Сделаем частный номер автономной системы в лучшем соответствии с мировыми практиками. И затем скажем, что у нас есть некоторое количество соседей. Neighbor. 10.100.1.1. Remote.

AS. 65001. И есть еще второй комплект. 2.2. И есть еще восьмой комплект. Прописал трех соседей. И соответственно сейчас на маленьком нашем роутере нужно будет прописать ответные действия. Сказать, что мы запускаем процесс BGP с вот такими номерами автономной системы. Первый комплект — вот такой номер. Второй комплект — вот такой номер. Восьмой комплект — вот такой номер. Идем на наш маленький роутер. Enable. Conf t. И указываем, что у нас есть no router. OSPF 1. Router. BGP. 65008. И указываем, какой сосед у нас есть. Neighbor.

10.100. Номер комплекта. Точка 100. В моем случае восьмой комплект — 10.100.8.100. Это тот самый IP-шник, который центральный роутер имеет в одной канальной среде с моим роутером. И соответственно указываем remote AS у него. И remote AS у него 65500. После того как neighbor мы указали, через некоторое время поднимается BGP-шное соседство. И хотя там никаких маршрутов BGP еще не протащил, соседство уже есть. Можно будет его посмотреть с помощью команды do show ip BGP summary. Вот у нас наш сосед. Он действительно в 65500 автономке. И эта циферка state prefix received означает, что у нас все хорошо. Действительно сосед работает. Действительно мы с ним готовы обмениваться маршрутами. Просто прямо сейчас обменялись нулем маршрутов.

Если бы там показывалось любое другое слово, active, open sent, open confirm, это все было бы плохо. Буквы тут показываться не должны. А циферка любая, в том числе и ноль, означает, что все хорошо, маршрутами мы готовы обмениваться. Дальше. Задачей нашей было все-таки установить не соседство, а установить одинаковые таблицы маршрутизации на наших роутерах. И у нас есть do show ip route. У нас есть сейчас некоторое количество маршрутов, которыми мы готовы обменяться. Эта сеточка 10.200.8.0 по 24-й маске у меня висит на loopback. У вас тоже есть на loopback сетки, там 10.200.1.0, 10.200.2.0 по 24-й маске. И давайте ими сейчас обменяемся. Ровно эту сетку, ровно с таким IP-шником, ровно с такой маской мы укажем в команде network. Если указать что-то отличное, либо сетка будет с другим IP-шником,

либо с другой маской, она не будет анонсироваться, она не попадет в таблицу BGP и не сможет быть анонсирована соседям. И мы указываем 10.200.8.0, mask 255.255.255.0. Обратите внимание, маска прямая. Это не условие access-листа, это именно команда network указывает на префикс таблицы маршрутизации. Поэтому маска тут прямая. И сейчас у нас в таблицу BGP попадет эта сетка, 10.200.8.0 по 24-й маске. У вас это будет другая сетка, 10.200.1.0. И show ip BGP покажет, что действительно она есть. 10.200.8.0 по 24-й маске. Мы сами ее придумали, мы анонсируем ее соседу, а сосед, может быть, нам анонсирует чего-нибудь еще. Очень хорошо видно, что BGP — протокол крайне неспешный. Он никуда не торопится. У OSPF мы вбросили, она сразу появилась, прямо сразу раскаталась на все роутеры. А здесь он медленно и печально что-то нам присылает. Вот прислал.

Показано, что маршрут у нас действительно есть. Вот он. Маршрут до сети 10.200.1.0 по 24-й маске. NextHop — тот IP-шник, который будет ставиться в таблицу маршрутизации для того, чтобы вбросить этот маршрут в таблицу, — 10.100.8.100, он и будет. Тот, кто прислал нам такой маршрут в случае с EBGP, с External Link связью, на него трафик посылаться и будет. И маршрут прошел через 65500 автономку, это центральная, и там появился из 65001 автономки. Через две автономные системы такой маршрут прошел. Можно взять и пингануть ping 10.200.1.1. Source 10.200.8.8. Пингуется. Забавный момент заключается в том, что если я просто укажу сейчас ping 10.200.1.1, вот так, пинговаться не будет.

Причем видно, что в принципе пинги ходят. Но если просто указать ping, то пинги не ходят. Связано это с тем, что пакеты до 10.200.1.1 у меня дойдут, если я их сейчас отправлю. Только в случае, если я просто отправляю пакеты на адрес 10.200.1.1, они у меня уходят с указанием адреса источника, динамически выбранным. А динамически выбирается адрес с того интерфейса, с которого уходят пакеты. И это вот такой адрес — 10.100.8.8. Его банально нет в таблице маршрутизации. Поэтому пакеты доходят до первого роутера, но обратно вернуться ответы не смогут, потому что непонятно, куда их девать. Show ip route BGP. Покажет нам только один маршрут, который в таблице есть. Эти connected сетки центральный роутер нам не присылает. BGP-шные маршруты, если мы говорим про external BGP-связь, про связь между автономными системами, будут приходить с административным расстоянием 20.

Надо будет понимать, что если нам EBGP что-то смог вбросить в таблицу маршрутизации, то это будет существенно более приоритетно, чем OSPF, чем EIGRP, чем RIP. И поэтому надо с очень большой осторожностью относиться к тому, что маршрутизатор соседа из другой автономки вам может прислать. Если вы согласны принять некий маршрут, он у вас попадет в эту самую таблицу show ip BGP, то дальше он вытеснит из таблицы маршрутизации любой другой маршрут, который вы туда вбросите самостоятельно через любую динамическую маршрутизацию IGP-шную. Статику он не сможет выкинуть, а вот OSPF, EIGRP, RIP он выкинет, потому что у него административное расстояние достаточно маленькое, меньше, чем у любого другого протокола, который мы с вами разбирали. И показывается этот IP-шник. Этот IP-шник — это NextHop, который прислал нам сосед. BGP — очень интересный протокол, потому что, если вдруг вы обмениваетесь маршрутами

и там указан просто какой-то абстрактный NextHop, то никаким образом при вбросе маршрута в таблицу маршрутизации BGP не будет менять этот самый атрибут NextHop. Ему сказали, что NextHop будет Вася. Он в таблицу маршрутизации Васю таким образом и поставит. И у вас может быть такое, что BGP присылает маршрут и указывает, что для того, чтобы ходить в эту сетку, ходи вон через него. И дальше — а как добраться вот до этого «вон через него»? Надо отдельный маршрут иметь, чтобы было указано, что этот IP-шник доступен через какой-то другой интерфейс, через какой-то другой адрес шлюза. Это нормальная ситуация. У BGP такое довольно часто происходит. Опять же, в рамках курса ICND2 мы с вами не будем это изучать, но на курсе по роутингу обязательно посмотрим. Там с этим есть ряд проблем, которые заботливо раскладывают грабли

начинающим администраторам провайдеров. BGP в рамках такого обзорного курса мы с вами посмотрели, убедились, что маршрут он протаскивает. Если вдруг захотите, можете сделать с IPv6 то же самое. Принципиально ничего не меняется. Единственное, что вам понадобятся маршрутизируемые адреса IPv6 для указания IP-шников соседей. В принципе, можно и с link-local, но очень лень сейчас брать и переписывать все эти link-local, указывать network, neighbor, дальше указывать IP-шник link-local, интерфейс. Это тяжело сейчас будет делать. Я предлагаю этого не делать. На экзамене этого не будет. Но как бы там ни было, смысл будет точно тот же самый, что у вас в таблицу BGP IPv6 маршруты будут накапливаться. Точно так же они будут иметь в колонке network указания, что за IP-шники. Точно так же будет какой-то NextHop, link-local, как правило. Будет точно так же в колонке path указание, через какие автономные системы прошел маршрут.

И в таблицу маршрутизации маршруты будут точно так же попадать. IPv4 и IPv6 в части работы, протаскивания маршрутов, не сильно будут отличаться. Вот так вот. BGP в рамках предприятия настраивается. По-хорошему, конечно же, здесь надо было бы еще дополнительные всякие штуки повесить. Нужно было бы указать, какие маршруты мы согласны принимать, какие маршруты мы согласны отправлять. Но наш курс не предусматривает такое глубокое изучение материала. show run, show run, show run, section BGP. Вот так вот выглядит секция в настройке BGP. Она указывает, что у нас есть router BGP, что у нас есть сетка, которую мы анонсируем,

и у нас есть некоторое количество соседей в определенных автономных системах. Может быть такое, что на конкретного нейбора мы захотим повесить какой-нибудь фильтр, может быть такое, что мы захотим с ним какие-то дополнительные настройки сделать. В этом случае строчек, которые содержат слово нейбор и определенный IP-шник, может быть несколько. Ну вот там будет нейбор 10.100.8.100.remote.is. Такое-то. Нейбор 10.100.8.100. Допустим, висеть будет фильтр. Сейчас покажу. router BGP. Если взять и запустить BGP с несуществующим номером, он скажет, что... А, router. Вот. Он скажет, что BGP уже запущен с номером автономной системы 65.508. Так что запустить можно только один экземпляр BGP. И вот нейбор 10.100.8.100.

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

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