プリペンドが機能しない場合の対処方法

Russ White ブログからの一連のメモの翻訳を共有したいと考えています。彼は、BGPを介してインターネットプロバイダーに接続するときにAS-PATH Prependを使用する問題を提起しています。

組織をBGPを介して2つ以上のプロバイダーに接続すると、いくつかのタスクが発生する場合があります。 たとえば、非対称ルーティングを回避するには、つまり、セッションが開始された同じプロバイダーを介して応答パケットが返されるようにします。 または、逆に、非対称ルーティングを考慮せずに、プロバイダーのチャネル全体でトラフィックの均一な分散を実現します。 どちらの場合でも、BGP属性AS-PATHを使用して、インターネットプロバイダーの企業ネットワークへのルーティングに影響を与えることができます。 しかし、残念ながら、このアプローチは常に望ましい結果を達成するのに役立つとは限りません。 AS-PATH Prependの使用に関する問題について説明します。



AS-Path Prependが機能しないのはなぜですか？



したがって、着信チャネルの負荷分散を改善する必要があります。 インターネットを検索すると、このタスク用にAS-Path Prependを構成する方法を説明するサイトがすぐに見つかります。 次の予防作業中に、これらすべてを実行し、特定の量のトラフィックがリダイレクトされることを確認しますが、私たちが望むほど多くはありません。 チャンネルで次に予定されている作業を待って、さらにいくつかのプリペンドを設定します。 すべてを再度起動すると、...ほとんど何も変わっていないことがわかります。 なぜそう prependが常に効果的ではない理由はいくつかあります。 しかし、これは主にインターネット自体の動作方法によるものです。 ネットワークの例として、以下の画像をご覧ください。









AS65000にいて、チャネル65001-> 65000と65004-> 65000の間でトラフィックのバランスをとろうとしています。 このプロバイダーがより多くのトラフィックを送信するため、AS65001のprependを構成したとします。 AS65003がAS65001とAS65004からのルートを等しい条件で受け入れると仮定します。 prependをセットアップすることにより、AS65003の観点からAS65000でネットワークへのルートを作成し、AS65001を介してより長く見えるようにしました。 ここでは、最初のプリペンドが機能します。



しかし、別のプリペンドを追加するとどうなりますか？ 何らかの形でトラフィックフローに影響しますか？ AS65003には、宛先へのパスが2つしかありません。1つはAS65001を経由し、もう1つはAS65004を経由します。 彼は、これら2つのルートのうち1つだけを選択できます。 ここで1つの前置詞が機能した場合、2番目の前置詞は何もしません。 これにより、prependを使用した最初の問題が発生します。これは、現実的なAS-Pathパラメーター内で指定した場合にのみ有効です。 このネットワークにさらに256個のプリペンドを追加しても、最初のプリペンドよりも大きな効果はありません。



prependを使用することの有効性がネットワーク上のルートの全長に関連する場合、最初に尋ねる質問は、インターネット上のルートの平均の長さです。 そのような測定を定期的かつかなりの期間（インターネットの標準により）実施している組織があることが判明しました。 たとえば、CAIDA、RIPE、およびPotarooのアナリストは、Internet Default-Free Zone（DFZ）からの大規模な測定値を取得しています。 1998年以降のDFZのASパスの平均長のグラフは次のとおりです 。









ご覧のとおり、ASパスの平均の長さは、ルートと接続された自律システムの数が同時に劇的に増加したにもかかわらず、過去8年間でほとんど変化していません。 これにより、ほとんどの場合、最初のASパスの前置が最大の効果を持ち、2番目のASが前ほど効果が少なく、残りはすべて美しさのためだけであることは明らかです。



prependがまったく機能しない理由は2つあります。



最初：AS65001とAS65004の間の接続を確立します。 私たちは、それらの間に何らかの種類のピアツーピア関係があることを知っています：おそらく支払いあり、おそらくなし-これは私たちには知られていません。 ただし、AS65001は、AS65004から受信した同じルートよりも、ユーザーから受信したルートを常に優先することを確信しています。 また、この設定はLOCAL_PREFを介してAS65001に対して設定され、常にAS-Path Prependよりも高い優先度を持ちます。 結論は？ どのように試行しても、prependを使用してパス65004-> 65001にトラフィックを誘導することはできません。



2番目：隅にあるAS65002に注意してください。 AS65001は常に、クライアント自体から受信したクライアントへのルートを優先します。 したがって、上記に加えて、AS65001の代わりにAS65002からAS65004を介してトラフィックを取得することもできません。



prependが常に機能しない理由がわかったので、次に何ができるか考えてみましょう。



どうする



AS-Pathの追加が役に立たないと判断した場合、次のステップは何ですか？



ルーティングは、宛先アドレスに一致する最長のプレフィックスを選択することに基づいています。 これは、AS-PATHに関係なく、BGPルートを比較する場合に当てはまります。 したがって、ここでのオプションの1つは、アドレス空間をより長いアドバタイズされたプレフィックスに分割し、上位プロバイダーのそれぞれに一部をアナウンスすることです（ フォールトトレランスを確保するために、最初の-BGP条件付きアドバタイズメント機能-約 ）。 図 図3は、AS65000が/ 44 IPv6プレフィックスを2つに分割し、それぞれAS65001とAS65004にアナウンスすることを示しています。これが、AS65000サブネットトラフィックの半分が1つの特定プロバイダーから来る理由です。 この手法をAS-Path prependと組み合わせて使用​​すると、負荷をより効率的に分散できます。









より長いプレフィックスを使用して優先インバウンドチャネルにトラフィックを誘導することは、すでに着信トラフィックの望ましいパターンを形成するための良いステップです。 一部のシナリオでは、よりきめ細かな制御が必要です。



しかし、ASNに長いプレフィックスを作成する機能がない場合（たとえば、IPv4の場合は/ 24、IPv6の場合は/ 48など）はどうでしょうか。 このような場合、BGPコミュニティ属性が役立ちます。 コミュニティを使用すると、優れたプロバイダーとそのピアのネットワーク内でASNが発表される方法に影響を与えることができます。 例は図に見ることができます。 4. AS65002-65001内のルーティングポリシーに従って、クライアントAS65001は、クライアントから受信したプレフィックスがBGPピアから受信したプレフィックスより優先されます。 これは、AS65001用にチャネルからASプリペンドが発表されたにもかかわらず、AS65002は引き続き1ギガビットチャネルを使用することを意味します。 AS65002から大量のトラフィックが送信されると、AS65001を介した着信接続で輻輳が発生する場合があります。 BGPコミュニティを使用すると、独自のポリシーにもかかわらず、AS65001にトラフィックを誘導するAS65001を作成できます。









ほとんどのプロバイダーには、そのようなタスクにどのコミュニティを受け入れて使用するかを示す文書があります。RFC1998に示されているように、プロバイダーを使用するコミュニティはほとんどありません。 たとえば、これはL3に関する古いドキュメントであり、JTプロバイダーが現在使用しているBGPコミュニティポリシーのリストです 。 そのようなことを見つける最良の方法は、プロバイダーに直接尋ねることです。



AS prepend、プレフィックスの分離、およびBGPコミュニティは同時に使用できますが、BGPポリシーをよく検討することが非常に重要です。



より複雑なポリシーが提供する安定性は、障害発生時のシステムの安定性に影響を与えたり、2晩でその論理を理解するのが容易ではない過度の構成の複雑さを生み出したりします。 ポリシーを作成するときにエンジニアが尋ねるべき主な質問は、何かが落ちた場合にどうなるかということです。 図 図から5つのポリシー 3および図 4が同時に適用されます。 すぐに考えるべきこと：

• 長いプレフィックスとともに集約ルートをアナウンスする必要がありますか？ ヒント：この質問に対する答えはほとんど常に肯定的です。
• AS65004には競合する内部ルーティングポリシーがありますか？
• チャネルに障害が発生するとどうなりますか？
• 発信パケットへの応答は、同じチャネル（ステートフルファイアウォールまたはNAT）で返されるべきですか？

問題を解決する前に何を考えるべきですか？



この小さなサイクルは単純な問題から始まりました。インターネットアクセスのある2つのチャネルで着信トラフィックのバランスが取れていない場合の対処方法です。 つまり、BGPで負荷分散を実装する方法。 最初の部分ではAS-Path prependの問題を扱い、2番目の部分では属性コミュニティを分解して使用し、プロバイダーのネットワークのローカル設定を変更しました。



最後の部分では、再び分解に触れます。 より長いプレフィックスを発表することは、ルーティングの「重砲」です。 より多くのプレフィックスが発表されると、注意が必要です。 デフォルトのフリーゾーンはパブリックプロパティです。 インターネット上のルーティングテーブルは誰のものでもありませんが、誰もが使用します。 分解には何もかかりませんが、他のすべての人は支払う必要があります。 ルーティングテーブルに別のルートを追加するのは簡単ですが、追加する長いプレフィックスはインターネット全体に表示されることに注意してください。 問題を解決するために、DFZに接続されている世界中の各ルーターから少量のメモリを支払います。 誰もが考えずに分解し始めると、誰もがより強力なルーターと追加のメモリを購入する必要があります。 あなたを含む。



公共のリソースの使用とその乱用の間には微妙な境界線があります。 誰もが「無料」で公共のリソースを悪用すると、結果はこのリソースにとって悲惨なものになります。 そして、公共財産を破壊したため、元の信頼関係を復元することは非常に困難です。 そのため、分解を設定する前に、それなしでは本当にできないかどうかを考えてください。



これは本当に必要ですか？ これら2つのインバウンドチャネルのバランスを取ることは本当に重要ですか？ たとえば、2つのチャネルを使用するコストや、一方のチャネルでトラフィックを超過するコストなど、経済的な理由があります。 もちろん、これらは単なる仮定にすぎませんが、おそらく、使用可能なチャネルの幅を変更する方が、維持および維持する必要がある技術的なソリューションを導入するよりも合理的です。



設定したものはいつか失敗することを忘れないでください。 また、障害が発生すると、多くの場合、夜間に電話がかかります。 最適化を設定する前に、さまざまなオプションを検討してください。



公共財産への損害を減らすにはどうすればよいですか？









最初の例からネットワークに戻る-AS65001からAS65004にトラフィックを転送するような方法で、これらのプロバイダーが接続している全員のテーブルのサイズに影響を与えずに、分解を実装することは可能ですか？ 実際、ほとんどのプロバイダーは、ASでローカルプリファレンスを設定するために送信するコミュニティを受け入れるだけでなく、ピアへの特定のルートのアナウンスをブロックすることもできます。 これらのコミュニティが着信トラフィックの流れにどのように影響するかを理解するために、これらのコミュニティで少し遊ぶ必要があるかもしれません。 たとえば、特定のプロバイダークライアントグループの同じプレフィックスのアナウンスメントをブロックするのと比較して、上位プロバイダーのトランジットピアへの長いプレフィックスのアナウンスメントをブロックする効果。 このプロバイダーがどのように、どこで接続されているかを直接判断することはできないため、グローバルな影響を最小限に抑えるために彼に連絡して何をどこでアナウンスすべきかを調べるか、さまざまな組み合わせを試してプロセスの最適なオプションを決定することができます。



ピアリングは正しく構成されていますか？ もう1つのオプションは、グローバルネットワークに接続するプロバイダーを介して注意を払うことです。 これが1つの地域プロバイダーと1つのグローバルプロバイダーであるとします。 この場合、どのトラフィックがより多くのトラフィックを送信するかは、クライアントベースに大きく依存します。



たとえば、地域の銀行や医療機関などの地元企業の場合、ほとんどの顧客は（Tier-1ではなく）地域のプロバイダーに接続され、ほとんどの場合、そのチャネルからほとんどのトラフィックを受信します。 あなたのビジネスがそれほどジオリファレンスされていない場合、地域のトラフィックプロバイダーからはそれほど多くの情報は得られません。ほとんどの場合、地域にいる間にネットワークにアクセスする人々からです。 このような場合、これらの2つのチャネルの負荷が不均等になることが予想されます。



これが状況である場合は、2つのプロバイダーとの対話を確立して、顧客により近づけることができます。 顧客が世界中にいる場合は、1つの地域および1つのグローバルよりも、国内またはグローバルレベルで2つのプロバイダーに接続する方が良いでしょう。 可能であれば、さまざまなエンジニアリングトリックに行き、まったく異なるタイプの2つのプロバイダーのネットワークに同じ量のトラフィックを送信させようとするのではなく、顧客が誰で、どのようにそれらをカバーするのが最善かから始めて、着信トラフィックのバランスを取ることをお勧めします。



結論は次のとおりです。エンジニアリングソリューションは、他に何も役に立たない最後の出口であるべきです。 もちろん、私たちは全員エンジニアであり、ハードウェアの購入に費やしたお金を正当化するものはありません。これらのハードウェアのエレガントで膨大なコマンドと構成のセットとして、高チャネル負荷の問題を解決しました。 しかし、それでも、実際のエンジニアリングスキルはソースを見つけることであり、問​​題の本質を掘り下げ、二次的な結果と格闘することではありません。