さまざまなPOPでのiBGPピアとの間の送受信トラフィックエンジニアリングの問題


8

私たちは、シドニーの単一のデータセンターで小規模ネットワークを実行しているマネージドサービスプロバイダーです。私たちは最近、メルボルン(どちらもオーストラリアの東海岸にあります)に新しいPOPインターステートを展開しました。初めて、交通工学の面で現実の課題に直面する必要があります。私の希望は、iBGPパスをある程度のレベルで制御する方法について、ここでガイダンスが得られることです。

相互に関連するいくつかの質問を投稿する可能性がありますが、この場合は特に内部のトラフィックエンジニアリングについて懸念しています。iBGPで最適なルーティングを決定する方法を理解するのは驚くほど難しいことに気づきました。

私の主な目標は、iBGPにPOPごとの境界と距離の概念を与える方法を見つける必要があることです。つまり、同じ都市にあるPOPと、州間であるPOPと、東海岸と西海岸であるPOPを区別できます。次に、これに基づいてインバウンド/アウトバウンドルーティングを最適化します。

ケースバイケースのシナリオがたくさんあることは知っていますが、おそらく80%の時間で機能するiBGPルーティング戦略を開発でき、残りは特別なエッジケースに対処する必要があります。構成。

環境

  • 各POPでエッジデバイスとして機能する4x ASR 1001-Xを購入しました(POPごとに2xですが、ハードウェアの制限により、現在のところ、メルボルンに1つのエッジデバイスを配置することにのみ焦点を当てています)
  • また、ハードウェアの切り替えにもジュニパーを利用しています。「コアスイッチ」としてのEX4500およびアクセスレイヤーのEX4200。
  • 現在、2xの交通機関があります。私たちは、各1つの状態の各プロバイダーにのみ相互接続します。
  • AS 1000はアグリゲーターであり、シドニーの主要なアップストリームの1つとしてAS 4000を使用します。
  • AS 1000を介して受信されるすべてのパスは、通常、AS 4000から取得されるパスよりも1だけ長いため、これには少しの課題があります。
  • Ansibleを使用して、Jinja2テンプレートを使用してIOS構成を生成しています。そのため、物事を成し遂げるためにiBGPピアごとに大量のルートマップロジックを生成することは問題ではありません。

私の目標

基本的に、POPを展開するときに、POP間のルーティングを最適化できるようにしたいと考えています。しかし、現在のところ、iBGPがパスを選択する方法を制御することはできません。

私の現在のデザイン

  • 私は現在、2台のASR1Kをエッジルータとして機能させ、シドニーとメルボルンにフルテーブルを配置しています。
  • どちらのPOPも異なる交通機関を使用しています。
  • dot1qサブインターフェイスのエッジデバイスによって両側で終端される2つのPOP間のポイントツーポイント回路があります。
  • すべてのエッジデバイス間のこのリンク上でOSPFを実行すると、リンクのコストが増加するため、これが最も優先度の低いOSPFパスになります。
  • 両方のPOPにわたって単一のOSPFエリア0があります。
  • エッジデバイスは、統合されたコア/エッジに近いものです。私たちのコアスイッチは、テーブル全体を処理できないため、L3をあまり実行しません。
  • 各POPでは、ASR1KはそのPOP内の他のBGPデバイス(ファイアウォール、コアスイッチ、LNSなど)のルートリフレクターとして機能します。
    • POPごとではなく、それぞれに独自のクラスターIDがあります。これをPOPごとに変更することを検討しています。
  • 各ASR1Kは、BGPを介してルートリフレクタクライアントへのデフォルトルートを発信します。
  • すべてのASR1KはiBGPメッシュ内にあります。
  • すべての交通機関は、すべてのサイトで同じローカル設定を持っています。

次善のルーティングの例

  • メルボルンとシドニーをすべてオンラインで通過する場合、アウトバウンドルーティングは正常に機能します。シドニーの交通はシドニー経由で、メルボルンはメルボルン経由で出ます。
  • 問題は、シドニーの主要なトランジットを管理者が無効にするだけで、メルボルンのトランジットが自動的に優先されるようになったことです。私のセカンダリシドニーの代わりに、シドニーのBDR02ルーターを経由します。
  • そのため、トラフィックがバックホールを介してメルボルンに跳ね返り、メルボルンを出てシドニーに戻るというシナリオがよく起こります。1ミリ秒未満で発生していたパスは、約30ミリ秒になりました。
  • さらに悪いことに、この特定のシナリオでは、メルボルンが好まれている理由を理解できません。

    • 重量は同じです
    • ローカル設定は同一です
    • ASパスは同じ長さです
    • どちらのパスも自己由来ではありません。
    • どちらもIGPを起源としています。
    • 両方のメトリック(MED?)は0です。
    • どちらも、このルーターから見たiBGPパスです。
    • IGPとしてOSPFを使用しているため、IGPメトリックはOSPFリンクコストと相関していると考えていました。
    • 100G参照帯域幅がすべてのOSPFデバイスに設定されていることを確認しました。

編集:30/01:IGPコストの計算方法が間違っていると思いますが、おそらく現在は同じですか?私のOSPFルートはすべてタイプE2です。IGPコストが同じである場合、RIDに基づいて最良のパス選択が行われることが理にかなっていると思います。この場合、MEL BDRのRIDはSYDよりも低くなります。

シドニー間のOSPFリンクコストをデフォルトよりもはるかに高い15,000に設定しました。100 Gbpsの参照帯域幅で確実に機能するようにこれを計算しました。

OSPFリンクコストの観点から-これは、BGPルートの各ネクストホップのOSPFs設定です。

bdr-01-syd#sh ip route x.x.201.73 (AS 4000 next hop)
Routing entry for x.x.201.72/30
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 15000
  Last update from x.x.13.51 on Port-channel1.1125, 14:57:17 ago
  Routing Descriptor Blocks:
  * x.x.13.51, from x.x.13.66, 14:57:17 ago, via Port-channel1.1125
      Route metric is 20, traffic share count is 1
bdr-01-syd#

bdr-01-syd#sh ip route x.x.31.5 (AS 1000 next hop)
Routing entry for x.x.31.4/30
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 5
  Last update from x.x.216.67 on Port-channel1.36, 1d00h ago
  Routing Descriptor Blocks:
  * x.x.216.67, from x.x.216.163, 1d12h ago, via Port-channel1.36
      Route metric is 20, traffic share count is 1
bdr-01-syd#


x.x.201.73 is the next hop to 139.130.4.4 via the Melbourne path.

x.x.13.51 is the other end of the inter-state Point to Point. x.x.13.66 is BDR-01-MEL.

x.x.31.5 is the next hop to 139.130.4.4 via the Secondary Sydney transit in the same POP as the primary transit - via BDR-02-SYD.

x.x.216.67 is the local OSPF VLAN for the Sydney POP that both BDR01 and BDR02 are in.

x.x.216.163 is the BDR-02-SYD router.

これらのOSPFの選択に関しては、より短いOSPF "転送メトリック"が選択されていることがわかります。私はBGPがこれに基づいてシドニーの道を選ぶべきだと思ったでしょう。

このトレースから、最初のホップが13ミリ秒(139.130.4.4はエニーキャストされ、両方の州にパスがある)であるため、バックホールを介してメルボルンにすぐにホップすることがわかります。

bdr-01-syd#traceroute 139.130.4.4
Type escape sequence to abort.
Tracing the route to 139.130.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 x.x.13.51 13 msec 13 msec 13 msec
  2 x.x.201.73 14 msec 14 msec 14 msec
  3 x.x.196.54 [AS 4000] [MPLS: Label 25049 Exp 0] 14 msec 14 msec 14 msec
  4 x.x.196.51 [AS 4000] 14 msec 14 msec 14 msec
  5 139.130.110.29 [AS 1221] 14 msec 15 msec 14 msec
  6 203.50.11.113 [AS 1221] 16 msec 14 msec 16 msec
  7 139.130.4.4 [AS 1221] 13 msec 14 msec 14 msec
bdr-01-syd#

bdr-01-syd#sh ip route 139.130.4.4
Routing entry for 139.130.0.0/16
  Known via "bgp 5000", distance 200, metric 0
  Tag 4000, type internal
  Last update from x.x.201.73 06:06:14 ago
  Routing Descriptor Blocks:
  * x.x.201.73, from x.x.13.66, 06:06:14 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 4000
      MPLS label: none
bdr-01-syd#

bdr-01-syd#sh ip bgp regexp ^1000 1221$
BGP table version is 11307146, local router ID is x.x.216.161
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
...
 * i  139.130.0.0      x.x.31.5             0    100      0 1000 1221 i
...

Versus the path via AS 4000:

bdr-01-syd#sh ip bgp regexp ^4000 1221$
 *>i  138.130.0.0      x.x.201.73            0    100      0 4000 1221 i

bdr-01-syd#

この出力では、シドニーの2番目のトランジットと有効なパスの両方が有効です。メルボルンは最高のものとして選ばれています。

bdr-01-syd#sh ip bgp 139.130.4.4
BGP routing table entry for 139.130.0.0/16, version 10794227
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     66
  Refresh Epoch 1
  1000 1221, (received & used)
    x.x.31.5 (metric 20) from x.x.216.163 (x.x.216.163)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 1000:65110 5000:1000 5000:1001 5000:1002
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  4000 1221, (received & used)
    x.x.201.73 (metric 20) from x.x.13.66 (x.x.13.66)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 4000:5307 4000:6100 4000:53073 5000:1000 5000:1030 5000:1031
      rx pathid: 0, tx pathid: 0x0
bdr-01-syd#

私が試したこと

OSPFリンクコスト15,000を追加してみました。これは、100 Gbpsの参照帯域幅に基づいて安全な数値として計算したもので、常に最低の優先OSPFコストであるとしています。これは「IGPコスト」としてカウントされると思っていましたが、何らかの理由でBGPは依然としてメルボルンパスを優先しています。

これが何の影響もないように思われた後、私の主な計画は、iBGPでAS PATHを先頭に追加することでした。計画では、POPごとにピアグループを用意しました。また、テンプレートでは、2つのPOPがどれだけ離れているかに基づいて、プリペンドをいくつ行うかを指定します。これはかなり一般的なタイプの目標だと思っていました。

例えば:

  • POP内の場合は0が付加されます
  • 州内POPの場合は1を付加
  • 州間のPOPの場合は2が付加されます
  • 東西海岸POPの場合は3が付加されます

これは非常に完璧に機能し、非常にエレガントなソリューションであり、まさに私が望んでいるタイプのソリューションです。数時間で構成を書いてデプロイしました。しかし、iBGPがASパスの先頭付加をサポートしていないことに気づくまで、頭を悩ませました。

これを機能させることができたとしても、それがサポートされるソリューションになることは決してないようです。

私が考えていること

  • 最後のリンク@ ipspace.netは、AS内で永続化するためにlocal-prefを使用できることを述べています。しかし、私はすでに下流の顧客ルート、IXes、通常を優先するようにlocal-prefポリシーを計画しました...これにlocalprefを使用するとうまく混合しないようです。そしてイヴァンはそれを示唆していません!
  • BGPコンフェデレーションの使用を検討しましたが、これは私たちの小規模ネットワークにとっては多くの追加作業のようです。また、連合AS間のASパスホップはいずれにしても追加されないことも読みました。だから私はおそらく同じ場所に行きつくでしょう。
  • MPLSの使用を検討します(MPLS TEと思いますか?)が、MPLSに関しては非常に環境に配慮しており、すでに多くの課題を抱えています。したがって、問題の適切な解決策でない限り、複雑さが増すのを避けたいと思います。

詳細は明日追加します。とりあえず、現在のセットアップを表す図を次に示します。

州間データセンター図


2
あなたはここでかなり多くを求めています。個人的に言えば、これらの種類の問題を解決することは、ここにいる私たちの多くが私たちの生計を立てている方法です。特定の質問にお答えして喜んでサポートさせていただきますが、このレベルのエンジニアリングが無料で提供されるとお客様や会社が期待するのは合理的ではないと思います。
ロントランク

@Geekmanは、Cisco BGPのベストパス選択を適切に評価するために欠けている部分があります。これは、バイパスしたり、次の手順を続行したりするのが難しいと思われる情報に基づいています。出力から、Distance 200はiBGPなので、ステップ10に進むことができます。この内訳について系統的でしたか?アルゴリズムへのリンクは[こちら] [0] [0]:cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/...
DRP

@RonTrunkこんにちはロン、間違いなくそれを意識して、私はそれを書き直す必要があるかもしれないと思って質問を提出しました。私は私が求めているように私は感じると思い1ビットが最終的に太字で質問を、。私はこれの多くが「依存する」ことを知っているので、ソリューションが適合するように私の全体的な目標が何であるかについて多くの詳細とコンテキストを提供したいと思います。私は完全に一般的なアプローチをとり、自分のニーズを満たすために詳細に合わせるつもりです。おそらく、あなたはまだこれがあまりにも多くを求めているように感じますか?
ギークマン2018年

@RonTrunk最終的に私はこのような状況で一般的に次のようなものを得ることを望んでいたと思います、AS PATHの前に追加する代わりに、次の方法を使用してPOPごとにうまく機能するiBGP距離に境界を課すことができます。多分何人かの人々は経験からうまくいく方法で話すことができますか?これらの目標すべてに完全に対処するように要求しているように見えるのは、詳細レベルだけなのかどうか不明です-私はそうではありません。
ギークマン2018年

2
これは私がSEで目にした中で最も記述的な質問です!違反はありませんが、これはSEコミュニティから無料で要求するには多すぎます!
マーベリック

回答:


6

どちらのルートも外部タイプ2であり、OSPF E1としてルートをアドバタイズしました。E2は常にE1よりも優先され、これにより問題が解決しました。


@Geekman質問が少し拡張されているので、短い回答でも問題ありません:)
DRP

はい、あなたの助けをありがとう!この回答を喜んで受け入れます。E2からE1に変更することで、ルートメトリックが常に20であるのではなく、15020に更新されたことにも気づきます(つまり、当初予想したとおり)。累積コストを計算するには、E1が必要なようです。
ギークマン2018

1
Geekmanの定義によると、OSPF E1ルートには、そのE1ネクストホップに到達するためのリンクメトリックの合計が含まれます
Mike Pennington
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.