Demystifying Juniper's rib-groups

Многие из моих знакомых не до конца понимаю механизм работы rib-groups внутри Juniper's JunOS. В данной статье я попробую наиболее просто объяснить, что же это такое — rib-groups, и зачем они нужны.
Подробности под катом.


Для начала необходимо понять, как заполняется таблица маршрутизации в Junos'е. Происходит (схематически) это следующим образом:

[protocol]_____[protocol's db]_____[RIB]

где:

protocol — протокол маршрутизации в рамках Junos (это не совсем протокол маршрутизации в его
класическом понимание, ибо сюда же входит скажем и интерфейсы маршрутизатора)

protocol's db — база данных протокола (например isis/ospf/bgp database). Сюда заносятся все маршруты, и выбирается наилучший, после чего он инсталится в RIB.

RIB — соответсвенно сама тиблица маршрутизации. Зависит от того, какой протокол мы используем, и где мы его используем (eg. ipv4 маршруты идут в inet.0, ldp — inet.3; маршрути внутри vrf/virt router в <vrf.name>.inet.0 и тп)

Механизм rib-group позволяет нам использовать след конструкцию:

[protocol]_________[protocol's db]______________________[RIB-Group],

где RIB-Group состоит из:
Primary RIB — таблица, куда протокол по умолчанию инсталит свои маршруты
Secondary RIB — одна или несколько дополнительных таблиц маршрутизации, куда мы хотим, чтоб протокол так же инсталил свои маршруты.
Import-Policy — политика, описывающая, как из маршрутов мы разрешаем инсталить в Secondary RIB, а какие нет.

Те мы получили возможность инсталить маршруты, полученные от протокола маршрутизации, не только в ту таблицу, с которой он работает по умолчанию, но и в любую другую. Причем появляются понятия Primary и Secondary RIB. Отличаются они тем, что мы можем (при помощи import policy) явно указывать, какие маршруты инсталить в secondary RIB (в primary инсталятся все, вне зависимости от import policy).

Рассмотрим пример использования rib-groups.

Пример:
Дано: MPLS сеть, в ней выделеный BGP RR, на котором запушенны лишь IGP и MP-BGP (те LDP/RSVP-TE нету (например в качестве рефлектора используем JCS, и, так как форвардить все равно не умеет, LDP там и не нужен + стабильность (тк все лишнее выключено)), и, соответственно, некому инсталить маршруты в inet.3 table). Проблема такого сценария в том, что для того, чтобы vpnv4 маршрут был пригодным, с точки зрения bgp в Junos, его next-hop должен быть внутри inet.3 таблицы.

root@JunLAB:RR> show route table bgp.l3vpn.0

bgp.l3vpn.0: 9 destinations, 9 routes (0 active, 0 holddown, 9 hidden)

root@JunLAB:RR>

9 hidden маршрутов. Причина:

root@JunLAB:RR> ...ute table bgp.l3vpn.0 hidden extensive | grep "Next hop"
Next hop type: Unusable


root@JunLAB:RR> show route table inet.3

root@JunLAB:RR>

как видем inet.3 пустая

У нас выключен LDP, но есть IGP, каторый по умолчанию инсталит все в inet.0

Создадим rib-group, включающий в себя inet.0 и inet.3, причем сделаем так, что в inet.3 будут инсталяться только маршруты bgp loopback'ов (через route-filter и заранее известный диапазон ip адресов)

описание rib-group:

root@JunLAB:RR> show configuration routing-options
rib-groups {
MPBGP_LB {
import-rib [ inet.0 inet.3 ];
import-policy INET3_LB;
}
}

где:
inet.0 — primary
inet.3 — secondary

Описание политики:

policy-statement INET3_LB {
term LOOPBACKS {
from {
route-filter 192.168.250.0/24 longer;
}
to rib inet.3;
then accept;
}
then reject;
}


Привязываем политику к IGP:

root@JunLAB:RR# show protocols isis
lsp-lifetime 65535;
no-ipv6-routing;
rib-group inet MPBGP_LB;
level 1 disable;
level 2 wide-metrics-only;
interface fxp1.14 {
point-to-point;
}
interface lo0.8 {
passive;
}

После commita убеждаемся, что маршруты до loopback'ов попали в inet.3

root@JunLAB:RR> show route table inet.3

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.250.1/32 *[IS-IS/18] 00:00:41, metric 20
> to 10.0.0.25 via fxp1.14
192.168.250.2/32 *[IS-IS/18] 00:00:41, metric 20
> to 10.0.0.25 via fxp1.14
192.168.250.3/32 *[IS-IS/18] 00:00:41, metric 10
> to 10.0.0.25 via fxp1.14
192.168.250.4/32 *[IS-IS/18] 00:00:41, metric 30
> to 10.0.0.25 via fxp1.14
192.168.250.5/32 *[IS-IS/18] 00:00:41, metric 30
> to 10.0.0.25 via fxp1.14
192.168.250.6/32 *[IS-IS/18] 00:00:41, metric 20
> to 10.0.0.25 via fxp1.14
192.168.250.7/32 *[IS-IS/18] 00:00:41, metric 30
> to 10.0.0.25 via fxp1.14

root@JunLAB:RR>

И vpnv4 маршруты больше не hidden, тк появились маршруты до next-hop'ов внутри inet.3

bgp.l3vpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.250.1:1:192.168.0.0/30
*[BGP/170] 00:22:08, localpref 100, from 192.168.250.1
AS path: I
> to 10.0.0.25 via fxp1.14, Push 16
...


Так же rib-group's очень удобно использовать, когда необходимо сделать route leak между vrf'ами (в IOS для этого необходимо поднимать bgp процесс, в Junos можно обойтись и без него)
Или сделать leak из vrf в GRT (в IOS это сделать нельзя(акромя статик маршрутов, что не очень удобно). Так же rib-group используются в FBF (filter bassed forwarding — аналог PBR из cisco's world).