Чем больше знакомишься с оборудованием Juniper, тем больше влюбляешься в это оборудование и операционную систему JunOS. Сегодня речь пойдет о Static, Aggregate и Generate маршрутах. По этой теме есть статьи на английском (не встречал на русском даже переводов), поэтому решил написать свою статью. Надеюсь, помогу какому-нибудь начинающему инженеру.

Итак, начну. Все три перечисленых выше видов маршрутов по своей сути являются статическими маршрутами и прописывают в конфигурации junos в иерархии edit routing-options.

Итак, static route. Любой сетевой инженер знает что это такое. Нам надо попасть в какую то сеть, но нет возможности (или желания) использовать протоколы динамической маршрутизации, выход — статика. Вот пример статического маршрута в juniper:

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

10.0.0.0/30   *[Static/5] 19w3d 09:40:52
                    > to 10.0.10.10 via ge-1/3/2

Как видно из вывода, нам надо добраться до сети 10.0.0.0/30 — мы прописываем статический маршрут и указываем next hop. Маршрутизация пакета по IP-сети работает по принципу per-hop behavior (PHB), то есть каждый маршрутизатор сам определяет, куда отправлять пакет на основе имеющейся таблицы маршрутизации (мы не рассматриваем сейчас маршрутизацию от источника). В качестве next hop должен быть маршрутизатор, у которого будет маршрут до указанной сети ( может быть тоже статический- не важно), в противном случае, пакет будет просто отброшен этим маршрутизатором (с отправкой ICMP сообщения или без такового) Не вижу смыла больше писать о статических маршрутах, поэтому идем дальше.

Aggregate route. По сути это тот же static route, только next hop или reject или discard, то есть данный маршрут невозможно использовать для передачи трафика (кроме случаев, когда трафик намеренно заворачивается в discard). Встает вопрос — а зачем нам такой маршрут??? Есть несколько применений данному маршруту. Самое распространенное применение — объединение нескольких более специфичных префиксов в один менее специфичный( к примеру несколько /27-/28 в один /24 или /22) и передача его другим bgp-пирам. Bgp все равно сменит next-hop на себя ( для ebgp по умолчанию, для ibgp придется делать политику для next-hop self).

Вот так выглядит Aggregate route в конфигурации JunOS:

routing-options {
    aggregate {
        route 10.0.0.0/8 policy aggregate-contribute-routes;
    }

С помощью данной политики: aggregate-contribute-routes, мы задаем contribute route (Contribute (анг. вносить, способствовать) route –по сути это более специфичный префикс, который и аггрегируется в менее специфичный):

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;
        }
    }

Aggregate route будет анонсироваться, пока у него есть хотя бы один доступный contribute route. Ниже вывод show route при указанной выше конфигурации. Next-hop в данном случае reject.

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

1.0.0.0/30         *[Direct/0] 00:38:45
                    > via ge-0/0/2.0
1.0.0.2/32         *[Local/0] 00:38:45
                      Local via ge-0/0/2.0
10.0.0.0/8         *[Aggregate/130] 00:23:27
                      Reject                          ## next-hop равен reject
10.0.0.0/30        *[BGP/170] 00:31:03, MED 0, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.0.1.0/30        *[BGP/170] 00:31:03, MED 0, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.0.2.0/30        *[BGP/170] 00:31:03, MED 4500, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.1.1.1/32        *[BGP/170] 00:31:03, MED 0, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.1.1.2/32        *[BGP/170] 00:31:03, MED 4500, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.1.1.3/32        *[BGP/170] 00:31:03, MED 4500, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0

А вот так он будет передан bgp-пиру:

[edit]
root# run show route advertising-protocol bgp 20.1.1.2

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.0.0.0/8              Self                         100        200 ?

Теперь осталось понять природу generate route. Generate route по сути тот же aggregate route, но с реальным next-hop, который берется из contribute route:

[edit routing-options]
root# show
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;
        }
    }

Если в политике указано два и более префикса, то маршрутизатор выбирает next-hop из указанных contribute route, действуя по следующему алгоритму:

1. Маршрут, полученный от протокола с наименьшим protocol preference
2. Наименьший маршрут из всех, например из 192.168.1.0/24, 10.0.0.0/8 и 5.0.0.0/22 наименьшим является последний.
3. Если первые два условия не выявили лучший маршрут, то выбирается маршрут с наименьшей длинной префикса.

Пример применения generate route — это дефолтный маршрут, анонсируемый провайдером клиенту, или редистрибуция внешних маршрутов из BGP в IGP (вместо нескольких сот или тысяч маршрутов генерируется всего одни дефолтный маршрут):

R5#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     20.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       20.0.0.0/30 is directly connected, GigabitEthernet1/0
C       20.0.1.0/30 is directly connected, GigabitEthernet2/0
C       20.1.1.2/32 is directly connected, Loopback0
O       20.0.2.0/30 [110/2] via 20.0.1.2, 00:00:07, GigabitEthernet2/0
O       20.1.1.3/32 [110/2] via 20.0.1.2, 00:00:07, GigabitEthernet2/0
B    10.0.0.0/8 [200/0] via 20.1.1.1, 00:01:36         ## аггрегированный маршрут

Как и aggregate, generate route активен, пока имеется хотя бы одни contribute route. В выводе видно, что маршрут имеет реальный next-hop.

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

1.0.0.0/30         *[Direct/0] 00:35:07
                    > via ge-0/0/2.0
1.0.0.2/32         *[Local/0] 00:35:07
                      Local via ge-0/0/2.0
10.0.0.0/8         *[Aggregate/130] 00:19:49
                    > to 1.0.0.1 via ge-0/0/2.0       ## реальный next-hop
10.0.0.0/30        *[BGP/170] 00:27:25, MED 0, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.0.1.0/30        *[BGP/170] 00:27:25, MED 0, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.0.2.0/30        *[BGP/170] 00:27:25, MED 4500, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.1.1.1/32        *[BGP/170] 00:27:25, MED 0, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.1.1.2/32        *[BGP/170] 00:27:25, MED 4500, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0
10.1.1.3/32        *[BGP/170] 00:27:25, MED 4500, localpref 100
                      AS path: 200 ?
                    > to 1.0.0.1 via ge-0/0/2.0

Примечание: у generate route может быть next-hop discard, если это задаст администратор. В данном случае generate route будет подобен aggregate route. Но для generate route нельзя задать next-hop reject.

[edit]
root# show routing-options
generate {
    route 10.0.0.0/8 {
        policy aggregate-contribute-routes;
        discard;
    }
}

root# run show route

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

1.0.0.0/30         *[Direct/0] 00:45:38
                    > via ge-0/0/2.0
1.0.0.2/32         *[Local/0] 00:45:38
                      Local via ge-0/0/2.0
10.0.0.0/8         *[Aggregate/130] 00:30:20
                      Discard        ## next-hop равен discard

Одной из причин того, что инженеры часто путают или не могут понять разницу между generate и aggregate route является то, что в таблице маршрутизации они имеют одно и тоже обозначение и preference, равное 130 ( в отличии от static, у которого preference 5):

10.0.0.0/8         *[Aggregate/130] 00:30:20

А так же при составлении политик (например для export) и generate и aggregate route обозначаются как protocol aggregate.

Спасибо за внимание!