MPLS&VPNアーキテクチャ第6章
最終更新：
yayoi82912 2012年05月22日(火) 21:16:49履歴
MPLS移行と設定のケーススタディ
バックボーンのフレームモードMPLSソリューションへの移行
移行前のインフラストラクチャの確認
CEF要件
内部BGP構造の取扱い
内部リンクからMPLSへの移行
不要なBGPピアリングセッションの削除
ATMベースバックボーンからフレームモードMPLSへの移行
セルモードMPLS移行
バックボーンのフレームモードMPLSソリューションへの移行 
- 複数POPと複数の上位プロバイダーへの出口を持つサービスプロバイダにおいては、各POPでBGPを実行しバックボーンネットワークで顧客ルートを伝搬させ、外部BGPピアに対して広報する必要がある。
- そのためにはPOPとコアにルートリフレクタを持ち、POPのルートリフレクタはコアのルートリフレクタクライアントとして動作させる必要があり、複雑で階層的なトポロジーとなる。
- MPLSアーキテクチャへの移行はサービスプロバイダのルーティングプロトコル構造の複雑性を軽減したいというソリューションに応えることができる。
移行前のインフラストラクチャの確認
サービスプロバイダコアでMPLSを実行する利点として、コアルータからBGP情報を削除できる点にある。
すべての顧客ルートはBGPで運ばれることになり、デザイン面で以下の利点がある。
すべての顧客ルートはBGPで運ばれることになり、デザイン面で以下の利点がある。
- BGPは多数のルート数に対応できる唯一のプロトコルである。プロトコル設計の最終形態の1つでもある。スケーラビリティは本プロトコル設計目的の1つとされます。
- 外部ルーティングはBGPにより運ばれるので、ネットワークの内部ルーティング構造はルートフラッピングなどの外部の影響から保護される。
- BGPによりQoSポリシーを分配することが可能（QoS Policy Propagation for BGP:QPPB）。これにより、BGPコミュニティ属性を使用して各顧客ごとに差別化したサービスを提供することができる。
- IGPに大量のルートを注入すると、プロトコルのパフォーマンスが低下し、安定性とスケーラビリティに問題が発生する。
CEF要件
- バックボーン内の全インタフェースでCEFを利用可能にする必要はない。
- エッジLSRのインバウンドインタフェースのような、ラベル付加を実行するものについてのみ必要となる。
- ただし、インタフェースでCEFを利用付加としておく特別な理由がなければ全インタフェースで使えるようにしておくのが望ましい。
- (config)# ip cef または (config-if)# ip cef distributed(75xxシリーズでのdistributed CEF)
- インタフェースごとにCEFを実行しないようにするには
- (config-if)# no ip route-cache cef または no ip route-cache distributed
コメントをかく