as-OVERRIDEとALLOWAS-INの違い

はじめに

ALLOWAS-INとas-OVERRIDEは、複数のサイト/PoPsを介してas X(プロバイダなど)が別のAs Y(トランジットオペレータ/バックボーンMPLSなど)に接続されるシナリオで採用できる二つの同様の機能です。 両方の機能をよりよく理解するには、BGPプロトコル(RFC4271)のループの制御がどのように機能するかを分析することが適切です。

BGPプロトコル仕様は、ループ制御と防止のためのいくつかのメカニズムを提供します。 例えば、IBGPシナリオ(すなわち、同じA S内のBGPセッション)では、分割地平線ルールは、ibgpネイバー(A)によってIBGPネイバー(B)に発表された接頭辞が、(B)によって第3のIBGPネイバー(C)に再発表されるのを防止するループ制御および防止機構の1つである。 このルールを”緩和”するために利用可能ないくつかの可能な解決策があります(例えば、Route-Reflectorsを使用することもその1つです)が、この記事では説明しません。

すでにeBGPシナリオ(つまり、異なるAce間のBGPセッション)では、最も単純なループ制御と防止メカニズムはas_path属性の分析です。 基本的に、eBGPピア(A)がeBGPピア(B)によってアドバタイズされた接頭辞(複数可)のas_path属性内で独自のASNを検出した場合(およびその逆)、ルータは、ルーティングルー ALLOWAS-INとas-OVERRIDEは、この場合に使用できる2つの同様の解決策であり、その時点から、どちらか一方を使用できる状況の種類を詳しく説明します。

ALLOWAS-IN

図1のシナリオで、AS20(プロバイダー)がas10(アップストリーム)トランジットクライアントであるとします。 この性質のトポロジーは、例えば、IP Pop間に物理的な接続がなく、各PoP/地域の加入者にインターネットアクセスを提供するために上流からIP transitを購入する必要があるインターネットプロバイダーでは、ある程度の頻度で発生する可能性があります。

図1:異なる場所にある2つのPopでISP/上流(as10)に接続されたクライアント(AS20)。

このシナリオでは、R2はアップストリームのプレフィックス10.0.0.0/24を発表し、そのプレフィックスのas_pathはアップストリームルーターで次のように表示されます。

R1_Upstream#sh ip bgp 10.0.0.0/24 Network Next Hop Metric LocPrf Weight Path*> 10.0.0.0/24 100.64.0.2 100 20 i

BGPプロトコルの”通常の”操作に従います(フィルタ、ルーティングポリシーなどを無視します)。).)、接頭辞のas_path属性は、ピアに向けて再アドバタイズされる前にR1に変更されます。 接頭辞の”new”as-PATHリストは次のようになります:ただし、接頭辞10.0.0.0/24を運ぶBGP更新メッセージがR3に到達すると、r3はその接頭辞のas_path属性に独自のASN(この場合は20)が存在することに気付く これに類似したアラートはR3ルータログで見ることができます(cisco IOSプラットフォーム、デバッグモード):

これはALLOWAS-INがこの制限を緩めるために演劇に ALLOWAS-INは、プロバイダーのルーター、この場合はR3で構成されます。 その効果は、単にBGPが上流から受信した接頭辞のas_pathに独自のASが存在する可能性を受け入れることです。

ほとんどのプラットフォーム(Cisco、Juniperなど)では、

これは、受信したプレフィックスに関連付けられたas_path属性内で、自身のASNが許容される最大発生回数です。 たとえば、Cisco IOSでは、ピアeBGP1.1.1.1(R1_Upstream)を介して受信したルート更新で、最大2倍の独自のASNの発生を許可する場合、設定は次のとおりです。:

R3# conf tR3# (config) router bgp 20R3# (config-router) neighbor 1.1.1.1 allowas-in 2

上記の例では、as-PATHフィールドに最大2つのASNが含まれている接頭辞を学習できるように設定を実行します。 BGPループ制御ルールを緩和することを望むすべてのクライアントルータでALLOWAS-INが設定されなければならないことに注意することは重要です! より完全な例を見てみましょう(およびCisco IOSプラットフォームでデバッグモードが有効になっている場合)。 端末では、プレフィックスとサブネットマスクに関する情報を運ぶデータ構造を含むBGP更新メッセージ(Network Layer Reachability Information-NLRI)を非常に明確に見ることができます。 以下では、ルータがr1_upstream(neighbor1.1.1.1)によって発表されたプレフィックス10.0.0.0/24のas_path属性でAS20の存在を検出しましたが、neighbor1.1.1.1の”allowas-in”設定によ: すでに述べたように、AS-OVERRIDE機能は、BGPプロトコルループ制御を緩和することである所望の目標に関してALLOWAS-INに非常に似ています。 しかし、この2つの大きな違いは、ループの「原因」ASNの存在を上流自身のASNに置き換えることによって、接頭辞のas_path属性を変更することです。 その結果、as-OVERRIDEは常に上流(サービスプロバイダ)側で設定され、allowas-in設定はすべてクライアント側で実行されます。 また、as-OVERRIDEの使用は、通常、管理対象MPLSネットワーク上のレイヤ3VPN(L3VPN)シナリオに関連付けられていることにも注意してください。 このタイプのシナリオでは、顧客は複数のサイトを持ち、上流のCE(顧客エッジ)とPE(プロバイダーエッジ)の間のルーティングプロトコルとしてBGPを使用し この場合、AS-OVERRIDEがPEルータに適用され、その効果は、MPLSネットワーク内の他のPEに接頭辞が再通知される前に、CE ASNがPE ASNに置き換えられることになります。上の図では、CE/R3ルータはas-PATH属性”20 10″を持つ接頭辞10.0.0.0/24を受け取り、その後、私はそれを閉じるでしょう。すでに前述したbgpループ防止メカニズムによる発表。 ただし、AS OVERRIDE設定がPE1で実行される場合、CE/R3ルータはas-path属性「10 10」の接頭辞10.0.0.0/24を受け取り、従って接頭辞はFIBにインストールされます。 L3VPN内のクライアントプレフィックスの到達可能性を確保するために、すべてのPEルータでAS-OVERRIDEを設定する必要があることを指摘することは非常に重要です。

操作上の観点からは、as-OVERRIDE設定は最新のものでは単純すぎますrouters.As 例は、上記のシナリオのためのCisco IOSの設定を見てみましょう:AS-OVERRIDE設定はPEとCE間のBGPセッションでリセットします。

as-OVERRIDE設定はPEとCE間のBGPセッ 以下では、このVpnv4のCEルータによって発信または発表された接頭辞をチェックすることが可能になります属性AS_PATHにPEのASN(上流)のみが含まれています。

as-OVERRIDEの使用は、パケットの転送における問題や不整合を回避するためによく考え抜かれ、計画されている必要があります。 これらの問題を防ぐための補助的なメカニズムは、BGP拡張コミュニティ「Site of Origin-SoO」を使用して、各VPNクライアントサイトが発信し、L3VPNを介して他のCEに通知するIPプレフィックスを識別することです。 しかし、この記事では、このトピックについては説明しませんし、読者のための追加の研究トピックです。

著者:ダニエルDamitoeウンベルトGaliza

コメントを残す

メールアドレスが公開されることはありません。