The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"как правильно анонсировать по bgp суммарный маршрут на JunOS?"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Изначальное сообщение [ Отслеживать ]

"как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 20-Фев-17, 13:08 
Имеется 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 теряется, несмотря на то, что у каждого из них продолжает работать канал во внешний мир. Требуется обеспечить связность объектов и в этой ситуации.

Объект С у нас отличается от остальных тем, что у него практически всегда работают каналы обоих операторов. Решено с этого объекта помимо его собственных локальных сетей анонсировать дополнительно суммарный префикс вида 10.Z.0.0/16, который охватывает все локальные сети всех объектов (своего рода default).

Вопрос: как это правильно сделать на JunOS? Скорее всего вопрос простой, но я застрял на этой простой вещи. Этот суммарный маршрут отсутствует в таблице маршрутизации объекта С и соответственно не будет анонсироваться пирам (операторам), несмотря на то, что я его указал в префикс листах политики экспорта bgp. Можно маршрут добавить в статику, но что правильно указать в этом случае в качестве next-hop? Самое простое - discard/reject. При этом все нормально анонсируется, на объектах суммарный префикс принимается, но толку от этого все равно нет, т.к. с таким next-hop транзитный трафик через объект С запрещается. Читал про aggregate/generate маршруты, команду advertise-inactive, но что-то так и не получается.
Прошу помощи.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ivb (??) on 20-Фев-17, 13:32 
Сделать aggregate маршруты, можно passive.
В полиси Export BGP Указать  from protocol aggregate и  from route-filter если требуется.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 20-Фев-17, 16:22 
Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный трафик.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от Аноним (??) on 21-Фев-17, 02:29 
> Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный
> трафик.

так оно у вас и не пойдет по этому маршруту, а пойдет по more-specific маршрутам на те сети, которые реальны. Это же не фаервол.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 21-Фев-17, 10:44 
>> Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный
>> трафик.
> так оно у вас и не пойдет по этому маршруту, а пойдет
> по more-specific маршрутам на те сети, которые реальны. Это же не
> фаервол.

нет, не так. От пункта А, подключенного только по каналу M в пункт С прилетает анонсированный им префикс его (пункта А) локальной сети, но этот префикс из-за отсутствия связности между транзитными для нас сетями операторов не передается в пункт B, подключенный только по каналу R. Т.е. локальная сеть пункта А в пункте B будет покрыта только aggregate маршрутом с next-hop reject/discard, никакого more specific маршрута в пункт B от пункта А не прилетит.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от Аноним (??) on 21-Фев-17, 23:34 
> нет, не так. От пункта А, подключенного только по каналу M в
> пункт С прилетает анонсированный им префикс его (пункта А) локальной сети,
> но этот префикс из-за отсутствия связности между транзитными для нас сетями
> операторов не передается в пункт B, подключенный только по каналу R.
> Т.е. локальная сеть пункта А в пункте B будет покрыта только
> aggregate маршрутом с next-hop reject/discard, никакого more specific маршрута в пункт
> B от пункта А не прилетит.

Вы сами запутались. more-specific прилетит на C, и этого достаточно для форвардинга. На C же будет нужный маршрут.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 22-Фев-17, 10:14 
> Вы сами запутались. more-specific прилетит на C, и этого достаточно для форвардинга.
> На C же будет нужный маршрут.

Прилететь-то от А в С он прилетит по каналу провайдера M, но, откуда этот префикс или менее специфичный, покрывающий его, возьмется на B с рабочим каналом R? Т.е. сначала трафик от B должен как-то добраться до С и только потом уже сработает то, о чем Вы говорите.

Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в таблице маршрутизации и с next-hop-self (а не reject/discard)?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

4. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от fantom (??) on 21-Фев-17, 07:38 
>[оверквотинг удален]
> я застрял на этой простой вещи. Этот суммарный маршрут отсутствует в
> таблице маршрутизации объекта С и соответственно не будет анонсироваться пирам (операторам),
> несмотря на то, что я его указал в префикс листах политики
> экспорта bgp. Можно маршрут добавить в статику, но что правильно указать
> в этом случае в качестве next-hop? Самое простое - discard/reject. При
> этом все нормально анонсируется, на объектах суммарный префикс принимается, но толку
> от этого все равно нет, т.к. с таким next-hop транзитный трафик
> через объект С запрещается. Читал про aggregate/generate маршруты, команду advertise-inactive,
> но что-то так и не получается.
> Прошу помощи.

Если сети локальные - что мешает использовать разные номера AS для разных объектов и построить "как в инете"???
Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет

а если есть возможность туннели через IP построить....

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 21-Фев-17, 10:53 
> Если сети локальные - что мешает использовать разные номера AS для разных
> объектов и построить "как в инете"???
> Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
> Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет

Так именно и сделано, но либо я Вас не совсем понял, либо Вы не совсем внимательно прочитали. Если нет связности между транзитными для нас сетями двух операторов, то мы теряем и связность между анонсируемыми нами локальными сетями объектов в ситуации, когда 2 объекта подключены каждый только к одному и при этом разным операторам. Для этого и хочу сделать транзит через один из своих объектов.

> а если есть возможность туннели через IP построить....

с этого, как раз и мигрировали на плоскую сеть

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от fantom (??) on 22-Фев-17, 08:48 
>[оверквотинг удален]
>> Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
>> Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет
> Так именно и сделано, но либо я Вас не совсем понял, либо
> Вы не совсем внимательно прочитали. Если нет связности между транзитными для
> нас сетями двух операторов, то мы теряем и связность между анонсируемыми
> нами локальными сетями объектов в ситуации, когда 2 объекта подключены каждый
> только к одному и при этом разным операторам. Для этого и
> хочу сделать транзит через один из своих объектов.
>> а если есть возможность туннели через IP построить....
> с этого, как раз и мигрировали на плоскую сеть

Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные от объекта "С" и наоборот???
Фильтры так настроены?? политика такая?? так поправте фильтры-политику

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 22-Фев-17, 10:01 
> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
> от объекта "С" и наоборот???
> Фильтры так настроены?? политика такая?? так поправте фильтры-политику

потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо. Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно доставляет все эти префиксы другим объектам, но только в рамках своей транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие префиксы, но только с помощью одного объекта - С и лучше одним более общим маршрутом.

Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в таблице маршрутизации и с next-hop-self (а не reject/discard)?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от Аноним (??) on 23-Фев-17, 18:03 
> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
> таблице маршрутизации и с next-hop-self (а не reject/discard)?

с next-hop-self это как? заруливать трафик на процессор?

Предлагаю сузить суть вопроса: нарисуйте схемку со стрелочками и облачками, а то сейчас непонятно вообще, что где ходит а что нет, и почему агрегейт/генерейт не подходитю

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 25-Фев-17, 11:56 
>> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
>> таблице маршрутизации и с 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. Какой?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от fantom (??) on 27-Фев-17, 09:30 
>> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
>> от объекта "С" и наоборот???
>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.

УХТЫ!!!
А как же интернет-то тогда работает вцелом?????

Открою тайну - именно переобьявляет полученные от соседа сети....

> Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно
> доставляет все эти префиксы другим объектам, но только в рамках своей
> транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие
> префиксы, но только с помощью одного объекта - С и лучше
> одним более общим маршрутом.
> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
> таблице маршрутизации и с next-hop-self (а не reject/discard)?

Если этот маршрут получаем по eBGP - Правкой политики и фильтров на out направление.
Если его вообще нет нигде - то по классике:
создаем маршрут в null0 и его анонсим соседям.
Лет 30 уже этому решению, считается классическим примером...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от fantom (ok) on 27-Фев-17, 09:35 
Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак не хотите понять, что ваши объекты - точно такие же провайдеры!
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 27-Фев-17, 12:02 
> Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак
> не хотите понять, что ваши объекты - точно такие же провайдеры!

не верно, т.к. пропуск транзитного трафика для объектов (клиентов) не является их задачей (за исключением объекта С) и даже вредно в отличие от провайдеров M и R

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

15. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 27-Фев-17, 11:59 
>>> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
>>> от объекта "С" и наоборот???
>>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
>> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.
> УХТЫ!!!
> А как же интернет-то тогда работает вцелом?????
> Открою тайну - именно переобьявляет полученные от соседа сети....

Это если ваша задача именно предоставлять услуги связи для других. Здесь же конечный объект этими услугами только пользуется и он не должен пропускать через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение - только объект С.

> Если этот маршрут получаем по eBGP - Правкой политики и фильтров на
> out направление.
> Если его вообще нет нигде - то по классике:
> создаем маршрут в null0 и его анонсим соседям.
> Лет 30 уже этому решению, считается классическим примером...

Именно, его нигде нет, но Ваше предложение "создаем маршрут в null0" - это в JunOS делается как aggregate route с next-hop reject/discard. Я уже несколько раз писал, почему это не работает/подходит в данном конкретном случае.


Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от fantom (ok) on 28-Фев-17, 08:53 
>[оверквотинг удален]
>>>> от объекта "С" и наоборот???
>>>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
>>> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.
>> УХТЫ!!!
>> А как же интернет-то тогда работает вцелом?????
>> Открою тайну - именно переобьявляет полученные от соседа сети....
> Это если ваша задача именно предоставлять услуги связи для других. Здесь же
> конечный объект этими услугами только пользуется и он не должен пропускать
> через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение
> - только объект С.

ВО! т.е. объект С становится "провайдером для объектов А и В" вот и разрешите ему объявлять сети автономных систем объектов А и В.

А если копнуть чуть дальше - то почему бы А и В не уровнять в правах с С?

>> Если этот маршрут получаем по 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 протоколов.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 28-Фев-17, 12:19 
> ВО! т.е. объект С становится "провайдером для объектов А и В" вот
> и разрешите ему объявлять сети автономных систем объектов А и В.

да, уже и сам решил попробовать так сделать.

> А если копнуть чуть дальше - то почему бы А и В
> не уровнять в правах с С?

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

> Вот похоже ваш случай.
> https://habrahabr.ru/post/274873/
> С подробностями вроде даже.
> Цитата:
> Теперь осталось понять природу generate route. Generate route по сути тот же
> aggregate route, но с реальным next-hop, который берется из contribute route:

эту статью я читал.


> Кто пирами на А,В,С является? рутеры провайдера или ваши?

провайдера
> Вы от провов получаете только свои префиксы или еще и горку чужих??

свои
> Если у вас MPLS VPN L3 - то в теории вам должны
> прилетать только ваши префиксы (иначе смысл MPLS L3 городить лично для
> меня не совсем понятен.).

так и есть
> И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО
> СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????
> BGP позволяет играть префиксами, анонсами и еще кучей параметров так, как надо
> вам и в этом плане гораздо гибче IGP протоколов.

это все понятно. только вопрос остался: можно ли (как?) анонсировать сеть, отсутствующую на роутере и, следовательно, в его таблице маршрутизации? Возможно, это неверный путь решения начальной задачи, но все равно хочется разобраться и с этим.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от fantom (ok) on 01-Мрт-17, 11:28 
>[оверквотинг удален]
>> меня не совсем понятен.).
> так и есть
>> И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО
>> СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????
>> 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;
        }
    }


Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 01-Мрт-17, 14:19 
У меня небольшие отличия. Вместо 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, указывающим на этот же самый узел, но такой маршрут, как я понял, установить в таблицу невозможно.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "как правильно анонсировать по bgp суммарный маршрут на JunOS?"  +/
Сообщение от ale_xb (ok) on 04-Апр-17, 17:24 
решил, наконец-то! Как обычно, следует просто четко понимать, что требуется (в моем случае не хватало именно этого) и внимательно читать, в частности, упомянутую выше статью на Хабре, за что её автору отдельное спасибо.
Кратко: В моем случае используются два пограничника, связанные по 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;
   }
}

все заработало.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру