Geekly Articles each Day

BGP Inter-AS

今日は、「オペレーター間」相互作用-BGP Inter-ASについて説明します。 これらのオプションは、異なる自律システムにあるPEルーター間でL3vpnを切り替える必要がある場合に使用されます。 これらのオプションは、ネットワークをマージ/マージするときに企業内で使用されることが多く、独自の自律システムとmplsドメインがある場合、同じ企業のブランチ間の相互作用に使用されることを明確にする価値があります。
この記事では、次のトピックを検討します。
-BGP Inter-ASオプションA
-BGP Inter-ASオプションB
-BGP Inter-ASオプションC
-JunOSでこれらのオプションを設定する機能
この記事は、Cisco CLIとJuniperからの多くの結論になります。 mplsの基本、bgpラベル付きユニキャストとvpnv4ユニキャストの違いがわからない場合、この記事を読むのは意味がありません。 これらの概念がおなじみの場合は、猫をお願いします。

注：上の図では、左側の部分は、Cisco IOS15の右側にあるJunOS（CEを除く）を実行しているルーターで構成されています。

それでは、最も一般的なオプションAから始めましょう。
このオプションの意味は、ASBRで各VPNに対してVRFが作成され、隣接ASからの個別のサブインターフェイスが生成されることです。 このようにして、ASBRはCE-PEルーターとして相互作用し、純粋なIPルートを交換します。 このオプションでは、ASBR間にMPLSはありません-純粋なIPトラフィックのみ：

コントロールプレーンがどのように機能するかを詳しく調べてみましょう。

1. PE1はvpnv4ルートを生成し、MP-BGP経由でルーター（RR1）に送信します。

2. routreflectorにはASBR1とのvpnv4セッションがあり、その中でPE1 vpnv4から受信したルートを提供します。

3. VRFはASBR1（トポロジ、ASBR1 CE1とCE3、およびASBR2-CE2とCE4）でも作成されたため、ルートを受け入れ、対応するvrfのルーティングテーブルにインストールします。

4. ASBR1は、既にクリーンなIPルートをASBR2に転送します（ルーティングプロトコルは、RIPからBGPへの任意のものです）。 これは、CEからPEへの相互作用が機能する場所です。ASBR1はIPプレフィックスを提供するルーターCEとして機能し、ASBR2はルーターのPEとなり、プレフィックスを受信して​​ASのvpnv4プレフィックスを生成します。 （ルートは両側から送信されるため、ASBRはルーターのCEとPEの両方として機能します）。

5. IPプレフィックスを受信するASBR2は、vpnv4プレフィックスを生成し、ルーター（RR2）に送信します。

6. PE2は、vpnv4セッションのルーターからこのプレフィックスを受信し、vrf-importルーターで構成されたルートでネクストホップの到達可能性とrtの一致を確認した後、対応するvrfのルーティングテーブルにインストールします。

それでは、データプレーンに移りましょう。

1. PE1は、CE1からパケットを受信し、ASBR1から受信したラベル（vrfラベル）、ASBR1へのトランスポートラベル（ldp経由で受信）をハングアップさせ、対応するインターフェイスに送信します。

2. 2-xタグのスタックでPE1からパケットを受信したP1は、上位トランスポートラベル（php）を削除し、パケットをASBR1に送信します。

3. ASBR1は1つのラベル（vrfラベル）を持つパケットを受信し、クライアントCEルーターを終了する通常のPEルーターとして機能します-ラベルを削除し、適切なインターフェースにパケットを送信しますASBR2とのジョイントに送信されます。

4. ASBR2はこのパケットを受信し、通常のPEルーターのように機能します。vrfラベル（PE2から受信）、トランスポートラベルをPE2（ldpから受信）に追加し、適切なインターフェイスに送信します。

5. P2は、トランスポートラベル（php）を削除します。

6. PE2は、1つのラベル（それ自体が生成したVRFラベル）を持つパケットを受信し、それを削除し、IPルックアップを行い、対応するVRFのルーティングテーブルに従ってパケットを送信します。

次に、実際にタグを使用して実行される操作を見てみましょう。
ASBRのBGP設定は次のとおりです。
bormoglotx@ASBR1> show configuration routing-instances CE1 instance-type vrf; interface ge-0/0/3.0; route-distinguisher 1:2; vrf-target { import target:1:100; export target:1:100; } vrf-table-label; protocols { bgp { group AS64999 { type external; local-address 10.2.0.1; peer-as 64999; local-as 65000; neighbor 10.2.0.2; } } } 

 ASBR2#sh configuration | b ip vrf ip vrf CE2 rd 2:2 route-target export 2:100 route-target import 2:100 ASBR2#sh configuration | b address-family ipv4 address-family ipv4 vrf CE2 no synchronization neighbor 10.2.0.1 remote-as 65000 neighbor 10.2.0.1 local-as 64999 neighbor 10.2.0.1 activate exit-address-family

ご覧のとおり、通常のPEルーターのように、すべてが犯罪ではありません。

注：ルーティングプロトコルに関してはいくつかのニュアンスがあります。 BGPを使用する場合、2つのクライアントサイトを同じ自律システム番号でリンクする場合、たとえばOSPFがどこにでもある場合は、DNビットを忘れないでください。loops2コマンドを使用する必要があります。 個々のケースは個別に検討する必要があります。

したがって、図に示すように、PE1とASBR1にvrf CE1を、PE2とASBR2にvrf CE2を作成しました。 vpnv4ルートのエクスポートとインポートは、自律システム内のVRFデータ間でのみ可能です。 自律システム間では、ASBR（およびipv4ユニキャストさえ）のみがルートを交換します。 CE1とCE2クライアントルーター間の接続を確認します。
 R5#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/70/84 ms

すべてが順調で、接続性があります。 次に、パッケージの進行に伴ってラベルを使用する操作がどのようになるかを検討します。
それでは、PE1のルートを見てみましょう。
 bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:03:29, localpref 100, from 10.0.10.10 AS path: 65000 64999 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 16, Push 299824(top)

PE1は2つのタグをハングアップします。

16-ASBR1からRR1を介して受信したVRFタグ
299824-ldpプロトコルを介して受信したトランスポートラベル

パケットをP-0に向けてge-0 / 0 / 0.0インターフェイスに送信します。
P1はmpls.0テーブルに従って（中継ルーターであるため）、トップマークを削除し（PHPメカニズムを実行）、このパケットをASBR1に送信します：
 bormoglotx@P1> show route table mpls.0 label 299824 mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299824 *[LDP/9] 00:41:16, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop 299824(S=0) *[LDP/9] 00:41:16, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop

ASBR1はvrfラベルを削除し、CE1.inet.0テーブルでIPルックアップを行います（JunOSでvrf-table-labelコマンドを忘れないでください）：
 bormoglotx@ASBR1> show route table mpls.0 label 16 mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 16 *[VPN/0] 00:35:23 to table CE1.inet.0, Pop bormoglotx@ASBR1> show route table CE1.inet.0 10.0.1.0/24 CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:05:41, localpref 100 AS path: 64999 2 ? > to 10.2.0.2 via ge-0/0/3.0

ASBR1からのパケットは、ge-0 / 0/3インターフェースを介してmplsヘッダーなしでASBR2に送信されます-純粋なipトラフィックのみ（通常はタグ付き、この場合はvrfのみです。複数のvrfがある場合、サブインターフェースを実行しませんでした。 vpnごとに個別のサブインターフェイスを作成し、vrf設定で指定します）。
IPパケットを受信したASBR2は、vrf CE2ルーティングテーブルでルートを探します。
 ASBR2#show ip route vrf CE2 10.0.1.0 Routing Table: CE2 Routing entry for 10.0.1.0/24 Known via "bgp 2", distance 200, metric 0, type internal Last update from 10.1.10.1 00:20:49 ago Routing Descriptor Blocks: * 10.1.10.1 (default), from 10.1.10.10, 00:20:49 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 22 MPLS Flags: MPLS Required 

 ASBR2#sh mpls forwarding-table 10.1.10.1 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 21 18 10.1.10.1/32 0 Gi1/0 10.1.0.2 17 10.1.10.1/32 0 Gi2/0 10.1.2.2

ルートに従って、ASBR2は、PE2からbgp vpnv4から受信したvrf（22）ラベルをハングさせ、PE2（10.1.10.1）上のlspに送信します。 ルートの次のホップはP2またはRR2です（この場合、リフレクターはPルーターのように機能します）。 トラフィックがP2を通過すると想定し、ラベルの付いた操作を監視します。 P2は2つのラベル22および17のパケットを受信し、mpls転送テーブルを検索します。
 P1#sh mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 Pop Label 10.1.10.1/32 18542 Gi1/0 10.1.3.1

mpls転送テーブルによると、P2はトップマークを削除し（再びphp）、パケットをPE2に送信します。

PE2は、このラベルがvrf CE2を指していることを確認し、vrf CE2テーブルでIPルックアップを実行し、クライアントにクリーンなIPパケットを送信します。
 PE2#sh mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 No Label 10.0.1.0/24[V] 14450 aggregate/CE2 PE2#sh ip rou vrf CE2 10.0.1.0 Routing Table: CE2 Routing entry for 10.0.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 2 Advertised by bgp 2 Routing Descriptor Blocks: * directly connected, via GigabitEthernet3/0.10 Route metric is 0, traffic share count is 1

このソリューションが非常に難しいことは明らかです。 新しいクライアントを接続する場合、このクライアントが終了するPEルーターだけでなく、ASBRでもvrfを作成する必要があります（反対側からも同じことをする必要があります）。 当然、このソリューションは通信事業者の今日の要求を満たしていないため、さらに興味深いソリューションであるオプションBおよびCを検討します。

オプションB

ASBRの間でvpnv4セッションが発生し、その中でvpnv4ルートが交換されます（もちろん、余分なものを与えたり与えたりしないように、指定されたプレフィックスと受信されたプレフィックスのASBRでフィルタリングを構成する必要があります）。 ただし、これらのルートの宛先となるVRFがない場合（インポート時にvrfsでNLRIで指定されたルートターゲットが見つからない場合）、ルーターはvpnv4ルートを破棄します（Juniperルーターを除く）。 このデフォルトの動作をASBRに変更するには、すべてのvpnv4ルートを有効にする必要があります（すべて保持-ジュニパー、bgpデフォルトルートターゲットフィルターなし-IOS、ルートターゲットすべてを保持-IOS XR、元のポリシーvpn-ターゲット-Huawei）。

注：Juniperルーターでは、eBGP vpnv4セッションを構成するときに、オプションBのASBR-romと見なされるため、vpnv4ピアから受信したすべてのルートを受け入れてbgp.l3vpn.0テーブルに転送するため、keep allコマンドは不要です。ピアへのルートを指定します。

それでは、コントロールプレーンから始めましょう。

1. PE2はvpnv4ルートを生成し、RR2ルーターに送信します。

2. RR2 Routreflectorは、このルートをすべての顧客に転送します。

3.ルートリフレクタのクライアントであるASBR2は、生成されたPE2 vpnv4ルートを受信します。 オプションno bgp default route-target filterが有効になっているため、ASBR2は受信したルートをルーティングテーブルにインストールします。

4. ASBR2は、ルーターが受信したネクストホップルートを変更し、新しいラベルを生成し（ラベル値は変更されない可能性があります）、ebgp vpnv4セッションによってこのルートをASBR1に送信します。

5. ASBR1はASBR2からvpnv4ルートを受信し、ルーティングテーブルbgp.l3vpn.0にインストールします。

6. ASBR1は、ASBR2から受信したネクストホップルートを自身に変更し、新しいmplsラベルを生成して、指定されたルートをRR1に送信します。

7.このルートを受信したRR1は、ネクストホップ、as-path（最適なbgpルートを選択するための標準メカニズム）の可用性を確認し、このルートをルーティングテーブルにインストールします。

8. RR1は、ASBR1から受信したルートをPE1に送信します。

9. vpnv4ルーターからルートを受信したPE1は、ネクストホップの可用性を確認し、受信したルートのextcommunity（rt）がルーターに設定されたvrf-importと一致するかどうかを確認し、対応するvrfのルーティングテーブルにインストールします。

AS内のASBRへのトランスポートラベルは、標準的な方法（LDPまたはRSVP-TE）で配布されます。

次に、例を挙げて上記を検討します。

PE2 vrf CE2で終了するクライアントプレフィックス10.0.1.0/24のラベル付けがどのように発生するかを考えてみましょう。
 PE2#sh ip route vrf CE2 10.0.1.0 Routing Table: CE2 Routing entry for 10.0.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 2 Advertised by bgp 2 Routing Descriptor Blocks: * directly connected, via GigabitEthernet3/0.10 Route metric is 0, traffic share count is 1

PE2はvpnv4ルートを生成し、iBGPを介してRR2ルートリフレクターに送信します。
 PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 2 Paths: (1 available, best #1, table CE2) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (10.1.10.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 mpls labels in/out 17/nolabel(CE2)

上記の結論によれば、このプレフィックスに対してラベル17が生成されました。mplslabels in / out 17 / nolabel（CE2）
次に、PE2はvpnv4ルートをルーターに送信します。 1つはPE2とCE2の間のネットワークであり、2つ目はCE2クライアントルータのループバックであるため、2つのルートがあります。
 PE2#sh ip bgp vpnv4 all neighbors 10.1.10.10 advertised-routes BGP table version is 39, local router ID is 10.1.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 (default for vrf CE1) *> 10.0.1.0/24 0.0.0.0 0 32768 ? *> 10.1.1.2/32 10.0.1.2 2 32768 ? Total number of prefixes 2

RR2ルーターは、PE2 vpnv4から受信したASBR2などのクライアントへのルートを反映します。
 RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.1.10.3 advertised-routes BGP table version is 21, local router ID is 10.1.10.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 *>i10.0.1.0/24 10.1.10.1 0 100 0 ? *>i10.1.1.2/32 10.1.10.1 2 100 0 ? Total number of prefixes 2

ASBR2はこのルートを受け入れ、ルーティングテーブルにインストールします。
 ASBR2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 4 Paths: (1 available, best #1, no table) Advertised to update-groups: 1 Local 10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 Originator: 10.1.10.1, Cluster list: 10.1.10.10 mpls labels in/out 26/17

「mpls labels in / out 26/17」という行に注目します。 ASBR2はin-26で新しいラベルを生成し、所有するすべてのvpnv4ルート（フィルタリングがoutに設定されている場合はすべてではない）をASBR1上の隣接ASに送信します。
 ASBR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.2.0.1 advertised-routes BGP table version is 13, local router ID is 10.1.10.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 *>i10.0.1.0/24 10.1.10.1 0 100 0 ? *>i10.1.1.2/32 10.1.10.1 2 100 0 ? Total number of prefixes 2

ASBR1はこれらのルートを受け入れ、ルーティングテーブルにインストールします。
 bormoglotx@ASBR1> show route receive-protocol bgp 10.2.0.2 10.0.1.0/24 10.0.1.0/24 detail inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 2:1:10.0.1.0/24 (1 entry, 1 announced) Accepted Route Distinguisher: 2:1 VPN Label: 26 Nexthop: 10.2.0.2 AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

新しいラベルの生成に加えて、ASBR2はネクストホップをそれ自体に変更しました（ネクストホップ：10.2.0.2）。
ASBR1は、プレフィックス10.0.1.0/24の前に新しいラベル（VPNラベル：299888）を生成し、ネクストホップをそれ自体（ネクストホップ：セルフ）に変更し、RR1ルーターへのルートを提供します
 bormoglotx@ASBR1> show route advertising-protocol bgp 10.0.10.10 10.0.1.0/24 detail bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 2:1:10.0.1.0/24 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 2:1 VPN Label: 299888 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [1] 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

RR1 Routreflectorは、PE1を含む顧客にルートを提供します。
 bormoglotx@PE1> show route receive-protocol bgp 10.0.10.10 10.0.1.0/24 detail inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) * 10.0.1.0/24 (1 entry, 1 announced) Import Accepted Route Distinguisher: 2:1 VPN Label: 299888 Nexthop: 10.0.10.3 Localpref: 100 AS path: 2 ? (Originator) Cluster list: 10.0.10.10 AS path: Originator ID: 10.0.10.3 Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) * 2:1:10.0.1.0/24 (1 entry, 0 announced) Import Accepted Route Distinguisher: 2:1 VPN Label: 299888 Nexthop: 10.0.10.3 Localpref: 100 AS path: 2 ? (Originator) Cluster list: 10.0.10.10 AS path: Originator ID: 10.0.10.3 Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

ルートは、vrfテーブルCE1.inet.0とbgpテーブルvpnv4ルートbgp.l3vpn.0の2つのテーブルに表示されます。
JunOSはvpnv4ルートを受信し、その適合性（AS-PATH、ネクストホップの可用性）、インポート用のルーティングインスタンス構成のvpnv4で指定されたエクスコミュニティがあるかどうか、およびルートが検証データを通過し、通常のbgp最適パス選択アルゴリズムに従って最適として選択されているかどうかをチェックします、bgp.l3vpn.0テーブルにインストールされます。 そして、すでにこのIPテーブルから、プレフィックスはvrfテーブル（この場合はCE1.inet.0）に転送されます。

データプレーン：

アラームマーキングを使用して、私たちは把握しました。 次に、データプレーン、つまり、パケットが「mplsクラウド」を介してCE1（10.0.0.2から）からCE2（10.0.1.2）に転送される方法を検討します。
最初に、CEルーター間のpingを開始し、ホスト間に接続があることを確認します。
 CE1#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/91/132 ms

トレースを作成しましょう：
 R5#traceroute 10.0.1.2 numeric timeout 1 Type escape sequence to abort. Tracing the route to 10.0.1.2 1 10.0.0.1 32 msec 4 msec 12 msec 2 10.0.2.2 [MPLS: Labels 299792/299888 Exp 0] 48 msec 68 msec 52 msec 3 10.0.3.1 [MPLS: Label 299888 Exp 0] 48 msec 60 msec 52 msec 4 10.2.0.2 [MPLS: Label 26 Exp 0] 64 msec 52 msec 52 msec 5 10.1.0.2 [MPLS: Labels 19/17 Exp 0] 48 msec 60 msec 52 msec 6 10.0.1.1 52 msec 52 msec 56 msec 7 10.0.1.2 48 msec 64 msec 108 msec

タグの最大数は2であることがわかります。

注：traffic-engineerengを使用する場合、さらに多くの可能性があります。 この場合、ldpのみがラベルを配布します。

次に、パケットがネットワーク上を移動するときのラベル操作を扱います。
クリーンなIPパケットは、CE1クライアントルータからPE1に到着します（この例ではvlanタグ10を使用していますが、l3vpnであり、タグが削除されているため、問題ではありません）。 PE1のルートは、パケットをmplsトンネルに送信する必要があることを示しています。 PE1は2つのラベルをハングさせます：vrfラベルは299888（ASBR1から受け取った）であり、ASBR1へのトランスポートラベルは299792です（ldpプロトコルによって受け取った）：
 bormoglotx@PE1> show route table CE1.inet.0 10.0.1.2 CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:15:32, localpref 100, from 10.0.10.10 AS path: 2 ? to 10.0.2.2 via ge-0/0/0.0, Push 299888, Push 299792(top) > to 10.0.0.2 via ge-0/0/1.0, Push 299888, Push 299792(top) 

 bormoglotx@PE1> show interfaces descriptions Interface Admin Link Description ge-0/0/0 up up to P1 ge-0/0/1 up up to RR1 ge-0/0/3 up up to SW1 lo0 up up router-id

PE1は、このパケットをRR1の方向でge-0 / 0/1インターフェイスに送信します（この場合、ルーターリフレクターはPルーターとしても機能します）。
RR1はラベルスタックのあるパケットを受信し、トップラベル299792を解析します。
 bormoglotx@RR1> show route table mpls.0 label 299792 mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299792 *[LDP/9] 01:19:34, metric 1 > to 10.0.1.1 via ge-0/0/0.0, Pop 299792(S=0) *[LDP/9] 01:19:34, metric 1 > to 10.0.1.1 via ge-0/0/0.0, Pop

mpls.0テーブルによると、RR1はラベル（php）を削除し、ASBR2に向けてge-0 / 0 / 0.0インターフェイスにパケットを送信します。
ASBR2は、299888というラベルが1つだけ付いたパッチを受け取ります。何をすべきかを見ていきます。
 bormoglotx@ASBR1> show route table mpls.0 label 299888 mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299888 *[VPN/170] 00:17:02 > to 10.2.0.2 via ge-0/0/3.0, Swap 26

ASBR1はラベル299888をラベル26にスワップし、ジョイントを介してAS2からASBR2にパケットを送信します。

次に、ASBR2はラベル26もラベル17にスワップします（PE2から受け取った）。
 ASBR2#show ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 4 Paths: (1 available, best #1, no table) Advertised to update-groups: 1 Local 10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 Originator: 10.1.10.1, Cluster list: 10.1.10.10 mpls labels in/out 26/17

したがって、ネクストホップルートは10.1.10.1であるため、ASBR2はトランスポートラベル（19）もPE2に追加する必要があります。
 ASBR2#sh mpls forwarding-table 10.1.10.1 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 23 19 10.1.10.1/32 0 Gi1/0 10.1.0.2 19 10.1.10.1/32 0 Gi2/0 10.1.2.2

パスは同等であるため、パケットはRR2またはP2に送信されます。P2がこのパケットで何を行うかを見てみましょう。
 P1#sh mpls forwarding-table labels 19 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 19 Pop Label 10.1.10.1/32 1180 Gi1/0 10.1.3.1

P2はタグを削除し、単一タグのパケットをPE2に送信します。

PE2は、VRFラベルである単一のラベル17を持つパケットを受信します。 この場合、プレフィックスのラベルの配布が使用されます（1つのラベル-1つのクライアントプレフィックス）。これは実際には無駄であるため、ラベル配布モードを-vrf（vrfの1つのラベル）に切り替える必要があります。 Ciscoとは異なり、JunOSでは、デフォルトのラベル配布メカニズムはネクストホップごとです。 クライアントにイーサネットリンクがあり、これが大部分の場合に自然に発生する場合は、vrf-table-labelコマンドでVRFごとのラベル生成を有効にする必要があります。 この場合のパッケージの処理の原則は変更されており、別の記事に値します。
 PE2#show mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 No Label 10.0.1.0/24[V] 0 aggregate/CE1 PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 2 Paths: (1 available, best #1, table CE1) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (10.1.10.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 mpls labels in/out 17/nolabel(CE1)

上記の情報に従って、PE2はラベル17を削除し、vrfテーブルCE1でipルックアップを行い、パケットをクライアントに送信します。

ASBRの構成：
 bormoglotx@ASBR1# show keep all; group RR { type internal; local-address 10.0.10.3; family inet-vpn { unicast; } export NHS; neighbor 10.0.10.10; } group ASBR-AS2 { type external; local-address 10.2.0.1; family inet-vpn { unicast; } peer-as 2; neighbor 10.2.0.2; } 

 ASBR2#sh configuration | b router bgp router bgp 2 no synchronization no bgp default route-target filter bgp log-neighbor-changes neighbor 10.1.10.10 remote-as 2 neighbor 10.1.10.10 description RR2 neighbor 10.1.10.10 update-source Loopback0 neighbor 10.2.0.1 remote-as 1 neighbor 10.2.0.1 description ASBR1 | AS2 neighbor 10.2.0.1 update-source GigabitEthernet3/0 no auto-summary ! address-family vpnv4 neighbor 10.1.10.10 activate neighbor 10.1.10.10 send-community extended neighbor 10.1.10.10 next-hop-self neighbor 10.2.0.1 activate neighbor 10.2.0.1 send-community extended exit-address-family ASBR2#sh run int gi3/0 Building configuration... Current configuration : 143 bytes ! interface GigabitEthernet3/0 description to ASBR1 | AS1 ip address 10.2.0.2 255.255.255.252 negotiation auto mpls bgp forwarding ! end

オプションBには2つのタイプがあることを付け加えます。最初の方法-最も一般的な方法-を検討しました。ASBRは、自律システム内でルートを転送するとき（ルートをリフレクターに転送するとき）にネクストホップを置き換えます。 2番目の方法は、リフレクターへのルートをアナウンスするときにASBRがibgpセッションのはずなので、ネクストホップをそのアドレスに置き換えなかったことです。 ただし、ASBR間のネットワークはIGPでアナウンスする必要があります（ASBR間のリンクをパッシブにするか、ASBRにスタティックを登録してIGPで再配布できます）。 これは、PEルーターがテーブルへのBGPルートを設定し（ネクストホップの可用性チェック）、ldpがこのプレフィックスにラベルを生成するために必要です。

オプションBで整理されたと思います。 オプションCに進みましょう。

オプションc

vpnv4ルートの交換は、異なるASのルートリフレクター間でebgp-multihopセッションによって直接実行されます。ASBR-riesは、mplsラベルを持つルートを、ルートリフレクターのループバックおよび隣接する自律システムのPEルーターに配布するタスクを持っています。

コントロールプレーンの仕組みを見てみましょう。

ラベル配布：

1. ldpを介したASBR2は、PE2のネイバーからラベルを受信します。

2.設定されたポリシーに従って、ASBR2は自律システムの潤滑油へのラベル付きのルートを生成し、bgpラベル付きユニキャストを介してこれらのルートをASBR1に転送し、ネクストホップルートに自身を示します。

3. ASBR1は、ASBR2からのラベル付きユニキャストルートを受け入れ、mpls転送テーブルにインストールします。

4. ASBR1は、ASBR2から受信したルートのラベルを生成し、ネクストホップ自体を示し、RR1へのルートを提供します。

5.これらのルートを受信したRR1は、ルートの有効性を確認し、ルーティングテーブルにインストールして、他のすべてのクライアントに送信します。

6. PE1は、ラベル付きユニキャストルーターからルートを受信し、検証して、ルーティングテーブルにルートをインストールします。

VRFタグの配布：

1. PE2はvpnv4ルートを生成し、RR2ルーターに送信します。

2. RR2ルーティングリフレクターは、ネクストホップとラベルの値を変更せずに、eBGPマルチホップセッションを介してこのルートをすべてのクライアントとRR1に転送します。

3. RR1は、RR2から受信したルートを、PE1を含むすべてのクライアントに転送します。

4. PE1は、ルートの適合性を確認し、対応するVRFをルーティングテーブルにインストールします。

Vrfタグとトランスポートタグが配布されます。

次に、実際にどのように機能するかを見てみましょう。 まず、自律システム間でループバックルートを配布する必要があります。これは、リモートルートリフレクターへのルートがないため、ルートリフレクター間のvpnv4セッションが増加しないためです。 自律システム間でラベル付きのルートをすぐに配布するため、ASBR間のラベル付きユニキャストセッションのみが存在します（ラベルのないipv4プレフィックスは不要です）。ただし、両方のアドレスファミリが必要な場合は、ラベル付きユニキャストルートをinet.3にインストールする必要があることを指定する必要があります（それ以外の場合、JunOSでは、同じセッションで2つのipv4およびipv4ラベル付きユニキャストアドレスファミリを発生させません）。

ASBR1でのBgp設定（ASBR2とのセッション）：
 bormoglotx@ASBR1> show configuration protocols bgp group ASBR-AS2 type external; local-address 10.2.0.1; family inet { labeled-unicast; } export Lo-export; peer-as 2; neighbor 10.2.0.2; 

 bormoglotx@ASBR1> show configuration policy-options policy-statement Lo-export term 1 { from { protocol isis; route-filter 10.0.10.0/24 prefix-length-range /32-/32; } then accept; } term 2 { then reject;

マーキングシステムがPE2ループバックまでどのように機能するかを見てみましょう。

そのため、自律システム内では、ループバックがAS全体に自動的に分散される前に、ldpが実行され、ラベルがあります。当然、ASBR2には、すべてのAS2ルーターのループバックまでのラベルがあります。これで、ASBR2はASのループバックへのラベル付きのルートを生成し、ASBR1に転送する必要があります。見てみましょう：
 ASBR2#sh ip bgp 10.1.10.1/32 BGP routing table entry for 10.1.10.1/32, version 2 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 2 Local 10.1.0.2 from 0.0.0.0 (10.1.10.3) Origin incomplete, metric 3, localpref 100, weight 32768, valid, sourced, best mpls labels in/out 22/nolabel

出力からわかるように、ASBR2は22に等しいプレフィックス10.1.10.1からinの前にラベルを生成し

ました。ASBR1でこのルートを見てみましょう。
 bormoglotx@ASBR1> show route receive-protocol bgp 10.2.0.2 10.1.10.1/32 detail inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden) * 10.1.10.1/32 (1 entry, 1 announced) Accepted Route Label: 22 Nexthop: 10.2.0.2 MED: 3 AS path: 2 ?

出力ラベル：22およびnext-hop：10.2.0.2（ASBR2インターフェースのアドレス）に関心があります。これで、ASBR1はPE2に到達する方法を認識しました。

さらに、このルートは、ラベル付きユニキャストセッションを介してリフレクタに送信され、そこからPEルータ間の自律システム内に配信されます。ただし、ここに1つのことがあります。ASBR1がASBR2から受信したのと同じ形式でルートを渡す場合、自律システム内のネットワーク10.2.0.0/30（ASBR間のネットワーク）へのルートがないため、機能しません。したがって、ASBR1はネクストホップをそれ自体に変更し、新しいラベルを生成します。
 bormoglotx@ASBR1> show route advertising-protocol bgp 10.0.10.10 10.1.10.1/32 detail inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden) * 10.1.10.1/32 (1 entry, 1 announced) BGP group RR type Internal Route Label: 299920 Nexthop: Self Flags: Nexthop Change MED: 3 Localpref: 100 AS path: [1] 2 ?

次に、PE1でこのルートを見てみましょう。
 bormoglotx@PE1> show route protocol bgp 10.1.10.1/32 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.10.1/32 *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10 AS path: 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top) to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top) inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.10.1/32 *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10 AS path: 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top) to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top)

そうです、ラベル299920はPE2に到達するために使用されます。出力には、別のラベル299776も表示されます。つまり、ラベルのスタックがあります。2番目（299776）の任命は以下に記載されます）。

OK、PE1とPE2の間にエンドツーエンドのlspができました。実際には、RR1とRR2へのルートにもラベルが付けられているため、リフレクター間にはlspもあります。自律システム間でループバックルートを配布した後、ルートリフレクター間で近隣が上昇します。
 bormoglotx@RR1> show bgp neighbor 10.1.10.10 Peer: 10.1.10.10+34875 AS 2 Local: 10.0.10.10+179 AS 1 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Multihop NoNextHopChange Preference LocalAddress Ttl AddressFamily PeerAS Rib-group Refresh> Address families configured: inet-vpn-unicast Local Address: 10.0.10.10 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.1.10.10 Local ID: 10.0.10.10 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-vpn-unicast NLRI advertised by peer: inet-unicast inet-vpn-unicast NLRI for this session: inet-vpn-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality Peer does not support Receiver functionality Peer supports 4 byte AS extension (peer-as 2) Peer does not support Addpath Table bgp.l3vpn.0 Bit: 20001 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 20 Sent 13 Checked 68 Input messages: Total 210 Updates 3 Refreshes 0 Octets 4222 Output messages: Total 212 Updates 2 Refreshes 0 Octets 4205 Output Queue[1]: 0

Vpnv4ルートは、リフレクター間で配布されます。このセッションのNLRI：inet-vpn-unicast。
近隣から2つのプレフィックスを受け入れます：受け入れられたプレフィックス：2
そして、同じ量を与えます：広告されたプレフィックス：2
これは理解できると思います。

リフレクター設定：
 bormoglotx@RR1# show protocols bgp group RR-AS2 type external; multihop { ttl 5; no-nexthop-change; } local-address 10.0.10.10; family inet-vpn { unicast; } peer-as 2; neighbor 10.1.10.10; 


 RR2#sh configuration | b router bgp router bgp 2 bgp log-neighbor-changes neighbor 10.0.10.10 remote-as 1 neighbor 10.0.10.10 ebgp-multihop 5 neighbor 10.0.10.10 update-source Loopback0 ! address-family vpnv4 neighbor 10.0.10.10 activate neighbor 10.0.10.10 send-community extended neighbor 10.0.10.10 next-hop-unchanged exit-address-family

注：RR2構成（Cisco IOS15）では、出力サイズを削減するために、10.0.10.10以外の行が削除されます。

これで、vrfラベル配布の仕組みを確認できます

。PE2は10.0.1.0/24ネットワークへのルートを生成し、vrf CE1で終端します
 PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 2 Paths: (1 available, best #1, table CE1) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (10.1.10.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 mpls labels in/out 22/nolabel(CE1)

ご覧のとおり、ラベル22が生成されました。

次に、ルートがRR2に与えられます。
 PE2#sh ip bgp vpnv4 all neighbors 10.1.10.10 advertised-routes BGP table version is 7, local router ID is 10.1.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 (default for vrf CE1) *> 10.0.1.0/24 0.0.0.0 0 32768 ? *> 10.1.1.2/32 10.0.1.2 2 32768 ? Total number of prefixes 2

ルートリフレクタは、RR1だけでなく、すべての顧客にこのルートを提供します。
 RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.0.10.10 advertised-routes BGP table version is 5, local router ID is 10.1.10.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 *>i10.0.1.0/24 10.1.10.1 0 100 0 ? *>i10.1.1.2/32 10.1.10.1 2 100 0 ? Total number of prefixes 2

RR1で受信したルートを見てみましょう。
 bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)

ルートは非表示になり、配布されなくなりました。質問は-なぜですか？（さらに、シスコにはそのような災害はありません）
 bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 2:1:10.0.1.0/24 [BGP/170] 00:29:12, localpref 100, from 10.1.10.10 AS path: 2 ? Unusable

その理由を見てみましょう：
 bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden detail bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) 2:1:10.0.1.0/24 (1 entry, 0 announced) BGP Preference: 170/-101 Route Distinguisher: 2:1 Next hop type: Unusable Address: 0x8f3c5a4 Next-hop reference count: 2 State: <Hidden Ext> Local AS: 1 Peer AS: 2 Age: 31:00 Task: BGP_2.10.1.10.10+34875 AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 Accepted VPN Label: 22 Localpref: 100 Router ID: 10.1.10.10

Next hop typeの反対側の出力はUnusableです。ルートリフレクターは、ネクストホップの可用性についてルートをチェックしましたが、ルーティングテーブルで指定されたネクストホップへのルートが見つかりませんでした。

ルーティングテーブルを見てみましょう。
 bormoglotx@RR1> show route 10.1.10.1/32 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.10.1/32 *[BGP/170] 00:33:04, MED 3, localpref 100, from 10.0.10.3 AS path: 2 ? > to 10.0.1.1 via ge-0/0/0.0, Push 299920

ラベルがあってもルートがあります（論理的には、ASBR1からラベル付きユニキャストに配布しました）。実際、JunOSには（他のベンダーとは異なり）いくつかのルーティングテーブルがあります。ここで、テーブルinet.0およびinet.3に注目します。

inet.0は、ipv4ユニキャストルートが保存されるルーティングテーブルです。

inet.3-ipv4 mplsルートが保存されるルーティングテーブル。ルータは、入力LSRである場合、このテーブルを使用します。

vpnv4ルートを受信するBGPは、inet.3テーブルのネクストホップの解決を試みます。デフォルトでは、bgpラベル付きユニキャストルートはinet.0テーブルにインストールされ、inet.3には分類されません。つまり、ルートリフレクタはvpnv4ルートを受信し、ネクストホップを解決しようとしますが、inet.3テーブルでそのルートへのルートを見つけられず、使用できないネクストホップによりvpnv4ルートを非表示としてマークします。

この動作を変更する必要があります。彼のためにいくつかのレバーがあります。

RESOLVE-VPNは -このコマンドは、JUNOS標識、ユニキャストルーティングテーブル内のルートを設置に関するデフォルトの動作を変更します。これで、JunOSはbgpラベル付きユニキャストルートをinet.0テーブルとinet.3テーブルの両方にインストールします。

リブグループ-非常に柔軟なメカニズムで、ポリシーを使用して特定のルート（肉の中の/ 32プレフィックス）をあるルーティングテーブルから別のルーティングテーブル（この場合、inet.0からinet.3）にドラッグできますが、リブグループには注意する必要があります。何をしているのかを明確に理解することなくfireを壊すことができます（rib骨グループの可能性は非常に大きいです）。

resolution rib bgp.l3vpn.0 resolution-ribs inet.0-このコマンドを使用すると、どこにも何も転送できませんが、inet.0テーブル内のvpnv4ルートのみをルーターに強制的に解決させます。

ルータでは、コマンド解決リブを指定し、PEルータではresolve-vpnを指定します。
 bormoglotx@RR1# show routing-options router-id 10.0.10.10; autonomous-system 1; resolution { rib bgp.l3vpn.0 { resolution-ribs inet.0; } }

これで、リフレクター上のルートが表示され、自律システム内で配布できます。
 bormoglotx@RR1> show route receive-protocol bgp 10.1.10.10 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 2:1:10.0.1.0/24 * 10.1.10.1 2 ? 2:1:10.1.1.2/32 * 10.1.10.1 2 ?

詳細とともにルート自体を見てみましょう：
 bormoglotx@RR1> show route protocol bgp rd-prefix 2:1:10.0.1.0/24 detail bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 2:1:10.0.1.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 2:1 Next hop type: Indirect Address: 0x934d6d8 Next-hop reference count: 1 Source: 10.1.10.10 Protocol next hop: 10.1.10.1 Push 22 Indirect next hop: 2 no-forward State: <Active Ext> Local AS: 1 Peer AS: 2 Age: 11:55 Metric2: 1 Task: BGP_2.10.1.10.10+34875 Announcement bits (1): 0-BGP_RT_Background AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 Accepted VPN Label: 22 Localpref: 100 Router ID: 10.1.10.10

結論は、自律システムの境界を越えてもネクストホップが変化しないことを示しています。これはebgpには一般的ではありません。実際には、構成（上記）にはno-nexthop-changeコマンドがあります-JunOS、next-hop-unchanged-Cisco、ebgpの標準動作を変更し、自律システムの境界を越えるときのネクストホップの変更を許可しません。これは何のためですか？このコマンドを指定しない場合、すべてのvpnv4ルートでルーターは次のホップに進みます。つまり、すべてのvpnトラフィックがルーターを通過しますが、これは人生でそれほど甘くないです。現在、多数のルートを消化することに加えて（特にFVがある場合）、膨大な量のトラフィックを処理する必要があります。実際には、終わりは常に1つです。この回路は、すべての結果を伴うルーターの落下に失敗します。さらに、2つの冗長リフレクターが存在しても、役に立ちません。ただし、トポロジに戻り、PE1でvpnv4ルートを確認します（resolve-vpnコマンドを既に与えたことを忘れないでください。そうしないと、ルートが非表示になります）。
 bormoglotx@PE1> show configuration protocols bgp group RR type internal; local-address 10.0.10.1; family inet { labeled-unicast { resolve-vpn; } } family inet-vpn { unicast; } neighbor 10.0.10.10; 

 bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 detail CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 10.0.1.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 2:1 Next hop type: Indirect Address: 0x934d2e8 Next-hop reference count: 3 Source: 10.0.10.10 Next hop type: Router, Next hop index: 608 Next hop: 10.0.2.2 via ge-0/0/0.0, selected Label operation: Push 22, Push 299920, Push 299776(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Protocol next hop: 10.1.10.1 Push 22 Indirect next hop: 94a0658 262151 State: <Secondary Active Int Ext> Local AS: 1 Peer AS: 1 Age: 39:28 Metric2: 1 Task: BGP_1.10.0.10.10+179 Announcement bits (2): 0-CE1-OSPF 1-KRT AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 Import Accepted VPN Label: 22 Localpref: 100 Router ID: 10.0.10.10 Primary Routing Table bgp.l3vpn.0

次の行に関心があります。
プロトコルネクストホップ：10.1.10.1
プッシュ22
VPNラベル：22

アラームが機能しました。PEルーターとvrfタグの間にlspができました。

データプレーン：

次に、信号経路に沿ってトラフィックがどのように送信されるかを見てみましょう。
まず、CE間の接続を確認します。
 CE1#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/68 ms

素晴らしい。 これでトレースを作成できます。
 R5#traceroute 10.0.1.2 Type escape sequence to abort. Tracing the route to 10.0.1.2 1 10.0.0.1 4 msec 4 msec 8 msec 2 10.0.2.2 [MPLS: Labels 299776/299920/22 Exp 0] 48 msec 48 msec 12 msec 3 10.0.3.1 [MPLS: Labels 299920/22 Exp 0] 76 msec 56 msec 36 msec 4 10.2.0.2 [MPLS: Labels 22/22 Exp 0] 48 msec 12 msec 76 msec 5 10.1.2.2 [MPLS: Labels 17/22 Exp 0] 40 msec 52 msec 44 msec 6 10.0.1.1 44 msec 60 msec 48 msec 7 10.0.1.2 44 msec 56 msec 56 msec

3つのタグのスタックが表示されます。

それで、PE1上のクライアントプレフィックス10.0.1.0/24へのルートを見てみましょう。
 bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:39:25, localpref 100, from 10.0.10.10 AS path: 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 22, Push 299920, Push 299776(top)

PE1は3つのラベルをハングさせます：

22-PE2
299920 からリフレクター
を介して受信したVRFラベル-ASBR1 299776 からルーティングリフレクターを介して受信したPE2ループバックへのラベル-LDPを介して受信したASBR1へのラベル

。 2.2 ge-0 / 0経由/ 0.0
 bormoglotx@PE1> show interfaces descriptions Interface Admin Link Description ge-0/0/0 up up to P1 ge-0/0/1 up up to RR1 ge-0/0/3 up up to SW1 lo0 up up router-id

注：labeled-unicastによってラベルをPE2に配布したため、P1にはPE2に対するラベルがありません。2つのタグを含むパケットを送信すると、P1はこのタグをどうするかを知りません。したがって、ASBR1にもう1つのラベルを追加する必要があります。P1は、隣接ASへのトラフィックであると疑わずにこのトラフィックを処理します（トップラベルでのみ動作します）。つまり、ASBR1がPE2についてlspをトンネリングする前にlspにいます。

P1が受信したパケットをどう処理するかを見てみましょう。
 bormoglotx@P1> show route table mpls.0 label 299776 mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299776 *[LDP/9] 01:13:09, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop 299776(S=0) *[LDP/9] 01:13:09, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop

すべてが論理的で、P1はトップラベルを削除し（phpメカニズム）、2つのラベルのスタックを持つパケットをASBR1に既に送信します。

ASBR1は、トップラベル（PE2の前のラベル）をASBR2から通知されたラベルに交換します。
 bormoglotx@ASBR1> show route table mpls.0 label 299920 mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299920 *[VPN/170] 01:13:51 > to 10.2.0.2 via ge-0/0/3.0, Swap 22

注：非常に明確に判明-ラベル22はAS2によって生成され、PE2が達成されましたが、ラベル22はPE2がVRFラベルとして生成されました。したがって、ASBR1とASBR2の間には、2つの同一のラベル22/22のスタックで送信されるパケットがあります。実際には、これらは2つの異なるラベル（意図したとおり）であり、この場合に同じであるという事実は偶然です。

その後、パケットはASBR2に送られます。
 ASBR2#sh mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 18 10.1.10.1/32 0 Gi1/0 10.1.0.2 17 10.1.10.1/32 13378 Gi2/0 10.1.2.2

ASBR2は、スタックのトップラベルをラベル18または17に交換します（同等のパスがあります）。彼はこれらのラベルをldpプロトコルから取得しました。
 ASBR2#show mpls ldp bindings 10.1.10.1 32 lib entry: 10.1.10.1/32, rev 18 local binding: label: 22 remote binding: lsr: 10.1.10.2:0, label: 17 remote binding: lsr: 10.1.10.10:0, label: 18

パケットがP2に送られ、ASBR2がトップラベルをラベル17にスワップするとします。P2が
何をするかを見てみましょう。
 P1#sh mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 Pop Label 10.1.10.1/32 12936 Gi1/0 10.1.3.1

P2はラベルを削除し、単一ラベル（vrfラベル）を持つパケットをPE2に送信します。
PE2がラベル22のパケットで何を行うかを確認するだけです
。PE1はMPLS転送テーブルを調べ、ラベルを削除し、CE1テーブルでIPルックアップを行い、GigabitEthernet3 / 0.10インターフェイスにパケットを送信します。 CE2：
 PE2#sh mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 No Label 10.0.1.0/24[V] 3296 aggregate/CE1 

 PE2#sh ip route vrf CE1 10.0.1.0 Routing Table: CE1 Routing entry for 10.0.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 2 Advertised by bgp 2 Routing Descriptor Blocks: * directly connected, via GigabitEthernet3/0.10 Route metric is 0, traffic share count is 1

この例では、3つのラベルのスタックを持つスキームを使用しました。 2つのタグのスタックを使用するオプションがあります。違いは、ASBRが受信したルートをIGPに再配布する必要があることです。その後、ldpはラベルを近隣の自律システムのループバックに配布し始めますが、少なくともbgpルートをigpに入れるため、私は個人的にこのオプションが好きではありません。それ以外の場合、すべては上記のものと同様です。

これらのオプションの動作原理を読者に伝え、この記事がl3vpnの問題を診断する際に役立つことを願っています。この記事は非常に大きく、1日以上書かれていました。誰かが何かを追加したい、または何らかの欠陥に気づいたら（結局私は人です）、PMに書いてください。修正して追加します。ご質問がある場合は、コメントを記入してください。可能な場合はお答えします。ご清聴ありがとうございました！

AllTheThingsUndone.

Source: https://habr.com/ru/post/J302600/

More articles:


All Articles