エンタープライズマルチホームの改善


33

BGPデュアルプロバイダー、デュアルルーターの設計を改善する方法に関する意見を聞きたいと思います。各プロバイダーは、/ 24パブリックサブネットを提供します。ルーター、回路、サブネット、HSRPグループ、およびプロバイダーをそれぞれAおよびBと呼びます。各回路の帯域幅は、負荷全体に十分です。

現在の設計

現在の設計では、プロバイダーごとの対称性を実現しようとしています。定常状態では、目的のルーティングロジックは、サブネットAとの間のトラフィックが回線Aのみを通過し、サブネットBとのトラフィックが回線Bだけを通過することです。回線は、障害状態で相互にバックアップします。

プロバイダーは、デフォルトルートのみをアドバタイズします。アウトバウンドルーティングには、PBRとHSRPの混在が伴います。ルーターにはルーティングがありません。iBGP、OSPF、静的ルーティングはありません。代わりに、デフォルトルートを追跡する2つのHSRPグループがあります。ルータAはHSRPグループAのプライマリであり、ルータBはHSRPグループBのプライマリです。ダウンストリームデバイスには、サブネットBからのトラフィックをHSRPグループBに向けるHSRPグループAおよびPBRを指すデフォルトルートがあります。コミュニティ。サブネットAは回線Bで先頭に追加されて通信され、サブネットBは回線Aで先頭に追加されて通信されます。

この設計には改善の余地が大いにあります。インターネットトポロジの認識不足と回線アフィニティの組み合わせにより、最適なパス選択が完全に排除されます。プロバイダーの階層指定に関する懸念があり、設計は「許容可能なパフォーマンス」を提供し、トラブルシューティングが簡単であると合理化されています。確かに、デザインはおそらくこれ以上シンプルになりませんでした。追加のASを通過すると、RTTに6ホップと63ミリ秒(+ 421%)が追加されることを実証しました。私は受け入れられるために解決したくない。

より良いデザイン

より優れた設計により、ルーターは可能な限りインターネットトポロジを認識できます。最適なパスアルゴリズムは、着信および発信ルーティングロジックを決定するために残されます。回線は、障害状態で相互にバックアップします。

プロバイダーは完全なビューをアドバタイズします。ルーターはiBGPとOSPFを実行します。HSRPは廃止されました。アウトバウンドルーティングは、純粋に宛先ベースのベストパスであり、インバウンドルーティングは、ベストパスアルゴリズムとトランジットプロバイダーの気まぐれに委ねられます。

入力したら、もっと簡単に見えます。少なくとも、説明するのに必要な言葉は少なかった。非対称性に関する懸念がありますが、現在の設計では多くの非対称性が見られます。それらはおそらく同様に非対称になりやすいと思うだろうし、それは本当に私を心配しない。結果として問題を見たことはありません。現在、それはifsの領域に追いやられています。

私はここで基地を離れていますか、それとも頭に釘を打ちましたか?他の人がこの問題をどのように解決しましたか?Googleは何をしますか?


詳細と説明。ようこそ!
パンダム

伝統的に、「私は私のデザインにいくつかの意見を取得したいと思い、」質問は本当に素晴らしいSEの質問ではありません...しかし、これはメタに議論することができます
アーロン

回答:


16

はい、あなたは頭に釘を打ちました。

改良された設計では非対称性が得られますが、非対称性はインターネットの現実であり、トラフィックの対称ルーティングを期待する正当な理由はありません。シュート、パケットルーティングの全体的な概念は、別々のパケットが互いに独立してルーティングされ、異なる方向、つまり同じ方向に進むパケットであってもよいということです。

個人的に、私はPBRを嫌います。問題に対する最善の解決策であると判断したとき、私は停止し、問題の本当の性質を本当に理解しているかどうかを確認するために一歩戻りますです。そうすると、ほとんどの場合、そのような技術を使用せずに問題を解決する方法があることに気づきます。

ルーターに完全なインターネットルートを設定するには慣れるのに時間がかかりますが、慣れるとトラブルシューティングが非常に簡単になります。確かに、心配する必要のあるさまざまなプロトコルの「可動部分」はほとんどありません。

OSPFデータベースに完全なインターネットルートが必要ないため、OSPFを介してネットワークの内部にデフォルトをアドバタイズする必要があります(または静的デフォルト...個人的にはOSPFのデフォルトを好みます)。これにより、トラフィックをBGPを話すインターネットルーターに移動します。これにより、完全なインターネットルートを持つという、より十分な情報に基づいた決定を下すことができます。

これにより、「宛先ベースの最適パス」に近づきます。トラフィックが予期しない動作をする場合がまだあるので、BGPルート選択プロセスに精通してください。


ありがとう、ジェフ。PBRに関するあなたの態度に同意します。悪夢のように実装されているのを見てきました。覚えておくよりも多くのPBRをネットワークからリッピングしました。私はかつて、SVI(100's)ごとに一意のルートマップを持つ仮想ルーティングメカニズムとしてPBRが展開された階層環境を管理していました。PBRには、プロセスの切り替えにつながる許可/設定なしの句も含まれていました。ハードコピーでは、60ページの構成のようでした。言うまでもなく、私は破壊ボールをそれに取りました。それをVRFに置き換えました。
デニスオルバニー

6

既存のアイデアよりも良い場合もそうでない場合もあるが、主にそこにあるいくつかの余分なアイデアを通して、すでに与えられている他の人に異なるアプローチを提供する。

現在の状況を改善するためにできる2つの簡単な手順は次のとおりです。

ステップ1 ;

両方のプロバイダーから完全なBGPテーブルを取得します-これで、目的地へのASパスが最小のトランジットプロバイダー経由でルーティングされるため、より最適なアウトバウンドルーティングが得られます。前述のように、HSRPを削除し、OSPFでデフォルトルートを簡単にアドバタイズし、2つのエッジルーター間でiBGPを実行できます。

ステップ2 ;

2つのエッジルーターにASプリペンドとコミュニティなどを設定して、必要に応じて送信トラフィックをきめ細かく制御します。したがって、ISP Bはあるサブネットへのより良いルートを持っているかもしれませんが、ISP Aからより多くのトランジットを購入するかもしれません。


あなたが持っているとして言及した2つの/ 24がPI独立アドレススペースであると仮定すると、両方のプロバイダーを介してそれらをアナウンスするか、両方のプロバイダーが同じIPアドレススペースをアナウンスすることに同意している場合、両方のルーターから両方のISPに両方のプレフィックスをアナウンスすることができますプリペンドまたはコミュニティなしで、より良いインバウンドルーティングも取得します(もちろん、adhearなどに必要なCDRがない限り、必要に応じて調整できます)。


ありがとう、javano。インバウンドとアウトバウンドのルーティングポリシーが有害であることに同意すると思います。PBR、プリペンディング、コミュニティを完全に廃止したい!
デニスオルバニー

3

シンプルに始めて、必要な場合にのみ複雑さを追加します。インターネットエッジルーターでOSPFを実行する必要があるかどうかも疑問です。PBRを縁石までブートし、内部ネットワークでのみ使用します。

  1. ルーターにメモリがある場合は完全なインターネットルートを使用しますが、フィルタリングを実行してください!gt a / 24を投げます。
  2. AとBからデフォルトルートを取得します。
  3. iBGPを実行して、AおよびBから受信したすべてのプレフィックスを考慮して、ルーターがベストパスを決定できるようにする必要があります。
  4. 両方のプロバイダーでAとBの両方/ 24を使用する予定の場合、BのネットワークにAの/ 24を追加するか、またはその逆を行うことにより、着信トラフィックにより良い影響を与えることができます。両方の/ 24をアドバタイズする必要があります!ISPのコミュニティでprependsの設定を確認してください。
  5. ファイアウォールからの送信トラフィックに2つの異なるHSRPグループを使用します。ECLBをセットアップして、2台のルーターに負荷分散することができます。 等コスト負荷分散

AとBの両方にアドバタイズされた単一の/ 24を使用している場合、これらすべてを単純化できます。

後で、より優れたトラフィックエンジニアリングと保護のために、より複雑になります。

  1. ピアルートマップを使用してlocalprefを設定し、AとBのどちらのルートを使用するかを決定したい場合は、AとBのコミュニティに精通してください。
  2. BGPが破裂した場合の緊急バックアップとして、両方のルーターにフローティングスタティックデフォルトルートを設定します。

    ip route 0.0.0.0 0.0.0.0 a.b.c.d 254
    
  3. IPスペースの半分がAを通過し、残りの半分がBを通過するなど、インバウンドポリシーを制御するためのより複雑な広告方法を検討します。特定の/ 24に対して、/ 24をAとBの両方に広告できますが、 2つの/ 25を使用し、下位の/ 25をAに、上位の/ 25をBにアドバタイズします。

  4. ソフトリコンフィギュレーションを使用して、ポリシーを微調整し、BGPセッションでソフトリセットを実行できるため、セッションを完全にリセット(またはクリア)した場合に、反対側でプレフィックスが減衰することはありません。ポリシーの変更にはリセットが必要です。


1

この記事から理解できることは、外部サブネットに到達するためにASパスに基づいて決定する必要は本当にないということであり、2つのISPへのデュアルホーミングの唯一の目的は、インターネットに到達するために冗長性を購入することです。その場合、BGPを実行する必要はありません。両方のサービスプロバイダーから既に受信している同じデフォルトルートをそのまま使用できます。次に、ネットワークのローカル側で、LANに面しているインターフェイス上のISPに接続するルーターで単一のospfエリアを実行します(プロセスにISPインターフェイスを含めないでください)。異なるエリアにルーターを追加し、ネットワーク境界でサブネットを要約できますが、2つのサブネットの場合、OSPFデータベースのサイズやLSAフラッディングの数は大きな問題ではないと思います。

ISPに接続する各OSPFルーターで、「default-information origin」ステートメントを使用して、学習したデフォルトルートをOSPFに再配布します。

いくつかの利点:

  1. この設計により、ネットワークを拡大するときに、サービスプロバイダーでBGPを有効にし、ダウンストリームデバイスに触れることなくデフォルトルートを受け入れることができます。BGPからデフォルトルートを受信して​​いることを確認するまでは問題ありません。

  2. メンテナンスのためにISPからトラフィックをルーティングする必要があるときはいつでも、そのルーターのOSPFプロセスの下から「デフォルト情報発信元」を削除して、メンテナンスを続行します。他に何も必要ありません。

そして、対称ルーティングが過大評価されているという以前の答えに同意します。むしろ、スケーラビリティと保守の容易さを追求します。


@ user161の計画を理解している場合、目標はよりインテリジェントなアウトバウンドパスの選択です。OSPFベースのソリューションでそれをどのように実現しますか?
ポール・ギア

ありがとう、ヴィニー。アウトバンドトラフィックのフェールオーバーは問題ではありませんが、着信をフェールオーバーするためにBGPは必要ありませんか?これがユーザーがインターネットにPATを取得するだけの場合は、実行可能かもしれませんが、これはWebホスティング環境です。
デニスオルバニー

@ user161:もちろん、発信元のサブネットにインバウンドフェールオーバーが必要な場合は、BGPを実行する必要があります。ISPに確認して、BGPピアリングのORF機能をサポートしているかどうかを確認してください。デフォルトルートを受け入れるためだけに、またはISPルーターからいくつかのサブネットを選択するために、ボーダールーターにインバウンドフィルターを使用してローカルに発信されたサブネットをBGPでアドバタイズできるかどうかを確認してください。ISPがORFをサポートしていない場合、ジュースの多いルーターを購入するよりも良い選択はありません
。-ヴィニー

1

完全なBGPテーブルが多すぎる場合は、一部だけを受け取ることを検討できると思います。おそらく、プロバイダーAとBはそれぞれデフォルトルートとローカルASルートをアドバタイズします。内部でiBGPを実行する必要があります。そうすれば、プロバイダーに直接接続されているものの最短ルートが得られ、ダウンストリームASルートのいずれかが使用されます。


ありがとう、ケリー。より良い設計はiBGPを実行します。ハードウェアの更新によりアーキテクチャのレビューが促されているため、ルーターがそれを処理できるかどうかはあまり心配していません。営業チームは、IOSからJUNOSへの移行は簡単なことだと言います。これまでのところ、同意するかどうかはわかりません。
デニスオルバニー

私はそれがケーキウォークだと言うことを知りません...新しい構文だけでなく、構文の新しい概念を学ぶのは大変です。しかし、私が言うことは、それはそれだけの価値があると信じているということです。JunOSはしばらく頭を悩ましますが、ある時点でクリックし、すべてが意味を成し始めます。もちろん、まだ調べておく必要があります(言語の構文を知ることは、語彙を知ることと同じではありません)が、概してそれは理にかなっています。
ジェフマクアダムス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.