それで、始めましょう。 上記の3つのタイプのルートはすべて本質的に静的なルートであり、ルーティングオプションの編集階層のjunos設定で指定されています。
静的ルートです。 ネットワークエンジニアなら誰でも知っています。 何らかのネットワークに入る必要がありますが、動的ルーティングプロトコルを使用する可能性（または希望）はなく、出力は静的です。 ジュニパーの静的ルートの例を次に示します。
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に到達する必要があります。静的ルートを規定し、ネクストホップを示します。 IPネットワーク上のパケットルーティングは、ホップごとの動作（PHB）の原則に従って動作します。つまり、各ルーター自体が、既存のルーティングテーブルに基づいてパケットの送信先を決定します（現在、ソースルーティングは考慮していません）。 次のホップは、指定されたネットワークへのルートを持つルーターである必要があります（静的でも構いません）、そうでない場合、パケットはこのルーターによって単にドロップされます（ICMPメッセージを送信するかどうかに関係なく）静的ルートなので、次に進みます。
集約ルート。 本質的に、これは同じ静的ルートであり、ネクストホップまたは拒否または破棄のみです。つまり、このルートを使用してトラフィックを転送することはできません（トラフィックが意図的に破棄にラップされる場合を除く）。 疑問が生じます-なぜこのようなルートが必要なのですか???? このルートにはいくつかの用途があります。 最も一般的な使用法は、複数のより具体的なプレフィックスを1つのより具体的でないものに組み合わせて（たとえば、複数の/ 27- / 28を1/24または/ 22に）、他のbgpピアに転送することです。 とにかくBgpはそれ自体のネクストホップを変更します（デフォルトではebgpの場合、ibgpの場合はネクストホップセルフのポリシーを実行する必要があります）。
これは、JunOS構成での集約ルートの外観です。
routing-options { aggregate { route 10.0.0.0/8 policy aggregate-contribute-routes; }
このポリシー：aggregate-contribute-routesを使用して、コントリビュートルートを設定します（Contributeはより限定的なプレフィックスであり、より限定的なものに集約されます）。
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; } }
集約ルートは、少なくとも1つの利用可能な貢献ルートがある限り発表されます。 上記の設定での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: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-peerに渡されます：
[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 ?
今では、生成ルートの性質を理解する必要があります。 生成ルートは基本的に同じ集約ルートですが、コントリビュートルートから取得される実際のネクストホップを使用します。
[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; } }
ポリシーで2つ以上のプレフィックスが指定されている場合、ルーターは指定されたコントリビュートルートから次ホップを選択し、次のアルゴリズムに従って動作します。
1.プロトコルプリファレンスが最小のプロトコルから受信したルート
2. 192.168.1.0/24、10.0.0.0/8、および5.0.0.0/22など、すべての中で最も小さいルートが最後です。
3.最初の2つの条件が最適なルートを明らかにしなかった場合、最短のプレフィックス長を持つルートが選択されます。
生成ルートの使用例は、プロバイダーによってクライアントにアナウンスされるデフォルトルート、またはBGPからIGPへの外部ルートの再配布です（数百または数千のルートではなく、1つのデフォルトルートのみが生成されます）。
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 ##
集約と同様に、少なくとも1つのコントリビュートルートがある限り、生成ルートはアクティブです。 結論は、ルートに実際のネクストホップがあることを示しています。
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
注：管理者から要求された場合、ルートの生成にはネクストホップ破棄が含まれる場合があります。 この場合、生成ルートは集約ルートに似ています。 ただし、ルートの生成では、ネクストホップ拒否を指定できません。
[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
エンジニアが生成ルートと集約ルートの違いを混同したり、理解できないことがよくある理由の1つは、ルーティングテーブルで同じ指定と優先度が130に等しいことです（静的ではなく、優先度5）：
10.0.0.0/8 *[Aggregate/130] 00:30:20
また、ポリシーをコンパイルするとき（たとえば、エクスポート用）、生成ルートと集約ルートの両方がプロトコル集約として指定されます。
ご清聴ありがとうございました！