- как правильно анонсировать по 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; } } все заработало.
|