Суммаризация в BGP: aggregate-address и AS-SET

Следующей темой нашего занятия будет суммаризация префиксов в BGP-сетях. В принципе, суммаризация в чем-то похожа на суммаризацию в EGRP. Она похожа тем, что суммарный маршрут может быть создан на любом маршруте в сети, независимо от того, где были порождены специфики. Давайте рассмотрим на примере, как работает суммаризация и каким проблемам она может привести. Для начала создадим на маршруте заторе R3 несколько лупбеков, которые потом будем суммаризировать. Итак, я создам интерфейс лупбек 1.

У него будет IP-адрес 200.0.0.3. 255.255.255. Будет интерфейс лупбек 2 с IP-адресом 200.0.1.3. Будет интерфейс лупбек 3 с IP-адресом 200.0.2.3. И будет интерфейс. Я думаю, этого будет достаточно. Так, был неправильный маск. Хорошо, теперь проанонсируем эти префиксы в BGP процесс. Работа 255.0.3. Варим Network. 200.0.0.3. Маск. 200.0.0.1.2.

Так, нашел IP-BGP. Убедимся в том, что данные префиксы попали в BGP-таблицу. И в частности убедимся в том, что они появились, например, на мушке затрагившись. BGP. Есть. Это хорошо. Есть префикс 200.0.0.3. Я, к сожалению, здесь не вижу префиксов 200.0.1.3 и 200.0.2.3. Наклину 200. А нет, не есть. То есть, видимо, я просто не до конца пролистал. Хорошо. Как видите, все интерфрайз-компании будут объявлять в мир. Очень специфичный маршрут. И в какой-то момент это придет к коллапсу. Как вы знаете, агрегация чаще всего хороша в определенных местах.

Например, на границе, скажем, между двумя сетями. Поэтому мы можем присумморизовать маршруты, как на муштизаторе, например, R3. То есть тот муштизатор, кто объявлял сети, может их сумморизовать. Либо же это может делать любой другой муштизатор. При условии, что более специфичный маршрут есть в нем в таблице муштизации. Давайте настроим сумморизацию маршрутов на муштизаторе R1 и на муштизаторе R2. Посмотрим, что произойдет. Для сумморизации используется специальная команда, которая называется aggregate address. Далее вы указываете подсеть, в которую вы будете сумморизовывать все свои более специфичные префиксы. Поскольку у меня сеть префиксы 200, 0, я просумморизую их, например, в 200, 8.

Или давайте в 200, 0, 16. Итак, адрес 200, 0, 0, 0. И маска 255, 255, 00. Это на муштизаторе R1. И то же самое мы можем сделать на муштизаторе R3. Ой. Не на муштизаторе R3 я хотел это сделать. А на муштизаторе R2. Готово. То есть у нас в текущий момент муштизаторы R1 и R2 генерируют суммарный маршрут.

Давайте посмотрим BGP таблицу. Show IP BGP. Обратите внимание, что у нас появился маршрут 200, 0, 0, 0, с 16 маской. При этом у нас есть две записи относительно данного префикса. Первая запись имеет на схобе 4, 0. То есть говорит о том, что этот маршрут был порожден нами. И второй маршрут, который был получен от муштизатора R1. На муштизаторе R1 должна быть противоположная ситуация. Есть маршрут, который был сгенерирован локально. И также маршрут, который был получен от муштизатора R2. Что более интересно, обратите внимание, в таблице до сих пор присутствуют более специфичные префиксы, которые входят в суммарный диапазон. То есть это первое. При создании суммарного маршрута более специфичные маршруты не подавляются.

То есть на самом деле просто создается отдельный префикс, то есть отдельная BGP-запись. Давайте посмотрим на эту BGP-запись. Может быть, в ней будет что-то интересное. 0.16. Итак. Что мы можем судить? Нас, наверное, будет больше интересовать тот маршрут, который сгенерировали мы сами. Во-первых, origin type выставляется в IGP. Далее. Выставляется специальный атрибут, который называется aggregated, то есть который указывает на то, что это маршрут агрегированный. То же самое мы видим для маршрута, который мы получили от муштизатора R1. И плюс-плюс выставляется атрибут, который показывает, кто этот маршрут первоначально суммаризовал.

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

Очень часто вы захотите отдавать, например, своим вышестоящим сервис-провайдерам только суммарный маршрут. Только суммарный маршрут. Это можно сделать. Для этого вам необходимо несколько видоизменить команду aggregate address. Задача aggregate address 200, 0, 0, 0, 25, 0, 0. Здесь есть дополнительная команда, которая называется summary only. То есть из названия команды, я думаю, все понятно, то есть генерируется исключительно суммарный маршрут. Нет, нам здесь это не надо. Можно это задать на маршрутизатор R1.

Готово. На маршрутизатор R2. Show IPBGP. Обратите внимание, что более специфичные префиксы, которые входят в диапазон агрегированного маршрута 200, 16, помечаются специальным флагом S. И S говорит, что это suspend или suppressed. То есть если я скажу show IPBGP, 200, 0, 0, 3, то я увижу, что этот префикс никому не передается. Not advertised to any peer. И advertisement suppressed by an aggregate. Говорит от меня о том, что данный маршрут подавлен. Данный маршрут подавлен. И, например, если я посмотрю команду show IP route, то обратите внимание на следующую вещь. На что я хочу обратить ваше внимание. Более специфичные префиксы присутствуют у меня в таблице маршрутизации.

Хоть они и подавлены, но вот эти префиксы к нам прилетели от маршрутизатора R3. При этом в таблице маршрутизации устанавливается суммарный маршрут 200, 16 с интерфейсом 0. То есть это нам говорит о чем? О том, что любой пакет, который прилетит на адрес из диапазона 200, 16, он на самом деле будет уничтожен. То есть если у вас в таблице маршрутизации указан выходной интерфейс как 0.0, это то же самое, что в Linux, вам сказать, отправить что-то на директорию slash dev slash null. То есть любой пакет, который прилетает на данную подсеть, будет уничтожен. Естественно, за исключением, если этот пакет не летит на адрес из более специфичных подсетей.

То есть это сделано, по сути, для предотвращения блокхолинга. Итак, что мы увидим на маршрутизаторе, например, R4? Show IP RAL BGP. И здесь мы видим только суммарный маршрут с 16-м маршрут. Show IP BGP. Она нам также покажет, что у нас есть только суммарный префикс и нету. Никаких спецификов. Аналогичная информация должна наблюдаться на R7. Show IP BGP. Окей. Ну так. Есть. Хорошо. А теперь давайте представим, что желтый сервис провайдер решил. Я получаю от компании A префикс, скажем, 200. Слэш 16.

Возможно ситуация, когда другие клиенты адвертайзят в желтый провайдер, например, подсети 200.1. Слэш 16. Кто-то адвертайзит, например, 200.2. Слэш 16. И вот тут желтый провайдер решает сделать следующую вещь. Я хочу, например, на маршрутизаторе R7 сагрегировать все получаемые 16-ые префиксы в 1. Например, 200. Слэш 8. И дальше этот префикс уже распространять по сети. Давайте посмотрим. Технически это сделать можно, но это иногда может привести к некоторым проблемам. Итак, мы говорим. Раутер BGP 123. Ну, извиняюсь. 4578. Например, на садах говорит. Агрегейт. Адрес 200.0.0.0.

255.0.0.0. Ну, скажем так же summary only. Обращаем внимание. Теперь show IP route BGP. У нас появляется маршрут 200.8, который устанавливается через интерфейс 0.0. И также у нас остаются подсети 200.16. 200.16. Хорошо. Что произойдет дальше? Мужчизатор R7 сгенерировал префикс. Сгенерировал префикс 200.8. И, очевидно, отдает его в сторону мускителтора R8 в сторону муск hauler على R5 в сторону муску заточаOneR4. Мужчизатор R8 отдает его в сторону мускухлизатора R9. R4 отдает его в сторону Р1 и в сторону Р2. И вот тут возникает очень интересный вопрос. Что будут делать муштизаторы R1 и R2? Должны ли они отбрасывать данное обновление?

Ведь по сути, что произошло у нас в конкретном нашем топологии? На муштизаторе R3 у нас есть некие префиксы, например, 200.0.0.3.32. Мы его суммаризовали в 200.0.0.0.16 и отправили в сторону желтого сервис-провайдера. Желтый сервис-провайдер сегрегировал этот маршрут в 200.0.8 и отдал нам его обратно. Не приведет ли это к каким-либо петлям? Давайте с вами посмотрим. Посмотрим на муштизаторе R1. Что мы видим? Show IPBGP. Обратите внимание, на муштизаторе R1 появился маршрут 200.0.8. Появился маршрут 200.0.8.

Вы скажете, а как же так? Ведь первоначальные префиксы были порождены в автономной системе 1.2.3. После этого переданы в сторону автономной системы 4.5.7.8. А после этого вернулись обратно. То есть по логике вам может показаться, что при передаче апдейта от желтого к красному путь автономной системы должен выглядеть как 45.7.8.1.2.3. Но по факту что мы видим? Мы видим, что у префикса 200.0.8 автономный ASPath состоит только из одной автономной системы 45.7.8. Show IPBGP. 200.0.0.0.8. Вот подтверждение.

При этом мы видим, что этот префикс был сегрегирован внутри автономной системы 45.7.8. И сделано это было на маршрутизаторе R7. Так почему же так происходит? Давайте для этого вернемся на маршрутизатор R7. По сути, на маршрутизаторе R7 сказано. Команда aggregate address говорит создать новый префикс. Создать новый BGP. Префикс. С параметрами для сети 200.0.8. Если есть более специфичный маршрут. То есть, по сути, на самом деле создается новый префикс. А поскольку это новый префикс, то атрибут ASPath у него будет пустым. Show IPBGP. 200.0.0.2.5.0.0.0.0. как вы видите в данном случае а и спас он отсутствует он 0 к сожалению да к

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

обрежьте внимание что теперь когда шоу ран сэкшн биджи пин аэссэта саммари он хорошо обрежьте внимание теперь когда может изотор версии генерирует некий апдейт генерирует суммарный маршрут он берет в том числе заполняет аэспас эти вот 123 здесь еще две сотни почему почему а дело в том что амортизатор начинает просматривать все специфичные маршруты и он находит в них какие номера автономных систем присутствуют в специфичных маршрут давайте для примера сделаем больше там вот так на амортизаторе r9 я создам

я создам некий loopback 9 ip адресом например 200 0 0 9 до 5 до 5 до 5 до 5 до 5 до 5 я создам раутмапу раутмапу set prepend и скажу set аэспас prepend и некий номер автономных систем например 77 89 например и 43 вернусь раутер бит же пи 9 и повешу эту этот аэспропенд для всех исходящих апдейтов нейбер 10 8 8 раутмап

set prepend аут и нейбер 10 6 9 6 раутмапу set prepend аут сделаю клеер айпи биджи пи аут для чего я это сейчас делал для чего я это сейчас делаю обратите внимание что мусор затор р 9 будет отдавать префикс 200 0 0 9 он дойдет до маршрутизатора р 8 дойдет до маршрутизатора корсей из другой стороны дома что за таракер сей дойдет префикс 200 слоя 16 при этом у этого префикса аэспас будет состоять из 102 123 100 100 100 100 поскольку у нас на муштат р 1 выставлен при пендинг а для префикса 200 слаж 9 для пресса действий саждец а

аэспас будет состоять из 9 и вот то что мы сейчас с вами написали 77 89 43 и здесь получается 77 89 43 так вот когда мы выдаем ключевую команду когда мы даем ключевую команду аэссет то маршрутизатор р 7 который делает шуморизацию начинает просматривать все специфичные префиксы нашел есть более специфичный префикс 200 слэш 16 есть более специфичный префикс 200 слэш 200 009 слэш 32 он берет аэспасы из всех специфичных префиксов и на основе них составляет атрибут вернее это на эти эти цены компонент аэспаса атрибут называется аэссет который

состоит из всех автономных систем которые присутствуют в аэспасах всех специфичных префиксов в нашем случае аэспас должен будет выглядеть примерно вот так 123 100 9 77 89 и 43 и 43 далее далее если маршрутизатор r7 после этого передаст префикс на маршрутизатор r4 маршрутизатор r4 передаст его на маршрутизатор r1 то маршрутизатор r1 когда будет проверять аэспас он в частности будет проверять и атрибут и компонент аэссет в частности он там найдет что внутри аэссета представлена автономная система номер 123 поэтому он узнает что на самом то деле на самом то деле на апдейт как бы от него уже уходил и поэтому в избежание петель такой апдейт нужно дропнуть нужно дроп

так давайте посмотрим так ли так прежде всего посмотрим на маршрутизатор r7 команду show ip gp как вы видите единственное почему то здесь нету префикса 200 009 давайте я посмотрю на маршрутизатор r8 шалайки биджи пин и на маршрутизаторе r8 его нет а да я здесь совсем забыл объявить эту сеть в биджи пи таблицу 9 network 200 0 9 маск шоу и пиджи пин 200 сажать 9 200 . 9 появился он должен был появиться на маршрутизаторе r8

вот с таким вот и спас и на маршрутизаторе r7 на маршрутизаторе с обратить внимание сейчас аэспас составляет только 123 100 100 как только у нас появился префикс еще один более специфичный вот для суммарного префикса у нас появляется а с сет который состоит из набора который скажем так является комбинацией а и спасов всех более специфичных префиксов более специфичных префикс теперь теперь вот этот префикс 200 200 слэш 8 он должен отсутствовать на маршрутизаторе r1 например брить мань раньше у нас это префикс был сейчас этого префикса нет и

чтобы убедиться в том что он отбрасывать именно из-за проверки аэссета давайте сами запустим дебага и бджп апдейт и скажем clear ip бджп 10 1 4 4 in да вот она внимание что префикс 200 00 сошелся был отброс по причине того что аэспас содержит нашу собственную айс