https://www.opennet.ru/openforum/vsluhforumID6/2126.html Имеется 3 (для рассмотрения задачи этого достаточно) однотипных объекта A, B и C. Каждый подключен (L3) к двум операторам, предоставляющим (на основе MPLS) основной (M) и резервный каналы (R) во внешний мир. Каждый из трех объектов по bgp анонсирует свои локальные сети вида (для примера пусть по одной сети) 10.Z.A.0/24, 10.Z.B.0/24 и 10.Z.C.0/24 обоим операторам. При нормальной работе получаем связность объектов каждый-с-каждым. Между сетями операторов M и R не обеспечивается связность и обмен bgp префиксами локальных сетей наших объектов. Обмен маршрутной информацией каждый из операторов обеспечивает только в пределах своей сети. Это данность, с которой приходится смириться. В этом случае, если, например, на объекте А работает только канал оператора M, а на объекте B - только канал оператора R, связность между A и B теряется, несмотря на то, что у каждого из них продолжает работать канал во внешний мир. Требуется обеспечить связность объектов и в этой ситуации.<br><br>Объект С у нас отличается от остальных тем, https://www.opennet.ru/openforum/vsluhforumID6/2126.html#21 Tue, 04 Apr 2017 14:24:53 GMT решил, наконец-то! Как обычно, следует просто четко понимать, что требуется (в моем случае не хватало именно этого) и внимательно читать, в частности, упомянутую выше статью на Хабре, за что её автору отдельное спасибо.<br>Кратко: В моем случае используются два пограничника, связанные по iBGP, описываю для этой ситуации. В суммарный (generate, а не aggregate!) маршрут собираем, полученные iBGP префиксы от второго внутреннего пира и просто добавляем в политику экспорта (уже по eBGP) внешнему пиру этот суммарный маршрут. Все очень просто.<br><br>Примерно так:<br><br>[edit routing-options]<br>generate {<br> route X.Y.0.0/16 policy GENERATE; &lt;== суммарный маршрут для анонса<br>}<br>...<br><br>[edit policy-options]<br>policy-statement GENERATE {<br> from {<br> protocol bgp; &lt;== собираем на основе префиксов, полученных по iBGP<br> neighbor A.B.C.D; &lt;== от второго пира A.B.C.D<br> route-filter X.Y.0.0/16 orlonger;<br> }<br> then accept;<br>}<br>...<br>policy-statement BGP_OUT {<br>...<br> term GENERATE {<br> from {<br> pro https://www.opennet.ru/openforum/vsluhforumID6/2126.html#20 Wed, 01 Mar 2017 11:19:49 GMT У меня небольшие отличия. Вместо prefix-list я импортирую маршруты, полученные по bgp от пиров (провайдеров), т.к. маршрутов довольно много и они время от времени могут меняться.<br>При этом, когда я затем анонсирую пирам aggregate-route, созданный на основе этих принятых, он отдается одному пиру с next-hop self, а другому с адресом этого пира. Видимо получается так потому, что пришедшие от одного пира префиксы при анонсе другому (в виде уже aggregate-route) пройдут через AS транзитного объекта С и в этом случае ebgp подменит адрес next-hop на адрес пира, который передал aggregate-route, т.е. самого объекта С. Если же префиксы, пришедшие от пира возвращаются ему же (конечно тоже в виде aggregate-route), то next-hop-ом сохраняется адрес этого пира. Конечные объекты, получив префикс с таким next-hop не имеют к нему маршрут и следовательно трафик от них не может достигнуть и транзита С.<br>Надеюсь не запутал, но мне кажется, именно так все срабатывает. В итоге одному пиру aggregate-prefix передается с правильным (ну https://www.opennet.ru/openforum/vsluhforumID6/2126.html#19 Wed, 01 Mar 2017 08:28:04 GMT &gt;[оверквотинг удален]<br>&gt;&gt; меня не совсем понятен.).<br>&gt; так и есть <br>&gt;&gt; И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО <br>&gt;&gt; СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????<br>&gt;&gt; BGP позволяет играть префиксами, анонсами и еще кучей параметров так, как надо <br>&gt;&gt; вам и в этом плане гораздо гибче IGP протоколов.<br>&gt; это все понятно. только вопрос остался: можно ли (как?) анонсировать сеть, отсутствующую <br>&gt; на роутере и, следовательно, в его таблице маршрутизации? Возможно, это неверный <br>&gt; путь решения начальной задачи, но все равно хочется разобраться и с <br>&gt; этим.<br><br>:) там же в статье вроде все описано....<br><br>В BGP для нейбора<br><br>export OUT-FILTER;<br><br><br>Политика<br> policy-statement OUT-FILTER {<br> term 01 {<br> from {<br> route-filter 10.0.0.0/8 exact accept;<br> }<br> then accept;<br> }<br> term 99 {<br> then reject;<br> }<br> }<br><br><br>И сам маршрут:<br>generate {<br> route 10.0.0.0/8 policy aggregate-contribute-routes;<br> https://www.opennet.ru/openforum/vsluhforumID6/2126.html#18 Tue, 28 Feb 2017 09:19:47 GMT &gt; ВО! т.е. объект С становится "провайдером для объектов А и В" вот <br>&gt; и разрешите ему объявлять сети автономных систем объектов А и В. <br><br>да, уже и сам решил попробовать так сделать.<br><br>&gt; А если копнуть чуть дальше - то почему бы А и В <br>&gt; не уровнять в правах с С?<br><br>не нужно этого. разные объекты имеют разные по скорости каналы подключения к провайдерам и генерят разный по объему трафик. Следует избегать ситуации, когда через низкоскоростной объект будет пытаться ходить трафик от высокоскоростного да еще и значительного объема.<br><br>&gt; Вот похоже ваш случай.<br>&gt; https://habrahabr.ru/post/274873/ <br>&gt; С подробностями вроде даже.<br>&gt; Цитата: <br>&gt; Теперь осталось понять природу generate route. Generate route по сути тот же <br>&gt; aggregate route, но с реальным next-hop, который берется из contribute route: <br><br>эту статью я читал.<br><br><br>&gt; Кто пирами на А,В,С является? рутеры провайдера или ваши?<br><br>провайдера<br>&gt; Вы от провов получаете только свои префиксы или еще и горку чужих?? <br><br>свои<br>&gt; Если у вас MPLS VPN L3 - то в тео https://www.opennet.ru/openforum/vsluhforumID6/2126.html#17 Tue, 28 Feb 2017 05:53:57 GMT &gt;[оверквотинг удален]<br>&gt;&gt;&gt;&gt; от объекта "С" и наоборот???<br>&gt;&gt;&gt;&gt; Фильтры так настроены?? политика такая?? так поправте фильтры-политику <br>&gt;&gt;&gt; потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.<br>&gt;&gt; УХТЫ!!!<br>&gt;&gt; А как же интернет-то тогда работает вцелом?????<br>&gt;&gt; Открою тайну - именно переобьявляет полученные от соседа сети....<br>&gt; Это если ваша задача именно предоставлять услуги связи для других. Здесь же <br>&gt; конечный объект этими услугами только пользуется и он не должен пропускать <br>&gt; через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение <br>&gt; - только объект С.<br><br>ВО! т.е. объект С становится "провайдером для объектов А и В" вот и разрешите ему объявлять сети автономных систем объектов А и В.<br><br>А если копнуть чуть дальше - то почему бы А и В не уровнять в правах с С? <br><br>&gt;&gt; Если этот маршрут получаем по eBGP - Правкой политики и фильтров на <br>&gt;&gt; out направление.<br>&gt;&gt; Если его вообще нет нигде - то по классике: <br>&gt;&gt; создаем маршрут в null0 и его анонсим https://www.opennet.ru/openforum/vsluhforumID6/2126.html#16 Mon, 27 Feb 2017 09:02:26 GMT &gt; Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак <br>&gt; не хотите понять, что ваши объекты - точно такие же провайдеры! <br><br>не верно, т.к. пропуск транзитного трафика для объектов (клиентов) не является их задачей (за исключением объекта С) и даже вредно в отличие от провайдеров M и R<br><br> https://www.opennet.ru/openforum/vsluhforumID6/2126.html#15 Mon, 27 Feb 2017 08:59:46 GMT &gt;&gt;&gt; Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные <br>&gt;&gt;&gt; от объекта "С" и наоборот???<br>&gt;&gt;&gt; Фильтры так настроены?? политика такая?? так поправте фильтры-политику <br>&gt;&gt; потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.<br>&gt; УХТЫ!!!<br>&gt; А как же интернет-то тогда работает вцелом?????<br>&gt; Открою тайну - именно переобьявляет полученные от соседа сети....<br><br>Это если ваша задача именно предоставлять услуги связи для других. Здесь же конечный объект этими услугами только пользуется и он не должен пропускать через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение - только объект С.<br><br>&gt; Если этот маршрут получаем по eBGP - Правкой политики и фильтров на <br>&gt; out направление.<br>&gt; Если его вообще нет нигде - то по классике: <br>&gt; создаем маршрут в null0 и его анонсим соседям.<br>&gt; Лет 30 уже этому решению, считается классическим примером...<br><br>Именно, его нигде нет, но Ваше предложение "создаем маршрут в null0" - это в JunOS делается как aggregat https://www.opennet.ru/openforum/vsluhforumID6/2126.html#14 Mon, 27 Feb 2017 06:35:52 GMT Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак не хотите понять, что ваши объекты - точно такие же провайдеры!<br> https://www.opennet.ru/openforum/vsluhforumID6/2126.html#13 Mon, 27 Feb 2017 06:30:55 GMT &gt;&gt; Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные <br>&gt;&gt; от объекта "С" и наоборот???<br>&gt;&gt; Фильтры так настроены?? политика такая?? так поправте фильтры-политику <br>&gt; потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо. <br><br>УХТЫ!!!<br>А как же интернет-то тогда работает вцелом?????<br><br>Открою тайну - именно переобьявляет полученные от соседа сети....<br><br>&gt; Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно <br>&gt; доставляет все эти префиксы другим объектам, но только в рамках своей <br>&gt; транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие <br>&gt; префиксы, но только с помощью одного объекта - С и лучше <br>&gt; одним более общим маршрутом.<br>&gt; Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в <br>&gt; таблице маршрутизации и с next-hop-self (а не reject/discard)?<br><br>Если этот маршрут получаем по eBGP - Правкой политики и фильтров на out направление.<br>Если его вообще нет нигде - то по класс