Атрибуты в BGP

Продолжаем обсуждать маршрутизацию, продолжаем обсуждать BGP. Мы столкнулись с тем, что у нас есть маршруты. У этих маршрутов есть какие-то свойства, и нам с этими свойствами нужно уметь разбираться. И здесь мы трогаем огромную тему, которая называется атрибуты BGP. BGP, когда будет ориентироваться на качество маршрута, будет смотреть именно на атрибуты, на то, как он знает определённую сетку, для того чтобы выбрать один маршрут среди нескольких хороших, для того чтобы найти один самый лучший маршрут. Это самая процедура, которая называется Best Path Selection. Пример. У нас есть роутер R2, который говорит: я знаю, как добраться по пути А до CTX. Роутер R3 говорит: я тоже знаю, как добраться до CTX, но по пути B. Нам надо выбрать, какой из путей для CTX будет лучше, путь А или путь Б.

Роутер 1 не может балансировать трафик, он говорит: я не буду пускать часть трафика сюда, часть туда. Я должен буду сравнить эти два пути, путь А и путь Б, и сказать, один из них заведомо лучше, чем другой. Хотя бы монетку кинуть, хотя бы на кофейной гуще погадать и сказать, что один лучше, чем другой, но должен каким-то образом предсказуемо получить результат. Роутер R1 выбирает каким-то образом лучший путь до CTX и анонсирует своим соседям, говорит: я знаю, как добраться по пути А плюс R1 до CTX. Он говорит: я туда трафик буду посылать. И дальше все остальные соседи видят, что трафик будет идти именно по тому пути. Вы можете, если очень сильно хочется балансировать трафик между двумя маршрутами, выполнять его в пределах автономной системы. Если у вас есть своя автономная система, в ней есть какие-то роутеры, и роутеры в том числе есть пограничники, которые говорят: я знаю, как выйти из автономной системы,

я знаю, как добраться до какой-то сетки. У нас есть какая-то внутренняя топология. Один роутер говорит: я знаю, как добраться до сети. Второй роутер говорит: я знаю, как добраться до сети. И дальше возникает вопрос, куда трафик посылать, на одного или на другого? И в такой ситуации мы до предела выжимаем из процедуры выбора лучшего маршрута все сроки до тех пор, пока она не скажет: лучший выход из автономной системы через NextHop роутер R2. Как только мы определили, что самый лучший NextHop — роутер R2, мы добавили маршрут в таблицу маршрутизации, мы сказали, у нас IP-шник NextHop будет 101.101.101.101. Мы определили, что самый лучший маршрут имеет вот такой NextHop. Дальше вы можете сказать: до этого NextHop можно добраться разными трассами. Мы можем запустить, условно говоря, OSPF и сказать, как мы знаем 101.101.101.101. И он может сказать, что мы его знаем двумя трассами. Мы можем пойти напрямую и можем пойти в обход. И тогда трафик до внешней сети, у которой NextHop 101.101.101.101,

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

Но это очень редкое явление. Дальше. Когда у нас есть дистанц-векторные протоколы, как вы помните, в EIGRP была такая картинка, что у нас есть два вектора, которые можно сложить между собой и получить результирующий вектор. Если у нас есть вектор А и вектор Б, то результирующий вектор — это будет как правило сложения векторов. Вектор, которым будут обмениваться роутеры, будет состоять из этих самых атрибутов. И выглядеть он будет следующим образом. Атрибут NextHop — это просто IP-шник. Он каждый раз будет меняться. Вы можете менять его при отправке по EBGP-шной связи. Это штатное поведение, что при отправке соседу по EBGP он меняется, за исключением случая, когда у вас есть сосед, который дружит с вами из-под определённого интерфейса, и вы этот маршрут отправляете в тот же самый интерфейс, из-под которого он пришёл. Более строго — не по тому же интерфейсу, а в той же самой IP-сети. То, что мы с вами наблюдали в лабе, когда маршрут приходит от 192.168.0.1, а отправляется на 192.168.0.2.

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

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

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

потому что эта сетка зародилась прямо в нашей автономке. NextHop — это я, потому что я эту сетку придумал. Отправляет эту сетку роутеру R2. R2 говорит: я отправляю дальше по EBGP-шной связи это всё роутеру R3, поэтому я указываю в атрибуте ASPath, что этот маршрут пришёл из первой автономки, и NextHop я себя проставляю, потому что это EBGP-шная связь. Ходи, дорогой R3, через меня по умолчанию. R3 принимает такой маршрут, говорит: я получил его по EBGP-шной связи, я дальше его отправляю по EBGP-шной связи своему соседу роутеру R4. И сосед роутер R4 видит маршрут, у которого ASPath содержит циферку 1, что это маршрут, зародившийся в первой автономке. И NextHop у него, как мы уже знаем, по умолчанию не меняется, он видит IP-шник NextHop роутера R2. Если он его знает, он его добавит в таблицу маршрутизации. Если нет, то нет. Мы предполагаем, что он знает, потому что в таблице маршрутизации у роутера R4 этот маршрут всё-таки оказался. Поэтому R4 дальше эту сетку анонсирует куда-то ещё по EBGP-шной связи.

Он говорит: я знаю, как добраться до сети. И рассказывает, что маршрут из нашей автономки номер 2, дальше продолжается автономка номер 1, где этот маршрут уже и завершается. И NextHop он говорит: ходи, пожалуйста, через меня, через R4. Вот такая штука. Если говорить про Cisco и вообще про многие реализации BGP, то атрибут ASPath вы будете видеть просто в виде текстовой строки. Там 1, 2, 4, 9, 65101. Это просто через запятую указаны номера автономных систем или через пробел. Как текстовая строка, она даже и обрабатывается зачастую именно как текстовая строка. Так, Local Preference. Атрибут стандартный. Указывает на приоритет маршрута внутри автономной системы. По умолчанию особенно никак не работает. Все маршруты, которые приходят к вам из внешних автономных систем,

они просто приходят, и вы им назначаете какой-то условно-дефолтный Local Preference. Никакой разницы. Все маршруты получают одинаковый приоритет. Но вы этот приоритет можете искусственно понизить или повысить. И тогда, если у вас есть две точки выхода из автономной системы, и какой-то роутер думает, куда направить трафик — на один или на другой роутер, чтобы они отправили это всё наружу, то вы будете предпочитать тот маршрут, у которого Local Preference будет получше. А тот, который похуже, не будете предпочитать. Весь трафик будет загоняться на один роутер, и дальше выходить из автономной системы будет по основному аплинку. Если он дохнет, то трафик направляется на другой роутер, и оттуда уже выходит по запасному аплинку. MultiExit Discriminator или MED — это прямо противоположный атрибут по смыслу, нужен для того, чтобы вы могли указать соседу, через какой аплинк в вашу сторону по анонсированным вами маршрутам можно было войти. Если есть ваша автономка и автономка соседа, которому вы анонсируете маршрут по двум разным линкам,

вы в этом случае отправляете MED1 и MED2. И при прочих равных, если сосед скажет, что хочет Local Preference рулить, вы с этим ничего не сделаете. А если скажет сосед: мне всё равно, Local Preference там и там одинаковый, всё одинаково — при прочих равных вы будете смотреть на MED, и сосед возьмёт MED, который получше, трафик будет посылать по одному линку, а второй останется свободный, как запасной. Как в сценарии, когда у вас есть проводная связь и, например, запасная радиорелейка. Как раз MED-ами эту штуку можно будет удобно разрулить. И наконец два атрибута. Origin — это код происхождения маршрута, это та маленькая буковка I, которая стоит в конце после списка автономных систем в атрибуте ASPath. Откуда взялся маршрут? На самом деле бесполезный атрибут, когда давным-давно был полезный, сейчас уже нет.

И последний атрибут Community — это список меток, которые вы можете повесить на маршруты. Очень интересная штука. Это позволяет политикой раскрасить маршруты, что-то типа тегов, только Community. Вы можете эти метки не просто передавать, а передавать по какому-то правилу. И на эти метки можно вешать достаточно неплохие обработчики. Опять же, всё роутмапами будет делаться, но тем не менее вы можете сказать, что некоторые маршруты мы отправляем типа красненькие, некоторые зелёненькие. И если вы отправляете маршрут типа красненькие, то ему сосед должен чего-нибудь хорошее сделать. Если вы отправляете зелёненькие, то ему сосед должен что-то плохое сделать. Такие вещи можно будет сделать, и для этого есть штатный атрибут. Так, с NextHop всё уже рассказал. Это тот самый адрес, который роутер будет пытаться добавить в таблицу маршрутизации. Обычно при передаче по IBGP не меняется. NextHopSelf. Если мы не указываем, то не меняется.

Он должен резолвиться в таблице маршрутизации. Обычно рекурсивно. Более того, обычно как раз это и происходит рекурсивно, когда сосед по EBGP говорит: я знаю, как добраться до какой-то сети. Дальше роутер по IBGP говорит: он знает, как добраться до какой-то сети. И роутер ставит NextHop того, и дальше этот NextHop должен быть известен через, условно говоря, OSPF. Если у вас будет условный OSPF показывать, как можно добраться до внешнего адреса несколькими разными способами, то у вас будет балансировка. Если вы указываете, что какие-то маршруты вы сами придумали, то в анонсах IBGP-шных или EBGP-шных вы всегда будете указывать свой собственный IP-шник. Или по EBGP, если вы что-то анонсируете, то вы, как правило, тоже в этом случае NextHop проставляете в свой собственный IP-шник. Про ASPath уже было сказано, что этот атрибут добавляет при передаче по EBGP свой собственный номер автономки в этот атрибут,

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

роутер по EBGP рассказывает, что можно добраться до этой сети, указывает свой номер автономки в анонсе. Дальше этот рассказ идёт по IBGP-шной связи, там по EBGP-шной добавляется своя автономка четвёртая, снова IBGP, снова EBGP, и здесь должно быть 5, 4, 1. Своя автономка добавляется спереди. И тут по IBGP-шной связи рассказ идёт про то, что своя сетка. Дальше EBGP-шная связь, добавляется первая автономка, IBGP, EBGP — снова добавляется вторая автономка, и отсюда у нас приходит апдейт, в котором ASPath содержит три автономные системы: пятая, четвёртая, первая. Отсюда приходят две автономные системы: вторая, первая. Мы говорим: маршрут через два прыжка между автономками при прочих равных лучше, чем маршрут через три прыжка. И мы говорим: окей. Дальше анонсируем маршрут только тот, который выгодный, с атрибутом ASPath 2, 1.

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

ASSequence, ASSet, ASConfedSequence и ASConfedSet. Про конфедерации мы в нашем курсе не рассматриваем совсем ничего, а ASSequence и ASSet — эти штуки мы уже с вами изучать будем. То, что дополняется номером автономной системы при отправке соседу, это атрибут, который называется ASSequence. И если вы видите, что маршрут, который проходит через несколько автономных систем, приходит на вас, то вы можете эту информацию использовать для защиты от петли. Если вы получаете по EBGP-шному соседству некий маршрут, вы смотрите, не проходит ли этот маршрут через вашу автономную систему. Если вы видите, что анонс, приходящий к вам, содержит в ASPath вашу собственную автономку, вы такой маршрут просто отбрасываете. Вы говорите: я уже знаю, как добраться до этой сети, я не буду принимать твой маршрут просто потому, что в моей автономке этот маршрут уже есть.

Нет смысла проходить вот так, если я могу пройти сразу. Атрибут ASSequence добавляет номер автономки при отправке по EBGP-шной связи. Также вы можете его модифицировать политикой. Но это делать надо очень аккуратно, потому что можно, если вы будете его модифицировать абы как, поломать этот механизм защиты от петель. Здесь у нас пример. Есть роутер R1. Он говорит: зная по EBGP, что через меня ты можешь добраться до этой сети, я её сам придумал. Роутер R2 говорит: окей, вижу номер автономки первой в списке, я номер автономки второй, моей автономки в списке нет. Анонсирует эту сетку роутеру R3. Говорит: ходи через меня, а потом через первую автономку. R3 говорит: окей, хорошо, моей автономки тут нет. Анонсирует эту сетку. Говорит: через третью автономку мою в сторону второй и дальше через первую ходи, пожалуйста, до этой сетки. Роутер R1 говорит: извините, вижу свой номер автономки, считаю такой апдейт криминальным и отбрасывает его.

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

то все автономки, которые были в ASSequence отдельных компонентов, мы складываем в атрибут ASSet. И дальше то же самое работает. Анонс мы отправляем, и дальше у нас используются оба атрибута. В ASSequence добавляется наша автономка, а ASSet бежит сравнительно неизменный по сети. И в этом случае мы говорим: у нас есть вот такая-то одна большая сеть, она сформирована из компонентов, у которых в этой куче ASSet намешаны всякие разные автономки, плюс ASSequence, там единичка. Дальше это анонсируется в сторону R3. Опять же, куча мелких сеток, у которых ASSet проставлен, сформировали одну большую крупную сетку. И ASSequence у неё вот такой. И неважно, где вы встретите свою автономку — либо в ASSet, либо в ASSequence, в любом случае, если вы видите свою автономку, то вы такой маршрут отбрасываете. Это защита от петли. С Local Preference вы можете рулить тем, как вы хотите выйти из своей автономной системы,

Как вы хотите трафик направить наружу. Local Preference – это выбор маршрута для исходящего трафика. Как вы помните, маршруты у нас идут в одну сторону, а трафик по этим маршрутам идет в прямо противоположную сторону. Поэтому, если мы хотим рулить исходящим трафиком, то мы должны будем использовать атрибут Local Preference фактически для выбора входящих маршрутов, когда к нам соседи приходят и говорят «Ходи, пожалуйста, через меня до какой-то внешней сети». Соседи присылают нам маршруты, мы эти маршруты ловим и говорим «Этот маршрут лучше, чем другой». Представим себе, что у нас есть такая сетка, наша автономная система, у нас есть два провайдера, и мы хотим сказать, что один провайдер основной, верхний, а второй провайдер запасной, потому что он дорогой и с нас берет деньги за трафик, и вообще он плохой. Мы хотим по умолчанию весь трафик направлять через основной провайдер. Но мы хотим это делать для исходящего трафика и для входящего трафика. Local Preference позволяет рулить исходящим трафиком. Те маршруты, которые приходят от провайдера 1,

они должны стать приоритетнее по сравнению с маршрутами от провайдера 2. Даже если у нас есть какой-то клиент провайдера 2, до которого мы хотим добраться, нам хочется, чтобы маршрут до этого клиента был вот такой кривой, чтобы через интернет мы подключились к провайдеру 2 снаружи и после этого выпустили трафик туда. Local Preference – это просто 32-битное число, и чем больше оно, тем лучше. Мы его назначаем по некоторой политике. Например, у нас есть маршрут до какой-то сетки через провайдер 1, мы ему политикой назначаем Local Preference 150. Точно такой же маршрут, который приходит от провайдера 2, мы оставляем значение по умолчанию Local Preference 100. И в такой ситуации каждый из роутеров, что R1, что R2, что какие-то роутеры, которые здесь будут, они будут видеть два маршрута. У одного будет Local Preference 150, у другого Local Preference 100. Они говорят, мы посылаем трафик на R1, чтобы он выпустил трафик на провайдера 1.

В этом случае точка выхода из автономной системы ESP2 не будет рассматриваться в качестве вообще возможной. За одним исключением. Если у нас здесь что-то происходит, остается только один маршрут с Local Preference 100, и мы выпускаем трафик наружу через ESP2. Local Preference не отправляется EBGP-шным соседям. Это очень хитрый атрибут, который отправляется только по IBGP-шной связи. Маршруты, которые приходят по EBGP, получают Local Preference по умолчанию. Если мы говорим про Cisco, то обычно это 100. Но вы можете на конкретного соседа сказать, что Local Preference на конкретного соседа будет какой-то другой. Например, здесь мы говорим, что все маршруты, полученные у ESP1, будут иметь Local Preference 150. Скобочка показывает на то, что это по сети не передается, что это происходит в воображении роутера R1, что когда апдейт приходит на R1, только здесь этому апдейту проставляется значение 150. Дальше при IBGP-шных апдейтах это значение можно будет уже увидеть.

Оно по сети будет передаваться, потому что там уже нельзя будет догадаться, что имел в виду роутер R1 при назначении Local Preference. В тот момент, когда маршрут пришел по IBGP-шной связи, у него породился Local Preference, который придумал сам принимающий роутер. Для выбора того, как трафик должен входить в нашу автономку, как мы отправляем наши маршруты до нашей собственной сети — есть у нас, например, роутер АА, у него подключена какая-то сетка. И он хочет анонсировать эту сеть, хочет, чтобы роутеры R1 и R2 заявили, что эта сетка известна во внешнем мире, чтобы роутеры, которые находятся где-то снаружи, могли добраться до этой сети. Но мы хотим, опять же, чтобы аплинк провайдера 1 использовался по умолчанию, а аплинк провайдера 2 не использовался. Точнее, не провайдера 2, а аплинк — вот этот провод, радиорелейка. Для этого мы можем использовать MED,

и MED работает только в очень ограниченном количестве случаев. Во-первых, он работает только, если у вас есть два или больше линков из вашей автономки в автономку соседа, одну и ту же автономку. Здесь видно, что это не две разные автономные системы, это одно облачко, это одна и та же автономная система. У нас провайдерский роутер 1, провайдерский роутер 2. Они оба принадлежат одной и той же автономке. И в этой ситуации мы хотим, чтобы провайдер посылал нам трафик вот так, но не через низ, чтобы такого не было. И в этой ситуации мы можем отправить маршруты и проставить им тот самый атрибут MED, Multi-Exit Discriminator. И чем меньше этот атрибут будет, тем лучше. MED — очень слабый атрибут, он сравнивается в одну из последних очередей. Соответственно, если провайдер скажет, я хочу направлять трафик по нижнему маршруту, он может сказать: Local Preference я здесь буду ставить миллион. Он имеет право такое делать. А здесь будет Local Preference единичка.

Вы никак переубедить не можете, хоть MED-ами, хоть чем угодно. Local Preference — сильный атрибут. И он трафик будет посылать вниз. Но если он этого не сделает, если он не будет рулить Local Preference для трафика в вашу автономку, то вы можете сказать, что если тебе всё равно, пожалуйста, используй вот этот верхний аплинк, я тебе подсказываю, что это хорошо было бы сделать, с помощью как раз слабого атрибута MED. Очень удобно этот атрибут использовать, заимствуя изначальную метрику IGP. Если у нас здесь есть, например, OSPF, и здесь у нас есть сетка А, и OSPF протаскивает эту сетку, говорит, здесь метрика будет 10, а здесь метрика будет условно 20 до этой сети, то при команде network, дальше мы указываем IP сети, маска, мы перекладываем маршрут из таблицы маршрутизации в таблицу BGP, и как раз внутренняя метрика может быть заимствована как MED. Здесь 10 и 20 плохо, пусть будет 50 и 100.

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

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

если этот MED изучен по IBGP, до тех пор, пока мы не прописываем волшебный пендель. Обычно он, естественно, не прописывается. Если вы провайдер и вам клиент прислал какой-то MED, вы его дальше не передаете. По этой причине распространяется MED только по той автономке, куда вы его отправляете. Имеет смысл этот самый MED передавать в случае, если у вас dual-home-подключение. Если вам нужно использовать не балансировку, а указание приоритета автономных систем в ситуации, когда есть роутер, есть одна автономка и другая автономка, и вы хотите, чтобы весь трафик ходил через одну автономку, и в такой ситуации вы хотите управлять трафиком, то вам нужно будет использовать не атрибут MED, а два других атрибута. Первый — атрибут community, и второй — AS prepending. Точнее, не атрибут, а техника. Это работа с атрибутом AS path для того, чтобы воспользоваться правилом: у кого длиннее, тот хуже. Если вы отправляете

одному соседу указание, что у вас есть какая-то сетка, и вы говорите: у меня в AS path свой собственный номер автономки 65000, а в другую сторону вы отправляете свой собственный номер автономки, но повторенный 10 раз. Раз, два, три, четыре — 65000. Вы свою собственную автономку много раз прописываете в AS path. В этой ситуации соседские автономные системы будут говорить, что здесь у нас одна автономка в списке AS path, а здесь 10. Соответственно, весь трафик надо пускать вот так, потому что это просто выгоднее. Хорошо, здесь одна, здесь две, здесь три, здесь четыре. Даже вот эта автономка говорит: сюда четыре автономки, а сюда 10. Выгоднее туда, куда четыре. Эта штука, как вы понимаете, немножко читерская, потому что один раз автономку свою прописать вы, конечно, должны, а вот 10 раз подряд одну и ту же автономку писать как-то нехорошо.

Поэтому многие провайдеры такое недолюбливают и не принимают анонсы с префиксами, у которых AS path содержит несколько раз подряд одно и то же число. Вы можете искусственно удлинить AS path, но будет ли это работать или не будет, заранее науке неизвестно. Зависит от вашего провайдера. Но в любом случае гарантировать, что вы сможете повлиять на какие-то другие автономные системы, какие-то другие роутеры, чтобы они трафик направляли в вашу сторону так, как это хочется вам, вы не можете никак. Гарантированного способа это сделать нет. Но есть способы с теми или иными техниками той или иной степени грязности попытаться на это дело повлиять. Если одна и та же автономка — используется для этого штатный атрибут MED. Если вы используете технику AS prepending, то вы добавляете в AS path свои номера автономных систем много раз подряд и тем самым заставляете предпочитать другие маршруты, где вы AS path не испортили.

Или если вы используете community, вы можете отправить одному провайдеру маршрут и не портить его с помощью техники AS path, но отправить его покрашенным с помощью community, а уже провайдер использует AS path для того, чтобы испортить этот маршрут дальше. Такие тоже штуки бывают. С community всё довольно просто. Это просто метки, которые вы можете использовать тем или иным образом. Список этот неупорядоченный, вы просто имеете место, куда можно дописать несколько разных community. Допустим, есть у вас маршрут, и вы говорите, я крашу этот маршрут меткой допустим, 1,2,1, рядом меткой 2,1, рядом меткой 3,1, рядом меткой 500,1, рядом меткой 500,1, это просто какие-то метки, которые сами по себе ничего не означают. Они записываются в разных формах, и есть три варианта

записи этих самых меток. Каждая из конкретных меток, вот 1,2,1, что она означает? Да хрен её знает. Вы должны будете как-то договориться с провайдером, которому вы отправляете эти самые метки, community, чтобы он умел их понимать. Метки передаются в другие автономные системы, поэтому вы можете community поставить какой-нибудь, который будет понимать вообще все роутеры в интернете. Можете отправить community, которая будет передаваться только в пределах автономной системы соседа, и вы ему проставляете эту метку и говорите, пожалуйста, ориентируйся на эту метку для того, чтобы как-то по-хитрому обрабатывать определённый маршрут. Никакого стандартного использования для этих меток нет, за редкими исключениями. Был случай не так давно, когда с помощью меток этих самых community чуваки играли в морской бой по BGP. Они отправляли друг другу маршруты, и они в community отправляли свои ходы. Там ранил, убил и так далее.

Стандартного способа чем красить, как красить и как реагировать на эти раскраски, ещё раз подчеркну, нет. Вам нужны договорённости. Пример договорённостей вы можете взять у какого-то конкретного провайдера, не знаю, вашему собственному провайдеру напишите, скажите, ребята, а что будет, если будем с вами пиринг по BGP, какие метки community что у вас будут означать? Например, есть такая штука, московская точка обмена трафиком, MSK-IX, и вы можете взять и посмотреть, пример договорённостей у них на сайте kb.msk-ix.ru, там есть статья Services Route Server, это точка обмена трафиком, поэтому это не совсем честный провайдер, но там тоже есть community, и вы можете посмотреть, как, например, они какие community принимают и что они с ними делают. Способов задать community есть три, как уже говорилось, это всё community, просто разные. Самый простой вариант, описанный в RFC 1997, это древняя-древняя штука, это два числа,

разделённых двоеточием, каждое число по 16 бит, каждое число 16-битное, если у нас есть автономка 16-битная и просто число 16-битное, то получается 32-битное значение. Изначально идея была такая, что каждый маршрутизатор, через который проходит определённый маршрут, может добавить какие-то свои community, каждая автономка точнее, и можно сделать так, что у вас есть гирлянда из автономных систем, маршрут проходит через эти самые автономки, и каждая из этих автономных систем что-то своё может добавить. И надо было, чтобы не запутаться, кто где что добавил, указывать ваш номер автономной системы и через двоеточие вашу метку. И получается, что маршрут к конечному получателю, к конечному роутеру, может прийти обросший этими самыми метками, каждая автономка добавила что-то своё. Потом появились extended communities,

и проблема была с обычными community в том, что в 16 бит значений очень мало, что можно было вписать. Поэтому находились люди, которые говорили, мы знаем, что определённые номера автономок не используются, или не проставляют community, или они вообще не входят в путь трафика, поэтому начинали заимствовать номера автономных систем, которые им не принадлежат, для того, чтобы расширить диапазон значений, которые можно было бы использовать. Им 16 бит значений было мало, и они хотели раскрашивать маршруты в больше чем 65 тысяч разных цветов. Для того чтобы адресовать эту проблему, появились extended communities, в которых по-прежнему были номера автономок 16-битные, но добавлялись разные метки, и эти метки были достаточно жирные. Там зависит от того, что вы хотите сделать, но вы можете указывать, что за community вы добавляете, и там места под хранение значения было больше. И через некоторое время, в 2007 году, появились

4-байтовые автономки, и для того, чтобы с 4-байтовыми автономками дружить, появился сравнительно недавно механизм large communities. Мы и 32-битные автономки там можем вписать, и там аж два разных значения можно вписать. Вы можете сказать, что мы красим это в такой-то цвет и в такой-то подоттенок. Есть стандартные метки, их очень мало, но они есть. Я говорил, что нету стандартного способа указывать что-то в этих метках. Но на самом деле есть буквально штучное количество этих самых меток. Самая первая метка называется no export. Если вы отправляете маршрут с указанием метки no export, там 65 535, 65 281. Это самый большой номер автономки в 16-битном диапазоне и 65 281. Это значение FFFFFF01. Это значит, что маршрут распространяется в пределах автономки соседа,

но не анонсируется по EBGP. Если вы отправляете маршрут с таким community, то по автономке соседа, да, он будет известен. Очень удобный способ сделать так, чтобы сосед узнал про какие-то ваши сетки, но не передавал их никому больше. Дальше вы можете проставить метку no advertise. Это значит 65 535, 65 282, опечатка, FFFF02. Не анонсировать вообще никому. У вас есть два роутера, один говорит другому, расскажу, и на ушко ему отправляете маршрут, который он никуда дальше не анонсирует. И вы можете сказать, что за херня, зачем такой маршрут вообще можно отсылать, зачем делать так, чтобы на соседнем роутере появился какой-то маршрут, про который он не сможет никому рассказать. BGP нужен для того, чтобы про маршруты рассказывать. Зачем делать так, чтобы про маршрут рассказать было нельзя. На самом деле эта штука очень удобная, потому что она прекрасно совмещается с третьей меткой, которая есть стандартная. Метка Black Hole. 65 535,

2.666. Эта 666 намекает на то, что у нас здесь странная ситуация возникает. Мы собираемся дьявола вызвать. Нет, 666 это действительно такое нехорошее число в том смысле, что если вы отправляете маршрут с меткой Black Hole, это значит, что сосед должен установить Next Hop в интерфейс 00. Вы присылаете соседу маршрут, вы говорите, Next Hop должен быть я, и вы выставляете метку Black Hole, что переопределяет значение атрибута Next Hop и говорит, этот маршрут должен смотреть в никуда. Очень удобная штука, если вас, например, дудосят. Есть вы, ваш роутер, есть роутер провайдера, есть аплинк провайдера. Со стороны аплинка провайдера валится огромная туча трафика на роутер провайдера. Этот роутер провайдера говорит, огромную тучу трафика мы посылаем на IP-шник назначения, и ваш роутер принимает этот трафик, отправляет его на сервер

ваш собственный, который ложится, потому что трафика приходит слишком много. Вы говорите, окей, этот сервер сдох, и он работать уже не будет, но у нас вместе с ним сдохли все остальные сервера, которые у нас тут были. А нам хочется, чтобы хотя бы некоторые серваки работали, потому что их-то не дудосят, дудосят только один сервер. Поэтому вы говорите, мы анонсируем всю свою сетку /24, она нормальная, она анонсируется дальше в интернет, и все остальные узлы в интернете знают, что до всей сетки /24 можно добраться и, соответственно, направить трафик в сторону именно наших серваков. Но рядышком мы можем сказать, мы посылаем маршрут /32 до той сетки, которую дудосят, и с меткой 666. Прибей этот маршрут у себя в таблице. Этот роутер добавляет маршрут до /32 сетки у себя в таблице, добавляет NextHop 00, и, соответственно, весь трафик до именно этого айпишника блокируется на уровне этого роутера провайдера. Соответственно,

если приходит какой-то пакет на айпишник блокируемого сервера, он убивается. Если какой-то пакет приходит на айпишник другого сервера внутри /24 сетки, он дальше пересылается по таблице и доходит до сервера назначения. Если вы указываете, соответственно, метку Black Hole и No Advertise, то сосед прибьёт такой маршрут, но дальше его не передаст, и как раз примерно то, что хочется, то и получится. Эти три метки известны. На экзамене я не думаю, что будут про Black Hole спрашивать вас, но про No Export, про No Advertise, наверное, будет. Вы должны будете примерно представлять, как это работает. Детально разбираться не обязательно, но общее представление иметь всё-таки нужно. И последнее, последний атрибут, про который идёт рассказ, это код происхождения. Древний атрибут,

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

здесь у нас, соответственно, была автономная система с EGP. И вы могли сказать, что у вас есть здесь тоже BGP. И здесь у нас, соответственно, исходная автономка, в которой зародился трафик. И автономки были связаны по такому правилу. И здесь как раз у нас наш роутер, который думает, как бы мне добраться до этой автономки. И у него приходит маршрут один такой и другой, соответственно, такой. В BGP мы видим, что здесь трафик этот нативным BGP-шным образом приходит на нас. Эта автономка, у неё есть вариант, как добраться. Так добраться или так добраться. Через верх этот маршрут изначально взялся как раз из IGP. Мы здесь видим, что у нас автономка дружит с нами по BGP, эта дружит с нами по BGP. Здесь везде нативная BGP-связь. И код происхождения этого маршрута — нолик.

Зародился маршрут здесь, дальше в BGP переложился здесь, дальше в BGP переложился здесь. С этим маршрутом всё хорошо. Для этой автономки, эта автономка дружит по EGP. И, соответственно, маршрут зародился в EGP, переложился в BGP и дальше приходит на нас. И в этой ситуации BGP всегда предпочитает маршруты, зародившиеся в BGP. Он говорит, я не хочу брать маршруты, которые переложены из EGP, если у нас есть нормальный маршрут. Но, соответственно, есть ещё двоечка. Код происхождения двойка означает — хрен его знает, откуда оно взялось. Вы можете увидеть 0, то есть IGP, если вы используете команду Network. Вы можете увидеть двойку, если вы используете в BGP команду Redistribute, потому что хрен его знает, откуда оно взялось в условном OSPF, если вы говорите, переложим из OSPF в BGP. А может быть вы EGP-шные маршруты положили в OSPF, а оттуда уже Redistribute в BGP. Поэтому эти самые incomplete вы будете видеть в Cisco, когда используете команду Redistribute.

А EGP вы не увидите никогда. Атрибут позволял выбрать маршруты нативные BGP-шные тогда, когда был вариант добраться по BGP-шным маршрутам или добраться по маршрутам потенциально EGP-шным. Сегодня это смысла вообще никакого не имеет, потому что RFC 904, он же 827, если мне память не изменяет, это очень древняя некромантия, поэтому смысла использовать его нет. Но тем не менее в процедуре выбора маршрута этот атрибут участвует. Каждый атрибут будет иметь некоторые свойства, и надо будет на экзамене, по крайней мере, разобраться, что это за свойства и откуда они берутся, почему они так называются. Я уверяю вас, что в литературе, по крайней мере которую я читал, я не увидел никогда внятного описания, почему эти атрибуты называются так и как между ними разобраться. Хотя на самом деле это всё очень просто. Well-known mandatory attribute — если у него есть такое свойство well-known mandatory, то значит, что well-known — его распознают вообще все, и mandatory — он обязан быть в каждом апдейте.

У него говорящее название: well-known — его распознают все, хорошо известный. Вы видите Васю, он говорит, ой, это Вася, все знают Васю. И mandatory значит, если вы видите апдейт, то в нём обязательно такой атрибут должен присутствовать. Например, NextHop атрибут — это well-known mandatory атрибут. Не может быть такого, что какой-то роутер не будет знать, что такое NextHop. И не может быть такого, что вам приходит апдейт, и в нём нет NextHop. В то же время есть атрибуты, которые могут не присутствовать в апдейте. Например, есть такой атрибут, который называется Local Preference. Тот самый, который у нас назначается внутри автономной системы, указывает, как можно выйти из автономной системы, если у нас есть два варианта, три варианта выхода. Этот атрибут хорошо известный, его все обязаны понимать. Не может быть такого, чтобы кто-то не понимал, что такое Local Preference. Но этот атрибут не обязан передаваться в апдейте.

По крайней мере, в EBGP Local Preference не передаётся. Поэтому well-known discretionary — все обязаны понимать, что это такое, но в определённых ситуациях мы можем его не передавать, или мы можем не иметь права его передавать, потому что, например, Local Preference в EBGP-шной связи мы передавать просто не имеем права. Он только внутри IBGP. Well-known атрибут в любом случае обязан поддерживаться всеми. Не может быть такого, что кто-то не понимает, что такое Local Preference. Альтернативные варианты. Если это не well-known атрибуты, значит, кто-то их может не понимать. Optional transitive атрибут означает, что кто-то может атрибут не понимать, но если вдруг он принял маршрут, содержащий этот атрибут, он должен дальше этот атрибут передать в любом случае. Опциональный транзитивный атрибут — это как раз community. У нас есть маршрут, который нам присылают.

Мы говорим, мы видим какое-то community, мы не понимаем, что там такое. Мы можем вообще не знать, что такое community. У нас может быть какой-то суперстарый роутер, который вообще community не понимает, или понимает только community обычные, не extended, не large community. Но в любом случае эти все community, какие бы они ни были, надо передать дальше. Это опциональные транзитивные атрибуты. Мы можем не понимать, что это такое, но надо дальше отдать в том виде, в котором мы их получили. И опциональные нетранзитивные атрибуты. Мы не обязаны поддерживать эту реализацию. Если мы не знаем, что это такое, мы это дальше не передаём. Опциональный нетранзитивный атрибут — это MED. Это атрибут, который не обязан присутствовать в апдейте. Если он присутствует, но мы его не понимаем, мы можем его проигнорировать, и соседям мы его передавать совершенно не обязаны. И более того, мы не просто не обязаны, а если мы его не понимаем, мы его не хотим принимать, мы его просто выкинем и всё. Так что четыре типа атрибутов есть. Хорошо известные — обязательные.

Хорошо известные — необязательные. Опциональные — транзитивные. Опциональные — нетранзитивные. Их надо на экзамене запомнить, что они такие бывают. Внизу к вам шпаргалка, которая позволит это всё дело запомнить. NextHop. Он обязательный. Нельзя представить себе апдейт без NextHop. И нельзя представить себе роутер, который не понимает, что такое NextHop. ASPath — та же самая история. Это основной атрибут, на котором BGP основан. Все обязаны его понимать. Все обязаны его дальше передавать. Нельзя представить себе апдейт без ASPath. Local Preference может быть в апдейте, а может и не быть. Внутри IBGP он обязательный, а между EBGP соседями его передавать просто запрещено. Поэтому он как раз well-known discretionary. MED — опциональный, нетранзитивный. Origin — хорошо известный, обязательный. Community — опциональный, транзитивный. При выборе маршрута у нас есть стандартный способ выбора, который описан в RFC 4271.

Если есть два или больше вариантов, как добраться до какой-то сети, мы должны будем постепенно отбрасывать те маршруты, которые не самые хорошие. Процедура называется Best Path Selection. Но на самом деле на каждом шаге мы отбираем те маршруты, которые заведомо нехорошие. И может так получиться, что у нас вообще ни одного маршрута не останется, гипотетически. Шаг номер один. Отбрасываем те маршруты, где Next Hop не резолвится, или AS Path содержит номер автономки. Это маршруты, которые заведомо кривые. Заведомо кривые маршруты выбрасываем. Если что-то осталось, то мы дальше продолжаем на шаге два. Шаг два – это отбросить те маршруты, у которых Local Preference меньше, чем у других. Оставляем только те маршруты, у которых Local Preference самый большой из всех доступных. Если осталось больше одного маршрута, смотрим, у кого AS Path короче.

Предпочитаем маршруты с меньшим количеством AS Path. Отбрасываем те, у которого больше. Если осталось больше одного маршрута, смотрим на атрибут происхождения. Откуда оно взялось? Если оно взялось из оригинального BGP, то мы говорим, из автономной системы в BGP этот маршрут попал с помощью команды Network. С ним всё хорошо, это нативный BGP-шный маршрут. Если там код происхождения EGP, значит, этот маршрут попал в BGP из EGP, который классовый, который кривой, косой, не имеет защиты от петель, поэтому маршруту такому мы не доверяем. Если у нас есть вариант IGP-шный или EGP-шный маршрут, мы берём IGP. Если у нас есть только EGP-шный маршрут гипотетически, то мы предпочтём его, конечно же. IGP это 0, EGP 1, Incomplete 2. Поэтому чем меньше здесь, тем лучше. Скорее всего, вы EGP никогда не увидите, поэтому IGP это буковка I, а Incomplete это вопросик.

Обозначение в циске: I лучше, чем вопросик. Пятый шаг. Предпочитаем маршруты с меньшим MED. Смотрите, MED сравнивается после Local Preference, после длины AS Path. Он действительно слабый атрибут. Сравнивается только для маршрутов, полученных из одной и той же автономки. Они прошли по одной и той же трассе в вражескую автономку. Дальше соседи анонсировали нам эти маршруты. И мы принимаем два варианта, как можно добраться до удалённой сети через соседскую автономку. В этой ситуации мы говорим, мы можем довериться тому, что проставил нам сосед, и пойти по тому маршруту, который MED имеет меньший. Если MED вообще отсутствует, потому что это опциональный атрибут, он не обязан присутствовать всегда. Более того, он опциональный нетранзитивный, поэтому вы могли и удалить. Мы полагаем его значение наименьшим возможным. Это стандартное поведение. Если MED нет, то считаем 0. Дальше. Шестой шаг.

Мы посмотрели на маршруты. У нас есть два или больше маршрутов, и они все одинаковые. У них разные Next Hop, но они резолвятся. AS Path у них одинаковой длины и не содержит нашу собственную автономку. Local Preference одинаковые, код происхождения одинаковый, MED одинаковые. Здесь мы должны подбрасывать монетку. Мы должны из двух или больше маршрутов выбрать маршрут, который будет лучше, но свойства маршрута идентичны. Поэтому мы говорим, если у нас есть маршрут в одну сторону и маршрут в другую сторону, и это абсолютно идентичные маршруты, то в этом случае мы предпочитаем маршруты, которые получены по EBGP. Если у нас есть EBGP-шное соседство и IBGP-шное соседство, и мы можем направить трафик наружу или внутрь, в этом случае мы предпочитаем маршруты, которые приходят по EBGP. Эта штука называется Hot Potato Routing. Технология горячей картошки. Если вы когда-нибудь готовили картошку на костре, то я расскажу, как это выглядит.

У вас есть костёр, вы картофелину заворачиваете в фольгу и кладёте в угли, а потом достаёте, разворачиваете и едите. Картошка, приготовленная таким способом, она очень вкусная, но у неё есть капитальный недостаток. Она горячая. Поэтому чем меньше вы в руках держите, тем меньше вы обожжётесь. И Hot Potato Routing заключается в том, что если у вас есть маршрут внутри своей автономной системы и вне автономной системы, и у вас длина AS Path одинаковая, этот маршрут гарантированно смотрит куда-то наружу. Поэтому нет смысла перекидывать эту картошку из руки в руку, потому что вы обжигаете обе руки, и чем больше вы перекидываете, тем дольше вы страдаете. Если вы знаете, что эту картошку надо отбросить куда-то наружу из своей автономной системы, то её надо выбросить из автономной системы. Она слишком горячая. Чем раньше вы от неё избавитесь, тем лучше. Всё равно, если вы отправите IBGP-шному соседу эту картошку, пакет по этому маршруту, то ему всё равно в какой-то момент придётся выйти из автономной системы.

Local Preference не назначен, значит, Hot Potato Routing говорит: отправляем сразу наружу, нечего занимать свой канал. Дальше. Седьмой шаг. Если у нас есть два маршрута, они оба получены по IBGP, и у них будет разный Next Hop. В этом случае мы должны будем посчитать до IP-шника Next Hop метрику в таблице маршрутизации. В таблице маршрутизации IP-шники у нас Next Hop есть, они резолвятся. И мы смотрим, что до одного IP-шника, возможно, метрика будет меньше, чем до другого. Мы не знаем, откуда она взялась. Может быть, один Next Hop у нас известен по OSPF, другой по EIGRP. У нас до EIGRP метрика 2 миллиона, до OSPF метрика 4. В этом случае мы говорим, в таблице маршрутизации метрика очень мало на что влияет, но это позволит нам из двух идентичных маршрутов выбрать один. Мы берём и смотрим тот, у которого Next Hop метрика меньше.

Метрика таблицы маршрутизации. Если предположить, что у вас везде один и тот же IGP протокол используется, например, OSPF, и OSPF говорит, до одного Next Hop 3 прыжка, до другого 4 прыжка, то в этом случае получится, что мы просто будем задействовать тот путь, который чуть-чуть быстрее в нашей автономке. А дальше за пределы нашей автономки трафик уже любым способом может выйти. Здесь уже всё равно. И если мы на этих семи этапах не нашли лучший маршрут, у нас по-прежнему два или больше маршрутов, которые до одной и той же сети смотрят, и два разных Next Hop имеют, нам надо хотя бы каким-то образом выбрать среди них один, но уже дальше начинается просто гадание на кофейной гуще. Мы говорим, что лучше будет тот маршрут, который получен от соседа с большим Router ID. Это не означает, что мы на этом этапе гарантированно решаем все проблемы, потому что может быть наш роутер и роутер соседа, и у нас две сессии с ним установлены. Тогда, если у нас один и тот же Router ID на одном и на втором соседстве есть, тогда мы предпочитаем тот маршрут, который получен от соседа в рамках сессии с большим IP-шником.

Это уже точно и гарантированно нам даёт из двух или больше вариантов способа добраться до удалённой сети только один. Это Best Path Selection, это не Best Path Set, где много маршрутов, это Best Path, он один. BGP всеми правдами и неправдами стремится выбрать один лучший маршрут. Это стандартный способ RFC 4271. Вендоры, скажем, Cisco, Juniper, условный MikroTik, они могут от этого механизма отходить. И когда мы будем говорить про Cisco, я вам расскажу, как Cisco будет предпочитать маршруты, выбор лучшего маршрута из нескольких вариантов, и надо будет Cisco-вский вариант для экзамена запомнить. Там будет специальная мнемоническая аббревиатура, которая вам позволит это дело чуть-чуть легче запомнить, чем просто запоминать 9 пунктов. Давайте на сегодня разбегаться.

Уже поговорили нормально. Завтра встретимся и договорим про BGP, поговорим про особенности выбора лучшего маршрута в Cisco, поговорим про всякие штуки типа роутмапов. И последний модуль у нас будет про дизайн. На сегодня всё. Спасибо за внимание. Пока-пока.