forum.opennet.ru - "как правильно анонсировать по bgp суммарный маршрут на JunOS?" (21)

форумы

правила/FAQ

поиск

регистрация

вход/выход

слежка

"как правильно анонсировать по 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ообщить модератору

Оглавление

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ivb, 13:32 , 20-Фев-17, (1)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 16:22 , 20-Фев-17, (2)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, Аноним, 02:29 , 21-Фев-17, (3)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:44 , 21-Фев-17, (5)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, Аноним, 23:34 , 21-Фев-17, (7)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:14 , 22-Фев-17, (10)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 07:38 , 21-Фев-17, (4)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:53 , 21-Фев-17, (6)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 08:48 , 22-Фев-17, (8)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 10:01 , 22-Фев-17, (9)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, Аноним, 18:03 , 23-Фев-17, (11)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 11:56 , 25-Фев-17, (12)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 09:30 , 27-Фев-17, (13)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 09:35 , 27-Фев-17, (14)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 12:02 , 27-Фев-17, (16)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 11:59 , 27-Фев-17, (15)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 08:53 , 28-Фев-17, (17)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 12:19 , 28-Фев-17, (18)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, fantom, 11:28 , 01-Мрт-17, (19)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 14:19 , 01-Мрт-17, (20)

как правильно анонсировать по bgp суммарный маршрут на JunOS?, ale_xb, 17:24 , 04-Апр-17, (21)

Сообщения по теме [Сортировка по времени | 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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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ообщить модератору