Junos ネットワーキングテクノロジー - juniper.net · 6 This Week ：MPLSの導入 MPLS（Multi-Protocol Label Switching ）コアとMPLS サービスの導入を決定

Junos®ネットワーキングテクノロジー

This Week：MPLSの導入

著者：ティム・フィオラおよびジェイミー・パナゴス

第1章: MPLSコアネットワークの概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

第2章: MPLSサービスの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

第3章: MPLSコアの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

第4章: MPLSの導入例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

付録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

ii ii

© 2011 by Juniper Networks, Inc. All rights reserved.Juniper Networks、Juniper Networks のロゴ、Junos、NetScreen、および ScreenOSは、Juniper Networks, Inc.（以下、ジュニパーネットワークス）の米国およびその他の国における登録商標です。Junoseは、Juniper Networks, Inc.の商標です。その他すべての商標、サービスマーク、登録商標、登録サービスマークは、それぞれの所有者に帰属します。ジュニパーネットワークスは、本書中の誤りに対して何ら責任を負いません。ジュニパーネットワークスは、予告なく本書を変更、修正、転載、または改訂する権利を留保します。ジュニパーネットワークスが製造、販売する製品、あるいはその部品は、ジュニパーネットワークスが保有する、あるいはライセンスを受けた以下の米国特許のうち 1件または複数により保護されている場合があります。米国特許第 5,473,599号、第 5,905,725号、第 5,909,440号、第 6,192,051号、第 6,333,650号、第 6,359,479号、第6,406,312号、第 6,429,706号、第 6,459,579号、第 6,493,347号、第 6,538,518号、第 6,538,899号、第 6,552,918号、第6,567,902号、第 6,578,186号、第 6,590,785号。

発行者：Juniper Networks Books著者：ティム・フィオラ、ジェイミー・パナゴス技術校閲者：ユーラル・オースメント主編集者：パトリック・エイムズ校正者：ナンシー・ケルベルJunosプログラムマネージャ：キャシー・ガデッキJ-Netコミュニティ管理：ジュリー・ワイダー

著者の紹介ティム・フィオラは、ジュニパーネットワークスのプロフェッショナルサービス部門上級ネットワークコンサルタントであり、MPLSネットワークの設計、実装、および運用を専門としています。JNCIE-M/T #419の保有者、JNCIS-SEC認定取得者であり、Junosデバイスの操作経験は 7年以上にのぼります。

ジェイミー・パナゴスは、ジュニパーネットワークスのプロフェッショナルサービス部門上級ネットワークコンサルタントであり、データセンター、エンタープライズ、およびサービスプロバイダネットワークの設計、実装、および運用を専門としています。10年以上に渡って世界最大規模のネットワークに携わってきた経験を持ち、大きな影響力を持つ NANOG、ARIN、RIPEを始めとする業界コミュニティのメンバーとして活躍しています。ジェイミーは、JNCIE-M/T#445および JNCIE-ER #50の保有者です。

著者の謝辞ティム・フィオラおよびジェイミー・パナゴスより、本書のアイデアを結実させるために多大な努力を払ってくれたパトリック・エイムズ氏およびキャシー・ガデッキ氏に感謝を申し上げます。クレイグ・サーキン氏がスケジュールに柔軟に対応してくれたおかげで、本書を執筆することができました。最後に、過密なスケジュールを割いて本書の技術的編集にあたってくれたユーラル・オースメント氏、価値ある意見および洞察を与えてくれた校正者の方々、Constant Contact®のニック・ハーランド氏、ジュニパーネットワークスのニック・スラバコフ氏とネイサン・アルガー氏にも深く感謝いたします。

ティム・フィオラは、あらゆる面から支えてくれた家族に特に感謝しています。

また、ジェイミー・パナゴスは、常に辛抱強く支え、このようなプロジェクトを成功へと導いてくれた家族に感謝しています。

本書は、様々な形式で入手できます。詳細については、www.juniper.net/dayoneを参照してください。

皆様のご意見、ご要望、ご批判を電子メールで [email protected]までお送りください。

是非、本書およびその他の Juniper Networks Booksをフォローしてください。 Twitter：@Day1Junos

改訂：v1（This Week）、2011年 4月 ISBN：978-1-936779-24-6（印刷）印刷：Vervante Corporation（米国）

ISBN：978-1-936779-25-3（電子書籍）

2 3 4 5 6 7 8 9 10 #7500210-en

Juniper Networks Booksは、ネットワークの生産性および効率に特に重点を置いた書籍を扱っています。完全なライブラリについては、 www.juniper.net/booksを参照してください。

www.juniper.net/dayone


mailto:dayone%40juniper.net

www.juniper.net/books

iii iii

This WeekへようこそThis Weekシリーズは、Juniper Networks Booksが出版する、非常に高い評価を得ているDay Oneシリーズから発展した書籍です。Day Oneシリーズは、読者が 1日で実施または習得できる量の情報を提供することに重点を置いています。一方、This Weekシリーズでは、ネットワーキングテクノロジーについて、講習形式であれば数日かけて習得する内容を、演習を用いながら探求します。どちらのシリーズも、ジュニパーネットワークス（www.juniper.net/dayone）から入手できます。This Weekの構想は単純です。ジュニパーネットワークスの機器を最大限に活用してその機能や接続性を利用したくても、特定トピックに関するエキスパートレベルの参考資料をすべて探し出して比較考察する時間はなかなか取れません。This Weekシリーズは、このような方に代わって情報を比較考察することで、読者が約1週間という期間で Junosについて有益な知識を新たに習得し、それをすぐに実環境で活かせるように構成されています。This Weekシリーズは、ジュニパーネットワークスの各テーマのエキスパートが執筆し、Juniper Networks Booksによる専門的な編集を経て出版されています。電子版から印刷版まで様々な形式で提供されているため、電車での移動中や、ネットワーキングデバイスに接続された端末に向かいながらなど、どんなスタイルでJunosを探求するかを選ぶことができます。

本書を読む前に知っておくべきこと

本書を読む前に、Junos OSの基本的な管理機能について理解しておいてください。例えば、操作コマンドを使用したり、Junosの設定を読み取り、理解し、変更したりできる必要があります。

この他、本書を探求していくうえで以下のことが役立ちます。 � Junosデバイスを実際に使用しながら読み進めると、設定や各自のアイデアを試すことができます。本書に掲載されている設定をコピーして使い慣れたテキストエディターに貼り付けることのできるコピーアンドペースト版は、 www.juniper.net/dayoneからリッチテキスト形式で無料で入手できます。

� ルーティングおよび BGP、OSPF、ISISなどのルーティングプロトコルに関する基本的な知識。

前提条件本書では、読者が以下の条件を満たしていることを前提としています。これらの条件のうち満たされていないものがある場合、本書に記載されてる内容を容易に理解できなかったり、設定例を実際のデバイスやテストベッドにスムーズに実装できない可能性があります。

� BGPと、OSPFまたは ISISについての経験が実際にあること、または少なくとも実際的な基本知識があること

� Junos CLIに関する実際的な知識が豊富なこと � MPLSの導入に関心がある、またはその計画があること � 初期導入において、ルーティングドメイン内でのユニキャストの IPv4トラフィックに重点を置くこと



iv iv

本書の学習目標

本書は、MPLS（Multi-Protocol Label Switching）のメカニズムおよび機能の理解に役立ちます。これには、MPLSでどのように値が提供されるか、MPLSネットワークをどのように設計および実装すればよいか、レイヤー 3 VPNや VPLSなどのMPLSアプリケーションをどのように有効にすればよいかなどが含まれます。本書では、MPLSについて特定のスキルを学習します。本書を読み終えると、以下のことができるようになります。

� ラベルスイッチドパスとは何か、またどのように動作するかについて理解する � LDPとRSVPの違いを説明する � MPLSネットワークにおける障害回復力について理解する � トラフィック制御や障害復旧などの高度な機能を含む、MPLSネットワークを実装する

� レイヤー 3 VPN、レイヤー 2 VPN、および VPLSの基本的な実装の設定方法を理解する

� ネットワークの設計およびアーキテクチャにおいて考慮すべき要素を理解する � MPLSネットワークの設計および成長時にスケーリングファクターを分析する � ネットワークの例を基に、各自のネットワークを設計する

MPLS導入に関する読者への留意事項本書では、2つのテストベッドを使用しました。1つ目は、パケットモードの Jシリーズルーターから成るテストベッドです。VPLSを実行する JシリーズルーターではJunos 10.0R3.10を実行し、VPLSを実行しないルーターでは 9.6R4.4を使用しました。また、ハイエンドルーターおよびMXシリーズプラットフォームでのみ利用可能な（本書の執筆時点）MPLS機能について説明するために、Junos 10.3R1.9を実行するMX-80、M10i、M5ルーターから成るテストベッドを使用しました。本書では、一般的な環境におけるMPLSの概念と例を紹介することを目的としているため、inter-AS VPN、NG-MVPN、IPv6など高度なMPLSトピックについては扱っていません。読者が本書で学んだことを活かしてMPLSネットワークの導入を成功させ、また前述のような高度なトピックが必要になったときには、この知識が土台として役立てばと思います。

さらに詳しくは NG-MVPNに関する優れた著書として、新たな『This Week:Deploying MBGP Multicast VPNs』があります。これは、www.juniper.net/dayoneから入手できます。

さらに詳しくは高度なMPLSトピックに関する優れた著書として、アイナ・ミネイおよびジュリアン・ルセック著『MPLS-Enabled Applications, Third Edition』（2011年Wiley & Sons Publishers）があります。このMPLSベストセラー書籍の詳細については、www.juniper.net/booksを参照してください。


www.juniper.net/books

第1章

MPLSコアネットワークの概念

はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

RSVP LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

フェイルオーバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

トラフィック制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

LSPの帯域幅管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

6 This Week：MPLSの導入

MPLS（Multi-Protocol Label Switching）コアとMPLSサービスの導入を決定した後に、その概念について理解し、ニーズに合った柔軟性と拡張性を備えたアーキテクチャを設計し、最後にその設計をネットワークに実装する作業は、気の遠くなるような道のりになる可能性があります。本書では、これらのステップを案内します。最初の章では、MPLSコアネットワークのさまざまな概念について説明します。この概念をしっかり理解しておけば、自信を持って次のステップへと進み、その知識を基に、新たな Junos MPLSコアネットワークにはどんな特性があるか、またそれには何が必要かを判断することができます。

はじめにMPLSネットワークにおいて最も重要になるのがコアMPLSプロトコルの選択です。ラベルスイッチドパス（LSP）を利用するには、LSPが経由する各ルーターでMPLSプロトコルが必要になります。ルーターは、MPLSプロトコルを使用することにより、ラベルと宛先およびその他ラベルを照合するためのローカルデータベースを確立し、これらのラベルを隣接ルーターと交換して、ラベル付きパケットを送受信することができます。この章では、MPLSプロトコルのオプションについて説明します。後の第3章では、特定のネットワークに最適なMPLSプロトコルはRSVPか LDPか、またはその両方かを判断する方法について説明します。まずは、LSPとは何か、また LSPはどのように確立されるかについて説明しましょう。LSPとは、ラベル付きパケットがネットワークを通過するときに取るルートです。パケットの宛先 IPアドレスに基づくルーティングの代わりに、ラベル付きパケットは、パケットに付けられた数値ラベルの値に基づいてネットワーク上でルーティングされます。LSPの受信または Egressルーターを LER（Label Edge Router）と言います。これに対して、LSR（Label-swithcing Router）は受信ラベルの値に基づいてスイッチングを行うトランジットルーターです。図 1.1に、5台のMPLSルーターと、R1からR5までの LSPを示します。R1は LSPの Ingress LERです。R2、R3、および R4は、MPLSラベルに従ってスイッチングのみを行うLSR、R5は LSPの Egress LERです。R4は R3に対し、R4に送信するパケットにラベル 234875を付加すれば R4経由で R5に到達できることを通知するラベルをアドバタイズします（Ingress LSR R1が実施するラベルの付与動作をプッシュと呼びます）。Egress LER R5に到達するためのラベル処理は各ルーターで行われ、隣接のルーターにラベルを通知します。これを上流のルーターでも繰り返すことで、ラベルパスを形成します。R1が R5に到達するために使用するルーターのパスに沿った一連のラベルを、R1からR5へのラベルスイッチドパスと言います。各 LSPのラベル、トランジットルーター、および宛先の組み合わせはそれぞれ固有のため、LSPは単方向の性質を持ちます。すなわち、図 1.1の R1からR5へのトラフィックが使用する LSPと、R5からR1へのトラフィックが使用する LSPは同じではありません。

R5

R4 R3

R2

R1

パケット

ラベル168942 パケット

ラベル145783

パケット

ラベル234875

パケット

R1からR5に到達するために、ラベル168942 を要求



R2はラベル168942を削除し、ラベル145873を追加して、パケットをR3に送信


R4はラベル234875を削除して、パケットをR5に送信

図 1.1 Egress LER R5へのMPLSラベル情報伝搬

第1章：MPLSコアネットワークの概念 7

注パケットの先頭に付加されるラベルは、パケットのラベルスタックと呼ばれ、一般に、図示するときには 1つ以上のラベルが積み重ねられた（スタックされた）パケットとして表されます。本書の後の章では、複数のラベルを積み重ねることがなぜ必要なのかを考察します。

図 1.1では、R1はパケットにラベルをプッシュし、そのパケットを R2に転送します。R2は、ラベル付きパケットを受信すると、168942ラベルを削除して 145783ラベルに置き換え（この処理をラベルスワップと言う）、そのパケットを R3に転送します。R3も同様にラベルスワップを実行し、ラベル 145783を 234875に交換します。R4も同じようにR3からラベル付きパケットを受信しますが、ラベルを削除し（ラベルを置き換えるのではなく、ラベルスタックからラベルを削除することをポップと言う）、ラベルのない状態でパケットをR5に転送します。これをPHP（Penultimate Hop Popping）と言います。R5は LSPの終端にあるため、ラベル付きパケットを受信する必要はありません。PHPにより、R5は、ラベルのポップ処理を省略し、宛先アドレスに基づいてパケットを転送することができます。

LSPの Egressルーターが最後から 2番目のルーターに PHPを実行するよう通知するときは、トップラベルをポップしてパケットを送信するよう指示する値 3のラベルオブジェクトをアドバタイズします。ラベル値 3は、PHPの通知専用に予約されている値です（ラベル値 3が実際にラベルとして送信されるわけではない）。以下は、lagavulin-to-dalwhinnie LSPにおける、最後から 2番目のルーターである glenlivetの出力です。ここには、dalwhinnie宛ての LSPトラフィックに対して Label out値 3が示されています。これは、このルーターが LSPラベルなしでdalwhinnieにパケットを送信することを意味します。ラベルなしのパケットを受信した dalwhinnieに必要な処理は、宛先アドレスについて通常のルートルックアップを実行することのみです。

ps@glenlivet> show mpls lsp name lagavulin-to-dalwhinnie detailIngress LSP:0 sessionsTotal 0 displayed, Up 0, Down 0

Egress LSP:2 sessionsTotal 0 displayed, Up 0, Down 0

Transit LSP:1 sessions

10.200.86.5 From:10.200.86.7, LSPstate:Up, ActiveRoute:1 LSPname: lagavulin-to-dalwhinnie, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:3 Resv style:1 FF, Label in:300016, Label out:3 Time left:126, Since:Tue Feb 15 03:28:02 2011 Tspec: rate 64kbps size 64kbps peak Infbps m 20 M 1500 Port number: sender 1 receiver 30254 protocol 0 PATH rcvfrom:192.168.86.45 (ge-0/0/3.0) 42150 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto:192.168.86.6 (ge-0/0/2.0) 42297 pkts RESV rcvfrom:192.168.86.6 (ge-0/0/2.0) 42264 pkts Explct route:192.168.86.6 Record route:192.168.86.2 192.168.86.42 192.168.86.45 <self> 192.168.86.6Total 1 displayed, Up 1, Down 0

PHPは、MPLSを実行するすべての Junosデバイスのデフォルト動作です。PHPに代わる動作としてUHP（Ultimate Hop Popping）があります。UHPの場合、LSPの Egressルーター（LSPの最後のルーター）は LSPの最後から2番目のルーターに対し、ラベル付きパケットを送信するよう要求します。図 1.1で UHPが設定されている場合、最後から 2番目のルーターであるR4は、ポップではなくラベルスワップを実行し、ラベル付きパケットを R5に送信します。

注 UHPは、QoSを適切に機能させるため、またはベンダー間の相互接続性を確保するために、一部のMPLSネットワークで必要になる場合があります。


Junosデバイスに UHPを設定するには、以下のように、MPLS protocolの階層で explicit-nullを設定します。[edit protocols mpls]ps@dalwhinnie# showexplicit-null;......

Egressルーターに UHPが設定されている場合、このルーターは、最後から 2番目のルーターに値 0のラベルオブジェクトをアドバタイズします。これにより、最後から 2番目のルーターに対し、トップラベルのラベルスワップ（ポップではなく）を実行し、トップラベル値を 0にしてパケットを Egressルーターに送信するよう通知されます（図 1.2を参照）。ラベル値 0は、UHP用に予約されています。以下は、dalwhinnieに UHPが設定されている場合の、最後から 2番目のルーターであるglenlivetの出力です。ここには、Label out値として0が示されています。この場合、dalwhinnieはラベルをポップしてから、通常のルーティングテーブルルックアップを実行します。

ps@glenlivet> show mpls lsp name lagavulin-to-dalwhinnie detailIngress LSP:0 sessionsTotal 0 displayed, Up 0, Down 0


Transit LSP:1 sessions

10.200.86.5 From:10.200.86.7, LSPstate:Up, ActiveRoute:1 LSPname: lagavulin-to-dalwhinnie, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:0 Resv style:1 FF, Label in:302016, Label out:0 Time left:146, Since:Tue Feb 15 03:28:02 2011 Tspec: rate 64kbps size 64kbps peak Infbps m 20 M 1500 Port number: sender 1 receiver 30254 protocol 0 PATH rcvfrom:192.168.86.45 (ge-0/0/3.0) 42156 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto:192.168.86.6 (ge-0/0/2.0) 42302 pkts RESV rcvfrom:192.168.86.6 (ge-0/0/2.0) 42269 pkts Explct route:192.168.86.6 Record route:192.168.86.2 192.168.86.42 192.168.86.45 <self> 192.168.86.6Total 1 displayed, Up 1, Down 0

注ラベル値 2は、IPv6の明示的 nullラベル用に予約されています。

R5

R4 R3

R2

R1

パケット

ラベル168942 パケット

ラベル145783

パケット

ラベル234875

パケット

ラベル0




R4からここに到達するために、ラベル0のパケットを要求



R4はラベル234875を削除して、パケットをR5に送信

図 1.2 UHPを使用した Egress LER R5へのMPLSラベル情報伝搬


RSVP LSP

先に進む前に、図 1.3に、9台のルーターで構成されるMPLSドメインのネットワーク構成を示します。本書の以降の部分では、この図を基に説明を進めていきます。カスタマーエッジルーターはこの図に含まれていませんが、第 2章でMPLSサービスについて説明するときに追加します。特に記載がなければ、これらの各ルーターでは、コア側の各インタフェースでコアMPLSプロトコルとしてRSVPおよびLDPが両方実行されています。本章のケーススタディでは、この図を参照してください。

tormore lo0 10.200.86.9

mortlach

lo0 10.200.86.2

glenlivet lo0 10.200.86.6

lagavulin

lo0 10.200.86.7

blair lo0 10.200.86.1

oban lo0 10.200.86.3

macduff lo0 10.200.86.8

特に明記されていない限り、インタフェースのIPアドレスはすべて192.168.86/24ネットワークの/30サブネットに属しています。

特に明記されていない限り、論理インタフェースユニットはすべて.0です。

リンクに対してインタフェース名が1つだけ示されている場合、その名前がリンク両端のルーターのインタフェース名です。

.1

.6

.5

.2

.34

talisker lo0 10.200.86.4

ge-0/0/2

ge-0/0/3

.30

.29

ge-0/0/1 .10 .9

.46

.45

ge-0/0/3

ge-0/0/2

ge-0/0/1 .14

fe-0/0/1 .13

fe-2/0/1

ge-0/0/3 .42

.41

ge-0/0/2 .50

ge-0/0/3 .18

fe-2/0/0 .17

ge-6/0/0 .26

.25

ge-0/0/2

ge-0/0/3

.38

.37

fe-2/0/1

.33

ge-0/0/2

e1-1/0/0

.22

fe-0/0/1 fe-2/0/0

.49

.21

図 1.3 本書で使用する、9台のルーターで構成されるMPLSドメインのネットワーク構成

RSVPは、resource reservation protocol（リソース予約プロトコル）の略です。RSVPは、トラフィック制御（TE）、高速なフェイルオーバー、QoS、帯域幅の予約、LSPのカスタマイズなど豊富な機能を備えているため、コアネットワークのMPLSプロトコルとして広く使用されています。RSVP LSPは、LDP LSPより多くの設定が必要になりますが、LDP LSPより多くの機能が提供されます（LDPについては、次のセクションで説明）。また、RSVPの設定の複雑さは、RSVP自動メッシュ（Junos 10.1より利用可能）などの最新機能により軽減されます。RSVP自動メッシュについては、第 3章で説明します。

Junosデバイスで基本的な RSVP LSPを設定するにはまず、LSPの Ingressルーターから開始します。1. family mplsを使用して、RSVPを実行するインタフェースを設定します（通常は、コア側のすべてのインタフェース）。


[edit interfaces]ps@dalwhinnie# show ... <snip> ... ge-0/0/2 { unit 0 { description "Connection to glenlivet ge-0/0/2.0"; family inet { address 192.168.86.6/30; } family mpls; }}ge-0/0/3 { unit 0 { description "Connection to lagavulin ge-0/0/3.0"; family inet { address 192.168.86.30/30; } family mpls; }}

2. [edit protocols mpls]階層で、to <destination>ステートメントを使用してlabel-switched-pathを設定し、MPLSを実行するインタフェースを設定します。 [edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban { ##only on lsp ingress router to 10.200.86.3;}interface ge-0/0/2.0;interface ge-0/0/3.0;

3. [edit protocols rsvp]階層で、RSVPを実行するインタフェースを設定します。 [edit protocols rsvp]ps@dalwhinnie# showinterface ge-0/0/2.0 interface ge-0/0/3.0

次に、MPLSドメイン内の各ルーターを手順 1～ 3に従って設定します。ただし、手順 2で示した label-switched-pathステートメントは使用しません。RSVP LSPの設定は、LSPの Ingressルーターでのみ行います。上記の手順 1および 2に関して、設定の際に [edit protocols mpls]レベルでインタフェースを指定し、同じインタフェースに対して [edit interfaces unit <unit

number>]レベルで family mpls設定を行う必要があるのはなぜか、これは重複していないのか、という質問がよく寄せられます。

これはもっともな疑問です。その理由を以下に説明します。[edit protocols mpls]でインタフェースを指定することにより、これらのインタフェースがMPLSプロトコルを実行し、RSVP LSPで使用可能なリソースとして TED（Traffic Engineering Database）に保持されるようになります。一方、論理インタフェースに対してfamily mplsを設定すると、そのインタフェースがラベル付きパケットを送受信できるようになります。この機能がないと、インタフェースはラベル付きパケットに対してどのような処理を実行すればよいのかわからず、そのパケットを単純に破棄してしまいます。よくあるのが、一方のみを設定し、もう一方を設定しないという間違いです。この場合、以下のように、設定されているすべての RSVP LSPに対してCSPF


Failed:no route toward <destination>が表示され、その原因をトラブルシューティングするために時間を費やすことになります。

[edit protocols mpls]ps@dalwhinnie# show label-switched-path dalwhinnie-to-lagavulinto 10.200.86.7;

[edit protocols mpls]ps@dalwhinnie# run show mpls lsp name dalwhinnie-to-lagavulin detailIngress LSP:3 sessions

10.200.86.7 From:0.0.0.0, State:Dn, ActiveRoute:0, LSPname: dalwhinnie-to-lagavulin ActivePath:(none) LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 Primary State:Dn Priorities:7 0 SmartOptimizeTimer:180 Will be enqueued for recomputation in 19 second(s). 84 Oct 2 00:51:48.731 CSPF failed: no route toward 10.200.86.7[9 times]

LSPの宛先までMPLSが有効になっている完全なパスがないため、RSVP LSP dalwhinnie-to-lagavulinが有効になることができないのです。

注 LDPの場合は、[edit protocols mpls]でインタフェースを設定する必要はありません。この設定が必要なのは、RSVP LSPのみです。ただし、どちらのプロトコルの場合も、実際の論理インタフェースに対して family mplsを設定する必要があります。

注直感に反するようですが、RSVPによってシグナリングされる LSPは [edit

protocols mpls]階層で設定します。

すべて正しく設定すると、RSVP LSPが有効になります。以下の出力には、LSPの状態が Upとして示され、LSPのレコードルート（ネットワークを通過する LSPのパス）が示されています。LSPの受信レコードルートには、RSVP LSPが経由する、Ingressおよび Egressノードを含むインタフェースの IPアドレスのリストが含まれます。この出力には、このルーターがパケットを下流ルーターに送信する前に、パケットにラベル 300432をプッシュしていることも示されています。

ps@dalwhinnie> show rsvp session lsp name dalwhinnie-to-oban detailIngress RSVP:1 sessions

10.200.86.3 From:10.200.86.5, LSPstate:Up, ActiveRoute:0 LSPname: dalwhinnie-to-oban, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:300432 Resv style:1 FF, Label in:-, Label out:300432 Time left: -, Since:Wed Jul 21 03:36:04 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 1773 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.5 (ge-0/0/2.0) 126 pkts RESV rcvfrom:192.168.86.5 (ge-0/0/2.0) 124 pkts Explct route:192.168.86.5 192.168.86.9 192.168.86.25 Record route:<self> 192.168.86.5 192.168.86.9 192.168.86.25Total 1 displayed, Up 1, Down 0


LSPパスに含まれる各ルーター（Ingressおよび Egressルーターを含む）では、RSVP LSPが使用するすべてのインタフェースで RSVPが有効になっていなければなりません。本書では、後の章でその他の RSVP機能について詳しく探求します。

LDP LSP

LDP（Label Distribution Protocol）は、コアMPLSプロトコルとして使用できるもう 1つのオプションです。LDPは、設定が RSVPより大幅に簡単ですが、高速フェイルオーバーメカニズム、トラフィック制御機能などの機能がありません。簡単に言うと、LDPでは、MPLSサービスの基盤となるMPLSコアを比較的簡単に確立できますが、その他の機能に関しては、ISISや OSPF以上のことを実行することができません。一方、LFA（Loop-Free Alternates）などの最近の開発により、ある程度のフェイルオーバーメカニズムは付加されますが、それでもRSVPに比較すると機能は限定的です。

LDPコアを確立するには1. 各ルーターのコア側のインタフェースに family mplsを設定します。ps@tormore> show configuration interfaces ... <snip> ... ge-0/0/2 { unit 0 { description "Connection to talisker fe-2/0/1.0"; family inet { address 192.168.86.33/30; } family mpls; }}ge-0/0/3 { unit 0 { description "Connection to oban ge-0/0/3.0"; family inet { address 192.168.86.37/30; } family mpls; }}

2. [edit protocols ldp]階層で、手順 1の各インタフェースを設定します。ps@tormore> show configuration protocols ldpinterface ge-0/0/2.0;interface ge-0/0/3.0;

3. MPLSドメイン内の各ルーターに対して手順 1～ 2を繰り返します。手順 1～ 3が完了すると、各ルーターは、lo0アドレスへのルートについて隣接ルーターとLDPラベルを交換できるようになります。このラベルを受信したすべての隣接ルーターは、その他の隣接ルーターにその LDPの到達性をラベルによってアドバタイズします。このような処理により、各ルーターは、LDPドメインに含まれるその他すべてのルーターの lo0アドレスへの LDP LSPを学習します。RSVPとは異なり、ネットワークを通過する LDP LSPルートは、直接制御したり（IGPの最短パスに従う）、単一のルーターから表示したりできません。ラベル操作および LSP上の次のルーターを確認するには、各ネクストホップルーターで LDPを確認する必要があります。


[edit protocols mpls]ps@tormore# run show route protocol ldp 10.200.86.7

inet.0:32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)

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

10.200.86.7/32 *[LDP/9] 00:00:17, metric 1 > to 192.168.86.34 via ge-0/0/2.0, Push 300080

tormoreは、10.200.86.7宛てのパケットに値300080のラベルをプッシュします。

フェイルオーバーネットワーク設計者やネットワークエンジニアにとって、リンクやノードで障害が発生した場合のネットワークの動作は、考慮すべき最も重要な事柄です。特に、フェイルオーバーモードを適切に設計すれば、容量プランニングを適切に計画し、必要に応じてネットワークを拡張し、サービス品質要件を満たすことができます。また、ネットワーク運用者がネットワーク障害にどのように対応するかを決定するうえでも重要な要素になります。ジュニパーネットワークスのルーターは、ネットワークの障害に対処するための豊富なオプションを備えています。ここで説明するフェイルオーバーオプションは、IngressルーターとEgressルーター間の単一障害点からRSVP LSPを保護することを目的としています。ただし、障害が複数箇所で発生した場合は、以降に説明する方法が役立たないこともあります。また、ここで説明するどの方法も、LSPの Ingressまたは Egressルーターの壊滅的障害から保護することはできません。

リンクプロテクション

リンクプロテクションは、RSVPラベルスイッチドパス上で発生したリンク障害からのプロテクションを提供します。リンクプロテクションが設定されている場合、LSP上にある各ルーター（Egressルーターを除く）は、LSPの次のルーターへの代替パスを見つけようとします。この代替パスはネクストホップバイパス LSPと呼ばれます。ネクストホップバイパス LSPの目的は、保護されたリンクの向こう側にあるルーターへの代替パスを提供することです。各ネクストホップバイパス LSPは、メイン LSPの確立後に確立されます。LSP上にある 2台のルーター間でリンク障害が発生すると、障害が発生したリンクに接続された、LSPIngressルーターに最も近いローカルルーターにより修復アクションが開始されます。このルーターは、ローカル修復ポイント（PLR）と呼ばれます。

図 1.4 に、glenlivetと blair 間のリンク切断を示します。glenlivet の方がIngressルーター（dalwhinnie）に近いため、glenlivetが PLRになります。リンク切断を最初に認識するルーターは glenlivetとblairであるため、glenlivetは素早く反応し、事前にシグナリングされた、glenlivet-mortlach-blairを通るネクストホップバイパス LSPでトラフィックを送信します。特定のネクストホップバイパス LSPを提供するほどネットワークトポロジーが充実していない場合、ルーターはバイパス LSPを確立しませんが、プライマリLSPはサポートします。切断箇所に最も近いルーターがリンク切断を素早く検出してそれに対処できるため、リンクプロテクションは最も迅速なフェイルオーバーオプションです。リンクプロテクションには、拡張性というメリットもあります。glenlivetは、単一のネクストホップバイパス LSPである glenlivet-mortlach-blairを使用して、障害リンクを経由して blairに向かうすべての LSP上のトラフィックを保護します。これは、比較的少数のネクストホップバイパス LSPがあれば、多数のプライマリLSPを保護できるということです。


tormore lo0 10.200.86.9

mortlach lo0 10.200.86.2


lagavulin lo0 10.200.86.7

blair lo0 10.200.86.1

dalwhinnie lo0 10.200.86.6

oban lo0 10.200.86.3

macduff lo0 10.200.86.8

.1

.6

.5

.2

.34


.30

.29

.10 .9

.46

.45

.14

.13

.42

.41

.50 .18

.17

.26 .25

.38

.37

.33

.22

.49

.21

X

インタフェースのIPアドレスはすべて192.168.86/24ネットワークの/30サブネットに属しています。

LSPのプライマリパス

迂回されたLSPのパス

図 1.4 リンク切断時のリンクプロテクション

図 1.5に、glenlivetとblair間のリンクを共有する dalwhinnie-to-oban LSPとdalwhinnie-to-tormore LSPを示します。このリンクがダウンした場合、どちらのLSPも、glenlivet-mortlach-blairを経由するネクストホップバイパス LSPを使用できます。このように保護された LSPを多重化できるため、リンクプロテクションは非常に拡張性に優れた方式です。

tormore lo0 10.200.86.9



blair lo0 10.200.86.1



oban lo0 10.200.86.3

macduff lo0 10.200.86.8


.1

.6

.5

.2

.34


.30

.29

.10 .9

.46

.45

.14

.13

.42

.41

.50 .18

.17

.26 .25

.38

.37

.33

.22

.49

.21

X

dalwhinnie-to-oban LSPのプライマリパスdalwhinnie-to-tomore LSPのプライマリパス

dalwhinnie-to-oban LSPで迂回されたトラフィックのパスdalwhinnie-to-tomore LSPで迂回されたトラフィックのパス

図 1.5 同じバイパス LSPを共有するdalwhinnie-to-oban LSPとdalwhinnie-to-tormore LSP


以下の出力には、glenlivetの 1つのバイパス LSPにより2つのトランジット LSPが保護されていることが示されています。

ps@glenlivet> show mpls lsp transitTransit LSP:2 sessionsTo From State Rt Style Labelin Labelout LSPname10.200.86.3 10.200.86.5 Up 1 1 SE 300208 300112 dalwhinnie-to-oban10.200.86.9 10.200.86.5 Up 1 1 SE 300224 300128 dalwhinnie-to-tormoreTotal 2 displayed, Up 2, Down 0

ps@glenlivet> show mpls lsp bypass ingress detailIngress LSP:1 sessions

10.200.86.1 From:10.200.86.6, LSPstate:Up, ActiveRoute:0 LSPname:Bypass->192.168.86.9 Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:299936 Resv style:1 SE, Label in:-, Label out:299936 Time left: -, Since:Fri Jul 16 04:08:48 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 53500 protocol 0 Type:Bypass LSP Number of data route tunnel through:2 Number of RSVP session tunnel through:0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.45 (ge-0/0/3.0) 218 pkts RESV rcvfrom:192.168.86.45 (ge-0/0/3.0) 218 pkts Explct route:192.168.86.45 192.168.86.50 Record route:<self> 192.168.86.45 192.168.86.50Total 1 displayed, Up 1, Down 0

glenlivet の Bypass LSP->192.168.86.9 では、2 つの LSP（Number of data route tunnel through:2）を保護しており、192.168.86.45 および192.168.86.50を経由しています。LSPのトラフィックは blairに到達すると、再び元の LSPについてシグナリングされたパスでそれぞれの宛先であるobanまたは tormoreに到達します。ネクストホップバイパス LSPによるトラフィックの迂回は、一次的な処置です。PLRはトラフィックをバイパス LSPに切り替えると、LSPの Ingressルーターへのシグナリングも行います。これにより、Ingressルーターは、その LSPの別のプライマリパスをシグナリングしようとします。LSPのトラフィックがバイパス LSPにフェイルオーバーするときに行われるラベル操作を理解しておくと、フェイルオーバーメカニズムの本質をより深く理解することができます。glenlivetを経由しているdalwhinnie-to-oban LSPを調べると、glenlivetは、トラフィックを blairに送信する前に、ラベル 303168を 303296にスワップします。glenlivet-blairリンクに障害が発生した場合、glenlivetはトラフィックをバイパス LSPに切り替え、パケットをmortlachに転送する前に、同様に初期ラベルスワップを実行し、さらにラベルをプッシュして 300880をトップラベルとして追加します。この例の 300880ラベルは、トラフィックがバイパス LSPを使用するときに追加されることから、バイパスラベルとも呼ばれます。この LSPを調べてみましょう。

ps@glenlivet> show mpls lsp transit name dalwhinnie-to-obanTransit LSP:5 sessionsTo From State Rt Style Labelin Labelout LSPname10.200.86.3 10.200.86.5 Up 1 1 SE 303168 303296 dalwhinnie-to-obanTotal 1 displayed, Up 1, Down 0

ps@glenlivet> show route table mpls.0 label 303168 detail | match Label Label-switched-path dalwhinnie-to-oban Label operation:Swap 303296


Label-switched-path Bypass->192.168.86.9 Label operation:Swap 303296, Push 300880(top)

この出力から、glenlivetは、ラベル 303168のパケットを受信すると、そのラベルを 303296にスワップすることがわかります。また、glenlivetとblair間でリンク切断が発生した場合は、引き続きラベル 303168を 303296にスワップしますが、さらに 303296の上にラベル 300880をプッシュします。glenlivetは、バイパスLSPによってパケットが blairに配信されることを認識しているため、パケットをバイパス LSP用の送信インタフェースから送信します。リンク切断が発生した場合、パケットはmortlachに着信します。このルーターは 300880ラベルをポップし（バイパス LSPで PHPを使用）、スタックにラベル（303296）を 1つのみ残した状態でパケットを blairに送信します。

ps@mortlach> show route table mpls.0 label 300880 detail

mpls.0:27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)300880 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:584 Next-hop reference count:3 Next hop:192.168.86.50 via fe-2/0/0.0 weight 0x1, selected Label-switched-path Bypass->192.168.86.9 Label operation:Pop State:<Active Int> Local AS:7176 Age:54:59 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

300880(S=0) (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:594 Next-hop reference count:2 Next hop:192.168.86.50 via fe-2/0/0.0 weight 0x1, selected Label-switched-path Bypass->192.168.86.9 Label operation:Pop State:<Active Int> Local AS:7176 Age:54:59 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

注特定ラベルについてmpls.0テーブルに保持されている (S=0)エントリーは、ラベルスタック深さ n>=2でルーターに着信したパケットが、ラベルスタック深さ n-1でルーターから送信されることを示します。情報にS=0の記述が含まれていない場合、ラベルスタック深さ 1でルーターに着信したパケットが、ラベルなしの状態でルーターから送信されることを示します。この例では、パケットはスタック深さn=2でルーターに着信しています。

図 1.6に示すように、バイパス LSPの本当の効果は、パケットがトップラベル303296の状態で blairに着信することです。これは、パケットがバイパス LSPを使用しなかった場合とまったく同じ状況です（唯一異なる点は、パケットが異なるインタフェースに着信することだが、ラベルは特定のインタフェースに関連付けられないため問題ない）。すなわち、blairでは、バイパス LSPでトラフィックを受信した場合も、その処理動作を変更する必要がありません。リンクプロテクションでもノードリンクプロテクション（次のセクションで説明）でも、バイパス LSPでバイパスラベルが使用されます。




blair lo0 10.200.86.1


oban lo0 10.200.86.3


.6

.5 .10 .9

.46

.45

.50

.26 .25

.38

.49


X


パケット

303296

パケット

303296

300880

パケット

303296

図 1.6 リンクプロテクションのラベル操作

リンクプロテクションを設定するには、MPLS label-switched-path内、および [edit

protocols rsvp]階層レベルの各インタフェース内に、link-protectionキーワードを含めます。両方のレベルでこの設定を行わないと、LSPがリンクプロテクションされません。リンクプロテクションをこれらの 2つの領域で設定しなければならない理由を理解しておくことが重要です。LSP設定内の link-protectionキーワードは、ネクストホップバイパス LSPを使用できる場合に、そのバイパス LSPで LSPを保護するよう Ingressルーターおよびトランジットルーターに指示します。一方、[edit

protocols rsvp]階層のインタフェース階層内の link-protection設定は、リンクプロテクションされた LSPがその RSVPインタフェースを経由する場合に、バイパスLSPをシグナリングする必要があることをルーターの RSVPに通知します。この 2つの違いについて考慮しなければならないもう 1つの点は、LSP設定（Ingressルーターのみ）が、LSPのパス上にあるすべての LSRに、それぞれのバイパスをシグナリングするよう指示することです。これは、LSRの送信 RSVPインタフェースにリンクプロテクションが設定されている場合のみ可能です。[edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; link-protection;}label-switched-path dalwhinnie-to-oban-lo-priority { to 10.200.86.3; link-protection;}path via-tormore;interface ge-0/0/2.0;interface ge-0/0/3.0;

[edit protocols rsvp]ps@dalwhinnie# showinterface ge-0/0/2.0 { link-protection;}interface ge-0/0/3.0 { link-protection;}


リンクプロテクションの欠点として、LSP上にある各トランジットルーターで、この機能を必要とするRSVPインタフェースにリンクプロテクション機能を設定しなければならないため、各ルーターの設定が多少増えることが挙げられます。

ヒントリンクプロテクションを使用するときは、ベストプラクティスとして、RSVPドメインに含まれる各ルーターのすべての RSVPインタフェースでリンクプロテクション機能を有効にすることをお奨めします。これにより、特定時点で LSPがどのルーターまたはコア側インタフェースを経由しているかに関係なく、RSVP LSPのリンクプロテクションを使用することができます。

ノードリンクプロテクション

ノードリンクプロテクションは、リンクプロテクションで提供されるフェイルオーバープロテクションを基盤としています。ノードリンクプロテクションでは、前のセクションで説明したネクストホップバイパス LSPとネクストネクストホップバイパス LSPの 2つのタイプのフェイルオーバー LSPがシグナリングされます。ネクストネクストホップバイパス LSPの目的は、ネクストホップルーターのネクストホップルーターへの代替パスを保護された LSP上のトラフィックに提供することです。これにより、LSPのネクストホップルーターにおいてリンクのダウンやハードウェアまたはソフトウェアの壊滅的障害が発生した場合に LSPを保護することができます。つまり、ネクストホップのネクストホップルーターへの代替パスを提供するのがネクストネクストホップバイパス LSPです。ネクストネクストホップバイパス LSPを提供するほどネットワークトポロジーが充実していない場合、またはルーターが LSPの最後から2番目のルーターの場合、ルーターは代わりにネクストホップバイパス LSPをシグナリングします。ネットワークトポロジーがネクストホップバイパス LSPをサポートしていない場合は、バイパス LSPは確立されませんが、ルーターでは元の LSPがサポートされます。図 1.7に、ノードリンクプロテクションによるネクストネクストホップバイパス LSPの確立シナリオを示します。

R5

R4

R3

R2

R1

R6 R7

R8

R9 R10

LSP R1-R5で通常トラフィックのパス

LSP R1-R5で迂回されたトラフィックのパス

X

図 1.7 R1-R5 LSPと、ノードリンクプロテクションによって確立されるネクストネクストホップバイパス LSP

ノードリンクプロテクションを設定するには、この保護を実装する各MPLS LSP内にnode-link-protectionキーワードを含めます。また、ノードリンクプロテクションされた


LSPが経由する可能性のある各RSVPインタフェースにリンクプロテクションを設定することも必要です。この場合、ローカルルーターは、ノードリンクプロテクションを要求している LSPを検出すると、その LSPのネクストネクストホップルーターへのバイパス LSPをシグナリングしようとします。これを行えない場合は、ネクストホップバイパス LSPをシグナリングします。リンクプロテクションと同様に、ノードリンクプロテクションを有効にする場合は、ベストプラクティスとして、RSVPドメインに含まれる各ルーターの、RSVPが設定されているすべてのインタフェースで、リンクプロテクションを設定することをお奨めします。これにより、LSPが経由する可能性のあるすべてのコア側インタフェースでノードリンクプロテクションを提供できるようになります。以下の出力では、LSP設定内に node-link-protectionキーワードが含まれています。ps@dalwhinnie> show configuration protocols mplslabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; node-link-protection;}interface ge-0/0/2.0;interface ge-0/0/3.0;

ps@dalwhinnie> show configuration protocols rsvpinterface ge-0/0/2.0 { link-protection;}interface ge-0/0/3.0 { link-protection;}

dalwhinnie-to-oban LSP上にある各トランジットルーターは、アーキテクチャでサポートされていれば、ノードプロテクションのためのネクストネクストホップバイパス LSPをシグナリングします。アーキテクチャがこのタイプの LSPをサポートできない場合は、ルーターはリンクプロテクションのためのネクストホップバイパスLSPをシグナリングしようとします。ネクストホップバイパス LSPもサポートできないアーキテクチャでは、パス上の各ルーターは LSP自体のみをサポートします。ルーターは、ノードリンクプロテクションされたLSPを保護するために、ネクストホップ LSPとネクストネクストホップ LSPの両方のシグナリングは行わないことに注意してください。ルーターがシグナリングするのは、アーキテクチャでのサポートに応じてそのいずれかです。

警告ノードリンクプロテクションに関するジュニパーネットワークス公式の多くの参考資料では、LSPパス上の各 Ingressルーターとトランジットルーターでネクストネクストホップ LSPとネクストホップ LSPの両方をシグナリングすることを推奨しています。ただし、本書で紹介するラボ結果には、これらの各ルーターがそのいずれかをシグナリングすることが示されています。すなわち、ネットワークアーキテクチャでネクストネクストホップバイパス LSPがサポートされている場合は、保護のためこのバイパス LSPをシグナリングし、サポートされていない場合のみ、ノードリンクプロテクションされた LSPを保護するためにネクストホップバイパス LSPをシグナリングしています。

以下の出力では、ノードリンクプロテクションが設定された dalwhinnie-to-oban LSPが有効になっています。

ps@dalwhinnie> show mpls lsp detailIngress LSP:1 sessions

10.200.86.3 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-oban ActivePath:(primary) Node/Link protection desired LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary State:Up Priorities:7 0


SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:3) 192.168.86.5 S 192.168.86.9 S 192.168.86.25 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.200.86.6(flag=0x29) 192.168.86.5(flag=9 Label=300416) 10.200.86.1(flag=0x21) 192.168.86.9(flag=1 Label=300400) 10.200.86.3(flag=0x20) 192.168.86.25(Label=3)

dalwhinnie-to-oban LSPは、glenlivetとblairを経由してobanで終端します（図1.3を参照）。この LSPでは、このパス上の各ルーター（Egressルーターを除く）が、ネクストネクストホップバイパスタイプまたはネクストホップバイパスタイプの保護 LSPをシグナリングするよう設定されています。以下に示すように、dalwhinnieは、保護のためにネクストネクストホップバイパスLSPをシグナリングします。

ps@dalwhinnie> show mpls lsp bypass ingressIngress LSP:2 sessionsTo From State Rt Style Labelin Labelout LSPname10.200.86.1 10.200.86.5 Up 0 1 SE - 300384 Bypass->192.168.86.5->192.168.86.9Total 1 displayed, Up 1, Down 0

ps@dalwhinnie> show mpls lsp bypass name Bypass->192.168.86.5->192.168.86.9 detailIngress LSP:2 sessions

10.200.86.1 From:10.200.86.5, LSPstate:Up, ActiveRoute:0 LSPname:Bypass->192.168.86.5->192.168.86.9 Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:300848 Resv style:1 SE, Label in:-, Label out:300848 Time left: -, Since:Wed Dec 8 05:54:30 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 1845 protocol 0 Type:Bypass LSP Number of data route tunnel through:1 Number of RSVP session tunnel through:0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.29 (ge-0/0/3.0) 4 pkts RESV rcvfrom:192.168.86.29 (ge-0/0/3.0) 4 pkts Explct route:192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.18 Record route:<self> 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.18Total 1 displayed, Up 1, Down 0


Transit LSP:3 sessionsTotal 0 displayed, Up 0, Down 0

dalwhinnieのネクストネクストホップLSPはBypass->192.168.86.5->192.168.86.9という名前で、lagavulin、macduff、および taliskerを経由してblairに送信されます。この LSPでは、glenlivetを完全にバイパスすることにより、glenlivetノード全体または glenlivetノードへのリンクが障害になった場合に保護を提供します。このルーターは、glenlivetへのリンクを保護するためのネクストホップタイプのバイパス LSPを別途確立しておらず、ネクストネクストホップ LSPによってネクストホップリンクとネクストホップノードの両方を保護しています。最後に、dalwhinnie-to-oban LSPと、この LSPの最後から 2番目のルーターである blairでの保護 LSPを見てみましょう。

ps@blair> show mpls lsp transit name dalwhinnie-to-oban detailTransit LSP:12 sessions


10.200.86.3 From:10.200.86.5, LSPstate:Up, ActiveRoute:1 LSPname: dalwhinnie-to-oban, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:3 Resv style:1 SE, Label in:303744, Label out:3 Time left:144, Since:Wed Dec 8 07:21:19 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 3 receiver 1843 protocol 0 Node/Link protection desired Type:Link protected LSP PATH rcvfrom:192.168.86.10 (ge-0/0/1.0) 41 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto:192.168.86.25 (ge-6/0/0.0) 43 pkts RESV rcvfrom:192.168.86.25 (ge-6/0/0.0) 41 pkts Explct route:192.168.86.25 Record route:192.168.86.6 192.168.86.10 <self> 10.200.86.3 (node-id) 192.168.86.25Total 1 displayed, Up 1, Down 0

ps@blair> show mpls lsp bypass ingressIngress LSP:2 sessionsTo From State Rt Style Labelin Labelout LSPname10.200.86.3 10.200.86.1 Up 0 1 SE - 301360 Bypass->192.168.86.2510.200.86.4 10.200.86.1 Up 0 1 SE - 301168 Bypass->192.168.86.17Total 2 displayed, Up 2, Down 0

ps@blair>

ps@blair> show mpls lsp bypass name Bypass->192.168.86.25 detailIngress LSP:2 sessions

10.200.86.3 From:10.200.86.1, LSPstate:Up, ActiveRoute:0 LSPname:Bypass->192.168.86.25 Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:301360 Resv style:1 SE, Label in:-, Label out:301360 Time left: -, Since:Wed Dec 8 05:21:15 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 49268 protocol 0 Type:Bypass LSP Number of data route tunnel through:2 Number of RSVP session tunnel through:0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.17 (ge-0/0/3.0) 185 pkts RESV rcvfrom:192.168.86.17 (ge-0/0/3.0) 185 pkts Explct route:192.168.86.17 192.168.86.33 192.168.86.38 Record route:<self> 192.168.86.17 192.168.86.33 192.168.86.38Total 1 displayed, Up 1, Down 0



ps@blair>

blairは、LSPが終端する obanまでのリンクを保護する必要があります。blairは、LSPがノード /リンクプロテクションを要求していることを認識していますが、最後から2番目のルーターであるため、ノードプロテクションを提供することはできません（LSPの Egressノードをバイパスしても意味がない）。そのため、blairは、ネクストネクストホップバイパス LSPの代わりに、LSPの Egressルーターへのリンクを保護するネクストホップ Bypass LSP->192.168.86.25をシグナリングします。ネクストホップバイパス LSPとネクストネクストホップバイパス LSPのパフォーマンス


にはいくつか違いがあります。前に説明したとおり、リンクプロテクションでは、ルーターのハードウェアによってリンク障害が検出されるため、PLRは素早くリンク切断を検出し、トラフィックをネクストホップ LSPに切り替えて保護することができます。一方、ノードプロテクションでは、隣接ルーターからのhelloメッセージの受信によって、そのルーターが存続しているかどうかが判断されます。そのため、PLRルーターがトラフィックをネクストネクストホップ LSPに切り替えるまでの時間は、隣接ルーターによる helloメッセージの送信頻度と、これらのメッセージが届いていないことをPLRルーターが検出するまでの時間に左右されます。ただし、いったん障害を検出すると、PLRは素早くトラフィックをネクストネクストホップバイパス LSPに切り替えることができます。ネクストホップLSPとネクストネクストホップ LSPにはこのような違いがあるため、ノードプロテクションを使用するときは、ネクストネクストホップ LSPのフェイルオーバー時間が、ネクストホップ LSPのフェイルオーバー時間より多少長くなると考えるのが妥当です。このフェイルオーバー時間の違いは、リンクノードプロテクションとリンクプロテクションのどちらを導入するかを決定するときに重要な要素になる場合があります。また、密接な関係のあるもう 1つの要素として、特に実際のルーターモデルで冗長ルーティングエンジンおよび冗長電源を使用できる場合に、ノード全体が障害になる可能性も考慮しなければなりません。ネクストホップバイパス LSPまたはネクストネクストホップバイパス LSPによるトラフィックの移動は、一時的な処置です。PLRはトラフィックをバイパス LSPに切り替えると、LSPの Ingressルーターへのシグナリングも行います。これにより、Ingressルーターは、その LSPを再度シグナリングしようとします。ネクストホップバイパス LSPと同様に、ネクストネクストホップバイパス LSPでも複数の LSPのトラフックを保護できるため、非常に拡張性に優れています。また、リンクプロテクションと同様に、ノードリンクプロテクション機能は、LSP上にある各トランジットルーターの RSVPインタフェースに設定する必要があります。

ファストリルート

ファストリルート（FRR）は、LSPフェイルオーバープロテクションを実装する、ジュニパーネットワークス独自の手法です。ファストリルートでは、LSP上の各ルーター（Egressルーターを除く）に、LSPの宛先に向かう、次の下流ノードおよび次の下流ノード自体へのリンクを回避する単一の代替パスをシグナリングするよう指示します。これらの代替パスはバイパス経路と呼ばれます。特定のファストリルート経路をサポートするほどネットワークトポロジーが充実していない場合、そのバイパス経路は確立されません。

ファストリルートで保護された LSPで障害が発生したときのバイパス経路は、LSPの宛先への最適パスでない可能性があります。Ingress LSRは、恒久的な処置として、新しいパスをmake before break方式でシグナリングし、障害のある古い LSPパスから新しい最適 LSPパスへとトラフィックをグレースフルに移行します。LSPの切断時に失われるトラフィック量を左右する要因には、PLRルーターがリンク切断を検出するまでの時間（ルーターは、GigEの障害よりSONETリンク障害を素早く検出でき、ノード障害よりリンク障害を素早く検出できるなど）、事前にシグナリングされたバイパス経路にトラフィックを移行するまでの時間などがあります。リンクプロテクションおよびノードリンクプロテクションとは異なり、LSPパス上で障害が発生した場合に、ラベルスタックにバイパスラベルが追加されません。PLRルーターは、単純にトップラベルをスワップし、パケットの送信インタフェースを変更するため、ラベルスタックの高さは変化しません。この他、FRRと、リンクプロテクションおよびノードリンクプロテクションの重要な違いとして、LSP上の各ルーターによって生成されるそれぞれの FRRバイパス経路を、特定の LSPのトラフィックを保護するためにのみ使用できることが挙げられます。N台のルーターで構成される 1つの LSPのパス内では、ファストリルートにより、その LSPを保護するために N-1通りのバイパス経路が生成される可能性があり（Egressノード以外のすべてのルーターがバイパス経路を生成可能）、それぞれのバイパス経路で保護できるのは、1つの特定の LSPのみです。この数に、特定ネットワークで必要になる LSPの合計数を掛ければ、ファストリルートの拡張性がそれほど高くないことは明白です。


ファストリルートでは、その拡張性の影響を低減するためにいくつかの措置が実装されます。その 1つは、ファストリルート経路が、できる限り少ないホップ数で元のLSPにマージしようとすることです。これにより、各バイパス経路を維持するために必要なルーターのオーバーヘッドが最小限に抑えられます。また、トポロジーの制約により、バイパス経路を素早く元の LSPパスにマージできない場合は、1つのバイパス経路を、同じ LSPの別のバイパス経路とマージすることができます。図 1.8に、このシナリオの例を示します。R1は、R1-R2リンクとR2自体をバイパスするバイパス経路をシグナリングしますが、そのバイパス経路をできる限り少ないホップ数で元のLSPパスにマージしようとしています。R2は、R2-R3リンクとR3自体をバイパスするバイパス経路をシグナリングし、同様にそのバイパス経路をできる限り少ないホップ数で元の LSPパスにマージしようとしています。この場合、どちらのバイパス経路も、できる限り少ないホップ数で元の LSPにマージするために、必要に応じてR9-R10および R10-R4リンクを共有できます。

R5

R4

R3

R2

R1

R6 R7

R8

R9 R10

LSP R1-R5で通常トラフィックのパス

R1の迂回パスR2の迂回パス

図 1.8 R1および R2でのファストリルート経路リンクの共有

LSPでファストリルートを有効にするには、ファストリルートを実装する特定のラベルスイッチドパス内で fast-rerouteキーワードを設定します。リンクプロテクションおよびノードリンクプロテクションとは異なり、ファストリルートの設定は、LSPの Ingressルーターでのみ必要になります。LSPが確立されると、Ingressルーターは、ファストリルートを希望していることをすべての下流ルーターに通知します。これに対して、下流ルーターは、バイパス経路を確立しようとします。何らかの理由で、ルーターから特定のバイパス経路を確立できない場合、そのルーターは引き続きLSPをサポートします。以下に示す dalwhinnieのコンフィグには、dalwhinnie-to-oban LSPにファストリルートが設定されていることが示されています。この LSPを保護するために必要な設定は、Ingressルーターで fast-rerouteキーワードを追加することのみです。

[edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban {


to 10.200.86.3; fast-reroute;}interface ge-0/0/2.0;interface ge-0/0/3.0;

[edit protocols mpls]ps@dalwhinnie#

注ファストリルートで保護された LSPにリンクカラー制限がある場合、FRRバイパス経路にもその制限が継承されます。リンクカラーについては、この章の「トラフィック制御」セクションで説明します。

IngressルーターからファストリルートRSVP LSPのステータス、LSPパス、およびバイパス経路のステータスを確認するには、該当する LSPに対して show rsvp

session detail操作コマンドを使用します。以下の出力例には、LSPがネットワーク上で経由するレコードルートの IPアドレスが示されています。ファストリルート経路が有効になっており、そのバイパス経路パスのレコードルートが示されています。

ps@dalwhinnie> show rsvp session lsp name dalwhinnie-to-oban detailIngress RSVP:1 sessions

10.200.86.3 From:10.200.86.5, LSPstate:Up, ActiveRoute:0 LSPname: dalwhinnie-to-oban, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:300432 Resv style:1 FF, Label in:-, Label out:300432 Time left: -, Since:Wed Jul 21 03:36:04 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 1773 protocol 0 FastReroute desired PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.5 (ge-0/0/2.0) 37 pkts RESV rcvfrom:192.168.86.5 (ge-0/0/2.0) 34 pkts Explct route:192.168.86.5 192.168.86.9 192.168.86.25 Record route:<self> 192.168.86.5 192.168.86.9 192.168.86.25 Detour is Up Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Detour adspec: sent MTU 1500 Path MTU: received 1500 Detour PATH sentto:192.168.86.29 (ge-0/0/3.0) 34 pkts Detour RESV rcvfrom:192.168.86.29 (ge-0/0/3.0) 32 pkts Detour Explct route:192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38 Detour Record route:<self> 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38 Detour Label out:300400Total 1 displayed, Up 1, Down 0

dalwhinnie-to-oban LSPは、glenlivetと blairを経由して obanで終端します。FRRバイパス経路が有効になると、lagavulin、macduff、talisker、およびtormoreを経由して obanで終端します（前の図 1.3を参照）。

LSPのレコードルート上にあるどのルーターも、そのルーターから始まるバイパス経路 LSPのステータスとパスを表示できます。以下の出力では、トランジットルーターglenlivetが、LSPの宛先である obanへのバイパス経路をシグナリングしています。

ps@glenlivet> show rsvp session transit detail lsp name dalwhinnie-to-obanTransit RSVP:1 sessions


10.200.86.3 From:10.200.86.5, LSPstate:Up, ActiveRoute:1 LSPname: dalwhinnie-to-oban, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:300416 Resv style:1 FF, Label in:300432, Label out:300416 Time left:130, Since:Wed Jul 21 03:34:58 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 1773 protocol 0 FastReroute desired PATH rcvfrom:192.168.86.6 (ge-0/0/2.0) 44 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto:192.168.86.9 (ge-0/0/1.0) 42 pkts RESV rcvfrom:192.168.86.9 (ge-0/0/1.0) 40 pkts Explct route:192.168.86.9 192.168.86.25 Record route:192.168.86.6 <self> 192.168.86.9 192.168.86.25 Detour is Up Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Detour adspec: received MTU 1500 sent MTU 1500 Path MTU: received 1500 Detour PATH sentto:192.168.86.45 (ge-0/0/3.0) 40 pkts Detour RESV rcvfrom:192.168.86.45 (ge-0/0/3.0) 37 pkts Detour Explct route:192.168.86.45 192.168.86.42 192.168.86.13 192.168.86.33 192.168.86.38 Detour Record route:192.168.86.6 <self> 192.168.86.45 192.168.86.42 192.168.86.13 192.168.86.33 192.168.86.38 Detour Label out:300192Total 1 displayed, Up 1, Down 0

ps@glenlivet>

LSP dalwhinnie-to-obanを保護する、glenlivetからのバイパス経路は、mortlach、macduff、talisker、および tormoreを経由して obanで終端します。より小規模なネットワークでは、ファストリルートは、設定が容易で信頼性の高いフェイルオーバー手段になりますが、ネットワークの成長に伴って拡張性の問題が生じる可能性があります。FRRは、それほど拡張性が高くなく、またジュニパーネットワークス独自の手法であるため、今後もRSVPドメインが小規模なままで、ジュニパーネットワークスのルーターのみで構成されることが十分確実な場合を除き、このフェイルオーバー手法を使用しないことをお奨めします。

セカンダリLSP

LSPを障害から保護するためのもう 1つの方法が、セカンダリLSPです。1つのLSPに対して 1つ以上のセカンダリパスを設定することができます。セカンダリLSPを設定すると、結果的に、最初に使用されるプライマリパスと、プライマリパスで障害が発生した場合に使用できる 1つ以上のセカンダリパスの、2つ以上の LSPパスが確立されます。プライマリパスと同様に、セカンダリパスは、LSPの Egressルーターで終端します。Junosルーターは、プライマリパスが確立されるまで待ってから、トラフィック制御データベース（TED）で適切なセカンダリパスを検索します。完全に異なるパスが存在しない場合、セカンダリLSPにプライマリLSPと共通のリンクが含まれることがあります。以下に示す例では、dalwhinnie-to-oban LSPにプライマリパスとセカンダリパスが設定されています。standbyキーワードは、フェイルオーバーに備えて常時有効な状態にするセカンダリパスをシグナリングするようLSPに指示します。セカンダリパスに standbyを設定しない場合、LSPはプライマリパスが障害になってからセカンダリパスを確立するため、フェイルオーバー時間が大幅に長くなります。以下の dalwhinnieの設定では、dalwhinnie-to-oban LSPが、セカンダリLSPを即座にシグナリングするよう設定されています。


[edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; primary via-blair; secondary via-tormore { standby; }}path via-tormore { 10.200.86.9 loose;}path via-blair { 192.168.86.5 strict; 192.168.86.9 strict; 192.168.86.25 strict;}interface ge-0/0/2.0;interface ge-0/0/3.0;

この設定により、glenlivetとblairを経由して obanに到達するストリクトプライマリパスと、tormoreを経由する必要のある、事前にシグナリングされたルーズセカンダリパスを持つ、LSPが生成されます。label-switched-pathのパスでのストリクトホップとルーズホップの使用はオプションです。ただし、ストリクトホップとルーズホップを指定することにより、ネットワークエンジニアは、トラフィック制御のためのオプションを利用できるようになります（トラフィック制御の概念、およびそのためのツールについては、この章で後に説明）。

注パス上のホップは、looseまたは strictとして定義できます。LSPパスは、設定されているすべてのホップを設定されている順序で経由する必要があります。LSPパス上のどのルーターでも、ネクストストリクトホップは、そのルーターに直接接続されている必要があります。また、ルーズホップは、そのルーターから到達可能な、ネットワーク上の任意のホップにできます。

以下に示す dalwhinnieの操作コマンド出力には、dalwhinnie-to-oban LSPについて、プライマリパスとセカンダリ（スタンバイ）パスのレコードルートオブジェクト（RRO）などが示されています。RROは、LSP上にある各ノードの受信インタフェースの IPアドレスが順番にリストされたものです。

ps@dalwhinnie> show mpls lsp name dalwhinnie-to-oban detailIngress LSP:2 sessions

10.200.86.3 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-oban ActivePath: via-blair (primary) LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:3) 192.168.86.5 S 192.168.86.9 S 192.168.86.25 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.5 192.168.86.9 192.168.86.25 Standby via-tormore State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:5) 192.168.86.29 S 192.168.86.1 S 192.168.86.13 S 192.168.86.33 S 192.168.86.38 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38Total 1 displayed, Up 1, Down 0




dalwhinnie-to-oban LSPのプライマリパスは via-blairで、glenlivet、blair、および obanルーターの順に到達します。スタンバイパスは via-tormoreで、現在有効な状態です。このパスは lagavulin、macduff、talisker、および tormoreを経由してobanで終端します。図 1.9に、これらのパスを示します。

tormorelo0 10.200.86.9




blair lo0 10.200.86.1


oban lo0 10.200.86.3

macduff lo0 10.200.86.8

.1

.6

.5

.2

.34


.30

.29

.10 .9

.46

.45

.14

.13

.42

.41

.50 .18

.17

.26 .25

.38

.37

.33

.22

.49

.21

X




図 1.9 LSP dalwhinnie-to-obanのプライマリパスとセカンダリパス

警告リンクプロテクション、ノードリンクプロテクション、またはセカンダリLSPを使用してフェイルオーバーシナリオを適切にプランニングしても、ネットワークリンクまたはルーターの障害が複数箇所で発生した場合は、保護できないことがあります。

LSPパスを primaryとして指定すると、ネットワークでプライマリパスを使用できるときは、必ずそのパスを使用しなければならなくなります。すなわち、プライマリパスは切り戻しされます。LSPのプライマリパスがダウンしてセカンダリパスにトラフィックが切り替わり、その後プライマリパスが再び使用可能になった場合、トラフィックはプライマリパスに戻されます。この切り戻し動作を回避するには、プライマリパスとセカンダリパスを使用する代わりに、2つ以上のセカンダリパスを設定してスタンバイにします（プライマリは設定しない）。LSPは、その LSPで設定されている順にセカンダリパスをシグナリングします。アクティブパスが障害になった場合、トラフィックはもう一方のセカンダリパスにフェイルオーバーされます。ただし、以前のアクティブパスが復帰しても、トラフィックを引き継いだセカンダリパスが障害になるまで、トラフィックは引き続きそのセカンダリパスで転送されます。両方のセカンダリLSPに standbyキーワードを使用することにより、特定時点でどちらのパスがアクティブかに関わらず、LSPは両方のパスをシグナリングし、両方のパスを有効な状態に維持しようとします。以下の dalwhinnieの設定では、dalwhinnie-to-tormore LSPに 2つのセカンダリパスが設定されています。[edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; primary via-blair; secondary via-tormore {


standby; }}label-switched-path dalwhinnie-to-tormore { to 10.200.86.9; secondary via-talisker { standby; } secondary alt-path { standby; }}path via-tormore { 10.200.86.9 loose;}path via-talisker { 10.200.86.4 loose;}path via-blair { 192.168.86.5 strict; 192.168.86.9 strict; 192.168.86.25 strict;}path alt-path;interface ge-0/0/2.0;interface ge-0/0/3.0;

この例のパス alt-pathにはホップが定義されていません。そのため、LSPは単純に、ネットワークを通過するベストパスをシグナリングしようとします。一方、via-taliskerパスには、ルーズホップが設定されています。dalwhinnie-to-tormore LSPを詳しく調べると、両方のセカンダリLSPパスが有効になっています。

[edit protocols mpls]ps@dalwhinnie# run show mpls lsp name dalwhinnie-to-tormore detailIngress LSP:2 sessions

10.200.86.9 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-tormore ActivePath: via-talisker (secondary) LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Standby via-talisker State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:4) 192.168.86.5 S 192.168.86.9 S 192.168.86.17 S 192.168.86.33 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.5 192.168.86.9 192.168.86.17 192.168.86.33 Standby alt-path State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:4) 192.168.86.5 S 192.168.86.9 S 192.168.86.17 S 192.168.86.33 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.5 192.168.86.9 192.168.86.17 192.168.86.33Total 1 displayed, Up 1, Down 0




この出力を注意深く分析すると、この段階での問題点として、両方のセカンダリパスがネットワーク上で同じルートを取っていることがわかります。このような結果は、LSPを保護するパスに、それぞれのパスがネットワーク上で固有のルートを取るために十分なストリクトホップまたはルーズホップが含まれていない場合に生じる可能性があります。セカンダリパスを使用してフェイルオーバーを提供する場合は、ネットワークトポロジー、IGPリンクコスト、およびパスのストリクトホップとルーズホップがパスの多様性に影響する可能性があることを理解しておくことが重要です。最後に、定義されている単一のパス名が複数の LSPに適用されている場合、その1つのパス名で複数のレコードルートを保持できることを理解しておくと便利です。以下の設定では、alt-pathが2つのLSPのセカンダリパスとして指定されています。ps@dalwhinnie> show configuration protocols mplslabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; primary via-blair; secondary alt-path { standby; }}label-switched-path dalwhinnie-to-tormore { to 10.200.86.9; secondary via-talisker { standby; } secondary alt-path { standby; }}...<snipped for brevity> ... path alt-path;

dalwhinnie-to-oban LSPと dalwhinnie-to-tormore LSPの両方に、それぞれのセカンダリパスとして alt-pathが示されています。以下の出力には、保護対象として設定されている LSPに応じて、パス alt-pathがネットワーク上で 2つの異なるパスを取ることが示されています。

ps@dalwhinnie> show mpls lsp detailIngress LSP:2 sessions

10.200.86.3 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-oban ActivePath: via-blair (primary) LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up ... ...<snipped for brevity> ... ... Standby alt-path State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:5) 192.168.86.29 S 192.168.86.1 S 192.168.86.13 S 192.168.86.33 S 192.168.86.38 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38

10.200.86.9 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-tormore ActivePath: via-talisker (secondary) dalwhinnie-to-oban LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4


*Standby via-talisker State:Up ... ...<snipped for brevity> ... ... Standby alt-path State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:4) 192.168.86.5 S 192.168.86.9 S 192.168.86.17 S 192.168.86.33 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.5 192.168.86.9 192.168.86.17 192.168.86.33

alt-pathは、dalwhinnie-to-oban LSPを保護するときは、lagavulin-macduff-talisker-tormore-obanというパスを取り、dalwhinnie-to-tormore保護するときは glenlivet-blair-talisker-tormoreというパスを取ります。フェイルオーバーシナリオでは、通常、セカンダリLSPは最も低速な代替パスであり、必ずしも信頼できるとは限りません。これは、リンク切断またはノード障害の通知が、信頼性の低い RESV TEARメッセージによって Ingressルーターまで上流へ移動する必要があるためです。また、Ingressルーターはこのメッセージを受信した場合のみ、トラフィックをアクティブパスからスタンバイパスへと移行します。リンク切断によって他のリンクのトラフィックが飽和した場合、RESV TEARメッセージは、Ingressルーターに到達する前に破棄される可能性があります。この時点では、Ingressルーターは、IGP情報が再び集まるまで待って初めてリンクまたはノードの障害を認識することになります（これには何秒もかかる可能性がある）。それまでの間、LSP上のトラフィックはブラックホール化されます。セカンダリLSPによるフェイルオーバー手法と、ネットワーク障害に最も近いルーター（障害を検出する最初のルーター）によってトラフィックが即座にリダイレクトされるリンクプロテクション、ノードリンクプロテクション、およびファストリルートを比較すると、なぜセカンダリLSPではトラフィックの切り替えに時間がかかるかがわかります。

IGPのループフリー代替パス

ここでは、もう 1つのフェイルオーバーオプションである IGPのループフリー代替パス（LFAパス）について簡単に説明します。OSPFおよび ISISはリンクステート型プロトコルであるため、ネットワークトポロジーに基づいてルーティングテーブルを構築し、これによってOSPF/OSPF3領域全体または ISISレベルを把握します。Junos 9.5以降では ISISを、また Junos 10.0以降ではOSPFを、特定の送信インタフェースにリンクプロテクションまたはノードリンクプロテクションを提供するよう設定できます。この場合、最初の SPFの実行後、各ルーターの IGP（OSPFまたは ISIS）により、トポロジーから送信リンク（リンクプロテクションの場合）またはネクストホップノード（ノードリンクプロテクションの場合）が削除され、ダイクストラ法で計算された代替パスが返されます。これらの代替パスは、JunosによりPFE（Packet-forwarding Engine）にあらかじめインストールされるため、PFEは、更新された FIB（Forwarding Information Base）をルーティングエンジンから受信する前に、障害になったリンクまたはノードをバイパスしてトラフィックを転送し始めることができます。このように、LFA IGPパスにより、設定されたインタフェースから宛先へと向かう各ルートが保護されます。MPLSプロトコルとして LDPを実行しているネットワークでは、LFAにより、設定されたインタフェースから宛先へと向かうLDP LSPに高速フェイルオーバープロテクションが提供されます。この機能により、MPLSサービス（L2VPN、L3VPN、および VPLS）および単純な高速フェイルオーバーを必要とし、RSVPで提供されるトラフィック制御（TE）機能を必要としないネットワークにとって、LDPがより魅力的なオプションになる場合があります。TEについては、次のセクションで説明します。以下の設定には、OSPFおよび OSPF3での LFAによるリンクプロテクションまたはノードリンクプロテクションの設定方法が示されています。 [edit protocols]ps@dalwhinnie# show ospf


area 0.0.0.0 { interface ge-0/0/0.0 { link-protection; } interface ge-0/0/1.0 { node-link-protection; }}

[edit protocols]ps@dalwhinnie# show ospf3area 0.0.0.0 { interface ge-0/0/0.0 { link-protection; } interface ge-0/0/1.0 { node-link-protection; }}

以下は、ISIS設定における LFAを示しています。[edit protocols]ps@dalwhinnie# show isisinterface fe-0/0/3.0 { link-protection; level 1 disable;}interface fe-0/0/4.0 { node-link-protection; level 1 disable;}

インタフェースでは、リンクプロテクションまたはノードリンクプロテクションのいずれかを提供できますが、両方を提供することはできないことに注意してください。デフォルトでは、マスターインスタンスまたはルーティングインスタンスのすべてのOSPFまたは ISISインタフェースに、リンクプロテクションまたはノードリンクプロテクションされたインタフェースのバックアップインタフェースとして機能します。インタフェースでのバックアップ機能の提供を無効にするには、該当するインタフェースに no-eligible-backupキーフレーズを含めます。以下の例では、インタフェース ge-1/0/0.0が、LFAで保護されたインタフェースに代替送信インタフェースを提供しないよう除外されています。[edit protocols]tim@srx100# show ospf area 0 interface ge-1/0/0.0no-eligible-backup;

ヒントリンクプロテクションを設定するときは、IGPによって特定ルートのすべてのネクストホップがルーティングテーブルにインストールされるようにするために、per-packet load-balancing policyも設定する必要があります。以下は、その設定例になります。このポリシーは、階層の [edit routing-options forwarding-table]レベルで適用します。

[edit]ps@dalwhinnie# show policy-optionspolicy-statement basic-load-balancing-policy { then { load-balance per-packet; }}

[edit]


ps@dalwhinnie# show routing-options ... ... router-id 10.200.86.5;autonomous-system 7176;forwarding-table { export basic-load-balancing-policy;}... ...

注意トポロジーによっては、LFAに制限が課されることがあります。これについては、本書の範囲外です。

トラフィック制御トラフィック制御（TE）は、ネットワークバックボーンを通過するトラフィックを調整することにより、ネットワークのリソースとパフォーマンスを最適化する手段です。トラフィック制御では（通常）、特定の条件に基づいてトラフックをクラス分類し、そのトラフィックがバックボーンを通過するときにどのネットワークパスを使用できるかを指定します。これにより、組織は、時間的な制約のある重要なトラフィックが最適なルートを取り、また電子メールなど即時性を必要としない低優先度のトラフィックが別のルート（あまり直接的でないルートなど）を取るようにすることができます。このタイプのセグメント化を適用することにより、特定のルーターやリンクが十分に使用されなかったり、過剰に使用されるような状況を防ぐことができます。また、MPLSで提供されるいくつかのトラフィック制御ツールを利用することにより、ネットワーク設計者やエンジニアは、ネットワークリソースを最大限に活用することができます。

LSPメトリックIGPインタフェースにメトリックを割り当てることができるように、RSVP LSPにも手動でスタティックメトリックを割り当てることができます。いったん設定された LSPコストは、LSPのパス上にあるインタフェースに設定された IGPメトリックに関わらず、固定されて変更できません。LSPでリンクプロテクションなどのフェイルオーバー手法が有効になり、再度シグナリングが行われても、LSPメトリックは、設定された値のまま固定されることを覚えておいてください。これにより、特定の宛先へのLSPが複数存在する場合に、すべてのトラフィックを強制的に 1つの LSPで転送したり、またはトラフィックを複数の LSPに負荷分散させることが可能になります。特定の LSPの階層で LSPのメトリックを設定するには、以下のようにします。[edit protocols mpls]ps@dalwhinnie# show label-switched-path dalwhinnie-to-obanto 10.200.86.3;metric 20;link-protection;

リンクカラーネットワークエンジニアおよび設計者は、リンクカラーを使用することで、特定のネットワークリンクを、32個のいずれかの値（0～ 31）でマーキングすることができます。これらのリンクにマーキングした後、特定の LSPが特定リンクのみを経由するように設定したり、他のリンクを経由しないように設定したりできます。Junosでは、このタイプのリンクマーキングを管理グループによって行えます。管理グループは、ユーザー定義のグループ名を数値 0～ 31に対応付けます。このグループ名は、前後関係がほとんどわからない数値に代わって意味を与えるユーザーフレンドリなニーモニックです。

図 1.10を見ていきましょう。この図には、goldのカラーが割り当てられた（名前が付けられた）dalwhinnie-glenlivet、glenlivet-blair、および blair-obanの各リンクを含むネットワークが示されています。






blair lo0 10.200.86.1


oban

lo0 10.200.86.3

macduff lo0 10.200.86.8




.1

.6

.5

.2

.34


ge-0/0/2

ge-0/0/3

.30

.29

ge-0/0/1 .10 .9

.46

.45

ge-0/0/3

ge-0/0/2

ge-0/0/1 .14

fe-0/0/1 .13

fe-2/0/1

ge-0/0/3 .42

.41

ge-0/0/2 .50 ge-0/0/3

.18

fe-2/0/0 .17

ge-6/0/0 .26

.25 ge-0/0/2

ge-0/0/3

.38

.37

fe-2/0/1

.33 ge-0/0/2

e1-1/0/0

.22

fe-0/0/1

fe-2/0/0 .49

.21

goldリンク

図 1.10 リンクカラー

以下の設定例には、gold管理グループと、設定されている 2つの LSPが示されています。dalwhinnieのインタフェース ge-0/0/2.0は、gold管理グループに設定されています。また、ラベルスイッチドパス dalwhinnie-to-oban-lo-priorityは、goldリンクを回避するように設定されています。

goldのリンクカラーは、[edit protocols mpls]階層で glenlivet（ge-0/0/1.0）および blair（ge-6/0/0.0）の特定インタフェースに対しても設定されています（出力には示されていない）。これにより、LSPに対して以下に示す 2つの効果がもたらされます。

� LSP dalwhinnie-to-obanは、obanに到達するために、ネットワーク上でgoldリンクを使用する必要があります。ただし、このリンクを保護するバイパスLSPは、そのパスに goldリンクを含む必要はありません。これは、1つのバイパス LSPにより、多くの制約を持つ可能性のある複数の LSPを保護できるためです。一方、FRRで保護された LSPのファストリルート経路は、プライマリLSPの制約を継承するため、この例では goldリンクを取る必要があります。

� LSP dalwhinnie-to-oban-lo-priorityは、goldカラーのリンクを取ることが明示的に禁止されます。ただし、この LSPにリンクプロテクションが設定されている場合は、この LSPを保護するバイパス LSPは、明示的に禁止されていなければ gold リンクを使用できます。プライマリパスとセカンダリパス、およびバイパス LSPにも、管理グループによる制限を設定できます。この LSPにリンクプロテクションバイパス LSPではなくファストリルートが設定されている場合は、FRRバイパス経路は goldリンクを使用することが禁止されます

注 LSPは単方向のため、ネットワークエンジニアが obanから dalwhinnieに向かう反対方向にも同等の goldパスを必要とする場合は、obanからdalwhinnieへの LSPをプロビジョニングし、obanのmplsインタフェース ge-0/0/2.0、blairの ge-0/0/1.0、および glenlivetの ge-0/0/1.0を gold管理グループに追加する必要があります。

goldリンクカラーが設定された、dalwhinnieのMPLS設定は以下のようになりま


す。ps@dalwhinnie> show configuration protocols mplsadmin-groups { gold 1;}label-switched-path dalwhinnie-to-oban { to 10.200.86.3; admin-group include-any gold; link-protection;}label-switched-path dalwhinnie-to-oban-lo-priority { to 10.200.86.3; admin-group exclude gold; link-protection;}path via-tormore;interface ge-0/0/2.0 { admin-group gold;}interface ge-0/0/3.0;

ps@dalwhinnie> show configuration protocols rsvpinterface ge-0/0/2.0 { link-protection;}interface ge-0/0/3.0 { link-protection;}

ge-0/0/2.0インタフェースが gold管理グループに追加されています。dalwhinnie-to-oban LSPは、 include-any goldが設定されているため goldリンクを使用する必要があります。ge-0/0/2.0はdalwhinnieの唯一の goldリンクであるため、このルーターからdalwhinnie-to-oban LSPで転送されるトラフィックは、このインタフェースから送信する必要があります。dalwhinnieからobanまで完全な goldリンクのパスがない場合、dalwhinnie-to-oban LSPは有効にならないことに注意してください。以下の設定には、管理グループによって制限が適用されたプライマリおよびセカンダリLSPパスが示されています。[edit protocols mpls]ps@dalwhinnie# showadmin-groups { gold 1;}label-switched-path dalwhinnie-to-oban { to 10.200.86.3; primary via-tormore { admin-group include-all gold; } secondary alt-path { admin-group include-all gold; }}interface ge-0/0/2.0 { admin-group gold;}

また、バイパスLSPには、goldリンクを含むという要件が設定されています。これは、[protocols rsvp]階層で設定します。[edit protocols rsvp]ps@dalwhinnie# show


interface ge-0/0/2.0 { link-protection { admin-group include-any gold; }}

管理グループによる制限を設定するときのオプションには、exclude、include-all、include-anyがあります。 [edit protocols mpls label-switched-path dalwhinnie-to-oban]ps@dalwhinnie# set primary via-tormore admin-group ?Possible completions: ... + exclude Groups, all of which must be absent+ include-all Groups, all of which must be present+ include-any Groups, one or more of which must be present

注 LSPに管理グループによる制約が適用されていない場合、その LSPは、どのルーターインタフェースにどのリンクカラーが設定されているかに関わらず、ネットワーク上で可能な任意のパスを考慮することができます。

リンクカラーは、優先度の高いトラフィック用に特定のリンクを予約したり、低優先度のトラフィックが特定のリンクを使用しないように排除する効果的な方法です。リンクには、必要な場合のみカラーを追加してください。ネットワーク上の特定リンクのみを使用するようにする LSP、または特定リンクを使用しないようにする LSPがある場合、リンクカラーは最適なソリューションです。リンクカラーが必要ない場合にリンクカラーを追加すると、ネットワークが制約されるのみで、設定およびプランニングのオーバーヘッドが増えるだけでなく、LSPの確立を妨げる可能性もあります。管理グループ名および数値には論理的な意味しかありませんが、TED（Traffic-engineering Database）において、MPLSドメイン内のすべてのルーターに渡って表示を一貫させるために、ベストプラクティスとして、各ルーターで同じ管理グループ名、スペル、および数値を使用することをお奨めします。TEDは、ドメイン内の、RSVPが有効になっている各ルーター（NodeID）に関する情報が保持される共通のデータベースです。TEDに各エントリーについて保持される情報には、実行されているTEプロトコル（ISIS/OSPF）や、インタフェースの宛先（隣接ルーターのlo0アドレス）、静的帯域幅と予約可能帯域幅、メトリック、設定されている管理グループ（カラー）などの RSVPインタフェース情報が含まれます。各ルーターは、リンクカラーなどの管理制約のあるパスなど、ネットワーク上で使用可能なパスを見つけるために TEDを使用します。ドメイン内のすべての RSVPルーターに対してTEDのビューが同一であることが重要です。例えば、glenlivetの TEDには、dalwhinnieの ge-0/0/2.0インタフェースに設定されているリンクカラーが示されます。

ps@glenlivet> show ted database extensive | find 10.200.86.5NodeID:10.200.86.5 Type:Rtr, Age:877 secs, LinkIn:2, LinkOut:2 Protocol:OSPF(0.0.0.0) To:10.200.86.6, Local:192.168.86.6, Remote:192.168.86.5 Local interface index:71, Remote interface index:0 Color:0x2 gold Metric:1 Static BW:1000Mbps Reservable BW:1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type:Packet


Encoding type:Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps To:10.200.86.7, Local:192.168.86.30, Remote:192.168.86.29 Local interface index:72, Remote interface index:0 Color:0 <none> Metric:1 Static BW:1000Mbps Reservable BW:1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type:Packet Encoding type:Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps ... ...

また、glenlivetの TEDには、NodeID:10.200.86.5（dalwhinnieのルーターID）に関する情報が示されています。この情報では、dalwhinnieの ge-2/0/0.0インタフェースを To:10.200.86.6（glenlivetのルーター ID）として認識し、さらにこのインタフェースが Color:0x2 gold特性を持つものとして認識しています（0x2は、10進数値 2に相当する 16進数表記）。glenlivetの TEDに表示される

dalwhinnieのトラフィック制御情報から、管理グループ名と数値の一貫性を保つことの重要性がわかります。glenlivetまたはこの RSVPドメインに含まれるその他のルーターで、異なる管理グループ名が異なる数値に割り当てられている状況を想像してみてください。TEDを見てそのデータを理解することはほぼ不可能でしょう。

注ここに示した例では、gold管理グループに値 1が割り当てられていますが、1は、0～ 31までの 32個の数値のうち使用可能な 2番目の値です。

Strictおよび Loose LSPホップ

この章の「フェイルオーバー」セクションでセカンダリLSPについて説明したときに、LSPパスに定義されたストリクトホップとルーズホップの使用について触れました。エンジニアおよびプランナーは、特定のMPLSパスのプライマリおよびセカンダリパスを制御する手段として、プライマリ /セカンダリLSPパスに一連のストリクト /ループホップを定義することができます。

RSVP LSPにリンクプロテクションが設定されている場合、特定の RSVPリンクを保護するバイパス LSPにも、ストリクトホップまたはルーズホップを定義できます。以下に示す出力では、LSP dalwhinnie-to-obanにプライマリパスが設定され、ストリクトホップが定義されています。また、dalwhinnieの RSVPインタフェースを保護するRSVPバイパス LSPには、以下に示すようにストリクトホップが定義されています。ps@dalwhinnie> show configuration protocols mplslabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; link-protection; primary via-blair;}path via-blair { 192.168.86.5 strict; 192.168.86.9 strict; 192.168.86.25 strict;}


interface ge-0/0/2.0;interface ge-0/0/3.0;

ps@dalwhinnie> show configuration protocols rsvpinterface ge-0/0/2.0 { link-protection { path { 192.168.86.29 strict; 192.168.86.1 strict; 192.168.86.41 strict; 192.168.86.46 strict; } }}interface ge-0/0/3.0 { link-protection { path { 192.168.86.5 strict; 192.168.86.45 strict; 192.168.86.42 strict; 192.168.86.2 strict; } }}

前に示したように、LSPのプライマリパスは path階層で定義します。ただし、ネクストホップバイパスLSPの定義方法には注意が必要です。各RSVPインタフェースを保護するネクストホップバイパス LSPは、 [protocols rsvp]階層のそれぞれのインタフェースの下で定義します。この設定により、プライマリパスおよびインタフェース ge-0/0/2.0のバイパスLSPの両方に対して特定のパスが生成されます。

ps@dalwhinnie> show mpls lsp name dalwhinnie-to-oban detail ingressIngress LSP:1 sessions

10.200.86.3 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-oban ActivePath: via-blair (primary) Link protection desired LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:3) 192.168.86.5 S 192.168.86.9 S 192.168.86.25 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.200.86.6(flag=0x21) 192.168.86.5(flag=1 Label=300816) 10.200.86.1(flag=0x20) 192.168.86.9(Label=300816) 10.200.86.3(flag=0x20) 192.168.86.25(Label=3)Total 1 displayed, Up 1, Down 0ps@dalwhinnie>

ps@dalwhinnie> show mpls lsp bypass detail ingressIngress LSP:2 sessions

10.200.86.6 From:10.200.86.5, LSPstate:Up, ActiveRoute:0 LSPname:Bypass->192.168.86.5 Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:300608 Resv style:1 SE, Label in:-, Label out:300608 Time left: -, Since:Thu Jul 22 01:02:54 2010


Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 1787 protocol 0 Type:Bypass LSP Number of data route tunnel through:1 Number of RSVP session tunnel through:0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.29 (ge-0/0/3.0) 58 pkts RESV rcvfrom:192.168.86.29 (ge-0/0/3.0) 58 pkts Explct route:192.168.86.29 192.168.86.1 192.168.86.41 192.168.86.46 Record route:<self> 192.168.86.29 192.168.86.1 192.168.86.41 192.168.86.46Total 1 displayed, Up 1, Down 0

期待どおり、各LSPのRROは、設定に指定されたストリクトホップと一致しています。

この機能により、RSVPドメイン内の各ルーターは、そのルーターの RSVPインタフェースを保護するバイパスLSPに対して独自のパスを指定できます。glenlivetルーターでは、glenlivet-blairリンクを保護するバイパス LSPが以下のように設定されています。ps@glenlivet> show configuration protocols rsvpinterface ge-0/0/1.0 { link-protection { path { 192.168.86.45 strict; 192.168.86.21 strict; 192.168.86.18 strict; } }} ... ... ...

ps@glenlivet> show mpls lsp bypass ingress detailIngress LSP:1 sessions

10.200.86.1 From:10.200.86.6, LSPstate:Up, ActiveRoute:0 LSPname:Bypass->192.168.86.9 Suggested label received:-, Suggested label sent:- ... ... ... Explct route:192.168.86.45 192.168.86.21 192.168.86.18 Record route:<self> 192.168.86.45 192.168.86.21 192.168.86.18Total 1 displayed, Up 1, Down 0

ここでは、ネットワークエンジニアがプライマリパスまたはバイパス LSPのホップを設定するときにどのような制御が可能かを示すために、意図的に Bypass LSP->192.168.86.9が最適ルートより多少長いルートを取るよう設定されています。図1.11に、dalwhinnie-to-oban LSPのプライマリパスと、このパス上の各リンクを保護するバイパス LSPに対して設定されているストリクトホップパスを示します。バイパス LSPに対してストリクト /ルーズホップを設定することにより、ネットワークエンジニアおよびキャパシティプランナーは、大幅な制御および予測が可能になります。






blair lo0 10.200.86.1


oban lo0 10.200.86.3

macduff lo0 10.200.86.8

All interface IP addresses are in /30 subnets in the 192.168.86/24 network

.1

.6

.5

.2

.34


.30

.29

.10 .9

.46

.45

.14

.13

.42

.41

.50

.18

.17

.26 .25

.38

.37

.33

.22

.49

.21

dalwhinnie-to-oban LSPのパス迂回パス->192.168.86.5 LSP迂回パス->192.168.86.9 LSP迂回パス->192.168.86.25 LSP

図 1.11 ストリクトホップによる LSPフェイルオーバーのトラフィック制御

ルートテーブルとLSPの統合

これまでに説明してきたトラフィック制御手法を使用することにより、ネットワークエンジニアは、ネットワーク上で LSPが取るパスを制御したり、そのパスに影響を与えることができます。ここで、inet.3ルーティングテーブルについて紹介し、どのトラフィックが LSPを使用できるかを制御する方法と、LSPがどのように inet.0および inet.3ルーティングテーブルに関連付けられるかを説明しましょう。

inet.3テーブルには、デバイスの RSVPおよび LDPラベルスイッチドパスのエンドポイントが保持されます。その唯一の目的は、BGPに、そのネクストホップを解決するためのもう 1つの場所を提供することです（inet.0に加えて）。これにより、デフォルトでは、BGPが inet.3テーブルを使用する唯一のプロトコルとなり、BGPトラフィックが、LSPを使用する唯一のトラフィックタイプとなります。この章の以降のセクションでは、デフォルト動作を出発点として、この動作の変更方法を説明していきます。

BGPネクストホップのインストールこの時点では、dalwhinnieおよび obanルーター間で dalwhinnie-to-oban LSPが確立され、実行されています（前の図 1.11を参照）。dalwhinnieの inet.3テーブルには、ネットワーク上の、それぞれ LDP LSPまたは RSVP LSP、あるいはその両方の終端となる他の 8つの lo0アドレスが保持されています。

ps@dalwhinnie> show route table inet.3 | match metric10.200.86.1/32 *[LDP/9] 00:03:40, metric 110.200.86.2/32 *[LDP/9] 00:03:40, metric 110.200.86.3/32 *[RSVP/7] 00:03:40, metric 3 [LDP/9] 00:03:40, metric 110.200.86.4/32 *[LDP/9] 00:03:40, metric 110.200.86.6/32 *[LDP/9] 00:03:39, metric 110.200.86.7/32 *[LDP/9] 00:03:39, metric 110.200.86.8/32 *[LDP/9] 00:03:40, metric 110.200.86.9/32 *[LDP/9] 00:03:40, metric 1


予測どおり、dalwhinnieの inet.3テーブルには、他のルーターの各 lo0が表示されています。dalwhinnie-to-oban RSVP LSPが確立されているため、obanの lo0（10.200.86.3）には RSVPエントリーが保持されています。また、LDP LSPを形成している各ルーターの各コアインタフェースでは LDPが有効になっているため、各アドレスには LDPエントリーが保持されています。以下の出力に示す、LSPを使用した BGPトラフィックの最初の例では、oban（10.200.86.3）は dalwhinnieとの間で iBGPを実行し、iBGPネクストホップが 10.200.86.3の 172.16.0/24をアドバタイズしています。10.200.86.3はdalwhinnieの inet.3テーブルに保持されているため、dalwhinnieから 172.16.0/24へ向かうトラフィックは、この LSPを使用して obanに到達します。

ps@dalwhinnie> show route 172.16.0/24


172.16.0.0/24 *[BGP/170] 2d 20:09:01, localpref 100, from 10.200.86.3 AS path:I > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5

172.16.0/24の iBGPネクストホップが、dalwhinnieの inet.3テーブルにはないobanのアドレスの場合、そのルートのトラフィックは、RSVP LSPを使用できません。RSVP LSPを使用するためには、そのネクストホップが inet.3に保持されている必要があります。

次のケーススタディ（図 1.12を参照）では、eBGPピアであるCE4（192.168.90.14）が obanに 172.17.0/24をアドバタイズしています。obanは、iBGPによるアドバタイズ前に、そのルートのネクストホップをそれ自体の IPアドレスに書き換えていないため、dalwhinnieは、そのルートのプロトコルネクストホップが192.168.90.14であるものと認識します。

ps@dalwhinnie> show route 172.17.0/24 detail

inet.0:34 destinations, 34 routes (33 active, 0 holddown, 1 hidden)172.17.0.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Next hop type:Indirect Next-hop reference count:3 Source:10.200.86.3 Next hop type:Router, Next hop index:554 Next hop:192.168.86.5 via ge-0/0/2.0, selected Protocol next hop:192.168.90.14 ... ... ... Router ID:10.200.86.3

この場合、172.17.0/24宛てのトラフィックでは、dalwhinnie-to-oban LSPが使用されません。これは、192.168.90.14（BGPネクストホップ）が dalwhinnieのinet.3テーブルに存在しないためです。

dalwhinnieのトラフィックが dalwhinnie-to-oban LSPを経て宛先 172.17.0/24に到達するためには、dalwhinnie-to-oban LSP内で install <route>設定を使用します。dalwhinnie-to-oban LSPに install 192.168.90.12/30を追加すると、192.168.90.12/30ルートが inet.3テーブルにインストールされ、このアドレスが dalwhinnie-to-oban LSPのネクストホップとして認識されます。これにより、BGPが inet.3テーブル内でプロトコルネクストホップ（CE4 - 192.168.90.14）を解決できるようになり、dalwhinnie-to-oban LSPが使用可能なときには、CE4の BGPルート宛てのトラフィックがこの LSPを使用できるようになります。この設定変更後、tracerouteにより、172.17.0/24宛てのトラフィックがこの LSPを使用することを確認できます。


tormore lo0 10.200.86.9




blair lo0 10.200.86.1


oban

lo0 10.200.86.3

macduff lo0 10.200.86.8




.1

.6

.5

.2

.34


ge-0/0/2

ge-0/0/3

.30

.29

ge-0/0/1 .10 .9

.46

.45

ge-0/0/3

ge-0/0/2

ge-0/0/1 .14

fe-0/0/1 .13

fe-2/0/1

ge-0/0/3 .42

.41

ge-0/0/2 .50

ge-0/0/3

.18

fe-2/0/0 .17

ge-6/0/0 .26

.25 ge-0/0/2

ge-0/0/3

.38

.37

fe-2/0/1

.33 ge-0/0/2

e1-1/0/0

.22

fe-0/0/1

fe-2/0/0 .49

.21

ge-0/0/1.803

192.168.90.13/30

CE4

172.17.0/24 eBGP経由でobanへ

172.17.0/24 BGPネクストホップは

192.168.90.14

図 1.12 BGPルートとLSP

[edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; install 192.168.90.12/30; link-protection; primary via-blair;}

ps@dalwhinnie> show route 192.168.90.12/30


192.168.90.12/30 *[OSPF/10] 07:14:42, metric 4 > to 192.168.86.5 via ge-0/0/2.0


192.168.90.12/30 *[RSVP/7] 00:00:43, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5

ps@dalwhinnie> show route 172.17.0/24 detail

inet.0:34 destinations, 34 routes (33 active, 0 holddown, 1 hidden)172.17.0.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Next hop type:Indirect Next-hop reference count:3 Source:10.200.86.3 Next hop type:Router, Next hop index:262142


Next hop:192.168.86.5 via ge-0/0/2.0 weight 0x1, selected Label-switched-path dalwhinnie-to-oban Label operation:Push 300928 Next hop:192.168.86.29 via ge-0/0/3.0 weight 0x8001 Label-switched-path Bypass->192.168.86.5 Label operation:Push 300928, Push 300656(top) Protocol next hop:192.168.90.14 ... ... ... Router ID:10.200.86.3

ps@dalwhinnie> traceroute 172.17.0.1 no-resolvetraceroute to 172.17.0.1 (172.17.0.1), 30 hops max, 40 byte packets 1 192.168.86.5 4.675 ms 2.758 ms 2.843 ms MPLS Label=300928 CoS=0 TTL=1 S=1 2 192.168.86.9 3.410 ms 4.945 ms 2.540 ms MPLS Label=300928 CoS=0 TTL=1 S=1 3 192.168.86.25 5.750 ms 5.619 ms 7.720 ms 4 192.168.90.14 4.575 ms !N 3.045 ms !N 2.865 ms !N

ps@dalwhinnie> show route table inet.3


10.200.86.1/32 *[LDP/9] 1w0d 03:47:47, metric 1 > to 192.168.86.5 via ge-0/0/2.0, Push 299920 ... ... ... > to 192.168.86.5 via ge-0/0/2.0, Push 300000 to 192.168.86.29 via ge-0/0/3.0, Push 300112192.168.90.12/30 *[RSVP/7] 00:01:18, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5

CE4の BGPルート宛てのトラフィックが、dalwhinnie-to-oban LSP（本書で頻出の LSP）を経由してCE4に到達できるようになっています。ただし、192.168.90.14自体宛てのトラフィックでは、この LSPが使用されません（inet.0内のOSPFルートを使用）。これは、デフォルトでは、BGPはネクストホップを解決する目的にのみinet.3テーブルを使用でき、トラフィックを LSPによって inet.3内のルートに転送することはできないためです（BGPは、ネクストホップが inet.3に保持されているルートに対してのみ LSPを使用でき、inet.3にあるネクストホップ自体に LSP経由でトラフィックを送信することはできない）。

192.168.90.12/30宛てのトラフィックが LSPを使用できるようにするには、そのRSVP /30ルートを inet.3から inet.0に移動する必要があります。これを行う前に、dalwhinnieからCE4（192.168.90.14）への、基盤となる tracerouteを取得してみましょう。

ps@dalwhinnie> traceroute 192.168.90.14 no-resolvetraceroute to 192.168.90.14 (192.168.90.14), 30 hops max, 40 byte packets 1 192.168.86.5 4.708 ms 4.491 ms 4.892 ms 2 192.168.86.9 4.572 ms 3.854 ms 3.848 ms 3 192.168.86.25 4.599 ms 4.878 ms 4.578 ms 4 192.168.90.14 3.941 ms 3.737 ms 3.590 ms

tracerouteには、その宛先へのトラフィックが RSVP LSPを使用していないことが示されています。LSP内のinstall 192.168.90.12/30設定にactiveキーワードを追加することにより、192.168.90.12/30への RSVPルートが inet.3テーブルから inet.0テーブルに移動します。


[edit protocols mpls]ps@dalwhinnie# showlabel-switched-path dalwhinnie-to-oban { to 10.200.86.3; install 192.168.90.12/30 active; link-protection; primary via-blair;}

これにより、dalwhinnieから送信される 192.168.90.12/30宛てのトラフィックでは、ラベルスイッチドパス dalwhinnie-to-obanが使用可能な場合はその LSPが使用されるようになります。tracerouteにより、activeの設定後に、トラフィックがこの LSPを経由して宛先に転送されることを確認できます。前の show route

192.168.90.12/30の出力と、LSP設定に activeキーワードを追加した後の以下の出力を比較してみてください。



192.168.90.12/30 *[RSVP/7] 00:00:26, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5 [OSPF/10] 1d 14:07:52, metric 4 > to 192.168.86.5 via ge-0/0/2.0

ps@dalwhinnie> traceroute 192.168.90.14 no-resolvetraceroute to 192.168.90.14 (192.168.90.14), 30 hops max, 40 byte packets 1 192.168.86.5 4.492 ms 2.691 ms 2.833 ms MPLS Label=300944 CoS=0 TTL=1 S=1 2 192.168.86.9 4.157 ms 4.080 ms 4.643 ms MPLS Label=300944 CoS=0 TTL=1 S=1 3 192.168.86.25 4.677 ms 4.859 ms 4.624 ms 4 192.168.90.14 10.693 ms 9.747 ms 3.859 ms

設定変更により、RSVPルート 192.168.90.12が inet.3から inet.0に移動し、その宛先へのトラフィックが RSVP LSPを使用できるようになりました。また、BGPは、ネクストホップを解決するために inet.0または inet.3を使用できるため、プロトコルネクストホップ 192.168.0.14の BGPルート宛てのトラフィックでも引き続きその LSPが使用されます。



172.17.0.0/24 *[BGP/170] 1d 07:34:55, localpref 100, from 10.200.86.3 AS path:65432 I > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5

192.168.0.12/30ルートを inet.3から inet.0に移動することにより、その BGPネクストホップのルート宛てのトラフィックが、使用可能な LSPを使用できるようになりました。また、その宛先自体宛てのトラフィックもその LSPを使用できるようになりました。前の例には、install <route> (active)により、ローカルルーターで特定の LSPを使用するよう特定のルートをマッピングする方法が示されています。ただし、この手法には欠点もあります。スタティックルートとの類似点により、拡張性が制限され、ルートごとの設定オーバーヘッドが増えます。スタティックルートと同様に、このオプションを使用するときは注意が必要ですが、適切に適用すれば便利なツールです。


ここで、次の概念について説明するために、LSPから install 192.168.90.12/30

active設定を削除しましょう。 [edit protocols mpls]ps@dalwhinnie# delete label-switched-path dalwhinnie-to-oban install 192.168.90.12/30

Traffic-engineering bgp-igp

本章の前述の inet.3テーブルについての説明で、dalwhinnieから送信される、プロトコルネクストホップ 10.200.86.3（oban）でアドバタイズされた BGPルート宛てのトラフィックが、使用可能な obanへの LSPを使用することを示しました。ただし、10.200.86.3は、BGPがネクストホップとして使用する inet.3テーブルにのみ保持されているため、obanの lo0アドレス自体宛てのトラフィックは、この LSPを使用できません（デフォルトでは、そのアドレス自体へのトラフィックが、使用可能な LSPを使用できない）。これは、show routeおよび tracerouteにより確認できます。

ps@dalwhinnie> show route 10.200.86.3


10.200.86.3/32 *[OSPF/10] 1w3d 00:32:38, metric 3 > to 192.168.86.5 via ge-0/0/2.0


10.200.86.3/32 *[RSVP/7] 01:24:24, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5 [LDP/9] 01:33:16, metric 1 > to 192.168.86.5 via ge-0/0/2.0, Push 300960

ps@dalwhinnie> traceroute 10.200.86.3 no-resolvetraceroute to 10.200.86.3 (10.200.86.3), 30 hops max, 40 byte packets 1 192.168.86.5 675.632 ms 5.764 ms 4.069 ms 2 192.168.86.9 5.025 ms 6.629 ms 4.293 ms 3 10.200.86.3 3.808 ms 3.021 ms 3.996 ms

結果の出力には、10.200.86.3へのトラフィックが LSPを使用しないことが示されています。ネットワークのすべての内部トラフィックが、使用可能な場合に LSPを使用することを目標とする場合、Junosにはそのための手法がいくつかあります。最初に説明する手法は、[edit protocols mpls]階層内で traffic-engineering bgp-igpを設定する方法です。この設定では、ローカルルーターの inet.3テーブルの内容が inet.0テーブルに移されるため、dalwhinnie上の IGPが obanへの LSPを認識できるようになります。これにより、inet.3テーブル内のルートが inet.0に移動して inet.3が空になり、ネットワークの任意の lo0アドレス宛てのトラフィックが、使用可能な場合はLSPを使用できるようになります。dalwhinnieからobanの lo0へのトラフィックでも、使用可能な LSPが使用されます。これについても、同様に show routeおよび tracerouteの出力で確認できます。

[edit protocols mpls]ps@dalwhinnie# showtraffic-engineering bgp-igp;label-switched-path dalwhinnie-to-oban { to 10.200.86.3; link-protection; primary via-blair;} ... ...


...

[edit protocols mpls]ps@dalwhinnie# run show route 10.200.86.3


10.200.86.3/32 *[RSVP/7] 00:00:28, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5 [LDP/9] 00:00:29, metric 1 > to 192.168.86.5 via ge-0/0/2.0, Push 300960 [OSPF/10] 00:00:29, metric 3 > to 192.168.86.5 via ge-0/0/2.0

[edit protocols mpls]ps@dalwhinnie# run traceroute 10.200.86.3 no-resolvetraceroute to 10.200.86.3 (10.200.86.3), 30 hops max, 40 byte packets 1 192.168.86.5 3.955 ms 4.309 ms 2.823 ms MPLS Label=301040 CoS=0 TTL=1 S=1 2 192.168.86.9 4.427 ms 2.806 ms 2.832 ms MPLS Label=300992 CoS=0 TTL=1 S=1 3 10.200.86.3 8.533 ms 11.487 ms 12.444 ms

[edit protocols mpls]ps@dalwhinnie# run show route table inet.3

[edit protocols mpls]ps@dalwhinnie# run show route table inet.0 | match 10.200.*/3210.200.86.1/32 *[LDP/9] 00:15:42, metric 110.200.86.2/32 *[LDP/9] 00:15:42, metric 110.200.86.3/32 *[RSVP/7] 00:15:41, metric 310.200.86.4/32 *[LDP/9] 00:15:42, metric 110.200.86.5/32 *[Direct/0] 4w0d 00:58:5210.200.86.6/32 *[LDP/9] 00:15:41, metric 110.200.86.7/32 *[LDP/9] 00:15:41, metric 110.200.86.8/32 *[LDP/9] 00:15:42, metric 110.200.86.9/32 *[LDP/9] 00:15:42, metric 1

traffic-engineering bgp-igpは、LSPごとに設定されていません。この設定変更は、グローバルに適用されます。また、inet.3テーブルが空になっており、そこにあったルートは inet.0に保持されています。

Traffic-engineering bgp-igp-both-ribs

VPNをサポートする場合、MPLSでは、LSP送信アドレスが inet.3に保持されている必要がありますが、traffic-engineering bgp-igpを使用すると inet.3が空になってしまうため、別の方法を使用しなければなりません。それがこのオプションの欠点です。その解決策は、traffic-engineeringコマンドの別のオプションにあります。bgp-igp-both-ribsオプションを使用すると、（inet.3を空にするのではなく）inet.3の内容が inet.0にコピーされます。そのため、このオプションでは、トラフィックが LSPエンドポイントへのルートにアクセスできると同時に、これらのエンドポイントが inet.3で維持され、VPNをサポートできます。 [edit protocols mpls]ps@dalwhinnie# showtraffic-engineering bgp-igp-both-ribs;label-switched-path dalwhinnie-to-oban { to 10.200.86.3; link-protection; primary via-blair;}


[edit]ps@dalwhinnie# run show route table inet.3 | match /3210.200.86.1/32 *[LDP/9] 00:00:20, metric 110.200.86.2/32 *[LDP/9] 00:00:20, metric 110.200.86.3/32 *[RSVP/7] 00:00:19, metric 310.200.86.4/32 *[LDP/9] 00:00:20, metric 110.200.86.6/32 *[LDP/9] 00:00:20, metric 110.200.86.7/32 *[LDP/9] 00:00:20, metric 110.200.86.8/32 *[LDP/9] 00:00:20, metric 110.200.86.9/32 *[LDP/9] 00:00:20, metric 1

[edit]ps@dalwhinnie# run show route table inet.0 | match 10.200.*/3210.200.86.1/32 *[LDP/9] 00:00:29, metric 110.200.86.2/32 *[LDP/9] 00:00:29, metric 110.200.86.3/32 *[RSVP/7] 00:00:28, metric 310.200.86.4/32 *[LDP/9] 00:00:29, metric 110.200.86.5/32 *[Direct/0] 4w0d 01:05:5310.200.86.6/32 *[LDP/9] 00:00:29, metric 110.200.86.7/32 *[LDP/9] 00:00:29, metric 110.200.86.8/32 *[LDP/9] 00:00:29, metric 110.200.86.9/32 *[LDP/9] 00:00:29, metric 1

inet.3のルートが inet.3テーブルと inet.0テーブルの両方に保持されています。

Traffic-engineering mpls-forwarding

traffic-engineering bgp-igp-both-ribsを使用すると、inet.3ルートのプリファレンスの方が良い（低い）ため、inet.0テーブルに保持されている宛先への IGPルートに代わって inet.3ルートが使用されます。ルーティングの目的で inet.0テーブル内の IGPルートをアクティブな状態で維持するには、traffic-engineering mpls-

forwardingを設定します。このオプションは、IGPルートを使用可能にする必要のあるレガシーなポリシーで必要になる場合があります。このオプションを使用しても、転送目的では、LSPエンドポイントがアクティブなままになります。以下の出力には、この設定の前後の効果が示されています。

[edit]ps@dalwhinnie# run show route 10.200.86.3


10.200.86.3/32 *[RSVP/7] 00:07:51, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5 [LDP/9] 00:07:52, metric 1 > to 192.168.86.5 via ge-0/0/2.0, Push 300960 [OSPF/10] 00:30:06, metric 3 > to 192.168.86.5 via ge-0/0/2.0



[edit]ps@dalwhinnie# delete protocols mpls traffic-engineering bgp-igp-both-ribs


[edit]ps@dalwhinnie# set protocols mpls traffic-engineering mpls-forwarding

[edit]ps@dalwhinnie# commitcommit complete


inet.0:34 destinations, 43 routes (33 active, 0 holddown, 1 hidden)@ = Routing Use Only, # = Forwarding Use Only+ = Active Route, - = Last Active, * = Both

10.200.86.3/32 @[OSPF/10] 00:31:57, metric 3 > to 192.168.86.5 via ge-0/0/2.0 #[RSVP/7] 00:00:10, metric 3 > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path Bypass->192.168.86.5 [LDP/9] 00:00:11, metric 1 > to 192.168.86.5 via ge-0/0/2.0, Push 300960



この章の以降のセクションでの説明のため、dalwhinnieを [edit protocols mpls]階層で traffic-engineering bgp-igp-both-ribs設定に戻します。

[edit]ps@dalwhinnie# show protocols mplstraffic-engineering bgp-igp-both-ribs;......

IGP shortcuts

この時点では、dalwhinnieからネットワークの任意の lo0アドレスに転送されるすべてのトラフィックは、使用可能な場合に LDP LSPまたは RSVP LSPを使用します。ここで、ネットワークのすべての内部トラフィックが、使用可能な LSPを使用するという要件を満たすために、最後のステップが必要になります。IGPインタフェースへのトラフィックでは、まだ使用可能な LSPがネクストホップとして使用されていません。例えば、dalwhinnieから obanの ge-0/0/3.0インタフェース（192.168.86.38）へのトラフィックでは、まだ IGPルートが使用されています。これは、tracerouteにより確認できます。



192.168.86.36/30 *[OSPF/10] 00:02:00, metric 4 > to 192.168.86.5 via ge-0/0/2.0


[edit]ps@dalwhinnie# run traceroute 192.168.86.38 no-resolvetraceroute to 192.168.86.38 (192.168.86.38), 30 hops max, 40 byte packets 1 192.168.86.5 4.082 ms 4.697 ms 4.052 ms 2 192.168.86.9 4.798 ms 6.081 ms 4.835 ms 3 192.168.86.38 5.058 ms 3.122 ms 3.678 ms

この動作では、一部のオペレータに、obanへの LSPが存在しないか動作していないかのように見える可能性があり、運用上の問題が生じることがあります。このネクストホップ動作を変更するには、[edit protocols ospf traffic-engineering]階層でshortcutsを設定するか、ネットワークで ISISが実行されている場合は set protocols

isis traffic-engineering family inet shortcutsを設定します。本書のラボネットワークでは、OSPFが使用されています。以下の出力には、shortcutsを追加したことによる効果が示されています。すなわち、dalwhinnieのすべてのネットワーク内部トラフィックが、使用可能な場合に LSPパスを使用できるようになっています。 [edit protocols mpls]ps@dalwhinnie# showtraffic-engineering bgp-igp-both-ribs;label-switched-path dalwhinnie-to-oban { to 10.200.86.3; link-protection; primary via-blair;}

[edit]ps@dalwhinnie# show protocols ospftraffic-engineering { shortcuts;}

[edit]ps@dalwhinnie# commitcommit complete

[edit]ps@dalwhinnie# run traceroute 192.168.86.38 no-resolvetraceroute to 192.168.86.38 (192.168.86.38), 30 hops max, 40 byte packets 1 192.168.86.5 3.190 ms 2.776 ms 3.606 ms MPLS Label=301168 CoS=0 TTL=1 S=1 2 192.168.86.9 2.676 ms 4.863 ms 2.578 ms MPLS Label=301072 CoS=0 TTL=1 S=1 3 192.168.86.38 3.719 ms 3.799 ms 3.820 ms

注 OSPFとは異なり、ISISでは、traffic-engineeringおよびトラフィック制御データベースの作成がデフォルトでサポートされます。そのため、shortcuts設定を追加するには、ISIS内で明示的に traffic-engineeringを設定する必要があります。

注本書の例では、IGP shortcutsを有効にする前に protocols mpls traffic-engineering

が設定されています。protocols mpls traffic-engineeringが設定されていない場合、shortcuts設定により、LSPをネクストホップとして使用可能だったすべての IGPアドレスが inet.3テーブルに移動し、BGPネクストホップとして使用できるようになります。本書の例では、すでに dalwhinnieに traffic-engineering bgp-igp-both-ribsが設定されているため、代わりに、LSPをネクストホップとして使用可能だったすべての IGPルートが inet.0テーブルに取り込まれています。

traffic-engineering shortcutsを追加することにより、内部 IGPインタフェースアドレス 192.168.86.38へのトラフィックが、使用可能な LSPを dalwhinnieからその宛先まで使用できるようになります。


MPLSおよび IGPプロトコルで traffic-engineering設定コマンドを使用すると、ルーターにおいて、使用可能な LSPをどのトラフィックが使用するかについて幅広く影響を与えることができ、これらの手法を柔軟に拡張することができます。ただし、特定のLSPを使用するプレフィックス /プレフィックス範囲に対する制御が低下するというトレードオフもあります。これは、古典的なショットガン（traffic-engineering コマンド）アプローチとスナイパー（LSP設定の installおよび active）アプローチの違いのようなものです。どのアプローチが実際のネットワークに適しているかは、ネットワーク規模、成長の可能性、運用上の考慮事項、およびネットワーク要件によって異なってきます。

これまでに説明したルートテーブルを統合する手法でも、その動作は、これらの設定が行われたルーターに制限されます。例えば、dalwhinnieでは、ネットワークの内部トラフィックおよびトランジットトラフィックに LSPを使用できるようにするために、MPLSおよび OSPFで traffic-engineeringが設定されています。ただし、この設定は、ネットワーク内の他のルーターによるルーティングの決定には影響しません。それでは、IGP隣接機器によるルーティングの決定に影響を与えることのできるオプションについて説明しましょう。

IGPへの LSPの直接アドバタイズ

内部ネットワークトラフィックが、使用可能な LSPを使用できるようにするもう 1つのオプションとして、ラベルスイッチドパスをメトリックとともに IGPに直接アドバタイズする方法があります。以下の例では、lagavulinには、インタフェースと同様に、obanおよび tormoreへの LSPがOSPFに直接アドバタイズされています。LSPを IGPにアドバタイズするときは、ベストプラクティスとして、逆方向の IGPでも LSPのメトリックを同じにすることをお奨めします。以下の例では、obanおよび tormoreにも、それぞれの OSPF設定に lagavulinへの LSPがアドバタイズされています（出力には示されていない）。 [edit protocols ospf]ps@lagavulin# showtraffic-engineering;area 0.0.0.0 { interface ge-0/0/2.0 { interface-type p2p; } interface ge-0/0/3.0 { interface-type p2p; } interface lo0.0; label-switched-path lagavulin-to-oban { metric 2; } label-switched-path lagavulin-to-tormore { metric 2; }}

ps@lagavulin> show ospf neighborAddress Interface State ID Pri Dead192.168.86.1 ge-0/0/2.0 Full 10.200.86.8 128 32192.168.86.30 ge-0/0/3.0 Full 10.200.86.5 128 3510.200.86.3 lagavulin-to-oban Full 10.200.86.3 0 010.200.86.9 lagavulin-to-tormore Full 10.200.86.9 0 0

ps@lagavulin> show ospf interfaceInterface State Area DR ID BDR ID Nbrsge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1ge-0/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1lagavulin-to-oban PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1lagavulin-to-tormorePtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1lo0.0 DR 0.0.0.0 10.200.86.7 0.0.0.0 0

ps@lagavulin>


それぞれ IGPにアドバタイズされた、ルーター相互のフルメッシュのRSVP LSPでは、IGPが LSPにアクセスしてアドバタイズできるようにすることにより、inet.0テーブルが大幅に変更されます。lagavulinの show routeの出力から、lo0およびOSPFインタフェースアドレスへのトラフィックが LSPを使用することを確認できます。

ps@lagavulin> show route 10.200.86.3


10.200.86.3/32 *[OSPF/10] 00:12:56, metric 2 > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban


10.200.86.3/32 *[RSVP/7] 00:12:51, metric 2 > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban

ps@lagavulin> show route 192.168.86.33


192.168.86.32/30 *[OSPF/10] 00:09:43, metric 3 > to 192.168.86.1 via ge-0/0/2.0 to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore

lagavulinから obanの lo0インタフェースおよび tormoreの ge-0/0/2.0インタフェースへのトラフィックでは、使用可能な LSPが使用されます。この章で前に使用した traffic-engineering設定とは異なり、この手法では、IGP隣接機器によるルーティングの決定を変更することも可能です。IGPは、その他の IGPインタフェースのときと同様に LSPをアドバタイズするため、ルーターは、OSPF Type 1 LSAまたは ISIS TLVで LSPをアドバタイズします。これにより、IGP隣接機器は、ネットワーク内部トラフィックを移動するために、ローカルルーターの LSPを使用し始めることができます。IGPへの LSPのアドバタイズは拡張性が高いため、比較的大規模なネットワークに役立ちます。ただし、IGPピアが、使用可能なパスとしての LSPの存在に基づいてルーティングの決定を変更するという欠点があります。言うまでもなく、このオプションを効果的に実装するためには、ネットワーク動作を十分に理解しておくことが必要です。

ヒントベストプラクティスとして、IGP shortcutsと IGPへの LSPアドバタイズメントの両方を実装しないことをお奨めします。

ポリシーベースの LSPマッピング

この章で最後に説明するトラフィック制御手法は、ポリシーベースの LSPマッピングです。これについて説明するために、lagavulinの OSPF階層からRSVP LSPが削除され、OSPFをアクティブに実行している 2つの論理ネットワークインタフェースが残されています。以下に示すように、lagavulinは obanへの 2つの RSVP LSPを持ち、それぞれにネットワークを通過する異なるプライマリパスが設定されています。 [edit protocols ospf]ps@lagavulin# showtraffic-engineering;area 0.0.0.0 { interface ge-0/0/2.0 { interface-type p2p;


} interface ge-0/0/3.0 { interface-type p2p; } interface lo0.0 { passive; }}

[edit protocols mpls]ps@lagavulin# showlabel-switched-path lagavulin-to-tormore { to 10.200.86.9;}label-switched-path lagavulin-to-oban { to 10.200.86.3; primary via-blair;}label-switched-path lagavulin-to-oban-prime { to 10.200.86.3; primary via-talisker;}path via-blair { 10.200.86.1 loose;}path via-talisker { 10.200.86.4 loose;}interface ge-0/0/2.0;interface ge-0/0/3.0;

先ほど、obanは、172.16.0/22範囲内にある 4つの /24ルートを iBGPによって lagavulinにアドバタイズし始めました。ここで説明するトラフィック制御手法の目標は、強制的に 172.16.0/24および 172.16.1/24ネットワークに lagavulin-to-oban LSPを使用させ、また 172.16.2/24および 172.16.3/24ネットワークにlagavulin-to-oban-prime LSPを使用させることです。以下の出力には、ポリシーベースの LSPマッピングを実装する前の、各ルートのパス選択が示されています。

ps@lagavulin> show route protocol bgp range 172.16.0.0/22


172.16.0.0/24 *[BGP/170] 00:00:25, localpref 100, from 10.200.86.3 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban-prime172.16.1.0/24 *[BGP/170] 00:00:25, localpref 100, from 10.200.86.3 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban-prime172.16.2.0/24 *[BGP/170] 00:00:25, localpref 100, from 10.200.86.3 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban-prime172.16.3.0/24 *[BGP/170] 00:00:25, localpref 100, from 10.200.86.3 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban-prime

この時点では、すべてのルートが優先的に lagavulin-to-oban-prime LSPを使用しています。図 1.13に、各 LSPのパスを示します。


注上記の結果から、172.16.0/22範囲にあるルートへのすべてのトラフィックが lagavulin-to-oban-prime LSPを使用していることがわかります。ただし、デフォルトでは、1つのアクティブルートに対し、同じ宛先への等コストパスが複数ある場合、Junos OSは、ハッシュアルゴリズムによってネクストホップを選択してフォワーディングテーブルにインストールします。

tormore lo0 10.200.86.9




blair lo0 10.200.86.1


oban lo0 10.200.86.3

macduff

lo0 10.200.86.8



.1

.6

.5

.2

.34


.30

.29

.10 .9

.46

.45

.14

.13

.42

.41

.50 .18

.17

.26 .25

.38

.37

.33

.22

.49

.21

lagavulin-to-oban 優先 lagavulin-to-oban

obanがiBGP経由で172.17.[0-3]/24をアドバタイズ

iBGP経由で172.17.[0-3]/24をアドバタイズ

図 1.13 一般に、ポリシーマッピングは同じルーター間に複数の LSPがある場合に使用される

ポリシーベースのLSPマッピングを実装するための最初のステップでは、特定のルートまたはルートの範囲を特定の LSPにマッピングするためのポリシーを作成します。以下に示すポリシーは、アドバタイズされた 4つの対象プレフィックスについてこれを行っています。 [edit policy-options]ps@lagavulin# showpolicy-statement map-routes-to-oban-lsps { term 10 { from { protocol bgp; neighbor 10.200.86.3; route-filter 172.16.0.0/24 orlonger; route-filter 172.16.1.0/24 orlonger; } then { install-nexthop lsp lagavulin-to-oban; accept; } } term 20 { from { protocol bgp; neighbor 10.200.86.3; route-filter 172.16.2.0/24 orlonger; route-filter 172.16.3.0/24 orlonger; } then { install-nexthop lsp lagavulin-to-oban-prime; accept; } }}


ポリシーの作成を完了したら、そのポリシーを [edit routing-options forwarding-

table]階層で適用します。 [edit routing-options]ps@lagavulin# show ... ... ...forwarding-table { export map-routes-to-oban-lsps;}

このポリシーは、ルートテーブルの観点からフォワーディングテーブルに適用されるため、エクスポートポリシーとして適用されます。以下の出力では、目的のプレフィックスが、適切な LSPを使用するようマッピングされています。これは比較的単純な例ですが、必要に応じて拡張することにより、多数のルートおよび BGPピアに対応させることができます。

ps@lagavulin> show route protocol bgp range 172.16.0.0/22


172.16.0.0/24 *[BGP/170] 3d 18:53:04, localpref 100, from 10.200.86.3 AS path:I > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban172.16.1.0/24 *[BGP/170] 01:06:32, localpref 100, from 10.200.86.3 AS path:I > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban172.16.2.0/24 *[BGP/170] 01:06:32, localpref 100, from 10.200.86.3 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban-prime172.16.3.0/24 *[BGP/170] 01:06:32, localpref 100, from 10.200.86.3 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-oban-prime

ps@lagavulin>

予測どおり、172.16.0/24および 172.16.1/24ルートでは明示的に lagavulin-to-oban LSPが優先的に使用され、その他の 2つのルートでは明示的に lagavulin-to-oban-prime LSPが優先的に使用されています。

ポリシーベースの LSPマッピングは、等コストパスが複数存在する 2つのエンドポイント間のトラフィックを管理するうえで効果的です。install <route> (active)

を使用する手法と同様に、この手法にはそれほど拡張性がありません。すなわち、ネットワークが成長したり送受信されるトラフィックが増加するたびに、ルーターごとにそれぞれ独自のポリシーを管理することが負担になる可能性があります。ただし、適切に使用すれば、ネットワークエンジニアは、ポリシーベースの LSPマッピングによって非常にきめ細かくトラフィックフローを制御することができます。

TEのまとめ

このセクションでは、ジュニパーネットワークスのルーターで利用できる複数の TEオプションについて説明しました。どのオプションを実装するのがベストかは、特定の要件、成長の可能性、および特定ネットワークのトラフィックパターンによって異なります。参考までに、表 1.1に、各手法の重要ポイントをまとめます。


表 1.1 TEオプションのまとめ

TE手法説明影響の対象利点欠点

LSPメトリック

インタフェースに設定された IGPメトリックに関わらず、LSPにスタティックメトリックを割り当てます。

パスに関わらず、LSPのメトリックを固定

安定した、予測可能なコストが提供されます。

次善のパス選択になる可能性があります。

リンクカラー

LSPに特定リンクを使用することを要求または禁止します。ネットワーク全体に適用されます。

LSPパス

優先度の高いトラフィック用にリンクを予約したり、トラフィックを複数のリンクに均等に分配したりできます。

ネットワークが非常に複雑になり、適切に実装しないとLSPの形成が制限される可能性があります。

ストリクト /ルーズホップ

LSPごとに LSPのプライマリまたはセカンダリパスを制御したり、そのパスに影響を与えます。

LSPパス LSPパスを制御できます。フェイルオーバーオプションが制限されたり、LSPの確立を妨げられる可能性があります。

インストールルート (アクティブ )

LSPごとに、特定のLSPを使用するよう特定のプレフィックス /プレフィックス範囲をマッピングします。ルーターごとに適用されます。

LSPを使用するトラフィック、ローカルルーティングの決定

プレフィックスが使用する LSPを制御でき、非BGPプレフィックスがLSPパスを使用できるようになります。

スタティックルートと同様の動作。特定の LSPが過負荷にならないよう注意が必要です。ネットワークやトラフィックの成長に応じて十分に拡張できない可能性があります。

traffic-engineering bgp-igp

inet.3を inet.0に移すことにより、inet.3エントリーを転送に使用できるようにします。ルーターごとに適用されます。


非 BGPトラフィックがLSPを使用して LSPエンドポイントに到達できるようになります。拡張性に優れています。

MPLSサービスがサポートされません *（第 2章で説明）。

traffic-engineering bgp-igp-both-ribs

inet.3を inet.0にコピーすることにより、inet.3エントリーを転送に使用できるようにします。MPLSサービスがサポートされます *。ルーターごとに適用されます。


非 BGPトラフィックがLSPを使用して LSPエンドポイントに到達できるようになります。拡張性に優れています。

特定の RSVP LSPにどのプレフィックスをマッピングするかを制御する機能が失われ始めます。

traffic-engineering mpls-forwarding

inet.3を inet.0にコピーして、ポリシー処理のために IGPルーティングエントリーをそのまま維持します。MPLSサービスがサポートされます *。ルーターごとに適用されます。


非 BGPトラフィックがLSPを使用して LSPエンドポイントに到達できるようになります。処理のため IGPルートが使用可能でなければならないレガシーなポリシーをサポートできます。拡張性に優れています。

特定の RSVP LSPにどのプレフィックスをマッピングするかを制御する機能が失われ始めます。

IGP shortcuts

IGPルートが、使用可能な LSPを使用できるようになります。ルーターごとに適用されます。


すべての内部トラフィックが LSPを使用できます。拡張性に優れています。

特定の RSVP LSPにどのプレフィックスをマッピングするかを決定する機能が失われます。

IGPでの LSP

IGPが、IGPインタフェースについて行うときと同様に LSPを使用 /アドバタイズします。ルーターごとに適用されます。他の IGPピアルーターによるルーティングの決定に影響を与えることができます。

LSPを使用するトラフィック、ネットワークルーティングの決定

ネットワークトラフィックが外部の宛先宛ての場合も LSPを使用できます。拡張性に優れています。

ネットワーク全体で有効にするには、慎重なプランニングと実装が必要です。


ポリシーベースのLSPマッピング

フォワーディングテーブルに適用されたエクスポートポリシーによって、特定の LSPを使用するよう特定のプレフィックス /プレフィックス範囲をマッピングします。ルーターごとに適用されます。


2台のルーター間に複数の等コストLSPが存在する場合に、負荷分散の管理に役立ちます。install routeが LSP単位であるのに対し、ポリシー単位で更新できることから、実装方法によっては、install route設定より拡張性が高まります。

ポリシーを作成するときは、そのポリシーによって特定の LSPが過負荷にならないよう十分注意する必要があります。ネットワークやトラフィックの成長に応じて十分に拡張できない可能性があります。

LSPの帯域幅管理どのリンクも飽和しないだけのハードウェアおよび物理接続を付加することでネットワークを拡張できない場合、またはネットワークの規模が大きくなり過ぎて、運用上、使用可能な容量がわからず十分に活用できていない場合、LSPの帯域幅を適切に管理することによって既存の資産を最大限に活用することが不可欠です。LSPの帯域幅管理はトラフィック制御の 1つの方法で、使用可能なリソース全体にトラフィックを分配します。帯域幅管理はトラフィック制御の一部ですが、使用できる機能や手法が多岐に渡るため、その説明のためにこのセクションを別途設けています。帯域幅管理では、最適パス上に容量を追加する代わりに、既存のリソースを最大限に活用することに重点を置くため、一部のトラフィックでネットワーク上の最適パスが使用されない可能性があります。ただし、リソースが限られている環境では、トラフィックが最適パスで宛先まで到達することより、確実に宛先に到達することの方が重要なこともあります。

LSPの静的帯域幅

LSPに特定量の帯域幅を割り当てることにより、Ingressルーターが LSPをシグナリングするときに、各リンクで特定量の帯域幅をその LSP用に予約することが可能です。以下の出力例では、LSP lagavulin-to-obanおよび lagavulin-to-oban-primeのそれぞれに 150Mbpsの帯域幅が予約されています。これは、LSPのシグナリング時の制約であり、使用可能な帯域幅を持つパスが存在しない場合、その LSPは有効になりません。

[edit protocols mpls]ps@lagavulin# showlabel-switched-path lagavulin-to-oban { to 10.200.86.3; bandwidth 150m; primary via-blair;}label-switched-path lagavulin-to-oban-prime { to 10.200.86.3; bandwidth 150m; primary via-talisker;} ... ...

トラフィック量に変化がない場合は、これは非常に便利なツールになります。これにより、各配信リンク上の帯域幅が予約されますが、LSP上のトラフィックが増加し続ける場合は、各 LSPの帯域幅を手動で更新しなければなりません。また、短中期的にその LSPで転送する必要のあるトラフィックが小容量の場合に、将来的なトラフィック増加を見込んで LSP用に大量の帯域幅を静的に予約してしまうと、それによって他の LSPで必要な帯域幅が消費されてしまうため、非効率になる可


能性もあります。このオプションは、容易に予測可能な一定量のトラフィックを転送し、仮にトラフィック量が増加する場合もそれほど大きく変動しないことが予測される LSPに適しています。幸い、Junos OSには、LSPの帯域幅をより動的に管理できるオプションもあります。

帯域幅の自動割り当て

帯域幅の自動割り当てでは、LSPの静的帯域幅とは異なり、RSVP LSPで転送されるトラフィック量に応じてその予約帯域幅を動的に調整することができます。（割り当て帯域幅の変更によって）トラフィックは、make before break形式で古いパスから新しいパスへと移行されます。すなわち、Ingressルーターは、変更後の帯域幅とともに新しい LSPパスをシグナリングし、そのパスが正常に有効になってから、古いパスから新しいパスへとトラフィックを移行します。新しいパスに十分な帯域幅がない場合、現在のパスとその予約帯域幅が維持されます。すなわち、帯域幅の自動割り当てでは、新しいパスのシグナリング時点ではトラフィックに影響しません。例えば、最小限の初期帯域幅を予約するようLSPを設定し、その後自動割り当てを使用して、移行時にパケットロスを生じさせることなく、実際の使用量に応じて予約帯域幅を調整することができます。

注割り当てられる帯域幅は、必ずしも LSPで転送可能なトラフィックの最大量である必要はありません。この帯域幅は、LSPが経由する特定リンク上で予約される帯域幅です。LSPのパス上のリンクが実際のトラフィックまたは予約帯域幅で飽和していない場合、いずれかのリンクで帯域幅の競合が生じるまで、その LSPでは、必要量のトラフィックを転送することができます。輻輳時に特定のトラフィックに優先度を設定するには、QoSを実装する必要があります。これについては、本書の範囲外です。

帯域幅の自動割り当てを有効にするための最初のステップでは、auto-bandwidthオプションを使用してMPLS統計を設定します。intervalは、平均使用帯域幅の計算に使用する期間で、秒単位で指定します。[edit protocols mpls]ps@lagavulin# showstatistics { file auto-bw; interval 600; auto-bandwidth;}

ここでは、intervalが 600秒（10分）に設定されています。この設定により、lagavulinは、LSPのそれぞれの定期的調整に必要なトラフィック統計を収集することができます。MPLS統計を収集するようルーターを設定したら、目的とする各 LSPで帯域幅の自動割り当てを有効にする必要があります。各 LSPで帯域幅の自動割り当てを有効にするには、auto-bandwidthキーワードを設定します。

[edit protocols mpls]ps@lagavulin# showstatistics { file auto-bw; interval 600; ## interval to calculate average bandwidth usage; default is 300 seconds auto-bandwidth;


}label-switched-path lagavulin-to-oban { to 10.200.86.3; auto-bandwidth { adjust-interval 7200; ## bandwidth reallocation interval; default is 86,400 seconds adjust-threshold 20; ## specifies the sensitivity of the adjust-interval (optional) minimum-bandwidth 64k; ## optional – min bandwidth reservation for LSP maximum-bandwidth 150m; ## optional – hard max limit bandwidth reservation for LSP } primary via-blair;}

ヒントベストプラクティスとして、デフォルト値を使用する場合も、MPLS統計の intervalおよび LSPの auto-bandwidth adjust-intervalの値を明示的に指定することをお奨めします。こうすることにより、帯域幅の自動割り当てにどのような動作が期待されるか、またどのようなときに効果が期待されるかを運用者やエンジニアに知らせるリマインダまたは通知として役立てることができます。

上記の設定では、LSP lagavulin-to-obanに帯域幅の自動割り当てが設定されています。この機能を LSPで有効にするために必要なのは auto-bandwidthキーワードのみですが、ベストプラクティスに従って、また使用可能なオプションのさまざまな機能を示すために、auto-bandwidth階層内でその他のオプションも設定されています。上記のように設定した場合、lagavulin-to-oban LSPの帯域幅の自動割り当ては、以下のように動作します。

� 各 LSP上の平均帯域幅が 600秒おきに測定されます。 � 設定されている adjust-interval値 7200は、lagavulin-to-oban LSPが

7200秒ごとにその期間のトラフィック統計に基づいて割り当て帯域幅を調整できることを意味します。

� LSPの adjust-thresholdは 20%です。この LSPに対する現在の割り当て帯域幅が 100Mbpsの場合、帯域幅需要が 110Mbpsまで増加するか90Mbpsまで減少しても（10%）、LSPの割り当て帯域幅は調整されません。ただし、帯域幅需要が 125Mbpsまで増加するか 75Mbpsまで減少した場合（25%）、LSPの帯域幅は、それぞれ 125Mbpsまたは 75Mbpsに調整されます。

LSPに割り当てられる帯域幅は最小 64kbpsで、予約帯域幅は厳密に最大 150Mbpsです。

ヒント LSPの auto-bandwidth adjust-intervalおよびMPLS統計の intervalを設定するときは、ベストプラクティスとして、LSPの auto-bandwidth adjust-intervalの値を、MPLS統計の intervalの 3倍以上に設定することをお奨めします。これを数式で表すと、3*（MPLS統計の interval）< = （LSPの auto-bandwidth adjust-interval）となります。これにより、LSPは、少なくとも 3回分のMPLS統計バッチを基に、割り当て帯域幅の調整が必要かどうかを判断できるため、不要な LSPの再シグナリングを最小限に抑えることができます。

警告本書の執筆時点では、Junos 10.0までの参考資料には、LSPの auto-bandwidth adjust-intervalをMPLS統計の intervalの 3倍以下にするよう（3*（MPLS統計の interval）> =（LSPの auto-bandwidth adjust-interval））に記載されていますが、これは間違いです。この記述は修正される予定ですが、修正日は本書の執筆時点では不明です。


監視のみ

LSPの帯域幅の監視のみを必要とし、ルーターによる割り当て帯域幅割の自動調整を必要としない場合、LSPの auto-bandwidth階層内でmonitor-bandwidthキーワードを使用します。 [edit protocols mpls]ps@lagavulin# show label-switched-path lagavulin-to-oban-primeto 10.200.86.3;bandwidth 150m;auto-bandwidth { adjust-interval 86400; monitor-bandwidth;}primary via-talisker;

上記の出力では、lagavulinの lagavulin-to-oban-prime LSPにより、この LSPに割り当てられた帯域幅が監視されていますが、割り当てられた帯域幅の変更は行われていません。これは、帯域幅使用量のパッシブモニタリングと呼ばれます。

帯域幅調整の手動トリガー

Junosでは、ユーザーが、auto-bandwidthが設定されているすべての LSP、または auto-bandwidthが設定された特定の LSPのみについて、割り当て帯域幅の自動調整を手動でトリガーすることができます。この機能は、ラボで帯域幅の自動割り当てをテストする場合や、帯域幅使用量のパッシブモニタリングが設定されている LSPで帯域幅の調整を開始する場合に役立ちます。割り当て帯域幅の自動調整を即座に開始するには、操作コマンド request mpls lsp adjust-autobandwidthを使用します。

ps@lagavulin> request mpls lsp adjust-autobandwidth ?Possible completions: <[Enter]> Execute this command name Regular expression for LSP names to match | Pipe through a command

ps@lagavulin> request mpls lsp adjust-autobandwidth

オプションの LSP名を指定しない場合、このコマンドにより、auto-bandwidthが設定されているすべての LSPに対して調整が呼び出されます。LSP名にオプションの正規表現を含めた場合、auto-bandwidthが設定されている、指定した正規表現を名前に含むすべての LSPのうち、帯域幅調整条件を満たしている各 LSPで自動的に帯域幅が調整されます。

注帯域幅の自動調整の手動トリガーを使用した場合、影響を受ける各 LSPの adjust-intervalタイマーはリセットされません。

auto-bandwidthの動作 – 例

このセクションでは、auto-bandwidthの動作例を紹介します。lagavulinで以下のように設定されているとします。 [edit protocols mpls]ps@lagavulin# showstatistics { file auto-bw; interval 600;


auto-bandwidth;}label-switched-path lagavulin-to-oban { to 10.200.86.3; auto-bandwidth { adjust-interval 7200; adjust-threshold 20; minimum-bandwidth 64k; maximum-bandwidth 150m; } primary via-blair;}

まず、100Mbpsのトラフィックが lagavulin-to-oban LSPで送信されます（この LSPについて示される帯域幅は、一定期間に渡る平均化により、この値よりわずかに低くなる）。

ps@lagavulin> show mpls lsp name lagavulin-to-oban detailIngress LSP:6 sessions

10.200.86.3 From:10.200.86.7, State:Up, ActiveRoute:0, LSPname: lagavulin-to-oban ActivePath: via-blair (primary) LoadBalance:Random Autobandwidth MinBW:64kbps MaxBW:150Mbps AdjustTimer:7200 secs AdjustThreshold:20% Max AvgBW util:90.4322Mbps, Bandwidth Adjustment in 6423 second(s). Overflow limit:0, Overflow sample count:0 Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up Priorities:7 0 Bandwidth:90.4322Mbps SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:4) 192.168.86.30 S 192.168.86.5 S 192.168.86.9 S 192.168.86.25 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.30 192.168.86.5 192.168.86.9 192.168.86.25 ... ...

その後、トラフィック量が 150Mbpsに増加します。Max AvgBW util値が増加し、LSPの予約帯域幅の値を超えています。

ps@lagavulin> show mpls lsp name lagavulin-to-oban extensiveIngress LSP:6 sessions

10.200.86.3 From:10.200.86.7, State:Up, ActiveRoute:0, LSPname: lagavulin-to-oban ActivePath: via-blair (primary) LoadBalance:Random Autobandwidth MinBW:64kbps MaxBW:150Mbps AdjustTimer:7200 secs AdjustThreshold:20% Max AvgBW util:110.722Mbps, Bandwidth Adjustment in 6317 second(s). Overflow limit:0, Overflow sample count:0 Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up Priorities:7 0 Bandwidth:90.4322Mbps SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:4) 192.168.86.30 S 192.168.86.5 S 192.168.86.9 S 192.168.86.25 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):


192.168.86.30 192.168.86.5 192.168.86.9 192.168.86.25 ... ...

ここで、割り当て帯域幅の自動調整の手動要求を発行します（この効果は、adjust-intervalタイマーが時間切れになった場合と同じ）。

ps@lagavulin> request mpls lsp adjust-autobandwidth name "lagavulin-to-oban" ps@lagavulin> show mpls lsp name lagavulin-to-oban extensiveIngress LSP:6 sessions

10.200.86.3 From:10.200.86.7, State:Up, ActiveRoute:0, LSPname: lagavulin-to-oban ActivePath: via-blair (primary) LoadBalance:Random Autobandwidth MinBW:64kbps MaxBW:150Mbps AdjustTimer:7200 secs AdjustThreshold:20% Max AvgBW util:111.402Mbps, Bandwidth Adjustment in 6302 second(s). Overflow limit:0, Overflow sample count:0 Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up Priorities:7 0 Bandwidth:110.722Mbps SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:4) 192.168.86.30 S 192.168.86.5 S 192.168.86.9 S 192.168.86.25 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.30 192.168.86.5 192.168.86.9 192.168.86.25 11 Jan 5 08:05:25.662 Record Route:192.168.86.30 192.168.86.5 192.168.86.9 192.168.86.25 10 Jan 5 08:05:25.662 Up 9 Jan 5 08:05:25.662 Automatic Autobw adjustment succeeded 8 Jan 5 08:05:25.629 Originate make-before-break call ... ...

ps@lagavulin> show log messages | match "bandwidth changed"Jan 5 08:05:25 lagavulin rpd[1075]:RPD_MPLS_PATH_BANDWIDTH_CHANGE:MPLS path via-blair (lsp lagavulin-to-oban) bandwidth changed, path bandwidth 110721928 bpsJan 5 08:05:26 lagavulin rpd[1075]:RPD_MPLS_LSP_BANDWIDTH_CHANGE:MPLS LSP lagavulin-to-oban bandwidth changed, lsp bandwidth 110721928 bpsJan 6 05:41:26 lagavulin mgd[97769]:UI_CMDLINE_READ_LINE:User 'ps’, command 'show log messages | match "bandwidth changed" '

LSPの割り当て帯域幅が 90.4Mbpsから 110.7Mbpsに変化しています。これは、手動要求をトリガーしたときに、Max AvgBW値が前回の平均の 20%を超えていたため、LSPで帯域幅が調整されたことによる結果です（手動での adjust-autobandwidth要求による動作は、adjust-intervalタイマーが期限切れになったときと同じ）。LSPにより、トラフィックを移行する前に、make before break呼び出しが開始され、新しいパスがシグナリングされています。これらの値が、測定期間における最大トラフィックではなく最大平均トラフィックを表していることを理解しておいてください。このデータはラボ環境のもので、adjust-autobandwidth手動調整トリガーを使用しているため、トラフィックの測定期間は、人為的に実可動ネットワークより短くなっています。

警告割り当て帯域幅の自動調整は、帯域幅を作り出すのではなく、既存の帯域幅の最適化と、ネットワークを拡張すべきタイミングの理解に役立つツールとしてのみ機能します。当然ながら、適切なネットワークプランニングの代わりになるものではなく、既存のリソースの効率的な使用を支援するためのツールです。


LSPの帯域幅急増に対するプランニング

一般に、LSPの adjust-intervalは、数時間や数日など比較的長い期間に設定します（この例では、7200秒（2時間）に設定）。その期間に LSP上のトラフィックが急増し、輻輳やパケットロスが生じる可能性もあります。通常、これが何時間も続くような状況は許容できません。adjust-threshold-overflow-limit機能は、このような状況に対処するよう設計されています。以下の出力では、lagavulin-to-oban LSPにこの追加設定が行われています。[edit protocols mpls]ps@lagavulin# showstatistics { file auto-bw; interval 600; auto-bandwidth;}label-switched-path lagavulin-to-oban { to 10.200.86.3; auto-bandwidth { adjust-interval 7200; adjust-threshold 20; minimum-bandwidth 64k; maximum-bandwidth 150m; adjust-threshold-overflow-limit 2; } primary via-blair;}

この LSPの adjust-threshold-overflow-limitは、2回分のMPLS統計期間に設定されています。adjust-threshold-overflow-limitを設定すると、MPLS統計の各測定期間（この例では 600秒）ごとに、LSPで以下の状態が確認されます。

� この期間における LSPの平均帯域幅使用量が現在の最大平均帯域幅使用量を超えたか

� 最大平均帯域幅使用量の変化が、設定されている adjust-thresholdを超えたか

これらの状態は簡単には理解できないため、例を使用して考えてみましょう。auto-bandwidthを設定すると、show mpls lsp name <lsp-name> detail出力に LSPの最大平均帯域幅が示されます（以下の出力を参照）。以下の例では、現在のMax AvgBW util値は 90.4Mbpsです。MPLS統計期間が終了するたびに、LSPの予約帯域幅（以下の例では 25.7Mbps）とその期間におけるMax AvgBW util値が比較され、Max AvgBW utilの方が LSP帯域幅より大きい場合、ポイント（1）は真になります。Max AvgBW utilの変化が調整しきい値（この例では 20%）を超えた場合、ポイント（2）も真になります。


10.200.86.3 From:10.200.86.7, State:Up, ActiveRoute:0, LSPname: lagavulin-to-oban ActivePath: via-blair (primary) LoadBalance:Random Autobandwidth MinBW:64kbps MaxBW:150Mbps AdjustTimer:7200 secs AdjustThreshold:20%


Max AvgBW util:90.4322Mbps, Bandwidth Adjustment in 6423 second(s). Overflow limit:2, Overflow sample count:0 Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary via-blair State:Up Priorities:7 0 Bandwidth:25.6762Mbps

前述の状態（1）および（2）が真になった場合、サンプルは帯域幅オーバーフローサンプルと見なされます。adjust-threshold-overflow-limitステートメントでは、連続したオーバーフローサンプル数の制限を設定できます。この制限に達すると、LSPの現在の adjust-intervalタイマーが期限切れになり、LSPで帯域幅が調整されます。調整が行われると、adjust-intervalタイマーは再びゼロから開始します。

adjust-intervalと adjust-threshold-overflow-limitの違いを理解しておくことが重要です。adjust-intervalは、比較的長い期間に渡るなだらかな帯域幅の増減に対処する場合に最適です。一方、adjust-threshold-overflow-limitは、比較的短期間での帯域幅要件の激的な増加に対処する場合に最適です。

注本書の執筆時点では、adjust-threshold-overflow-limitでは、LSPの割り当て帯域幅の増加のみが可能です。帯域幅の急減に基づいて LSPの割り当て帯域幅を減少させることはできません。LSPの縮小は、各 adjust-interval期間の終了時に必要に応じて行われます。

Most-fill/least-fill/random

同じ宛先への等コストパスが複数存在する場合、パス上のリンクで使用可能な帯域幅と、そのリンクで予約可能な総帯域幅の比率に基づいて、明示的CSPF（Constrain Shortest Path First – LSPのパスを決定するためのアルゴリズム）タイブレーカーを設定することができます。LSPの RRO（LSPが経由する必要のあるルーターが順番に並べられたリスト）に保持できるパスは 1つのみのため、タイブレーク方法が必要になります。タイブレークオプションにはmost-fill、least-fill、および randomがあります。使用可能な帯域幅と予約可能な帯域幅がそれぞれ異なるLSPパスの候補が、各リンクで使用可能な帯域幅を予約可能な帯域幅で除算した比率によって比較されます。リンクの使用可能 /予約可能の比率は使用可能帯域幅比率と呼ばれます。 available bandwidth ratio = (available bandwidth)/(reservable bandwidth)

show rsvp interfaceの出力には、インタフェースの使用可能帯域幅と予約可能帯域幅が表示されます。

[edit protocols mpls]ps@dalwhinnie# run show rsvp interfaceRSVP interface:2 active Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markge-0/0/2.0 Up 1 100% 1000Mbps 850Mbps 150Mbps 150Mbps

ge-0/0/3.0 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

上記の dalwhinnieの ge-0/0/2.0の出力例には、ge-0/0/2.0について、予約帯域幅が 150Mbps、使用可能帯域幅が 850Mbps、RSVP予約可能帯域幅（出力では static BW）が 1000Mbpsとして示されています。これらの値から、インタフェース ge-0/0/2.0の使用可能帯域幅比率は 850Mbps/1000Mbps、すなわち 0.85です。[protocols rsvp]階層で帯域幅値を指定することにより、RSVPプロトコルがインタフェースで予約できる帯域幅を制限することができます。以下の出力では、dalwhinnie.ge-0/0/2.0でのRSVP予約帯域幅が500Mbpsに制限されています。

dalwhinnie.ge


[edit protocols rsvp]ps@dalwhinnie# show interface ge-0/0/2.0bandwidth 500m;link-protection;

[edit protocols]ps@dalwhinnie# run show rsvp interface ge-0/0/2.0 Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markge-0/0/2.0 Up 1 100% 500Mbps 350Mbps 150Mbps 150Mbps

この出力から、静的帯域幅がどのように 1000Mbps（static BWのデフォルト値はインタフェースの物理帯域幅）から 500Mbpsに変更されたかがわかります。この例では、この変更により、ge-0/0/2.0の使用可能帯域幅比率が350Mbps/500Mbps（0.70）に変化しています。表 1.2に、各 CSPFタイブレーカー方法とそれに伴う一般的なネットワーク動作を示します。

表 1.2 Most-fill/least-fill/randomの動作

オプション一般的な動作

most-fill

使用率が最も高い（すなわち、使用可能な帯域幅が最も少なく、使用帯域幅比率が最も低い）リンクを含む LSPパスが優先的に使用されます。これにより、一般には、最も使用されていないリンクを消費する前に、特定量のトラフィックを転送しているリンクがいっぱいの状態に近づきます。注：特定パスの最低使用可能帯域幅比率は、そのパス上にあるいずれかのリンクに属する 1つの最低使用可能帯域幅比率です。これは、理解しておかなければならない重要なポイントです。most-fillでは、パス上で帯域幅比率が最低の単一リンクによってパスが決定されます。

least-fill使用率が最も低い（使用可能な帯域幅がより多く、使用可能帯域幅比率がより高い）リンクを含むLSPパスが優先的に使用されます。これにより、一般には、トラフィックがより均等にネットワーク全体に分配されます。

random等コストパスのいずれかがランダムに選択されます。等コストパスに十分な予約可能帯域幅がある限り、そのパスは、トラフィックが追加される候補になります。これはデフォルト設定です。

CSPF等コストタイブレーカーは、[edit protocols mpls <lsp-name>]階層レベルで設定します。例えば、lagavulinの lagavulin-to-obanおよび lagavulin-to-oban-prime LSPには、most-fillが設定されています。これにより、このルーターは、使用可能帯域幅比率が最も低いリンクを含むパスを、そのインタフェースがいっぱいになるまで使用します。 [edit protocols mpls]ps@lagavulin# show ... ... label-switched-path lagavulin-to-oban { to 10.200.86.3; most-fill; auto-bandwidth { adjust-interval 7200;


adjust-threshold 20; minimum-bandwidth 64k; maximum-bandwidth 150m; adjust-threshold-overflow-limit 2; } primary via-blair;}label-switched-path lagavulin-to-oban-prime { to 10.200.86.3; bandwidth 150m; most-fill; auto-bandwidth { adjust-interval 86400; } primary via-talisker;} ... ... ...

ヒント CSPFタイブレーカーとしてmost-fill/least-fill/randomを使用するときは、一般にベストプラクティスとして、ネットワーク上のすべての LSPに対して 1つの方法のみを使用することをお奨めします。

LSPの CSPFタイブレーカー方法は、show mpls lsp <lsp-name> detail操作コマンドの詳細な出力を調べることにより確認できます。


10.200.86.3 From:10.200.86.7, State:Up, ActiveRoute:1, LSPname: lagavulin-to-oban ActivePath: via-blair (primary) LoadBalance:Most-fill Autobandwidth MinBW:64kbps MaxBW:150Mbps AdjustTimer:7200 secs AdjustThreshold:20%

ヒント多数またはすべての LSPに共通の多数のオプションや機能を設定しようとすると、大変な作業になる可能性があります。Junosのグループ（テンプレートの一種）を使用すると、選択した LSPに共通の設定を適用できるため、この設定作業が簡素化されます。以下の例では、auto-bandwidth属性をすべてのLSPに適用しています。

[edit]ps@lagavulin# show## Last changed:2011-02-15 02:41:30 UTCversion 10.0R3.10;groups { LSP-ATTRIBUTES { protocols { mpls { label-switched-path <*> { auto-bandwidth { adjust-interval 7200; adjust-threshold 20; minimum-bandwidth 64k; maximum-bandwidth 150m; } } } }


}}apply-groups LSP-ATTRIBUTES; ... ...

[edit]ps@lagavulin# show protocols mplsstatistics { file auto-bw; interval 600; auto-bandwidth;} ... ... label-switched-path lagavulin-to-dalwhinnie { to 10.200.86.5;} ... ...

[edit]ps@lagavulin# show protocols mpls | display inheritancestatistics { file auto-bw; interval 600; auto-bandwidth;} ... ... label-switched-path lagavulin-to-dalwhinnie { to 10.200.86.5; ## ## 'auto-bandwidth' was inherited from group 'LSP-ATTRIBUTES' ## auto-bandwidth { ## ## '7200' was inherited from group 'LSP-ATTRIBUTES' ## adjust-interval 7200; ## ## '20' was inherited from group 'LSP-ATTRIBUTES' ## adjust-threshold 20; ## ## '64k' was inherited from group 'LSP-ATTRIBUTES' ## minimum-bandwidth 64k; ## ## '150m' was inherited from group 'LSP-ATTRIBUTES' ## maximum-bandwidth 150m; }} ... ...

[edit]ps@lagavulin# run show mpls lsp name lagavulin-to-dalwhinnie detailIngress LSP:5 sessions


10.200.86.5 From:10.200.86.7, State:Up, ActiveRoute:1, LSPname: lagavulin-to-dalwhinnie ActivePath:(primary) LoadBalance:Random Autobandwidth MinBW:64kbps MaxBW:150Mbps AdjustTimer:7200 secs AdjustThreshold:20% Max AvgBW util:112bps, Bandwidth Adjustment in 216 second(s). Overflow limit:0, Overflow sample count:0 Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary State:Up Priorities:7 0 Bandwidth:64kbps SmartOptimizeTimer:180

LSPの設定を調べるときに、CLIの showコマンドに | display inheritanceを追加しないと、グループによって適用された設定が表示されません。show mpls lsp出力により、lagavulin-to-dalwhinnie LSPの属性がグループの適用によって設定されていることがわかります。

さらに詳しくは Junosのグループに関する詳細な説明は本書の範囲外です。Junosのこの機能に関する詳細は、Day Oneブックレット『Junosの基本設定』に記載されています。無料のダウンロード版は、www.juniper.net/dayoneから入手できます。また、電子書籍版は、Amazonおよび Appleの iBookstoreから入手できます。

まとめこの章では、MPLSコアネットワークの概念とさまざまな特性について簡単に説明しました。コアで提供される各概念についてすべてを説明しているわけではありませんが、LDPとRSVPの違い、LDPとは何か、各 RSVP LSPフェイルオーバー手法のオプションとトレードオフ、トラフィック制御および LDPの帯域幅管理のためのさまざまな手法、各概念の基本的な設定についての基礎知識は身に付いたかと思います。

それでは、ネットワークコアにおけるMPLSの概念についてこれまでに習得した知識を基に、第 2章に進みましょう。第 2章では、次の論理的ビルディングブロックであるMPLSサービスの概念について説明します。


第2章

MPLSサービスの概要

はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

レイヤー3 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

レイヤー2 MPLS VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98


MPLSサービスは、MPLSコアの機能を活用することにより、ネットワークユーザーに追加リソースを提供します。MPLSサービスには、レイヤー 3 VPN（L3VPN）、レイヤー 2 VPN（L2VPN）、および VPLSの 3つの主要カテゴリがあります。この章では、これら 3つの各サービスについて機能と基本メカニズムを説明します。

はじめに一般に、MPLSサービスのシナリオには、カスタマーエッジ、プロバイダエッジ、およびプロバイダコアの3種類のルーターが存在します。カスタマーエッジ（CE）ルーターは、エンドユーザーが直接接続するルーターで、特定のユーザー群または特定サイトのユーザーのトラフィックを集約します。CEはプロバイダエッジ（PE）ルーターに接続します。PEは、複数の CEから送信されたトラフィックを集約し、適切な QoS（CoS）処理を適用し、データをユーザー間で論理的に区別して、プロバイダコア（P)ルーターに送信する役割を担います。

図 2.1に示すように、一般に、PEルーターには受信 LSPと送信 LSPがありますが、トランジット LSPはありません（通常、トランジット LSPの管理は Pルーターの役割）。PルーターはMPLSバックボーンルーターであり、特定PEから宛先PEにデータを配信するためのMPLSバックボーン機能を提供します。すなわち、一般的には、主に、宛先 PEへの配信パスが通る、LSPのコンジットのような役割を果たします。宛先 PEは、ルーター内の適切な論理セグメントにデータを配置し、適切な CoS処理を適用して、データを CEに引き渡します。

PE PE P

CE カスタマーエッジPE プロバイダエッジ

VRF VPNルーティング/フォワーディングテーブル VPN バーチャルプライベートネットワーク

P プロバイダコア

VRF

CE

CE

サイト

サイト

CE

CE

サイト

サイト

VPN

VPN

カスタマーサービスプロバイダカスタマー

VRF VRF VRF

G G

R R

図 2.1 VPNルーターの役割

図 2.2は、CEルーター、PEルーター、および Pルーターで構成される一般的なネットワークの構成です。この章では、この図を出発点としてMPLSサービスについて説明していきます。ネットワークの規模、ユーザー要件、成長の可能性、その他多数の要因によっては、一部のルーターの役割が組み合わされることも珍しくありませ

第2章：MPLSサービスの概要 69

ん。そのよくある例として、1台のルーターで PEルーターとPルーターの両方の役割を担うことがあります。このようなネットワークアーキテクチャの決定については、第3章で説明します。ネットワークの規模と要件により、図2.2のPEルーターは、トランジット LSPのパスとして機能しているという点で、Pルーターの一部の役割も果たしています。

CE2

CE1

CE3

CE4

CE5

PE1

PE2

PE3

PE4

P1 P2

P3

P4

P5

図 2.2 一般的なMPLSシナリオの構成

レイヤー 3 VPN

レイヤー 3 VPN（L3VPN）では、一般のインターネットトラフィックやその他VPNトラフィックにさらされることなく、一連のユーザーグループがMPLSコアを通してレイヤー 3で通信するための手段が提供されます。レイヤー 3 VPNは、共通のルーティング情報を共有するサイトのグループで構成され、サイトとの接続性は一連のポリシーによって制御されます。L3VPNの基本となるのがバーチャルルーティングおよび転送（VRF）インスタンスです。分かりやすく言えば、VRFは PEルーター内の論理セグメントであり、ここに、CE側のインタフェース、バーチャルルーティングテーブル、接続性を制御するポリシーが存在します。また、PEルーターとCEルーター間で実行されるプロトコルもVRFルーティングインスタンス（以下、VRF）に設定されます。図 2.3は、それぞれ独自のルーティングテーブルを持つ 3つの VRFで構成される PEルーターを仮想的に表したものです。各 VRFのルーティングテーブルには、その VRFのルートのみが保持されます。Junosでは、各VRFのルーティングテーブルに <routing-instance name>.inet.0という名前が付けられます。

さらに詳しくは L3VPNは、IETF RFC 4364に基づいています。詳細については、http://tools.ietf.org/html/rfc4364を参照してください。


CE

PEはvrfルーティングインスタンスに区分され、vrfルーティングインスタンスごとに専用のルーティングテーブルとCE対向インタフェースが用意されています。

vrf1 vrf1.inet.0 vrf1 ポリシー

Pルーターへのリンク

vrf3 vrf3.inet.0 vrf 3 ポリシー

vrf2 vrf2.inet.0

vrf2 ポリシー

CE

inet.0 inet.0 テーブル

inet.0 policies

CE

bgp.l3vpn.0

図 2.3 VRFの論理構成図

L3VPNの制御プレーン

異なる PEルーター上にある共通の VRFは、マルチプロトコル BGP（MP-BGP）によって相互にルートを交換し合います。具体的には、family inet-vpn設定を使用して、NLRIをアドバタイズしたり受信したりします。inet-vpnの設定は、L3VPN NLRIの送信と受信を必要とするグループおよび隣接機器に応じて、[edit protocols bgp]、[edit protocols bgp group <group-name>]、または [edit

protocols bgp group <group-name> neighbor <neighbor-id>]階層で行えます。ps@dalwhinnie> show configuration protocols bgpfamily inet { any;}family inet-vpn { any;}

一般的には、VRFインスタンスが存在する PEルーターは、その VRFのルーティングテーブルをMP-BGPピアにアドバタイズします。各 VRFのプレフィックスは、VRF固有のルート識別子（RD）によって一意性が保たれます。異なるVRFにはそれぞれ RD値が必要です。VRFのルートの先頭に RDが付けられるため、ルートリフレクタによって iBGP隣接機器にアドバタイズおよび再アドバタイズされるときにも、各プレフィックスは固有のままになります。このように、それぞれに付加される固有の RDによって各プレフィックスの一意性が保たれるため、異なるVRFの複数のユーザーグループが重複したアドレススキームを使用することができます。L3VPNルートを受信するPEルーターは、bgp.l3vpn.0ルーティングテーブルでそのルートを受け入れます。このテーブルには、他の PEルーターから受信したすべての VPN-IPv4ユニキャストルートが保存されます。ルートがローカルルーターのVRFで受け入れられると、RDが削除され、ルートがローカル VRFルーティングテーブルに配置されます。

RDの役割を理解するには、例を使用するのが最も効果的です。ここでは、図 2.4に示す L3VPN構成の例を調べてみましょう。図 2.4では、CE1および CE5ルーターが spruce L3VPNにあり、CE2、CE3、および CE4 ルーターが aspen L3VPN にあります。dalwhinnie は、2 つの172.17.0.0/24インスタンスと、192.168.90.12/30および 192.168.90.16/30の 4つのルートを bgp.l3vpn.inet.0テーブルで受信します。ここで、CE4および CE5がどちらも 172.17.0/24をそれぞれの PEルーターにアドバタイズしていることに注意してください。


CE2 (aspen )

CE1 (spruce)

CE3 (aspen)

CE4 (aspen)

CE5 (spruce)

ge-0/0/1.800 192.168.90.1/30

ge-0/0/1.801 192.168.90.5/30

ge-0/0/1.803 192.168.90.13/30

ge-0/0/1.804 192.168.90.17/30

172.17.0/24eBGP経由でobanへ

tormore (PE) lo0 10.200.86.9

mortlach (P) lo0 10.200.86.2

glenlivet (P) lo0 10.200.86.6

lagavulin (PE) lo0 10.200.86.7

blair (P) lo0 10.200.86.1

dalwhinnie (PE) lo0 10.200.86.5

oban (PE) lo0 10.200.86.3

macduff (P) lo0 10.200.86.8

talisker (P) lo0 10.200.86.4

172.17.0/24eBGP経由でtomoreへ

各CE名の下に丸括弧付きで示されているのはL3VPNの名前であり、それぞれのPEで接続する対象です。

図 2.4 L3VPNサービスが実行されているMPLSネットワーク

以下に示す出力は、dalwhinnieの bgp.l3vpn.0ルーティングテーブルです。 ps@dalwhinnie> show route table bgp.l3vpn.0

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

192.168.90.14:20:172.17.0.0/24 *[BGP/170] 2d 13:53:39, localpref 100, from 10.200.86.3 AS path:65432 I > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path dalwhinnie-to-oban192.168.90.14:20:192.168.90.12/30 *[BGP/170] 2d 13:53:39, localpref 100, from 10.200.86.3 AS path:I > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-oban to 192.168.86.29 via ge-0/0/3.0, label-switched-path dalwhinnie-to-oban192.168.90.18:30:172.17.0.0/24 *[BGP/170] 00:02:01, localpref 100, from 10.200.86.9 AS path:65433 I > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-tormore192.168.90.18:30:192.168.90.16/30 *[BGP/170] 2d 13:54:27, localpref 100, from 10.200.86.9 AS path:I > to 192.168.86.5 via ge-0/0/2.0, label-switched-path dalwhinnie-to-tormore

2つの 172.17.0.0/24ルートのルート識別子はそれぞれ異なるため、このテーブル内でこれらのルートの一意性が保たれています（192.168.90.14:20と192.168.90.18:30）。これにより、172.17.0.0/24ルートを bgp.l3vpn.0テーブルに配置したときに、各ルートは実質的にそれぞれ固有のものになります。

この時点では、dalwhinnieの bgp.l3vpn.0テーブルには、他の PEルーターから受信している 4つの VPN-IPv4ルートがあります。それでは、dalwhinnieに設定されている 2つの L3VPNルーティングインスタンスは、どのルートをインポー


トするかをどのように判断するのでしょうか。ルーティングインスタンスでは、この判断を行うために、ルートターゲット（RT）が使用されます。

以下に示す設定は、L3VPNルーティングインスタンスの非常に基本的な設定です。ps@dalwhinnie> show configuration routing-instancesaspen { instance-type vrf; interface ge-0/0/1.801; route-distinguisher 192.168.90.6:20; vrf-target target:100:200; vrf-table-label; protocols { bgp { group ce2 { neighbor 192.168.90.6 { peer-as 65432; } } } }}spruce { instance-type vrf; interface ge-0/0/1.800; route-distinguisher 192.168.90.2:30; vrf-target target:100:300; vrf-table-label; protocols { bgp { group ce1 { neighbor 192.168.90.2 { peer-as 65433; } } } }}

ルートターゲットは、target:x:y形式の BGP拡張コミュニティです。共通の VRFを持つサイト間の通信を制御するポリシーでは、通常、ルートに付加されたルートターゲットに基づいて、プレフィックスを許可または拒否することができます。この設定では、ルーティングインスタンス aspenは、ルートターゲット値が target:100:200

のルートを探し、spruceは、ルートターゲット値 target:100:300のルートを探します。以下に示す 172.17.0/24ルートの show route detail出力を見れば、このことがよく分かります。

ps@dalwhinnie> show route 172.17.0.0/24 detail

aspen.inet.0:4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)172.17.0.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Route Distinguisher:192.168.90.14:20 ... ... ... Communities: target:100:200 Import Accepted VPN Label:16 Localpref:100 Router ID:10.200.86.3 Primary Routing Table bgp.l3vpn.0

spruce.inet.0:4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)


172.17.0.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Route Distinguisher:192.168.90.18:30 ... ... ... Communities: target:100:300 Import Accepted VPN Label:16 Localpref:100 Router ID:10.200.86.9 Primary Routing Table bgp.l3vpn.0

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

192.168.90.14:20:172.17.0.0/24 (1 entry, 0 announced) *BGP Preference:170/-101 Route Distinguisher:192.168.90.14:20 ... ... ... Communities: target:100:200 Import Accepted VPN Label:16 Localpref:100 Router ID:10.200.86.3 Secondary Tables: aspen.inet.0

192.168.90.18:30:172.17.0.0/24 (1 entry, 0 announced) *BGP Preference:170/-101 Route Distinguisher:192.168.90.18:30 ... ... ... Communities: target:100:300 Import Accepted VPN Label:16 Localpref:100 Router ID:10.200.86.9 Secondary Tables: spruce.inet.0

この出力から、以下のことが分かります。 � aspen VRFは、ルートターゲット target:100:200の 172.17.0/24ルートを受け入れて、aspen.inet.0にインストールする

� spruce VRFは、ルートターゲット target:100:300の 172.17.0/24ルートを受け入れて、spruce.inet.0にインストールする

� bgp.l3vpn.0テーブルでは、ルートの空間が重複していても、ルート識別子（RD）によってルートの一意性が保たれる � bgp.l3vpn.0からどのルートを受け入れてローカル VRFのルーティングテーブルに配置するかは、ルートターゲット（RT）によって決められる

注 VRFルーティングインスタンス名がローカルでのみ意味を持つことに注意してください。L3VPNにおけるVRFのメンバーシップは、名前ではなく、それに関連付けられた RTとインポート /エクスポートポリシーによって決まります。ただし、ベストプラクティスとして、特定の L3VPNに対してすべてのルーターで共通のインスタンス名を付けることをお奨めします。


RTとRDの役割は混同しやすいため、時間をかけてこれらの点について理解しておいてください。L3VPNについて完全に理解するには、これら（上記リストの最後の 2つ）の違いを理解することが不可欠です。

L3VPNの転送プレーン

これで、MP-BGP、RT、および RDと、これらが L3VPNルート配信にどのように影響するかを理解できました。それでは、L3VPNトラフィックがどのように送信元CEから配信パス上にある受信 PE、コア、送信 PEを経て宛先 CEまで移動するかを見ていきましょう。CE2ルーターは、dalwhinnieとの eBGPセッションによって受信したCE4ルーターの 192.168.90.14アドレスにパケットを送信しようとしています（前の図2.4を参照）。以下の show route detail出力には、L3VPN転送プレーンの動作について豊富な情報が示されています。

ps@dalwhinnie> show route advertising-protocol bgp 192.168.90.6

aspen.inet.0:4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.90.12/30 Self I

ps@dalwhinnie> show route 192.168.90.14 table aspen detail

aspen.inet.0:4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)192.168.90.12/30 (1 entry, 1 announced) *BGP Preference:170/-101 Route Distinguisher:192.168.90.14:20 Next hop type:Indirect Next-hop reference count:6 Source:10.200.86.3 Next hop type:Router, Next hop index:262147 Next hop:192.168.86.5 via ge-0/0/2.0 weight 0x1, selected Label-switched-path dalwhinnie-to-oban Label operation:Push 16, Push 301328(top) Next hop:192.168.86.29 via ge-0/0/3.0 weight 0x8001 Label-switched-path dalwhinnie-to-oban Label operation:Push 16, Push 301328, Push 301552(top) Protocol next hop:10.200.86.3 Push 16 Indirect next hop:8dfd210 262148 State:<Secondary Active Int Ext> Local AS:7176 Peer AS:7176 Age:3d 21:32:59 Metric2:3 Task:BGP_7176.10.200.86.3+65455 Announcement bits (2):0-BGP RT Background 1-KRT AS path:I Communities: target:100:200 Import Accepted VPN Label:16 Localpref:100 Router ID:10.200.86.3 Primary Routing Table bgp.l3vpn.0

この出力から以下のことが分かります。 � dalwhinnieが CE2ルーターに 192.168.90.12/30ルートをアドバタイズしている

� dalwhinnie-to-oban LSPは、aspen.inet.0テーブルに保持されている、このルートの dalwhinnieのネクストホップである


� 選択されたパスは、dalwhinnie-to-oban LSPのプライマリパスである（示されているその他のパスは、この LSPのフェイルオーバーパス）

� コアへの送信時に、2つのラベル 16および 301328（ラベルスタックは 2つのラベルで構成）がパケットに追加される（301328がスタックのトップラベル）

転送プレーンについて理解するには、ローカルルーターが認識しているすべてのラベルとそのラベルに関連付けられたネクストホップのリストであるmpls.0テーブルの使用方法を理解しなければなりません。

上記の出力において、301328はスタックのトップラベルであるため、ネクストホップルーターはこのラベルに基づいて動作します。上記の出力には、パケットが、glenlivet側の ge-0/0/2.0インタフェースを通して dalwhinnieから送信されることも示されています。確認してみましょう。

ps@glenlivet> show route table mpls.0 label 301328 detail

mpls.0:44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)301328 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router Next-hop reference count:1 Next hop:192.168.86.9 via ge-0/0/1.0 weight 0x1, selected Label-switched-path dalwhinnie-to-oban Label operation:Swap 301248 Next hop:192.168.86.45 via ge-0/0/3.0 weight 0x8001 Label-switched-path Bypass->192.168.86.9 Label operation:Swap 301248, Push 299920(top) State:<Active Int> Local AS:7176 Age:6d 22:34:58 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

また、glenlivetのmpls.0テーブルには、ラベル 301328を持つパケットを受信した場合に以下のアクションを実行することが示されています。

� 301328ラベルを 301248ラベルと交換する � dalwhinnie-to-oban LSPでパケットを送信する � インタフェース ge-0/0/1.0からblairルーターにパケットをルーティングする

blairのmpls.0テーブルを調べると、ラベル 301248のパケットを受信した場合に、そのラベルをポップ（削除）し、dalwhinnie-to-oban LSPでパケットをge-6/0/0.0から obanにルーティングすることが示されています。

ps@blair> show route table mpls.0 label 301248 detail

mpls.0:52 destinations, 52 routes (52 active, 0 holddown, 0 hidden) ...<truncated for brevity> ... 301248 (S=0) (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router Next-hop reference count:1 Next hop:192.168.86.25 via ge-6/0/0.0 weight 0x1, selected Label-switched-path dalwhinnie-to-oban Label operation:Pop Next hop:192.168.86.17 via ge-0/0/3.0 weight 0x8001 Label-switched-path Bypass->192.168.86.25 Label operation:Swap 299920 State:<Active Int> Local AS:7176


Age:6d 22:39:40 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

注 mpls.0テーブルの (S=0)エントリーは、ラベルスタック深さ n>=2でルーターに着信したパケットが、ラベルスタック深さn-1でルーターから送信されることを示します。情報に S=0ラベルが含まれていない場合、ラベルスタック深さ 1でルーターに着信したパケットが、ラベルなしの状態でルーターから送信されることを示します。上記の例では、パケットはスタック深さ n=2でルーターに着信しています。

パケットが obanに到着したときには、スタックには、値 16のラベルのみが残されています。以下の出力には、obanが値 16のラベルを受信した場合に、そのラベルをポップし、ルーティングルックアップのため aspen.inet.0テーブルに転送することが示されています。

ps@oban> show route table mpls.0 label 16

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

16 *[VPN/0] 4d 17:56:27 to table aspen.inet.0, Pop

ps@oban>

パケットは、aspen.inet.0テーブルに転送されると、ge-0/0/1.803インタフェースからCE4ルーターに向けてルーティングされます（PEおよび Pルーターでのラベル交換は、CE2および CE4ルーター上のユーザーに対して透過的）。

ps@oban> show route 192.168.90.14 table aspen detail

aspen.inet.0:4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)192.168.90.12/30 (1 entry, 1 announced) *Direct Preference:0 Next hop type:Interface Next-hop reference count:1 Next hop: via ge-0/0/1.803, selected State:<Active Int> Age:5d 18:11:12 Task:IF Announcement bits (1):1-BGP RT Background AS path:I

図 2.5に、dalwhinnieから始まりobanで終わる、前述のラベルの操作を示します。



ge-0/0/2 ge-0/0/1 ge-6/0/0 ge-0/0/2 ge-0/0/1.801 192.168.90.5/30

CE 2 CE 4

ge-0/0/1.803 192.168.90.13/30

blair lo0 10.200.86.1

oban lo0 10.200.86.3

パケットパケット

16

301328

パケット

16

301248

パケット

16

パケット

CEのインタフェース名は示されていません。



図 2.5 RSVPによる L3VPNサービスのエンドツーエンドのラベル操作


レイヤー 2 MPLS VPN

レイヤー 2 MPLS バーチャルプライベートネットワーク（VPN）では、MPLSネットワークでレイヤー 2データをポイントツーポイントで転送する手段が提供されます。MPLSによる転送は、CEルーターのエンドユーザーに対して透過的です。すなわち、いずれかのサーキットで接続された 2つの CEルーターからは、リモート IPアドレスが直接接続されているように見えます。レイヤー 2 VPNには、シグナリングが BGPによって行われるものと（l2vpn）、LDPによって行われるもの（l2circuit）の 2つのタイプがあります。

L2VPN

l2vpn接続（Kompellaトンネルとも呼ばれる）は、2台の PEルータ上のルーティングインスタンス内にプロビジョニングされます。以下に示す lagavulinの l2vpn設定には、l3vpn設定との類似点が多数あります。

� ルーティングインスタンスに参加する interface

� route-distinguisher

� vrf-target

注 l2vpnは、draft-kompella-l2vpn-l2vpn-00.txtに基づいています。詳細については、http://tools.ietf.org/html/draft-kompella-l2vpn-l2vpn-00を参照してください。

これらの要素の機能は l3vpnのものと同じです。図 2.6に、lagavulinルーターとtormoreルーター間の l2vpn接続の構成を示します。

tormore lo0

10.200.86.9

mortlachlo0 10.200.86.2



blair lo0 10.200.86.1


oban lo0 10.200.86.3

macduff lo0 10.200.86.8




.1

.6

.5

.2

.34


ge-0/0/2

ge-0/0/3

.30

.29

ge-0/0/1 .10 .9

.46

.45

ge-0/0/3

ge-0/0/2

ge-0/0/1 .14

fe-0/0/1 .13

fe-2/0/1

ge-0/0/3 .42

.41

ge-0/0/2 .50

ge-0/0/3 .18

fe-2/0/0 .17

ge-6/0/0 .26

.25

ge-0/0/2

ge-0/0/3

.38

.37

fe-2/0/1

.33

ge-0/0/2

e1-1/0/0

.22

fe-0/0/1 fe-2/0/0 .49

.21

ge-0/0/1.802

CE 3

CE 6

ge-0/0/1

.802

fe-0/0/3.802 192.168.90.10/30

fe-0/0/5.802

192.168.90.9/30

図 2.6 L2VPN接続のネットワーク構成


この他、[protocols l2vpn]階層の l2vpnルーティングインスタンスの情報には、encapsulation-type（インスタンスに参加しているインタフェースは VLANタギングを使用しているため ethernet-vlanに設定）および [site]階層が含まれます。[site]階層内の site-identifierはゼロより大きい 16ビット数値で、これによってサイトが VPN内で一意に識別され、サイト間の接続性を制御することができます。例えば、lagavulinインスタンスの 3という site-identifierは、tormoreのremote-site-idに対応しており、6という remote-site-idは、tormoreの site-identifier値に対応しています。

ps@lagavulin> show configuration routing-instances pineinstance-type l2vpn;interface ge-0/0/1.802;route-distinguisher 10.200.86.7:10;vrf-target target:200:100;protocols { l2vpn { encapsulation-type ethernet-vlan; site ce3 { site-identifier 3; interface ge-0/0/1.802 { remote-site-id 6; } } }}

ps@tormore> show configuration routing-instances pineinstance-type l2vpn;interface ge-0/0/1.802;route-distinguisher 10.200.86.9:10;vrf-target target:200:100;protocols { l2vpn { encapsulation-type ethernet-vlan; site ce6 { site-identifier 6; interface ge-0/0/1.802 { remote-site-id 3; } } }}

l2vpnに参加している各 CE側のインタフェースには、特定の設定を適用する必要があります。CE側の物理インタフェースと、そのそれぞれの論理インタフェースには、同じ ccc（Circuit Cross-connect）カプセル化タイプが指定されている必要があります。vlan 512～ 4094は、cccカプセル化用に予約されており、511以下の vlan値は、必要に応じて、通常の VLANタグ付きインタフェースとして使用できます。以下に示す lagavulinの出力例には、ユニット802が l2vpnで動作するように設定され、ユニット400は l3vpnまたはマスタールーティングインタフェースのいずれかに参加できることが示されています。イーサネットベースのインタフェースには、複数の論理ユニットが設定されている場合は VLANタギングが必要です。

ps@lagavulin> show configuration interfaces ge-0/0/1vlan-tagging;encapsulation vlan-ccc;unit 400 { vlan-id 400; family inet { address 192.168.90.17/30;


}}unit 802 { description "to CE3"; encapsulation vlan-ccc; vlan-id 802;}

フレームリレー、PPP、および ATMインタフェースも、cccカプセル化をサポートし、l2vpnで動作するように設定できます。l2vpn接続の各端で異なるカプセル化タイプを使用するには、tcc（Translation Cross-connect）カプセル化を使用する必要があります。

さらに詳しくは PEインタフェースでの cccカプセル化の詳細については、http://www.juniper.net/ techpubs/en_US/junos10.3/topics/usage-guidelines/vpns-configuring-ccc-encapsulation-for-layer-2-vpns.htmlを参照してください。本書の執筆時点では、Junos 10.3が最新の Junosバージョンです。

さらに詳しくは PEインタフェースでの tccカプセル化の使用に関する詳細については、http://www.juniper.net/techpubs/en_US/junos10.3/information-products/topic-collections/config-guide-vpns/index.html?topic-33769.htmlを参照してください。本書の執筆時点では、Junos 10.3が最新の Junosバージョンです。

L2VPNの制御プレーンBGPは l2vpnの制御プレーンとして機能し、l2vpnの NLRIを配信します。この例では、PEルーター間にフルメッシュの iBGP接続が存在しています。l3vpnと同様に、BGPは、このタイプのサーキットに制御プレーンを提供します。これは、lagavulinルーターと tormoreルーターが l2vpn固有の NLRIを交換できなければならないことを意味します。lagavulinの BGP設定には、これがどのように行われるかが示されています。すなわち、l2vpnファミリーにより、このルーターは BGPで l2vpnシグナリング情報を送信および受信することができます。

ps@lagavulin> show configuration protocols bgpfamily inet { any;}family inet-vpn { any;}family l2vpn { signaling;}group ibgp { type internal; local-address 10.200.86.7; ...<snip> ... neighbor 10.200.86.9;}

制御プレーンの動作は、数個の単純なコマンドを使用することで分かります。また、これらのコマンドは、必要に応じてトラブルシューティングのために使用することもできます。以下の例では、tormoreがその l2vpnルートを lagavulinにアドバタイズしています。

ps@tormore> show route advertising-protocol bgp 10.200.86.7 table pine

pine.l2vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.200.86.9:10:6:3/96* Self 100 I

簡単な確認により、lagavulinが確かに tormoreからBGPで l2vpn情報を受信し

http://www.juniper.net/techpubs/en_US/junos10.3/topics/usage-guidelines/vpns-configuring-ccc-encapsulation-for-layer-2-vpns.html



http://www.juniper.net/techpubs/en_US/junos10.3/information-products/topic-collections/config-guide-vpns/index.html?topic-33769.html




ていることが分かります。以下の例では、tormoreの l2vpnインスタンスに設定されているRDが、BGPのルートターゲット拡張コミュニティとともに示されています。

ps@lagavulin> show route receive-protocol bgp 10.200.86.9 table bgp.l2vpn.0 detail

bgp.l2vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)* 10.200.86.9:10:6:3/96 (1 entry, 0 announced) Import Accepted Route Distinguisher:10.200.86.9:10 Label-base:800000, range:2, status-vector:0x0 Nexthop:10.200.86.9 Localpref:100 AS path:I Communities:target:200:100 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu:0, site preference:100

最終的な確認により、tormoreのルートが lagavulin上の pineルーティングテーブルに存在することが分かります。

ps@lagavulin> show route receive-protocol bgp 10.200.86.9 table pine

pine.l2vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.200.86.9:10:6:3/96* 10.200.86.9 100 I

lagavulin上の pine l2vpnインスタンスのルートテーブル全体を調べると、ローカルインタフェースで生成されたエントリーと、tormoreからの BGPによって受信したルートが分かります。また、この出力には、tormoreからのルートのネクストホップ LSPが示されているため、転送プレーンについても知ることができます。

ps@lagavulin> show route table pine

pine.l2vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.200.86.7:10:3:5/96 *[L2VPN/170/-101] 2w4d 23:17:36, metric2 1 Indirect10.200.86.9:10:6:3/96 *[BGP/170] 00:20:07, localpref 100, from 10.200.86.9 AS path:I > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore-v2

l2vpnの転送接続自体のステータスを確認するには、show l2vpn connectionsコマンドを使用します。以下に示すように、このコマンドにより、各 l2vpnについて、接続のステータス、複数のリモートPEルーターのアドレス、ローカルインタフェースのステータス、l2vpnのラベルなど、多くの役立つ情報が出力されます。

ps@lagavulin> show l2vpn connections extensiveLayer-2 VPN connections:

Legend for connection status (St)EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS ...<truncated for brevity> ... PF -- Profile parse failure PB -- Profile busyRS -- remote site standby

Legend for interface statusUp -- operationalDn -- down


Instance: pine Local site: ce3 (3) Number of local interfaces:1 Number of local interfaces up:1 ge-0/0/1.802 6 Label-base Offset Size Range Preference 800000 5 2 2 100 status-vector:0 connection-site Type St Time last up # Up trans 6 rmt Up Aug 24 04:50:31 2010 1 Remote PE:10.200.86.9, Negotiated control-word:Yes (Null) Incoming label:800001, Outgoing label:800000 Local interface: ge-0/0/1.802, Status:Up, Encapsulation:VLAN Connection History: Aug 24 04:50:31 2010 status update timer Aug 24 04:50:30 2010 PE route changed Aug 24 04:50:30 2010 Out lbl Update 800000 Aug 24 04:50:30 2010 In lbl Update 800001 Aug 24 04:50:30 2010 loc intf up ge-0/0/1.802

注一見すると、l2vpnルートを理解するのは大変なように思えます。簡単に言えば、最初の 2つの部分（例では 10.200.86.9:10および :6）は、ルートをアドバタイズしているルーターに設定されているRDと、アドバタイズメントの送信元のサイトIDです。最後の部分（:3）は、ラベルオフセットです（このオフセットは自動的に生成され、VPNラベルを生成するために内部で使用）。/96は、96ビットアドレスのネットマスクがすべて 1であることを示します。l2vpnルートの各部分の詳細については、http://tools.ietf.org/html/draft-kompella-l2vpn-l2vpn-00を参照してください。

L2VPNの転送プレーンl3vpnと同様に、転送プレーンを調べることにより、l2vpnにおけるトラフィックのラベル操作を理解することができます。前に示した lagavulinの show l2vpn

connectionsの出力には、接続の送信ラベルが 800000として示されていました。これは、tormore宛てのパケットにプッシュされる最初のラベルです。l2vpnインスタンスのルーティングテーブルを詳しく調べると、tormoreからこのルートに向かうトラフィックでは、lagavulin-to-tormore LSPが使用されています。

ps@lagavulin> show route table pine

pine.l2vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.200.86.7:10:3:5/96 *[L2VPN/170/-101] 2w5d 22:06:26, metric2 1 Indirect10.200.86.9:10:6:3/96 *[BGP/170] 23:08:57, localpref 100, from 10.200.86.9 AS path:I > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore-v2

LSPの RSVPセッションを調べると、送信ラベルは 302160です。ps@lagavulin> show rsvp session lsp name lagavulin-to-tormore detailIngress RSVP:10 sessions

10.200.86.9 From:10.200.86.7, LSPstate:Up, ActiveRoute:0

http://tools.ietf.org/html/draft-kompella-l2vpn-l2vpn-00


LSPname: lagavulin-to-tormore, LSPpath:Primary Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:302160 Resv style:1 FF, Label in:-, Label out:302160 Time left: -, Since:Thu Aug 5 23:50:59 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 34752 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.1 (ge-0/0/2.0) 36871 pkts RESV rcvfrom:192.168.86.1 (ge-0/0/2.0) 36848 pkts Explct route:192.168.86.1 192.168.86.13 192.168.86.33 Record route:<self> 192.168.86.1 192.168.86.13 192.168.86.33Total 1 displayed, Up 1, Down 0

つまり、パケットは、800000と302160のラベルスタックで tormoreから送信されます（800000はスタックのボトムラベル）。パスの次のルーターを見てみましょう。macduffは 302160ラベルを検出すると、taliskerに向かう lagavulin-to-tormore LSPで ge-0/0/1.0からパケットを送信する前に、このラベルを 300144に交換します。

ps@macduff> show route table mpls.0 label 302160 detail

mpls.0:35 destinations, 35 routes (35 active, 0 holddown, 0 hidden)302160 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:561 Next-hop reference count:3 Next hop:192.168.86.13 via ge-0/0/1.0 weight 0x1, selected Label-switched-path lagavulin-to-tormore Label operation:Swap 300144

taliskerは、300144ラベルを検出するとポップ操作を実行し、パケットをlagavulin-to-tormore LSPで fe-2/0/1.0インタフェースから送信します。

ps@talisker> show route table mpls.0 label 300144 detail

mpls.0:43 destinations, 43 routes (43 active, 0 holddown, 0 hidden) ...<truncated for brevity> ... 300144 (S=0)(1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:592 Next-hop reference count:2 Next hop:192.168.86.33 via fe-2/0/1.0 weight 0x1, selected Label-switched-path lagavulin-to-tormore Label operation:Pop ...<truncated for brevity> ...

talisker（最後から 2番目のルーター）によってトップラベルがポップされたため、パケットのラベルスタックには 800000ラベルのみが残されています。最後のルーターである tormoreは、このラベルを読み取り、そのラベル値に基づいてパケットを pineルーティングインスタンスに割り当てます。taliskerは、残りの 800000ラベルをポップし、ge-0/0/1.802から宛先の CE6に向けて送信します。

ps@tormore> show route table mpls.0 label 800000



800000 *[L2VPN/7] 23:59:23 > via ge-0/0/1.802, Pop Offset:4

図 2.7に、これらの l2vpn転送プレーンの動作を示します。

macduff lo0 10.200.86.8


ge-0/0/2 ge-0/0/1 fe-2/0/1 ge-0/0/1.802

CE 3 CE 6

ge-0/0/1.802


tormore lo0 10.200.86.9


800000

302160

パケット

800000

300144

パケット

800000

パケット

CEのインタフェース名は示されていません。特に明記されていない限り、論理インタフェースユニットはすべて.0です。

図 2.7 L2VPNのエンドツーエンドのラベル操作

l2circuit

もう 1つのタイプのレイヤー 2 VPNは、Junosで l2circuitと呼ばれるもので、Martiniトンネルと呼ばれることもあります。これは、レイヤー 2プロトコルをカプセル化し、MPLSネットワーク上で転送するもう 1つの方法です。

注 l2circuitは、IETF RFC 4447に基づいています。この参考資料は、http://www.rfc-editor.org/rfc/rfc4447.txtから入手できます。

l2circuitは l2vpnと同様に、SONET、ATM、イーサネット、またはフレームリレーでカプセル化されたトラフィックを、エンドユーザーに透過的なモードで転送することができます。l2circuitの両端にいるCEエンドユーザーからは、ユーザ同士が直接接続されているように見えます。ただし、l2vpnとは異なり、l2circuitでは、（BGPではなく）LDPによってシグナリングが行われます。また、l2circuitはルーティングインスタンス内には設定されず、サイト識別子やルート識別子は使用されません。標準の l2circuitでは、同じPEルーターに接続しているCEルーター間で接続を確立することはできません。ただし、このようなローカルレイヤー 2インタフェーススイッチングが望ましい場合は、[edit protocols l2circuit]レベルでローカルスイッチングを設定することが可能です。以下に例を示します。[edit]ps@dalwhinnie# show protocols l2circuit local-switchinginterface ge-0/0/1.200 { end-interface { interface ge-0/0/3.200; }}

注本書では、MPLSおよびMPLSサービスに重点を置いているため、ローカルスイッチングについての詳しい説明は省きます。

図 2.8に、ネットワーク構成と、dalwhinnieおよび tormore間の l2circuit接続を示します。

http://www.rfc-editor.org/rfc/rfc4447.txt

http://www.rfc-editor.org/rfc/rfc4447.txt


tormore lo0 10.200.86.9



lagavulinlo0 10.200.86.7

blair lo0 10.200.86.1


oban lo0 10.200.86.3

macduff lo0 10.200.86.8




.1

.6

.5

.2

.34


ge-0/0/2

ge-0/0/3

.30

.29

ge-0/0/1 .10 .9

.46

.45

ge-0/0/3

ge-0/0/2

ge-0/0/1 .14

fe-0/0/1 .13

fe-2/0/1

ge-0/0/3 .42

.41

ge-0/0/2 .50

ge-0/0/3 .18

fe-2/0/0 .17

ge-6/0/0 .26

.25

ge-0/0/2

ge-0/0/3

.38

.37

fe-2/0/1

.33

ge-0/0/2

e1-1/0/0

.22

fe-0/0/1

fe-2/0/0 .49

.21

ge-0/0/1.805

ge-0/0/1.805

CE1 (pseudowire)

CE10 (pseudowire)

192.168.90.1/30

192.168.90.2/30

図 2.8 l2circuit接続のネットワーク構成

図 2.8では、PE上の CE側の物理インタフェースと、l2circuitに参加しているその各論理インタフェースの設定は、l2vpnに参加しているインタフェースと同じです。各エンドポイントPEルーターの物理インタフェースと論理インタフェースには、同じ ccc（Circuit Cross-connect）カプセル化タイプが指定されている必要があります。この場合も、vlan 512～ 4094は、cccカプセル化用に予約されており、511以下の vlan値は、必要に応じて、通常の VLANタグ付きインタフェースとして使用できます。以下の dalwhinnieのスナップショットには、vlan-cccカプセル化が設定されている物理インタフェース ge-0/0/1とその論理ユニット805が示されています。一方、vlan-idが 403のユニット403は、l3vpnまたは通常の IPv4トラフィック用のマスタールーティングインスタンスに参加できます。LDPを実行している、PE上のコア側のインタフェースに加え、PEエンドポイントルーターでも、それぞれの lo0アドレスで LDPを実行する必要があります。リモートPEの lo0アドレスは、Martiniトンネルに参加している dalwhinnieのローカルインタフェースとともに、[edit protocols l2circuit]階層で設定する必要があります。

ps@dalwhinnie> show configuration interfaces ge-0/0/1vlan-tagging;encapsulation vlan-ccc;unit 403 { description "to CE2"; vlan-id 403; family inet { address 192.168.90.5/30; }}unit 805 { description "to CE1"; encapsulation vlan-ccc;


vlan-id 805;}

ps@dalwhinnie> show configuration protocols ldpinterface ge-0/0/2.0;interface ge-0/0/3.0;interface lo0.0;

ps@dalwhinnie> show configuration protocols l2circuitneighbor 10.200.86.9 { interface ge-0/0/1.805 { virtual-circuit-id 10; }}

補足として、対応する tormoreの設定を以下に示します。ps@tormore> show configuration interfaces ge-0/0/1vlan-tagging;encapsulation vlan-ccc;unit 802 { description "to CE6"; encapsulation vlan-ccc; vlan-id 802;}unit 805 { description "to ce10"; encapsulation vlan-ccc; vlan-id 805;}

ps@tormore> show configuration protocols ldpinterface ge-0/0/2.0;interface ge-0/0/3.0;interface lo0.0;

ps@tormore> show configuration protocols l2circuitneighbor 10.200.86.5 { interface ge-0/0/1.805 { virtual-circuit-id 10; }}

両側でこの設定を行うことにより、以下のような l2circuitになります。ps@tormore> show l2circuit connectionsLayer-2 Circuit Connections:

Legend for connection status (St)EI -- encapsulation invalid NP -- interface h/w not present...<truncated for brevity> ... RD -- remote site signaled down XX -- unknown

Legend for interface statusUp -- operationalDn -- downNeighbor:10.200.86.5 Interface Type St Time last up # Up trans ge-0/0/1.805(vc 10) rmt Up Aug 31 08:50:10 2010 4 Remote PE:10.200.86.5, Negotiated control-word:Yes (Null) Incoming label:300000, Outgoing label:301136 Negotiated PW status TLV:No Local interface: ge-0/0/1.805, Status:Up, Encapsulation:VLAN


tormoreのローカルインタフェース ge-0/0/1.805を使用して l2circuitが有効になっています。リモートエンドは 10.200.86.5（dalwhinnie）です。また、コントロールワードを使用できるかどうかのネゴシエーションが行われていますが、コントロールワードは設定されていません。tormoreは、ge-0/0/1.805宛てのトラフィックの受信ラベルが 300000であると想定し、ラベル 301136を付けて、このl2circuitで dalwhinnieにトラフィックを送信します。

注 Martiniトンネルの標準的な動作では、両側のカプセル化タイプとVLAN-IDが同じである必要があります。Junosでは、一方がイーサネットで他方が vlanなど、Martiniトンネルの各側で VLAN-IDやカプセル化タイプが異なる標準外の動作が許容されます。

L2circuitの制御プレーンLDPは、l2circuit用の制御プレーンを備えています。tormoreの LDP隣接機器には、tormoreの lo0.0インタフェースで接続している 10.200.86.5（dalwhinnie）が含まれています。この接続は、LDPを実行しているdalwhinnieの lo0インタフェースと、このインタフェースに対する tormoreのターゲット LDPセッションによって確立することができます。これは、[edit protocols l2circuit]階層で neighborステートメントを使用して指定します。

ps@tormore> show configuration protocols l2circuitneighbor 10.200.86.5 { interface ge-0/0/1.805 { virtual-circuit-id 10; }}

ps@tormore> show ldp neighborAddress Interface Label space ID Hold time192.168.86.34 ge-0/0/2.0 10.200.86.4:0 11192.168.86.38 ge-0/0/3.0 10.200.86.3:0 1410.200.86.5 lo0.0 10.200.86.5:0 37

tormoreの l2circuit.0テーブルで利用可能な LDPルートを調べると、1つのルートが 10.200.86.5（dalwhinnie）からのものであることが示されます。

ps@tormore> show route protocol ldp table l2circuit.0 extensive

l2circuit.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)10.200.86.5:CtrlWord:4:10:Remote/96 (1 entry, 1 announced) *LDP Preference:9 Next hop type:Discard Next-hop reference count:1 State:<Active Int> Local AS:7176 Age:6d 7:24:08 Task:LDP Announcement bits (1):1-l2 circuit AS path:I VC Label 301136, MTU 1500, VLAN ID 805

dalwhinnieの l2circuit.0の出力から、以下のことが分かります。 � ルートが LDPによって学習されている � tormoreは、このルートで送信するトラフィックにラベル 301136を付ける必要がある

� l2circuitのMTUは 1500バイトである � l2circuitの vlan値は 805である


l2circuitルートのルート形式は、neighbor-address:control-word-status:

encapsulation-type:vc-id:sourceです。表 2.1に、これらの各フィールドの意味を説明します。

表 2.1 l2circuitルート形式のフィールド

フィールド意味

neighbor-address ルートをアドバタイズしている LDP隣接機器のアドレス

control-word-status

サーキットについてコントロールワードの使用がネゴシエーションされたかどうかを示します。control-word-statusがネゴシエーション完了になっていても、必ずしもサーキットがコントロールワードを使用しなければならないわけではなく、コントロールワードが設定されている場合にサーキットがそれを使用できることを意味します。

encapsulation-type

1 - フレームリレー DLCI

2 - ATM AAL5 VCC転送 3 - ATM透過セル転送 4 - イーサネットVLAN

5 - イーサネット 6 - HDLC

7 - PPP

9 - ATM VCCセル転送10 - ATM VPCセル転送

vc-id バーチャルサーキット識別子

source アドバタイズメントの送信元で、localまたは remoteのいずれか

L2circuitの転送プレーンMartiniトンネルの転送プレーンは、いくつかのコマンドを使用することで明らかにすることができます。dalwhinnieに戻る転送プレーンのラベル情報を理解するには、まず tormoreの l2circuit.0テーブルを調べるのがよいでしょう。以下の show

route table l2circuit.0 detailコマンドの出力は、2つの部分で構成されています。 ps@tormore> show route table l2circuit.0 detail

l2circuit.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)10.200.86.5:CtrlWord:4:10:Local/96 (1 entry, 1 announced) *L2CKT Preference:7 Next hop type:Indirect Next-hop reference count:1 Next hop type:Router Next hop:192.168.86.34 via ge-0/0/2.0 weight 0x1, selected Label-switched-path tormore-to-dalwhinnie Label operation:Push 300592 Protocol next hop:10.200.86.5 Indirect next hop:8e50300 - State:<Active Int> Local AS:7176 Age:1d 1:25:03 Metric2:4 Task: l2 circuit Announcement bits (1):0-LDP AS path:I VC Label 300000, MTU 1500, VLAN ID 805

10.200.86.5:CtrlWord:4:10:Remote/96 (1 entry, 1 announced)


*LDP Preference:9 Next hop type:Discard Next-hop reference count:1 State:<Active Int> Local AS:7176 Age:1w0d 8:45:57 Task:LDP Announcement bits (1):1-l2 circuit AS path:I VC Label 301136, MTU 1500, VLAN ID 805

最初に、出力の 2番目の部分から見ていきましょう。この部分には、LDPによって受信した 10.200.86.5:CtrlWord:4:10:Remote/96宛先エントリーと、tormoreがその宛先宛てのパケットに VCラベル 301136をプッシュすることが示されています。出力の最初の部分には、宛先 10.200.86.5:CtrlWord:4:10:Local/96が示されており、これは上記と同じエントリーですが、送信元が remoteではなくlocalになっています。このように送信元を切り替えたことにより、tormoreがそのルートをローカルテーブルに受け入れ、その宛先にトラフィックを転送できる状態にあることを示しています。tormoreは、tormore-to-dalwhinnie LSPを使用し、パケットにラベル 300592をプッシュしてこの LSPで送信することにより、その宛先まで到達します。

注 L2CKTセクションにあるVC Label 300000という出力は、tormoreが、ラベル300000で受信したパケットを、ローカル CE側のインタフェースから転送することを意味します。

注この出力は、サーキットのエンドポイントルーター間で RSVP LSPを使用できる場合の典型的なスタイルです。コアが LDPを実行し、RSVPを実行していない場合も同様の出力になりますが、label-switched-path行は含まれません。また、label operation行は含まれますが、そこに示されるラベルは、LDP LSP用のラベルになります。

このすべての情報が、このMartiniトンネルサーキットについて tormoreからdalwhinnieへの転送ラベル操作をマッピングするための開始点となります（show

mpls lsp name <LSP-name> detailコマンドを使用した RSVP LSPのパスの確認方法を思い出すこと）。以下は、LSP上にある各ネクストホップルーターの出力です。出力例の後に示す図 2.9は、これを基にしています。

ps@talisker> show route table mpls.0 label 300592 detail

mpls.0:43 destinations, 43 routes (43 active, 0 holddown, 0 hidden)300592 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:608 Next-hop reference count:3 Next hop:192.168.86.14 via fe-0/0/1.0 weight 0x1, selected Label-switched-path tormore-to-dalwhinnie Label operation:Swap 302368...<truncated for brevity> ...

ps@macduff> show route table mpls.0 label 302368 detail

mpls.0:36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)302368 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:596 Next-hop reference count:3 Next hop:192.168.86.2 via ge-0/0/2.0 weight 0x1, selected Label-switched-path tormore-to-dalwhinnie Label operation:Swap 299984...<truncated for brevity> ...

ps@lagavulin> show route table mpls.0 label 299984 detail


mpls.0:11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) ...<truncated for brevity> ... 299984(S=0) (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:607 Next-hop reference count:2 Next hop:192.168.86.30 via ge-0/0/3.0 weight 0x1, selected Label-switched-path tormore-to-dalwhinnie Label operation:Pop...<truncated for brevity> ...

ps@dalwhinnie> show route table mpls.0 label 301136 detail

mpls.0:15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)301136 (1 entry, 1 announced) *L2CKT Preference:7 Next hop type:Router, Next hop index:571 Next-hop reference count:2 Next hop: via ge-0/0/1.805, selected Label operation:Pop Offset:4 State:<Active Int> Local AS:7176 Age:1w0d 22:18:07 Task:Common L2 VC Announcement bits (1):0-KRT AS path:I

taliskerlo0 10.200.86.4

tormore lo0 10.200.86.9

ge-0/0/2 fe-0/0/1 ge-0/0/2

ge-0/0/1.805

CE10 CE1

ge-0/0/1.805

macduff lo0 10.200.86.8



301136

300592

パケット

301136

302368

パケット

301136

パケット

CEのインタフェース名は示されていません。



パケット

301136

299984


ge-0/0/3 fe-2/0/1 ge-0/0/1

図 2.9 l2circuitのエンドツーエンドの転送ラベル操作例

MartiniとKompella

先に進む前に、Martini（Junosにおける l2circuit）とKompella（Junosにおける l2vpn）に多くの類似点があることに留意することが重要です。例えば、どちらもポイントツーポイントのレイヤー 2接続を確立し、どちらも同じタイプのカプセル化を使用します（図 2.10を参照）。しかし、重要な相違点もあります。Martiniはシグナリングに LDPを使用するのに対し、Kompellaは BGPを使用します。Martiniは設定が容易で、既存の BGPインフラストラクチャを必要としないため、小規模な環境ではMartiniの方が有利です。ただし、Martiniは、各 PEとその他すべての PEとの接続に、それぞれターゲット LDPセッションが必要となるため（各 PE間にポイントツーポイントの接続性を提供できるようにする場合）、より大規模なネットワークや、拡大する可能性の高いネットワークでは、その拡張性が問題となります。一方、KompellaはMartiniとは異なり、この Nx(N-1)の拡張性が問題になることはありません。これは、制御プレーンと、効果的に拡張するためのツールが BGPに備わっているからです。また、BGPルートリフレクタを使用する大規模なネットワークでは、Kompellaの自動検出メカニズムにより、各 PEが


リモートPEに対して個別の TCPセッションを必要とするMartiniと比べて（ただし、2台の PE間にある複数の l2circuitを単一の TCPセッションでシグナリング可能）、必要な設定や制御プレーンの接続が少なくて済みます。結果として、ネットワークプランナーが一連のMPLSサービス（L3VPN、レイヤー 2 VPN、VPLS）の導入を計画する際には、Martiniを使用するより、BGPを必要とするKompellaのためのBGPインフラストラクチャを活用する方が理にかなっていると言えます。表 2.2に、これらの違いをいくつか示します。

表 2.2 Martini/Kompellaの大まかな比較

要素 Martini Kompella

小規模ネットワークへの実装の容易さ比較的容易比較的複雑

より大規模なネットワークへの実装の容易さより多くの設定とルーターリソースが必要ネットワークの成長に応じてBGPの拡張性を

活用

拡張性あまり拡張性がない非常に拡張性が高い

シグナリングプロトコル LDP BGP

他のMPLSサービスで使用される共通リソースの活用不可可

図 2.10に、パケットがイーサネットVLANの PEルーターに着信してから、l2circuitまたは l2vpnでの転送用にデータをカプセル化するPEに着信するまでに、データのカプセル化がどのように変化するかを示します。l2circuitとl2vpnでは、コアMPLSネットワークを通してデータを転送するために、同じタイプのカプセル化が使用されます。

CE1 CE 2


VC ラベル

LSP ラベル

パケット

VC ラベル

パケット

宛先 MAC

イーサネット送信元

MAC パケットの長さ

データ（可変） FCS VLAN

VC ラベルLSP ラベルフラグ

MPLS ヘッダー

長さ連番

制御ワード（オプション）データ

パケット

VC ラベル

LSP ラベル

PE1 PE2 P1 Px

データ（可変）

図 2.10 l2circuitおよび l2vpnパケットのカプセル化

警告 l2circuitまたは l2vｐ n上を移動するときにレイヤー 2データがどのようにカプセル化されるかを表すMartiniカプセル化と、サーキットのシグナリングがどのように行われるかを表すMartiniトンネルがあることを理解しておくことが重要です。Martiniトンネル（l2circuit）とKompellaトンネル（l2vpn）では、異なるシグナ


リングプロトコルが使用されますが（それぞれ LDPとBGP）、カプセル化は共通です（Martiniカプセル化）。一般に、Martiniトンネルは幅広いベンダーでサポートされているため、通常、異なるベンダーの PEルーター間の相互接続性を確保するのに適しています。

VPLSVPLSは、Virtual Private LAN Service（バーチャルプライベート LAN サービス）の略で、ネットワークの PEルーターによって提供されるバーチャル LANサービスを指します。CEルーターから見ると、VPLSは単一の LANに見え、単一のLANであるかのように機能します。一連のMartiniまたは Kompellaトンネルを使用して、ブロードキャストドメインのような動作を作り上げることも可能ですが、これを行うには、PEルーターのローカルサーキットを各リモートPEルーターに手動でマッピングする必要があります。また、この作業を行っても、ポイントツーマルチポイント機能は得られません。このマッピング作業は、特に PEルーター間にフルメッシュを作成しようとしている場合は、多大な労力と時間を要し、また複雑になる可能性があります。VPLSを使用すれば、このような負担がなくなり、手動でサイトをマッピングしなくてもブロードキャストドメインの動作が得られます。実際、VPLSの出現により、エンタープライズにとっては、最初に 2つのサイト間でVPLSを確立し、その後必要に応じてサイトを追加して、レイヤー 2のポイントツーポイントからレイヤー 2のマルチサイトブロードキャストドメイン動作へとシームレスに移行することが望ましいかもしれません。VPLSの標準には、BGPによってシグナリングを行うRFC 4761と、LDPによってシグナリングを行うRFC 4762の 2つがあります。RFC 4761（BGP）は、以下の理由から、多くの状況に適していることが分かっています。

� LDPによってシグナリングされるVPLSでは、PEルーター間にフルメッシュの LDPセッションが必要になります。新しいルーターをメッシュに追加した場合、メッシュ内のその他すべてのルーターで新しいルーターへのターゲットLDPセッションをプロビジョニングする必要があります。

� LDPでは、各サーキットのプロビジョニングを手動で行う必要があります（VPLSインスタンス内で neighborステートメントを使用）。一方、BGPのシグナリングには、ネイティブの自動検出機能があります。

注 LDP-VPLSにおける最近の開発（本書の執筆時点）により、BGPを使用した自動検出が可能になりました。これにより、プロビジョニングが簡素化されますが、VPLSをサポートするために追加プロトコル（LDP）が必要となることに変わりはありません。これに対し、BGP-VPLSでは、シグナリングと自動検出の両方にBGPが使用されます。

� BGPではシグナリングフレームワークが提供されるため、拡張可能なフレームワークであらゆるタイプのMPLSサービス（VPLS、レイヤー 2 VPN、およびレイヤー 3 VPN）を提供することができます。

� LDPによってシグナリングされるVPLSの拡張性を高める手段として階層型VPLSがありますが、これにはレイヤー 2スイッチという形の資源が必要になります。一方、BGPによってシグナリングされるVPLSは、追加のレイヤー2スイッチがなくても拡張可能です。

このリストは、BGPの方が LDPよりVPLSシグナリングに適している理由を示す重要ポイントを挙げたもので、これがすべてではありません。このセクションでは、上記のポイントを基に、VPLSのための BGPの実装について取り上げます（LDPによってシグナリングされるVPLS用に Junosデバイスを設定する方法については、http://www.juniper.net/techpubs/en_US/junos10.1/topics/usage-guidelines/vpns-configuring-vpls-routing-instances.html#id-vpls-ldp-signalを参照）。

図 2.11に、ネットワークの構成と、VPLSインスタンス oakに参加しているCEルーターを示します。

http://www.juniper.net/techpubs/en_US/junos10.1/topics/usage-guidelines/vpns-configuringvpls-routing-instances.html#id-vpls-ldp-signal

http://www.juniper.net/techpubs/en_US/junos10.1/topics/usage-guidelines/vpns-configuringvpls-routing-instances.html#id-vpls-ldp-signal


tormore

lo0 10.200.86.9




blair lo0 10.200.86.1

dalwhinnielo0 10.200.86.5

oban lo0 10.200.86.3

macduff

lo0 10.200.86.8

特に明記されていない限り、インタフェースのIPアドレスはすべて192.168.86/24ネットワークの/30サブネットに属しています。特に明記されていない限り、論理インタフェースユニットはすべて.0です。リンクに対してインタフェース名が1つだけ示されている場合、その名前がリンク両端のルーターのインタフェース名です。

.1

.6

.5

.2

.34


ge-0/0/2

ge-0/0/3

.30

.29

ge-0/0/1 .10 .9

.46

.45

ge-0/0/3

ge-0/0/2

ge-0/0/1 .14

fe-0/0/1 .13

fe-2/0/1

ge-0/0/3 .42

.41

ge-0/0/2 .50

ge-0/0/3 .18

fe-2/0/0

.17

ge-6/0/0 .26

.25

ge-0/0/2

ge-0/0/3

.38

.37

fe-2/0/1

.33

ge-0/0/2

e1-1/0/0

.22

fe-0/0/1 fe-2/0/0 .49

.21

CE8 (vpls-oak)

CE9 (vpls-oak)

CE4 (vpls - oak)

ge-0/0/1.804

192.168.100.1/24

192.168.100.2/24

192.168.100.3/24

ge-0/0/1 .801

ge-0/0/1.800

図 2.11 VPLSの構成

l2vpnと同様に、VPLSでは、VPLS NLRI情報をアドバタイズするために、BGPでファミリー l2vpnに signalingを指定する必要があります。family l2vpn { signaling;}

図 2.11の lagavulinの CE側インタフェースに見られるように、インタフェースがVPLSインスタンスに参加するためには特定の設定が必要となります。すなわち、物理インタフェースには、vlan-taggingおよび vlan-vplsカプセル化を設定する必要があります。また、インスタンスに参加する論理インタフェースには、vlan-vpls

カプセル化を設定する必要があります。この設定により、ge-0/0/1上で、それぞれ IPv4を実行してレイヤー 3 VPNまたはインターネットアクセス用のマスタールーティングインスタンスに参加可能な複数の論理インタフェースを使用できるようになります。ps@lagavulin> show configuration interfaces ge-0/0/1vlan-tagging;encapsulation vlan-vpls;unit 400 { description "Internet connection"; vlan-id 400; family inet { address 192.168.90.17/30; }}unit 804 {


description "VPLS to CE4"; encapsulation vlan-vpls; vlan-id 804; input-vlan-map pop; output-vlan-map push; family vpls;}

注最初は、テストベッドのすべての Pルーターおよび PEルーター（すべて Jシリーズ）で Junos 9.6R4.4が実行されていました。ジュニパーネットワークスの Junos 9.5のリリースノート（http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/release-notes/9.5/j-series-new-features.html）には、このバージョンからVPLSのサポートが開始されると記載されています。ところが、J2350で VPLSを設定しようとすると、VPLSがサポートされていないという警告が表示されました（以下を参照）。そこで、VPLSを実行するルーター（偶然にもすべて J2350）を 10.0R3.10にアップグレードしたところ、VPLSを実行できるようになりました。

[edit routing-instances test]ps@lagavulin# show#### Warning: statement ignored: unsupported platform (j2350)##instance-type vpls;

[edit routing-instances test]ps@lagavulin# run show versionHostname: lagavulinModel: j2350JUNOS Software Release [9.6R4.4]

ここで、図 2.12のユニット804に設定されているVLANマップに注目してください。ジュニパーネットワークスの多くのルーターでは、VLANマップにより、1つの VPLSインスタンス内で、それぞれ異なる vlan-id値を取ることのできる複数のCEサイトと通信できるようになります。

注 MXシリーズルーターでは、VLANマップを使用する必要はありません。MXシリーズ固有の VPLSの設定および機能については、付録 Aを参照してください。


ge-0/0/1.804

CE4 CE 9

ge-0/0/1.801

tormore lo0 10.200.86.9

CEのインタフェース名は示されていません。特に明記されていない限り、論理インタフェースユニットはすべて.0です。

パケットデータ

vlan 804

vlan 801

input-vlan-map popは受信側のvlan IDを削除 output- -map vlan pushは

送信側のvlan IDを追加

パケットはvlan-idなしでコアを通じて伝送されます。

VC ラベル

LSP ラベル

VC ラベル




図 2.12 VPLSの VLANマップの例

図 2.12 には、vlan-id が 804 のパケットが、CE4 ルーターから lagavulinに着信する VLANマップのメカニズムが示されています。lagavulinの ge-0/0/1.804インタフェースで input-vlan-map popにより、パケットから vlan-idタグがポップされます（ラベルのポップと同様）。その後、パケットはコアを通過して tormoreに着信します。tormoreからの送信時に、ge-0/0/1.801で output-

http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/release-notes/9.5/j-series-new-features.html




vlan-map pushにより、パケットに 801の vlan-idタグがプッシュされ（ラベルのプッシュと同様）、パケットが CE9ルーターに送信されます。output-vlan-map push関数は、明示的に異なる vlan-idが指定されている場合を除き、論理インタフェースに設定されている vlan-idを自動的にパケットに追加します。同じVPLSインスタンス内のすべてのサイトで vlan-idが同じ場合、VLANマップは必要ありません。実際の VPLSルーティングインスタンス設定には、前に説明した RDおよび RTと、インスタンスに参加しているインタフェースが含まれます。l2vpnと同様に、VPLSインスタンスでは、共通の VPLSインスタンスの各 CEに固有のサイト識別子が指定されます。

ps@lagavulin> show configuration routing-instances oakinstance-type vpls;interface ge-0/0/1.804;route-distinguisher 10.200.86.7:100;vrf-target target:300:200;protocols { vpls { site-range 5; no-tunnel-services; site ce4 { site-identifier 1; interface ge-0/0/1.804; ## matches interface to specific site } }}

補足と参照用に、tormoreとobanの oak VPLSルーティングインスタンス設定を以下に示します。

ps@tormore> show configuration routing-instances oakinstance-type vpls;interface ge-0/0/1.801;route-distinguisher 10.200.86.9:100;vrf-target target:300:200;protocols { vpls { site-range 5; no-tunnel-services; site ce9 { site-identifier 3; interface ge-0/0/1.801; ## matches interface to specific site } }}

ps@oban> show configuration routing-instances oakinstance-type vpls;interface ge-0/0/1.800; route-distinguisher 10.200.86.3:100;vrf-target target:300:200;protocols { vpls { site-range 5; no-tunnel-services; site ce8 { site-identifier 2; interface ge-0/0/1.800; ## matches interface to specific site } }}

no-tunnel-services設定を使用することで、トンネルサービス用 PICを追加しなくても、JシリーズルーターでVPLSを機能させることができます。この設定により、ローカルルーター上に、VPLSインスタンス内の各リモートサイト用の lsiインタフェース


が作成されます。lagavulinの show vpls connectionsの出力には、obanの CE側インタフェースがダウンしていることが obanから通知されているため、サイト2への接続がダウンしていることが示されています。サイト3（tormore）への接続は有効で、ローカルインタフェース lsi.1050113でパケットを受信しています。

ps@lagavulin> show vpls connectionsLayer-2 VPN connections:

Legend for connection status (St)EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS ...<snipped for brevity> ... RD -- remote site signaled down SC -- local and remote site ID collision...<snipped for brevity> ... PF -- Profile parse failure PB -- Profile busyRS -- remote site standby

Legend for interface statusUp -- operationalDn -- down

Instance: oak Local site: ce4 (1) connection-site Type St Time last up # Up trans 2 rmt RD 3 rmt Up Sep 1 07:29:50 2010 1 Remote PE:10.200.86.9, Negotiated control-word:No Incoming label:262147, Outgoing label:262145 Local interface:lsi.1050113, Status:Up, Encapsulation:VPLS Description:Intf - vpls oak local site 1 remote site 3

VPLSの制御プレーン

RFC 4761バージョンの VPLSでは、BGPが制御プレーンの機能を実行し、PEルーター間のアドバタイズメントを処理します。BGPによってシグナリングされるVPLSの制御プレーンは、主に、自動検出と、VPLSドメインを構成するレイヤー2接続の確立および切断の 2つの機能を実行します。BGPによってシグナリングされる VPLSでは、他のどの PEが VPLSインスタンスを共有しているかを、各PEが自動的に検出し、その PEへのレイヤー 2接続をシグナリングすることができます。また、PEが共通の VPLSインスタンスのメンバーでなくなったときにそれを検出し、そのリモートPEへのレイヤー 2接続を自動的に削除することもできます。これを、ネットワークの成長および進化に伴い大幅な設定およびプランニング作業が必要になる、LDPによってシグナリングされる設定ベースのアプローチと比較してみてください。BGPでは、VPLSを実行している隣接 PEにレイヤー 2 NLRIをアドバタイズするために、BGPで family l2vpn signalingを設定する必要があります。VPLS NLRIの形式は、draft-Kompella（l2vpn）と同じです。lagavulinは、oakルーティングテーブルにある tormoreおよび obanからそれぞれ 1つずつルートを受信しています。受信したRDおよびRTは、これらのルーターについて前に示した VPLSルーティングインスタンス設定を調べることにより確認できます。

ps@lagavulin> show route receive-protocol bgp 10.200.86.9 detail table oak

oak.l2vpn.0:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)* 10.200.86.9:100:3:1/96 (1 entry, 1 announced) Import Accepted Route Distinguisher:10.200.86.9:100 Label-base:262145, range:8 Nexthop:10.200.86.9 Localpref:100


AS path:I Communities:target:300:200 Layer2-info: encaps:VPLS, control flags:, mtu:0, site preference:100

ps@lagavulin> show route receive-protocol bgp 10.200.86.3 detail table oak

oak.l2vpn.0:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)* 10.200.86.3:100:2:1/96 (1 entry, 1 announced) Import Accepted Route Distinguisher:10.200.86.3:100 Label-base:262145, range:8 Nexthop:10.200.86.3 Localpref:0 AS path:I Communities:target:300:200 Layer2-info: encaps:VPLS, control flags:Site-Down, mtu:0, site preference:100

予測したとおり、どちらのルーターもRT BGP拡張コミュニティ値 target:300:200を持つため、oakインスタンスはそのルートをインポートすることができます。また、各ルートの RD値が異なっているのも予測どおりで、これにより、他の VPLSインスタンスが存在してルートが重複する可能性があっても、各ルートの一意性が保たれます。

VPLSではレイヤー 2スイッチングが実行されるため、この時点で次のような疑問を持つ方もいるかも知れません。どのMACアドレスが VPLSドメインのものかをどのように判断すればよいのでしょうか。各 VPLSドメインのMACアドレスは、各インスタンスのフォワーディングテーブルに保存されます。そのため、トラブルシューティングでは、このテーブルが非常に役立ちます。以下に示す lagavulinの oakフォワーディングテーブルには、2つのMACアドレスが示されています。最初にリストされているMACは、インタフェースge-0/0/2.0から到達可能です。ネクストホップは 192.168.86.1で、ルーターは、ここに転送されるパケットに対して、リストされた 2つのラベルプッシュ操作を実行します。2番目にリストされているMACは、CEに直接接続されています。リストされている送信インタフェースは ge-0/0/1.804で、これは oak VPLSルーティングインスタンスに参加しているCE側インタフェースです。

ps@lagavulin> show route forwarding-table vpn oakRouting table: oak.vplsVPLS:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 565 1lsi.1050113 user 0 comp 613 2ge-0/0/1.804 user 0 comp 605 200:24:dc:df:07:05/48 dynm 0 indr 262150 4 192.168.86.1 Push 262145, Push 302160(top) 614 1 ge-0/0/2.000:26:88:03:1c:03/48 dynm 0 ucst 603 3 ge-0/0/1.804

VPLSの転送プレーン

oakフォワーディングテーブルを見れば、ローカルルーターがリモートVPLS宛てのパケットをどのように転送しているかが分かります。lagavulinの oakフォワーディングテーブルには、00:24:dc:df:07:05/48 MACアドレスに到達するためのネクストホップタイプとして Push 262145, Push 302160(top)が示されており、ネクストホップルーターはこのトップラベルに基づいて動作します。302160ラベルの RSVPセッションをざっと検索すると、そのMACアドレス宛てのパケットがlagavulin-to-tormore LSPを使用していることが分かります。

ps@lagavulin> show rsvp session | match 30216010.200.86.9 10.200.86.7 Up 0 1 FF - 302160 lagavulin-to-tormore


注意受信 PEルーターと送信 PEルーター間に等コストの LSPが複数ある場合、VPLSフォワーディングテーブル内にある特定MACアドレスのネクストホップの label-switched-pathと、ルートテーブルにある NLRI のネクストホップの label-switched-pathが一致しないことがあります。以下の出力には、tormoreから着信するNLRIの実際のパスとして、label-switched-path lagavulin-to-tormore-v2（前の出力にある lagavulin-to-tormoreではなく）が示されていることに注意してください。等コストのパスが複数ある場合、Junosでは、ハッシュアルゴリズムによって、宛先ごとにどのパスを使用するかが決定されます。VPLSの場合、ハッシュによって、特定MACに到達するための等コストLSPが決定されます。

ps@lagavulin> show route table oak

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

...<snipped for brevity> ... 10.200.86.9:100:3:1/96 *[BGP/170] 1w5d 20:37:32, localpref 100, from 10.200.86.9 AS path:I to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore > to 192.168.86.1 via ge-0/0/2.0, label-switched-path lagavulin-to-tormore-v2

実践：VPLSラベル操作のマッピング

説明はこれで十分でしょう。それでは、各自で確認してみてください。以下の出力例を基に、oak VPLSインスタンスの L3VPNおよび L2VPNの説明で示したようなラベル操作の図を作成してください。

ps@macduff> show route table mpls.0 label-switched-path lagavulin-to-tormore detail

mpls.0:45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)302160 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:561 Next-hop reference count:4 Next hop:192.168.86.13 via ge-0/0/1.0 weight 0x1, selected Label-switched-path lagavulin-to-tormore Label operation:Swap 300144 State:<Active Int AckRequest> Local AS:7176 Age:5w4d 4:11:09 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

ps@talisker> show route table mpls.0 label-switched-path lagavulin-to-tormore detail

mpls.0:43 destinations, 43 routes (43 active, 0 holddown, 0 hidden)300144 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:592 Next-hop reference count:4 Next hop:192.168.86.33 via fe-2/0/1.0 weight 0x1, selected Label-switched-path lagavulin-to-tormore Label operation:Pop State:<Active Int> Local AS:7176 Age:5w4d 4:14:23 Metric:1 Task:RSVP Announcement bits (1):0-KRT


AS path:I

ps@tormore> show route table mpls.0 source-gateway 10.200.86.7

mpls.0:19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

ps@tormore> show route table mpls.0 label 262145


262145 *[VPLS/7] 1w5d 20:36:43 > via lsi.1049600, Pop

まとめこの章では、L3VPN、レイヤー 2 VPN、VPLSについて説明し、それぞれの基本設定を示しました。また、ルートターゲットとルート識別子の役割と、それぞれの機能の違いについて取り上げました。前にも述べたとおり、BGP制御プレーンを使用したMPLSサービスの基礎を理解するための土台として、これらの役割の違いを理解することが不可欠です。

さらに、この章では、LDPで制御するオプションに比べ、BGPで制御するMPLSサービスの方が拡張性に優れ、より多くの相乗効果がもたらされることを示しました。これで、MPLSサービスの基本設定方法について理解できたでしょう。また、これらのサービスのトラブルシューティング方法についても十分理解できたと思います。理解が不十分な場合は、第 3章に進む前に、この章の各セクションを読み直すとよいでしょう。第 3章では、各自が抱える特定の制約や要件に基づいてネットワークをベストな形で設計する方法について説明します。

第3章

MPLSコアの実装

ネットワークの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100

ルーターの役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

コアのラベル配布 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

コアMPLS設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

MPLS拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

BGPの考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142


今度は、最初の 2つの章で紹介した概念と原理に基づいて構築するとともに、MPLSネットワークの構築および拡張用のオプションを紹介します。この章では、物理的および論理的なアーキテクチャのオプションやデバイスの役割に加えて、拡張用のオプションについて説明します。ネットワークの安全な構築について解説するだけでなく、ネットワークの拡張時に直面する課題について検討するきっかけを提供することも目的としています。いくつかの用語の定義と、現在のMPLSネットワークの分析から始めて、ネットワークのさまざまな要件を考察して設計オプションに置き換えて考えていきましょう。その上で、拡張時の考慮事項について詳しく説明し、有効なソリューションと対策の手順を紹介します。

ネットワークの目的MPLSネットワークの設計時には、ネットワークの目的を確認し、理解しておくことが重要です。そのネットワークは、パフォーマンスに左右されるトラフィックをサポートするのでしょうか。障害回復力は重視される要因でしょうか。そのネットワークで、どのようなサービス（MPLS VPNなど）をサポートする必要があるのでしょうか。QoSは要件に含まれているでしょうか。同様の質問を含めて、このような質問への回答は、適切なネットワークの設計方法を理解する上で重要であり、パフォーマンス要件、障害回復力要件、サービス要件という3つの主要なカテゴリで、実際のネットワークの要件を確認していく上で役に立ちます。

� パフォーマンス要件：確かに広範なカテゴリですが、本書で取り上げるのは、速度（遅延）、遅延の変動（ジッター）、帯域幅の保証、優先度設定（QoS）、クラスベースの転送など、最も一般的に検討されるパフォーマンス要件です。このようなパフォーマンス要件を満たす目的でネットワークに求められる動作について理解しておくことは、IGP以外にも、MPLSの測定方法（メトリックスキーム）、QoS分類、スケジューリングパラメータを導入する場合に役に立ち、トラフィックエンジニアリングでの決定事項にも大きな影響を及ぼすと考えられます。

� 障害回復力要件：障害回復力は、トポロジーの変化に適応するためのネットワークの機能です。リンクダウンイベントはトポロジーの変化を示す良い例ですが（ルーターダウンイベントは単純にリンクダウンイベントの上位集合に相当）、リンクアップイベントも同様に重要です。ネットワークにどの程度の障害回復力が必要かという点は、特にタイマー、IGPやMPLSの障害回復機能といったネットワーク設計に加えて、場合によっては QoSにも大きな影響を及ぼします。障害回復力要件とサービス要件は、結びつけて考える必要があります。質問の答えは結局、障害回復力と複雑性のバランスをどのように取るのかということになります。

注ネットワーク設計では一般に、複雑性の重要度が過小評価されています。通信事業者が複雑性に対処できるかどうかによって、ネットワークの価値は左右されます。

� サービス要件：実際のネットワークのサービス要件を理解することは、ネットワーク設計の最も重要な側面であると考えられます。パフォーマンス、障害回復力、DiffServなどは考慮せずに、inet.0でルーティングされた IPパケットをネットワークで転送する必要がある場合、ネットワーク設計はシンプルになります。IGPは（場合によっては BGPも）、このようなニーズを満たす必要があります。ただし、提供するサービスが差別化と保証、QoS、およびトラフィックエンジニアリングを必要としている場合、帯域幅予約プロトコルが必要になる可能性があります。音声、ビデオ、ゲームなど、リアルタイムトラフィックをネットワークに配信するには、ネットワークで確実に輻輳時間を抑制するとともに、エンジニアが IGPとMPLSの障害回復オプションを検討する必要があります。タイプを問わず、VPN（レイヤー 3 VPN、レイヤー 2 VPN、VPLS）を提供するには、ほとんどの場合、MPLSの採用を考慮する必要があります。重要なポイントとして、このような要件は排他的ではないという点にも注意してく

第3章：MPLSコアの実装 101

ださい。MPLSベースの VPNサービスを提供する場合は、確実に何らかのMPLSの導入を伴うことになります。したがって、現在の QoSの実装を変更するか、QoSの実装を作成する必要があると考えられます。また、エンジニアは、以前は問題にはならなかったトラフィックエンジニアリングについて検討する必要もあるでしょう。音声サービスの追加提供は、QoSに影響を及ぼし、障害回復力を見直す必要もあるでしょう。このような問題はすべて、「ネットワークを成功に導くには、ネットワークのサービス要件を理解する必要がある」という最も重要な原理を示しています。

� ネットワークで提供されるサービスは、常に変化しています。サービスの変更、拡張、削除、および追加は迅速であればあるほど、収益をもたらします。ただし、本書は、このような対応を最初から適切に実践すれば、長期的な成功が約束されると提案するものではありません。重要なポイントは、柔軟性と適応性に優れたネットワークを構築することです。本書は全体を通して、拡張性や柔軟性、さらには最も重要な、管理性に優れたMPLSネットワークを構築する場合に役に立つ説明や事例を記載することを目的としています。

ルーターの役割ルーターの役割と処理範囲を定義することで、ルーターの設定と要件の指針が明らかになります。ここでは、P（Provider）ルーターとPE（Provider Edge）ルーターに焦点を当てて説明します。Pルーターは通常、コアのみのデバイスであり、IGPを実行するとともに（エッジルーターと同様に、BGPを実行する場合もあります）、（IPパケットではなく）スイッチラベルを転送するのが主な役割です。PEデバイスは IGPに参加し、（ネットワークでの）必要に応じてBGPを実行し、IPパケットをスイッチングして、MPLS LSPに IPパケットを転送するのがその役割です。

MPLS環境では一般的に、この役割は 2つのモデルに分類されます。すなわち、P/PEを厳密に分離するモデルと、デバイスが Pおよび PEルーターとして動作するハイブリッドモデルです。

P（Provider）とPE（Provider Edge）の分離設計

P/PEの分離設計では、Pルーターが IPパケットではなく、MPLSラベルを転送します。MPLSラベルは転送用の識別子であり、IPヘッダーの宛先アドレスではありません。PEルーターは内部および外部のルーティング情報全般（ローカル、IGP、場合によっては BGPのルート）を管理し、宛先アドレスに基づいてルーティングルックアップを実行します。次に、IPパケットの先頭にMPLSラベルを付加して、このラベルを適切に転送します。このため、Pルーターが受信するのは（IPパケットではなく）ラベルだけであり、このラベルの情報に基づいてあらゆる転送を実行します。Pルーターはラベルルックアップを実行し、受信したラベルに対応する送信ラベルを見つけて、先頭のラベルと交換します。

図 3.1に示すように、このモデルの大きなメリットの 1つは、Pルーターの役割がラベルに基づいて転送するだけなので、IGPルーターとMPLSラベル情報だけがあれば済むということです。BGPを利用するネットワークでは、PルーターでBGPを実行する必要がないため、関連デバイスのリソース利用が減少するとともに、内部 BGPのフルメッシュのサイズが大幅に縮小されます。さらに、コアとエッジの間に厳密な境界を設定することで、運用上のメリットもいくつかあります。多くの組織は、ハードウェア /ソフトウェアのテストおよび導入を最適化する目的、異なるチーム間の責任やアクセスを分離する目的、またはこの両方の目的で、エッジとコアを分離する傾向があります。このモデルを採用すると、Pルーターは従来のエッジサービスの終端としては機能できなくなります。


tormorel0.200.86.9

mortlach10.200.86.2

blair10.200.86.1

lagavulin 10.200.86.7

dalwhinnie10.200.86.6

oban10.200.86.3

macduff10.200.86.8

talisker10.200.86.4

図 3.1 コア /エッジの分離設計

コア /エッジの分離モデルの大きなメリットは、サービスがエッジに限定されるので、分離によって運用や障害の範囲が明確になることです。分離モデルでは、機能要件とアップグレードサイクル、アクセス制限（ユーザーエラーの影響を限定できる）でもメリットがあります。

P（Provider）とPE（Provider Edge）のハイブリッド設計

厳密な P/PE分離モデルに代わるハイブリッドモデルでは、ルーターがプロバイダデバイスとプロバイダエッジデバイスの両方として機能します。このモデルでは、図 3.1に示した分離モデルで従来、Pルーターとして機能していたルーターが同様にエッジ機能も実行します。このルーターの役割（顧客の終端機器としての動作、外部 BGPピアへの接続、その他のサービスの提供）にかかわらず、追加のルーティング情報を適宜、このルーターに提供する必要があります。この結果、PEデバイスは、宛先 IPアドレスに基づいて一定のトラフィックを転送する役割を果たします。PEデバイスには、ネットワークの他のルーターにトランジットパスを提供する役割もあります。この場合、PEデバイスがラベル情報に基づいてトラフィックのスイッチングを実行することになります。つまり、Pルーターの役割も果たすということです。このモデルのメリットは、任意のデバイスからサービスを提供できるという柔軟性です。デメリットは、さらに詳細なルーティングテーブルを必要とするデバイスの数が増えることです。

P/PE設計の選定

どちらの設計が実際に適しているのか、判断に迷う場合もあるでしょう。その答えは、実際のネットワークの物理的な接続性によって大きく左右されます。

ネットワーク通信事業者がネットワークに左右される理由として、物理的なトポロジーはすでに確定されているか、少なくとも、利用可能な予算額がプロトコル設計よりも重視されることが挙げられます。多くの場合、「エッジとコアの物理的な接続性」と、コアルーターをそのままの役割で使用するのか、言い換えると、「コアデバイスでの非エッジ接続性」という2つの条件に基づいて考えると、P/PE設計を適切に選定できるでしょう。


エッジとコアの分離設計を強く支持する根拠として、専用のエッジを導入することで、複雑性はエッジに集約して、コアはパケットのスイッチング処理の高速化に専念させられるという点が挙げられます。また、運用上の境界を設けることで、デバイスの役割に基づいた厳密なグループベースの権限レベルが実現します。コード要件とテストについても、ハードウェアと役割の限定的な組み合わせに限定されるので、テストおよび導入を担当するグループは、デバイスのグループごとの各機能に注力できます。最後に、エッジサービスと接続をエッジデバイスに限定することで、計画内 /計画外を問わず、障害の範囲を特定することは容易になり、コアの変更による影響は軽減され、容量計画（キャパシティプランニング）の支援にもなります。

P/PE設計を定義する上で役に立つと考えられる要素の 1つが、エッジの接続方法です。少し時間をかけて、この点を詳しく見ていきましょう。

エッジ接続性エッジ接続性に関しては、U（またはボックス）設計とX設計という2種類の一般的な設計があります。この両設計の名前は、設計を図示したときに形状が似ている文字に由来しています（この両設計を組み合わせたハイブリッドバージョンもいくつか存在しますが、経済性や意思決定の要因から、どれもよく似たものになっています）。U設計では、ペアになったエッジルーターそれぞれにコアルーターへのアップリンクが用意され、エッジルーター間を接続することによって冗長性を確保しています。図3.2は、U設計を示しています。

コア1 コア2

コア2エッジ1

アップリンクポートが必要10

10

10

40

図 3.2 Uエッジ設計

U設計のメリットは、コストです。2つのエッジルーターの冗長アップリンクでは、必要な回線の数は、edge1から core1に 1つ、edge2から core2に 1つ、エッジルーター間に 1つ、つまり合計 3つ（6ポート）で済みます。障害状況では、2つのエッジデバイスがアップリンクを共有するので、オーバーサブスクリプションがデメリットになります。ただし、個別の帯域幅の増加または集約によってアップリンクのサイズが増加すると、このリスクは軽減されますが、コスト面のメリットは低下する可能性があります。エッジデバイスのペア構成も、ペア間のトラフィックはコアルーターを通過する必要がないので、エッジルーターのペア間でのトラフィックの不公平な優先処理の原因になることがあります。IGPの測定基準（メトリック）を適切に設定することで、このような動作を防ぐことができます（この目的を果たすメトリックについては、図 3.2を参照）。X設計では、このトレードオフが逆になり、コスト面を犠牲にして冗長容量を増やします。図 3.3は、このトポロジーを示しています。


コア1 コア2

アップリンクポートが必要

エッジ1

アップリンクポートが必要アップリンクポートが必要

エッジ2

図 3.3 Xエッジ設計

Xエッジ設計では、帯域幅のフル冗長構成によってコストは増加しますが、障害やサービスへの影響の可能性は低下します。各エッジルーターは 2つのアップリンク（それぞれのコアルーターに対して 1つのアップリンク）、つまり合計で 4つのポートを必要としますが、サイズ設計が適切であれば、アップリンク回線が使用過多の状態になることはありません。

注コアポートの合計数には限りがあり、エッジルーターがコアポートをすべて使用する可能性は十分にあります。このような事例では、図 3.4に示すように、分散レイヤーが必要になる可能性があります。

コア1 コア2

コア-sw1 コア-sw2

エッジ1 エッジ2 エッジ3 エッジ4 エッジ5 エッジ6 エッジ7 エッジ8

図 3.4 集約レイヤーを使用した X設計

X設計は P/PE分離モデルをサポートしており、（IGPのメトリックが適切な場合）トランジットトラフィックが PEルーターを通過することはありません。U設計は効果的にあらゆるPEを Pに転用するとともに、アップリンクの障害時にトラフィックが PEルーターを通過できるようにしています。最後に、この問題のもう 1つのポイントは、エッジルーターが排他的にエッジサービスを提供するかどうかです。従来のエッジサービスがエッジルーターだけに限定


されている場合、ネットワークでは P/PEの分離ネットワークをサポートできます。コアポートがエッジサービスを提供する場合、ネットワーク内のあらゆるルーターがPEの役割を果たす可能性があり、ネットワークはこのような役割の分離をサポートしていません。表 3.1は、考えられる組み合わせとP/PEの結果を示しています。

表 3.1 P/PE設計の意思決定マトリクス

物理的なトポロジーサービス分離の対応 P/PEの結果

U設計条件次第ハイブリッド

X設計条件次第ハイブリッド

X設計全面的 P/PE分離

コアのラベル配布

ネットワークでMPLSをサポートする場合、設計者はラベル配布プロトコルを選定する必要があります。具体的には、LDP（Label Distribution Protocol）とRSVP（Resource Reservation Protocol）という2種類のオプションがあります。この章の冒頭で、ネットワークの目的についての基本的な質問を紹介しましたが、その答えがこのオプション選定時の参考になるはずです。

RFC 4364スタイルのレイヤー 3 VPN、Kompella、Martiniスタイルのレイヤー2 Pseudo-Wiresまたは VPLSといったMPLSサービスだけが要求され、MPLSトラフィックエンジニアリングや（一般的な IGPの輻輳に対する）障害回復力の向上が要求されない環境では、LDPが適切なプロトコルであると考えられます（このような事例では、RSVPの複雑性はメリットに見合わないと判断されます）。これに対して、高速なフェイルオーバー、MPLSトラフィックエンジニアリング、ポイントツーマルチポイント LSP、その他の機能が求められる場合は、RSVPが必要であると考えられます。基本的にネットワークの要件と、実際のネットワークで許容される複雑性を考慮して選定することになります。LDPは極めてシンプルですが、多機能ではありません。RSVPには多くの機能・メリットがありますが、必要となるアーキテクチャのエンジニアリングや運用上の取り組みは格段に増加します。ネットワークの規模やLSPの数によっては、RSVPでは拡張技法が必要になる可能性があるのに対して、LDPではこのような制限はありません。この両方のオプションを採用するのはどうでしょうか。ハイブリッドMPLS設計は実際に採用される例もあり、RSVPの拡張に伴う制限をある程度、緩和できます。多くのネットワークでは、RSVPがプライマリの配信プロトコルとして採用されていますが、実装と運用の容易さから、LDPもバックアッププロトコルとして設定されています。

コアの LDP

コアで LDP（単独）を実装する場合の大きなメリットは、そのシンプルさです。LDPはルーティングプロトコルではなく、純粋にラベル配布プロトコルです。つまり、ルーティングテーブルのルートのラベルをアドバタイズするだけなので、一般的なルート選択の規則（最長一致（ロンゲストマッチ）、プロトコル優先度、プロトコル非依存の選択基準）がそのまま適用されます。LDPのメリットであるシンプルさは、デメリットにもなります。LDPは現在、トラフィックエンジニアリングや高速なフェイルオーバーをサポートしていません。


コアの RSVP

RSVPは多機能であることから、大規模なネットワーク（特にサービスプロバイダ）のコアで採用されることが一般的です。トラフィックエンジニアリングや帯域幅制限、障害回復力の向上、その他の機能（RFC 4364スタイルのレイヤー 3 VPNおよび VPLSでの使用に適したポイントツーマルチポイント LPSなど）により、ラベルシステムパスをネットワークに提供することが RSVPの目的です。RSVP-TE MPLSネットワークを導入する場合に考慮する必要がある主な要素として、RSVPに参加するルーターの数（つまり、作成する LSPの数）、フェイルオーバーの改善とLSPへの適用方法、トラフィックエンジニアリングポリシー、サービス関連事項などが挙げられます。さらに、見落とされる場合も多い要素ですが、運用のサポート性も挙げるべきでしょう。RSVP-TEで利用可能なツールはすべて、優れた効率性、（サービス関連の）フル機能、ネットワークの迅速な修復機能といった特長を備えています。ただし、これらのツールを利用した結果、ネットワークの把握やエンジニアリングが困難になり、トラブルシューティングがほぼ不可能になる可能性があります。

コアMPLS設計ネットワークの要件、プロトコルの選定、確認されている障害回復力の特性について、詳しく見てきました。今度は、さまざまなネットワークの設計とそのコンポーネント、それぞれについて考慮すべきメリットとデメリットについて詳しく見ていきましょう。最初に LDPのみのネットワーク、続いてRSVPフルメッシュアーキテクチャを取り上げます。その後で、数ページ前に説明したハイブリッドMPLS設計のポイントに戻って、LDPトンネリングコンポーネントを備えた RSVPコアによる LDPエッジに注目します。

LDPのみのネットワーク

図 3.5の小規模な LDPネットワークの例に示すように、LDP用に設定されたルーターが UDPを伝送メカニズムに使用して、直接接続された機器と隣接関係を形成します。

注 LDPの使用時に、ラベルはループバックアドレスにバインドされて、LDPの隣接機器と交換されます。ジュニパーネットワークス製ルーターは専用のループバックアドレスのラベル（通常、ラベル 3）を作成し、ピアから受信したラベルのマッピングを作成してから、ローカルラベルとマッピング済みラベルを LDPピアにアドバタイズします。

図 3.5では、各ルーターに、3つの宛先プレフィックス（他の 3つのルーターのループバックアドレス）を示すLDPラベルが設定されています。各ルーターが2つのルーターの最後から 2番目のホップになるので、LDPラベルのうち 2つはラベル 3になり、残りの 1つは、間接的に接続しているルーターを示す、ランダムに割り当てられたラベルになります。たとえば、mortlachはmacduffと同様に blairにも直接接続しているので、それぞれからラベル 3を受信することになります。ただし、taliskerは直接接続していないので、blairとmacduffのどちらも、taliskerから受信したラベルのラベルマッピングを作成して、そのラベルをmortlachにアドバタイズする必要があります。mortlachは taliskerへの標準的な IPルート選択を実行して、そのルートに関連付けられているラベルを選択します。この例では、blairを経由したパス（20）は、macduffを経由したパス（30）よりもコストが小さくなります。mortlachからの出力は、この情報を inet.3 MPLSテーブルとinet.0ルーティングテーブルに示しています。

ps@mortlach> show route 10.200.86.4 inet.0:13 destinations, 18 routes (13 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.4/32 *[LDP/9] 00:00:04, metric 1 ß Selected route through blair (metric 20)


IGPメトリック

10

10

10

20

mortlach10.200.86.2

blair10.200.86.1

macduff10.200.86.8

talisker10.200.86.4

図 3.5 LDPラベル配布図

> to 192.168.14.6 via ge-0/0/1.0, Push 100976 [OSPF/10] 00:00:04, metric 20to 192.168.14.6 via ge-0/0/1.0

blairとmacduffの LDPルートには、ラベル情報が示されていないことに注意してください。これは、mortlachが blairとmacduffの LDPルートに対してラベル 3を受信したからで、mortlachが最後から 2番目のホップであることを示しています。したがって、mortlachは、以下に示すように、blairまたはmacduffを宛先とするパケットにラベルを付加しません。

ps@mortlach> show route table inet.3 inet.3:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.1/32 *[LDP/9] 00:08:50, metric 1 ß LDP label for blair, no label > to 192.168.14.6 via ge-0/0/1.0 shown (label 3)10.200.86.4/32 *[LDP/9] 00:01:12, metric 1 ß LDP label for talisker, via blair > to 192.168.14.6 via ge-0/0/1.0, Push 10097610.200.86.8/32 *[LDP/9] 00:08:49, metric 1 ß LDP label for macduff, no label > to 192.168.14.1 via ge-0/0/1.0 shown (label 3)

If blair were to receive a packet with a label of 100976, it would consult its mpls table to find the label mapping for this label.ps@blair> show route table mpls.0 label 100976 mpls.0:8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both100976 *[LDP/9] 00:27:08, metric 1to 192.168.14.14 via ge-0/0/1.0, Pop

ここでは、blairが（PHPルーターと同様に）ラベルをポップして taliskerに送信していることがわかります。ここで取り上げるべき重要なポイントは、LDPはルーティングプロトコルではないということです。LDPは単純にラベルを配布して、ルーターによる選択済みルートとの関連付けを可能にします。VPNで使用するその他のプロトコル（または IP）の伝送メカニズムとして LDPネットワークを使用できるという意味で、IGPは確かに重要な要素です。ただし、LDPネットワークを使用しても、トラフィックエンジニア


リングやファストリルートなど、RSVPに関連するメリットは得られません（本書の執筆時点では、LDPのファストリルートはまだ標準化されていません）。実際のネットワークで、トラフィックエンジニアリングや障害回復力の向上が重視される場合は、プライマリのラベル配布プロトコルとして LDPを使用しないでください（後で説明するように、RSVPと組み合わせることで使用できます）。

注 MPLS設計の主目的が迅速な障害回復である場合は、OSPF LFA（Loop-Free Alternate）が代わりのアプローチになります。OSPF LFAは、MPLSのオーバーヘッドを伴わず、迅速なフェイルオーバーを可能にします。したがって、ネットワークの主目的が VPNサービスの提供であり、特別な障害回復力のニーズを伴わない場合は、LDP実装のシンプルさが目的に適していると考えられます。

RSVP-TE

トラフィックエンジニアリングや障害復旧力の向上など、付加的な機能を必要とするネットワークでは、プライマリのラベル配布メカニズムとしては、RSVPが正しい選択です。

ただし、RSVPを使用する場合、運用・処理のコストを伴うことに注意が必要です。LDPは機能面では制約がありますが、設定は極めてシンプルであり、ネットワークに対する負荷も限定されます。LDPは単純にラベルを交換し、ルーターはこのラベルに基づいてルートを選択します。RSVPはルーティングの決定に影響を及ぼし、ネットワーク全体にまたがるパスを作成するので、ルーターはパスの状態を保持して、ルーティングテーブル以外の情報も考慮する必要があります。つまり、ルーターは、利用可能な帯域幅や管理グループのトポロジーなど付加的なネットワーク情報を交換し、この情報に基づいて目的のパスをネットワークにまたがって作成する必要があるということです。ルーターはこのメッセージを使用して、ネットワーク全体の状態を作成し、保持します。さらに、ネットワークのトポロジーの変化に応じて、この情報を更新する必要があります。したがって、RSVPは LDPの場合よりも情報量が明らかに増えます。

ただし、機能が複雑化して処理が増えることから、環境によっては、問題視される可能性があります。トラフィックエンジニアリングによって、管理者は、最短の IGPパスとは異なるパスでトラフィックを送信できるようになります。つまり、低遅延のパスや利用率の低いパス、さらに特定のタイプのトラフィックについては渋滞箇所をバイパスするパスが選択肢として提供されます。また、プライマリパスと同じ物理パスと重なる可能性がある回線の使用をバックアップパスには許可しないよう設定できます。これらは強力な機能であり、RSVPは複雑なネットワークの問題を解決する手段になります。

注 LSPプロテクションは、その形態（ジュニパーネットワークスのファストリルート、セカンダリLSP、リンクプロテクション、リンクノードプロテクションなど）を問わず、通常の IPコンバージェンスでは得られないネットワークの障害復旧力を提供できます。この機能は特に、音声やビデオなど、障害に影響されやすいトラフィックをサポートする環境で真価を発揮します。

RSVPエッジメッシュネットワークRSVP-TEには、いくつかの異なる設計オプションがあります。一般的な設計の例として、RSVP-TEをエッジに拡張して、トラフィックエンジニアリングとLSPプロテクションのエンドツーエンドでのフルサポートを可能にするという設計が挙げられます。この設計では、シングルエリア /レベルの IGP実装が必要になり、大規模なネットワークでは拡張時に問題が発生する可能性があります。ただし、図 3.6に示すように、このシナリオでは、PEルーターが他のあらゆる PEルーターに対する LSPを構築しており、Pルーターが純粋にトランジットラベルのスイッチングルーターの役割を果たしています。これは、次に説明するBGPフリーコア設計では、極めて有効に機能します。


LSP

mortlachPルーター

10.200.86.2

blair Pルーター10.200.86.1

macduff Pルーター10.200.86.8

talisker Pルーター10.200.86.4

laguvulinPEルーター10.200.86.7

obanPEルーター10.200.86.3

図 3.6 エッジ LSPメッシュ

BGPフリーコア

あらゆる受信パケットがエッジでMPLSにカプセル化されたネットワークのメリットの 1つとして、Pルーターがパケットのスイッチング時に完全なルーティングテーブルを必要としないことが挙げられます。従来のネットワークでは、ルーターが IGPまたは BGPに基づいて、ネットワークのエッジを通過した宛先にトラフィックを転送します。また、各ルーターでルーティング情報全般（少なくともその一部）を保持する必要があり、Pルーターはほぼ常時、ネットワーク全体の情報を必要としています。大規模なネットワークで、インターネットのルーティング情報をフルに提供する場合、この情報は数十万ものルートと同義になると考えられます。つまり、このようなピアリング関係を作成・保持する処理、この情報を保持するメモリ、この情報を転送プレーンに展開するメカニズムが必要になります。

このため、リモートPEのネクストホップアドレスをラベルと関連付けることが可能な場合には、コアPルーターがあらゆるルートを把握する必要はなくなり、各 PEとその PEのラベルの情報を把握しているだけで済みます。したがって、受信 PEは受信パケットをMPLSラベルでカプセル化する必要があります。そのラベルによりパケットは送信 PEに送られ、コアルーターで BGPルートは不要になります。お察しのとおり、この設計では、制御の負荷が軽減されて、リソースが開放されるとともに、ネットワークの輻輳全般が改善されます。BGPフリーコア設計は LDPとRSVP-TEの両方でサポートされており、大規模なネットワークで採用される機会が多くなっています。

RSVPフルメッシュネットワーク

ネットワークによっては、ネットワーク内の大半またはすべてのルーターが PEの役割を果たしています。これに該当する場合、RSVPの機能でエニーツーエニー型のMPLS接続性を可能にするには、LSPのフルメッシュが必要になります。この条件では、さらに拡張性の問題が発生する可能性があります。つまり、ネットワーク通信事業者が OSPFエリア0（または、IS-ISレベル 2ネットワーク）のサイズを検討する必要があるだけでなく、作成した LSPの数が負担になる可能性があります。

ルーターの数が nであるネットワークの場合、各ルーターで他の各ルーターへの LSPを保持する必要があるので、フルメッシュでは n(n-1)個の LSPが作成されます。ルーターの数が 20のネットワークでも、LPSの数は 380に達します。ネットワークを拡


張してルーターの数を 100に増やすと、LSPの数は 9900にまで達します。この最良のシナリオでは、所定のルーター間に 2つの単方向 LSPが存在し、障害回復力メカニズムは使用されていないという想定です。たとえば、セカンダリLSPを使用すると（各 LSPにバックアップのセカンダリLSPを用意する場合）、LSPの合計数はそのまま2倍になります。LSPのメッセージングは一時的（送信後は放置される）であるので、ピアから送信されたすべてのメッセージを受信したのかどうかルーターが把握する方法も、送信したすべてのメッセージを目的のターゲットがすべて受信したのかどうか送信側が把握する方法もありません。トランジットパス上のルーターでLSPが数千単位で存在し、リンクダウンによって数千単位の RSVPメッセージが発生した状況では、送信側または受信側で大量のメッセージに対処できない場合、問題となります。この問題が発生した場合、ヘッドエンドの LSPから停止状態の LSPにパケットが送信され続けた結果、トラフィックのドロップが発生する可能性があります。この状況は、IGPの再集約が可能になり、RSVPの信号再送信が可能になった時点で解消されます。ただし、RSVPを導入する目的が障害回復力の向上であった場合、このような問題は重大な影響を及ぼす可能性があります。

さまざまな RSVPの実装事例で、グループ内の他のあらゆるルーターによるRSVPフルメッシュを必要とするルーターが存在し、この要件は運用に極めて大きな影響を及ぼす可能性があります。L3VPNや VPLSサービスを提供するPEがその典型的な例です。このフルメッシュの要件では、ルーターの数がNのグループの場合、各ルーターにN-1個の RSVP LSPが設定されることになります。このグループにルーターを追加すると、グループ内の他の各ルーターでは、その新しいルーターへの LSPが必要になります。RSVPオートメッシュ（Junos 10.1以降で利用可能）は、このようなタイプの RSVPの実装事例に伴う設定のオーバーヘッドを大幅に削減します。RSVPオートメッシュは、以下のように、各ルーターに対するポイントツーポイントの RSVP LSPを自動的に作成します。

� 各ルーターが iBGPルート（l3vpnルート、VPLSルート、または inet.0ルート）を受信します。

� 特定のアドレス範囲に収まる lo0アドレスが各ルーターに設定されます。

注ラボテストで明らかになったように、ローカルルーターで RSVPオートメッシュのLSPを生成するには、inet.0テーブル内に iBGPのネクストホップ（LSPの宛先）へのラベル付きルートが存在している必要があります。テストでは、LSPが有効になった時点で、宛先へのラベル付きルートが inet.0内に存在している必要があるという条件が不要になることも明らかになっています。inet.0にラベル付きのパスを作成するため、LDPプロトコルを有効にして、[protocols mpls]に traffic-engineering bgp-igp-both-ribsを設定しました。これで、宛先へのラベル付きパスが作成されて、この宛先が inet.0に追加されます。オートメッシュLSPの設定後に、LDPと traffic-engineering bgp-igp-both-ribsを非アクティブ化しても、オートメッシュLSPは破棄されません。この機能は、Junos 10.3 R1.9が動作するMX-80ルーターでテストしました。以下のように、[routing-options dynamic-tunnels]にオートメッシュを設定します。

ps@dalwhinnie> show configuration routing-options dynamic-tunnelsdt-default { rsvp-te dt-default-1 { label-switched-path-template { default-template; } destination-networks { 10.200.86.0/24; } }}

この例では、label-switched-path-templateはデフォルトテンプレートであり、destination-networksは LSPエンドポイントに許可されたアドレス範囲です。


この両方の設定を指定する必要があります。この例では、「dalwhinnieに iBGPルートを送信し、lo0アドレスが 10.200.86/24の範囲に収まる」という条件に当てはまるルーターへの LSPを作成しています。この設定は、指定されたネットワークを含む inet.3内のトンネルファミリのリストを作成します。

ps@dalwhinnie> show route table inet.3 protocol tunnel


10.200.86.0/24 *[Tunnel/300] 01:13:13 Tunnel

動的 LSPが生成されます。ps@dalwhinnie> show rsvp session ingressIngress RSVP:1 sessionsTo From State Rt Style Labelin Labelout LSPname10.200.86.7 10.200.86.4 Up 1 1 FF - 300000 10.200.86.7:dt-rsvp-dt-defaultTotal 1 displayed, Up 1, Down 0

ps@dalwhinnie> show rsvp session ingress detailIngress RSVP:1 sessions

10.200.86.7 From:10.200.86.4, LSPstate:Up, ActiveRoute:1 LSPname:10.200.86.7:dt-rsvp-dt-default, LSPpath:Primary LSPtype:Dynamic Configured Suggested label received:-, Suggested label sent:- Recovery label received:-, Recovery label sent:300000 Resv style:1 FF, Label in:-, Label out:300000 Time left: -, Since:Tue Mar 29 21:50:57 2011 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 34969 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto:192.168.86.6 (ge-0/0/2.0) 13 pkts RESV rcvfrom:192.168.86.6 (ge-0/0/2.0) 12 pkts Explct route:192.168.86.6 192.168.86.10 Record route:<self> 192.168.86.6 192.168.86.10Total 1 displayed, Up 1, Down 0

これで、dalwhinnieには 10.200.86.7（oban）への動的 RSVP LSPが設定されました。LSP名の形式は、以下のとおりです。[宛先 ]:dt-rsvp-[トンネル名 ]。dt-rsvpは、トンネルを作成したモジュール（動的トンネル）と、トンネルのタイプ（RSVP）を表します。ここでは、トンネルの通過を許可されたルートを確認します。

ps@dalwhinnie> show route table inet.3 10.200.86.7 detail

inet.3:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)10.200.86.7/32 (1 entry, 1 announced) State:<FlashAll> *RSVP Preference:7/3 Next hop type:Router, Next hop index:663 Next-hop reference count:10 Next hop:192.168.86.6 via ge-0/0/2.0 weight 0x1, selected Label-switched-path 10.200.86.7:dt-rsvp-dt-default Label operation:Push 300000 State:<Active Int>


Local AS: 1 Age:8:39 Metric:2 Task:RSVP Announcement bits (2):1-Resolve tree 1 2-Resolve tree 3 AS path:I

ps@dalwhinnie> show route next-hop 10.200.86.7


15.15.15.0/24 *[BGP/170] 00:59:38, localpref 100, from 10.200.86.7 AS path:I > to 192.168.86.6 via ge-0/0/2.0, label-switched-path 10.200.86.7:dt-rsvp-dt-default

inet.3:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

mpls.0:6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

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

10.200.86.3:100:4:1/96

*[BGP/170] 00:35:29, localpref 100, from 10.200.86.7 AS path:I > to 192.168.86.6 via ge-0/0/2.0, label-switched-path 10.200.86.7:dt-rsvp-dt-default

oak.l2vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.200.86.3:100:4:1/96 *[BGP/170] 00:09:22, localpref 100, from 10.200.86.7 AS path:I > to 192.168.86.6 via ge-0/0/2.0, label-switched-path 10.200.86.7:dt-rsvp-dt-default

この出力は、オートメッシュLSPを使用可能な 10.200.86.7から 1つの inet.0ルートと 1つの VPLSルートが受信されたことを示しています。default-templateに含まれていない機能で LSPを使用する必要がある場合、Junosでは、カスタマイズした LSPテンプレートを指定できます。以下の例は、LSPのリンクプロテクションを要求する dynamic-templateという名前のカスタマイズテンプレートを指定しています。

ps@dalwhinnie> show configuration routing-options dynamic-tunnelsdt { rsvp-te dt-1 { label-switched-path-template { dynamic-template; } destination-networks { 10.200.86.0/24; } }}

ps@dalwhinnie> show configuration protocols mplstraffic-engineering bgp-igp-both-ribs; ... ...


label-switched-path dynamic-template { template; link-protection;}interface ge-0/0/2.0;interface ge-0/0/3.0;

ps@dalwhinnie> show mpls lsp ingress detailIngress LSP:1 sessions

10.200.86.7 From:10.200.86.4, State:Up, ActiveRoute:1, LSPname:10.200.86.7:dt-rsvp-dt ActivePath:(primary) Link protection desired LSPtype:Dynamic Configured LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary State:Up Priorities:7 0 SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:2) 192.168.86.6 S 192.168.86.10 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.200.86.2(flag=0x20) 192.168.86.6(Label=300048) 10.200.86.7(flag=0x20) 192.168.86.10(Label=3)Total 1 displayed, Up 1, Down 0

これでオートメッシュLSPには、要求されたリンクプロテクションが設定されました。最後に、Junosでは、オートメッシュ LSPの使用を許可された iBGPルートが 1つも存在していなければ、オートメッシュLSPは存在できません。この状況に該当する場合、動的 LSPが 15分のカウントダウンタイマーを開始します。この期間内にルートが LSPの使用を許可されない場合、Junosは LSPを破棄します。以下の例は、オートメッシュLSPと同じ宛先に新しく設定した LSPを示しています。

ps@dalwhinnie> show configuration protocols mplstraffic-engineering bgp-igp-both-ribs;label-switched-path dalwhinnie-to-oban { to 10.200.86.7; link-protection;}

ps@dalwhinnie> show mpls lsp ingressIngress LSP:2 sessionsTo From State Rt P ActivePath LSPname10.200.86.7 10.200.86.4 Up 0 * 10.200.86.7:dt-rsvp-dt10.200.86.7 10.200.86.4 Up 2 * dalwhinnie-to-obanTotal 2 displayed, Up 2, Down 0

ps@dalwhinnie> show dynamic-tunnels databaseTable: inet.3

Destination-network:10.200.86.0/24Tunnel to:10.200.86.7/32 (expires in 00:14:17 seconds) Reference count:0 Next-hop type: rsvp-te 10.200.86.7:dt-rsvp-dt

設定された LSPとオートメッシュLSPの両方の宛先が同じ場合、Junosのデフォルトでは、設定された LSPが優先されます。上の例では、設定された LSPがiBGPルートで優先されるので、オートメッシュ LSPに適したルートは存在せず、期限切れのカウントダウンタイマーが開始されます。


RSVPオートメッシュは、RSVP実装を拡張する場合に役に立つツールです。重要なポイントとして、使用している Junosのバージョンが、GRES（Graceful Routing-Engine Switchover）や NSR（Non-Stop Routing）など、目的の HAオプションとの組み合わせで、RSVPオートメッシュをサポートしていることを確認してください。拡張されない小規模なネットワークでは、LSPのフルメッシュは確実に機能しますが、大規模なネットワークや拡張されるネットワークでは、拡張に関連する問題が深刻になる可能性があります。ただし、ネットワークの安定性をリスクにさらすことなく、同様の機能を可能にするオプションが用意されているので心配する必要はありません。

LDPエッジとRSVPコアのハイブリッドネットワーク

フルメッシュの代償を払わずに、エッジツーエッジのMPLS機能を利用するオプションとして、コア（P）デバイス間に限定して RSVPを実行し、LDPによってMPLSをエッジに拡張する方法が挙げられます。幸い、RSVP-TEは、図 3.7に示すように、RSVP信号が送られる LSPで LDPパケットのトンネリングを有効にすることで、この考え方をサポートしています。つまり、LSPの送 Ingressルーターは LDPラベルを直接交換して、各ラベルスイッチルーター間のシングルホップ LDPパスを効果的に作成します。この方法により、LDP信号が送られるエッジツーエッジのMPLSパスは、コアで RSVP信号が送られる LSP上に設定可能です。この設定により、拡張性に優れたMPLS実装が提供されるとともに、RSVP LSPのトラフィックエンジニアリングと障害復旧力向上のメリットがもたらされます。


10.200.86.2 blair Pルーター10.200.86.1





RSVP

RSVP

RSVP

RSVP

LDP

LDP

LDP

LDP

図 3.7 LDPトンネリング

図 3.7では、コアと対向するインタフェースで LDPを直接実行する Pルーターは存在しないにもかかわらず、lagavulinには obanへの LDP学習ルートが設定されます。コアRSVP LSPに対する LDPトンネリングでは、各 LSPの LDPラベルの交換が可能です。図 3.8は、lagavulinから obanへのパスを通るパケットで発生するラベル操作を示しています。

図 3.8で、PHPが発生していることに注意してください。taliskerの最後から 2番目のホップは、macduffから blairへの RSVP LSPに対してポップして、LDPラベルだけを blairに送信しています。blairは lagavulinから obanへの LDP LSPの最後から 2番目のホップとして、LDPラベルをポップし、IPパケットだけをobanに送信しています。



10.200.86.2






IP LDP RSVPIP LDP IP

LD

P

IP

図 3.8 トンネリングされた LDPによるラベル操作

LDPトンネリングの設定が完了したら、RSVP LSPの送受信 Pルーターがそのループバックアドレス間の LDP隣接関係を形成します（隣接機器は、show ldp neighborコマンドの出力に隣接インタフェースとして lo0で表示されます）。この出力は、ldp-tunnelingを有効にする場合に必要な設定を示しています。

ps@macduff> show configuration protocols mpls label-switched-path macduff-to-blair { to 10.200.86.1; ldp-tunneling;}ps@macduff> show configuration protocols ldp interface ge-0/0/2.0;interface lo0.0;

設定の 2つの重要な部分として、まず挙げられるのが、[protocols mpls label-switched-path]階層の ldp-tunneling ステートメントです。次に挙げられるのが、LDPセッションがループバックインタフェース間で設定されるので、lo0.0インタフェースに LDPを設定する必要があるという点です。

注 macduff-to-blairと blair-to-macduffの両方の LSPが、LDPセッションで必要な双方向通信を可能にするため、ldp-tunnelingを必要としています。このどちらかの LSPに対して設定がない場合、以下に示すように、show ldp neighborコマンドで表示されるセッションには、設定がある LSPでも Label space IDは表示されず、Hold timeには 0が表示されます。

ps@macduff> show ldp neighbor Address Interface Label space ID Hold time192.168.86.2 ge-0/0/2.0 10.200.86.7:0 1410.200.86.1 lo0.0 0.0.0.0:0 0


リモート側の設定に続いて、show ldp neighborコマンドの出力に、LSPのリモートエンド（この例では、blair）の新しい LDPセッションが適切に表示されます。

ps@macduff> show ldp neighbor Address Interface Label space ID Hold time192.168.86.2 ge-0/0/2.0 10.200.86.7:0 1210.200.86.1 lo0.0 10.200.86.1:0 43

LDPで PEルーターとPルーターの間にリンクを設定すると、エッジツーエッジのLDPラベル配布が可能になります。この制御プレーンのパスが設定されると、PEルーターは相互の LDPラベルを保持することになります。実際に確認してみましょう。

ps@lagavulin> show route 10.200.86.3 inet.0:16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.3/32 *[OSPF/10] 00:00:06, metric 4 > to 192.168.86.1 via ge-0/0/2.0inet.3:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.3/32 *[LDP/9] 00:00:06, metric 1 > to 192.168.86.1 via ge-0/0/2.0, Push 104224

想定どおりに、lagavulinには、obanのループバックアドレス（10.200.86.3）のinet.3 LDPルートが設定されています。この設定では、inet.3テーブルにアクセスできるのは BGPだけなので、MPLSラベルでカプセル化されたパケットを転送できるのもBGPだけになります。MPLS情報へのアクセスを他のプロトコルに許可するには、[protocols mpls]階層に traffic-engineering bgp-igpコマンドが必要です。

ps@lagavulin> show configuration protocols mpls traffic-engineering bgp-igp;interface ge-0/0/2.0;

このコマンドを設定することで、以下に示すように、ルーターは inet.3ルーティングテーブルから inet.0にルートを移動します。

ps@lagavulin> show route 10.200.86.6 inet.0:16 destinations, 20 routes (16 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.6/32 *[LDP/9] 00:00:24, metric 1 > to 192.168.86.1 via ge-0/0/2.0, Push 104224 [OSPF/10] 00:00:24, metric 4

> to 192.168.86.1 via ge-0/0/2.0

注 traffic-engineering bgp-igpコマンドを有効にすると、ルーターは inet.3テーブルからルートを削除するので、MPLS VPNの実装によっては、支障を来す場合があります。この問題に対処するには、以下に示すように、[protocols mpls]階層に traffic-engineering bgp-ibgp-both-ribsを設定して、inet.3から inet.0にルートをコピーします。

ps@lagavulin> show route 10.200.86.6 inet.0:16 destinations, 20 routes (16 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.6/32 *[LDP/9] 00:00:05, metric 1 > to 192.168.86.1 via ge-0/0/2.0, Push 104224 [OSPF/10] 00:14:57, metric 4 > to 192.168.86.1 via ge-0/0/2.0



10.200.86.6/32 *[LDP/9] 00:00:05, metric 1 > to 192.168.86.1 via ge-0/0/2.0, Push 104224

lagavulinは、宛先が obanのパケットにラベル 104224を添付します。このラベルがmacduffに到達したときに、macduffは LDPラベルの交換と同時に、RSVP-TE LSPへのプッシュを実行する必要があります。

ps@macduff> show route label 104224 detail mpls.0:11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)104224 (1 entry, 1 announced) *LDP Preference:9 Next hop type:Router, Next hop index:477 Next-hop reference count:2 Next hop:192.168.86.13 via ge-0/0/1.0 weight 0x1, selected Label-switched-path macduff-to-blair Label operation:Swap 101440, Push 100512(top) State:<Active Int> Age:15:56 Metric:1 Task:LDP Announcement bits (1):0-KRT AS path:I Prefixes bound to route:10.200.86.6/32

macduffが RSVPラベルをスタックにプッシュして、パケットが転送されると、パスの次のルーターは最上位のラベル（この場合、RSVPラベル）だけに基づいて処理を実行します。つまり、トランジットルーター（この場合、talisker）は、カプセル化された LDPラベルを把握している必要はなく、純粋に RSVPラベルに基づいて動作するということです。

ps@talisker> show route label 100512 detail mpls.0:5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)100512 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:470 Next-hop reference count:3 Next hop:192.168.86.18 via fe-2/0/0.0 weight 0x1, selected Label-switched-path macduff-to-blair Label operation:Pop State:<Active Int> Age:1:08:28 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

この場合、taliskerの役割は、（macduff-to-blair RSVP LSPでは、最後から 2番目のホップに該当するので）RSVPラベルをポップして、パケットが blairに転送されるときに、学習された LDPラベルだけはそのままにすることです。blairは、最上位のラベル（トンネリングされた LDPセッションで学習された LDPラベル）だけに基づいて動作します。

ps@blair> show route label 101440 detail mpls.0:7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)101440 (1 entry, 1 announced) *LDP Preference:9 Next hop type:Router, Next hop index:473 Next-hop reference count:2 Next hop:192.168.86.25 via ge-6/0/0.0, selected Label operation:Pop State:<Active Int> Age:32:25 Metric:1 Task:LDP Announcement bits (1):0-KRT AS path:I Prefixes bound to route:10.200.86.6/32


blairは LDPラベルをポップして、IPパケットだけを obanに送信します。obanは、転送を目的として標準的な IPルートルックアップを実行します。この階層型の設計では、ラベルスタッキングに基づき、RSVPラベル内の LDPラベル内に IPパケットをカプセル化して、拡張性に優れたエッジツーエッジのMPLSカプセル化を実現しています。エッジツーコアのパスでは、RSVP信号が送られる LSPのトラフィックエンジニアリングや障害回復力のメリットは得られませんが、エッジの帯域幅は通常（同じ施設で比較した場合）、少なく、LAN接続は常にWAN接続よりも安定しているので、これまでに説明したMPLS機能は一般的に、エッジではそれほど重要ではありません。

MPLSスケーリングMPLSは、従来の IP方式では実現できない、さまざまな機能を提供します。この機能により、MPLSが制御負荷をネットワークに追加することが可能になり、信頼度が大幅に向上します。さらに、VPLSなど、MPLSのいくつかの機能は、通常は見ないタイプのトラフィックをネットワークに表出させます。このような機能を実現するコンポーネントごとに、ネットワークエンジニアはさまざまな拡張の問題を検討した上で、拡張に関連する要素を限定するか、その影響を軽減する目的でネットワークを設計する必要があります。ネットワークにMPLSを導入する大きなメリットの 1つは、LSPのトラフィックエンジニアリングを可能にする機能です。ただし、このメリットを実現するには、ネットワークアーキテクチャで実装をサポートする必要があります。トラフィックエンジニアリングでは、IGPの観点とトラフィックエンジニアリングデータベースの観点の両方から、ネットワークの全体図を LSPのヘッドエンドに用意する必要があります。シングルエリアOSPFまたはシングルレベル IS-IS設計を必要とします。ルーターの処理性能やメモリ容量が向上し、シングルエリアまたはシングルレベル設計のサイズ制限が大幅に緩和された結果、ネットワークの発展を考慮したときに、各機能のバランスを取る上で、拡張が重要な問題になっています。IGPはネクストホップの到達可能性だけを目的として使用し、ネットワークの到達可能性を持たせないことも重要です。そうすることで、IGP TEドメインをさらに大きなサイズに拡張できます。前述の LDP/RSVPのハイブリッド設計以外にも、RSVPの拡張メカニズムが用意されています。最も一般的に導入されている RSVPの拡張方式としては、階層型LSPと、前述の LDPトンネリング方式と同様のハイブリッド設計の 2種類が挙げられます。ただし、ハイブリッド設計では、RSVP LSPをエッジツーコアとコア内の両方で使用します。LSPのトラフィックエンジニアリングについて、この両方の方式を詳しく見ていきましょう。

階層型 LSP

階層型 LSPでは、ルーターはコアツーコア LSPをリンクとして認識できます。つまり、ルーターは IGPを介して、実際の物理回線の場合と同様に、このリンクのメトリックとトラフィックエンジニアリング特性（総帯域幅、利用可能帯域幅、管理グループ）をアドバタイズします。この設計の大きなメリットは、Pルーターで追跡する LSPの数が大幅に減少するという点です。図 3.9に、このアーキテクチャの例を示します。

注階層型 LSPを実装する場合、OSPFが必要です。

階層型 LSPの設定は 3つのステップで構成されており、そのステップはすべて、LSP-in-LSPトンネリングを提供するルーター（この場合、Pルーター）で実行します。最初のステップでは、LSPを te-linkとして設定し、リンクを TEDの他のルーターで認識できるようにします。2番目のステップでは、論理インタフェースを作成します。OSPFとRSVPの設定では、この論理インタフェースを標準の物理インタフェースの場合と同様に使用します。



lagavulin Pルーター10.200.86.7


dalwhinniePEルーター10.200.86.5

tormorePEルーター10.200.86.9

階層2 LSP

階層1 LSP

図 3.9 階層型 LSP

どのステップでも、PEルーターは関係していないことに注意してください。このようなトンネリングがコアで発生しても、PEルーターの処理に特に変化はありません。以下に示すのは、lagavulinの設定の抜粋です。太字の項目は、関連する設定部分を表しています。設定の例に続いて、付加的な情報で太字の項目について説明しています。ps@lagavulin> show configuration protocols rsvp { interface ge-0/0/1.0; interface ge-0/0/2.0; peer-interface peer-talisker;}mpls { label-switched-path lagavulin-to-talisker { to 10.200.86.4; } interface ge-0/0/1.0; interface ge-0/0/2.0;}ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0 { passive; } interface ge-0/0/1.0 interface ge-0/0/2.0; peer-interface peer-talisker; }}link-management { te-link lagavulin-to-talisker-te { local-address 192.168.87.1; remote-address 192.168.87.2; te-metric 1; label-switched-path lagavulin-to-talisker;


} peer peer-talisker { address 10.200.86.4; te-link lagavulin-to-talisker-te; }}

peer-interface設定は適切なルーティングプロトコル（OSPFおよび RSVP）にpseudoインタフェースを設定しますが、設定の link-management部分に注目してください。

まず、他の P2Pインタフェースや IPトンネルと同様に、IPアドレスで te-linkのレイヤー 3エンドポイントを指定しています（この例では、192.168.87.1と192.168.87.2）。インタフェースの OSPFメトリックの設定と同様に、このリンクのte-metricは 1に設定され、この値は他の有効なパスを比較する場合に使用されます。つまり、te-linkの te-metricは、階層型 LSPのパスに含まれるホップの合計よりも優れていることになります。lagavulinからtaliskerへの2ホップパスにはデフォルト値 2が設定されているので、より優先度の高いパスになるようにそれよりも低い値（1）を使用する必要があります。次に、te-linkは、LSPにバインドされます（この例では、lagavulin-to-talisker）。最後に、前のステップで作成された te-linkに基づいて、ピアインタフェースが生成されます。このピアインタフェースは、優先回線のOSPFおよび RSVP設定に適用されます。ピアのアドレスは、label-switched-path設定の toディレクティブと同じエンドポイントであることに注意してください。

コミット後、いくつかのコマンドは、link-managementトンネルの状況を表示します。該当するコマンドで最も役に立つのが、show link-managementコマンドです。このコマンドは、あらゆる link-management情報を 1つに集約して出力します。

ヒント一度に表示する link-managementピアと te-linkの数が多すぎる場合、peer name peer nameおよび te-link name te-link name引数を使用して、出力を限定します。

以下の出力は、lagavulinの link-management情報を示しています。ps@lagavulin> show link-management Peer name: peer-talisker, System identifier:55629 State:Up, Control address:10.200.86.4 Hello interval:150, Hello dead interval:500 TE links: lagavulin-to-talisker-te

TE link name: lagavulin-to-talisker-te, State:Up Local identifier:2684274792, Remote identifier:2684274792, Local address:192.168.87.1, Remote address:192.168.87.2, Encoding:Packet, Switching:Packet, Minimum bandwidth:0bps, Maximum bandwidth:0bps, Total bandwidth:0bps, Available bandwidth:0bps Name State Local ID Remote ID Bandwidth Used LSP-name lagavulin-to-talisker Up 14956 0 0bps Yes dalwhinnie-to-tormore

このコマンドは、te-linkピア（10.200.86.4、talisker）、トンネルのローカルアドレスとリモートアドレス（他のルーターが LSPを作成する目的で使用）、標準的なRSVPインタフェース情報（最大帯域幅や利用可能な帯域幅など）を表示します。コンテナ LSP（この例では、lagavulin-to-talisker）も表示されますが、表示される最も重要な情報は、この階層型LSPを使用しているLSPでしょう。この出力から、dalwhinnie-to-tormoreの LSPが、この LSPをトンネリングで通過していることがわかります。これで、トンネリングを実行している LSPの情報を入手したので、別のコマンドをいくつか使用して、この階層型 LSPが想定どおりに動作しているかどうか確認できます。この場合、LSPのパスを確認する方法が最も簡単です。show mpls lsp detailコマンドを使用して、dalwhinnieからのパスを確認しましょう。


ps@dalwhinnie> show mpls lsp name dalwhinnie-to-tormore detail Ingress LSP:1 sessions10.200.86.9 From:10.200.86.5, State:Up, ActiveRoute:0, LSPname: dalwhinnie-to-tormore ActivePath:(primary) LoadBalance:Random Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary State:Up SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:60) 192.168.86.29 S 192.168.87.2 S 192.168.86.33 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 192.168.86.29 192.168.87.2 192.168.86.33Total 1 displayed, Up 1, Down 0

続いて、この出力は良い兆候を示しています。具体的には、トンネルインタフェースのアドレスの 1つ（192.168.87.2）がパスに現れており、この LSPが実際に階層型 LSPをトンネリングで通過していることをほぼ確実に意味しています。この見解を詳しく検証するには、パスにまたがるラベルマッピングを追跡します。エッジツーエッジの LSPは dalwhinnieから tormoreに到達するので、以下のように、tormoreのエンドポイントアドレスを dalwhinnieの起点として使用できます。

ps@dalwhinnie> show route 10.200.86.9 detail table inet.3

inet.3:1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)10.200.86.9/32 (1 entry, 0 announced) State:<FlashAll> *RSVP Preference:7 Next-hop reference count:3 Next hop:192.168.86.29 via ge-0/0/3.0 weight 0x1, selected Label-switched-path dalwhinnie-to-tormore Label operation:Push 300000 State:<Active Int> Local AS: 1 Age:7:28 Metric:61 Task:RSVP AS path:I

protocols mpls traffic-engineering bgp-igpまたは bgp-igp-both-ribsが設定されいないため、dalwhinnieの inet.3テーブルを指定でき、MPLSルートはinet.3テーブルだけに保存されます。このルートに対して、dalwhinnieは RSVPラベル 300000を使用して、lagavulinへの接続である fe-0/2/0でパケットを転送しています。lagavulinに沿って確認すると、この設定は有用な追加情報を提供しています。lagavulinでは、show routeコマンドを使用して、label 300000のラベル交換を確認できます。

ps@lagavulin> show route label 300000 detail mpls.0:6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)300000 (1 entry, 1 announced) *RSVP Preference:7/1 Next hop type:Router, Next hop index:526 Next-hop reference count:3 Next hop:192.168.86.1 via ge-0/0/2.0 weight 0x1, selected Label-switched-path lagavulin-to-talisker Label operation:Swap 299984, Push 299920(top) State:<Active Int AckRequest> Local AS: 1 Age:7:45 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I


通常の環境では、lagavulinは単純に RSVPラベルを交換して dalwhinnie-to-tormoreの LSPに沿って転送します。ただし、この例で実際に目にするのは、少し異なる処理です。lagavulinは代わりに交換とプッシュを実行して、最後にlagavulin-to-taliskerの階層型 LSPでパケットを転送します。この処理は、以前に説明した LDPトンネリングメカニズムと似ている部分があります。LSPが実際に別の LSPをトンネリングしているかどうか確信が持てない場合は、階層型 LSPのパスに存在するトランジットPが決定的な証拠になります。この例では、macduffで証明されています。

ps@macduff> show mpls lsp Ingress LSP:0 sessionsTotal 0 displayed, Up 0, Down 0


Transit LSP:2 sessionsTo From State Rt Style Labelin Labelout LSPname 10.200.86.4 10.200.86.7 Up 1 1 FF 299920 3 lagavulin-to-talisker10.200.86.7 10.200.86.4 Up 1 1 FF 299936 3 talisker-to-lagavulinTotal 2 displayed, Up 2, Down 0

LSPが実際にトンネリングを行っていなかった場合、macduffはそのことを把握している必要がありますが、実際には把握していません。把握しているのは、lagavulinから taliskerおよびこの逆方向のコア（階層型）LSPの情報だけです。つまり、dalwhinnie-to-tormoreの LSPは、エッジ PEまたはトランジットPルーターが特に認識することはなく、実際に lagavulin-to-taliskerの LSPをトンネリングで通過しているのです。

階層型 LSPは、MPLSネットワークを RSVP-TEだけが満たせる要件とともに管理する上で、強力なツールになります。

階層型 RSVPドメイン

コアツーエッジの RSVP LSP分離は、RSVPドメインを拡張する場合のオプションでもあります。図 3.10に示す設計では、最も近いコアルーターへの RSVP-TE LSPがエッジルーターに設定されており、コアルーターによってフルメッシュが形成されています。このシングルホップ LSPの分離によって、任意の Pルーターで他のPルーターとダウンストリーム PEの数だけ LSPをサポートするだけでよくなるので、拡張が可能になります。以前に説明した LDP/RSVPハイブリッドアーキテクチャに対する、この設計のメリットは、リンクプロテクションやリンクノードプロテクションのような LSPプロテクションメカニズムでパスの各ホップを保護できることです。また、コアでのトラフィックエンジニアリングや、エッジでの限定的なトラフィックエンジニアリングも可能になります。重要なポイントとして、コアツーエッジの RSVP LSP分離設計では、エンドツーエンドのMPLSパスが存在しないので、MPLSベースの VPNサービスをサポートしません。図 3.10では、PEは LSPを介して、隣接するコア Pルーターにトラフィックを転送しています。この例では、エッジツーコアの LSPがシングルホップであるので、ルーターはラベルをスタックにプッシュしません（エッジルーターは基本的に、最後から2番目のルーターに該当するため）。パケットがPルーターに到達すると、Pルーターはコアの LSPを介してパケットを転送し、コアを通過させ、終端の Pルーターはコアツーエッジの LSPでパケットを転送します。

注この設計が有効に機能するには、protocols ospf|isis traffic-engineering shortcuts

および protocols mpls traffic-engineering bgp-igp-both-ribsの両方が必要です。



10.200.86.2






Pushプッシュ

ポップ

ポップ、プッシュスワップ

ラベル操作

階層2 LSP

階層1 LSPIP RSVP

IP RSVP

IP RSVP

IP

RS

VP

図 3.10 エッジツーコアおよびコアツーコアの LSP

図 3.10に示すネットワークに基づいて、lagavulinに入力されて obanから出力されるパケットのフローを順番に確認しましょう。このパケットの宛先は 4.2.2.1であり、obanが4.2.2.0/24をBGP経由でアドバタイズします。lagavulinが IPルートルックアップを実行して、4.2.2.0/24のネクストホップは obanのループバックアドレス 10.200.86.3/32であることが判明します。実際に確認してみましょう。

ps@lagavulin> show route 4.2.2.1 detail inet.0:34 destinations, 45 routes (34 active, 0 holddown, 0 hidden)4.2.2.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Next hop type:Indirect Next-hop reference count:3 Source:10.200.86.3 Next hop type:Router, Next hop index:465 Next hop:192.168.86.1 via ge-0/0/2.0 weight 0x1, selected Label-switched-path lagavulin-to-macduff Protocol next hop:10.200.86.3 Indirect next hop:8a6d000 131070 State:<Active Int Ext> Local AS: 1 Peer AS: 1 Age:48:33 Metric2:4 Task:BGP_1.10.200.86.3+51109 Announcement bits (2):0-KRT 4-Resolve tree 2 AS path:I Localpref:100 Router ID:10.200.86.3

次に、lagavulinがこのアドレスに対する再帰的なルックアップを実行して、lagavulin-to-macduffの PE-to-P LSP経由で転送する必要があることが判明します。以前に説明した PHPの動作が原因で、以下の出力にラベル情報が表示されていないことに注意してください。

ps@lagavulin> show route 10.200.86.3 detail inet.0:16 destinations, 18 routes (16 active, 0 holddown, 0 hidden)10.200.86.3/32 (1 entry, 1 announced) *OSPF Preference:10 Next hop type:Router, Next hop index:462


Next-hop reference count:24 Next hop:192.168.86.1 via ge-0/0/2.0 weight 0x1, selected Label-switched-path lagavulin-to-macduff State:<Active Int> Age:13:03 Metric:4 Area:0.0.0.0 Task:OSPFv2 Announcement bits (1):0-KRT AS path:I

macduffは IPパケットを受信し、プライマリおよび再帰的なルートルックアップを実行して、blairを終端とするコアの LSP経由で、このパケットを転送する必要があることが判明します。

ps@macduff> show route 10.200.86.3 detail inet.0:18 destinations, 25 routes (18 active, 0 holddown, 0 hidden)10.200.86.3/32 (1 entry, 1 announced) *OSPF Preference:10 Next hop type:Router, Next hop index:472 Next-hop reference count:10 Next hop:192.168.86.13 via ge-0/0/1.0 weight 0x1, selected Label-switched-path macduff-to-blair Label operation:Push 100544 State:<Active Int> Age:10:19 Metric:3 Area:0.0.0.0 Task:OSPFv2 Announcement bits (1):0-KRT AS path:I

この LSPの ERO（Explicit Route Object）は、LSPの使用パスを示しています。ps@macduff> show mpls lsp detail name macduff-to-blair | resolve Ingress LSP:5 sessionsblair From: macduff, State:Up, ActiveRoute:0, LSPname: macduff-to-blair ActivePath:(primary) LoadBalance:Random Autobandwidth AdjustTimer:3600 secs Max AvgBW util:0bps, Bandwidth Adjustment in 886 second(s). Overflow limit:0, Overflow sample count:0 Encoding type:Packet, Switching type:Packet, GPID:IPv4 *Primary State:Up SmartOptimizeTimer:180 Computed ERO (S [L] denotes strict [loose] hops):(CSPF metric:20) talisker S blair S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 192.168.86.13 192.168.86.18Total 1 displayed, Up 1, Down 0Egress LSP:5 sessionsTotal 0 displayed, Up 0, Down 0Transit LSP:4 sessionsTotal 0 displayed, Up 0, Down 0

さらに、taliskerを通過することになるので、100544のラベル操作を見ていきましょう。

ps@talisker> show route label 100544 detail mpls.0:5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)100544 (1 entry, 1 announced) *RSVP Preference:7 Next hop type:Router, Next hop index:464 Next-hop reference count:3


Next hop:192.168.86.18 via fe-2/0/0.0 weight 0x1, selected Label-switched-path macduff-to-blair Label operation:Pop State:<Active Int> Age:17:58 Metric:1 Task:RSVP Announcement bits (1):0-KRT AS path:I

想定どおりに、taliskerは最後から 2番目のホップとして、パケットのラベルをPHP（Penultimate Hop Pop）処理してから、IPパケットだけを blairに転送します。ルートルックアップ処理が blairで繰り返されて、パケットを blair-to-obanの P to PE LSPで転送するよう指示します。

ps@blair> show route 10.200.86.3 detail inet.0:18 destinations, 25 routes (18 active, 0 holddown, 0 hidden)10.200.86.3/32 (2 entries, 1 announced) State:<FlashAll> *RSVP Preference:7 Next hop type:Router, Next hop index:475 Next-hop reference count:6 Next hop:192.168.86.25 via ge-6/0/0.0 weight 0x1, selected Label-switched-path blair-to-oban State:<Active Int> Age:12:18 Metric:1 Task:RSVP Announcement bits (2):0-KRT 2-OSPFv2 AS path:I

一連の LSPにより、lagavulinはエンドツーエンドの LSPを使用せずに、RSVP信号が送られる LSP経由でパケットを obanに転送できました。この設計は一般的ではありますが、あらゆるルーター（PルーターおよびPEルーターも同様）でルーティングテーブルを保持する必要があります。これは、PE-to-Pおよび P-to-PのLSPの末端として、Pルーターが IPルートルックアップを実行する必要があるからです。図 3.10は、この概念を示しています。

RSVPリフレッシュ削減

RSVPのデフォルトでは、一時的なメッセージングを定期的に実行することで、予約情報を維持するとともに、隣接機器間で制御メッセージを交換します。この一時的なメッセージングは、拡張性の問題に加えて、信頼性や遅延の問題の原因になる可能性があります。拡張性の問題は RSVPリフレッシュメッセージの送信および処理に起因し、拡張の問題は RSVPセッションの数に起因します。PathTearやPathErrメッセージなど、ワンタイムメッセージが失われた場合や、遅延障害が検出された場合（定期リフレッシュタイマーが動作しなかった結果による）にもトラフィックに影響を及ぼす可能性があります。つまり、メッセージング特有の遅延が原因で、検出に遅延が発生しやすくなるということです。このようなメッセージの拡張性と信頼性を向上させるため、RFC 2961では、信頼できるメッセージ、バンドルメッセージ、サマリーリフレッシュメッセージという、RSVPの 3つの新しい拡張機能が規定されています。

� 信頼できるメッセージ：このメッセージは、MESSAGE_IDオブジェクトをRSVPメッセージに導入することで、RSVPメッセージ交換の信頼性を向上させます。ACK_Desiredフィールドが RSVPメッセージで設定されている場合、受信側はMESSAGE_IDを含むMESSAGE_ID_ACKメッセージで応答し、受信側でのメッセージの受信確認を可能にします。

� バンドルメッセージ：バンドルメッセージは、複数の標準的な RSVPメッセージを単一のメッセージにグループ化します。グループ化される標準的な RSVPメッセージの例として、Path、PathErr、Resv、ResvTear、ResvErr、ResvConf、ACKメッセージなどが挙げられます。


� サマリーリフレッシュメッセージ：サマリーリフレッシュメッセージは、複数のPathおよび Resvメッセージを単一の更新に集約します。MESSAGE_IDはPathまたは Resvの状態にマッピングされ、サマリーリフレッシュメッセージに含まれているMESSAGE_IDは関連する Pathまたは Resvの状態を更新する目的で使用されます。

テストの結果、約 7500個の LSPで毎秒約 235個の RSVPメッセージが必要になることが判明しています。以下の出力は、obanが 119秒間に約 28000個のRSVPメッセージを受信したことを示しています。

ps@oban> show rsvp session | count Count:7442 linesps@oban> show system uptime | match currentCurrent time:2010-12-09 22:18:30 UTCps@oban> show rsvp statistics | match "^ Path |Sent.*Received"Sent Received Sent ReceivedPath 0 1 0 0ps@oban> show system uptime | match currentCurrent time:2010-12-09 22:20:29 UTCps@oban> show rsvp statistics | match "^ Path |Sent.*Received"Sent Received Sent ReceivedPath 3 27978 0 1269

この負荷を削減するオプションがあれば、ルーティングエンジンの処理が大幅に省力化されます。RSVPリフレッシュ削減の設定は、極めてシンプルです。aggregate

ステートメントを追加して、[protocols rsvp]階層のインタフェースに適用するだけで済みます。たとえば、obanでは、ge-0/0/2.0に、この設定が含まれています。ps@oban> show configuration protocols rsvp interface ge-0/0/2.0 { aggregate;}

この RSVPインタフェースで RSVPリフレッシュ削減を有効にした場合、毎秒のパケット数は約 12に低下します。RSVPリフレッシュ削減によって、ルーティングエンジンで伝送処理する必要があるRSVPパケットを 95%も削減したことになります。

ps@oban> show system uptime | match currentCurrent time:2010-12-09 22:40:31 UTC

ps@oban> show rsvp statistics | match "^ Path |Sent.*Received" Sent Received Sent Received Path 0 0 0 0

ps@oban> show system uptime | match currentCurrent time:2010-12-09 22:42:29 UTC

ps@oban> show rsvp statistics | match "^ Path |Sent.*Received" Sent Received Sent Received Path 3 1560 0 4

まとめると、メッセージングの削減によってネットワークのオーバーヘッドが減少し、MESSAGE_IDおよびMESSAGE_ID_ACKオブジェクトの追加によって信頼できるメッセージが提供され、障害検知やネットワーク輻輳の改善が可能になります。


BGPの考慮事項もう 1つ、MPLSネットワークの重要な考慮事項として、特にルートリフレクションを利用する環境に BGPを導入した場合のMPLSの影響が挙げられます。このセクションでは、ルートリフレクタでの VPNのネクストホップ解決と、BGPのルートターゲットファミリの両方について詳しく説明します。

VPN環境でのルートリフレクション

MPLS VPN環境で BGPを拡張する場合、ネットワークを検討する上で、ネットワークのMPLSのネクストホップ到達可能性が重要な特性になります。ルートリフレクションを BGPの拡張メカニズムとして使用する場合、MPLS VPNルートをリフレクトする対象である PEルーターを網羅したMPLSラベル情報をルートリフレクタに用意する必要があります。PEのMPLSラベルがルートリフレクタに存在しない場合、ネクストホップのタイプが UnusableであるVPNルートは無効になります。

PEルーターのMPLSラベル情報をルートリフレクタに提供する方法は、2種類あります。どちらの方法を選択するかは、使用するラベル配布メカニズムによって決まります。LDP環境では、ルートリフレクタをそのまま LDPに参加させるだけで、VPNルートのネクストホップを解決する場合に必要な inet.3ルートが提供されます。RSVP限定の環境では各 PEからルートリフレクタへの LSPが必要になるので、RSVP環境で inet.3ルーティング情報を提供する処理は少し複雑になります。少し時間をかけて、図 3.11を確認しましょう。


10.200.86.2






VPN1-CE2

VPN1-CE1

図 3.11 ルートリフレクションを含むMPLS VPN

このネットワークでは、2台の PEルーター（lagavulinとoban）が同じ 4364スタイルの VPN（VPN-1）で単一の CEをサポートしています。この 2台の PEルーターは、blairで処理されるルートリフレクタ経由で BGPルートを共有しています。ルートリフレクタに対するMPLSが存在しなければ、ルートリフレクタが VPNルートを無効にするので、この無効になったルートが他の PEにアドバタイズされることはありません。

この show routeの出力は、PEルーターのループバックアドレスが（LDPやRSVPではなく）OSPF経由でのみ認識されることを示しています。


ps@blair> show route 10.200.86.3 inet.0:18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.3/32 *[OSPF/10] 01:44:13, metric 1 > to 192.168.86.25 via 6/0/0.0

ps@blair> show route 10.200.86.7 inet.0:18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.7/32 *[OSPF/10] 01:42:44, metric 3 to 192.168.86.49 via ge-0/0/2.0 > to 192.168.86.17 via ge-0/0/3.0

MPLSが存在しないルートリフレクタでは、非表示のルートがどのように認識されるのかという例を紹介しましょう。この例からわかるように、ネクストホップのタイプはUnusableです。

ps@blair> show route protocol bgp hidden detail inet.0:18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)__juniper_private2__.inet.0:1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)bgp.l3vpn.0:2 destinations, 2 routes (0 active, 0 holddown, 2 hidden)1:1:1.1.1.0/24 (1 entry, 0 announced) BGP Preference:170/-101 Route Distinguisher:1:1 Next hop type:Unusable Next-hop reference count:2 State:<Hidden Int Ext> Local AS: 1 Peer AS: 1 Age:1:18:09 Task:BGP_1.10.200.86.7+179 AS path:I Communities: target:1:1 VPN Label:16 Localpref:100 Router ID:10.200.86.71:2:2.2.2.0/24 (1 entry, 0 announced) BGP Preference:170/-101 Route Distinguisher:1:2 Next hop type:Unusable Next-hop reference count:2 State:<Hidden Int Ext> Local AS: 1 Peer AS: 1 Age:1:18:13 Task:BGP_1.10.200.86.6+179 AS path:I Communities: target:1:1 VPN Label:16 Localpref:100 Router ID:10.200.86.3

このパスは使用不可であるので、ルートリフレクタは、このルートを PEルーターにアドバタイズしません。

ps@blair> show route advertising-protocol bgp 10.200.86.3ps@blair> show route advertising-protocol bgp 10.200.86.7 ps@blair>

ただし、ネットワークをまたがって LDPを有効にすると、PEへのMPLSパスがルートリフレクタに設定されるので、この問題は解決されます。LDPが有効になると、隣接するルーターは PEループバックのラベルをアドバタイズします（わかりやすくするため、LDPルートを太線で示しています）。

ps@blair> show route 10.200.86.3 inet.0:18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)


+ = Active Route, - = Last Active, * = Both10.200.86.3/32 *[OSPF/10] 01:46:16, metric 1 > to 10.100.7.3 via ge-6/0/0.0inet.3:5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.3/32 *[LDP/9] 00:01:15, metric 1 > to 10.100.7.3 via ge-6/0/0.0ps@blair> show route 10.200.86.7 inet.0:18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.200.86.7/32 *[OSPF/10] 01:46:18, metric 3 to 192.168.86.49 via ge-0/0/2.0 > to 192.168.86.17 via ge-0/0/3.0 inet.3:5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.7/32 *[LDP/9] 00:01:17, metric 1 > to 192.168.86.49 via ge-0/0/2.0, Push 103168 to 192.168.86.17 via ge-0/0/3.0, Push 100592

以下に示すように、アドバタイズ元の PEルーターへの新しいMPLSパスにより、ルートリフレクタは VPNルートをアクティブとしてマークし、対向の PEルーターへのアドバタイズを開始します。

ps@blair> show route protocol bgp detail inet.0:18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)inet.3:5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)__juniper_private2__.inet.0:1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)mpls.0:8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)bgp.l3vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)1:1:1.1.1.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Route Distinguisher:1:1 Next hop type:Indirect Next-hop reference count:1 Source:10.200.86.7 Protocol next hop:10.200.86.7 Push 16 Indirect next hop:2 no-forward State:<Active Int Ext> Local AS: 1 Peer AS: 1 Age:12:25 Metric2:1 Task:BGP_1.10.200.86.7+56251 Announcement bits (1):0-BGP RT Background AS path:I Communities: target:1:1 VPN Label:16 Localpref:100 Router ID:10.200.86.7 1:2:2.2.2.0/24 (1 entry, 1 announced) *BGP Preference:170/-101 Route Distinguisher:1:2 Next hop type:Indirect Next-hop reference count:1 Source:10.200.86.3 Protocol next hop:10.200.86.3 Push 16 Indirect next hop:2 no-forward State:<Active Int Ext> Local AS: 1 Peer AS: 1 Age:1:32:20 Metric2:1


Task:BGP_1.10.200.86.6+179 Announcement bits (1):0-BGP RT Background AS path:I Communities: target:1:1 VPN Label:16 Localpref:100 Router ID:10.200.86.3

ps@blair> show route advertising-protocol bgp 10.200.86.7 bgp.l3vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 1:1:1.1.1.0/24 * 10.200.86.7 100 Ips@blair> show route advertising-protocol bgp 10.200.86.3 bgp.l3vpn.0:2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 1:2:2.2.2.0/24 * 10.200.86.3 100 I

この状況は明らかに、RSVP限定のネットワークとは異なっています。RSVPネットワークは、以下で説明するステップを通信事業者が実施していない限り、ルートリフレクタからPEルーターへの LSPを必要とします。


10.200.86.2

blair Pルータールートリフレクタ10.200.86.1





VPN1-CE2

VPN1-CE1

図 3.12 ルートリフレクションとRSVPを含むMPLS VPN

図 3.12の重要なポイントは、アドバタイズ元の PEルーターのネクストホップへのMPLSパスをルートリフレクタに設定する必要があるという点です（後で説明するように、少なくとも設定されているという想定です）。LDPは確かにシンプルなモデルですが、ネットワークのMPLS設計とは適合しない可能性があります。

ルートリフレクタでの VPNのネクストホップ解決を可能にする場合

注この推奨事項は、ルートリフレクタが転送プレーンに存在しないか、ルートリフレクタが純粋な Pルーターである環境に特有のものです。


前述のように、ルートリフレクタは、VPNルートを検証するため、PEルーターへのMPLSパスがあると認識する必要があります。前のセクションでは、実際に PEルーターへのMPLSパスをルートリフレクタに設定する方法を説明しましたが、このセクションでは、このパスがあるとルートリフレクタに認識させる方法を説明します。この動作を実現する方法には、2種類あります。最初の方法では、[routing-options]階層にある Junosの resolutionキーワードを使用します。2番目の方法では、さらに複雑な設計で rib-groupsを使用します。resolution機能は、PEへのMPLS到達可能性がないルートリフレクタで、ネクストホップ到達可能性を検証して、他の PEへの VPNルートのアドバタイズを可能にする最も簡単な方法です。前に確認したように、ネクストホップが解決されなければ、VPNルートは Unusableとして表示され、ルートの設定やアドバタイズは実行できません。bgp.l3vpn.0テーブルで、別のルーティングテーブルを使用して解決できるようにすることで、この問題を簡単に解決できます。解決策を実施する前に、Unusableパスが原因で、ルートリフレクタが VPNルートを無効にしていることを確認しましょう（重要情報は太字で示しています）。

ps@blair> show bgp summary Groups:1 Peers:2 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 2 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.86.3 1 82 83 0 2 35:18 Establ inet.0:0/0/0 bgp.l3vpn.0:0/1/010.200.86.7 1 80 81 0 10 34:36 Establ inet.0:0/0/0 bgp.l3vpn.0:0/1/0

この例の設定は、inet.0を使用して bgp.l3vpn.0ルーティングテーブルのルートを解決するよう、ルーターに指示しています。ps@blair> show configuration routing-options router-id 10.200.86.1;autonomous-system 1;resolution { rib bgp.l3vpn.0 { resolution-ribs inet.0; }}

コミット後、ルートリフレクタはルートを検証して、他の PEへのアドバタイズを開始できる状態になります（わかりやすくするため、関連情報は太字で示しています）。

ps@blair> show bgp summary Groups:1 Peers:2 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 2 2 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.86.3 1 86 87 0 2 36:54 Establ inet.0:0/0/0 bgp.l3vpn.0:1/1/010.200.86.7 1 84 85 0 10 36:12 Establ inet.0:0/0/0 bgp.l3vpn.0:1/1/0

これは、シンプルなアプローチでした。rib-groupsを利用して inet.0ルーティング情報を inet.3と共有し、VPNルートの検証を可能にするような、さらに複雑な設計を使用することも可能です。ただし、rib-groupsは Junos OSの概念の中でも、内容がわかりにくく、誤解されることが多いので、細かい点を説明する前に、rib-


groupsの一般的な内容について、さらに詳しく説明しておく必要があるでしょう。

rib-groupsはルーティングテーブルの集合であり、特に複数のルーティングテーブルでルーティングプロトコルによるルートの設定を可能にします。rib-groupsには、他にもさまざまなアプリケーションがありますが、現在の目的上、rib-groupをわかりやすく説明するため、特定のユースケースに注目しましょう。OSPFルートをinet.0とinet.3の両方に設定する必要があるとします。この場合、処理は2つのステップで実行します。まず、rib-groupを作成してから、新しく作成した rib-groupにルートを設定するよう、ルーティングプロトコルに指示します。

注 rib-groupを作成するには、rib-groupの名前を設定する必要があります。任意の名前を指定できますが、わかりやすい名前を指定しておけば、運用時に役立ちます。

最初に表示されるルーティングテーブルは、プライマリテーブル（プロトコルのインスタンスに対するデフォルトのテーブル）です。この例では、OSPFインスタンスがメイン（inet.0）ルーティングインスタンスで動作しているので、inet.0がプライマリテーブルです。rib-groupの設定には、最初にプライマリルーティングテーブル、さらに後続のテーブルが含まれており、以下のようになります。ps@blair> show configuration routing-options rib-groups { inet.0-to-inet.3 { import-rib [ inet.0 inet.3 ]; }}

inet.0テーブルにルートを設定するだけでなく（デフォルトの OSPFの動作）、inet.0-to-inet.3 rib-groupにもルートを設定することをOSPFが認識している必要があります。具体的には、[protocols ospf]階層に rib-groupステートメントを使用します。ps@blair> show configuration protocols ospf rib-group inet.0-to-inet.3;area 0.0.0.0 { interface ge-0/0/1.0 { interface-type p2p; } interface ge-0/0/2.0 { interface-type p2p; } interface ge-0/0/3.0 { interface-type p2p; } interface ge-6/0/0.0 { interface-type p2p; } interface lo0.0;}

この変更後、inet.0 OSPFルートは inet.3テーブルに存在しています（以下の出力は、brevityのルーティングテーブルの一部だけを示しています）。

ps@blair> show route table inet.3 inet.3:12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.5/32 *[OSPF/10] 00:03:29, metric 1 > to 192.168.86.10 via ge-0/0/1.010.200.86.6/32 *[OSPF/10] 00:03:29, metric 1 > to 192.168.86.10 via ge-0/0/1.0192.168.86.12/30 *[OSPF/10] 00:03:29, metric 3 > to 192.168.86.49 via ge-0/0/2.0


to 192.168.86.17 via ge-0/0/3.0 […]

PEループバックが inet.3テーブルに存在しているので、ルートリフレクタは VPNルートのネクストホップを解決して、以下のように、他の PEに対して設定およびアドバタイズできます。

ps@blair> show bgp summary Groups:1 Peers:2 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 2 2 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.86.3 1 225 236 0 2 1:38:53 Establ inet.0:0/0/0 bgp.l3vpn.0:1/1/010.200.86.7 1 225 234 0 10 1:38:11 Establ inet.0:0/0/0 bgp.l3vpn.0:1/1/0

この設定の結果、あらゆるOSPFルートが inet.3にコピーされますが、この処理は不要です。サマリー出力からわかるように、/32のループバックルートに加えて、/30の接続ネットワークも存在しています。inet.3テーブルでは、このようなルートは不要であり、実際に必要とされるのは、/32のループバックルートだけです。

Junosには、この問題の解決策として、inet.3テーブルのデフォルトルートをそのまま使用する方法と、この方法よりも複雑な、ルートのコピーをポリシーによって制御する方法の 2種類が用意されています。

Junosでは、ユーザーが個別の ribテーブルにスタティックルートを設定できます。具体的には、[routing-options]階層に設定します。以下の設定は、この設定の例を示しています。routing-options { rib inet.3 { static { route 0.0.0.0/0 discard; } }}

さらに詳細な制御を目的として、inet.3テーブルへのルートのコピーをポリシーで制限できます。このポリシーは他のルーティングポリシーと似ていますが、import-

policyステートメントで rib-groupに適用されるという点が異なります。この例のネットワークでは、すべてのループバックが 10.200.86.0/24サブネットからアドレスを受信しているので、ポリシーによるルートのコピーの制御はかなりシンプルになります。以下の設定の抜粋は、このアプローチの例を示しています。ps@blair> show configuration policy-options policy-statement Loopbacks-Only term Loopbacks { from { route-filter 10.200.86.0/24 prefix-length-range /32-/32; } then accept;}term Reject-All-Else { then reject;}

ポリシーが一致するのは、以下に示すように、10.200.86/24サブネットの /32のルートだけです。


ps@blair> show configuration routing-options rib-groups { inet.0-to-inet.3 { import-rib [ inet.0 inet.3 ]; import-policy Loopbacks-Only; }}

これで、ルーターが inet.0から inet.3にコピーするルートをフィルタリングするので、inet.3に含まれているのは PEループバックアドレスだけになります。

ps@blair> show route table inet.3 inet.3:5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.200.86.2/32 *[OSPF/10] 00:00:58, metric 1 > to 10.100.7.17 via ge-0/0/1.40210.200.86.3/32 *[OSPF/10] 00:00:58, metric 1 > to 10.100.7.6 via ge-0/0/1.40510.200.86.4/32 *[OSPF/10] 00:00:58, metric 1 > to 10.100.7.10 via ge-0/0/1.40410.200.86.7/32 *[OSPF/10] 00:00:58, metric 3 to 10.100.7.17 via ge-0/0/1.402 > to 10.100.7.10 via ge-0/0/1.40410.200.86.8/32 *[OSPF/10] 00:00:58, metric 2 to 10.100.7.17 via ge-0/0/1.402 > to 10.100.7.10 via ge-0/0/1.404

前述のように、このプロセスでは、以下に示すように、PEによるVPNルートの設定およびアドバタイズが可能になります。

ps@blair> show bgp summary Groups:1 Peers:2 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 2 2 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.86.3 1 243 256 0 2 1:47:11 Establ inet.0:0/0/0 bgp.l3vpn.0:1/1/010.200.86.7 1 244 255 0 10 1:46:29 Establ inet.0:0/0/0 bgp.l3vpn.0:1/1/0

この 2つの方法では、同じ基本的な目的が達成されて、PEループバックのMPLS情報を必要とせずに、ルートリフレクタでの VPNネクストホップの解決が可能になります。Junosの routing-options resolutionキーワードを設定する方がシンプルなアプローチですが、rib-groupsの方は詳細な制御を可能にします。ただし、複雑性は増します。ほとんどの環境では、routing-options resolutionの方が適しています。

BGPのルートターゲットファミリ

VPNのトピックを終える前に、もう 1つの拡張関連の問題として、PE間（これには規模的に及ばないものの、PEとルートリフレクタ間）でアドバタイズされるルートの数を取り上げます。VPNでの PEルーターのデフォルト動作は、family inet-vpnで設定されたピアにすべての VPNルートをアドバタイズするという処理です。さらに、ローカル VPNのインポートポリシーに基づいて、受信側の PEで保持するルートと無視するルートが決定されます。

ただし、Junosでは、この拡張関連の問題に対して、route-targetという新しいBGPファミリの形で回答が用意されています。ルートリフレクションを使用しないネットワークでは通常、この機能を使用し、ルートリフレクタを使用するネットワークでは、適切な配信を保証するため、あらゆるVPNルートを受信する必要があると考えられます。


ルートリフレクション環境で route-targetファミリを使用することが望ましい場合、Junosの advertise-defaultコマンドを使用します。Junosの advertise-default

route-targetキーワードは、すべての指定を無効にして、デフォルト（0:0:0/0）の route-targetをアドバタイズします。この結果、それぞれの route-targetを個別に指定しなくても、ルートリフレクタは、あらゆるルートターゲットからルートを受信できるようになります。この考え方を正確に示すため、図 3.13では、ネットワークに変更を加えています。具体的には、ルートリフレクタを削除して、PEルーターが直接ピアを確立する必要があるようにしています。さらに、ルートターゲット機能の仕組みを示すため、2台の新しい PEルーターをネットワークに追加しています。


10.200.86.2






CE11(maple-l3vpn)

CE5(aspen-l3vpn)

CE12(maple-l3vpn)

CE2(aspen-l3vpn)

CE7(aspen-l3vpn)


glenlivetPルーター

10.200.86.6


図 3.13 ルートターゲットベースのトポロジー

図 3.13のトポロジーには、dalwhinnie、lagavulin、および obanに存在するaspenと、dalwhinnieおよび tormoreに存在するmapleという 2つの VPNが含まれています。この設計に基づいて考えると、obanとlagavuliはaspenのルートだけを必要とし、tormoreはmapleのルートだけを必要とし、dalwhinnieはこの両方のルートを必要とします。デフォルトの環境では、特定のターゲットとのVPNのインポートルートがリモートPEに設定されているかどうかに関係なく、4台の PEルーターがすべての VPNルートを他のすべての PEルーターにアドバタイズします。たとえば、tormoreを使用する場合、tormoreのmapleのルートに関係するリモートPEは dalwhinnieだけですが、以下に示すように、tormoreはmapleのルートを 3台すべての PEルーターにアドバタイズします。

ps@tormore> show bgp summary Groups:1 Peers:3 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendingbgp.l3vpn.0 1 1 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.86.3 1 19 20 0 0 7:36 Establ bgp.l3vpn.0:0/0/010.200.86.5 1 18 20 0 0 7:30 Establ bgp.l3vpn.0:1/1/0 maple.inet.0:1/1/010.200.86.7 1 20 21 0 0 7:42 Establ


bgp.l3vpn.0:0/0/0

ps@tormore> show route advertising-protocol bgp 10.200.86.3 ß obanmaple.inet.0:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 5.5.5.0/24 Self 100 I

ps@tormore> show route advertising-protocol bgp 10.200.86.5 ß dalwhinniemaple.inet.0:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 5.5.5.0/24 Self 100 I

ps@tormore> show route advertising-protocol bgp 10.200.86.7 ß lagavulinmaple.inet.0:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 5.5.5.0/24 Self 100 I

この例からわかるように、使用することがないにもかかわらず、obanと lagavulinはmapleの5.5.5.0/24ルートを受信しています。このような場合に、ルートターゲットファミリを使用します。JunosのルートターゲットBGPファミリを使用すると、インポートする対象の VPNルートターゲットを PEルーターから他の PEルーターに通知することが可能になります。つまり、リモートPEルーターが VPNルートのアドバタイズを、受信 PEが使用するものに限定して実行できるということです。この設定はシンプルであり、route-targetステートメントを適切な BGPグループ、この例では、ibgp bgp groupに追加するだけで済みます（アドバタイズされたルートターゲットのルートは、bgp.rtarget.0 route-tableで保持されます）。 ps@tormore> show configuration protocols bgp group ibgp { type internal; local-address 10.200.86.9; family inet-vpn { unicast; } family route-target; neighbor 10.200.86.7; neighbor 10.200.86.3; neighbor 10.200.86.5;}

設定後、show route table bgp.rtarget.0コマンドを使用して、学習されたルートターゲットを表示します。以下に示すのは、tormoreからコマンドを実行した場合の例です。

ps@tormore> show route table bgp.rtarget.0 bgp.rtarget.0:2 destinations, 5 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both1:1:1/96 *[BGP/170] 00:01:58, localpref 100, from 10.200.86.3 AS path:I > to 192.168.86.38 via ge-0/0/3.0 [BGP/170] 00:01:54, localpref 100, from 10.200.86.5 AS path:I > to 192.168.86.38 via ge-0/0/3.0, Push 100496 to 192.168.86.34 via ge-0/0/2.0, Push 655505 [BGP/170] 00:02:03, localpref 100, from 10.200.86.7 AS path:I > to 192.168.86.34 via ge-0/0/2.0, Push 6554891:2:2/96 *[RTarget/5] 00:02:15 Local [BGP/170] 00:01:54, localpref 100, from 10.200.86.5 AS path:I > to 192.168.86.38 via ge-0/0/3.0, Push 100496 to 192.168.86.34 via ge-0/0/2.0, Push 655505


この出力をよく確認すると、いくつかの重要な項目が明らかになります。第 1に、10.200.86.3（oban）、10.200.86.5（dalwhinnie）、および 10.200.86.7（lagavulin）のすべてに、1:1のルートターゲットとの VRFのインポートルートが設定されています。第 2に、10.200.86.5（dalwhinnie）は 2:2のターゲットとのルートを使用しています。localは、ローカルルーター（tormore）が 2:2のターゲットとのルートもインポートしていることを示しています。

この情報に基づいて、PEルーターは、PEがアドバタイズしたルートターゲットを条件にして、リモートPEへの VPNルートのアドバタイズをフィルタリングできます。これで、Junosのルートターゲットファミリが有効になり、tormoreは VPNルートを的確にアドバタイズします。つまり、以下に示すように、mapleのルートだけを dalwhinnieにアドバタイズします。

ps@tormore> show route advertising-protocol bgp 10.200.86.3 ß obanbgp.rtarget.0:2 destinations, 5 routes (2 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path1:2:2/96 * Self 100 Ips@tormore> show route advertising-protocol bgp 10.200.86.5 ß dalwhinniemaple.inet.0:3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path* 5.5.5.0/24 Self 100 Ibgp.rtarget.0:2 destinations, 5 routes (2 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path1:2:2/96 * Self 100 Ips@tormore> show route advertising-protocol bgp 10.200.86.7 ß lagavulinbgp.rtarget.0:2 destinations, 5 routes (2 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path1:2:2/96 * Self 100 I

この例からわかるように、この一連の手順により、どれほど大規模な VPNの導入事例でも、ネットワークのオーバーヘッドを大幅に削減できます。

VPLS

VPLSは、他のレイヤー 2 VPN技術を凌ぐ、大幅な機能と柔軟性の向上を実現しますが、拡張性にいくつかの問題があります。最も大きな問題は、ブロードキャスト、不明なユニキャスト、およびマルチキャストトラフィック（親しみを込めて、BUMトラフィックと呼ばれる）の管理方法です。このようなタイプのトラフィックは一般的な環境で使用されるとともに、あらゆるリモートサイトに拡散されるので、特にVPLS環境では問題になります。

P2MP（Point-to-Multipoint）LSPは BUMトラフィックを効果的に拡散して、ネットワークの負荷とファイアウォールフィルタを削減します。この結果、VPLSドメインでの BUMトラフィックについて、エンジニアによる制限が可能になります。実際に詳しく見ていきましょう。

P2MP LSP

これまで説明してきた LSPのほとんどは、P2P（Point-to-Point）LSPでした。このタイプの LSPは（実際にも）VPLS転送で使用できますが、BUMトラフィックを P2P LSPで転送することは非効率です。具体的には、異なる LSPへのパスはコアを通過する類似のパスであり、このようなトラフィックに対して P2P LSPを使用すると、パスで BUMトラフィックが重複する結果になります。

P2MP LSPは、この問題を解決するため、ソース PEを起点としてVPLSインスタンス内のすべての受信側 PEに広がる LSPを実装し、異なるパスの共通のリンクでパケットの単一のコピーだけを搬送できるようにします。パケットの複製が実行される場所は、分岐点に限定されます。IPマルチキャスト転送と似ている部分が多く、重要なポイントとして、P2MP LSPが搬送するのは BUMトラフィックだ


けであることを理解してください。P2P LSPが転送するのは、既知のMACアドレスを宛先とするトラフィックであり、このトラフィックに該当するのはユニキャストトラフィックです。図 3.14および 3.15は、P2P転送とP2MP転送の違いを示しています。最初の図は P2P環境での BUMトラフィックのパケットフローを示しているのに対して、2番目の図は P2MP LSPの使用環境での同じフローを示しています。


10.200.86.2





CE5(oak-VPLS)

CE2(oak-VPLS)

CE1(oak-VPLS)

CE7(oak-VPLS)



10.200.86.6

CE4(oak-VPLS)


MPLS (P2P)カプセル化されたトラフィック

PE to CEレイヤー2トラフィック

macduff Pルーター 10.200.86.8

図 3.14 BUMトラフィック（P2P LSP使用時）


10.200.86.2





CE5(oak-VPLS)

CE2(oak-VPLS)

CE1(oak-VPLS)

CE3(oak-VPLS)



10.200.86.6

CE4(oak-VPLS)


MPLS (P2P)カプセル化されたトラフィック

PE to CEレイヤー2トラフィック

macduff Pルーター 10.200.86.8

図 3.15 BUMトラフィック（P2MP LSP使用時）


この 2つの図には、5つの CE VPLSドメインが描かれています。CE1は BUMトラフィック（この例では、ARP）の送信元であり、VPLSドメインの他のあらゆるCEに拡散する必要があります。このネットワークがP2P LSPを使用していた場合、送信元の PEはパケットを 4回複製して、コピーを 1つずつそれぞれの P2P LSPで送信する必要があります。P2MP LSPでは、送信元の PEはパケットの単一のコピーだけを P2MP LSPに送信し、mortlachはパケットを 1回複製して、それぞれのコピーを obanとmacduffに送信します。macduffはパケットを 2回複製して、それぞれのコピーを lagavulin、tormore、およびローカル CEに送信します。P2MPは、ヘッドエンドの PEでの複製の負荷を軽減するとともに、パケットの不要なコピーを排除することで、ネットワークの負荷を軽減します。パケットが複製される場所は分岐点だけであり、BUMトラフィックの配信方法として、優れた効率の実現に寄与しています。このような目的を達成しているにもかかわらず、VPLS用の P2MP LSPの設定は極めてシンプルです。以下の設定例のように、設定は routing-instance階層に存在しています。ps@dalwhinnie> show configuration routing-instances oak instance-type vpls;interface ge-1/0/0.0;route-distinguisher 10.200.86.1:100;provider-tunnel { rsvp-te { label-switched-path-template { default-template; } }}vrf-target target:300:200;protocols { vpls { site-range 5; no-tunnel-services; site oak-ce1 { site-identifier 1; interface ge-1/0/0.0; } }}

個別の LSPを設定する必要はないことに注意してください。ルーターは VPLSインスタンスに参加している各 PEへのブランチを介して、P2MP LSPに信号を送信します。自動的に信号を送信される P2MP LSPトランクの名前は、route-distinguisher:instance nameという形式で設定されます。ブランチには、宛先ルーターのループバックアドレスがトランク名の前に付加されて設定されます。たとえば、dalwhinnieからのトランクP2MP LSPは10.200.86.1:100:vpls:oakという名前が設定されて、macduffおよび lagavulinへのブランチはそれぞれ、10.200.86.3:10.200.86.1:100:vpls:oak および10.200.86.5:10.200.86.1:100:vpls:oakになります。 show mpls lspおよび show mpls lsp detailの出力に、この LSPが表示されています。

ps@dalwhinnie> show mpls lsp ingress Ingress LSP:3 sessionsTo From State Rt P ActivePath LSPname10.200.86.3 10.200.86.1 Up 0 * dalwhinnie-to-macduff10.200.86.3 10.200.86.1 Up 0 * 10.200.86.3:10.200.86.1:100:vpls:oak10.200.86.5 10.200.86.1 Up 0 * dalwhinnie-to-lagavulin10.200.86.5 10.200.86.1 Up 0 * 10.200.86.5:10.200.86.1:100:vpls:oakTotal 4 displayed, Up 4, Down 0


show mpls lspコマンドの detailバージョンでは、LSPについての付加的な情報が表示され、default-templateの LSPによって設定された値を示しています。以下の出力の太字部分は、default-templateによって設定された属性を強調表示しています。ps@dalwhinnie> show mpls lsp detail name 10.200.86.3:10.200.86.1:100:vpls:oak Ingress LSP:3 sessions10.200.86.3From:10.200.86.1, State:Up, ActiveRoute:0, LSPname:10.200.86.3:10.200.86.1:100:vpls:oakActivePath:(primary)P2MP name:10.200.86.1:100:vpls:oakPathDomain:Inter-domainLSPtype:Dynamic ConfiguredLoadBalance:RandomEncoding type:Packet, Switching type:Packet, GPID:IPv4*Primary State:UpPriorities:7 0SmartOptimizeTimer:180

設定をカスタマイズする必要がある場合は、ユーザー定義のテンプレートでdefault-templateを置き換えることができます。以下のテンプレートでは、デフォルト以外の optimize-timerを指定しています。

ps@dalwhinnie> show configuration protocols mpls label-switched-path P2MP-template template;optimize-timer 35;p2mp;

この LSPを VPLSルーティングインスタンスに適用する設定は、default-templateの使用とよく似ています。ただし、default-templateを指定する代わりに、作成した LSPの名前を使用します。ps@dalwhinnie> show configuration routing-instances oak instance-type vpls;interface ge-1/0/0.0;route-distinguisher 10.200.86.1:100;provider-tunnel { rsvp-te { label-switched-path-template { P2MP-template; } }}vrf-target target:300:200;protocols { vpls { site-range 6; no-tunnel-services; site vpls1-ce1 { site-identifier 1; interface ge-1/0/0.0; } }}

コミット後、LSPはデフォルト以外の optimize-timer設定を示します。ps@dalwhinnie> show mpls lsp detail name 10.200.86.3:10.200.86.1:100:vpls:oak Ingress LSP:3 sessions10.200.86.3From:10.200.86.1, State:Up, ActiveRoute:0, LSPname:10.200.86.3:10.200.86.1:100:vpls:oak


ActivePath:(primary)P2MP name:10.200.86.1:100:vpls:oakLSPtype:Dynamic ConfiguredLoadBalance:RandomEncoding type:Packet, Switching type:Packet, GPID:IPv4*Primary State:UpPriorities:7 0OptimizeTimer:35SmartOptimizeTimer:180

dalwhinnieはこの（P2MP）LSPを使用して、ブロードキャスト、不明なユニキャスト、およびマルチキャストトラフィックを配信します。ユニキャストトラフィックは、P2P LSPを使用することに注意してください。宛先MACは学習されます。

BUMトラフィックのフィルタリング

VPLS導入を拡張するための 2番目の方法は、レイヤー 2ブロードキャスト、不明なユニキャスト、およびマルチキャストトラフィックの量をフィルタリングすることです。具体的には、ユーザーがファミリVPLSファイアウォールフィルタを設定し、このフィルタを Junos転送オプション階層でルーティングインスタンスに適用します。

以下のサンプルは、ルーティングインスタンス内でファイアウォールフィルタを使用して、ネットワークでの BUMトラフィックの拡散を防ぐ場合の設定を示しています（VPLSインスタンス、CEからPEへの回線、およびネットワーク全体の容量の必要性に応じて、ポリサーの 50メガビットという値はカスタマイズが必要になることに注意してください）。ps@dalwhinnie> show configuration firewallfamily vpls { filter OakVplsBumFilter { term LimitBroadcast { from { traffic-type broadcast; } then { policer 50M-Policer; accept; } } term LimitMulticast { from { traffic-type multicast; } then { policer 50M-Policer; accept; } } term LimitUnknownUnicast { from { traffic-type unknown-unicast; } then { policer 50M-Policer; accept; } } term ExplicitPermit { then accept; } }


}policer 50M-Policer { filter-specific; if-exceeding { bandwidth-limit 50m; burst-size-limit 10m; } then discard;}

最後に、以下に示すように、ルーティングインスタンスは上で作成したファイアウォールフィルタを [forwarding-options]階層に含むようになります。ps@dalwhinnie> show configuration routing-instances oak instance-type vpls;interface ge-1/0/0.0;route-distinguisher 10.200.86.1:100;provider-tunnel { rsvp-te { label-switched-path-template { default-template; } }}vrf-target target:300:200;forwarding-options { family vpls { filter { input OakVplsBumFilter; } }}

まとめMPLSは、以前には存在しなかったか、運用や拡張に制限が伴った特長および機能を備えた興味深いツールセットです。経験豊富なエンジニアは、このような機能がネットワークのオーバーヘッドという代償を伴うことを知っています。MPLSネットワークを導入および拡張する際には、拡張に関連する要素やその影響を軽減するオプションについて理解しておくことが重要です。このセクションで取り上げた手法は、MPLSネットワークの導入計画と積極的な拡張管理に必要なツールとして活用できることでしょう。

第4章

MPLSの導入例

基本的なネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

中規模のネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

拡張される中規模のネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

複雑なネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199


第 3章では、MPLSプロトコルとその実装はネットワークの目的と要件によって大きく左右されるという点を強調しました。第 4章では、MPLSの導入例をいくつか確認して、そのネットワーク要件や最終的な設計・設定に注目しましょう。具体的には、4種類のネットワークを取り上げます。その範囲は、かなりシンプルなLDPネットワークから、エッジでのMPLS VPNサービスをサポートするトラフィックエンジニアリング対応の複雑な RSVPネットワークに至るまで、さまざまです。まず、基本的なネットワークから始めて、徐々に複雑なネットワークに進みましょう。

基本的なネットワーク � IGP：OSPF

� IGP拡張：なし � ラベル配布プロトコル：LDP

� BGP：フルエッジメッシュ、BGPフリーコア � 成長の見込み：ほとんどない � 付加的な要件：MPLSベースの機能拡張のサポート

この基本的な設計のネットワークの要件は、将来的な追加機能の拡張をそのままサポートすることです。具体的な要件には、MPLS VPNサービスも含まれています。このネットワークは規模がそれほど成長しないという想定で、シングルエリアOSPFと、あらゆるコアおよびエッジの対向インタフェースに設定された LDPに基づいて導入されます。トラフィックエンジニアリングの要件がないことと、LDPのシンプルさの相乗効果で、図 4.1に示すように、この環境では、基本的な設計で適切なラベル配布プロトコルが実現しています。



glenlivetlo0 10.200.86.6


blair lo0 10.200.86.1


obanlo0 10.200.86.3

macdufflo0 10.200.86.8


OSPFエリア0とLDP

図 4.1 基本的なネットワーク図

第4章：MPLSの導入例 145

図 4.1は、実にシンプルな構成を示しています。各ルーターのループバックインタフェースとコア /エッジ対向インタフェースは、OSPFエリア0に対して設定されています。物理インタフェースはポイントツーポイントのリンクであり、interface-

type p2pに設定されて、高速な収束を実現しています。PEルーターの oban、tormore、dalwinnie、および lagavulinは、フル BGPメッシュに設定されています。このネットワークは LDPを実行しているので、コアルーターが BGPを実行する必要はなく、BGPフリーコアの実装が可能になっています。PEルーターはBGP AS 1に参加し、ループバックアドレス間でピアを形成しています。各ルーターが family inet、family inet-vpn、および family l2vpnを交換することで、VPNを必要なタイミングで容易に実装できるようになっています。この設計をサポートする設定は、PEとPという2つのカテゴリのどちらかに分類されます。以下の例は、JunosスタイルとSetスタイルの両方で PEとPの設定を示しています。

dalwhinnie（PE）

dalwhinie の 2 つのインタフェースは OSPFと LDP に対して設定され、dalwhinie自体は他の PEルーターとピアを形成するよう設定されています。BGPセッションは 3つの異なるファミリで設定され、現在、交換されているユニキャスト inetプレフィックスとともに、将来的な機能の導入に備えて、inet-vpnユニキャストルートや l2vpnシグナリング（L2VPNとVPLSのサポート）をサポートしています。

Junosスタイル

system { host-name dalwhinnie; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2003; class super-user; authentication { encrypted-password "$1$9iVZGMcI$Bz5/GWXsO32k1s2a0iEo70"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/2 { unit 0 { description "Connection to glenlivet ge-0/0/2";


family inet { address 192.168.86.6/30; } family mpls; } } ge-0/0/3 { unit 0 { description "Connection to lagavulin ge-0/0/3"; family inet { address 192.168.86.30/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.5/32; } } }}routing-options { router-id 10.200.86.5; autonomous-system 1;}protocols { bgp { group ibgp { type internal; local-address 10.200.86.5; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 10.200.86.7; neighbor 10.200.86.9; neighbor 10.200.86.3; } } ospf { area 0.0.0.0 { interface lo0.0; interface ge-0/2/0.0; interface ge-0/3/0.0; } } ldp { interface ge-0/2/0.0; interface ge-0/3/0.0; }}


Setスタイル

set system host-name dalwhinnieset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2003set system login user ps class super-userset system login user ps authentication encrypted-password "$1$9iVZGMcI$Bz5/GWXsO32k1s2a0iEo70"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/2/0 unit 0 description "Connection to glenlivet ge-0/2/0"set interfaces ge-0/2/0 unit 0 family inet address 192.168.86.6/30set interfaces ge-0/2/0 unit 0 family mplsset interfaces ge-0/3/0 unit 0 description "Connection to lagavulin ge-0/3/0"set interfaces ge-0/3/0 unit 0 family inet address 192.168.86.30/30set interfaces ge-0/3/0 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.5/32set routing-options router-id 10.200.86.5set routing-options autonomous-system 1set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.5set protocols bgp group ibgp family inet unicastset protocols bgp group ibgp family inet-vpn unicastset protocols bgp group ibgp family l2vpn signalingset protocols bgp group ibgp neighbor 10.200.86.7set protocols bgp group ibgp neighbor 10.200.86.9set protocols bgp group ibgp neighbor 10.200.86.3set protocols ospf area 0.0.0.0 interface lo0.0set protocols ospf area 0.0.0.0 interface ge-0/2/0.0set protocols ospf area 0.0.0.0 interface ge-0/3/0.0set protocols ldp interface ge-0/2/0.0set protocols ldp interface ge-0/3/0.0

mortlach（P）

この設計では Pルーターとして、mortlachの設定は極めてシンプルであり、OSPFとLDPがそれぞれのインタフェースに設定されています。BGPフリーコア環境では、mortlachは Pルーターであり、BGPセッションは処理せず、MPLSラベルだけに基づいてパケットをスイッチングします。

Junosスタイル

system { host-name mortlach; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA }


} } services { ssh; } syslog { user * { any emergency; } host 192.168.11.135 { any info; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { fe-0/0/1 { unit 0 { description "Connection to glenlivet ge-0/0/3"; family inet { address 192.168.86.45/30; } family mpls; } } fe-2/0/0 { unit 0 { description "Connection to blair ge-0/0/2"; family inet { address 192.168.86.49/30; } family mpls; } } e1-1/0/0 { unit 0 { description "Connection to talisker e1-1/0/0"; family inet { address 192.168.86.22/30; } family mpls; } } fe-2/0/1 { unit 0 { description "Connection to macduff ge-0/0/3"; family inet { address 192.168.86.41/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.2/32 { primary;


} } } }}routing-options { router-id 10.200.86.2;}protocols { ospf { area 0.0.0.0 { interface lo0.0; interface fe-0/0/1.0; interface e1-1/0/0.0; interface fe-2/0/0.0; interface fe-2/0/1.0; } } ldp { interface fe-0/0/1.0; interface e1-1/0/0.0; interface fe-2/0/0.0; interface fe-2/0/1.0; }}

Setスタイル

set system host-name mortlachset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog host 192.168.11.135 any infoset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces fe-0/0/1 unit 0 description "Connection to glenlivet ge-0/0/3"set interfaces fe-0/0/1 unit 0 family inet address 192.168.86.45/30set interfaces fe-0/0/1 unit 0 family mplsset interfaces e1-1/0/0 unit 0 description "Connection to talisker e1-1/0/0"set interfaces e1-1/0/0 unit 0 family inet address 192.168.86.22/30set interfaces e1-1/0/0 unit 0 family mplsset interfaces fe-2/0/0 unit 0 description "Connection to blair ge-0/0/2"set interfaces fe-2/0/0 unit 0 family inet address 192.168.86.49/30set interfaces fe-2/0/0 unit 0 family mplsset interfaces fe-2/0/1 unit 0 description "Connection to macduff fe-2/0/1"set interfaces fe-2/0/1 unit 0 family inet address 192.168.86.41/30set interfaces fe-2/0/1 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.2/32 primaryset routing-options router-id 10.200.86.2set protocols ospf area 0.0.0.0 interface lo0.0set protocols ospf area 0.0.0.0 interface fe-0/0/1.0set protocols ospf area 0.0.0.0 interface e1-1/0/0.0 set protocols ospf area 0.0.0.0 interface fe-2/0/0.0 set protocols ospf area 0.0.0.0 interface fe-2/0/1.0set protocols ldp interface fe-0/0/1.0set protocols ldp interface e1-1/0/0.0set protocols ldp interface fe-2/0/0.0set protocols ldp interface fe-2/0/1.0


中規模のネットワーク � IGP：IS-IS

� IGP拡張：なし � ラベル配布プロトコル：RSVP

� BGP：フルエッジメッシュ、BGPフリーコア � 付加的な要件：管理グループとスタティックEROベースのトラフィックエンジニアリング

この少し複雑な設計では、定期的なパックアップなど、高帯域幅のアプリケーションがトラフィックエンジニアリング機能を必要としています。このネットワークは規模がそれほど成長しないという想定で、シングル IS-ISレベルで導入されます。図 4.2に示すように、RSVPがあらゆるコアおよびエッジの対向インタフェースに設定されるとともに、LSPがあらゆる PEルーター間に設定され、トラフィックエンジニアリングの要件を満たしています。



glenlivetlo0 10.200.86.6


blair lo0 10.200.86.1


obanlo0 10.200.86.3

macdufflo0 10.200.86.8


admin-groupによる制約があるLSP

スタティックERO LSP

制約のないLSP 100メガビットのメトロイーサネット回線（admin—group blue）

カラーが設定されたTE回線（admin-group red） IS-ISレベル2とRSVP

図 4.2 中規模のネットワーク設計

図 4.2で、破線で表された 2つのリンクは、100メガビット回線を示しています（他の回線はすべて 1ギガビット回線）。tormoreは突発的に 500メガビットを超える大量のトラフィックを dalwhinnieと lagavulinから受信するので、どちらの LSPも100メガビットリンクを横断できません。また、この LSPは、（障害モードを除いて）同じリンクを横断できないことにも注意してください。明示的なプライマリパスのいずれかのリンクで障害が発生した場合には、セカンダリLSPで保護できるよう、この LSPは設定されます。このセカンダリLSPが過剰使用の原因になる可能性があるのに対して、ネットワークには完全冗長な代替パスを用意できるほどの余裕はありません。lagavulinから obanへの LSPでは、最大 150メガビットの伝送が頻繁に実行される結果、この LSPは、100メガビットリンクを横断できません。このLSPは、いずれかの ERO LSPとともに（合計 650メガビット）、1ギガビットリン


クを共有できます。したがって、この LSPが 100メガビットリンクを横断できない事態を防ぐだけで済みます（管理グループの使用に適している）。

目的のトラフィックエンジニアリングを確実なものにするため、100メガビットリンクのカラーを blueに設定し、lagavulinから obanへの LSPで blueのリンクを避けるよう指示しています。dalwhinnieから tormoreへの LSPが同じリンクを横断しないようにするため、macduffから taliskerへのリンクと、taliskerから tormoreへのリンクのカラーを redに設定し、dalwhinnieから tormoreへのLSPは redのリンクを避けるよう設定されています。したがって、この LSPは、図示されているパスを選択します（本書の版によっては、カラーが実線、点線、または灰色の線で表示されています）。残りの LSPは、大量のトラフィックを搬送しないので、特に制約もなく設定されています。このように複雑なので、ここでは、dalwhinnie、lagavulin、glenlivet、およびmacduffの設定について詳しく説明します。IS-ISはトラフィックエンジニアリングの TLVを搬送するので、IS-ISの使用時には、RSVP信号が送られる LSPで traffic-engineeringは必須のステートメントではないことに注意してください。

dalwhinnie（PE）

dalwhinnieで注目すべき設定部分のほとんどは、[protocols mpls]階層に含まれています。dalwhinnieから tormoreには 2つの LSPが存在することに注意してください。最初の LSP（-primary）は特定済みのパスに LSPを強制的に設定する admin-groupの制限に基づいて設定されているのに対して、2番目の LSP（-secondary）は特に制限もなく設定されており、利用可能な最短のパスを選択できるようにしています。metricキーワードを使用して、プライマリLSPをセカンダリLSPよりも優先しています。

Junosスタイル

system { host-name dalwhinnie; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2003; class super-user; authentication { encrypted-password "$1$9iVZGMcI$Bz5/GWXsO32k1s2a0iEo70"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }


}interfaces { ge-0/0/2 { unit 0 { description "Connection to glenlivet ge-0/0/2"; family inet { address 192.168.86.6/30; } family mpls; } } ge-0/0/3 { unit 0 { description "Connection to lagavulin ge-0/0/3"; family inet { address 192.168.86.30/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.5/32; } family iso { address 49.0001.1000.0000.0001.00; } } }}routing-options { router-id 10.200.86.5; autonomous-system 1;}protocols { rsvp { interface ge-0/0/2.0; interface ge-0/0/2.0; } mpls { admin-groups { blue 0; red 1; } label-switched-path dalwhinnie-to-oban { to 10.200.86.3; } label-switched-path dalwhinnie-to-lagavulin { to 10.200.86.7; } label-switched-path dalwhinnie-to-tormore-primary { to 10.200.86.9; metric 100; admin-group exclude [ blue red ]; } label-switched-path dalwhinnie-to-tormore-secondary { to 10.200.86.9; metric 200; } interface ge-0/0/2.0;


interface ge-0/0/3.0; } bgp { group ibgp { type internal; local-address 10.200.86.5; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 10.200.86.7; neighbor 10.200.86.9; neighbor 10.200.86.3; } } isis { level 1 disable; level 2 wide-metrics-only; interface ge-0/0/2.0 { level 1 disable; } interface ge-0/0/3.0 { level 1 disable; } interface lo0.0 { level 1 disable; } }}

Setスタイル

set system host-name dalwhinnieset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2003set system login user ps class super-userset system login user ps authentication encrypted-password "$1$9iVZGMcI$Bz5/GWXsO32k1s2a0iEo70"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/2/0 unit 0 description "Connection to glenlivet ge-0/2/0"set interfaces ge-0/2/0 unit 0 family inet address 192.168.86.6/30set interfaces ge-0/2/0 unit 0 family mplsset interfaces ge-0/3/0 unit 0 description "Connection to lagavulin ge-0/3/0"set interfaces ge-0/3/0 unit 0 family inet address 192.168.86.30/30set interfaces ge-0/3/0 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.5/32set interfaces lo0 unit 0 family iso address 49.0001.1000.0000.0001.00set routing-options router-id 10.200.86.5set routing-options autonomous-system 1set protocols rsvp interface ge-0/0/2.0set protocols rsvp interface ge-0/0/3.0


set protocols mpls admin-groups blue 0set protocols mpls admin-groups red 1set protocols mpls label-switched-path dalwhinnie-to-oban to 10.200.86.3set protocols mpls label-switched-path dalwhinnie-to-lagavulin to 10.200.86.7set protocols mpls label-switched-path dalwhinnie-to-tormore-primary to 10.200.86.9set protocols mpls label-switched-path dalwhinnie-to-tormore-primary metric 100set protocols mpls label-switched-path dalwhinnie-to-tormore-primary admin-group exclude blueset protocols mpls label-switched-path dalwhinnie-to-tormore-primary admin-group exclude redset protocols mpls label-switched-path dalwhinnie-to-tormore-secondary to 10.200.86.9set protocols mpls label-switched-path dalwhinnie-to-tormore-secondary metric 200set protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.5set protocols bgp group ibgp family inet unicastset protocols bgp group ibgp family inet-vpn unicastset protocols bgp group ibgp family l2vpn signalingset protocols bgp group ibgp neighbor 10.200.86.7set protocols bgp group ibgp neighbor 10.200.86.9set protocols bgp group ibgp neighbor 10.200.86.3set protocols isis level 1 disableset protocols isis level 2 wide-metrics-onlyset protocols isis interface ge-0/0/2.0 level 1 disableset protocols isis interface ge-0/0/3.0 level 1 disableset protocols isis interface lo0.0 level 1 disable

lagavulin（PE）

dalwhinnieと同様に、lagavulinで注目すべき設定部分は、[protocols mpls]セクションに含まれています。lagavulinは、tormoreの LSPと同様の LSPが設定されています。さらに、lagavulin-to-oban LSPには、mortlachをルースホップとして指定するプライマリと、パスの制限がないセカンダリという2つのパスがあります。このセカンダリは、standbyコマンドで設定します。この設定により、LSPへの事前の信号送信と優先的なフェイルオーバーが可能になります。

Junosスタイル

system { host-name lagavulin; root-authentication { encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } }


services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/2 { unit 0 { description "Connection to macduff ge-0/0/2"; family inet { address 192.168.86.2/30; } family iso; family mpls; } } ge-0/0/3 { unit 0 { description "Connection to dalwhinnie ge-0/0/3"; family inet { address 192.168.86.29/30; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.7/32 { primary; } } family iso { address 49.0001.1001.0000.0001.00; } } }}routing-options { router-id 10.200.86.7; autonomous-system 1;}protocols { rsvp { interface all; interface ge-0/0/2.0; interface ge-0/0/3.0; } mpls {


admin-groups { blue 0; red 1; } label-switched-path lagavulin-to-dalwhinnie { to 10.200.86.5; } label-switched-path lagavulin-to-tormore-primary { to 10.200.86.9; admin-group exclude blue; } label-switched-path lagavulin-to-tormore-secondary { to 10.200.86.9; metric 200; } label-switched-path lagavulin-to-oban { to 10.200.86.3; primary to-oban-primary; secondary to-oban-secondary { standby; } } path to-oban-primary { 10.100.7.21 loose; } path to-oban-secondary; interface ge-0/0/2.0; interface ge-0/0/3.0; } bgp { group ibgp { type internal; local-address 10.200.86.7; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 10.200.86.5; neighbor 10.200.86.3; neighbor 10.200.86.9; } } isis { level 1 disable; level 2 wide-metrics-only; interface ge-0/0/2.0 { level 1 disable; } interface ge-0/0/3.0 { level 1 disable; } interface lo0.0 { level 1 disable; } }}


Setスタイル

set system host-name lagavulinset system root-authentication encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/2 unit 0 description "Connection to macduff ge-0/0/2"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.2/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 unit 0 description "Connection to dalwhinnie ge-0/0/3"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.29/30set interfaces ge-0/0/3 unit 0 family isoset interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.7/32 primaryset interfaces lo0 unit 0 family iso address 49.0001.1000.0000.0001.00set routing-options router-id 10.200.86.7set routing-options autonomous-system 1set protocols rsvp interface allset protocols rsvp interface ge-0/0/2.0set protocols rsvp interface ge-0/0/3.0set protocols mpls admin-groups blue 0set protocols mpls admin-groups red 1set protocols mpls label-switched-path lagavulin-to-dalwhinnie to 10.200.86.5set protocols mpls label-switched-path lagavulin-to-tormore-primary to 10.200.86.9set protocols mpls label-switched-path lagavulin-to-tormore-primary admin-group exclude blueset protocols mpls label-switched-path lagavulin-to-oban to 10.200.86.3set protocols mpls label-switched-path lagavulin-to-oban primary to-oban-primaryset protocols mpls label-switched-path lagavulin-to-oban secondary to-oban-secondary standbyset protocols mpls label-switched-path lagavulin-to-tormore-secondary to 10.200.86.9set protocols mpls label-switched-path lagavulin-to-tormore-secondary metric 200set protocols mpls path to-oban-primary 10.100.7.21 looseset protocols mpls path to-oban-secondaryset protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.7set protocols bgp group ibgp family inet unicastset protocols bgp group ibgp family inet-vpn unicastset protocols bgp group ibgp family l2vpn signalingset protocols bgp group ibgp neighbor 10.200.86.5set protocols bgp group ibgp neighbor 10.200.86.3set protocols bgp group ibgp neighbor 10.200.86.9set protocols isis level 1 disableset protocols isis level 2 wide-metrics-onlyset protocols isis interface ge-0/0/2.0 level 1 disableset protocols isis interface ge-0/0/3.0 level 1 disableset protocols isis interface lo0.0 level 1 disable


glenlivet（P）

Pルーターは、admin-groupで特定のリンクを設定する場合の例を示しています。[protocols mpls]階層では、ge-0/0/1のカラーは blueであり、PEはtormoreへの LSPで回避するよう設定されています。

Junosスタイル

system { host-name glenlivet; root-authentication { encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/1 { unit 0 { description "Connection to blair ge-0/0/1"; family inet { address 192.168.86.10/30; } family iso; family mpls; } } ge-0/0/2 { unit 0 { description "Connection to dalwhinnie ge-0/0/2"; family inet { address 192.168.86.5/30; } family iso; family mpls; }


} ge-0/0/3 { unit 0 { description "Connection to mortlach fe-0/0/1"; family inet { address 192.168.86.46/30; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.6/32; } family iso { address 49.0001.1000.0000.0002.00; } } }}routing-options { router-id 10.200.86.6;}protocols { rsvp { interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/3.0; } mpls { admin-groups { blue 0; red 1; } interface ge-0/0/1.0 { admin-group blue; } interface ge-0/0/2.0; interface ge-0/0/3.0; } isis { level 1 disable; level 2 wide-metrics-only; interface ge-0/0/1.0 { level 1 disable; } interface ge-0/0/2.0 { level 1 disable; } interface ge-0/0/3.0 { level 1 disable; } interface lo0.0 { level 1 disable; } }}


Setスタイル

set system host-name glenlivetset system root-authentication encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/1 unit 0 description "Connection to blair ge-0/0/1"set interfaces ge-0/0/1 unit 0 family inet address 192.168.86.10/30set interfaces ge-0/0/1 unit 0 family isoset interfaces ge-0/0/1 unit 0 family mplsset interfaces ge-0/0/2 unit 0 description "Connection to dalwhinnie ge-0/0/2"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.5/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 unit 0 description "Connection to mortlach fe-0/0/1"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.46/30set interfaces ge-0/0/3 unit 0 family isoset interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.6/32set interfaces lo0 unit 0 family iso address 49.0001.1002.0000.0001.00set routing-options router-id 10.200.86.6set protocols rsvp interface ge-0/0/1.0set protocols rsvp interface ge-0/0/2.0set protocols rsvp interface ge-0/0/3.0set protocols mpls admin-groups blue 0set protocols mpls admin-groups red 1set protocols mpls interface ge-0/0/1.0 admin-group blueset protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols isis level 1 disableset protocols isis level 2 wide-metrics-onlyset protocols isis interface ge-0/0/1.0 level 1 disableset protocols isis interface ge-0/0/2.0 level 1 disableset protocols isis interface ge-0/0/3.0 level 1 disableset protocols isis interface lo0.0 level 1 disable

macduff（P）

繰り返しになりますが、Pルーターはリンクのカラー設定の使用例を示しています。[protocols mpls]階層では、ge-0/0/1.0のカラーは redであり、dalwhinnieは（blueのリンクに加えて）tormoreへの LSPで回避するよう設定されています。

Junosスタイル

system { host-name macduff; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2005;


class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/1 { unit 0 { description "Connection to talisker fe-0/0/1"; family inet { address 192.168.86.14/30; } family iso; family mpls; } } ge-0/0/2 { unit 0 { description "Connection to lagavulin ge-0/0/2"; family inet { address 192.168.86.1/30; } family iso; family mpls; } } ge-0/0/3 { unit 0 { description "Connection to mortlach fe-2/0/1"; family inet { address 192.168.86.42/30; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.8/32 { primary; } } family iso { address 49.0001.1003.0000.0001.00;


} } }}routing-options { router-id 10.200.86.8;}protocols { rsvp { interface all; interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/3.0; } mpls { admin-groups { blue 0; red 1; } interface ge-0/0/1.0 { admin-group red; } interface ge-0/0/2.0; interface ge-0/0/3.0; } isis { level 1 disable; level 2 wide-metrics-only; interface ge-0/0/1.0 { level 1 disable; } interface ge-0/0/2.0 { level 1 disable; } interface ge-0/0/3.0 { level 1 disable; } interface lo0.0 { level 1 disable; } }}

Setスタイル

set system host-name macduffset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/1 unit 0 description "Connection to talisker fe-0/0/1"set interfaces ge-0/0/1 unit 0 family inet address 192.168.86.14/30set interfaces ge-0/0/1 unit 0 family isoset interfaces ge-0/0/1 unit 0 family mpls


set interfaces ge-0/0/2 unit 0 description "Connection to lagavulin ge-0/0/2"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.1/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 unit 0 description "Connection to mortlach fe-2/0/1"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.42/30set interfaces ge-0/0/3 unit 0 family isoset interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.8/32 primaryset interfaces lo0 unit 0 family iso address 49.0001.1003.0000.0001.00set routing-options router-id 10.200.86.8set protocols rsvp interface allset protocols rsvp interface ge-0/0/1.0set protocols rsvp interface ge-0/0/2.0set protocols rsvp interface ge-0/0/3.0set protocols mpls admin-groups blue 0set protocols mpls admin-groups red 1set protocols mpls interface ge-0/0/1.0 admin-group redset protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols isis level 1 disableset protocols isis level 2 wide-metrics-onlyset protocols isis interface ge-0/0/1.0 level 1 disableset protocols isis interface ge-0/0/2.0 level 1 disableset protocols isis interface ge-0/0/3.0 level 1 disableset protocols isis interface lo0.0 level 1 disable

拡張される中規模のネットワーク � IGP：IS-IS

� IGP拡張：マルチエリア /レベル � ラベル配布プロトコル：LDPとRSVP

� BGP：ルートリフレクション � 成長の見込み：適度な成長 � 付加的な要件：RSVP信号が送られる LSPでの自動帯域幅調整

前の例で導入した中規模のネットワークが想定を上回る成長を遂げたので、このニーズに応えてネットワークを拡張する必要があります。具体的には、PEデバイスの追加と、この追加に伴うレベル 2 IS-ISへの参加デバイスの増加、BGPピアの増加、LSPの増加といった拡張が挙げられます。PEの追加をサポートするため、ネットワークは、PEルーターがレベル 1に配置されるマルチレベル設計に移行します。さらに、フルエッジ BGPメッシュは、専用のルートリフレクタが転送プレーンに存在しないルートリフレクションモデルに移行します。最後に、MPLSの拡張を可能にするため、エッジルーターを LDPに移行して、コアルーターをフル LSPメッシュで動作させます。LDPは RSVP信号が送られる LSPでトンネリングされ、エッジツーエッジのMPLS接続を可能にします。図 4.3は、この設計を示しています。

運用面では、LSPと制約が増えると、LSPを手動で管理することはほとんど不可能になってしまいます。したがって、このネットワークでは、Junosの auto-bandwidth機能を採用して、要求されたスループットを提供できるよう、パスに適切な帯域幅を確保しています。また、ネットワークの成長をサポートするため、100メガビットリンクがフル 1ギガビットリンクにアップグレードされていることにも注意してください。ここでは、PEおよび Pルーターの設定例に加えてルートリフレクタの設定例を、dalwhinnie、oban、blair、glenlivet、および aberlourを使用して紹介しています。


tormoreRRクライアントlo0 10.200.86.9

mortlachLSPフルメッシュlo0 10.200.86.2

glenlivetLSPフルメッシュlo0 10.200.86.6

lagavulinRRクライアントlo0 10.200.86.7

blair LSPフルメッシュlo0 10.200.86.1

dalwhinnieRRクライアントlo0 10.200.86.5 oban

RRクライアントlo0 10.200.86.3

macduffLSPフルメッシュlo0 10.200.86.8

taliskerLSPフルメッシュlo0 10.200.86.4

IS-ISレベル2とRSVP IS-ISレベル1とLDP

aberlourルートリフレクタlo0 10.200.86.10

laphroaigルートリフレクタlo0 10.200.86.11

図 4.3 拡張される中規模のネットワーク

dalwhinnie（PE）

dalwhinnieは、glenlivetへのアップリンクと lagavulinとのクロス接続に、LDPのみが設定されています。このリンクは、IS-ISレベル 1、エリア 49.0001でも動作しています。また、dalwhinnieは、2つのルートリフレクタのルートリフレクタクライアントに該当します。4台の PEルーターがすべて、この設計に基づいています。

Junosスタイル

system { host-name dalwhinnie; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2003; class super-user; authentication { encrypted-password "$1$9iVZGMcI$Bz5/GWXsO32k1s2a0iEo70"; ## SECRET-DATA } } } services { ssh; } syslog { user * {


any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/2 { unit 0 { description "Connection to glenlivet ge-0/0/2"; family inet { address 192.168.86.6/30; } family mpls; } } ge-0/0/3 { unit 0 { description "Connection to lagavulin ge-0/0/3"; family inet { address 192.168.86.30/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.5/32; } family iso { address 49.0001.0102.0008.6005.00; } } }}routing-options { router-id 10.200.86.5; autonomous-system 1;}protocols { bgp { group ibgp { type internal; local-address 10.200.86.5; neighbor 10.200.86.10; neighbor 10.200.86.11; } } isis { level 1 wide-metrics-only; level 2 disable; interface ge-0/.500 { level 2 disable; } interface ge-0/0/2.0 { level 2 disable; }


interface ge-0/0/3.0 { level 2 disable; } } ldp { interface ge-0/0/2.0; interface ge-0/0/3.0; }}

Setスタイル

set system host-name dalwhinnieset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2003set system login user ps class super-userset system login user ps authentication encrypted-password "$1$9iVZGMcI$Bz5/GWXsO32k1s2a0iEo70"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/2/0 unit 0 description "Connection to glenlivet ge-0/2/0"set interfaces ge-0/2/0 unit 0 family inet address 192.168.86.6/30set interfaces ge-0/2/0 unit 0 family mplsset interfaces ge-0/3/0 unit 0 description "Connection to lagavulin ge-0/3/0"set interfaces ge-0/3/0 unit 0 family inet address 192.168.86.30/30set interfaces ge-0/3/0 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.5/32set interfaces lo0 unit 0 family iso address 49.0001.0102.0008.6005.00set routing-options router-id 10.200.86.5set routing-options autonomous-system 1set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.5set protocols bgp group ibgp neighbor 10.200.86.10set protocols bgp group ibgp neighbor 10.200.86.11set protocols isis level 1 wide-metrics-onlyset protocols isis level 2 disableset protocols isis interface ge-0/0/2.0 level 2 disableset protocols isis interface ge-0/0/3.0 level 2 disableset protocols isis interface lo0.0 level 2 disableset protocols ldp interface ge-0/0/3.0set protocols ldp interface ge-0/0/3.0

glenlivet（P）

ここでは、まず Pルーターに注目していきます。Pルーターの IS-IS設定では、レベル 2ルートをレベル 1にリークすることが可能になります。この処理は、PEがIS-ISルートと関連 LDPラベルを設定するために必要です。この処理がなければ、デフォルトルートは L1-L2ルーター（そのアップストリームの Pルーター）から付加されたビットだけに基づいて設定されます。さらに、Junosの [protocols mpls]階層には、統計ファイルが設定されており、auto-bandwidthデータの収集が有効になっています。この統計情報は、デフォルトでは 300秒間隔で収集されますが、その他の値に設定することも可能です。最後に、各 LSPは、ldp-tunnelingに加えて auto-bandwidthも 3600秒（1時間）の調整間隔で設定されています。この一連のステートメントによって、LSPのリモート側のルーターと LDPラベルを交換（ldp-tunneling）するとともに、過去 3600秒の LSPの


帯域幅の平均利用率に基づいて帯域幅を確保するようルーターに指示します。このタイマーが時間切れになると、更新された帯域幅で LSPに信号が送信されます。

Junosスタイル

system { host-name glenlivet; root-authentication { encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/1 { unit 0 { description "Connection to blair ge-0/0/1"; family inet { address 192.168.86.10/30; } family iso; family mpls; } } ge-0/0/2 { unit 0 { description "Connection to dalwhinnie ge-0/0/2"; family inet { address 192.168.86.5/30; } family iso; family mpls; } }


ge-0/0/3 { unit 0 { description "Connection to mortlach fe-0/0/1"; family inet { address 192.168.86.46/30; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.6/32; } family iso { address 49.0001.0102.0008.6006.00; } } }}routing-options { router-id 10.200.86.6;}protocols { rsvp { interface ge-0/0/1.0; interface ge-0/0/3.0; } mpls { statistics { file mpls-stats; auto-bandwidth; } label-switched-path glenlivet-to-mortlach { to 10.200.86.2; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } label-switched-path glenlivet-to-talisker { to 10.200.86.4; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } label-switched-path glenlivet-to-macduff { to 10.200.86.8; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } label-switched-path glenlivet-to-blair { to 10.200.86.1; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } interface ge-0/0/1.0;


interface ge-0/0/3.0; } isis { export PE-Loopbacks-to-Level-1; level 2 wide-metrics-only; level 1 wide-metrics-only; interface ge-0/0/1.0 { level 1 disable; } interface ge-0/0/2.0 { level 2 disable; } interface ge-0/0/3.0 { level 1 disable; } interface lo0.0 { level 1 disable; } } ldp { interface ge-0/0/2.0; interface lo0.0; }}policy-options { policy-statement PE-Loopbacks-to-Level-1 { term Accept-Loopbacks { from { protocol isis; route-filter 10.200.86.0/24 prefix-length-range /32-/32; } then accept; } term Accept-Direct { from protocol direct; then accept; } term Reject-All-Else { then reject; } }}

Setスタイル

set system host-name glenlivetset system root-authentication encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/1 unit 0 description "Connection to blair ge-0/0/1"set interfaces ge-0/0/1 unit 0 family inet address 192.168.86.10/30


set interfaces ge-0/0/1 unit 0 family isoset interfaces ge-0/0/1 unit 0 family mplsset interfaces ge-0/0/2 unit 0 description "Connection to dalwhinnie ge-0/0/2"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.5/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 unit 0 description "Connection to mortlach fe-0/0/1"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.46/30set interfaces ge-0/0/3 unit 0 family isoset interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.6/32set interfaces lo0 unit 0 family iso address 49.0001.0102.0008.6006.00set routing-options router-id 10.200.86.6set protocols rsvp interface ge-0/0/1.0set protocols rsvp interface ge-0/0/3.0set protocols mpls statistics file mpls-statsset protocols mpls statistics auto-bandwidthset protocols mpls label-switched-path glenlivet-to-mortlach to 10.200.86.2set protocols mpls label-switched-path glenlivet-to-mortlach ldp-tunnelingset protocols mpls label-switched-path glenlivet-to-mortlach auto-bandwidth adjust-interval 3600set protocols mpls label-switched-path glenlivet-to-talisker to 10.200.86.4set protocols mpls label-switched-path glenlivet-to-talisker ldp-tunnelingset protocols mpls label-switched-path glenlivet-to-talisker auto-bandwidth adjust-interval 3600set protocols mpls label-switched-path glenlivet-to-macduff to 10.200.86.8set protocols mpls label-switched-path glenlivet-to-macduff ldp-tunnelingset protocols mpls label-switched-path glenlivet-to-macduff auto-bandwidth adjust-interval 3600set protocols mpls label-switched-path glenlivet-to-blair to 10.200.86.1set protocols mpls label-switched-path glenlivet-to-blair ldp-tunnelingset protocols mpls label-switched-path glenlivet-to-blair auto-bandwidth adjust-interval 3600set protocols mpls interface ge-0/0/1.0set protocols mpls interface ge-0/0/3.0set protocols isis export PE-Loopbacks-to-Level-1set protocols isis level 2 wide-metrics-onlyset protocols isis level 1 wide-metrics-onlyset protocols isis interface ge-0/0/1.0 level 1 disableset protocols isis interface ge-0/0/2.0 level 2 disableset protocols isis interface ge-0/0/3.0 level 1 disableset protocols isis interface lo0.0 level 1 disableset protocols ldp interface ge-0/0/2.0set protocols ldp interface lo0.0set policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Loopbacks from protocol isisset policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Loopbacks from route-filter 10.200.86.0/24 prefix-length-range /32-/32set policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Loopbacks then acceptset policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Direct from protocol directset policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Direct then acceptset policy-options policy-statement PE-Loopbacks-to-Level-1 term Reject-All-Else then reject


oban（PE）

obanの設定は情報を網羅するために紹介していますが、dalwhinnieの設定とよく似ています。

Junosスタイル

system { host-name oban; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/2 { unit 0 { description "Connection to blair ge-6/0/0"; family inet { address 192.168.86.25/30; } family iso; family mpls; } ge-0/0/3 { unit 0 { description "Connection to tormore ge-0/0/3"; family inet { address 192.168.86.38/30; } family iso; family mpls; } }


lo0 { unit 0 { family inet { address 10.200.86.3/32; } family iso { address 49.0002.0102.0008.6003.00; } } }}routing-options { router-id 10.200.86.3; autonomous-system 1;}protocols { bgp { group ibgp { type internal; local-address 10.200.86.3; neighbor 10.200.86.10; neighbor 10.200.86.11; } } isis { level 2 disable; level 1 wide-metrics-only; interface ge-0/0/2.0 { level 2 disable; } interface ge-0/0/3.0 { level 2 disable; } interface lo0.0 { level 2 disable; } } ldp { interface ge-0/0/2.0; interface ge-0/0/3.0; }}

Setスタイル

set system host-name obanset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/2 unit 0 description "Connection to blair ge-6/0/0"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.25/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mpls


set interfaces ge-0/0/3 unit 0 description "Connection to tormore ge-0/0/3"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.38/30set interfaces ge-0/0/3 unit 0 family isoset interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.3/32set interfaces lo0 unit 0 family iso address 49.0002.0102.0008.6003.00set routing-options router-id 10.200.86.3set routing-options autonomous-system 1set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.3set protocols bgp group ibgp neighbor 10.200.86.10set protocols bgp group ibgp neighbor 10.200.86.11set protocols isis level 2 disableset protocols isis level 1 wide-metrics-onlyset protocols isis interface ge-0/0/2.0 level 2 disableset protocols isis interface ge-0/0/3.0 level 2 disableset protocols isis interface lo0.0 level 2 disableset protocols ldp interface ge-0/0/2.0set protocols ldp interface ge-0/0/3.0

blair（P）

blairの設定は glenlivetの設定とよく似ています。大きな違いは、blairがglenlivet（49.0001）とは異なる IS-ISエリア 49.0002に存在していることです。

Junosスタイル

system { host-name blair; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}


interfaces { ge-0/0/0 { unit 0 { description "Connection to aberlour ge-0/0/0"; family inet { address 192.168.86.53/30; } family iso; family mpls; } } ge-0/0/1 { unit 0 { description "Connection to glenlivet ge-0/0/1"; family inet { address 192.168.86.9/30; } family iso; family mpls; } } ge-0/0/2 { unit 0 { description "Connection to mortlach fe-2/0/0"; family inet { address 192.168.86.50/30; } family iso; family mpls; } } ge-0/0/3 { unit 0 { description "Connection to talisker fe-2/0/0"; family inet { address 192.168.86.18/30; } family iso; family mpls; } } ge-6/0/0 { unit 0 { description "Connection to oban ge-0/0/2"; family inet { address 192.168.86.26/30; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.1/32 { primary; } } family iso { address 49.0002.0102.0008.6001.00; } } }


}routing-options { router-id 10.200.86.1; autonomous-system 1;}protocols { rsvp { interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/3.0; } mpls { statistics { file mpls-stats; auto-bandwidth; } label-switched-path blair-to-glenlivet { to 10.200.86.6; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } label-switched-path blair-to-mortlach { to 10.200.86.2; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } label-switched-path blair-to-talisker { to 10.200.86.4; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } label-switched-path blair-to-macduff { to 10.200.86.8; ldp-tunneling; auto-bandwidth { adjust-interval 3600; } } interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/3.0; } isis { export PE-Loopbacks-to-Level-1; level 2 wide-metrics-only; level 1 wide-metrics-only; interface ge-0/0/0.0 { level 2 disable; } interface ge-0/0/1.0 { level 1 disable; } interface ge-0/0/2.0 { level 1 disable; } interface ge-0/0/3.0 {


level 1 disable; } interface ge-6/0/0.0 { level 2 disable; } interface lo0.0 { level 1 disable; } } ldp { interface ge-6/0/0.0; interface lo0.0; }}policy-options { policy-statement PE-Loopbacks-to-Level-1 { term Accept-Loopbacks { from { protocol isis; route-filter 10.200.86.0/24 prefix-length-range /32-/32; } then accept; } term Accept-Direct { from protocol direct; then accept; } term Reject-All-Else { then reject; } }}

Setスタイル

set system host-name blairset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/0 unit 0 description "Connection to aberlour ge-0/0/0"set interfaces ge-0/0/0 unit 0 family inet address 192.168.86.53/30set interfaces ge-0/0/0 unit 0 family isoset interfaces ge-0/0/1 unit 0 description "Connection to glenlivet ge-0/0/1"set interfaces ge-0/0/1 unit 0 family inet address 192.168.86.9/30set interfaces ge-0/0/1 unit 0 family isoset interfaces ge-0/0/1 unit 0 family mplsset interfaces ge-0/0/2 unit 0 description "Connection to mortlach fe-2/0/0"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.50/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 unit 0 description "Connection to talisker fe-2/0/0"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.18/30set interfaces ge-0/0/3 unit 0 family iso


set interfaces ge-0/0/3 unit 0 family mplsset interfaces ge-6/0/0 unit 0 description "Connection to oban ge-0/0/2"set interfaces ge-6/0/0 unit 0 family inet address 192.168.86.26/30set interfaces ge-6/0/0 unit 0 family isoset interfaces ge-6/0/0 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.1/32 primaryset interfaces lo0 unit 0 family iso address 49.0002.0102.0008.6001.00set routing-options router-id 10.200.86.1set routing-options autonomous-system 1set protocols rsvp interface ge-0/0/1.0set protocols rsvp interface ge-0/0/2.0set protocols rsvp interface ge-0/0/3.0set protocols mpls statistics file mpls-statsset protocols mpls statistics auto-bandwidthset protocols mpls label-switched-path blair-to-glenlivet to 10.200.86.6set protocols mpls label-switched-path blair-to-glenlivet ldp-tunnelingset protocols mpls label-switched-path blair-to-glenlivet auto-bandwidth adjust-interval 3600set protocols mpls label-switched-path blair-to-mortlach to 10.200.86.2set protocols mpls label-switched-path blair-to-mortlach ldp-tunnelingset protocols mpls label-switched-path blair-to-mortlach auto-bandwidth adjust-interval 3600set protocols mpls label-switched-path blair-to-talisker to 10.200.86.4set protocols mpls label-switched-path blair-to-talisker ldp-tunnelingset protocols mpls label-switched-path blair-to-talisker auto-bandwidth adjust-interval 3600set protocols mpls label-switched-path blair-to-macduff to 10.200.86.8set protocols mpls label-switched-path blair-to-macduff ldp-tunnelingset protocols mpls label-switched-path blair-to-macduff auto-bandwidth adjust-interval 3600set protocols mpls interface ge-0/0/1.0set protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols isis export PE-Loopbacks-to-Level-1set protocols isis level 2 wide-metrics-onlyset protocols isis level 1 wide-metrics-onlyset protocols isis interface ge-0/0/0.0 level 1 disableset protocols isis interface ge-0/0/1.0 level 1 disableset protocols isis interface ge-0/0/2.0 level 1 disableset protocols isis interface ge-0/0/3.0 level 1 disableset protocols isis interface ge-6/0/0.0 level 2 disableset protocols isis interface lo0.0 level 1 disableset protocols ldp interface ge-6/0/0.0set protocols ldp interface lo0.0set policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Loopbacks from protocol isisset policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Loopbacks from route-filter 10.200.86.0/24 prefix-length-range /32-/32set policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Loopbacks then acceptset policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Direct from protocol directset policy-options policy-statement PE-Loopbacks-to-Level-1 term Accept-Direct then acceptset policy-options policy-statement PE-Loopbacks-to-Level-1 term Reject-All-Else then reject

aberlour（RR）

このルートリフレクタの設定は、極めてシンプルです。blairへの接続、ルートリフレクタクライアント（group rr-clients）との BGPセッション、さらに他のルートリフレクタ（laphroaig）との BGPセッションについては、IS-ISで設定されています。ここで引用している設定によって、BGPルート配信の冗長メカニズムが実現します。さらに冗長化が必要な場合は、各ルートリフレクタに 2番目の接続を追加します。


ただし、ルートリフレクタを二重化する設計を採用すると、重要な単一障害点は失われます。

Junosスタイル

system { host-name aberlour; root-authentication { encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"; ## SECRET-DATA } login { user ps { uid 2005; class super-user; authentication { encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/0 { unit 0 { description "Connection to blair ge-0/0/0"; family inet { address 192.168.86.54/30; } family iso; } } lo0 { unit 0 { family inet { address 10.200.86.10/32; } family iso { address 49.0002.0102.0008.6010.00; } } }}routing-options { router-id 10.200.86.10; autonomous-system 1;


}protocols { bgp { group rr-clients { type internal; local-address 10.200.86.10; cluster 10.200.86.10; neighbor 10.200.86.3; neighbor 10.200.86.5; neighbor 10.200.86.7; neighbor 10.200.86.9; } group ibgp { type internal; local-address 10.200.86.10; neighbor 10.200.86.11; } } isis { level 1 disable; level 2 wide-metrics-only; interface ge-0/0/0 { level 1 disable; } interface lo0.0 { level 1 disable; } }}

Setスタイル

set system host-name aberlourset system root-authentication encrypted-password "$1$O4d8X3vs$WPM4Gpe6Fy86YhU7CpvPe0"set system login user ps uid 2005set system login user ps class super-userset system login user ps authentication encrypted-password "$1$20Y5E3.P$KCIi/yaB9hJ4Z4xy1XIAS1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/0.0 unit 0 description "Connection to blair ge-0/0/0"set interfaces ge-0/0/0.0 unit 0 family inet address 192.168.86.54/30set interfaces ge-0/0/0.0 unit 0 family isoset interfaces lo0 unit 0 family inet address 10.200.86.10/32set interfaces lo0 unit 0 family iso address 49.0002.0102.0008.6010.00set routing-options router-id 10.200.86.10set routing-options autonomous-system 1set protocols bgp group rr-clients type internalset protocols bgp group rr-clients local-address 10.200.86.10set protocols bgp group rr-clients cluster 10.200.86.10set protocols bgp group rr-clients neighbor 10.200.86.3set protocols bgp group rr-clients neighbor 10.200.86.5set protocols bgp group rr-clients neighbor 10.200.86.7set protocols bgp group rr-clients neighbor 10.200.86.9set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.10set protocols bgp group ibgp neighbor 10.200.86.11


set protocols isis level 1 disableset protocols isis level 2 wide-metrics-onlyset protocols isis interface ge-0/0/0.0 level 1 disableset protocols isis interface lo0.0 level 1 disable

複雑なネットワーク � IGP：OSPF

� IGP拡張：シングルエリア � ラベル配布プロトコル：階層型 LSP

� RSVP拡張：リフレッシュ削減 BGP：ルートリフレクション � 成長の見込み：適度な成長 � 付加的な要件：迅速な障害回復、帯域幅の有効利用、MPLS VPNサービスのサポート

この例では、障害回復力の向上、エッジMPLS VPNサービス（具体的には、レイヤー 3 VPNとVPLS）といったサービスや要件がネットワークに追加され、帯域幅の最適な利用が求められています。ネットワークのエッジレイヤー部分が大きく成長するという想定で、ルートリフレクションや階層型 LSPが拡張のメカニズムとして採用されています。RSVP TE LSPにより、コアリンクの障害回復力を目的としたリンクプロテクション機能の使用が可能になり、障害回復力はサイト内リンクよりも格段に向上しています。図 4.4に示すように、この RSVP LSPは Junosのmost-filledキーワードで設定され、ネットワークリンクの有効利用を可能にしています。

tormoreRRクライアントlo0 10.200.86.9

mortlachLSPフルメッシュlo0 10.200.86.2

glenlivetLSPフルメッシュlo0 10.200.86.6

lagavulinRRクライアントlo0 10.200.86.7

blair LSPフルメッシュlo0 10.200.86.1

dalwhinnieRRクライアントlo0 10.200.86.5 oban

RRクライアントlo0 10.200.86.3

macduffLSPフルメッシュlo0 10.200.86.8

taliskerLSPフルメッシュlo0 10.200.86.4

OSPFエリア0とRSVP 非OSPFエリア0とLDP

aberlourルートリフレクタlo0 10.200.86.10

laphroaigルートリフレクタlo0 10.200.86.11

OSPFエリア0とRSVP

エリア0

図 4.4 複雑なネットワーク


このネットワークはルートリフレクションを使用しているので、ルートリフレクタは PEのネクストホップアドレスを解決できる必要があります。また、LSPをルートリフレクタまで拡張することは望ましくないので、Junosの routing-options resolution

設定を使用して、ネクストホップ情報を検証しています。ネットワークの具体的な構成を示すため、ここでも繰り返しになりますが、dalwhinnie、glenlivet、talisker、tormore、および aberlourの設定を紹介します。その内容は、dalwhinnieから tormore への LSP のトンネリングと、dalwhinie-glenlivet-mortlach-talisker-tormoreを経由することになるパスです。ただし、mortlachのホップは、glenliverから taliskerへの階層型 LSPが設定されているので、dalwhinnieでは認識されません。この LSPは、設定に示すように、glenlivetから taliskerへのコア LSPをトンネリングで通過します。

dalwhinnie（PE）

dalwhinnieは、glenlivetへのアップリンクと lagavulinとのクロス接続に RSVPが設定されています。このリンクは、OSPFエリア0でも動作しています。dalwhinnieは、2つのルートリフレクタのルートリフレクタクライアントに該当します。4台の PEルーターがすべて、この設計に基づいています。階層型 LSPを使用することに加えて、PEルーターは階層型 LSPによる拡張に左右されないので、dalwhinnieへの変更は不要であることに注意してください。LSPには、帯域幅を有効利用する目的でmost-fill、迅速な障害回復を実現する目的で link-protection、LSPの動的なサイズ変更を可能にする目的で auto-bandwidthが設定されています。RSVP制御メッセージのオーバーヘッドを削減するため、RSVPインタフェース階層にリフレッシュ削減が設定されています。BGPは 3つの異なるアドレスファミリで設定され、ユニキャスト IPルートに加えて、レイヤー 2およびレイヤー 3 VPNもサポートしています。

Junosスタイル

system { host-name dalwhinnie; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2002; class super-user; authentication { encrypted-password "$1$Vlgdcorz$TRO4TJKkijW62WJtol2EP1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}


interfaces { ge-0/0/2 { unit 0 { description "Connection to glenlivet ge-0/0/2"; family inet { address 192.168.86.6/30; } family mpls; } } ge-0/0/3 { unit 0 { description "Connection to lagavulin ge-0/0/3"; family inet { address 192.168.86.30/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.5/32; } } }}routing-options { router-id 10.200.86.5; autonomous-system 1;}protocols { rsvp { interface ge-0/0/2.0 { aggregate; link-protection; } interface ge-0/0/3.0 { aggregate; link-protection; } } mpls { statistics { file mpls-stats.txt; auto-bandwidth; } label-switched-path dalwhinnie-to-oban { to 10.200.86.3; most-fill; link-protection; auto-bandwidth; } label-switched-path dalwhinnie-to-lagavulin { to 10.200.86.7; most-fill; link-protection; auto-bandwidth; } label-switched-path dalwhinnie-to-tormore { to 10.200.86.9; most-fill; link-protection;


auto-bandwidth; } interface ge-0/0/2.0; interface ge-0/0/3.0; } bgp { group ibgp { type internal; local-address 10.200.86.5; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 10.200.86.10; neighbor 10.200.86.11; } } ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0; interface ge-0/0/2.0; interface ge-0/0/3.0; } }}

Setスタイル

set system host-name dalwhinnieset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2002set system login user ps class super-userset system login user ps authentication encrypted-password "$1$Vlgdcorz$TRO4TJKkijW62WJtol2EP1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/2/0 unit 0 description "Connection to glenlivet ge-0/2/0"set interfaces ge-0/2/0 unit 0 family inet address 192.168.86.6/30set interfaces ge-0/2/0 unit 0 family mplsset interfaces ge-0/3/0 unit 0 description "Connection to lagavulin ge-0/3/0"set interfaces ge-0/3/0 unit 0 family inet address 192.168.86.30/30set interfaces ge-0/3/0 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.5/32set routing-options router-id 10.200.86.5set routing-options autonomous-system 1set protocols rsvp interface ge-0/0/2.0 aggregateset protocols rsvp interface ge-0/0/2.0 link-protectionset protocols rsvp interface ge-0/0/3.0 aggregateset protocols rsvp interface ge-0/0/3.0 link-protectionset protocols mpls statistics file mpls-stats.txtset protocols mpls label-switched-path dalwhinnie-to-oban to 10.200.86.3set protocols mpls label-switched-path dalwhinnie-to-oban most-fill


set protocols mpls label-switched-path dalwhinnie-to-oban link-protectionset protocols mpls label-switched-path dalwhinnie-to-oban auto-bandwidthset protocols mpls label-switched-path dalwhinnie-to-lagavulin to 10.200.86.7set protocols mpls label-switched-path dalwhinnie-to-lagavulin most-fillset protocols mpls label-switched-path dalwhinnie-to-lagavulin link-protectionset protocols mpls label-switched-path dalwhinnie-to-lagavulin auto-bandwidthset protocols mpls label-switched-path dalwhinnie-to-tormore to 10.200.86.9set protocols mpls label-switched-path dalwhinnie-to-tormore most-fillset protocols mpls label-switched-path dalwhinnie-to-tormore link-protectionset protocols mpls label-switched-path dalwhinnie-to-tormore auto-bandwidthset protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.5set protocols bgp group ibgp family inet unicastset protocols bgp group ibgp family inet-vpn unicastset protocols bgp group ibgp family l2vpn signalingset protocols bgp group ibgp neighbor 10.200.86.10set protocols bgp group ibgp neighbor 10.200.86.11set protocols ospf traffic-engineeringset protocols ospf area 0.0.0.0 interface lo0.0set protocols ospf area 0.0.0.0 interface ge-0/0/2.0set protocols ospf area 0.0.0.0 interface ge-0/0/3.0

glenlivet（P）

今度も、まず Pルーターに注目します。使用しているのは、目的に応じた標準的な OSPF設定です。各 LSPは、link-protectionおよび most-fillで設定されています。link-managementの部分は、階層型 LSPを可能にするための部分です。protocols 階層の link-managementの部分には、階層型 LSPの設定が含まれています。この階層の te-linkおよび peerの設定では、設定の残りの部分で使用される論理リンクとインタフェースの構成体を作成します。

Junosスタイル

system { host-name glenlivet; root-authentication { encrypted-password "$1$RJD1JaT1$.SGbFfpwPCS3yc5gqy3Qw."; ## SECRET-DATA } login { user ps { uid 2000; class super-user; authentication { encrypted-password "$1$VUMxdqLz$hRi6WeofV5MNmn0vKESmV."; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency;


} file messages { any notice; authorization info; } } } interfaces { ge-0/0/1 { unit 0 { description "Connection to blair ge-0/0/1"; family inet { address 192.168.86.10/30; } family iso; family mpls; } } ge-0/0/2 { unit 0 { description "Connection to dalwhinnie ge-0/0/2"; family inet { address 192.168.86.5/30; } family iso; family mpls; } } ge-0/0/3 { unit 0 { description "Connection to mortlach fe-0/0/1"; family inet { address 192.168.86.46/30; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.7/32; } } }}routing-options { router-id 10.200.86.7; autonomous-system 1;}protocols { rsvp { interface ge-0/0/1.0 { aggregate; link-protection; } interface ge-0/0/2.0 { aggregate; link-protection; aggregate; } interface ge-0/0/3.0 { link-protection;


} peer-interface peer-talisker; peer-interface peer-mortlach; peer-interface peer-macduff; peer-interface peer-blair; } mpls { statistics { file mpls-stats.txt; } label-switched-path glenlivet-to-talisker { to 10.200.86.4; most-fill; link-protection; } label-switched-path glenlivet-to-mortlach { to 10.200.86.2; most-fill; link-protection; } label-switched-path glenlivet-to-blair { to 10.200.86.1; most-fill; link-protection; } label-switched-path glenlivet-to-macduff { to 10.200.86.8; most-fill; link-protection; } interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/2.0;

} ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0 { passive; } interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/3.0; peer-interface peer-talisker; peer-interface peer-mortlach; peer-interface peer-blair; peer-interface peer-macduff; } } link-management { te-link glenlivet-to-talisker-te { local-address 192.168.87.2; remote-address 192.168.87.1; label-switched-path glenlivet-to-talisker; } te-link glenlivet-to-mortlach-te { local-address 192.168.87.5; remote-address 192.168.87.6; te-metric 1; label-switched-path glenlivet-to-mortlach; } te-link glenlivet-to-blair-te {


local-address 192.168.87.9; remote-address 192.168.87.10; te-metric 1; label-switched-path glenlivet-to-blair; } te-link glenlivet-to-macduff-te { local-address 192.168.87.13; remote-address 192.168.87.14; te-metric 1; label-switched-path glenlivet-to-macduff; } peer peer-talisker { address 10.200.86.4; te-link glenlivet-to-talisker-te; } peer peer-mortlach { address 10.200.86.2; te-link glenlivet-to-mortlach-te; } peer peer-blair { address 10.200.86.1; te-link glenlivet-to-blair-te; } peer peer-macduff { address 10.200.86.8; te-link glenlivet-to-macduff-te; } } }

Setスタイル

set system host-name glenlivetset system root-authentication encrypted-password "$1$RJD1JaT1$.SGbFfpwPCS3yc5gqy3Qw."set system login user ps uid 2000set system login user ps class super-userset system login user ps authentication encrypted-password "$1$VUMxdqLz$hRi6WeofV5MNmn0vKESmV."set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset interfaces ge-0/0/1 unit 0 description "Connection to blair ge-0/0/1"set interfaces ge-0/0/1 unit 0 family inet address 192.168.86.10/30set interfaces ge-0/0/1 unit 0 family isoset interfaces ge-0/0/1 unit 0 family mplsset interfaces ge-0/0/2 unit 0 description "Connection to dalwhinnie ge-0/0/2"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.5/30set interfaces ge-0/0/2 unit 0 family isoset interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 unit 0 description "Connection to mortlach fe-0/0/1"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.46/30set interfaces ge-0/0/3 unit 0 family isoset interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.7/32set routing-options router-id 10.200.86.7set routing-options autonomous-system 1 set protocols rsvp interface ge-0/0/1.0 aggregateset protocols rsvp interface ge-0/0/1.0 link-protection


set protocols rsvp interface ge-0/0/2.0 aggregateset protocols rsvp interface ge-0/0/2.0 link-protectionset protocols rsvp interface ge-0/0/3.0 aggregateset protocols rsvp interface ge-0/0/3.0 link-protectionset protocols rsvp peer-interface peer-taliskerset protocols rsvp peer-interface peer-mortlachset protocols rsvp peer-interface peer-macduffset protocols rsvp peer-interface peer-blairset protocols mpls label-switched-path glenlivet-to-talisker to 10.200.86.4set protocols mpls label-switched-path glenlivet-to-talisker most-fillset protocols mpls label-switched-path glenlivet-to-talisker link-protectionset protocols mpls label-switched-path glenlivet-to-mortlach to 10.200.86.2set protocols mpls label-switched-path glenlivet-to-mortlach most-fillset protocols mpls label-switched-path glenlivet-to-mortlach link-protectionset protocols mpls label-switched-path glenlivet-to-blair to 10.200.86.1set protocols mpls label-switched-path glenlivet-to-blair most-fillset protocols mpls label-switched-path glenlivet-to-blair link-protectionset protocols mpls label-switched-path glenlivet-to-macduff to 10.200.86.8set protocols mpls label-switched-path glenlivet-to-macduff most-fillset protocols mpls label-switched-path glenlivet-to-macduff link-protectionset protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols ospf traffic-engineeringset protocols ospf area 0.0.0.0 interface lo0.0 passiveset protocols ospf area 0.0.0.0 interface ge-0/0/1.0set protocols ospf area 0.0.0.0 interface ge-0/0/2.0set protocols ospf area 0.0.0.0 interface ge-0/0/3.0set protocols ospf area 0.0.0.0 peer-interface peer-taliskerset protocols ospf area 0.0.0.0 peer-interface peer-mortlachset protocols ospf area 0.0.0.0 peer-interface peer-blairset protocols ospf area 0.0.0.0 peer-interface peer-macduffset protocols link-management te-link glenlivet-to-talisker-te local-address 192.168.87.2set protocols link-management te-link glenlivet-to-talisker-te remote-address 192.168.87.1set protocols link-management te-link glenlivet-to-talisker-te label-switched-path glenlivet-to-taliskerset protocols link-management te-link glenlivet-to-mortlach-te local-address 192.168.87.5set protocols link-management te-link glenlivet-to-mortlach-te remote-address 192.168.87.6set protocols link-management te-link glenlivet-to-mortlach-te te-metric 1set protocols link-management te-link glenlivet-to-mortlach-te label-switched-path glenlivet-to-mortlachset protocols link-management te-link glenlivet-to-blair-te local-address 192.168.87.9set protocols link-management te-link glenlivet-to-blair-te remote-address 192.168.87.10set protocols link-management te-link glenlivet-to-blair-te te-metric 1set protocols link-management te-link glenlivet-to-blair-te label-switched-path glenlivet-to-blairset protocols link-management te-link glenlivet-to-macduff-te local-address 192.168.87.13set protocols link-management te-link glenlivet-to-macduff-te remote-address 192.168.87.14set protocols link-management te-link glenlivet-to-macduff-te te-metric 1set protocols link-management te-link glenlivet-to-macduff-te label-switched-path glenlivet-to-macduffset protocols link-management peer peer-talisker address 10.200.86.4set protocols link-management peer peer-talisker te-link glenlivet-to-


talisker-teset protocols link-management peer peer-mortlach address 10.200.86.2set protocols link-management peer peer-mortlach te-link glenlivet-to-mortlach-teset protocols link-management peer peer-blair address 10.200.86.1set protocols link-management peer peer-blair te-link glenlivet-to-blair-teset protocols link-management peer peer-macduff address 10.200.86.8set protocols link-management peer peer-macduff te-link glenlivet-to-macduff-te

talisker（P）

taliskerの P設定は、glenlivetの P設定とよく似ています。

Junosスタイル

system { host-name talisker; root-authentication { encrypted-password "$1$RJD1JaT1$.SGbFfpwPCS3yc5gqy3Qw."; ## SECRET-DATA } login { user ps { uid 2000; class super-user; authentication { encrypted-password "$1$grlc52X7$RF98wUcuOF.b2FiZZKKLC1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } }}interfaces { fe-0/0/1 { description "Connection to macduff ge-0/0/1"; unit 0 { family inet { address 192.168.86.13/30; } family mpls; } } e1-1/0/0 { description "Connection to mortlach e1-0/0/0"; unit 0 { family inet { address 192.168.86.21/30; } family mpls;


} } fe-2/0/0 { description "Connection to blair ge-0/0/3"; unit 0 { family inet { address 192.168.86.17/30; } family mpls; } } fe-2/0/1 { description "Connection to tormore ge-0/0/2"; unit 0 { family inet { address 192.168.86.34/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.4/32; } } } } routing-options { router-id 10.200.86.4; autonomous-system 1;}protocols { rsvp { interface fe-0/0/1.0 { aggregate; link-protection; } interface e1-1/0/0.0 { aggregate; link-protection; } interface fe-2/0/0.0 { aggregate; link-protection; } interface fe-2/0/1.0 { aggregate; link-protection; } peer-interface peer-glenlivet; peer-interface peer-mortlach; peer-interface peer-blair; peer-interface peer-macduff; } mpls { label-switched-path talisker-to-glenlivet { to 10.200.86.7; most-fill; link-protection; } label-switched-path talisker-to-mortlach { to 10.200.86.2;


most-fill; link-protection; } label-switched-path talisker-to-blair { to 10.200.86.1; most-fill; link-protection; } label-switched-path talisker-to-macduff { to 10.200.86.8; most-fill; link-protection; } interface fe-0/0/1.0; interface e1-1/0/0.0; interface fe-2/0/0.0; interface fe-2/0/1.0; } ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0 { passive; }interface fe-0/0/1.0;interface e1-1/0/0.0;interface fe-2/0/0.0;interface fe-2/0/1.0; peer-interface peer-glenlivet; peer-interface peer-mortlach; peer-interface peer-blair; peer-interface peer-macduff; } } link-management { te-link talisker-to-glenlivet-te { local-address 192.168.87.1; remote-address 192.168.87.2; te-metric 1; label-switched-path talisker-to-glenlivet; } te-link talisker-to-mortlach-te { local-address 192.168.87.5; remote-address 192.168.87.6; te-metric 1; label-switched-path talisker-to-mortlach; } te-link talisker-to-blair-te { local-address 192.168.87.9; remote-address 192.168.87.10; te-metric 1; label-switched-path talisker-to-blair; } te-link talisker-to-macduff-te { local-address 192.168.87.13; remote-address 192.168.87.14; te-metric 1; label-switched-path talisker-to-macduff; } peer peer-glenlivet { address 10.200.86.7; te-link talisker-to-glenlivet-te; }


peer peer-mortlach { address 10.200.86.2; te-link talisker-to-mortlach-te; } peer peer-blair { address 10.200.86.1; te-link talisker-to-blair-te; } peer peer-macduff { address 10.200.86.8; te-link talisker-to-macduff-te; } }}

Setスタイル

set system host-name taliskerset system root-authentication encrypted-password "$1$RJD1JaT1$.SGbFfpwPCS3yc5gqy3Qw."set system login user ps uid 2000set system login user ps class super-userset system login user ps authentication encrypted-password "$1$grlc52X7$RF98wUcuOF.b2FiZZKKLC1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset interfaces fe-0/0/1 description "Connection to macduff ge-0/0/1"set interfaces fe-0/0/1 unit 0 family inet address 192.168.86.13/30set interfaces fe-0/0/1 unit 0 family mplsset interfaces e1-1/0/0 description "Connection to mortlach e1-0/0/0"set interfaces e1-1/0/0 unit 0 family inet address 192.168.86.21/30set interfaces e1-1/0/0 unit 0 family mplsset interfaces fe-2/0/0 description "Connection to blair ge-0/0/3"set interfaces fe-2/0/0 unit 0 family inet address 192.168.86.17/30set interfaces fe-2/0/0 unit 0 family mplsset interfaces fe-2/0/1 description "Connection to tormore ge-0/0/2"set interfaces fe-2/0/1 unit 0 family inet address 192.168.86.34/30set interfaces fe-2/0/1 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.4/32set routing-options router-id 10.200.86.4set routing-options autonomous-system 1 set protocols rsvp interface fe-0/0/1.0 aggregateset protocols rsvp interface fe-0/0/1.0 link-protectionset protocols rsvp interface e1-1/0/0.0 aggregateset protocols rsvp interface e1-1/0/0.0 link-protectionset protocols rsvp interface fe-2/0/0.0 aggregateset protocols rsvp interface fe-2/0/0.0 link-protectionset protocols rsvp interface fe-2/0/1.0 aggregateset protocols rsvp interface fe-2/0/1.0 link-protectionset protocols rsvp peer-interface peer-glenlivetset protocols rsvp peer-interface peer-mortlachset protocols rsvp peer-interface peer-blairset protocols rsvp peer-interface peer-macduffset protocols mpls label-switched-path talisker-to-glenlivet to 10.200.86.7set protocols mpls label-switched-path talisker-to-glenlivet most-fillset protocols mpls label-switched-path talisker-to-glenlivet link-protectionset protocols mpls label-switched-path talisker-to-mortlach to 10.200.86.2set protocols mpls label-switched-path talisker-to-mortlach most-fillset protocols mpls label-switched-path talisker-to-mortlach link-protectionset protocols mpls label-switched-path talisker-to-blair to 10.200.86.1


set protocols mpls label-switched-path talisker-to-blair most-fillset protocols mpls label-switched-path talisker-to-blair link-protectionset protocols mpls label-switched-path talisker-to-macduff to 10.200.86.8set protocols mpls label-switched-path talisker-to-macduff most-fillset protocols mpls label-switched-path talisker-to-macduff link-protectionset protocols mpls interface fe-0/0/1.0set protocols mpls interface e1-1/0/0.0set protocols mpls interface fe-2/0/0.0set protocols mpls interface fe-2/0/1.0set protocols ospf traffic-engineeringset protocols ospf area 0.0.0.0 interface lo0.0 passiveset protocols ospf area 0.0.0.0 interface fe-0/0/1.0set protocols ospf area 0.0.0.0 interface e1-1/0/0.0set protocols ospf area 0.0.0.0 interface fe-2/0/0.0set protocols ospf area 0.0.0.0 interface fe-2/0/1.0set protocols ospf area 0.0.0.0 peer-interface peer-glenlivetset protocols ospf area 0.0.0.0 peer-interface peer-mortlachset protocols ospf area 0.0.0.0 peer-interface peer-blairset protocols ospf area 0.0.0.0 peer-interface peer-macduffset protocols link-management te-link talisker-to-glenlivet-te local-address 192.168.87.1set protocols link-management te-link talisker-to-glenlivet-te remote-address 192.168.87.2set protocols link-management te-link talisker-to-glenlivet-te te-metric 1set protocols link-management te-link talisker-to-glenlivet-te label-switched-path talisker-to-glenlivetset protocols link-management te-link talisker-to-mortlach-te local-address 192.168.87.5set protocols link-management te-link talisker-to-mortlach-te remote-address 192.168.87.6set protocols link-management te-link talisker-to-mortlach-te te-metric 1set protocols link-management te-link talisker-to-mortlach-te label-switched-path talisker-to-mortlachset protocols link-management te-link talisker-to-blair-te local-address 192.168.87.9set protocols link-management te-link talisker-to-blair-te remote-address 192.168.87.10set protocols link-management te-link talisker-to-blair-te te-metric 1set protocols link-management te-link talisker-to-blair-te label-switched-path talisker-to-blairset protocols link-management te-link talisker-to-macduff-te local-address 192.168.87.13set protocols link-management te-link talisker-to-macduff-te remote-address 192.168.87.14set protocols link-management te-link talisker-to-macduff-te te-metric 1set protocols link-management te-link talisker-to-macduff-te label-switched-path talisker-to-macduffset protocols link-management peer peer-glenlivet address 10.200.86.7set protocols link-management peer peer-glenlivet te-link talisker-to-glenlivet-teset protocols link-management peer peer-mortlach address 10.200.86.2set protocols link-management peer peer-mortlach te-link talisker-to-mortlach-teset protocols link-management peer peer-blair address 10.200.86.1set protocols link-management peer peer-blair te-link talisker-to-blair-teset protocols link-management peer peer-macduff address 10.200.86.8set protocols link-management peer peer-macduff te-link talisker-to-macduff-te


tormore（PE）

tormoreの設定は情報を網羅するために紹介していますが、dalwhinnieの設定とほぼ同じものです。

Junosスタイル

system { host-name tormore; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2002; class super-user; authentication { encrypted-password "$1$Vlgdcorz$TRO4TJKkijW62WJtol2EP1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/2 { description "Connection to talisker ge-2/0/1"; unit 0 { family inet { address 192.168.86.33/30; } family mpls; } } ge-0/0/3 { description "Connection to oban ge-0/0/3"; unit 0 { family inet { address 192.168.86.37/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.200.86.9/32;


} } }}routing-options { router-id 10.200.86.9; autonomous-system 1;}protocols { rsvp { interface ge-0/0/2.0 { aggregate; link-protection; } interface ge-0/0/3.0 { aggregate; link-protection; } } mpls { statistics { file mpls-stats.txt; } label-switched-path tormore-to-oban { to 10.200.86.3; most-fill; link-protection; auto-bandwidth; } label-switched-path tormore-to-dalwhinnie { to 10.200.86.5; most-fill; link-protection; auto-bandwidth; } label-switched-path tormore-to-lagavulin { to 10.200.86.7; most-fill; link-protection; auto-bandwidth; } interface ge-0/0/2.0; interface ge-0/0/3.0; } bgp { group ibgp { type internal; local-address 10.200.86.9; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 10.200.86.10; neighbor 10.200.86.11; } } ospf { traffic-engineering;


area 0.0.0.0 { interface lo0.0; interface ge-0/0/2.0; interface ge-0/0/3.0; } }}

Setスタイル

set system host-name tormoreset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2002set system login user ps class super-userset system login user ps authentication encrypted-password "$1$Vlgdcorz$TRO4TJKkijW62WJtol2EP1"set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/2 description "Connection to talisker fe-2/0/1"set interfaces ge-0/0/2 unit 0 family inet address 192.168.86.33/30set interfaces ge-0/0/2 unit 0 family mplsset interfaces ge-0/0/3 description "Connection to oban ge-0/0/3"set interfaces ge-0/0/3 unit 0 family inet address 192.168.86.37/30set interfaces ge-0/0/3 unit 0 family mplsset interfaces lo0 unit 0 family inet address 10.200.86.9/32set routing-options router-id 10.200.86.9set routing-options autonomous-system 1set protocols rsvp interface ge-0/0/2.0 aggregateset protocols rsvp interface ge-0/0/2.0 link-protectionset protocols rsvp interface ge-0/0/3.0 aggregateset protocols rsvp interface ge-0/0/3.0 link-protectionset protocols mpls statistics file mpls-stats.txtset protocols mpls label-switched-path tormore-to-oban to 10.200.86.3set protocols mpls label-switched-path tormore-to-oban most-fillset protocols mpls label-switched-path tormore-to-oban link-protectionset protocols mpls label-switched-path tormore-to-oban auto-bandwidthset protocols mpls label-switched-path tormore-to-dalwhinnie to 10.200.86.5set protocols mpls label-switched-path tormore-to-dalwhinnie most-fillset protocols mpls label-switched-path tormore-to-dalwhinnie link-protectionset protocols mpls label-switched-path tormore-to-dalwhinnie auto-bandwidthset protocols mpls label-switched-path tormore-to-lagavulin to 10.200.86.7set protocols mpls label-switched-path tormore-to-lagavulin most-fillset protocols mpls label-switched-path tormore-to-lagavulin link-protectionset protocols mpls label-switched-path tormore-to-lagavulin auto-bandwidthset protocols mpls interface ge-0/0/2.0set protocols mpls interface ge-0/0/3.0set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.9set protocols bgp group ibgp family inet unicastset protocols bgp group ibgp family inet-vpn unicastset protocols bgp group ibgp family l2vpn signalingset protocols bgp group ibgp neighbor 10.200.86.10set protocols bgp group ibgp neighbor 10.200.86.11set protocols ospf traffic-engineeringset protocols ospf area 0.0.0.0 interface lo0.0set protocols ospf area 0.0.0.0 interface ge-0/0/2.0set protocols ospf area 0.0.0.0 interface ge-0/0/3.0


aberlour（RR）

このルートリフレクタの設定は、極めてシンプルです。blairへの接続、ルートリフレクタクライアント（group rr-clients）との BGPセッション、さらに他のルートリフレクタ（laphroaig）との BGPセッションについては、OSPFで設定されています。この設定によって、BGPルート配信の冗長メカニズムが実現します。さらに冗長化が必要な場合は、各ルートリフレクタに 2番目の接続を追加します。ただし、ルートリフレクタを二重化する設計を採用すると、重要な単一障害点に制約が生じます。aberlourは Junosの routing-options resolutionキーワードも設定され、PEルーターへのMPLSの到達可能性がない場合でも、VPNルートの検証を可能にしています。

Junosスタイル

system { host-name aberlour; root-authentication { encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."; ## SECRET-DATA } login { user ps { uid 2002; class super-user; authentication { encrypted-password "$1$Vlgdcorz$TRO4TJKkijW62WJtol2EP1"; ## SECRET-DATA } } } services { ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-0/0/0 { description "Connection to blair ge-0/0/0"; unit 0 { family inet { address 192.168.86.54/30; } } } lo0 { unit 0 { family inet { address 10.200.86.10/32; } } }


}routing-options { router-id 10.200.86.10; autonomous-system 1; resolution { rib bgp.l3vpn.0 { resolution-ribs inet.0; } }}protocols { bgp { group rr-clients { type internal; local-address 10.200.86.10; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } cluster 10.200.86.10; neighbor 10.200.86.5; neighbor 10.200.86.7; neighbor 10.200.86.3; neighbor 10.200.86.9; } group ibgp { type internal; local-address 10.200.86.10; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 10.200.86.11; } } ospf { area 0.0.0.0 { interface ge-0/0/0.0; interface lo0.0; } }}

Setスタイル

set system host-name aberlourset system root-authentication encrypted-password "$1$yCV3hpZD$EWpPM8TW8exo0r/6v.Yfk."set system login user ps uid 2002set system login user ps class super-userset system login user ps authentication encrypted-password "$1$Vlgdcorz$TRO4TJKkijW62WJtol2EP1"


set system services sshset system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyset interfaces ge-0/0/0 description "Connection to blair ge-0/0/0"set interfaces ge-0/0/0 unit 0 family inet address 192.168.86.54/30set interfaces lo0 unit 0 family inet address 10.200.86.10/32set routing-options router-id 10.200.86.10set routing-options autonomous-system 1set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0set protocols bgp group rr-clients type internalset protocols bgp group rr-clients local-address 10.200.86.10set protocols bgp group rr-clients family inet unicastset protocols bgp group rr-clients family inet-vpn unicastset protocols bgp group rr-clients family l2vpn signalingset protocols bgp group rr-clients cluster 10.200.86.10set protocols bgp group rr-clients neighbor 10.200.86.5set protocols bgp group rr-clients neighbor 10.200.86.7set protocols bgp group rr-clients neighbor 10.200.86.3set protocols bgp group rr-clients neighbor 10.200.86.9set protocols bgp group ibgp type internalset protocols bgp group ibgp local-address 10.200.86.10set protocols bgp group ibgp family inet unicastset protocols bgp group ibgp family inet-vpn unicastset protocols bgp group ibgp family l2vpn signalingset protocols bgp group ibgp neighbor 10.200.86.11set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set protocols ospf area 0.0.0.0 interface lo0.0

まとめネットワークの問題を解決する方法には、さまざまな種類がありますが、実際に最適な方法を判断するのは難しい場合もあります。一般的なネットワークの問題については、本書で紹介した例が有効な解決策になります。例として取り上げたネットワークのいずれかと、実際のネットワークでニーズが完全に一致することはないと思われますが、ニーズに応じて参考になる例を選別することは可能です。これが Junosのモジュール化された分散型アーキテクチャの最も優れた強みの 1つです。この強みにより、ユーザーは設定部分を選別し、簡単な操作でそのロード、アクティブ化、非アクティブ化を実行するとともに、変換を容易にするため、異なるプロトコルを並行して実行することも可能になります。

本書で紹介した例は、「カット＆ペースト」式のアプローチでMPLSの導入事例に応用するだけでなく、MPLSや Junosを使用して最適なカスタマイズ設計を実現するためのさまざまな方法に注意を向けることも目的としていました。

ヒント www.juniper.net/dayoneにアクセスし、本書のダウンロードページに移動すると、本書のコピー＆ペースト対応版が無償で公開されています。このファイルはリッチテキスト形式であり、さまざまなテキストエディタで開いて、Junosの設定に直接挿入できます。

http://www.juniper.net/dayone


付録

付録A：MXシリーズルーターのVPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

付録B：Junos Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

次に参照すべき資料およびサイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

202

付録 A：MXシリーズルーターの VPLS

ジュニパーネットワークスルーターのMXシリーズは、VPLSにさらなる機能性と構成の容易さを追加します。この付録では、追加されるこれらの特長について詳しく調査します。図 A.1は、この付録用の新しいサンプルネットワークです。PEルーターの dalwhinnieと oban（MX80ルーター）、3つの CEルーター（CE1、CE3、CE4）、および 2つのコアルーター（glenlivetとmacduff）が示されています。付録 Aで説明される事例については、この図を参照してください。

.1

.5

.13

.10

.9 .6

.2 .14


oak (VPLS) - irb.100

192.168.90.100/24

CE4 oak (VPLS)

oban lo0 10.200.86.3


macduff lo0 10.200.86.2

ISP

CE1 oak (VPLS)

CE3 oak (VPLS)

fe-0/3/0.550 192.168.90.1/24

fe-0/3/0. 0 192.168.90.5/24

ge-1/0/0.550 ge-1/0/2.0 ge-0/2/0.0 ge-0/2/1.0 ge-1/0/2.0

ge-1/0/0. 0

fe-0/3/1. 700 192.168.90.10/24

fe-0/3/1. 0 192.168.120.2/30

ge-1/0/6.0 .1/30

ge-1/0/6.700

特に明記されていない限り、コアインタフェースのIPアドレスはすべて192.168.86/24ネットワークの/30サブネットに属しています。

10.220.90.0/24

図 A.1 MX80 PEを使用するサンプルネットワーク

CE側のインタフェースとdalwhinnieルーター上の VPLSインスタンス oakのVPLS構成を以下に示します（MX80構成と Jシリーズルーターの構成を比較するには、第 2章を参照）。 regress@dalwhinnie> show configuration routing-instances oakinstance-type vpls;vlan-id none;interface ge-1/0/0.550;routing-interface irb.100;route-distinguisher 10.200.86.1:100;vrf-target target:300:200;protocols { vpls { site-range 5; no-tunnel-services; site ce4 { site-identifier 4; interface ge-1/0/0.550; } }}regress@dalwhinnie> show configuration interfacesge-1/0/0 {

付録 203

vlan-tagging; speed 100m; encapsulation vlan-vpls; unit 550 { encapsulation vlan-vpls; vlan-id 550; family vpls; }} . . . . . .irb { unit 100 { family inet { address 192.168.90.100/24; } }}lo0 { unit 0 { family inet { address 127.0.0.1/32; address 10.200.86.1/32; } }}

MX構成で注目すべき 1つ目の相違点は、MX80 PE上の CE側のインタフェースに input-および output-vlan-mapsがないことです。代わりに、VPLSインスタンスに vlan-id値（この例では none）が指定されています。第 2章では、input-vlan-mapを使用してVLANタグを削除したので、パケットは VLANタグを使用せずにコアを経由しました。また、output-vlan-mapを使用して、送信時に宛先 PEから適切な VLANタグをパケットに追加しなおしました。パケットが適切な vlan-id値とVLANスタックの高さを使用してコアを出入りできるようにするには、このマッピングを行う必要があります。実質的には、第 2章の vlan-map構成は、MPLSコアを通過するために VLANスタックの高さをゼロに標準化しました。VLANタギングを使用するインタフェース経由で PEにアクセスしているものと、VLANタギングをまったく使用しないインタフェース経由で PEにアクセスしているものがある場合、一般的な VPLSインスタンスの CEが互いにやり取りするためには、このような標準化が必要です。CE側の VPLSインタフェースで構成されたさまざまな vlan-idを PEが持つ場合、CEが互いにやり取りできるようにコア全体で VLANを標準化する必要があります。コアを通過するために input-vlan-mapを使用して受信 PEで VLANスタックの高さをゼロに標準化することにより、送信 PEの CE側インタフェースで output-vlan-mapが正しい vlan-id値（または none）をパケットに配置できます。しかしMXシリーズは、PEへの受信時にvlan-mapを使用せずに0～2個のスタックされた VLANタグ付きのパケットを受け入れることができます。VPLSインスタンスの vlan-id構成により、コアを経由するパケットの VLANスタックの高さが自動的に標準化されます。MXシリーズルーターは、指定されたパケットの受信 /送信インタフェースに必要な VLANタギング操作を自動的に計算します。


注このMXの例では、VLANスタックの高さはゼロ（vlan-idは none）に標準化されます。スタックの高さの値を 1に標準化するには、vlan-id値をゼロ以外の値に設定する必要があります。vlan-tags構成は、vlan-idとほとんど同じ機能を提供します。ただし、唯一の違いとして、vlan-tagsは 2つの VLAN値（innerとouter）を必要とするため、VLANスタックの高さを 2に標準化します。

ベストプラクティス一般的な VPLSインスタンスの場合、同じVLANスタックの高さに標準化する必要がありますが、必ずしも各 PEがMXシリーズルーター上の特定の VPLSインスタンスに対してVLANスタックで同じVLAN値を構成する必要はありません。しかし、そうすることがベストプラクティスです。さらに VLANスタックの値は、各 VPLSインスタンスごとに固有の値である必要はありません。2つの固有な VPLSインスタンスに対して同じ vlan-id/vlan-tags値を構成できます。これは、コアの vlan-id値はトラフィックの区別や分類には使用されないためです。コアの vlan-id値は、主に 802.1p CoSマーキングの搬送に使用されます。

以下の図 A.2は、MXシリーズの PE上の VPLSインスタンスの例を示しています。コア全体で VLANはゼロに標準化されています（vlan-idは none）。コア全体でVLANをゼロに標準化することにより、VLANタグが転送されなくなるため、パケットあたりのオーバーヘッドを最低限に抑えられます。

注：LSPラベルは示されていません。

vlan-id none vlan-id 1 vlan-tags inner 1 outer 2 = MXシリーズのPE = CE ルーター = プロバイダスイッチ



VLANタグ700


インナーVLANタグ100

アウターVLANタグ750


CE1

CE3 CE4

CE2 PE1 PE2

PE4 PE3


任意のVLANタグ1パケットデータ

任意の

VLA

Nタグ

1


インナーVLANタグ400

アウターVLANタグ600

任意の

VLA

Nタグ

2

任意のVLANタグ2

任意のVLANタグ2任意のVLANタグ1

図 A.2 VLAN標準化の図

図 A.2は、VPLSのコアを通過するために VLANスタックの高さを 0～ 2個のVLANタグに標準化する方法を示しています。それにより、適切な vlan-id値およびVLANスタックの高さでのみパケットが送信PEインタフェースから送信されます。ページ上で確認しながら追跡してみましょう。CE1が、VLANスタックの高さ 2でPE1にパケットを送信します。VLANスタックがコア全体でゼロに標準化される場合、PE1はパケットから両方の VLANタグ（pop 600 pop 400）を削除してからリモートPEへ転送します。PE2は、CE2へ送信するパケットに VLANを一切追加しま

付録 205

せん。PE3は VLANタグを 1つだけ（push 700）追加し、PE4はインナータグ100およびアウタータグ 750（push 100 push 750）を追加します。コア全体で 1個の VLANに標準化する必要がある場合（図 A.2の vlan-id 1）、PE1はアウターVLANタグ 600を削除し、vlan-id 1の VLANタグ 400をスワップします（pop 600 swap 1）。PE2はパケット（pop 1）から vlan-id 1を削除してからCE2へ送信します。PE3は vlan-id 1を vlan-id 700とスワップしてからCE3へ送信します（swap 700）。PE4は vlan-id 1を vlan-id 100とスワップし、値 750の追加タグをプッシュします（swap 100 push 750）。

実践：VLANスタック操作のマッピング

図 A.2の VPLSインスタンスがインナー 1およびアウター 2の VLANタグ用に構成されている場合、PE1に入るときの VLANタグ操作はどうなるでしょうか。また、PE2、PE3、および PE4からの送信時のVLANタグ操作はどうなるでしょうか。あなたの解答を本書の J-Netページ（www.juniper.net/dayone）に投稿してください。

VPLSインスタンスの oakを使用する例は、VLANスタックの高さをゼロに標準化します。CoS要件に応じて（本書では扱っていませんが）、コアを通過するパケットの vlan-idのスタックの高さを 1または 2に標準化する必要がある可能性があります。

注 MXシリーズのアーキテクチャに固有の VLAN標準化動作は「暗黙の VLAN変換」と呼ばれることがあり、サービスプロバイダが最低限の非常に簡単な構成で複雑なVLAN変換計画を実現するために使用する場合があります。

もう 1つの注目すべき点は、VPLSインスタンス内の任意的な存在の irb（integrated routing and bridging）インタフェースです。VPLSインスタンスにこのインタフェースが存在することにより、いくつかの追加機能が実現されます。VPLSカスタマへのインターネットアクセス用に、サービスプロバイダがクラウドでゲートウェイを提供することが可能になります。また、ISP用の追加のトラブルシューティング機能も実現されます。興味深いこれらの機能について調べてみましょう。エンド VPLSサイトの 1つでルーターを持つことが、それに伴う管理オーバーヘッドおよび潜在的な冗長性の問題によって実際的でない可能性があるために、同一サーキットを介した VPLSおよびインターネットアクセスを含むサービスが望ましい場合、irbインタフェースを VPLSに配置することで付加価値を与えることができます。たとえば、VPLSエンドサイトの 1つにインターネットアクセス用のオンサイトルーターがあり、そのルーターまたはサイトのアクセスサーキットが故障した場合、共通 VPLSドメイン内にあるほかのすべてのサイトがインターネットに接続できなくなります。VPLSインスタンス内にある別の CEサイトで冗長ルーターを追加することは可能ですが、そうすることにより、管理オーバーヘッドおよび実行すべき潜在的なフェイルオーバー手順が増加します。PEルーター上の irbインタフェースを経由するインターネットアクセスを使用するVPLSを持つことにより、VPLSユーザー用のクラウドにインターネットゲートウェイが提供されます。インスタンス oak内にある任意の CEサイトは、他の CEサイトが故障しているかどうかに関わらず、irbインタフェース経由で外部ルートに到達できます（当然ながら、irbインタフェース付きの PEが故障したり外部接続を失ったりしないことが前提）。VPLSインスタンス内の irbインタフェースの同様の使用方法には、この他に VPLS-L3VPN接続の提供または irbインタフェースを用いたVPLSから L3VPNサービスへの顧客移行支援などが含まれます。


注 VPLSインスタンス内の永久的な irbインタフェースについて指摘すべき重要なポイントは、マスタールーティングインスタンス内に irbインタフェースのレイヤー 3アドレスが存在することにより、ネットワークPEルーターが CEルーターのアドレス空間を認識するようになるということです。CEルーターは、CEアドレス指定計画のための指定されたパブリック IP空間を持ち、それを使用する必要があります。

出力例を見てみましょう。ここでは、oakのアドレス空間が直接到達可能であることが示されています。irb.100インタフェース経由で dalwhinnieのマスターインスタンスから到達できます。

regress@dalwhinnie> show route 192.168.90.5inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)+ = Active Route, - = Last Active, * = Both192.168.90.0/24 *[Direct/0] 3d 00:16:18 > via irb.100regress@dalwhinnie> ping 192.168.90.5PING 192.168.90.5 (192.168.90.5): 56 data bytes64 bytes from 192.168.90.5: icmp_seq=0 ttl=64 time=0.984 ms64 bytes from 192.168.90.5: icmp_seq=1 ttl=64 time=0.933 ms64 bytes from 192.168.90.5: icmp_seq=2 ttl=64 time=0.899 ms64 bytes from 192.168.90.5: icmp_seq=3 ttl=64 time=0.931 ms64 bytes from 192.168.90.5: icmp_seq=4 ttl=64 time=0.905 ms^C--- 192.168.90.5 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.899/0.930/0.984/0.030 ms

VPLSインスタンス oak内のルーター CE4を見てみましょう。一般的な VPLSサービスでは、CE4は oak内の他のサイトにトラフィックを送信できるだけですが、irbインタフェースを追加すると、oak内のユーザーは、コアネットワークの内部アドレスなど、VPLSインスタンスの外側にあるサイトに接続できるようになります。ここでは、CE4は 192.168.86.1、dalwhinnie上の ge-1/0/2.0に対して pingを行えます。

regress@ce4> ping 192.168.86.1PING 192.168.86.1 (192.168.86.1): 56 data bytes64 bytes from 192.168.86.1: icmp_seq=0 ttl=64 time=0.816 ms64 bytes from 192.168.86.1: icmp_seq=1 ttl=64 time=0.767 ms64 bytes from 192.168.86.1: icmp_seq=2 ttl=64 time=0.810 ms64 bytes from 192.168.86.1: icmp_seq=3 ttl=64 time=0.802 ms^C--- 192.168.86.1 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.767/0.799/0.816/0.019 ms

VPLSユーザーが内部のコアアドレスまたはその他の制限付きの機密サイトにトラフィックを送信できるようにしても意味がないかもしれません。このような潜在的な問題を修正するには、VPLSインスタンスの irbインタフェース上に入力フィルタを構成します。以下の例では、コアの内部アドレスへのアクセスは拒否するが、その他のネットワークへのアクセスは許可するフィルタを適用しています。[edit interfaces irb]regress@dalwhinnie# showunit 100 { family inet { address 192.168.90.100/24; }}[edit interfaces irb]regress@dalwhinnie# set unit 100 family inet filter input vpls-internet-access

付録 207

[edit interfaces irb]regress@dalwhinnie# showunit 100 { family inet { filter { input vpls-internet-access; } address 192.168.90.100/24; }}

したがって、irb.100に適用される vpls-internet-accessフィルタは、以下のように、コアネットワークアドレス宛てのトラフィックを廃棄し、その試みをログに記録し、その他全ての宛先へのトラフィックを許可します。

regress@dalwhinnie> show configuration firewall family inet filter vpls-internet-accessterm 10 { from { destination-prefix-list { internal-routes; } } then { count vpls-internal-attempt; discard; }}term 20 { then accept;}regress@dalwhinnie> show configuration policy-optionsprefix-list internal-routes { 192.168.86.0/24;} . . . . . . . . .regress@dalwhinnie>

このフィルタを適用することにより、oak内の CEルーターは、内部のコアネットワークアドレスに到達できなくなります。

regress@ce4> ping 192.168.86.1PING 192.168.86.1 (192.168.86.1): 56 data bytes^C--- 192.168.86.1 ping statistics ---191 packets transmitted, 0 packets received, 100% packet loss

regress@ce4>

CE4が 192.168.86.1に対してpingを試行するたびに、vpls-internet-accessフィルタのカウンタが増加します。これは、フィルタが実際にトラフィックをブロックしていることを示しています。

regress@dalwhinnie> show firewall filter vpls-internet-accessFilter: vpls-internet-accessCounters:Name Bytes Packetsvpls-internal-attempt 14868 177


regress@dalwhinnie> show firewall filter vpls-internet-accessFilter: vpls-internet-accessCounters:Name Bytes Packetsvpls-internal-attempt 16464 196

regress@dalwhinnie>

次に、図 A.3では、oak内のユーザーが外部のサイト 192.168.120.1/24に到達することを望んでいます。

.1

.5

.13

.10

.9 .6

.2 .14


oak (VPLS) - irb.100

192.168.90.100/24

CE4 oak (VPLS)

oban lo0 10.200.86.3


macduff lo0 10.200.86.2

ISP

CE1 oak (VPLS)

CE3 oak (VPLS)

fe-0/3/0.550 192.168.90.1/24

fe-0/3/0. 0 192.168.90.5/24

ge-1/0/0.550 ge-1/0/2.0 ge-0/2/0.0 ge-0/2/1.0 ge-1/0/2.0

ge-1/0/0. 0

fe-0/3/1. 700 192.168.90.10/24

fe-0/3/1. 0 192.168.120.2/30

ge-1/0/6.0 .1/30

ge-1/0/6.700

特に明記されていない限り、コアインタフェースの IPアドレスはすべて 192.168.86/24ネットワークの /30サブネットに属しています。

外部サイト10.220.90.1/24に到達したい。

10.220.90.0/24をアドバタイズしています。

外部サイト10.220.90.1/24に到達したい。

図 A.3 irbインタフェース経由の VPLSにおける外部ネットワークの到達可能性

10.220.90/24を提供している ISPは dalwhinnieとBGPセッションを確立します。CE4は到達可能性を有しています。

regress@ce4> ping 10.220.90.1PING 10.220.90.1 (10.220.90.1): 56 data bytes64 bytes from 10.220.90.1: icmp_seq=0 ttl=63 time=1.002 ms64 bytes from 10.220.90.1: icmp_seq=1 ttl=63 time=0.984 ms64 bytes from 10.220.90.1: icmp_seq=2 ttl=63 time=0.984 ms^C--- 10.220.90.1 ping statistics ---3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.984/0.990/1.002/0.008 msregress@ce4>

oak内のその他のサイトも、dalwhinnieの oakインスタンス内に構成されている irb.100インタフェース経由での 192.168.120.1/24への接続性を有しています。CE1および CE3は、どちらも 192.168.120.1/24に到達できます。

regress@ce3> ping 10.220.90.1

付録 209

PING 10.220.90.1 (10.220.90.1): 56 data bytes64 bytes from 10.220.90.1: icmp_seq=0 ttl=63 time=1.228 ms64 bytes from 10.220.90.1: icmp_seq=1 ttl=63 time=30.964 ms64 bytes from 10.220.90.1: icmp_seq=2 ttl=63 time=1.185 ms64 bytes from 10.220.90.1: icmp_seq=3 ttl=63 time=1.245 ms^C--- 10.220.90.1 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max/stddev = 1.185/8.655/30.964/12.880 ms

regress@ce1> ping 10.220.90.1PING 10.220.90.1 (10.220.90.1): 56 data bytes64 bytes from 10.220.90.1: icmp_seq=0 ttl=63 time=1.207 ms64 bytes from 10.220.90.1: icmp_seq=1 ttl=63 time=1.172 ms64 bytes from 10.220.90.1: icmp_seq=2 ttl=63 time=1.171 ms64 bytes from 10.220.90.1: icmp_seq=3 ttl=63 time=1.178 ms^C--- 10.220.90.1 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max/stddev = 1.171/1.182/1.207/0.015 ms

VPLSインスタンス内の irbインタフェースもさらにいくつかのトラブルシューティング機能を提供しています。irbインタフェースは、コアネットワークの PEルーターによる特定の VPLSドメインへの直接アクセスを提供しているため、そのドメイン内で pingや tracerouteを実行する機能も提供しています。したがって、VPLS pingに加えて、コアネットワークルーターはMACおよび IPの両方のアドレスの到達可能性も確認できます。この例では、dalwhinnieが oak VPN内のレイヤー2とレイヤー 3の両方で、MACアドレス 00:05:85:f4:f0:5eへの接続性を確認しています。

regress@dalwhinnie> show route forwarding-table vpn oak . . . . . . . . .Routing table: oak.vplsVPLS:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 dscd 608 100:05:85:f4:f0:5d/48 user 0 indr 1048574 6 192.168.86.2 Push 262244, Push 100016(top) 573 2 ge-1/0/2.000:05:85:f4:f0:5e/48 user 0 indr 1048574 6 192.168.86.2 Push 262244, Push 100016(top) 573 2 ge-1/0/2.0lsi.1049104 intf 0 indr 1048574 6 192.168.86.2 Push 262244, Push 100016(top) 573 2 ge-1/0/2.000:17:cb:05:44:5d/48 user 0 ucst 630 5 ge-1/0/0.5500x30003/51 user 0 comp 631 2ge-1/0/0.550 intf 0 ucst 630 5 ge-1/0/0.5500x30001/51 user 0 comp 623 20x30002/51 user 0 comp 618 2regress@dalwhinnie> ping vpls instance oak destination-mac 00:05:85:f4:f0:5e source-ip192.168.86.1! -> oban:oak:ge-1/0/6.700! -> oban:oak:ge-1/0/6.700! -> oban:oak:ge-1/0/6.700! -> oban:oak:ge-1/0/6.700! -> oban:oak:ge-1/0/6.700--- vpls ping statistics ---5 packets transmitted, 5 packets received, 0% packet loss

regress@dalwhinnie> ping 192.168.90.10PING 192.168.90.10 (192.168.90.10): 56 data bytes64 bytes from 192.168.90.10: icmp_seq=0 ttl=64 time=0.890 ms


64 bytes from 192.168.90.10: icmp_seq=1 ttl=64 time=0.843 ms64 bytes from 192.168.90.10: icmp_seq=2 ttl=64 time=0.859 ms64 bytes from 192.168.90.10: icmp_seq=3 ttl=64 time=0.815 ms64 bytes from 192.168.90.10: icmp_seq=4 ttl=64 time=0.848 ms^Cregress@dalwhinnie> show arp | match 192.168.90.1000:05:85:f4:f0:5e 192.168.90.10 192.168.90.10 lsi.1049104 none

普段は VPLSインスタンス内に irbインタフェースが構成されていなくても、必要に応じて、この追加のトラブルシューティング機能を使用するためだけに一時的に追加することもできます。ただし、irbインタフェースによりインターネットおよびいくつかのコアの内部アドレスへの追加アクセスが可能になるため、トラブルシューティングセッションの終了時に irbインタフェースを必ず削除してください。

まとめ

MXシリーズルーター上の VPLSにより構成が容易になり、VPLSユーザーに外部ルートへのアクセスを簡単に提供できるようになります。さらに、irbインタフェースをトラブルシューティングのために使用するオプションを備えることにより（レイヤー3の pingおよび tracerouteを含む）、ネットワーク通信事業者は顧客から報告された問題を迅速に診断して解決できる追加機能が得られます。参考までに、PEルーターの dalwhinnieおよび obanの関連部分の構成を以下に示します。

Dalwhinnie

regress@dalwhinnie> show configuration interfacesge-1/0/0 { vlan-tagging; speed 100m; encapsulation vlan-vpls; unit 550 { encapsulation vlan-vpls; vlan-id 550; family vpls; }}ge-1/0/2 { speed 100m; unit 0 { family inet { address 192.168.86.1/30; } family mpls; }}ge-1/0/4 { speed 100m; unit 0 { family inet { address 192.168.86.5/30; } family mpls; }}ge-1/0/6 { speed 100m; unit 0 {

付録 211

family inet { address 192.168.120.1/30; } }}irb { unit 100 { family inet { filter { input vpls-internet-access; } address 192.168.90.100/24; } }}lo0 { unit 0 { family inet { address 127.0.0.1/32; address 10.200.86.1/32; } }}regress@dalwhinnie> show configuration protocolsrsvp { interface ge-1/0/2.0; interface ge-1/0/4.0;}mpls { interface ge-1/0/4.0; interface ge-1/0/2.0;}bgp { family inet { any; } family l2vpn { signaling; } group internal { type internal; local-address 10.200.86.1; export next-hop-self; neighbor 10.200.86.3; neighbor 10.200.86.4; } group external { export [ export-internal oak-vpls-routes ]; peer-as 65432; neighbor 192.168.120.2; }}ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0 { passive; } interface ge-1/0/4.0; interface ge-1/0/2.0; }}ldp {


interface ge-1/0/2.0; interface ge-1/0/4.0;}regress@dalwhinnie> show configuration routing-instancesoak { instance-type vpls; vlan-id none; interface ge-1/0/0.550; routing-interface irb.100; route-distinguisher 10.200.86.1:100; vrf-target target:300:200; protocols { vpls { site-range 5; no-tunnel-services; site ce4 { site-identifier 4; interface ge-1/0/0.550; } } }}regress@dalwhinnie> show configuration policy-optionsprefix-list internal-routes { 192.168.86.0/24;}policy-statement export-internal { from { prefix-list internal-routes; } then accept;}policy-statement next-hop-self { from protocol bgp; then { next-hop self; accept; }}policy-statement oak-vpls-routes { term 10 { from { route-filter 192.168.90.0/24 orlonger; } then accept; }}regress@dalwhinnie> show configuration firewallfamily inet { filter vpls-internet-access { term 10 { from { destination-prefix-list { internal-routes; } } then { count vpls-internal-attempt; discard; } } term 20 { then accept;

付録 213

} }}regress@dalwhinnie> show versionHostname: dalwhinnieModel: mx80-48tJUNOS Base OS boot [10.3R1.9]

Oban

regress@oban> show configuration interfacesge-1/0/0 { speed 100m; encapsulation ethernet-vpls; unit 0 { family vpls; }}ge-1/0/2 { speed 100m; unit 0 { family inet { address 192.168.86.14/30; } family mpls; }}ge-1/0/4 { speed 100m; unit 0 { family inet { address 192.168.86.10/30; } family mpls; }}ge-1/0/6 { vlan-tagging; speed 100m; encapsulation vlan-vpls; unit 700 { encapsulation vlan-vpls; vlan-id 700; family vpls; }}lo0 { unit 0 { family inet { address 127.0.0.1/32; address 10.200.86.3/32; } }}regress@oban> show configuration protocolsrsvp { interface ge-1/0/4.0; interface ge-1/0/2.0;}mpls { interface ge-1/0/4.0; interface ge-1/0/2.0;}


bgp { family inet { any; } family l2vpn { signaling; } group internal { type internal; local-address 10.200.86.3; neighbor 10.200.86.1; }}ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0 { passive; } interface ge-1/0/4.0; interface ge-1/0/2.0; }}ldp { interface ge-1/0/2.0; interface ge-1/0/4.0;}regress@oban> show configuration routing-instancesoak { instance-type vpls; vlan-id none; interface ge-1/0/0.0; interface ge-1/0/6.700; route-distinguisher 10.200.86.3:100; vrf-target target:300:200; protocols { vpls { site-range 5; no-tunnel-services; site ce1 { site-identifier 1; interface ge-1/0/0.0; } site ce3 { site-identifier 3; interface ge-1/0/6.700; } } }}regress@oban# run show versionHostname: obanModel: mx80-48tJUNOS Base OS boot [10.3R1.9]

付録 215

付録 B：Junos Automation

少しの間ネットワーク計画から離れて、Junos Automationがネットワーク標準の実装および実施において果たす役割について分析してみましょう。Junos Automationは、Junosネットワークオペレーティングシステムの内蔵部品です。さまざまな機能を提供しますが、とりわけ、デバイス構成の自動化、構成規格の実施、カスタマイズされたコマンドの作成、ネットワークパラメータの定期的なチェック、および特定のイベントへの自動応答などの独特な機能があります。Junos Automationが提供する機能に関する情報および参考文献については、本書の最後のページを参照してください。

Junos Automationについての簡単な紹介

Junos Automationは、コミット、op、およびイベントの 3種類のスクリプトで構成されます。コミットスクリプトは構成がコミットされるたびに実行されます。コミットスクリプトを使用することにより、構成規格を実施したり（各論理および物理インタフェースに記述があることを確認するなど）、壊滅的な構成エラーを防いだり（OSPFまたは BGP階層全体の削除など）、複雑な構成においてステートメント数を削減することができます。opスクリプトは運用モードで使用されます。opスクリプトを使用して、カスタムコマンド（カスタマイズされた showコマンドなど）の作成やデバイス構成の変更（管理および構造化された方法でユーザーが構成を変更できるようにするなど）が行えます。イベントスクリプトは、syslogメッセージ、SNMPトラップ、またはカスタムの時間周期イベントなどのイベントに応じて、イベントオプションポリシーによってトリガーされます。たとえば、OSPFインタフェースが故障した場合、一貫性のある管理された方法でイベントスクリプトが応答し、特定データの収集、デバイス構成の変更、カスタムログメッセージの追加、またはそれらすべてを行います。要するに、イベントスクリプトは、トラブルシューティングおよび特定のイベントへの応答を自動化できます。イベントスクリプトは opスクリプトと密接な関係があります。多くの場合、opスクリプトをイベントスクリプトとして構成したり、またはその反対の構成を行うことができます。その違いはトリガー方法であり、CLI（opスクリプト）からトリガーされるか、またはイベント（イベントスクリプト）からトリガーされるかの違いです。各タイプのスクリプトの使用方法および機能とそれらの連携機能については、当然ながらこの短い紹介欄では説明しきれないので、Day Oneライブラリおよび本書の最後のページに記載されている資料を参照してください。JunosのネイティブXML機能を自動化のために効果的かつ効率的に利用するための XMLの使用方法について説明した Day One自動化ブックもあります。Junos Automationの素晴らしさをただお伝えするだけではなくお見せしましょう。

自動化例

Junos Automationの例を作成しましょう。OSPFインタフェースのネットワークマスクが /30または /31で、特定の構成タグがある場合、この例をOSPFリンクの遅延用に使用し、そのOSPFメトリックを設定します。計画としては、一連の 15個の RPMプローブを指定された試験期間（60～2592000秒）の間送信します。各試験期間ごとにイベントスクリプトが最後に完了したプローブ結果セットをチェックし、平均プローブ遅延時間を読み取ります。インタフェースプローブの平均遅延時間が許容分散よりも大きい場合、スクリプトに


よりその OSPFインタフェースのメトリックが修正されます。この例は、コミットスクリプトとイベントスクリプトの 2つの別々のスクリプトで構成する必要があります。

コミットスクリプト

一般に、コミットスクリプトはデバイス構成を正常な状態に保ちます。コミットスクリプトはソリューションの初期構成を実行したら（ユーザーはコミットスクリプトおよびイベントスクリプトの構成のみ行う必要がある）、それを破壊するような不測の構成変更が起きないようにします。コミットスクリプトは、各コミットにおいて以下のことを行います。

1. スクリプトで定義された test-intervalが有効な範囲の 60～ 2592000秒であるか判断します。

2. monitor-link-latencyの apply-macroを使ってOSPFで構成された各インタフェースについて、そのインタフェースのネットワークマスクが /30または/31であるかどうかを確かめます。そうであった場合、以下を行います。a. /30または /31 OSPFリンクのリモート側の IPアドレスを判断します。b. リンクのリモート側のターゲットアドレスを使ってRPMプローブを構成します（プローブ名は ospf-metric-probe-<logical-interface>）。

3. OSPFからインタフェースが削除される場合や、monitor-link-latencyのapply-macroが削除された場合、コミットスクリプトはそのインタフェースのソリューション RPMプローブを構成から削除します。

4. 生成イベントを構成します（イベントオプション階層下で）。このイベントは、定義された test-intervalで試験期間につき 1回発生します。

5. 生成イベントでのトリガーとこのソリューションのイベントスクリプトの実行を行うイベントオプションポリシーを構成します。

6. CLIおよびログで、構成の変更をユーザーに知らせます。7. コミットスクリプトの $test-interval変数が変更された場合、コミットスクリプトはその間隔で新しい生成イベントを作成し、そのイベントでトリガーするようにイベントオプションポリシーを変更し、（test-interval）/15秒に最も近い間隔で RPMプローブを送信するために各 OSPFインタフェースの RPMプローブを変更します。

コミットスクリプトにはユーザーが変更可能な変数が 3つあります。最も重要な変数は、$test-interval変数です。この変数の値を変更することにより、ユーザーは試験間隔の長さ（秒単位で測定）を変更できます。各 OSPFインタフェースプローブ用の 15個の RPMプローブが指定された試験間隔で送信されます。この値を変更すると、名前に正規表現の ospf-metric-probe-が含まれる各プローブのprobe-intervalをコミットスクリプトが変更します。また、この値を変更すると、その値で新しいイベントオプションによる生成イベントが作成されるだけでなく、対応する生成イベントでトリガーするためのイベントオプションポリシーmonitor-ospf-interface-probesの変更も行われます。つまり、ユーザーがこの変数を変更した場合、ソリューションにとって必要なすべての変更がスクリプトによって自動的に行われるので、ユーザーはそれ以上の変更を行う必要がありません。ユーザーが変更できる残りの 2つの変数は、$cmt-script-nameと $event-script-nameです。これらは、それぞれこのコミットスクリプトの名前と対応するイベントスクリプトの名前です。$event-script-name変数は、イベントスクリプトを実際に実行するイベントオプションポリシーが正しいイベントスクリプト用に設定されていることを確認するために使用されます。$cmt-script-name変数はこのコミットスクリプトの名前であり、システムのログでこのスクリプトの出力を識別するために使用されます。

付録 217

コミットスクリプトのアクションはログに記録され、コミット時にCLIに表示されます。

イベントスクリプト

このソリューションのイベントスクリプト部分は、コミットスクリプトによって構成されるイベントオプションポリシーによってアクティブ化されます。イベントスクリプトは、以下の作業を行います。

1. 名前に正規表現の ospf-metric-probe-が含まれる RPMプローブのみのRPMプローブデータを読み取り、最後に完了した試験の平均プローブ遅延時間を求めます。

2. 各インタフェースの最新のプローブ遅延時間に基づいて、各インタフェースの提案メトリックを決定します。メトリック = （マイクロ秒単位の平均遅延時間）/1000×10の式を使用し、最も近い整数に丸めます。つまり、10×（ミリ秒単位の平均遅延時間）を最も近い整数に丸めるということです。

3. 各OSPFインタフェースの最新のメトリックを読み取ります。4. 新しいメトリックが指定された既存のメトリックの分散内かどうか判断します。

a. 分散が 40%に設定されている場合、新しいメトリックが既存のメトリックの 40%以内であれば、そのインタフェースのメトリックは変更されません。

b. 新しいメトリックが既存のメトリックの 40%を超える場合のみ、そのインタフェースのメトリックが変更されます。

5. 各OSPFインタフェースのエリアを判断します。6. 新しいメトリックが許容分散外である場合、各インタフェースのメトリックを変更します。

7. イベントスクリプトは、実行されるたびに以下の作業を実行します。a. 何らかの変更を行うかどうかとその変更内容をログ経由でユーザーに知らせます。

イベントスクリプトは、排他的なコミットによって構成変更を行います。したがって、構成データベースがすでに変更されている場合、スクリプトがデータベースをロックしようとすると、スクリプトの構成ロックが失敗し、構成ロックの失敗理由を説明するメッセージがログに記録されます。

b. 監視した各OSPFインタフェースのプローブ結果をログに記録します。c. OSPFメトリックに変更が加えられなかった場合、スクリプトはそのようなメッセージをログに記録します。

そして、イベントスクリプトにはユーザーが変更可能な 3つの変数 $variance、$event-script-name、および $metric-up-on-lossがあります。

1. $varianceは、インタフェースの RPMプローブが許容可能な分散の割り合いを示す 10進値です。この許容範囲を超えるとイベントスクリプトがインタフェースの OSPFメトリックを変更します。このスクリプトは、往復遅延時間の 1ミリ秒につき 10のメトリックを提供するように設定されています。たとえば、$variance = 0.4（40%）の場合、インタフェースのメトリックが 500で、最新のプローブ結果が平均 65,000マイクロ秒（us）になると、スクリプトによってOSPFメトリックが変更されません（65,000マイクロ秒 = 65ミリ秒 = 650メトリック ; 分散 30%）。新しい結果セットが平均 75,000マイクロ秒（50%の差）になると、スクリプトによってOSPFメトリックが 750に変更されます。

2. $script-nameは、このイベントスクリプトの名前であり、システムログでこのスクリプトのメッセージを識別するために使用されます。


3. $metric-up-on-lossの値を 1に設定すると、OSPFインタフェースの RPMプローブが最新の期間で失われた場合、適切な OSPFインタフェースのメトリックを 50,000まで増加します。$metric-up-on-lossを 1以外の値に設定すると、そのインタフェースの利用可能な RPMプローブデータからインタフェースメトリックが決定されます。

注イベントスクリプトのアクションはすべてログに記録されます。

Junos Automationはいくつかの強力な利点をもたらしますが、自動化ソリューションを導入する前に、その機能について理解し、使用しているネットワーク環境に適するかどうかを把握することが重要です。誤りを自動化することだけは避けなければなりません。そうは言っても、このスクリプティングソリューションが役に立つ可能性がある場合は、機能に慣れるためにもこのソリューションをラボでテストすることを強くお奨めします。そうすれば、実稼働ネットワークにもたらされる効果を理解して予測することができます。トラフィックの最適化と変動（不要なコミットおよびメトリック変更）の最小化の間の適正なバランスを取りながら、分散と試験間隔の設定について注意深く検討する必要があります。これらの設定には、使用している固有のネットワークを考慮に入れる必要があります。たとえば、分散の設定値が低すぎると、トラフィックのパスを必ずしも変更しないコミットおよび OSPFメトリックの変更が増加する可能性があります。インタフェースのメトリックを500から600に変更すると、トラフィックパターンに必ず影響が及ぶかどうかを自問してみてください。

自動化ソリューションの適用

最初の手順は、Junosデバイスへのスクリプトの導入です。コミットスクリプトは /var/db/scripts/commit/ディレクトリに配置します。イベントスクリプトは /var/db/scripts/event/ディレクトリに配置します。以下に示す例は、ルーターに初めて自動化を適用する例です。まずは、すでに存在するものについて確認しましょう。

ps@lagavulin> show configuration protocols ospftraffic-engineering { shortcuts;}area 0.0.0.0 { interface ge-0/0/2.0 { interface-type p2p; }interface ge-0/0/3.0 { interface-type p2p; } interface lo0.0;}

ps@lagavulin> show interfaces terse | match ge-0/0 | match inetge-0/0/0.0 up up inet 172.19.112.200/27ge-0/0/1.201 up up inet 192.168.66.1/30ge-0/0/1.400 up up inet 192.168.90.17/30ge-0/0/2.0 up up inet 192.168.86.2/30ge-0/0/3.0 up up inet 192.168.86.29/30

ps@lagavulin> show configuration services rpm

ps@lagavulin> show configuration event-options

ps@lagavulin>

付録 219

この出力から、RPMプローブまたはイベントオプション構成が存在していないことが分かります。マスクが /30の構成済みのOSPFインタフェースが2つありますが、これらには必要な apply-macroがありません。それでは、ソリューションを構成しましょう。ps@lagavulin> editEntering configuration mode

[edit]ps@lagavulin# set system scripts commit file create-ospf-probes-and-evtoptns-cmt-script.slax

[edit]ps@lagavulin# set event-options event-script file read-ospf-probes-evtscript.slax

[edit]ps@lagavulin# edit protocols ospf

[edit protocols ospf]ps@lagavulin# showtraffic-engineering { shortcuts;}area 0.0.0.0 { interface ge-0/0/2.0 { interface-type p2p; } interface ge-0/0/3.0 { interface-type p2p; } interface lo0.0;}

[edit protocols ospf]ps@lagavulin# set area 0 interface ge-0/0/2.0 apply-macro monitor-linklatency

[edit protocols ospf]ps@lagavulin# set area 0 interface ge-0/0/3.0 apply-macro monitor-linklatency

[edit protocols ospf]ps@lagavulin# showtraffic-engineering { shortcuts;}area 0.0.0.0 { interface ge-0/0/2.0 { apply-macro monitor-link-latency; interface-type p2p; } interface ge-0/0/3.0 { apply-macro monitor-link-latency; interface-type p2p; } interface lo0.0;}

[edit protocols ospf]ps@lagavulin# commitwarning: commit script create-ospf-probes-and-evt-optns-cmt-script.slax


adding event-options generated-event 600-seconds to configuration to trigger OSPF RPM probe monitoringwarning: commit script create-ospf-probes-and-evt-optns-cmt-script.slaxadding event-options policy 'monitor-ospf-interface-probes' to configuration to trigger OSPF RPM probe monitoring event-script.warning: commit script create-ospf-probes-and-evt-optns-cmt-script.slaxadding rpm probe ospf-metric-probe-ge-0/0/2.0 in response to interfacege-0/0/2.0 being in ospf, having a /30 or /31 netmask, and having an applymacro of 'monitor-link-latency'warning: commit script create-ospf-probes-and-evt-optns-cmt-script.slaxadding rpm probe ospf-metric-probe-ge-0/0/3.0 in response to interfacege-0/0/3.0 being in ospf, having a /30 or /31 netmask, and having an applymacro of 'monitor-link-latency'commit complete

[edit protocols ospf]ps@lagavulin# top show services rpmprobe ospf-metric-probe-ge-0/0/2.0 { test 192.168.86.1 { probe-type icmp-ping; target address 192.168.86.1; probe-count 15; probe-interval 40; test-interval 10; }}probe ospf-metric-probe-ge-0/0/3.0 { test 192.168.86.30 { probe-type icmp-ping; target address 192.168.86.30; probe-count 15; probe-interval 40; test-interval 10; }}

[edit protocols ospf]ps@lagavulin# top show event-optionsgenerate-event { 600-seconds time-interval 600;}policy monitor-ospf-interface-probes { events 600-seconds; then { event-script read-ospf-probes-evt-script.slax; }}event-script { file read-ospf-probes-evt-script.slax;}

イベントスクリプトとコミットスクリプトが構成され、目的の OSPFインタフェースが必要な apply-macroでタグ付けされたら（この場合は、両方のインタフェースが監視用にタグ付けされる）、コミット時にコミットスクリプトによって必要な RPMプローブ、イベントオプションポリシー、および生成イベントが構成されます。コミットスクリプトは、CLIメッセージおよびログ内の同等のメッセージにより、構成変更をユーザーに知らせます。これで完成です。使用できます。

付録 221

注 apply-macro構成は非表示の構成なので打ち込む必要があります（タブ補完できません）。

注最初にインタフェースが監視に追加されている場合、そのインタフェースのプローブ結果を含む最初の 2～ 3個のログメッセージに、NaNプローブの損失による潜在的なパケット損失が示される場合があります。新たに追加されたインタフェースには平均遅延時間の判定の元になるフルセットの RPMデータがない場合があるため、このような動作が起きてもおかしくありません。以下に例を示します。

Feb 10 04:59:32 dalwhinnie cscript: message from event-script read-ospfprobes-evt-script.slax - OSPF RPM PROBE ospf-metric-probe-ge-0/0/3.0 lostNaN probe(s) during its most recent run. Verify that no packet loss isoccurring on ge-0/0/3.0

それでは、OSPFリンク遅延監視に追加されるインタフェースの例を示します。この例の自動化ソリューションがすでに ge-0/0/2.0のルーター上で動作しています。ge-0/0/3.0インタフェースはすでにOSPFで構成済みですが、監視されていないことがわかります。[edit protocols ospf]ps@dalwhinnie# top show services rpmprobe ospf-metric-probe-ge-0/0/2.0 { test 192.168.86.5 { probe-type icmp-ping; target address 192.168.86.5; probe-count 15; probe-interval 40; test-interval 10; }}

[edit protocols ospf]ps@dalwhinnie# showtraffic-engineering { shortcuts;}area 0.0.0.0 { interface ge-0/0/2.0 { apply-macro monitor-link-latency; interface-type p2p; metric 21; } interface ge-0/0/3.0 { metric 19; } interface lo0.0;}

[edit protocols ospf]ps@dalwhinnie# set area 0 interface ge-0/0/3.0 apply-macro monitor-linklatency

[edit protocols ospf]ps@dalwhinnie# commitwarning: commit script create-ospf-probes-and-evt-optns-cmt-script.slaxadding rpm probe ospf-metric-probe-ge-0/0/3.0 in response to interfacege-0/0/3.0 being in ospf, having a /30 or /31 netmask, and having an applymacroof 'monitor-link-latency'commit complete


[edit protocols ospf]ps@dalwhinnie# showtraffic-engineering { shortcuts;}area 0.0.0.0 { interface ge-0/0/2.0 { apply-macro monitor-link-latency; interface-type p2p; metric 21; } interface ge-0/0/3.0 { apply-macro monitor-link-latency; metric 19; } interface lo0.0;}

[edit protocols ospf]ps@dalwhinnie# top show services rpmprobe ospf-metric-probe-ge-0/0/2.0 { test 192.168.86.5 { probe-type icmp-ping; target address 192.168.86.5; probe-count 15; probe-interval 40; test-interval 10; }}probe ospf-metric-probe-ge-0/0/3.0 { test 192.168.86.29 { probe-type icmp-ping; target address 192.168.86.29; probe-count 15; probe-interval 40; test-interval 10; }}

この出力例では、ge-0/0/3.0はネットワークマスクが /30であり（非表示）、OSPFで構成されていますが、このソリューションでは監視されていません。適切な apply-macro構成を追加することにより、コミットスクリプトがこのリンク用のRPMプローブを追加します。これで、この自動化ソリューションによる監視が行われ、必要に応じてメトリックの変更が行われるようになります。コミットスクリプトは、CLIメッセージ（表示）および同等のログメッセージ（非表示）により、構成変更をユーザーに知らせます。イベントスクリプトは、最新のプローブ結果のフルセットを希望の試験間隔ごとに 1回チェックし、各インタフェースのプローブ結果と構成変更、または変更の欠落をログに記録します。この自動化例では、以下のように記録されます。

Feb 10 05:48:01 lagavulin cscript: $avg-delay for interface ge-0/0/2.0 = 2173 usec; this msggeneraged by read-ospf-probes-evt-script.slaxFeb 10 05:48:01 lagavulin cscript: event-script read-ospf-probes-evt-script.slax changing ospfinterface ge-0/0/2.0 metric from to 22 based on rpm probe data.Feb 10 05:48:01 lagavulin cscript: $avg-delay for interface ge-0/0/3.0 = 2297 usec; this msggeneraged by read-ospf-probes-evt-script.slaxFeb 10 05:48:01 lagavulin cscript: event-script read-ospf-probes-evt-script.slax changing ospfinterface ge-0/0/3.0 metric from to 23 based on rpm probe data.Feb 10 05:48:10 lagavulin cscript: configuration change to modify ospf metric values successful.this msg generated by read-ospf-probes-evt-script.slax

付録 223

Feb 10 05:58:01 lagavulin cscript: $avg-delay for interface ge-0/0/2.0 = 2300 usec; this msggeneraged by read-ospf-probes-evt-script.slaxFeb 10 05:58:01 lagavulin cscript: $avg-delay for interface ge-0/0/3.0 = 1938 usec; this msggeneraged by read-ospf-probes-evt-script.slaxFeb 10 05:58:01 lagavulin cscript: this message generated by read-ospf-probes-evt-script.slax:ospf probe results show no change in link latency outside the allowed variance of 40%.

ここでは、05:48:01に終わる試験間隔の間に、イベントスクリプトが各インタフェースの RPMプローブ結果をログに記録し、監視された各インタフェースのメトリックをデフォルト値からそのインタフェースの RPMプローブ遅延が反映された値に変更しました。05:58:01に終わる試験間隔の最後には、イベントスクリプトがプローブ結果をログに記録し、現在のインタフェースメトリックに要求される 40%の分散範囲を超えるプローブ結果がなかったことを報告しました。さらに参考のために、インタフェース ge-0/0/3.0のメトリック変更のイベントスクリプトによるログの一部を以下に示します。

Feb 10 06:28:01 lagavulin cscript: $avg-delay for interface ge-0/0/2.0 = 2642 usec; this msggeneraged by read-ospf-probes-evt-script.slaxFeb 10 06:28:01 lagavulin cscript: $avg-delay for interface ge-0/0/3.0 = 3357 usec; this msggeneraged by read-ospf-probes-evt-script.slaxFeb 10 06:28:01 lagavulin cscript: event-script read-ospf-probes-evt-script.slax changing ospfinterface ge-0/0/3.0 metric from 23 to 34 based on rpm probe data.Feb 10 06:28:10 lagavulin cscript: configuration change to modify ospf metric values successful.this msg generated by read-ospf-probes-evt-script.slax

自動化例の用途

ここで示した自動化例の用途はいくつか考えられますが、その中から 3つを以下に示します。

1. SPからのレイヤー 1およびレイヤー 2サービス。あなたの会社がサービスプロバイダ（SP）から提供されるレイヤー 1伝送またはレイヤー 2サービス（VPLSまたはポイントツーポイントの伝送など）を使用している場合、トラフィックが SPのネットワークに到達した後は、トラフィックが通る実際のパスを制御することはできません。SPネットワーク上での光ファイバーの事故、メンテナンス、またはその他の理由による機能停止は、トラフィックが通過するパスに影響を与える可能性があり、それにより遅延時間が大きく変わります。ここで示した自動化例は、物理的パスを制御できない OSPFインタフェース上で使用するか、もしくはリンク遅延の変動幅が広くなりそうな状況で使用することができます。必要なインタフェースのネットマスクが /30または /31であることを確認し、そのインタフェースに apply-macro値のmonitor-link-latencyをタグ付けして、イベントおよびコミットスクリプトを構成するだけで、自動化ソリューションが完成し、それらのインタフェース上で稼働します。

2. 監視のみ。ネットワーク遅延が定常状態で、遅延が根本的に変化しない場合（ポイントツーポイントリンクを直接制御できる）、この自動化例を使用してすべての OSPFインタフェースの適切な遅延時間に基づくOSPFメトリックを設定し、遅延およびパケット損失結果をログに記録することができます。イベントスクリプトの分散を非常に高く（10 = 1000%）設定し、コミットスクリプトの試験間隔を非常に短く（60秒）設定します。この実装により遅延時間に応じてリンクメトリックが設定され、リンク遅延および潜在的なパケット損失が 60秒ごとにログに記録されます。分散の値を高くすることでリンクメトリックが変化しなくなり、トラフィックパターンを一定に保てます。潜在的なパケット損失および実際のリンク遅延の監視のみが重要である場合、この実装が役立ちます。


3. 基礎的要素。この自動化例は、やや複雑なスクリプティングソリューションを示しています。もっと経験を積んだ Junos Automationユーザーや学習中のユーザーであれば、ラボ内でこのスクリプトを開始点として使用して、実稼働用に修正を加えたり、ただ単に使い方を学ぶためだけに使用することができます。

スクリプト

ここに示した自動化例に含まれるコミットスクリプトおよびイベントスクリプトの全体を以下に再掲載します。最初にコミットスクリプト、その後にイベントスクリプトを掲載します。

ヒント www.juniper.net/dayoneから本書のダウンロードページへのパスをたどると、本書の無料のコピーアンドペースト版が見つかります。これはリッチテキスト形式なので、さまざまなテキストエディタでファイルを開き、本書の構成を簡単にコピーアンドペーストできます。

create-ospf-probes-and-evt-optns-cmt-script.slax

version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";

import "../import/junos.xsl";

/* YOU MUST ACCEPT THE TERMS OF THIS DISCLAIMER TO USE THIS SOFTWARE.** JUNIPER IS WILLING TO MAKE THE INCLUDED SCRIPTING SOFTWARE AVAILABLE TO YOU ONLY UPON THECONDITION THAT YOU * ACCEPT ALL OF THE TERMS CONTAINED IN THIS DISCLAIMER. PLEASE READ THE TERMSAND CONDITIONS OF THIS DISCLAIMER * CAREFULLY.

* THE SOFTWARE CONTAINED IN THIS FILE IS PROVIDED "AS IS." JUNIPER MAKES NO WARRANTIES OF ANY KIND WHATSOEVER* WITH RESPECT TO SOFTWARE. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY* WARRANTY OF NON-INFRINGEMENT OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, ARE HEREBY* DISCLAIMED AND EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW.** IN NO EVENT WILL JUNIPER BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT,* CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY ARISING* OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF JUNIPER HAS BEEN ADVISED OF THE POSSIBILITY OF* SUCH DAMAGES. */

/* an explanation of this script’s functionality lies at the bottom of this file */

/* created by Tim Fiola, Juniper Networks Professional Services */

/****************************************************************//* these first 3 variables are all that need to be modified if *//* the user wishes to modify the script parameters; *//* any other mods require a good working knowledge of junos */

付録 225

/* automation *//****************************************************************/

/* cmt-script-name is the name of this commit script *//* this is used in the log messages to ID the *//* specific script that is creating the message */var $cmt-script-name = "create-ospf-probes-and-evt-optns-cmt-script.slax";

/* event-script-name is the name of the paired event-script that *//* gets triggered every test-interval and reads the rpm probe data *//* this needs to be accurate to ensure that the event-options *//* policy gets created properly */var $event-script-name = "read-ospf-probes-evt-script.slax";

/* interval is how long each monitoring period is; 15 probes *//* are sent every monitoring period; enter time in seconds *//* this value must be be in range 60..2592000 seconds inclusive */var $test-interval = 60;

/* MODIFYING ANYTHING OTHER THAN THE THREE VARIABLES ABOVE REQUIRES A *//* GOOD WORKING KNOWLEDGE OF JUNOS AUTOMATION AND IS NOT RECOMMENDED */

match configuration {

/* task 0 - determine if $test-interval is valid */ if ($test-interval < 60 or $test-interval > 2592000) { var $test-interval-message = "the commit script " _ $cmt-script-name _ " test interval must be be in range 60..2592000 seconds inclusive; the configured test-interval is " _ $test-interval; <xnm:error> { <xsl:message terminate="yes"> $test-interval-message; } }

/* task 1 - determine OSPF interfaces */ var $ospf-interfaces := { call ospf-interfaces($configuration = .); }

/* debug output */ <xnm:warning> { <message> { /* expr "ospf-interfaces is "; */ copy-of $ospf-interfaces; } }

/* task 2 - determine the destination IP for each interface */ var $dest-ip := { call dest-ip($ospf-interfaces, $configuration = .); }

/* debug output */ <xnm:warning> { <message> { /* expr "dest-ip is "; */ copy-of $dest-ip; } }

/* task 3 - configure the probe for each interface and the */ /* event-options generated-event and policy */


var $num-probes = count($dest-ip/dest-ip);

/* <xnm:warning> { * <message> { * expr "num-probes = " _ $num-probes; * } *} */ call create-probes-events($num-probes, $dest-ip, $configuration = ., $ospf-interfaces);}

/********************************************************************************//* this template determines which interfaces are configured in OSPF and builds *//* an element containing all of the interface names configured in OSPF *//********************************************************************************/template ospf-interfaces($configuration) { for-each ($configuration/protocols/ospf/area/interface[apply-macro/name == "monitorlink-latency"]) { var $physical-int = substring-before(name, "\."); var $logical-int = substring-after(name, "\.");

/* if the int is configured in OSPF with the apply-macro */ /* and has a /30 or /31 mask, add the interface to the element*/ if ($configuration/interfaces/interface[name == $physical-int]/unit[name == $logical int]/family/inet/address[contains(name, "\/30") or contains(name, "\/31")]) { copy-of name; } }}

/********************************************************************************************//* this template determines the destination ip address for the needed RPM probes and places *//* those values within an element that stores each value as text in a <dest-ip> node *//********************************************************************************************/template dest-ip($ospf-interfaces, $configuration) { for-each ($ospf-interfaces/name) { var $physical-int = substring-before(., "\."); var $logical-int = substring-after(., "\."); for-each ($configuration/interfaces/interface[name == $physical-int]/unit[name ==$logical-int]/family/inet/address[contains(name, "\/30") or contains(name, "\/31")]/name) { var $parsed-address := jcs:parse-ip(.); var $host-ip = $parsed-address[1]; /* takes the first element of the parse IP, whichis the address */

/* separate the address into its component octets */ var $first-octet = substring-before($host-ip, "\."); var $second-octet = substring-before(substring-after($host-ip, "\."), "\."); var $third-octet = substring-before(substring-after(substring-after($host-ip, "\."),"\."), "\."); var $last-octet = substring-after(substring-after(substring-after($host-ip, "\."),"\."), "\.");

/* determine the destination IP address, derived from the host address */ var $last-octet-dest-ip = { if($parsed-address[3] = 30) { if(($last-octet)mod(4) == 1) { expr $last-octet + 1; } else if (($last-octet)mod(4) == 2) { expr $last-octet - 1; } else { expr "9999"; /* dummy value showing that address is ineligible */ } } else if ($parsed-address[3] = 31){ if(($last-octet)mod(2) == 0) {

付録 227

expr $last-octet + 1; } else if (($last-octet)mod(2) == 1) { expr $last-octet - 1; } else { expr "9999"; /* dummy value showing that address is ineligible */ } } } /* create the full destination IP address using the last octet of */ /* the destination address and add it to the dest-ip-element element*/ var $dest-ip = $first-octet _ "." _ $second-octet _ "." _ $third-octet _ "." _ $last-octet-dest-ip; var $dest-ip-element := { <dest-ip> $dest-ip; } copy-of $dest-ip-element; } }}

/****************************************************************************************//* this template creates the change elements that configure the necessary event-options *//* policy and generated events if they are not already present; it also creates the RPM *//* probes for the ospf interfaces if they are not present. it will delete any *//* configured rpm probes for ospf interfaces that have since been removed from ospf *//****************************************************************************************/template create-probes-events($num-probes, $dest-ip, $configuration, $ospf-interfaces) {

/* event-name is the name of the generated event that will trigger the event-script */ var $event-name = $test-interval _ "-seconds";

/* this is the actual change element */ var $change := {

/* this part looks for the necessary generated event */ if(not($configuration/event-options/generate-event[time-interval == $test-interval &&name == $event-name])) { <event-options> { <generate-event> { <name> $event-name; <time-interval> $test-interval; } } }

/* this part looks for the necessary event-option policy, triggered by */ /* the generated event; this policy executes the event-script that */ /* reads the rpm probe data */ <event-options> { if (event-options/policy[name == "monitor-ospf-interface-probes"]) { <policy delete="delete"> { /* delete the policy before adding it back with anymodified info */ <name> "monitor-ospf-interface-probes"; } } <policy> { <name> "monitor-ospf-interface-probes"; <events> $event-name; <then> { <event-script> { <name> $event-script-name; } }


} }

/* this section adds necessary probes to the config change element if they don’t exist */ /* or if the needed rpm probes have been manually modified in a way that would break */ /* the solution, this section corrects those manual config errors */ for-each($ospf-interfaces/name) { var $probe-name = "ospf-metric-probe-" _ .; /* determine the numbered position of current 'name' element within $ospf-interfaces node */ /* this is the position of the current ospf int name within the $ospf-interfaces array */ var $position = position();

/* the test-name will be the probe’s destination IP address */ var $test-name = $dest-ip/dest-ip[$position];

/* probe-interval is the test-interval/15 probes (15 probes sent/test-interval) */ var $probe-interval = round(($test-interval)div(15));

/* if there is not a probe configured for the ospf int */ if(not($configuration/services/rpm/probe[name == $probe-name])) {

<services> { <rpm> { <probe> { <name> $probe-name; <test> { <name> $test-name; <probe-type> "icmp-ping"; <target> { <address> $test-name; } <probe-count> 15; <probe-interval> $probe-interval; <test-interval> 10; } } } } } /* if there is a probe configured for the ospf int but is has incorrect configs */ if (($configuration/services/rpm/probe[name == $probe-name]/test[name != $test-name or target/address != $test-name or probe-interval != $probe-interval]) or ($configuration/services/rpm/probe[name == $probe-name]/test[not(name) or not(probe-type) or not(probe-count) ornot(probe-interval) or not(test-interval)])) { <services> { <rpm> { <probe delete="delete"> { <name> $probe-name; } <probe> { <name> $probe-name; <test> { <name> $test-name; <probe-type> "icmp-ping"; <target> { <address> $test-name; } <probe-count> 15; <probe-interval> $probe-interval;

付録 229

<test-interval> 10; } } } } } }

/* this section deletes probes for interfaces that are not in OSPF anymore */ for-each($configuration/services/rpm/probe[contains(name, "ospf-metric-probe-")]) { var $int = substring-after(name, "ospf-metric-probe-"); if(not(contains($ospf-interfaces, $int))) { var $probe-name = name; <services> { <rpm> { <probe delete="delete"> { <name> $probe-name; } } } } } }

/* these next 4 loops use the same for-each & if/then logic as above to send status */ /* output to CLI and to the logs; these could not be part of the above statements */ /* or they’d have created undesirable nodes in the change element */

/* 1 - if generated event has been added by this script */ if(not($configuration/event-options/generate-event[time-interval == $test-interval &&name == $event-name])) { var $status-msg-event = "commit script " _ $cmt-script-name _ " adding event-optionsgenerated-event " _ $event-name _ " to configuration to trigger OSPF RPM probe monitoring"; call log-status-msg($status-msg = $status-msg-event); <xnm:warning> { <message> { expr $status-msg-event; } }

}

/* 2 - if event-options policy has been added by this script */ if(not($configuration/event-options/policy[(events == $event-name) && (name == "monitorospf-interface-probes")]/then/event-script[name == $event-script-name])) { var $status-msg-policy = "commit script " _ $cmt-script-name _ " adding event-optionspolicy 'monitor-ospf-interface-probes' to configuration to trigger OSPF RPM probe monitoring eventscript."; call log-status-msg($status-msg = $status-msg-policy); <xnm:warning> { <message> { expr $status-msg-policy; } } }

/* 3 - if RPM probe(s) have been added by this script or if the needed rpm probes */ /* have been manually modified in a way that would break the solution, this */ /* section corrects those manual config errors */ for-each($ospf-interfaces/name) {

var $probe-name = "ospf-metric-probe-" _ .; /* determine the numbered position of current 'name' element within $ospf-interfaces node


*/ /* this is the position of the current ospf int name within the $ospf-interfaces array */ var $position = position();

/* the test-name will be the probe’s destination IP address */ var $test-name = $dest-ip/dest-ip[$position];

/* probe-interval is the test-interval/15 probes (15 probes sent/test-interval) */ var $probe-interval = ($test-interval)div(15);

if(not($configuration/services/rpm/probe[name == $probe-name])) { var $status-msg = "commit script " _ $cmt-script-name _ " adding rpm probe " _ $probename_ " in response to interface " _ . _ " being in ospf, having a /30 or /31 netmask, and having an apply-macro of 'monitor-link-latency’"; call log-status-msg($status-msg); <xnm:warning> { <message> { expr $status-msg; } } }

if (($configuration/services/rpm/probe[name == $probe-name]/test[name != $test-name ortarget/address != $test-name or probe-interval != $probe-interval]) or ($configuration/services/rpm/probe[name == $probe-name]/test[not(name) or not(probe-type) or not(probe-count) or not(probeinterval)or not(test-interval)])) { var $status-msg = "commit script " _ $cmt-script-name _ " modifying rpm probe " _$probe-name _ " in order to maintain required probe configuration"; call log-status-msg($status-msg); <xnm:warning> { <message> { expr $status-msg; } } } }

/* 4 - if this script is deleting RPM probes for interfaces that are not in OSPF anymore */ for-each($configuration/services/rpm/probe[contains(name, "ospf-metric-probe-")]) { var $int = substring-after(name, "ospf-metric-probe-"); if(not(contains($ospf-interfaces, $int))) { var $probe-name = name; var $status-msg = "commit script " _ $cmt-script-name _ " removing rpm probe " _ $probe-name _ " in response to interface " _ $int _ " being removed from ospf, not being designated as a monitored ospf interface, or having a network mask that is not /30 or /31"; call log-status-msg($status-msg); <xnm:warning> { <message> { expr $status-msg; } } } }

/* debug output */ <xnm:warning> { <message> { copy-of $change; } }

/* make the configuration change */

付録 231

call jcs:emit-change($dot = ., $content = $change);

}

/************************************************//* this template puts $status-msg in the log *//************************************************/template log-status-msg($status-msg) { expr jcs:syslog(5, $status-msg);}

/* This automation solution sends a series of 15 RPM probes out over a defined testing period,ranging from 60* to 2592000 seconds, inclusive. One time per testing period, the event-script checks the results of the latest* completed set of probe results and reads the average probe latency. If an interface probe’s average latency is* greater than the allowed variance, then the script modifies that OSPF interface’s metric. This solution* consists of two separate scripts – a commit script and an event script.** In general, the commit script keeps the device configuration in line. The commit script performs initial* configuration of this solution (the user only need configure the commit and event scripts) and then ensures* that there is not an accidental configuration change that breaks it. The commit script does the following upon* each commit:* 1) Determines if the test-interval defined in the script lies within the valid range60..2592000 seconds* inclusive* 2) For each interface configured in OSPF with an apply-macro set to value 'monitor-linklatency’, the* commit script checks to see if that interface has a /30 or /31 network mask. This solution only runs* on ospf interfaces with the apply-macro value 'monitor-link-latency'* 3) Determines the IP address for the remote side of the /30 or /31 OSPF link* 4) Configures an RPM probe with a target address of the link’s remote side (probe name is* ospf-metric-probe-<logical-interface>)* 5) If an interface is removed from OSPF, the commit script deletes that interface’s solution RPM probes* from the configuration* 6) Configures a generated event (under the event-options hierarchy) that occurs at the defined test* interval once per testing period* 7) Configures an event-options policy that triggers upon the generated event and runs this solution’s event* script* 8) Notifies the user at the CLI and in the logs of any changes it makes to the configuration* 9) If the commit script’s $test-interval variable has been modified, the commit scriptcreates a new* generated event with that interval, modifies the event-options policy to trigger upon that event, and modifies* the RPM probes for each OSPF interface to send an RPM probe at an interval close to (testinterval)/15 seconds** The commit script has three variables that can be modified by the user. The most important one is the* $test-interval variable. Modifying this value allows the user to change the length of the test


interval. This* value is the length of the test interval, in seconds. Since 15 RPM probes for each OSPF interface probe are* sent in a given test interval, modifying this value causes the commit script to modify the probeinterval for* each probe whose name contains the regex 'ospf-metric-probe-’. Changing this value also causes a new* event-options generated event with the same value and a modification of the event-options policy* 'monitor-ospf-interface-probes' to trigger on the corresponding generated event. In other words, if the user* changes this variable, the script will automatically make all the necessary changes to thesolution – the user* need not make any further changes.* The other two variables, $cmt-script-name and $event-script-name are the names of this commitscript and the* name of the corresponding event script, respectively. The $event-script-name variable is used to ensure that* the event-options policy that runs the event script actually is configured for the correct event script. The* $cmt-script-name variable is the name of this commit script and is used to identify this script’s output in* the system’s logs.** any actions taken by the commit script are logged and also noted at the CLI upon commit* -----------------------------------------------------------------------------------------------**The event-script portion of this solution is activated by an event-options policy configured bythe commit* script. The event script performs the following tasks –* 1) Reads the RPM probe data only for the RPM probes whose names contain the regex ospfmetric-probe- and* finds the average probe latency for the most recently completed test* 2) Determines a proposed metric for each interface based on its most recent probe latency(metric =* (average delay in microsec)/1000 * 10, rounded to nearest integer. In other words, 10*(averagedelay in msec)* rounded to nearest integer)* 3) Reads the current metric for each OSPF interface* 4) Determines if the new metric is within a specified variance of the existing metric.* a. If variance is set to 40% (0.40), if the new metric is within 40% of the existing metric,the* interface’s metric is not changed* b. Only if the new metric is more than 40% of the existing metric will that specificinterface’s metric be* changed* 5) Determines the area for each OSPF interface* 6) Changes the metric for each interface if the new metric is outside the allowed variance* 7) Each time the event script runs, it notifies the user via logs if it is making any changes and what* those changes are. If no changes are made, the script logs a message to that effect*** The event script has three variables that can be modified by the user, $variance,$event-scriptname, and* $metric-up-on-loss.* a) $variance is a decimal value for the percentage of variance that an interface’s RPMprobes can tolerate* before the event script will modify its OSPF metric. The script is set to provide a metric of 10 for each ms* of round trip latency. For example, when $variance = 0.4 (40%), if an interface’s metric is 500 and the most

付録 233

* recent probe results show an average of 65,000 microseconds (us), the script will not modify the OSPF metric* (65,000us = 65 ms = 650 metric; 30% variance). If a new set of results comes in showing a 75,000 usaverage* (50% difference), then the script modifies the OSPF metric to 750.* b) $script-name is the name of this event-script and is used to identify this script’smessages in the* system logs.* c) $metric-up-on-loss, when set to a value of 1, will metric up the appropriate OSPFinterface to 50,000* if any of its RPM probes are lost on the most recent time-interval. If $metric-up-on-loss is set to any* value other than 1, then the interface metric is determined from the available RPM probe data for that* interface.** any actions taken by the event-script are logged /*

read-ospf-probes-evt-script.slax

version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";ns ext = "http://xmlsoft.org/XSLT/namespace";

ns math = "http://exslt.org/math";

import "../import/junos.xsl";

/* YOU MUST ACCEPT THE TERMS OF THIS DISCLAIMER TO USE THIS SOFTWARE.** JUNIPER IS WILLING TO MAKE THE INCLUDED SCRIPTING SOFTWARE AVAILABLE TO YOU ONLY UPON THE CONDITION THAT YOU * ACCEPT ALL OF THE TERMS CONTAINED IN THIS DISCLAIMER. PLEASE READ THE TERMS AND CONDITIONS OF THIS DISCLAIMER * CAREFULLY.

* THE SOFTWARE CONTAINED IN THIS FILE IS PROVIDED "AS IS." JUNIPER MAKES NO WARRANTIES OF ANY KIND WHATSOEVER* WITH RESPECT TO SOFTWARE. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,INCLUDING ANY* WARRANTY OF NON-INFRINGEMENT OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, ARE HEREBY* DISCLAIMED AND EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW.** IN NO EVENT WILL JUNIPER BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT,* CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF THE THEORY OFLIABILITY ARISING* OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF JUNIPER HAS BEEN ADVISED OF THEPOSSIBILITY OF* SUCH DAMAGES. */

/* an explanation of this script’s functionality lies at the bottom of this file */

/* created by Tim Fiola, Juniper Networks Professional Services */

/****************************************************************//* these first 3 variables are all that need to be modified if */


/* the user wishes to modify the script parameters; *//* any other mods require a good working knowledge of junos *//* automation *//****************************************************************/

/* $event-script-name is the script name that appears in the logs with this script’s *//* messages this name will appear in log messages created by this script so that the *//* user can determine which script is generating a specific log message */var $event-script-name = "read-ospf-probes-evt-script.slax";

/* the variance describes the % threshold that will trigger a modification of the *//* ospf interface metric; if the new metric differs from the current metric by more *//* than this percentage, the ospf interface will get configured with the new metric */var $variance = 0.40; /* if the metric difference is greater than this %, modify the metric */

/* if this is = 1, then if there is a probe loss on the interface the metric will be *//* changed to 50000. if it is anything other than 1, then the script will use the probe *//* data to determine the metric. if there is no probe loss, this value is not used */var $metric-up-on-loss = 1;

/* MODIFYING ANYTHING OTHER THAN THE THREE VARIABLES ABOVE REQUIRES A *//* GOOD WORKING KNOWLEDGE OF JUNOS AUTOMATION AND IS NOT RECOMMENDED */

/* opens a connection with mgd for jcs:execute() fn */var $connection = jcs:open();

/* this sequence grabs the running configuration */var $rpc-configuration = <get-configuration>;var $configuration = jcs:execute($connection, $rpc-configuration);

match / { <op-script-output> {

if(not($connection)) { var $log-msg-connection = $event-script-name _ " event-script unable to openconnection to mgd"; expr jcs:syslog(5, $log-msg-connection ); }

/* this sequence grabs the most recent rpm probe results data */ var $rpc-get-probe-results = {<command> "show services rpm probe-results";} var $probe-results = jcs:execute($connection, $rpc-get-probe-results);

/* read the data for each probe with 'ospf-metric-probe-' in the owner name */ /* and determine if a change to an interface’s metric needs to happen */ call config-ospf-probe-data($probe-results);

}}

/************************************************************************************************//* this template reads the rpm probe history and, based on the results, creates any necessary *//* change elements for modifying the OSPF interface metric *//************************************************************************************************/template config-ospf-probe-data($probe-results) {

var $change := { <configuration> { <protocols> {

付録 235

<ospf> { for-each ($probe-results/probe-test-results[contains(owner, "ospf-metricprobe-")]){

/* check for probe/packet loss */ var $probes-sent = probe-last-test-results/probe-test-generic-results/probessent; var $probe-responses = probe-last-test-results/probe-test-generic-results/probe-responses; var $difference = $probes-sent - $probe-responses; var $int = substring-after(owner, "ospf-metric-probe-"); if($difference != 0) { var $packet-loss-msg = "message from event-script " _ $event-script-name _ " - OSPF RPM PROBE " _ owner _ " lost " _ $difference _ " probe(s) during its most recent run. Verify that no packet loss is occurring on " _ $int; call log-status-msg($status-msg = $packet-loss-msg); }

/* determine if the difference between the new metric and the */ /* current-metric is greater than the allowed variance. if it */ /* is greater, then change to the new-metric. if it is not */ /* greater (ie - it is within the allowed variance), then do */ /* not change the metric */

var $avg-delay = { /* this is a conditional variable */ if (probe-last-test-results/probe-test-generic-results/probe-test-rtt/probe-summary-results/avg-delay[contains(@junos:format, "usec")]) { /* if the probe results come back in microseconds */ expr probe-last-test-results/probe-test-generic-results/probe-test-rtt/probe-summary-results/avg-delay; } else if ((probe-last-test-results/probe-test-generic-results/probe-test-rtt/probe-summary-results/avg-delay[contains(@junos:format, "msec")])) { /* if the probe results come back in milliseconds */ expr (probe-last-test-results/probe-test-generic-results/probe-test-rtt/probe-summary-results/avg-delay)*1000; } }

var $metric-msg = "$avg-delay for interface " _ $int _ " = " _ $avg-delay _ "usec; this msg generaged by " _ $event-script-name; call log-status-msg($status-msg = $metric-msg);

var $int-area := { call ospf-int-area($int); } var $new-metric = { call determine-metric($avg-delay, $difference); } var $current-metric = $configuration/protocols/ospf/area/interface[name = $int]/metric; if(((math:abs($new-metric - $current-metric)div($current-metric)) > $variance)or not($current-metric)) { /* if there is no average delay info for the last-probe-results yet */ /* then don’t make any changes to the ospf interface config */ if(not(probe-last-test-results)) { var $status-msg = "event-script " _ $event-script-name _ " did not changeospf interface " _ $int _ " metric because a complete RPM probe data set is not available."; call log-status-msg($status-msg); } else { /* the average delay info does exist */ <area> { <name> $int-area; <interface> {


<name> $int; <metric> $new-metric; } var $status-msg = "event-script " _ $event-script-name _ " changing ospf interface " _ $int _ " metric from " _ $current-metric _ " to " _ $new-metric _ " based on rpm probe data."; call log-status-msg($status-msg);

} } } } } } } }

/* this is an empty change element used to determine if any changes need to be made */ var $no-change := { <configuration> { <protocols> { <ospf> { <area> { } <area> { } <area> { } <area> { } } } } }

/* compare the change element to the no-change element */ if ($change == $no-change){ var $status-msg = "this message generated by " _ $event-script-name _ ": ospf probe results show no change in link latency outside the allowed variance of " _ ($variance*100) _ "%." ; call log-status-msg($status-msg); } else { call config-change($change); }

}

/********************************************************************************************//* this template returns the name of an ospf area given a logical ospf interface name *//********************************************************************************************/template ospf-int-area($int) { var $ospf-area = $configuration/protocols/ospf/area/interface[name == $int]/../name; expr $ospf-area;

}

/********************************************************************************************************//* this template is assuming probe results in always come in us; it returns a proposed interfacemetric *//* given the average delay info for an RPM probe test. *//* if there is packet loss and $metric-up-on-loss = 1, then metric up value to 50000 *//************************************************************************************************

付録 237

********/template determine-metric($avg-delay, $difference) { /* let’s say each ms for probe latency is worth a metric of 10 */ if ($difference != 0 && $metric-up-on-loss == 1) { expr 50000; } else { var $new-metric = round((($avg-delay)div(1000))*10); expr $new-metric; }}

/****************************************************************************************//* this template takes the config change element as input and commits the change via *//* an exclusive commit, then verifies if the change was successful. the template *//* returns a message indicating if the change was successful or not *//****************************************************************************************/template config-change($change) { /* debug output */ copy-of $change;

/* make the configuration change */ var $config-change-results := { call jcs:load-configuration($connection, $configuration = $change); }

/* debug output */ copy-of $config-change-results;

if($config-change-results//self::xnm:error) { var $error-msg = "configuration change failed for reason " _ $config-change-results _ ";could not configure RPM probes. this msg generated by " _ $event-script-name; call log-status-msg($status-msg = $error-msg); <output> $error-msg; copy-of $change; /* for debug purposes */ } else { var $success-msg = "configuration change to modify ospf metric values successful. this msg generated by " _ $event-script-name; call log-status-msg($status-msg = $success-msg); <output> $success-msg; copy-of $change; /* for debug purposes */ }}

/************************************************//* this template puts $status-msg in the log *//************************************************/template log-status-msg($status-msg) {expr jcs:syslog(5, $status-msg);}

/* EXPLANATION OF HOW THIS SOLUTION WORKS */

/* This automation solution sends a series of 15 RPM probes out over a defined testing period,ranging from 60* to 2592000 seconds, inclusive. One time per testing period, the event-script checks the results of the latest* completed set of probe results and reads the average probe latency. If an interface probe’s average latency is* greater than the allowed variance, then the script modifies that OSPF interface’s metric. Thissolution* consists of two separate scripts – a commit script and an event script.*


* In general, the commit script keeps the device configuration in line. The commit script performs initial* configuration of this solution (the user only need configure the commit and event scripts) andthen ensures* that there is not an accidental configuration change that breaks it. The commit script does thefollowing upon* each commit:* 1) Determines if the test-interval defined in the script lies within the valid range60..2592000 seconds* inclusive* 2) For each interface configured in OSPF with an apply-macro set to value 'monitor-linklatency’, the* commit script checks to see if that interface has a /30 or /31 network mask. This solution only runs* on ospf interfaces with the apply-macro value 'monitor-link-latency'* 3) Determines the IP address for the remote side of the /30 or /31 OSPF link* 4) Configures an RPM probe with a target address of the link’s remote side (probe name is* ospf-metric-probe-<logical-interface>)* 5) If an interface is removed from OSPF, the commit script deletes that interface’s solution RPM probes* from the configuration* 6) Configures a generated event (under the event-options hierarchy) that occurs at the defined test* interval once per testing period* 7) Configures an event-options policy that triggers upon the generated event and runs this solution’s event* script* 8) Notifies the user at the CLI and in the logs of any changes it makes to the configuration* 9) If the commit script’s $test-interval variable has been modified, the commit script creates a new* generated event with that interval, modifies the event-options policy to trigger upon that event, and modifies* the RPM probes for each OSPF interface to send an RPM probe at an interval close to (testinterval)/15 seconds*** The commit script has three variables that can be modified by the user. The most important one is the* $test-interval variable. Modifying this value allows the user to change the length of the testinterval. This* value is the length of the test interval, in seconds. Since 15 RPM probes for each OSPF interface probe are* sent in a given test interval, modifying this value causes the commit script to modify the probeinterval for* each probe whose name contains the regex 'ospf-metric-probe-’. Changing this value also causes a new* event-options generated event with the same value and a modification of the event-options policy* 'monitor-ospf-interface-probes' to trigger on the corresponding generated event. In other words, if the user* changes this variable, the script will automatically make all the necessary changes to the solution – the user* need not make any further changes.* The other two variables, $cmt-script-name and $event-script-name are the names of this commit script and the* name of the corresponding event script, respectively. The $event-script-name variable is used to ensure that* the event-options policy that runs the event script actually is configured for the correct event script. The* $cmt-script-name variable is the name of this commit script and is used to identify this script’s output in* the system’s logs.*

付録 239

* any actions taken by the commit script are logged and also noted at the CLI upon commit* ----------------------------------------------------------------------------------------------**The event-script portion of this solution is activated by an event-options policy configured by the commit* script. The event script performs the following tasks –* 1) Reads the RPM probe data only for the RPM probes whose names contain the regex ospf-metricprobe- and* finds the average probe latency for the most recently completed test* 2) Determines a proposed metric for each interface based on its most recent probe latency(metric =* (average delay in microsec)/1000 * 10, rounded to nearest integer. In other words, 10*(averagedelay in msec)* rounded to nearest integer)* 3) Reads the current metric for each OSPF interface* 4) Determines if the new metric is within a specified variance of the existing metric.* a. If variance is set to 40% (0.40), if the new metric is within 40% of the existingmetric, the* interface’s metric is not changed* b. Only if the new metric is more than 40% of the existing metric will that specificinterface’s metric be* changed* 5) Determines the area for each OSPF interface* 6) Changes the metric for each interface if the new metric is outside the allowed variance* 7) Each time the event script runs, it notifies the user via logs if it is making any changes and what* those changes are. If no changes are made, the script logs a message to that effect*** The event script has three variables that can be modified by the user, $variance,$event-scriptname, and* $metric-up-on-loss.* a) $variance is a decimal value for the percentage of variance that an interface’s RPMprobes can tolerate* before the event script will modify its OSPF metric. The script is set to provide a metric of 10 for each ms* of round trip latency. For example, when $variance = 0.4 (40%), if an interface’s metric is 500 and the most* recent probe results show an average of 65,000 microseconds (us), the script will not modify the OSPF metric* (65,000us = 65 ms = 650 metric; 30% variance). If a new set of results comes in showing a 75,000 us average* (50% difference), then the script modifies the OSPF metric to 750.* b) $script-name is the name of this event-script and is used to identify this script’smessages in the* system logs.* c) $metric-up-on-loss, when set to a value of 1, will metric up the appropriate OSPFinterface to 50,000* if any of its RPM probes are lost on the most recent time-interval. If $metric-up-on-loss is set to any* value other than 1, then the interface metric is determined from the available RPM probe data for that* interface.** any actions taken by the event-script are logged /*


次に参照すべき資料およびサイト

http://www.juniper.net/dayoneDay Oneシリーズの書籍は、PDF形式で無償でダウンロード可能です。特定のタイトルには、コピー＆ペースト対応版も用意されており、Junosの設定として直接、流用できます（ライブラリは、Apple iBookstoreから iPadおよび iPhone用のeBook形式のデータ、Kindle StoreからKindle、Android、Blackberry、Mac、および PC版のデータをそれぞれ入手できます。さらに、印刷版は、Amazonまたはwww.vervante.comで販売されています）。

http://www.juniper.net/booksJuniper Networks Booksライブラリのラインナップには、さまざまな出版社の書籍が含まれており、アイナ・ミネイとジュリアン・ルセック共著の『MPLS-Enabled Applications』もその一冊です。同書はMPLS関連のベストセラーであり、その第 3版は最高ランクの評価を得ています。

http://forums.juniper.net/jnet ジュニパーネットワークスがスポンサーである J-Net Communitiesフォーラムは、ジュニパーネットワークス製品、テクノロジー、およびソリューションに関する情報、ベストプラクティス、質問を共有するための場です。この無料のフォーラムに参加するには、登録が必要です。

www.juniper.net/techpubs/ジュニパーネットワークスのテクニカルマニュアルには、MPLSを含む、Junosのあらゆる部分を理解して設定する上で必要なすべての情報が含まれています。一連のマニュアルはあらゆる情報を網羅しているとともに、ジュニパーネットワークスのエンジニアリング担当者によって徹底的なレビューが行われています。

www.juniper.net/training/fasttrackオンライン、オンサイト、または世界中のパートナートレーニングセンターで受講できるコースをご用意しています。JNTCP（ジュニパーネットワークス技術認定資格プログラム）では、ジュニパーネットワークス製品の設定およびトラブルシューティングに関する能力認定を行っています。短期間でエンタープライズ向けルーティング、スイッチング、またはセキュリティでの認定を受けるには、提供されているオンラインコース、受講ガイド、およびラボガイドをご利用ください。

Junos Automationの参考資料

http://www.juniper.net/dayoneDay Oneのページにアクセスして、Junos Automation Seriesをご覧ください。

http://www.juniper.net/us/en/training/elearning/junos_scripting.htmlJunosの自動化を扱う無償のオンラインコースです。

http://www.juniper.net/us/en/community/junos/script-automation/#overviewジュニパーネットワークスのスクリプトライブラリです。無償で利用できるサンプルスクリプトが用意されています。

http://forums.juniper.net/t5/Junos-Automation-Scripting/bd-p/junos-automationJunosの自動化をテーマとするオンラインフォーラムです。


http://www.juniper.net/books

http://forums.juniper.net/jnet

www.juniper.net/training/fasttrack


http://www.juniper.net/us/en/training/elearning/junos_scripting.html

http://www.juniper.net/us/en/community/junos/script

http://forums.juniper.net/t5/Junos-Automation-Scripting/bd-p/junos

付録 241

Documents

Junos ネットワーキングテクノロジー - juniper.net · 6 This Week ：MPLSの導入 MPLS（Multi-Protocol Label Switching ）コアとMPLS サービスの導入を決定