>> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
>> таблице маршрутизации и с 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. Какой?
