- как правильно анонсировать по bgp суммарный маршрут на JunOS?,
 ivb, 13:32 , 20-Фев-17 (1)Сделать aggregate маршруты, можно passive.
В полиси Export BGP Указать from protocol aggregate и from route-filter если требуется.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 16:22 , 20-Фев-17 (2)
Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный трафик.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, Аноним, 02:29 , 21-Фев-17 (3)
> Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный
> трафик.так оно у вас и не пойдет по этому маршруту, а пойдет по more-specific маршрутам на те сети, которые реальны. Это же не фаервол.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:44 , 21-Фев-17 (5)
>> Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный
>> трафик.
> так оно у вас и не пойдет по этому маршруту, а пойдет
> по more-specific маршрутам на те сети, которые реальны. Это же не
> фаервол.нет, не так. От пункта А, подключенного только по каналу M в пункт С прилетает анонсированный им префикс его (пункта А) локальной сети, но этот префикс из-за отсутствия связности между транзитными для нас сетями операторов не передается в пункт B, подключенный только по каналу R. Т.е. локальная сеть пункта А в пункте B будет покрыта только aggregate маршрутом с next-hop reject/discard, никакого more specific маршрута в пункт B от пункта А не прилетит.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, Аноним, 23:34 , 21-Фев-17 (7)
> нет, не так. От пункта А, подключенного только по каналу M в
> пункт С прилетает анонсированный им префикс его (пункта А) локальной сети,
> но этот префикс из-за отсутствия связности между транзитными для нас сетями
> операторов не передается в пункт B, подключенный только по каналу R.
> Т.е. локальная сеть пункта А в пункте B будет покрыта только
> aggregate маршрутом с next-hop reject/discard, никакого more specific маршрута в пункт
> B от пункта А не прилетит.Вы сами запутались. more-specific прилетит на C, и этого достаточно для форвардинга. На C же будет нужный маршрут.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:14 , 22-Фев-17 (10)
> Вы сами запутались. more-specific прилетит на C, и этого достаточно для форвардинга.
> На C же будет нужный маршрут.Прилететь-то от А в С он прилетит по каналу провайдера M, но, откуда этот префикс или менее специфичный, покрывающий его, возьмется на B с рабочим каналом R? Т.е. сначала трафик от B должен как-то добраться до С и только потом уже сработает то, о чем Вы говорите. Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в таблице маршрутизации и с next-hop-self (а не reject/discard)?
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 07:38 , 21-Фев-17 (4)
>[оверквотинг удален]
> я застрял на этой простой вещи. Этот суммарный маршрут отсутствует в
> таблице маршрутизации объекта С и соответственно не будет анонсироваться пирам (операторам),
> несмотря на то, что я его указал в префикс листах политики
> экспорта bgp. Можно маршрут добавить в статику, но что правильно указать
> в этом случае в качестве next-hop? Самое простое - discard/reject. При
> этом все нормально анонсируется, на объектах суммарный префикс принимается, но толку
> от этого все равно нет, т.к. с таким next-hop транзитный трафик
> через объект С запрещается. Читал про aggregate/generate маршруты, команду advertise-inactive,
> но что-то так и не получается.
> Прошу помощи.Если сети локальные - что мешает использовать разные номера AS для разных объектов и построить "как в инете"???
Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет а если есть возможность туннели через IP построить....
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:53 , 21-Фев-17 (6)
> Если сети локальные - что мешает использовать разные номера AS для разных
> объектов и построить "как в инете"???
> Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
> Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет Так именно и сделано, но либо я Вас не совсем понял, либо Вы не совсем внимательно прочитали. Если нет связности между транзитными для нас сетями двух операторов, то мы теряем и связность между анонсируемыми нами локальными сетями объектов в ситуации, когда 2 объекта подключены каждый только к одному и при этом разным операторам. Для этого и хочу сделать транзит через один из своих объектов. > а если есть возможность туннели через IP построить.... с этого, как раз и мигрировали на плоскую сеть
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 08:48 , 22-Фев-17 (8)
>[оверквотинг удален]
>> Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
>> Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет
> Так именно и сделано, но либо я Вас не совсем понял, либо
> Вы не совсем внимательно прочитали. Если нет связности между транзитными для
> нас сетями двух операторов, то мы теряем и связность между анонсируемыми
> нами локальными сетями объектов в ситуации, когда 2 объекта подключены каждый
> только к одному и при этом разным операторам. Для этого и
> хочу сделать транзит через один из своих объектов.
>> а если есть возможность туннели через IP построить....
> с этого, как раз и мигрировали на плоскую сеть Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные от объекта "С" и наоборот???
Фильтры так настроены?? политика такая?? так поправте фильтры-политику
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:01 , 22-Фев-17 (9)
> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
> от объекта "С" и наоборот???
> Фильтры так настроены?? политика такая?? так поправте фильтры-политику потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо. Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно доставляет все эти префиксы другим объектам, но только в рамках своей транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие префиксы, но только с помощью одного объекта - С и лучше одним более общим маршрутом. Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в таблице маршрутизации и с next-hop-self (а не reject/discard)?
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, Аноним, 18:03 , 23-Фев-17 (11)
> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
> таблице маршрутизации и с next-hop-self (а не reject/discard)?с next-hop-self это как? заруливать трафик на процессор? Предлагаю сузить суть вопроса: нарисуйте схемку со стрелочками и облачками, а то сейчас непонятно вообще, что где ходит а что нет, и почему агрегейт/генерейт не подходитю
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 11:56 , 25-Фев-17 (12)
>> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
>> таблице маршрутизации и с next-hop-self (а не reject/discard)?
> с next-hop-self это как? заруливать трафик на процессор?
> Предлагаю сузить суть вопроса: нарисуйте схемку со стрелочками и облачками, а то
> сейчас непонятно вообще, что где ходит а что нет, и почему
> агрегейт/генерейт не подходитю next-hop-self (точнее в JunOS это команда "next-hop self") - стандартное поведение изменения адреса next-hop на адрес передавшего префикс пира при его (префикса) передаче по EBGP и опциональное для IBGP я правильно понимаю, что картинки/вложения здесь не поддерживаются, т.е. требуется ссылка на внешний ресурс? Вот картинки (jpg и docx):
https://yadi.sk/i/INWGyPLT3EZdyX
https://yadi.sk/i/okdsEgiS3EZdhg Кратко повторюсь. Объекты анонсируют провайдерам только свои локальные сети и принимают все префиксы локальных сетей других объектов, полученные через своих пиров/провайдеров. Редистрибьютить чужие локалки - неправильно, это резко увеличивает объем маршрутной информации и требования к памяти роутеров.
При нормальной работе каждый объект подключен к обоим провайдерам M и R. На рисунке приведена аварийная ситуация, когда на объектах A и B по одному (и разному) провайдеру потеряно. А связан с С через провайдера M, B связан с С через провайдера R. Требуется связать A с B с помощью С. Для этого решено от С помимо его локальной сети анонсировать дополнительно специальный префикс, покрывающий сети и А, и B, и С. Т.к. такой локальной сети у С нет, то сначала требуется как-то установить этот префикс в его таблицу маршрутизации, что бы потом можно было его экспортировать по bgp обоим пирам/провайдерам.
Для этого можно добавить на С статический маршрут в суммарную сеть, но при этом потребуется указать next-hop. Какой?
Можно использовать aggregate маршрут, но для него next-hop возможен только reject/discard, а это запретит транзитный трафик через С. Можно указать generate маршрут, но для него также требуется next-hop. Какой?
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 09:30 , 27-Фев-17 (13)
>> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
>> от объекта "С" и наоборот???
>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо. УХТЫ!!!
А как же интернет-то тогда работает вцелом????? Открою тайну - именно переобьявляет полученные от соседа сети.... > Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно
> доставляет все эти префиксы другим объектам, но только в рамках своей
> транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие
> префиксы, но только с помощью одного объекта - С и лучше
> одним более общим маршрутом.
> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
> таблице маршрутизации и с next-hop-self (а не reject/discard)? Если этот маршрут получаем по eBGP - Правкой политики и фильтров на out направление.
Если его вообще нет нигде - то по классике:
создаем маршрут в null0 и его анонсим соседям.
Лет 30 уже этому решению, считается классическим примером...
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 09:35 , 27-Фев-17 (14)
Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак не хотите понять, что ваши объекты - точно такие же провайдеры!
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 12:02 , 27-Фев-17 (16)
> Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак
> не хотите понять, что ваши объекты - точно такие же провайдеры! не верно, т.к. пропуск транзитного трафика для объектов (клиентов) не является их задачей (за исключением объекта С) и даже вредно в отличие от провайдеров M и R
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 11:59 , 27-Фев-17 (15)
>>> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
>>> от объекта "С" и наоборот???
>>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
>> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.
> УХТЫ!!!
> А как же интернет-то тогда работает вцелом?????
> Открою тайну - именно переобьявляет полученные от соседа сети....Это если ваша задача именно предоставлять услуги связи для других. Здесь же конечный объект этими услугами только пользуется и он не должен пропускать через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение - только объект С. > Если этот маршрут получаем по eBGP - Правкой политики и фильтров на
> out направление.
> Если его вообще нет нигде - то по классике:
> создаем маршрут в null0 и его анонсим соседям.
> Лет 30 уже этому решению, считается классическим примером... Именно, его нигде нет, но Ваше предложение "создаем маршрут в null0" - это в JunOS делается как aggregate route с next-hop reject/discard. Я уже несколько раз писал, почему это не работает/подходит в данном конкретном случае.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 08:53 , 28-Фев-17 (17)
>[оверквотинг удален]
>>>> от объекта "С" и наоборот???
>>>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
>>> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.
>> УХТЫ!!!
>> А как же интернет-то тогда работает вцелом?????
>> Открою тайну - именно переобьявляет полученные от соседа сети....
> Это если ваша задача именно предоставлять услуги связи для других. Здесь же
> конечный объект этими услугами только пользуется и он не должен пропускать
> через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение
> - только объект С.ВО! т.е. объект С становится "провайдером для объектов А и В" вот и разрешите ему объявлять сети автономных систем объектов А и В. А если копнуть чуть дальше - то почему бы А и В не уровнять в правах с С? >> Если этот маршрут получаем по eBGP - Правкой политики и фильтров на
>> out направление.
>> Если его вообще нет нигде - то по классике:
>> создаем маршрут в null0 и его анонсим соседям.
>> Лет 30 уже этому решению, считается классическим примером...
> Именно, его нигде нет, но Ваше предложение "создаем маршрут в null0" -
> это в JunOS делается как aggregate route с next-hop reject/discard. Я
> уже несколько раз писал, почему это не работает/подходит в данном конкретном
> случае. Вот похоже ваш случай.
https://habrahabr.ru/post/274873/
С подробностями вроде даже.
Цитата:
Теперь осталось понять природу generate route. Generate route по сути тот же aggregate route, но с реальным next-hop, который берется из contribute route:
....
Кто пирами на А,В,С является? рутеры провайдера или ваши?
Вы от провов получаете только свои префиксы или еще и горку чужих??
Если у вас MPLS VPN L3 - то в теории вам должны прилетать только ваши префиксы (иначе смысл MPLS L3 городить лично для меня не совсем понятен.).
И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ???? BGP позволяет играть префиксами, анонсами и еще кучей параметров так, как надо вам и в этом плане гораздо гибче IGP протоколов.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 12:19 , 28-Фев-17 (18)
> ВО! т.е. объект С становится "провайдером для объектов А и В" вот
> и разрешите ему объявлять сети автономных систем объектов А и В. да, уже и сам решил попробовать так сделать. > А если копнуть чуть дальше - то почему бы А и В
> не уровнять в правах с С? не нужно этого. разные объекты имеют разные по скорости каналы подключения к провайдерам и генерят разный по объему трафик. Следует избегать ситуации, когда через низкоскоростной объект будет пытаться ходить трафик от высокоскоростного да еще и значительного объема. > Вот похоже ваш случай.
> https://habrahabr.ru/post/274873/
> С подробностями вроде даже.
> Цитата:
> Теперь осталось понять природу generate route. Generate route по сути тот же
> aggregate route, но с реальным next-hop, который берется из contribute route: эту статью я читал.
> Кто пирами на А,В,С является? рутеры провайдера или ваши?
провайдера
> Вы от провов получаете только свои префиксы или еще и горку чужих?? свои
> Если у вас MPLS VPN L3 - то в теории вам должны
> прилетать только ваши префиксы (иначе смысл MPLS L3 городить лично для
> меня не совсем понятен.). так и есть
> И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО
> СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????
> BGP позволяет играть префиксами, анонсами и еще кучей параметров так, как надо
> вам и в этом плане гораздо гибче IGP протоколов. это все понятно. только вопрос остался: можно ли (как?) анонсировать сеть, отсутствующую на роутере и, следовательно, в его таблице маршрутизации? Возможно, это неверный путь решения начальной задачи, но все равно хочется разобраться и с этим.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 11:28 , 01-Мрт-17 (19)
>[оверквотинг удален]
>> меня не совсем понятен.).
> так и есть
>> И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО
>> СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????
>> BGP позволяет играть префиксами, анонсами и еще кучей параметров так, как надо
>> вам и в этом плане гораздо гибче IGP протоколов.
> это все понятно. только вопрос остался: можно ли (как?) анонсировать сеть, отсутствующую
> на роутере и, следовательно, в его таблице маршрутизации? Возможно, это неверный
> путь решения начальной задачи, но все равно хочется разобраться и с
> этим.:) там же в статье вроде все описано.... В BGP для нейбора export OUT-FILTER;
Политика
policy-statement OUT-FILTER {
term 01 {
from {
route-filter 10.0.0.0/8 exact accept;
}
then accept;
}
term 99 {
then reject;
}
}
И сам маршрут:
generate {
route 10.0.0.0/8 policy aggregate-contribute-routes;
policy-options {
prefix-list contribute-1 {
10.0.0.0/30; ## в данном примере это будет contribute route
10.0.1.0/30;
10.0.2.0/30;
10.1.1.1/32;
10.1.1.2/32;
10.1.1.3/32;
}
policy-statement aggregate-contribute-routes {
term 1 {
from {
prefix-list contribute-1;
}
then accept;
}
}
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 14:19 , 01-Мрт-17 (20)
У меня небольшие отличия. Вместо prefix-list я импортирую маршруты, полученные по bgp от пиров (провайдеров), т.к. маршрутов довольно много и они время от времени могут меняться.
При этом, когда я затем анонсирую пирам aggregate-route, созданный на основе этих принятых, он отдается одному пиру с next-hop self, а другому с адресом этого пира. Видимо получается так потому, что пришедшие от одного пира префиксы при анонсе другому (в виде уже aggregate-route) пройдут через AS транзитного объекта С и в этом случае ebgp подменит адрес next-hop на адрес пира, который передал aggregate-route, т.е. самого объекта С. Если же префиксы, пришедшие от пира возвращаются ему же (конечно тоже в виде aggregate-route), то next-hop-ом сохраняется адрес этого пира. Конечные объекты, получив префикс с таким next-hop не имеют к нему маршрут и следовательно трафик от них не может достигнуть и транзита С.
Надеюсь не запутал, но мне кажется, именно так все срабатывает. В итоге одному пиру aggregate-prefix передается с правильным (нужным мне) next-hop self, а другому - с недостижимым. Опция resolve, которая должна решать подобную ситуацию, мне не помогла, почему не разобрался.
Мне бы, возможно, подошел в таблице маршрутизации транзитного объекта С маршрут с next-hop, указывающим на этот же самый узел, но такой маршрут, как я понял, установить в таблицу невозможно.
- как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 17:24 , 04-Апр-17 (21)
решил, наконец-то! Как обычно, следует просто четко понимать, что требуется (в моем случае не хватало именно этого) и внимательно читать, в частности, упомянутую выше статью на Хабре, за что её автору отдельное спасибо.
Кратко: В моем случае используются два пограничника, связанные по iBGP, описываю для этой ситуации. В суммарный (generate, а не aggregate!) маршрут собираем, полученные iBGP префиксы от второго внутреннего пира и просто добавляем в политику экспорта (уже по eBGP) внешнему пиру этот суммарный маршрут. Все очень просто.Примерно так: [edit routing-options]
generate {
route X.Y.0.0/16 policy GENERATE; <== суммарный маршрут для анонса
}
... [edit policy-options]
policy-statement GENERATE {
from {
protocol bgp; <== собираем на основе префиксов, полученных по iBGP
neighbor A.B.C.D; <== от второго пира A.B.C.D
route-filter X.Y.0.0/16 orlonger;
}
then accept;
}
...
policy-statement BGP_OUT {
...
term GENERATE {
from {
protocol aggregate; <== для generate маршрута протокол все равно aggregate
route-filter X.Y.0.0/16 exact; <== для единственного generate маршрута это, пожалуй, и не требуется
}
then accept;
}
term OTHER {
then reject;
}
} все заработало.
|
Версия для распечатки
как правильно анонсировать по bgp суммарный маршрут на JunOS?, 
