VPLS。 BGPを使用したタグ配布

MPLSに出くわしたエンジニアは、タグをDU（ダウンストリーム非送信請求）とDD（ダウンストリームオンデマンド）の2つの方法で割り当てることができることを知っています。 最初のケースでは、ルーターは、ネクストホップであるプレフィックスまでのすべてのLDPネイバーへのラベルの生成と送信を開始します。 2番目の場合、LSRはプレフィックスの前にラベルを生成し、アップストリームルータの要求時にのみラベルを送信します。 最初のケースの例はLDPプロトコルで、2番目のケースはRSVP-TEです。 また、VPLSではラベルはどのように配布されますか？ それを理解しましょう。

まず、VPLSとは何か、なぜ必要なのか。 バーチャルプライベートLANサービスは、地理的に分散したネットワーク（だけでなく）のLANエミュレーションです。 仮想L2接続は、クライアントの分散サイト（またはデータセンター要素）間に作成されます。その結果、クライアントはプロバイダーのネットワークを（他のサイトが接続されている）スイッチへの接続と見なします。

私はinetzeroのウェブサイトから写真を撮りました。

VPLSには2つの実装があります。 1つの実装では、BGPシグナリング（Compellドラフト）、PEルーター間のターゲットLDPセッションの2番目の設定（Martiniドラフト）が提供されます。

2番目のケースでは、すべてが単純です。 ラベルは、タイプFEC 128のLDPプロトコルのラベルマッピングメッセージを使用して、ダウンストリーム非送信請求の原則に従って配信されます（強調表示された行は生成されたラベルです）。

BGPをアラームとして使用して、VPLSがラベルを配布する方法を理解することはより困難です（Compellドラフト）。 このVPLS実装では、次のタスクにコントロールプレーンを使用します。

1.クライアントサイトが接続されているPEルーターを自動的に検索します。

2.クライアントサイト間で完全に接続されたL2トポロジを実装するためのMPLSラベルの配布。

まず、クライアントサイトが接続されている各PEルーターでVPLSタイプのルーティングインスタンスを作成する必要があります。

routing-instances { vpls-bgp-cutomer1 { instance-type vpls; interface ge-0/0/1.0; route-distinguisher 100:100; vrf-target { import target:1:1; export target:2:2; } protocols { vpls { site-range 5; no-tunnel-services; site ce1 { site-identifier 1; } } } } } 

BGPシグナリングを設定します。 このタイプのVPLSでは、アドレスファミリl2vpnシグナリングを有効にする必要があります。

 root# show protocols bgp group internal { type internal; local-address 10.1.1.1; family l2vpn { signaling; } neighbor 10.3.3.3; } 

クライアント側へのインターフェースを構成します（たとえば、次のように）。

 root# show interfaces ge-0/0/1 vlan-tagging; encapsulation vlan-vpls; unit 0 { encapsulation vlan-vpls; vlan-id 512; family vpls; } 

また、ネットワークコアへのインターフェイス、いわゆるコアフェイスインターフェイスのMTU値を増やすことを忘れないでください。

これで、接続が確立されたかどうかを確認できます。

 root# run show vpls connections Layer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned <- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label MM -- MTU mismatch MI -- Mesh-Group ID not available BK -- Backup connection ST -- Standby connection PF -- Profile parse failure PB -- Profile busy RS -- remote site standby SN -- Static Neighbor VM -- VLAN ID mismatch Legend for interface status Up -- operational Dn -- down Instance: vpls-bgp-cutomer1 Local site: ce1 (1) connection-site Type St Time last up # Up trans 2 rmt Up Jan 16 20:50:51 2016 1 Remote PE: 10.3.3.3, Negotiated control-word: No Incoming label: 262154, Outgoing label: 262145 Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-bgp-cutomer1 local site 1 remote site 2 

ご覧のとおり、接続が確立されています。 次の出力は、OSPFネイバーフッドがクライアントルータ間で上昇し、ループバックへのルートが出現したことを示しています。

 R7(config)# *Jan 16 16:52:54.554: %OSPF-5-ADJCHG: Process 1, Nbr 20.1.1.1 on GigabitEthernet1/0.512 from LOADING to FULL, Loading Done R7(config)#sh R7(config)#do sh ip rou R7(config)#do sh ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is not set 100.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 100.0.0.0/24 is directly connected, GigabitEthernet1/0.512 L 100.0.0.2/32 is directly connected, GigabitEthernet1/0.512 O 100.1.1.1/32 [110/2] via 100.0.0.1, 00:00:54, GigabitEthernet1/0.512 C 100.1.1.2/32 is directly connected, Loopback0 R7(config)#do ping 100.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/40/88 ms 

ネットワークを介して送信されるパケットは、次のようになります（インストールする必要があるMTU、自分で計算できます）。

すべてが機能します。 次に、サイト間でどのタグが配布されているかを見てみましょう。

 Instance: vpls-bgp-cutomer1 Local site: ce1 (1) connection-site Type St Time last up # Up trans 2 rmt Up Jan 16 20:50:51 2016 1 Remote PE: 10.3.3.3, Negotiated control-word: No Incoming label: 262154, Outgoing label: 262145 Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-bgp-cutomer1 local site 1 remote site 2 

 Instance: vpls-bgp-customer1 Local site: ce2 (2) connection-site Type St Time last up # Up trans 1 rmt Up Jan 16 20:50:49 2016 1 Remote PE: 10.1.1.1, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262154 Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-bgp-customer1 local site 2 remote site 1 

この出力行に興味があります：
着信ラベル：262154、発信ラベル：262145

つまり、PE1はラベル262145を使用してCE1からCE2にパケットを送信し、ラベル262154を使用して、PE1はCE2からCE1に向かうパケットを受信します。 しかし、これらのタグはどのように生成および送信されますか？ よく見てみましょう。 これを行うために、PE1とPE2の間のBGPセッショントラフィックのダンプを見てみましょう（現在、BGPセッションはピア間で確立されていますが、実際には、99％のケースでルートリフレクターが使用されています）。

最初のシグナリングタスクは、既知のルートターゲットとルート識別を使用して解決されます。 ダンプの拡張コミュニティラインでは、L3VPNと同様に、ルーティング値をフィルタリングするために使用されるRT値を確認できます。 自動検索では、このタイプのルーティングインスタンスにRD値が構成されている必要があります（ところで、同じVPLSドメイン内で同じになる場合があります）。

ここで、ラベル配布メカニズムの実装方法を理解する必要があります。 私たちにとって興味深いのは、NLRI文字列です。 この行にはいくつかの値が含まれていますが、L3VPNやVPLS LDPシグナリングとは異なり、生成されたラベルの正確な表示はありません。 このフィールドの各値を分析しましょう。

誰もが最初の2つのフィールドを理解していると思います。
RD 100：0.0.0.100はRDです（RDが何であるかは誰もが知っているので、説明する必要はありません）
CE-ID-ネットワーク管理者が設定したサイトIDです。

しかし、次の3つのパラメーターは、馴染みのないものです。 実際、VPLS（Komplekt draft）はタグを一度に1つずつではなく、ブロック内の8（デフォルト）タグのブロックで配布します。 これらのフィールドは、ラベルの分散ブロックを特徴付けます。

Label-Block Offcetは、ラベルベースからのラベルのシフトです。
ラベルブロックサイズ - ラベルブロックのサイズ ; JunOSでは、デフォルトでは8ラベルです。
ラベルベースは、ラベルブロックベースです。

これで数学が始まります。 クライアントのサイトが接続されているPEルーターは、他のすべてのBGP更新PEルーターに次を含むメッセージを送信します。
1. RD
2. CE-ID
3.ラベルブロックオフセット
4.ラベルブロックサイズ
5.ラベルベース

VPLSは他のLSPにネストされたLSPのセットであるため、次のことを知る必要があります。
1.パッケージを任意のサイトに送信するラベル
2.指定されたラベルを持つパケットはどのサイトから到着しましたか

上記のBGPアップグレードメッセージを受信すると、PEルータは次の操作を実行します。 ネイバーから受信したデータを使用：

発信ラベル=リモートサイトのラベルベース-リモートサイトのラベルブロックオフセット+サイトID

この場合、PE2は次の操作を実行します。ベースの値は262153で、ラベルシフトはこの値から減算し（1があります）、この値にそのサイトIDを追加します。 これは、このBGP更新メッセージが到着したサイトへの発信ラベルになります。

CE2からCE1に到達するために、PE2は262153（base）-1（shift）+2（site-id）= 262154というラベルのパケットを送信する必要があります。 出力を確認します。

 Instance: vpls-bgp-customer1 Local site: ce2 (2) connection-site Type St Time last up # Up trans 1 rmt Up Jan 16 20:50:49 2016 1 Remote PE: 10.1.1.1, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262154 Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-bgp-customer1 local site 2 remote site 1 

そうです、発信ラベル262154。指定されたラベル262154のパケットを受信したPE1は、このパケットがCE2サイトのPE2から送信されたことを認識します。

着信ラベルは同じ方法で計算され、ベース値とシフトのみが独自に取得され（他のPEルーター用に生成されます）、必要なPEルーターのサイトIDがサイト識別子として使用されます。

着信ラベル=独自のラベルベース-独自のラベルブロックオフセット+リモートサイトのサイトID

設定を変更して、計算をやり直しましょう。 これで、サイトの最大数は10になり、サイトには識別子9（CE1）と6（CE2）があります（計算が同じになるため、残りの8つのサイトは原則を理解するように構成する意味がありませんが、もっとあります）。 ラベルの値を再度計算してみましょう。 トラフィックダンプを見てみましょう。
PE1からPE2へ：

PE2からPE1へ：

そのようなデータがあります。
PE1から：
RD 100：0.0.0.100
CE-ID 9
ラベルブロックオフセット1
ラベルブロックサイズ8
ラベルベース262169

PE2から：
RD 200：0.0.0.200
CE-ID 6
ラベルブロックオフセット1
ラベルブロックサイズ8
ラベルベース262153

次に、インバウンドラベルとアウトバウンドラベルサイトに必要なものを計算します。

PE1（サイト9）：
サイト6からの着信ラベル：262169-1 + 6 = 174
サイト6への発信ラベル：262153-1 + 9 = 161

PE2（サイト6）：
サイト9からの着信ラベル：262153-1 + 9 = 161
サイト9への発信ラベル：262169-1 + 6 = 174

そして、計算を確認します。

PE1で：

 Instance: vpls-bgp-cutomer1 Local site: ce1 (9) connection-site Type St Time last up # Up trans 6 rmt Up Jan 16 21:10:58 2016 1 Remote PE: 10.3.3.3, Negotiated control-word: No Incoming label: 262174, Outgoing label: 262161 Local interface: lsi.1048833, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-bgp-cutomer1 local site 9 remote site 6 

PE2の場合：

 Instance: vpls-bgp-customer1 Local site: ce2 (6) connection-site Type St Time last up # Up trans 9 rmt Up Jan 16 21:10:53 2016 1 Remote PE: 10.1.1.1, Negotiated control-word: No Incoming label: 262161, Outgoing label: 262174 Local interface: lsi.1048577, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-bgp-customer1 local site 6 remote site 9 

ご覧のとおり、すべてを正しく計算しました。

それでもこのメカニズムがどのように機能するか理解できない場合は、ネタバレの下で面白い写真をお願いします
クライアントにたとえば10個または12個のサイトがある場合、タグの標準ブロックは1つではなく、2つ必要です。 したがって、BGP更新メッセージには、ラベルとベースのシフトにいくつかの値が含まれる場合があります。

さらにもう1つ-JunOSは、2つまたは3つのサイトのみを接続する必要がある場合でも、デフォルトで8タグのブロックを使用します。 ただし、set label-block-sizeコマンドを使用すると、ブロック内のラベルの数を変更できます。 JunOSは、ブロック内で2、4、8、または16個のタグをサポートします。 ただし、すでに実行中のVPLSドメインでこの値を変更すると、このVPLSドメインで確立されたすべての接続が切断され、新しいパラメーターで再確立されることに注意してください。