Routing Instance

Junos способна логически группировать Routing Tables, интерфейсы, а также протоколы маршрутизации.
Такая группа называется Routing Instance
В каждой Routing Instance маршрутизация работает изолированно.

Использование Routing Instances даёт большую гибкость в настройках, поскольку одно устройство может работать, имитируя работу нескольких.

Master Routing Instance

Junos по умолчанию создаёт Master Routing Instance.
По умолчанию Master Routing Instance включает routing table inet.0

inet.0 используется для IPv4 unicast routing.

Junos также создаёт private routing instances, которые используются для внутренних коммуникаций, и которые мы можем игнорировать.

User-Defined Routing Instances

Мы можем добавлять свои Routing Instances, которые позволяют:
• forwarding: Used to implement filter-based forwarding for common Access Layer applications;
• l2vpn: Used in Layer 2 VPN implementations;
• no-forwarding: Used to separate large networks into smaller administrative entities;
• virtual-router: Used for non-VPN-related applications such as system virtualization;
• vpls: Used for point-to-multipoint LAN implementations between a set of sites in a VPN; and
• vrf: Used in Layer 3 VPN implementations

Работа с Routing Instances

При создании routing instance автоматом создаётся routing table в именем instance-name.inet.0.

Sharing Routes Between Routing Tables

Junos позволяет поместить routing information одновременно в несколько routing tables.

Первый метод использует Routing Information Base (RIB) Group.
RIB Group определяется, а затем может быть использована в секциях конфигурации.

Второй метод - использование instance-import, instance-export, auto-export.

Определение RIB Group

Чтобы понять работу RIB Group, сначала разберемся, как создаётся таблица маршрутизации в Junos без RIB Group:
Protocol -> ProtocolDB -> RIB

1. Отрабатывает протокол маршрутизации (protocol). При этом в терминах Junos, под понятим протокол может выступать не только к примеру OSPF, но и статические маршруты, Connected routes и т.д.
2. Protocol DB - алгоритм протокола хранит свои маршруты в Protocol DB, и оттуда по своим критериям выбирает лучший. Который помещается в RIB
3. RIB - собственно сама таблица маршрутизации. Для IPv4 - это inet.0

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

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

Как уже отмечалось, Junos использует RIB Group для того, чтобы поместить routing information в несколько routing tables.
Мы определяем имя RIB Group, а в самой конфигурации задаём две основные опции:
- import-rib - перечисляет несколько routing tables, куда будет помещена входящая route information.
Первая routing table в списке - будет Primary routing table.
Primary routing table - это таблица, куда будет помещена route information при отсутствии RIB Group
- export-rib - включает только одну routing table, куда отдавать route information.
export-rib часто не применяется в конфигурации.

Применение RIB Group

После того, как мы создали RIB Group, мы можем применить её в других секциях конфигурации.
RIB Group мы можем применить например в interface routes, static routes, OSPF, IS-IS, RIP, BGP, Physical Interface Module (PIM), and Multicast Source Discovery Protocol (MSDP).

В следующем примере OSPF будет отдавать свои маршруты в таблицы: inet.0 , test.inet.0

user@R1# show routing-options
rib-groups {
 test {
 import-rib [ inet.0 test.inet.0 ];
 }
}

user@R1# show protocols ospf
rib-group test;
area 0.0.0.0 {
 interface ge-0/0/1.0;
 interface lo0.0;
}

Это мы можем проверить через команду show route table:

user@R1> show route table inet.0 protocol ospf 
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.20.101.0/24 *[OSPF/150] 00:00:30, metric 0, tag 0
 > to 172.20.77.2 via ge-0/0/1.0
172.20.201.0/24 *[OSPF/150] 00:00:30, metric 0, tag 0
 > to 172.20.77.2 via ge-0/0/1.0
192.168.2.1/32 *[OSPF/10] 00:00:30, metric 1
 > to 172.20.77.2 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 2w1d 02:37:55, metric 1
 MultiRecv
user@R1> show route table test.inet.0 protocol ospf 
test.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.20.101.0/24 *[OSPF/150] 00:00:27, metric 0, tag 0
 > to 172.20.77.2 via ge-0/0/1.0
172.20.201.0/24 *[OSPF/150] 00:00:27, metric 0, tag 0
 > to 172.20.77.2 via ge-0/0/1.0
192.168.2.1/32 *[OSPF/10] 00:00:27, metric 1
 > to 172.20.77.2 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:00:27, metric 1
 MultiRecv

Routing Between Instances

Между разными instances также мы можем создавать соединения: физические или логические.

Пример логического соединения:

[edit interfaces lt-0/0/0]
user@R1# show
unit 0 {
 encapsulation ethernet;
 peer-unit 1;
 family inet {
 }
}
unit 1 {
 encapsulation ethernet;
 peer-unit 0;
 family inet;
}

Пример конфигурации

Настройка интерфейсов: