Зачем они нужны и как ими пользоваться?
Я, когда в одной книжке наткнулся на них, не совсем понял их. Там упоминалось, что их можно использовать, когда надо дефолт отдавать с условием, чтобы он подох при падении сессии с вышестоящим пиром.
И вот тут я столкнулся дженерейтами непосредственно.
Что было:
2 канала, основной и резервный, соотв. имеются два bgp пира. Обоим анонсируем свои префиксы, получаем от обоих дефолты. В резервный канал префиксы препендим, дефолту через основной канал приоритет поднимаем. В случае, если основной ложится - всё само начинает работать через резерв, т.к. сессия умирает со всеми вытекающми. Естественно, может быть ситуация с мёртвым каналом и живой сессией, на этот случай отдельный механизм.
И ещё с пиром на резервном канале была ipv6 сессия, отдавали наш префикс и получали дефолт.
Необходимость:
Поднять ipv6 сессию с пиром на основном канале, с сохранением имеющейся схемы с автоматическим переходом на бекап.
Что получилось:
Оказалось, что наш пир на основном канале не получает ipv6 дефолт и поэтому отдаёт нам fullview, который к нам не пролезает. Собственно, даже при поддержке fullview пришлось бы что-то делать, чтобы передавать дальше.
В общем, из того, что к нам шло, я выбрал один раут - до одного из корневых ДНСов.
Дальше пришлось состряпать две политики.
Одна для импорта нужного раута по bgp:
Вторая - для инжекта раута в генерируемый маршрут (po-inject):
И, наконец, поднимаем раут:
В результате имеем 2 дефолта с разными приоритетами (за счёт дефолтных приоритетов аггрегейтов и бгп), в случае смерти сессии с пиром на основном канале - сгенерированный маршрут умрёт, ибо не будет ни одного contributed раута.
Я, когда в одной книжке наткнулся на них, не совсем понял их. Там упоминалось, что их можно использовать, когда надо дефолт отдавать с условием, чтобы он подох при падении сессии с вышестоящим пиром.
И вот тут я столкнулся дженерейтами непосредственно.
Что было:
2 канала, основной и резервный, соотв. имеются два bgp пира. Обоим анонсируем свои префиксы, получаем от обоих дефолты. В резервный канал префиксы препендим, дефолту через основной канал приоритет поднимаем. В случае, если основной ложится - всё само начинает работать через резерв, т.к. сессия умирает со всеми вытекающми. Естественно, может быть ситуация с мёртвым каналом и живой сессией, на этот случай отдельный механизм.
И ещё с пиром на резервном канале была ipv6 сессия, отдавали наш префикс и получали дефолт.
Необходимость:
Поднять ipv6 сессию с пиром на основном канале, с сохранением имеющейся схемы с автоматическим переходом на бекап.
Что получилось:
Оказалось, что наш пир на основном канале не получает ipv6 дефолт и поэтому отдаёт нам fullview, который к нам не пролезает. Собственно, даже при поддержке fullview пришлось бы что-то делать, чтобы передавать дальше.
В общем, из того, что к нам шло, я выбрал один раут - до одного из корневых ДНСов.
Дальше пришлось состряпать две политики.
Одна для импорта нужного раута по bgp:
term root_dns_a {
from {
route-filter 2001:503:ba3e::/48 exact;
}
then accept;
}
term deny_others {
then reject;
}
Вторая - для инжекта раута в генерируемый маршрут (po-inject):
term inject_root_dns_only {
from {
neighbor 2a00:xxxx:0:13::1;
route-filter 2001:503:ba3e::/48 exact;
}
then accept;
}
term deny_other {
then reject;
}
И, наконец, поднимаем раут:
> show configuration routing-options rib inet6.0
generate {
route ::/0 policy po-inject;
}
В результате имеем 2 дефолта с разными приоритетами (за счёт дефолтных приоритетов аггрегейтов и бгп), в случае смерти сессии с пиром на основном канале - сгенерированный маршрут умрёт, ибо не будет ни одного contributed раута.
