OSPFをメトロイーサネット全体に展開するのは理にかなっていますか？

顧客のために複数のブランチサイトを相互に接続する必要がある場合、通常、信頼できるキャリア経由のMPLS VPNをお勧めします。各サイトのCEはアップストリームPEとBGPを話し、各サイトは独自のプライベートASNで番号が付けられます。BGPは無数のトラフィックエンジニアリングツールを提供し、隣接はnサイトに対してn + 1に制限されているため、これは非常に便利です（+1はコロ環境です）。

しかし、最近、メトロイーサネットソリューションに対する顧客の関心が高まっていることに気付きました。多くのお客様は、共通のメトロエリア内にブランチサイトを持ち、MetroEの見積もりは、同じ速度の回線のMPLSサービスよりも数百ドル（USD）安くなっています。これは魅力的ですが、メッシュトポロジをハブアンドスポークに変えることを避けながら、レイヤー2バックボーン全体に最適なルーティングを確立する方法がわかりません。

BGPは、メッシュ接続を維持するために、ブランチサイト間の隣接関係のフルメッシュを必要としますが、これは明らかにスケーラビリティの観点から望ましくありません。もう1つのオプションは、IGP、つまりOSPFを展開し、すべてのサイトがWANを介して隣接関係を形成することです。私は各サイトを独自のエリアとして扱いたいと思いますが、これはやり過ぎのようですが、各サイトからアドバタイズされたルートを要約する機能を保持したいと思います。これはエリア境界でのみ実行できます。

これは理にかなっていますか？この方法でOSPFを展開するときに注意する必要がある警告はありますか（たとえば、LSAフラッディングを無効にすることを検討する必要があります）。または私が見落とした別の解決策はありますか？

2つの異なる製品は非常に異なるため、これは一種の複雑な質問です。MPLS L3VPN回線は、本質的に参加するすべての場所間のフルメッシュであり、MetroE接続は一般に2つの特定のサイト間のポイントツーポイントリンクです。

私の経験では、MetroE回線は直接プロビジョニングされたパスであり、保護パスと契約していない限り、保護サービスはありません。つまり、特定のパスに沿ったインターフェイスまたはルーターの障害は、MetroEサービスによって直接リンクされている2つのサイト間のトラフィックの中断になります。MPLS L3VPNは、サイト間のフルメッシュを維持するために、インターフェイス/ルーティングの障害を修復します。これは通常、2つの価格差を考慮します。

MetroEプラットフォーム上に独自のサービスを構築することには何の問題もありません。適切なルーティングの種類を決定するために、顧客の要件を操作するだけです。小規模オフィスネットワークで作業している場合、OSPF / IS-IS / EIGRPは、確立した直接接続されたサイト間でルーティング情報を交換する素晴らしい方法です。NSP / ISP / * SPを使用している場合は、スケーリングするにつれて、IGPとEGPの間でインフラストラクチャと顧客のルートを分離することがより重要になります。

ISPエンジニアとして、MetroEおよびEWANリンクを広く使用してバックボーンを構築し、物理リンクの知識を活用してiBGP / eBGP環境を設計しています。多くの場合、ルートリフレクターとデュアルルートリフレクター（ピアリングの両側のルートリフレクタークライアント）を使用して、iBGPピアカウントを減らします。ただし、POPで6台以上のルーターを処理している場合を除き、iBGPは非常にうまくスケーリングします。

要するに、もしそれが単一のクライアントのためであるなら、それは彼ら自身のクライアントにネットワークサービスを提供していない-IGPに固執する。フェールオーバー/冗長性などを使用してサイト間で外部接続を共有する必要がある場合は、使用している物理パスを詳しく調べ、それを反映するようにeBGP / iBGPを設計します。AS内の他のすべてのルーターとサイト外のiBGPピアへのリンクが1つしかないリモートロケーションにルーターを置くことは意味がありません。デュアルルートリフレクターを使用します。

管理対象のL3VPN（「MPLS VPN」という意味）からL2VPNへの切り替えは、非IPプロトコルを実行し、ルーティングプロトコルとルーティングを定義するルーティングプラットフォームを完全に制御できるという点で優れたステップアップです。トポロジー。

各サイトのCPE側にイーサネットMACアドレスを1つだけ配置すると仮定すると、サイトごとに多数の潜在的なサブネットを学習およびルーティングするよりも、プロバイダーの機器がサイトごとに1つのMACアドレスを学習および転送する方がはるかに簡単です。

プロトコルに関して言えば、これは多くの情報なしで答えるのが少し難しい質問です。最良の選択はトラフィックと成長計画に依存するからです。

これは、内部接続とインターネット接続を必要とする1つの大きな顧客ですか、それとも接続も販売していますか？すべてが内部であると仮定すると、IGPを展開し、パスをアナウンスするためにeBGPを実行するだけです。

サイトや内部プレフィックスがあまりない場合は、OSPFやIS-ISなどのリンク状態プロトコルが最も理にかなっています。これは、すぐに収束し、プレフィックスが数個しかない場合にRIBからFIBをすばやく構築できるためです。 。

多くのサイトまたは多くのプレフィックスがある場合、それぞれがそれぞれを処理する必要があるため、ルーティングプラットフォームに負担がかかり始めます。これはn ²時間かかり始めるものです。頻繁にアップダウンするサイトがある場合、このリンクステートのチャーンはルータープールに負担をかけ始める可能性があります。

多くのサイト、多くのスタブサイト（1つのパス "上流"、他のダウンストリームルーターなし）、または大量のルートチャーンを使用する場合は、他のプロトコルまたはトポロジを調べる必要があります。

そのような場合には、いくつかのルートリフレクターでBGPを使用することをお勧めします。このようにして、スポークがアナウンスし、他のスポークがルーティングテーブルを取得できる、2つ以上の頑丈なルートリフレクタをプロビジョニングできます。このようにして、接続するだけで多くのスポークサイトに軽量CPEを展開し、スペースをアナウンスして、内部テーブルまたはルーターへのデフォルトルートを取得できます。

おおよそ、いくつかのスケールとギアを提案します（そして、サブギガビットのスループットを想定しています）：

• 1-20スポーク-すべてのサイト間のOSPFv3。Juniper SRX240またはすべてのサイトに類似したもの。
• 20-100スポーク-ルートリフレクターを備えたiBGP。スポークにはジュニパーSRX240、ルートリフレクション（またはDebian Linux / BIRD）にはジュニパーMX5 / 10/40/80。
• 100-500スポーク-それらを異なるL2ネットワーク、AS、またはエリアに分割し始めます

見落としがちな2つのビットをBGPの議論に追加するだけです。

• iBGPを実行する場合、通常、BGPネクストホップ間の接続を確立するために別のルーティングプロトコルが必要です。設計の観点から見ると、iBGPはルーティングプロトコルよりもスケーラビリティツールです。
• eBGPを実行する場合、エンドツーエンドの最適なトラフィックフローのためにBGPセッションのフルメッシュは必要ありません。BGPネクストホップ処理は、これらの問題をうまく解決します。

詳細については、http：//blog.ioshints.info/2011/08/bgp-next-hop-processing.htmlを参照してください

マルチポイントメトロイーサネットサービスでOSPF（または他のIGP）を非常にうまく実行でき、非常にうまく機能するはずです。

ただし、BGPを実行し続ける理由がある可能性がありますが、それらは、自分のネットワーク内でもBGPを実行する必要がある理由とほぼ同じです。

そのような「ブロードキャスト」ネットワーク上のすべてのBGPスピーカーを同じASに配置する必要は必ずしもありません。これは、プライベートASがレイヤー2メッシュを介して相互接続できる、電気通信によって実行される一種の内部IXPと考えてください。BGP更新は、ピアセッションの送信元とは異なる更新メッセージでネクストホップを運ぶことができるため、必ずしもBGPピアリングのフルメッシュを維持する必要さえありません。

したがって、たとえば、ルーターA、B、およびCを含むレイヤー2メッシュがあり、AとB、およびBとCの間にBGPピアがある場合、CがAから発信されたルートの更新を取得すると、 Bとのピアリングセッションを通じて学習された場合でも、Aをネクストホップとします。明らかに、単一のハブアンドスポークよりも多くのルートピアリングが必要になるため、単一のハブに依存しませんが、どうしてもフルメッシュを必要としないでください。

この方法でBGPを実行すると、ルーティングポリシーの利点がすべて得られます...また、別の回答者が述べたように、同じプライベートAS番号スペースを使用でき、既存のL3VPNと相互接続できるため、モデルとサポートメカニズムを変更する必要はありません。

そうは言っても、OSPFとiBGPを実行する2つのメトロEリンク（この場合はポイントツーポイント）があり、正常に機能します。

ハブ/メインルーターのrsクライアントを「スポーク」するルートサーバー構成はどうですか？

bgpピアリングはハブ＆スポークトポロジのようになりますが、すべてのスポークは他のすべてに直接トラフィックを送信できる必要があります。

MPLSプロバイダーで使用されているものと同じプライベートAS番号を再利用して、サービスから別のサービスへの移行を容易にすることもできます。

標準ではなくNBMAとして開始するなど、代替のOSPFトポロジを読んで決定することを強くお勧めします。OSPFが同じメトロイーサネット内の同じルーター/サイトに向かう2つのパスを正しく選択する方法がないことがすぐにわかります。これは、発信インターフェイスを介したコストの計算方法により、メインとバックアップの両方のWANリンクが同じに見えるためです標準OSPFのコスト。ただし、たとえばNBMAの使用を選択した場合、隣接コストを手動で定義できますが、メッシュ/隣接を手動で定義する必要があります。

何をしても、ルート2はレイヤー2に参加しないでください。レイヤー2の相互接続が必要な場合は、OTVまたはその他のレイヤー2オーバーのレイヤー2機能を使用してください。

WANコアが隠されている単純なプロバイダーMPLS-VPNに比べて、OSPFについて多くのことを学ぶことができます（さらに多くのことを知る必要があります）。

OSPF over metroEは正常に機能しますが、ニーズに合っていることを確認し、それに応じて設計する必要があります。言及されていない警告の1つは、プロバイダーがサポートしているMTUを確認することです。プロバイダーのメンテナンス中に、metroEリンクでMTUドロップが発生し、OSPFネイバーが起動しませんでした。おそらくジャンボフレームを実際にはサポートしていないために問題になっているだけでしょうが、私たちだけのためにやっていました。