PE-CE BGP в L3 VPN

заказчиков. Достичь этого можно с помощью BGP. С точки зрения PEM-машизатора, давайте глянем кучу конфиг. Вот у нас есть раутер BGP, у нас есть адресное семейство VPNV4, которое смотрит на наш рут-рефлектор. И самое приятное, что количество рут-рефлекторов, в общем, в VPNV4 сессии, количество нейборов в ней особо не меняется. Далее, все, что находится под адресом IPV4 в рф-реф, будет относиться к заказчику рф. Ребята, что нам нужно будет сделать на стране PEM-машизатора с точки зрения BGP, если у нас появится еще 100 заказчиков? Нам же не нужно будет создавать новые BGP-процессы. А что нам нужно будет сделать? Да, то есть у нас на самом деле просто начнут

плодиться наши адресные семейства. То есть у нас протокол, мы считаем, что остается один, BGP-таблица остается одна, увеличивается исключительно количество адресных семейств. И ни в коем случае, когда мы заскалабили по количеству процессов, мы не выйдем. Я не уверен, есть ли некое ограничение на самом деле по количеству адреса family, но сомневаюсь. Давайте рассмотрим нашу такую топологию. То есть, по сути, у нас топология остается такой же, какая есть. У нас будут мурсатеры R11, мурсатеры R12 и мурсатеры R14. Они будут эмулировать наших красных заказчиков. Но теперь все амуртизаторы будут периться по BGP. Соответственно, с точки зрения кастомера абсолютно ничего не меняется. То есть для него будет BGP, и он будет периться

с PE-муртизатором в рамках какого адресного семейства. То есть для CE-муртизатора BGP-пиринг будет в каком адресном семействе происходить. Да, все правильно. IPv4 обычный юникаст. Так, давайте настроим. Давайте настроим. Итак, идемте с вами на мурсатеры R11. Окей. Создаем BGP-процесс. Route BGP. Пусть у меня будет 11, 12, 14. То есть между мурсатерами 11, 12, 14. Обратите внимание, что в этой версии софта у меня нет ограничений на 65 тысяч.

Поскольку у меня будет только одно адресное семейство, я не буду на нем вводить команду как на PE. То есть, помните, мы вводили noBGP-default и активировали потом конкретного neighbor, делали activate. для мурсатера R11, поскольку у меня будет только IPv4, я там сразу пропишу нужный нам neighbor. Neighbor. 1. Здесь будет remote IS. Remote IS 100. В принципе, на самом деле все. То есть, этого достаточно, да. Это достаточно, чтобы поднять BGP-сессию. Далее, далее. С точки зрения мурсатера R12. на маршрутизатор R14, на маршрутизатор R14, на маршрутизатор R14, поднимаем никает к рецидер на маршрутизатор R14, на ибо . 2 и на маршрутизаторе

теперь очередь за маршрутизаторами поe. router bgp100, адресное семейство ipv4 vry for it, указываю нейбора это будет 10, 1, 11, 11, remote is 11, 12, 14 и на маршрутизаторе R2, адрес фамиль, ipv4, vry for it, нейбор 10, 2, 12, 12,

и на четвертом и на маршрутизаторе R2, деймор 10, 4, 14, 14, remote is 11, 12, 14, и на маршрутизаторе R2, деймор 10, 4, 14, 14, remote is 11, 12, 14. идея у меня что-то скоро с точки зрения

верификации на CE вы можете использовать просто команду, которая, наверное, привычна большинству из вас show ipv4, bgp summary да, то есть, видите, мы перемся с нейбором таким-то и получаем некое количество префиксов, да, получаем некое количество префиксов, но не равно 7 дальше дальше что но более правильная команда это showbgp дальше мы указываем адресное семейство то есть это ipv4 unicast и здесь есть команда это будет более правильная команда вывод у них на самом деле одинаковый но тем не менее и, с вашего позволения у меня здесь сейчас uspf верификации я удалю его no router uspf100 и здесь no router uspf100

и на четвертом ну, то, что у меня там где-то есть займ-редстрибуция на этом голову не помочь проверим количество префиксов окей смотрим морсиатр R11 showbgp далее для нашего морсиатра это конкретно URF это конкретно URF единственное что смотрите так я боюсь мы посмотреть не можем потому что это это и это и и и и и и и и и и и и и и и то так я боюсь мы посмотреть не можем потому что если я дам команду summary то очевидно я ничего не увижу поскольку я сейчас смотрю глобальную таблицу магнитизации мне нужно смотреть внутри поэтому команда звучит несколько иначе showbgp

vref далее vref-red red как сделать верификацию бит-гип-сессии Адресное семейство all. У нас есть пиринг с марштизатором 11 и мы от него не получаем никаких префиксов. У меня есть транзитный префикс.

Какой-то префикс 151.222, который пока непонятно откуда взялся. Сейчас мы с этим разберемся. А, ну понятно, да. И мне здесь нужно убить мои loopback, которые я недавно создавал на интерфейсе loopback1. Которую я использовал для построения шамлинга. Эти loopback теперь мне не нужны. Давайте на марштизаторах R11. У меня здесь есть showrun interface of back0. Я сейчас этот loopback просто помещу внутрь BGP. router BGP100. Окей. router 11, 12, 14. И пропишу network 11, 11, 11, 11. Сейчас я поправлю.

И на 14. Валя. Смотрим, что у нас на наших CE марштизаторах происходит. И, с вашего позволения, я пока погашу интерфейс G4. То есть это интерфейс, который соединяет CE марштизаторы напрямую. У меня будут пока такие. Независимые сайты. Итак, на марштизаторе R11. Show IP route BGP. Обратите внимание, таблица марштизации BGP пуста. При этом, если я приду на PE марштизатор, show IP route. В принципе, здесь BGP-шный префикс это и есть. То есть, видите, у меня есть префикс, который я получаю от первого CE марштизатора, от второго и от четвертого.

То есть, очевидно, что маршруты из VPN V4 таблицы в BGP, в VRF таблицу, они нормально экспортируются. То есть экспорт-импорт у нас везде происходит корректно. Но почему-то на CE раутере BGP-шных маршрутов нет. Здесь какой-то есть. И на 14. Ок. Вопрос к вам. Вопрос к вам. Как вы думаете, почему на CE марштизаторе не знают любопытки друг друга? Знают любопытки друг друга. Друг друга. Давайте вместе с вами об этом подумаем. Чтобы ответить на этот вопрос, нам нужно будет с вами немножко вспомнить, как работает BGP и понять, что мешает.

Либо PE марштизатору передать апдейт в сторону CE, либо, возможно, другой сценарий. Правильно? То есть у нас CE в принципе может просто не принимать эти апдейты. Не принимать эти апдейты. С вашего позволения я на одном из CE марштизаторов запущу. Обычно в таких ситуациях вам может помочь дебаг. То есть говорим debug.ip.bgp.updates. Нас интересует входящий апдейт. И давайте заклирим BGP-сессию. Clear.ip.bgp.in. То есть мы запросим BM-эштегатор переслать нам эти апдейты. Здесь я бы хотел обратить ваше внимание вот на что. То есть мы получаем какие-то апдейты на CE. В частности, как вы видите, мы получаем апдейт на 12 префикс, а мы получаем апдейт на 14 префикс.

Но оба этих апдейта отбрасываются нашим CE марштизатором. Из-за чего? IS-path contains our own IS. То есть у нас получается такой факт, что CE марштизатор получает BGP-update, в котором в атрибуте IS-path уже стоит номер нашей автономной системы. На самом деле, если мы посмотрим на нашу типологию, то это будет более чем логично. То есть у нас вот амортизатор R12. У него, соответственно, префикс 12, 12, 12, 12. Когда он передает апдейт в сторону PE марштизатора R2, он выставляет IS-path, выставляет свою автономную систему. То есть здесь будет 11, 12, 14.

11, 12, 14. Далее. Амортизатор R2 по IBGP передает апдейт в сторону рут-рефлектора, и рут-рефлектор передает апдейт в сторону PE марштизатора. Поскольку это IBGP-update, то автономная система не модифицируется. То есть получается путь 11, 12, 14. И далее этот префикс с PE марштизатором отправляется уже внутри VRF в сторону марштизатора R11. В этом случае модифицируется IS-path. Сначала выставляется номер автономной системы провайдера, и далее получается номер автономной системы кастомера 11, 12, 14. Далее на CE марштизаторе при входе, то есть при обработке входящего апдейта, в первую очередь анализируется, собственно говоря, вот этот атрибут. У нас на автономной системе R11 запущен IBGP-процесс с номером автономной системы 11, 12, 14.

Далее CE раутер во входящем апдейте видит номер своей автономной системы. Таким образом он решает, что этот апдейт уже в его автономке побывал, и согласно правилу IBGP-loop-prevention такой апдейт должен быть отброшен. То есть это классический IBGP-loop-прованч, ничего такого нет. Однако, мы с вами здесь точно знаем, что петли здесь у нас нет и быть не может. У нас получается end-to-end connectivity. Поэтому нам нужно, по сути, изменить что-то. Есть два варианта. Есть два варианта. Вариант номер один. Как написал Василий, мы можем дать команду на CE-маштизаторе. Мы можем дать команду, которая называется LOISIN. По сути, мы говорим следующее. Если при проверке атрибута ASPath мы видим номер нашей автономной системы,

и при этом этот номер автономной системы, что очень важно, ребят, он стоит первым. То есть он стоит в конце списка. По сути, это говорит о том, что номер, префикс был порожден в нашей автономке изначально. То в таком случае мы такой апдейт все равно инсталируем в свою IBGP-таблицу. Это непосредственно модификация IBGP-выб-провеншин. Это первый вариант. Когда мы что-то модифицируем на входе в CR. Есть второй вариант, который мы можем сделать на стороне PE-маштизатора для исходящего апдейта. Каким образом? Смотрите, на муштизаторе R1 у нас написано Naver R11 Remote AS 11, 12, 14.

И муштизатор R1 может посмотреть, какой BGP-атрибут ASPath он будет высылать. В частности, он видит, что будет высылаться атрибут вот этот вот. То есть 100, 11, 12, 14. То есть муштизатор R1 может понять, что он будет высылать префикс, и при этом есть вероятность того, что на входе у соседа такой апдейт будет дроп. Ну, потому что мы отсылаем его соседу, который находится в автономной системе 11, 12, 14, и этот же номер автомки уже содержится в нашем ASPath. Поэтому мы можем в таком случае выпилить номер автономной системы 11, 12, 14 из ASPath и заменить его на наш собственный апдейт. То есть мы меняем номер автономной системы кастомера на номер нашей собственной автономной системы. Далее добавляем к нему номер нашей автономной системы по правилам обычного IBGP

и отправляем этот апдейт в сторону CE. Василий, единственная такая команда называется не replace1. Replace1 нужна, replace1 нужна, а если она нужна, когда вы используете в конфедерации, вы используете частную автономную систему, например, вы хотите выпилить частную автономную систему, когда провайдеры дают. Вот эта фича называется AS Override. То есть вы просто переписываете номер одной автономки на свою собственную. Какой из этих двух методов выбрать на самом деле зависит от ваших пожеланий. Обычно провайдеры это выставляют на своей стороне, и заказчику об этом думать не нужно. Давайте проверим, как работают обе эти технологии. Давайте на мартизаторе R11. По форме сris muut Photo

allow is in. allow is in. Проверяем нашу BGP-табличку. Соответственно, вот она. У нас появились лупбеки наших удаленных мартизаторов. Мартизатор 12 и мартизатор 14. Если мы посмотрим show IP BGP, то, видите, есть номер в айспасе, номер в том системе 100 и 11, 12, 14, хотя на нашем собственном мартизаторе запущен абсолютно такой же процесс BGP. Это первый вариант. Второй вариант. На мартизаторе R2 я сделаю я сделаю AS override. Соответственно, говорим, router BGP 100, address family IPv4, RFR, neighbor 10, 2, 11, 12, AS override.

И, соответственно, на мартизаторе R12 на мартизаторе R12 и RRBGP. появились лупбеки других цели и по команде show IPBGP вот то, о чем я вам говорил. то есть у нас вместо реального, то есть видите, вот этот номер сотый, вот он появился из-за того, что provider как раз начал подставлять номер в свою автономную систему. Окей. Ребята, это понятно? то есть для чего она нужна?

Она нужна в том случае, если вы используете, то есть если вы используете L3 VPN и при этом используете одну и ту же автономную систему в двух разных офисах. Хорошо. Вообще, я не уверен, на самом деле, что это можно сделать. По крайней мере, я никогда об этом не задумывался. Да и смысла, на самом деле, никакого нет. ASPayPay нужен как минимум для того, чтобы сохранить длину ASPay на корректном уровне. Потому что должен показать, что трафик проходит через какую-то автономку реально в транзите. Мы стараемся их сохранить. Следующий нюанс, который я хотел бы вам показать, он связан как раз таки с технологией ASOveright

и он будет применен для случаев, когда у нас появляется BGP Multihoming. То есть, у нас вот здесь появляется линк. Здесь появляется линк. У нас красный, но не забываем. И предположим, да, предположим, ну, так, просто для большей ясности, для иногда понимания проблемы, у нас вот здесь есть еще некий мужетизатор, некий мужетизатор Rx, который вот так вот имеет связь. И предположим, что вот это у нас все, а на самом деле один офис. То есть, скажем, ваш офис в Питере, там, в Москве. У вас просто два подключения к сервис-провайдеру для отказа устойчивости. Но у вас получается, что здесь лупбак, например, в этот лупбак адвертайзите по BGP. Этот лупбак вы отдаете, вы отдаете его в сторону мужетизатора R11, отдаете его в сторону мужетизатора R12.

Далее, амортизатор R11. Да, и важно, важно то, что, например, провайдеры у себя, провайдеры у себя настроили технологию IS-override. То есть, соответственно, если, по сути, если настраивается IS-override, то что происходит? Происходит некий хак автономный, то есть этого IS-pass, то есть, ну, а как вы понимаете, любое изменение атрибута, которое, скажем так, которое первоначально не подразумевало, что оно будет изменяться в таких ситуациях, оно может привести к некоторым таким, скажем, нежелательным последствиям. Давайте с вами это, собственно говоря, последствия и разберем. Далее, мусора 12

В сторону мавжизатора R12. Таким образом, на мавжизаторе R12 происходит сравнение двух BGP апдейтов. И далее, в зависимости от того, какой путь с точки зрения мавжизатора R12 лучше, тот и будет заинсталлирован. Предположим, что на мавжизаторе R12 вы настроили в сторону мавжизатора R2 большой Local Preference. Например, вы настроили Local Preference 200. Для чего обычно Local Preference завышают? Для того, чтобы предпочесть какую-то точку выхода во внешний мир. Предположим, в нашем случае вы хотите выходить через мавжизатор R12.

Что происходит на мавжизаторе R12? Он сравнивает апдейт от нашего мавжизатора Rx и от мавжизатора R2. Если Local Preference был завышен для мавжизатора R2, то мавжизаторам R12, то есть CR-аутером, как наилучший маршрут выбирается вот этот красный префикс. То есть он будет помечен как Best. Вопрос к вам, ребят. Если сейчас мавжизатор R12 запустить трассировку на лупбек мавжизатора Rx, по какому пути он пойдет? Давайте, давайте.

Почему через Rx? Мы только что с вами поговорили, что мавжизатор R12 выбирает наилучший путь через R2. Потому что у него лучший Local Preference настроен. То есть у вас получается так, что мавжизатор R12 выбирает в качественных схопах R2. И у вас трафик на Rx тот же ASN, что... Ну, да, да, что это одна наша автономная система. Да, то есть смотрите, у вас трафик полетит вот так вот. Да, то есть у вас трафик полетит через MPLS и вернется вот сюда. Вернется вот сюда. И обратный трафик, да, обратный трафик может полететь точно так же. Почему?

То есть, да, то есть этот трафик летит от R12 к Rx. Чтобы разобраться, как полетит трафик от Rx к R12, да, что у нас произойдет? Посмотрите, у нас будет R12 вышлить BGP Update в сторону Rx. И второй BGP Update, да, до него дойдет вот так вот через облако. Правильно? Почему? Потому что мы, если скипаем, да, то есть если мы на провайдере, да, на P.E. делаем AS Override, да, AS Override, то муницизатор Rx не поймет, что это как бы Ctrl-plane петля и будет как бы получит два апдейта BGP, которые будут сравнивать между собой. Соответственно, есть вероятность того, что у нас и обратный трафик, да, побежит вот так же через облако. Да, побежит вот так через облако. Ребята, утверждать, что эта проблема, ну, наверное, некорректна. Ну, потому что, помните, мы с вами когда рассматривали вопрос с SPF,

мы тоже могли, то есть у нас по умолчанию трафик ходил как раз-таки через прямое соединение, да, и мы искали пути, как завернуть его через MPLS. С BGP у нас получается иная проблема, да, то есть если мы используем AS Override, то у нас появляется вероятность того, что весь трафик, внутри даже сайта, да, может ходить через MPLS-ный облако. Как с этим бороться, если вам хочется, чтобы ваш локальный трафик, да, ходил внутри как бы вашего сайта по прямым линкам? Для этого, для этого в BGP было придумано специальное комьюнити. Помните, мы когда с вами говорили о RAW-таргетах, я вам сказал, что это комьюнити, то есть по сути просто некое число, некая метка, которая прицепляется к BGP-апдейту и передается между маршрутизаторами, да, то есть далее на маршрутизаторах этот апдейт может как-то обрабатываться, и в зависимости, например, от политика, импорт RAW-таргет, да, префикс будет помещаться в ту или иную вероятность.

Что мы делаем? То есть, смотрите, мы считаем, да, что у нас вот это все один сайт, один сайт. По сути, по сути, что мы можем сделать? Смотрите, например, когда маршрутизатор R12 передает какой-то префикс нам вот сюда, какой-то префикс нам вот сюда. Мы на PE можем применить некую входную политику, то есть политика input. мы можем сказать, скажем, set, скажем, community, set community x. То есть мы все префиксы, которые получаем от CE12, помечаем неким community. Далее, далее. Передаем этот префикс на PE-маштизатор. На PE-маштизатор. На второй PE-маштизатор. Далее, далее. Пишем outgoing политику следующего вида.

match community x и, например, action deny. То есть плюс deny. То есть, если мы точно знаем, что CE12 и CE11 – это два маршрутизатора, которые находятся на одном и том же сайте, мы, в общем-то, вольны сделать такую конструкцию, если нас, скажем, заказчик попросит. То есть мы, по сути, не даем из-за того, что мы модифицируем iSpass, нам нужно некое дополнительное средство, которое позволит такие апдейты не передавать между сайтами при необходимости. Конечно, вот такую манипуляцию можно сделать вручную. То есть действительно на всех PE делать входящую политику и исходящую. Но поскольку это, скажем так, задача, которая встречается довольно-таки часто, то для этого вам достаточно просто сконфигурировать комьюнити,

которая называется Site of Origin. S-P-O, то есть Site of Origin. Но на PE-маштизаторе оно конфигурируется для каждого нейбора. И по сути своей, то есть если вы сконфигурируете Site of Origin одинаковый на PE-2 и на PE-1, то вот эти конструкции, вот это output и input, они на самом деле будут просто применены автоматно относительно комьюнити, которая будет называться S-POP. Давайте с вами рассмотрим на примере. Давайте с вами рассмотрим на примере. Например, на маштизаторе R2. Раутер, раутер BGP, 100, адрес family, IPv4, VRIF, IPv4,

VRIF. Давайте обратим внимание на следующее. Смотрите, сейчас, сейчас, сейчас, мужицатор R11, show IP, раут, BGP, то есть он знает о 12 префиксе, он знает о 12 префиксе. Итак, мы говорим здесь, на PE-маштизаторе говорим, neighbor, neighbor, 10, 2, 12, 12, 12, 12, 12, 12, 12, здесь, видите, есть, site of origin extended community. Мы просто говорим, что все апдейты, которые приходят от данного соседа, мы, соответственно, помечаем сайт of origin таким. Соответственно, если мы хотим отправить апдейты в сторону этого соседа, то мы, прежде всего, проверяем, нет ли в этом апдейте указанного site of origin. Если site of origin есть, и он совпадает с тем, что мы сконфигурируем на данном neighbor, мы такой апдейт не передаем.

Далее. SOO. И далее указываем community. Ну, например, пусть это будет community 100, например, 100, то есть, условно говоря, скажем, сот. Наш номер в основной системе и, скажем, как ID нашего заказчика. Окей. И, соответственно, на PE-маврицизаторе, на PE1 делаем то же самое. Roundup. E100. RoutesFamily. IPO4. Верайф. Right. Naiba. 10. 1. 11. 11. SOO. 100. Итак, теперь проверяем табличку мартизации.

Упс. Случайно. Не было апдейта. Не было апдейта. Не было апдейта. Не было апдейта. Так, сейчас. И... давайте проверим на мусортере R1 для начала. ShowBGP, VPNV4, Unicast. Упс. Упс. Упс. Упс. Упс. Сейчас мы получаем... Сейчас мы должны получать префикс 11. 11. 11. 11. Web 2.

Elizabeth. 11. Я отвертажу network. Вот я получил префикс. 11, 11, 11, 11. И обратите внимание, вот он, видите, site of region 100, 100, и для префикса 12, 12, 12. Давайте проверим. Здесь нету. Видимо, из-за того, что мне нужно прям, видите, видимо, сайт for region требует передергивания сессии. То есть, недостаточно обновить апдейты. ждем.

К нам сейчас прилетел BGP withdraw, который удалил наш BGP маршрут, поскольку сетка стала недоступна за другим P. BGP. И сейчас мы просто ждем, пока BGP сконвергирует. отлично. Отлично. Теперь мы получаем, да, то есть раньше у нас как Extended Community передавался просто RouteTarget. Теперь мы от Amorтизатора R2, то есть от P2, получаем в том числе Extended Community с сайтов origin. И теперь, если все хорошо, то есть если все правильно, то мы на Amorтизаторе R11, то есть мы не получаем LoopBack, Amorтизатора R2, E12. То есть, ну, конкретно в нашей топологии, да,

может быть, не так уж прямо очевидно, но, по крайней мере, как работает сайт of origin, здесь видно. И пример, когда он может быть полезен, я, в общем-то, привел. То есть рекомендуется настраивать ССО, если заказчик вас просит о том, что у него есть мультихоминг подключения к вам, и ему бы хотелось исключить вероятность того, чтобы трафик внутри сайта ходил через MPLS облако, да, то есть он хочет, чтобы трафик внутри сайта ходил локально. Ребят, по ССО вопросы остались, нет? По ССО, по оверрайду, по LOI-сыну. Ну, что ж, если вопросов нет,

то я предлагаю двигаться, а если просто не заменять номер S? Смотри, действительно, да, если ты не будешь заменять номер автономной системы, то, наверное, такого кейса ты не получишь, да, поскольку, конечно, на CE-машизатор ты сделаешь, ты сделаешь LOI-сын, но тут, понимаешь, если ты не будешь делать, а ясс убирать, у тебя может возникнуть другая проблема. Итак, у нас, например, здесь есть линк, да, здесь есть некий вот этот еще машизатор. Есть машизатор. Давайте подумаем, что будет, если мы не будем заменять номер автономной системы. Это но. Когда префикс передается от машизатора R14 в сторону машизатора R4, мы выставляем номер нашей автономной системы, да, 11, 12, 14. То есть, апдейт передается вот сюда,

да, дальше он передается вот сюда, вот, и здесь у нас аспас будет 11, там, 11, 12, 14, ну, и 100, единственное, местами передают. Но здесь мы делаем, то есть, если мы хотим такой префикс принять, да, мы вынуждены делать allow asin. Правильно? Правильно. Далее, мы этот префикс отдаем от R11 в сторону машизатора R. Ребята, если мы на машизаторе, вот на черном машизаторе R, мы должны делать allow asin или нет? Почему не должны? Какой aspass у нас будет вот на этом пути? У нас aspass будет абсолютно таким же, ребят.

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

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

на самом деле, про BGP здесь все. То есть, на самом деле, видите, BGP хорош тем, что у вас облегчается, у вас облегчается работа на P-е-раутере, вам не нужно делать взаимные дистрибуции, скажем, из USPF в BGP, из BGP в USPF, но появляются некие другие причудливые вещи, вам нужно теперь внимательно следить за USPF, и как-то его время от времени модифицировать. окей.