Имеется 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, но что-то так и не получается.
Прошу помощи.
Сделать aggregate маршруты, можно passive.
В полиси Export BGP Указать from protocol aggregate и from route-filter если требуется.
Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный трафик.
> Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный
> трафик.так оно у вас и не пойдет по этому маршруту, а пойдет по more-specific маршрутам на те сети, которые реальны. Это же не фаервол.
>> Так в aggregate же next-hop может быть только reject/discard, что запрещает транзитный
>> трафик.
> так оно у вас и не пойдет по этому маршруту, а пойдет
> по more-specific маршрутам на те сети, которые реальны. Это же не
> фаервол.нет, не так. От пункта А, подключенного только по каналу M в пункт С прилетает анонсированный им префикс его (пункта А) локальной сети, но этот префикс из-за отсутствия связности между транзитными для нас сетями операторов не передается в пункт B, подключенный только по каналу R. Т.е. локальная сеть пункта А в пункте B будет покрыта только aggregate маршрутом с next-hop reject/discard, никакого more specific маршрута в пункт B от пункта А не прилетит.
> нет, не так. От пункта А, подключенного только по каналу M в
> пункт С прилетает анонсированный им префикс его (пункта А) локальной сети,
> но этот префикс из-за отсутствия связности между транзитными для нас сетями
> операторов не передается в пункт B, подключенный только по каналу R.
> Т.е. локальная сеть пункта А в пункте B будет покрыта только
> aggregate маршрутом с next-hop reject/discard, никакого more specific маршрута в пункт
> B от пункта А не прилетит.Вы сами запутались. more-specific прилетит на C, и этого достаточно для форвардинга. На C же будет нужный маршрут.
> Вы сами запутались. more-specific прилетит на C, и этого достаточно для форвардинга.
> На C же будет нужный маршрут.Прилететь-то от А в С он прилетит по каналу провайдера M, но, откуда этот префикс или менее специфичный, покрывающий его, возьмется на B с рабочим каналом R? Т.е. сначала трафик от B должен как-то добраться до С и только потом уже сработает то, о чем Вы говорите.
Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в таблице маршрутизации и с next-hop-self (а не reject/discard)?
>[оверквотинг удален]
> я застрял на этой простой вещи. Этот суммарный маршрут отсутствует в
> таблице маршрутизации объекта С и соответственно не будет анонсироваться пирам (операторам),
> несмотря на то, что я его указал в префикс листах политики
> экспорта bgp. Можно маршрут добавить в статику, но что правильно указать
> в этом случае в качестве next-hop? Самое простое - discard/reject. При
> этом все нормально анонсируется, на объектах суммарный префикс принимается, но толку
> от этого все равно нет, т.к. с таким next-hop транзитный трафик
> через объект С запрещается. Читал про aggregate/generate маршруты, команду advertise-inactive,
> но что-то так и не получается.
> Прошу помощи.Если сети локальные - что мешает использовать разные номера AS для разных объектов и построить "как в инете"???
Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
Связность сохраниться практически при любом раскладе если хоть как-то IP работать будета если есть возможность туннели через IP построить....
> Если сети локальные - что мешает использовать разные номера AS для разных
> объектов и построить "как в инете"???
> Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
> Связность сохраниться практически при любом раскладе если хоть как-то IP работать будетТак именно и сделано, но либо я Вас не совсем понял, либо Вы не совсем внимательно прочитали. Если нет связности между транзитными для нас сетями двух операторов, то мы теряем и связность между анонсируемыми нами локальными сетями объектов в ситуации, когда 2 объекта подключены каждый только к одному и при этом разным операторам. Для этого и хочу сделать транзит через один из своих объектов.
> а если есть возможность туннели через IP построить....
с этого, как раз и мигрировали на плоскую сеть
>[оверквотинг удален]
>> Т.е. каждый каждому объявляет все, что знает, а маршрут выбирается по ASpath.
>> Связность сохраниться практически при любом раскладе если хоть как-то IP работать будет
> Так именно и сделано, но либо я Вас не совсем понял, либо
> Вы не совсем внимательно прочитали. Если нет связности между транзитными для
> нас сетями двух операторов, то мы теряем и связность между анонсируемыми
> нами локальными сетями объектов в ситуации, когда 2 объекта подключены каждый
> только к одному и при этом разным операторам. Для этого и
> хочу сделать транзит через один из своих объектов.
>> а если есть возможность туннели через IP построить....
> с этого, как раз и мигрировали на плоскую сетьТогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные от объекта "С" и наоборот???
Фильтры так настроены?? политика такая?? так поправте фильтры-политику
> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
> от объекта "С" и наоборот???
> Фильтры так настроены?? политика такая?? так поправте фильтры-политикупотому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо. Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно доставляет все эти префиксы другим объектам, но только в рамках своей транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие префиксы, но только с помощью одного объекта - С и лучше одним более общим маршрутом.
Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в таблице маршрутизации и с next-hop-self (а не reject/discard)?
> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
> таблице маршрутизации и с next-hop-self (а не reject/discard)?с next-hop-self это как? заруливать трафик на процессор?
Предлагаю сузить суть вопроса: нарисуйте схемку со стрелочками и облачками, а то сейчас непонятно вообще, что где ходит а что нет, и почему агрегейт/генерейт не подходитю
>> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
>> таблице маршрутизации и с 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. Какой?
>> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
>> от объекта "С" и наоборот???
>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.УХТЫ!!!
А как же интернет-то тогда работает вцелом?????Открою тайну - именно переобьявляет полученные от соседа сети....
> Эти объекты и так сами их объявляют своим провайдерам/пирам. Провайдер замечательно
> доставляет все эти префиксы другим объектам, но только в рамках своей
> транзитной сети, к сожалению. По сути я и хочу редистрибьютить чужие
> префиксы, но только с помощью одного объекта - С и лучше
> одним более общим маршрутом.
> Предлагаю сузить суть вопроса: как анонсировать произвольный маршрут, отсутствующий в
> таблице маршрутизации и с next-hop-self (а не reject/discard)?Если этот маршрут получаем по eBGP - Правкой политики и фильтров на out направление.
Если его вообще нет нигде - то по классике:
создаем маршрут в null0 и его анонсим соседям.
Лет 30 уже этому решению, считается классическим примером...
Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак не хотите понять, что ваши объекты - точно такие же провайдеры!
> Вы все пытаетесь делить ваши обьекты на клиента и провайдера, и никак
> не хотите понять, что ваши объекты - точно такие же провайдеры!не верно, т.к. пропуск транзитного трафика для объектов (клиентов) не является их задачей (за исключением объекта С) и даже вредно в отличие от провайдеров M и R
>>> Тогда почему объект "В" не объявляет по БГП объекту "А" сети, полученные
>>> от объекта "С" и наоборот???
>>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
>> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.
> УХТЫ!!!
> А как же интернет-то тогда работает вцелом?????
> Открою тайну - именно переобьявляет полученные от соседа сети....Это если ваша задача именно предоставлять услуги связи для других. Здесь же конечный объект этими услугами только пользуется и он не должен пропускать через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение - только объект С.
> Если этот маршрут получаем по eBGP - Правкой политики и фильтров на
> out направление.
> Если его вообще нет нигде - то по классике:
> создаем маршрут в null0 и его анонсим соседям.
> Лет 30 уже этому решению, считается классическим примером...Именно, его нигде нет, но Ваше предложение "создаем маршрут в null0" - это в JunOS делается как aggregate route с next-hop reject/discard. Я уже несколько раз писал, почему это не работает/подходит в данном конкретном случае.
>[оверквотинг удален]
>>>> от объекта "С" и наоборот???
>>>> Фильтры так настроены?? политика такая?? так поправте фильтры-политику
>>> потому что переобъявлять полученные "чужие" локальные сети (других объектов) не есть хорошо.
>> УХТЫ!!!
>> А как же интернет-то тогда работает вцелом?????
>> Открою тайну - именно переобьявляет полученные от соседа сети....
> Это если ваша задача именно предоставлять услуги связи для других. Здесь же
> конечный объект этими услугами только пользуется и он не должен пропускать
> через себя транзитный трафик из/в чужих сетей. Зачем ему это? Исключение
> - только объект С.ВО! т.е. объект С становится "провайдером для объектов А и В" вот и разрешите ему объявлять сети автономных систем объектов А и В.
А если копнуть чуть дальше - то почему бы А и В не уровнять в правах с С?
>> Если этот маршрут получаем по 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 протоколов.
> ВО! т.е. объект С становится "провайдером для объектов А и В" вот
> и разрешите ему объявлять сети автономных систем объектов А и В.да, уже и сам решил попробовать так сделать.
> А если копнуть чуть дальше - то почему бы А и В
> не уровнять в правах с С?не нужно этого. разные объекты имеют разные по скорости каналы подключения к провайдерам и генерят разный по объему трафик. Следует избегать ситуации, когда через низкоскоростной объект будет пытаться ходить трафик от высокоскоростного да еще и значительного объема.
> Вот похоже ваш случай.
> https://habrahabr.ru/post/274873/
> С подробностями вроде даже.
> Цитата:
> Теперь осталось понять природу generate route. Generate route по сути тот же
> aggregate route, но с реальным next-hop, который берется из contribute route:эту статью я читал.
> Кто пирами на А,В,С является? рутеры провайдера или ваши?провайдера
> Вы от провов получаете только свои префиксы или еще и горку чужих??свои
> Если у вас MPLS VPN L3 - то в теории вам должны
> прилетать только ваши префиксы (иначе смысл MPLS L3 городить лично для
> меня не совсем понятен.).так и есть
> И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО
> СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????
> BGP позволяет играть префиксами, анонсами и еще кучей параметров так, как надо
> вам и в этом плане гораздо гибче IGP протоколов.это все понятно. только вопрос остался: можно ли (как?) анонсировать сеть, отсутствующую на роутере и, следовательно, в его таблице маршрутизации? Возможно, это неверный путь решения начальной задачи, но все равно хочется разобраться и с этим.
>[оверквотинг удален]
>> меня не совсем понятен.).
> так и есть
>> И даже если вам прилетает вагон чужих префиксов, ЧТО МЕШАЕТ ТРАНЗИТИТЬ ТОЛЬКО
>> СВОИ СОБСТВЕННЫЕ С ДРУГИХ ОБЪЕКТОВ????
>> 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;
}
}
У меня небольшие отличия. Вместо 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, указывающим на этот же самый узел, но такой маршрут, как я понял, установить в таблицу невозможно.
решил, наконец-то! Как обычно, следует просто четко понимать, что требуется (в моем случае не хватало именно этого) и внимательно читать, в частности, упомянутую выше статью на Хабре, за что её автору отдельное спасибо.
Кратко: В моем случае используются два пограничника, связанные по 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;
}
}все заработало.