内容

概要

問題

ソリューションのアーキテクチャ

PE ルータ エンドポイント ID

VPLS ID および MPLS ラベル

カプセル化情報

VPLS BGP 自動検出プレフィックスと VPLS BGP シグナリング プレフィックス

Cisco IOS ソフトウェアの設定のサンプル

アドバタイズされたラベルのブロック

ルート識別子およびルート ターゲット

PE1 の設定例

ラベル範囲の確認

ラベルの確認

ラベル ブロックの確認

アドバタイズされたプレフィックスの確認

プレフィックスの詳細表示

BGP 更新メッセージのアドバタイズ、受信、およびプロセス ラベル ブロック

PE2：BGP アップデートの受信

PE2：ラベルの検出

PE2：PE1 へのプレフィックスの送信

PE1：ラベルの検出

追加の確認コマンド

1 つの VFI の PE ルータからアドバタイズされた複数の L2VPN VPLS プレフィックス

PE1 の設定

PE2 の設定

最初のラベル ブロック

PE1 と PE2 の交換

PE1 と PE2 の交換の分析

プレフィックス詳細

相互運用性

概要

このドキュメントでは、BGP シグナリングを使用した仮想プライベート LAN サービス（VPLS）の Border Gateway Protocol（BGP）ベースの自動検出について説明します。自動検出は、プロバイダーエッジ(PE)が特定のVPLSドメインのメンバーであるリモートPEを学習するための手段です。シグナリングは、PEが特定のVPLSドメインの特定のリモートPEで期待される疑似配線ラベルを学習するための手段です。

次の Internet Engineering Task Force のドキュメントを参照してください。

- 「RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling」では、VPLS（別名 Martini）のラベル配布プロトコル（LDP）シグナリングを使用する BGP 自動検出について説明しています。

- 「RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling」では、VPLS（別名 Kompella）の BGP 自動検出および BGP シグナリングについて説明しています。

このドキュメントでは、RFC 4761 に焦点を当てて説明しています。RFC 4761 では、BGP 更新の BGP ネットワーク層到達可能性情報（NLRI）は、自動検出およびシグナリングの両方の情報を保持しています。リモート PE ルータがこの BGP 更新を受信する場合、このルータには VPLS の疑似配線でフル メッシュを設定するために必要なすべての情報があります。BGP 自動検出と BGP シグナリングは、同じ BGP アドレス ファミリを使用します。

コマンドライン インターフェイス（CLI）と出力は、Cisco IOS® ソフトウェアのものです。設定と機能は、Cisco IOS-XR ソフトウェアおよび Cisco NX-OS ソフトウェアとよく似ています。

問題

VPLS は、一連のポイントツーマルチポイント方式の疑似配線（PW）で構成されます。これまでは、LDP は PE ルータ間の疑似配線のシグナリングに使用されていました。そのため、宛先の LDP セッションは、PE ルータの 1 つのペア間の疑似配線用に使用されるラベルをシグナリングしていました。1 つの VPLS ドメインに参加する一連の PE ルータを手動で設定したり、BGP を使用して設定を自動的に検出したりできました。この自動検出を行うために、どの PE がどの VPLS ドメインのメンバーなのかを BGP でアドバタイズしました。ただし、この BGP 自動検出が使用されていても、マルチプロトコル ラベル スイッチング（MPLS）の仮想回線（VC）ラベルおよび疑似配線 ID をシグナリングするために、LDP が使用されていました。

現在では、PE ルータ間で疑似配線をシグナリングするために BGP を使用できます。

ペアのルータ間で 1 本の疑似配線をセットアップする場合、他のルータはこの疑似配線に関する情報を必要としません。たとえば、このような情報には、使用される VC ラベルなどがあります。

疑似配線を設定するシグナリング プロトコルとして LDP を使用すると、情報はルータのペアによってのみ受信されます。これは、LDP がシグナリングをポイントツーポイント方式で行うためです。

疑似配線を設定するシグナリング プロトコルとして BGP を使用すると、情報は他のすべてのルータで受信されます。これは、内部 BGP（iBGP）がシグナリングをポイントツーマルチポイント方式で行うためです。iBGP にはフル メッシュの要件があるため、1 台のルータが送信する 1 つの iBGP アップデートが、他のすべてのルータへ送信されます。これは、ルート リフレクタを使用しても実行できます。

シグナリング プロトコルとして iBGP を使用する場合、アップデートを送信する方法には次の 2 つがあります。

1. 各 PE ルータが、1 つの BGP アップデートを各 PW のすべての iBGP ネイバーにアドバタイズします。毎回、1 つの MPLS VC ラベルが添付されます。したがって、存在する PE ルータと同じ数の BGP アップデートが 1 台の PE ルータから送信されます。ただし、BGP アップデートに添付される VC ラベルは、PE ルータのうち 1 台だけで使用されます。この PE ルータは、PW の他方の端の PE ルータです。

2. 大量の BGP アップデートが発生するという問題を回避するために、すべてのリモート PE ルータのローカル VC ラベルのセットまたはブロックが 1 つのローカル PE から送信されるようにアーキテクチャが設計されています。それぞれのリモート PE ルータで、VC ラベルの 1 つが選択され、ローカル PE ルータに対する PW のリモート VC ラベルとして使用されます。リモート PE ルータでは、他の PE ルータがアドバタイズされたラベルのブロックから同じ VC のラベルを選ばないように、一意の方法でリモート VC ラベルを選択する必要があります。ラベルのブロックが送信されるため、セットアップされる可能性のあるすべての PW に対応する十分な数のラベルがあるはずですが、あまりに多くのラベルを予約して、使用せず無駄になってしまうことがないようにしてください。

このマニュアルでは、疑似配線をシグナリングするために BGP がどのように使用されるかを説明します。BGP は同時に自動検出でも使用されることに注意してください。

ソリューションのアーキテクチャ

これは VPLS であるため、PE から PE ルータにラベル付きパケットを伝送するために、コアでは引き続きホップバイホップのシグナリング プロトコルが必要です。このコアでの転送機能は、引き続き LDP または MPLS トラフィック エンジニアリングによって実施される必要があります。

BGP では、VPLS によってポイントツーマルチポイント方式で疑似配線を設定するために必要とされる情報を送信する必要があります。このシグナリング情報には、次のものが含まれます。

- PE ルータ エンドポイント ID

- VPLS ID

- MPLS ラベルのブロック

- カプセル化情報

PE ルータ エンドポイント ID

PE ルータ エンドポイント ID は、BGP アップデートの送信元の PE ルータによって決まります。

レイヤ2バーチャルプライベートネットワーク(L2VPN)VPLSに関連するBGPアップデートは、AFI/SAFI 25/65で識別されます。このアドレスファミリは、BGPがOPENメッセージを送信するとネゴシエートされます。

VPLS ID および MPLS ラベル

プレフィックスとしても知られる NLRI には、VPLS ID および MPLS ラベルのブロックに関する情報が保持されています。このエンコーディングの長さは、次のように合計で 19 バイトです。

+------------------------------------+

|  Length (2 octets)                 |

+------------------------------------+

|  Route Distinguisher  (8 octets)   |

+------------------------------------+

|  VE ID (2 octets)                  |

+------------------------------------+

|  VE Block Offset (2 octets)        |

+------------------------------------+

|  VE Block Size (2 octets)          |

+------------------------------------+

|  Label Base (3 octets)             |

+------------------------------------+

ルート識別子（RD）は、VPLS の ID に関連しています。

注：Cisco IOS および Cisco NX-OS ソフトウェア実装では、同じ VPLS ドメイン内では、すべての PE ルータが同じ RD を持っている必要があります。

仮想拡張（VE） ID、VE ブロック オフセット、VE ブロック サイズ、およびラベル ベース（LB）は、次のセクションで説明するように、アドバタイズされたラベルのブロックに関連しています。

カプセル化情報

カプセル化情報は、プレフィックスにも添付され、拡張コミュニティ「Layer2 Info Extended Community」として BGP アップデートにエンコードされます。値は 0x800A で、次のようにエンコードされます。

+------------------------------------+

| Extended community type (2 octets) |

+------------------------------------+

|  Encaps Type (1 octet)             |

+------------------------------------+

|  Control Flags (1 octet)           |

+------------------------------------+

|  Layer-2 MTU (2 octet)             |

+------------------------------------+

|  Reserved (2 octets)               |

+------------------------------------+

VPLS のカプセル化タイプは 19 です。

コントロール フラグ（ビット ベクトル）は、次のようにエンコードされます。

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|   MBZ     |C|S|      (MBZ = MUST Be Zero)

+-+-+-+-+-+-+-+-+

[名前(Name)]

値

意味

C

1

VPLS パケットがこの PE に送信される場合、コントロール ワードが存在していなければなりません。

0

VPLS パケットがこの PE に送信される場合、コントロール ワードが存在してはなりません。

S

1

VPLS パケットがこの PE に送信される場合、フレームの連続配信を使用しなければなりません。

0

VPLS パケットがこの PE に送信される場合、フレームの連続配信を使用してはなりません。

BGP アップデートに添付されるルート ターゲット（RT）もあります。RT は、L2VPN との間でのインポートとエクスポートを、MPLS L3VPN と同じ方法で制御します。

VPLS BGP 自動検出プレフィックスと VPLS BGP シグナリング プレフィックス

VPLS BGP 自動検出プレフィックスは /96 のプレフィックスですが、VPLS BGP シグナリング プレフィックスは /136 プレフィックスです。以下にそれぞれの例を示します。

PE2#show bgp l2vpn vpls all

BGP table version is 264, local router ID is 10.100.1.2

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,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>i 1:100:VEID-1001:Blk-150/136

10.100.1.1               0    100      0 ?

*>  1:100:10.100.1.2/96

0.0.0.0                            32768 ?

PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 150

BGP routing table entry for 1:100:VEID-1001:Blk-150/136, version 262

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best

AGI version(0), VE Block Size(50) Label Base(10105)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

Originator: 10.100.1.1, Cluster list: 10.100.1.4

rx pathid: 0, tx pathid: 0x0

PE2#show bgp l2vpn vpls rd 1:100 10.100.1.2

BGP routing table entry for 1:100:10.100.1.2/96, version 43

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.2)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local,

best, AGI version(0)

Extended Community: RT:1:100 L2VPN AGI:1:100

rx pathid: 0, tx pathid: 0x0

Cisco IOS ソフトウェアの設定のサンプル

以下に示すのは、Cisco IOS ソフトウェア設定のサンプルです。

!

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp     <<< "signaling ldp" would be RFC 4762

ve id 1001

ve range 50

route-target export 32:64

route-target import 32:64

mpls label range 10000 20000

!

bridge-domain 1

member Ethernet0/0 service-instance 100

member vfi one

!

l2 router-id 10.100.1.1

!

interface Ethernet0/0

no ip address

service instance 100 ethernet

!

!

router bgp 1

bgp log-neighbor-changes

neighbor 10.100.1.4 remote-as 1

neighbor 10.100.1.4 update-source Loopback0

!

address-family l2vpn vpls

neighbor 10.100.1.4 activate

neighbor 10.100.1.4 send-community extended

neighbor 10.100.1.4 suppress-signaling-protocol ldp

exit-address-family

アドバタイズされたラベルのブロック

1 つの PE ルータは少なくとも 1 つのラベル ブロックをアドバタイズする必要があります。ラベル ブロックは連続的な MPLS のラベルのセットであり、リモート PE ルータにより 1 つのリモート VC ラベルを選択するために使用されます。リモート ラベルは、ローカルとリモートの PE ルータ間の PW に使用されます（1 つの PE ルータは、後のセクションで説明するように、複数のラベル ブロックをアドバタイズできます）。

VE-ID は、各 PE 上で設定する必要があります。これにより、VPLS ドメイン内の PE ルータを識別します。

VEブロックサイズ(VBS)はラベルブロックのサイズで、既定値は10です。've range'が設定されている場合、その値になります。「ve range」の設定可能な範囲は、[11 ～ 100] です。

ラベル ベース（LB）は、この VPLS ドメインに使用する PE ルータで予約可能な一連の空きラベルの、最初のラベル値です。

VE ブロック オフセット（VBO）は、複数のラベル ブロックを PE ルータで作成する必要があるときに使用されるオフセット値です。VBO は次の式で計算されます。VBO = RND(VE-ID/VBS) * VBS

以下は計算の例です。

- VBS = 8 および VE-ID = 2 の場合、VBO = RND(2/8) * 8 = 1

- VBS = 8 および VE-ID = 20 の場合、VBO = RND (20/8) * 8 = 16

- VBS = 50 および VE-ID = 199 の場合、VBO = RND (199/50) * 50 = 150

- VBS = 50 および VE-ID = 1002 の場合、VBO = RND (1002/50) * 50 = 1000

リモート PE ルータにアドバタイズされるラベルのブロックは、{LB, LB + 1, ?, LB + VBS - 1} です。ラベル ブロックは LB と VBS によって定義されます。このブロックの先頭は LB で、末尾は（LB + VBS - 1）です。

必要であれば、複数のラベル ブロックを各 PE ルータで作成できます。ルータはこれが連続した空きラベルのセットであることを確認する必要があります。

ルート識別子およびルート ターゲット

PE1 の設定例

router bgp 1

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1001

ve range 50

route-target export 32:64

route-target import 32:64

mpls label range 10000 20000

以下は設定値の説明です。

- VPN ID は 100 に設定されています。

- RDは、明示的に設定されていない限り、[ASN:vpn id]から取得されます。ここでは、RD は 1:100 です。

- インポート/エクスポート ルート ターゲットは 32:64 です。

- LB の範囲は [10000 ～ 20000] です。LB の正確な値は、すべてのラベルを保持するのに十分な大きさがあると VBS が判断した、連続する空きローカル ラベルの最初のセットで決まります。

- VE-ID は 1001 に設定されています。

- VBS は 50 に設定されています。

- VBO は次のようにして計算されます。VBO = RND(VE-ID/VBS) * VBS または RND(1001/50) * 50 = 1000

ラベル範囲の確認

ラベル範囲は、show mpls label range コマンドで確認できます。

PE1#show mpls label range

Downstream Generic label region: Min/Max label: 10000/20000

プラットフォームごとにデフォルトのラベル範囲がありますが、これは mpls label range で変更できます。

ラベルの確認

ラベル転送情報ベース（LFIB）内の 1 ラベル ブロックに実際に使用されているラベルを確認するには、show mpls forwarding-table コマンドを使用できます。

PE1#show mpls forwarding-table

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   Label

Label      or Tunnel Id     Switched      interface

10000      No Label   lbl-blk-id(1:0)  0             drop

10001      No Label   lbl-blk-id(1:1)  0             drop

10002      No Label   lbl-blk-id(1:2)  0             drop

?

10048      No Label   lbl-blk-id(1:48) 0             drop

10049      No Label   lbl-blk-id(1:49) 0             drop

10050      Pop Label  10.100.1.4/32    0             Et1/0      10.1.1.4

この例では、ローカル ルータである PE1 で、ラベル ブロック用に 50 のローカル ラベルが予約されています。「lbl-blk-id(1:0)」は、ブロック ID が 1 であり、ブロック インスタンスが 0 であることを意味しており、このブロックの最初のラベルであることを示しています。このブロックの最後のラベルは、ラベル 10049 です。

LFIB の「Outgoing」インターフェイスは、そのローカル ラベルに PW が設定されていなければ、「drop」になります。PW が設定されている場合には、「Outgoing」インターフェイスは「none point2point」になります。

ラベル ブロックの確認

割り当てられているラベル ブロックは、「service internal」が設定されている場合には、show mpls infrastructure lfd block-database summary コマンド で確認できます。

PE1#show mpls infrastructure lfd block-database summary

Block-DB entry for block-id : 0x1

Block-size : 50, App-Key type : AToM PWID, Labels : 10000 - 10049

LBは10000です。この例では、ラベルブロックはLB ～ (LB + VBS - 1)または10000 ～ (10000 + 50 - 1) = 10049です。

アドバタイズされたプレフィックスの確認

アドバタイズされたプレフィックスは、show bgp l2vpn vpls rd 1:100 コマンドで確認できます。

PE1#show bgp l2vpn vpls rd 1:100

BGP table version is 3, local router ID is 10.100.1.1

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,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-1001:Blk-1000/136

0.0.0.0                            32768 ?

プレフィックスの詳細表示

このプレフィックスを詳細表示するには、show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000 コマンドを使用します。VE-ID およびラベル ブロックを指定することに注意してください。これは NLRI（Blk-1000）にあります。

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000

BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 3

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Advertised to update-groups:

1

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.1)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best

AGI version(0), VE Block Size(50) Label Base(10000)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

rx pathid: 0, tx pathid: 0x0

NLRI は、RD が 1:100、VE-ID が 1001、VBO が 1000、VBS が 50、および LB が 10000 であることを示しています。

Layer2 Info Extended Community には、次の情報が保持されています。

- カプセル化タイプは 19（VPLS）

- コントロール フラグ：C = 0 （コントロール ワードを設定しない）、S = 0（フレームの連続配信なし）

- MTU は 1500

RT Extended Community には、次の情報が保持されています。

- RT 1:100

- RT 32:64

注：ローカル ラベルが無駄にならないように、デフォルトの VBS（10）は少なめになっています。

BGP 更新メッセージのアドバタイズ、受信、およびプロセス ラベル ブロック

ローカル PE のルータが L2VPN VPLS のプレフィックスまたはラベル ブロックをアドバタイズする場合、それぞれのリモート PE ルータは、リモート VC ラベルとして使用するための 1 つのラベルをこの範囲から選択する必要があります。

- この選択を正常に実行したら、リモート PE ルータはそのリモート VC ラベルを使用して、データ プレーン内にプログラムします。BGP によるこれ以上のシグナリング機能はありません。

- ラベルを選択できなかった場合、リモート PE ルータはローカル PE ルータによってアドバタイズされる別の L2VPN VPLS プレフィックスを待機し、そのラベル ブロックから別のリモート VC ラベルを選択する必要があります。

PE1 は前の設定を使用するローカル PE であり、PE2 は次の設定を使用するリモート PE であると想定します。

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1002

ve range 50

!

mpls label range 3000 60000

PE2：BGP アップデートの受信

PE2 は PE1 からこの BGP アップデートを受信します。

PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000

BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 5

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 2

Local

10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best

AGI version(0), VE Block Size(50) Label Base(10000)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

Originator: 10.100.1.1, Cluster list: 10.100.1.4

rx pathid: 0, tx pathid: 0x0

PE2：ラベルの検出

PE2 は、PE1 向けの PW にリモート VC のラベルとして使用できるラベルを見つける必要があります。

PE2 はまず、VBO が設定の範囲内にあるかどうかを判別する必要があります。PE2 は、VBO <= VE-ID < VBO + VBS という計算を使用して、PE1 によりアドバタイズされた範囲に照らして VE-ID を検査します。この場合、1000 <= 1002 < 1000 + 50 であるので、PE2 は問題ありません。

次に、PE2 はリモート VC ラベルを選択する必要があります。リモート PE で使用されるデマルチプレクサ（VC）ラベルは、（LB + VE-ID - VBO）で計算されます。

前述のプレフィックスでは、LB は 10000 で、VBO は 1000 です。VE-ID は PE2 からのもので、1002 です。したがって、PE2 の選択するラベルは、（LB + VE-ID - VBO）=（10000 + 1002 - 1000）= 10002 になります。

これを確認するには、show l2vpn vfi name one コマンドを使用します。

PE2#show l2vpn vfi name one

Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: one, state: up, type: multipoint, signaling: BGP

VPN ID: 100, VE-ID: 1002, VE-SIZE: 50

RD: 1:100, RT: 1:100

Bridge-Domain 100 attachment circuits:

Pseudo-port interface: pseudowire100001

Interface          Peer Address    VE-ID  Local Label  Remote Label    S

pseudowire100002   10.100.1.1      1001   3101         10002           Y

PE2：PE1 へのプレフィックスの送信

次に、PE2 は PE1 にプレフィックスを送信します。

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1002 block-offset 1000

BGP routing table entry for 1:100:VEID-1002:Blk-1000/136, version 4

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.2 (metric 21) from 10.100.1.4 (10.100.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best

AGI version(0), VE Block Size(50) Label Base(3100)

Extended Community: RT:1:100 L2VPN L2:0x0:MTU-1500

Originator: 10.100.1.2, Cluster list: 10.100.1.4

rx pathid: 0, tx pathid: 0x0

PE1：ラベルの検出

ここまでで PE1 はリモート PE になっており、PE2 向けの PW 用にリモート VC ラベルとして使用できるラベルを見つける必要があります。

PE1 はまず、VBO が設定の範囲内にあるかどうかを判別する必要があります。PE1 は、VBO <= VE-ID < VBO + VBS という計算を使用して、PE2 によりアドバタイズされた範囲に照らして VE-ID を検査します。この場合、1000 <= 1001 < 1000 + 50 であるので、PE1 は問題ありません。

次に、PE1 はリモート VC ラベルを選択する必要があります。リモート PE で使用されるデマルチプレクサ（VC）ラベルは、（LB + VE-ID - VBO）で計算されます。

前述のプレフィックスでは、LB は 3100 で、VBO は 1000 です。VE-ID は PE1 からのもので、1001 です。したがって、PE1 の選択するラベルは、（LB + VE-ID - VBO）=（3100 + 1001 - 1000）= 3101 になります。

これを確認するには、show l2vpn vfi name one コマンドを使用します。

PE1#show l2vpn vfi name one

Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: one, state: up, type: multipoint, signaling: BGP

VPN ID: 100, VE-ID: 1001, VE-SIZE: 50

RD: 1:100, RT: 1:100, 32:64

Bridge-Domain 1 attachment circuits:

Pseudo-port interface: pseudowire100001

Interface          Peer Address    VE-ID  Local Label  Remote Label    S

pseudowire100002   10.100.1.2      1002   10002        3101            Y

追加の確認コマンド

PE1#show mpls l2transport vc detail

Local interface: VFI one vfi up

Interworking type is Ethernet

Destination address: 10.100.1.2, VC ID: 100, VC status: up

Output interface: Et1/0, imposed label stack {17 3101}

Preferred path: not configured

Default path: active

Next hop: 10.1.1.4

Create time: 02:06:08, last status change time: 02:06:08

Last label FSM state change time: 02:06:08

Signaling protocol: BGP

Status TLV support (local/remote)   : Not Applicable

LDP route watch                   : Not Applicable

Label/status state machine        : established, LruRru

Last local dataplane   status rcvd: No fault

Last BFD dataplane     status rcvd: Not Applicable

Last BFD peer monitor  status rcvd: Not Applicable

Last local AC  circuit status rcvd: No fault

Last local AC  circuit status sent: No fault

Last local PW i/f circ status rcvd: No fault

Last local LDP TLV     status sent: Not Applicable

Last remote LDP TLV    status rcvd: Not Applicable

Last remote LDP ADJ    status rcvd: Not Applicable

MPLS VC labels: local 10002, remote 3101

Group ID: local 0, remote 0

MTU: local 1500, remote 1500

Control Word: Off

Dataplane:

SSM segment/switch IDs: 8195/4097 (used), PWID: 3

VC statistics:

transit packet totals: receive 0, send 0

transit byte totals:   receive 0, send 0

transit packet drops:  receive 0, seq error 0, send 0

PE1#show mpls infrastructure lfd block-database id 1

Block-DB entry for block-id : 0x1

Block-size : 50, App-Key type : AToM PWID

App-Key entries:

l2ckt(1)  10000

l2ckt(2)  10001

l2ckt(3)  10002

l2ckt(4)  10003

l2ckt(5)  10004

l2ckt(6)  10005

l2ckt(7)  10006

l2ckt(8)  10007

l2ckt(9)  10008

l2ckt(10)  10009

l2ckt(11)  10010

l2ckt(12)  10011

l2ckt(13)  10012

l2ckt(14)  10013

l2ckt(15)  10014

l2ckt(16)  10015

l2ckt(17)  10016

l2ckt(18)  10017

l2ckt(19)  10018

l2ckt(20)  10019

l2ckt(21)  10020

l2ckt(22)  10021

l2ckt(23)  10022

l2ckt(24)  10023

l2ckt(25)  10024

l2ckt(26)  10025

l2ckt(27)  10026

l2ckt(28)  10027

l2ckt(29)  10028

l2ckt(30)  10029

l2ckt(31)  10030

l2ckt(32)  10031

l2ckt(33)  10032

l2ckt(34)  10033

l2ckt(35)  10034

l2ckt(36)  10035

l2ckt(37)  10036

l2ckt(38)  10037

l2ckt(39)  10038

l2ckt(40)  10039

l2ckt(41)  10040

l2ckt(42)  10041

l2ckt(43)  10042

l2ckt(44)  10043

l2ckt(45)  10044

l2ckt(46)  10045

l2ckt(47)  10046

l2ckt(48)  10047

l2ckt(49)  10048

l2ckt(50)  10049

PE1#show l2vpn atom vc destination 10.100.1.2

Service

Interface Dest Address    VC ID      Type   Name                     Status

--------- --------------- ---------- ------ ------------------------ ----------

pw100002  10.100.1.2      100        vfi    one                      UP

PE1#show l2vpn atom vc destination 10.100.1.2 detail

pseudowire100002 is up, VC status is up PW type: Ethernet

Create time: 02:11:13, last status change time: 02:11:13

Last label FSM state change time: 02:11:13

Destination address: 10.100.1.2 VC ID: 100

Output interface: Et1/0, imposed label stack {17 3101}

Preferred path: not configured

Default path: active

Next hop: 10.1.1.4

Member of vfi service one

Bridge-Domain id: 1

Service id: 0xe7000001

Signaling protocol: BGP

Local VE ID: 1001, Remote VE ID: 1002

Status TLV support (local/remote)         : Not Applicable

LDP route watch                         : Not Applicable

Label/status state machine              : established, LruRru

Local dataplane status received         : No fault

BFD dataplane status received           : Not Applicable

BFD peer monitor status received        : Not Applicable

Status received from access circuit     : No fault

Status sent to access circuit           : No fault

Status received from pseudowire i/f     : No fault

Status sent to network peer             : Not Applicable

Status received from network peer       : Not Applicable

Adjacency status of remote peer         : Not Applicable

Bindings

Parameter    Local                          Remote

------------ ------------------------------ ------------------------------

Label        10002                          3101

Group ID     0                              0

Interface

MTU          1500                           1500

Control word off                            off

PW type      Ethernet                       Ethernet

VCCV CV type 0x32                           0x32

LSPV [2], BFD/Raw [5]          LSPV [2], BFD/Raw [5]

BFD/Raw + sig [6]              BFD/Raw + sig [6]

VCCV CC type 0x07                           0x07

CW [1], RA [2], TTL [3]       CW [1], RA [2], TTL [3]

Status TLV   disabled                       N/A

Dataplane:

SSM segment/switch IDs: 8195/4097 (used), PWID: 3

Rx Counters

0 input transit packets, 0 bytes

0 drops, 0 seq err

Tx Counters

0 output transit packets, 0 bytes

0 drops

PE1#show l2vpn signaling rib rd 1:100

+- Origin of entry                                (i=iBGP/e=eBGP)

| +- Provisioned                                  (Yes/No)?

| | +- Stale entry                                (Yes/No)?

| | |

v v v

O P S     RD             VE-ID    VBO     VBS       LB       Next-Hop

-+-+-+-----------------+-------+-------+-------+---------+-----------------+

i Y N  1:100             1002    1000    50      3100       10.100.1.2

PE1#show l2vpn signaling rib rd 1:100 detail

Route 1:100:1002 (epoch:0) from iBGP peer 10.100.1.2

Provisioned (Y) Stale (N)

Route-Target: 1:100

NLRI [FF000001]

VE-ID:1002 VBO:1000 VBS:50 LB:3100

MTU: 1500 Control Word: off

RIB Filter [27000002]

RD: 1:100

VE-ID: 1001, VBO: 1000, VBS: 50 LB: 10000

Forwarder [58000001] VFI one

PE1#show l2vpn atom pwid

AToM Pseudowire IDs: In use: 50, In holddown: 0

Label  Peer-Address    VCID       PWID       In-Use FirstUse ResuedAt FreedAt

------ --------------- ---------- ---------- ------ -------- -------- --------

10000  0.0.0.0         0          1          Yes    00:00:15 Never    Never

10001  0.0.0.0         0          2          Yes    00:00:15 Never    Never

10002  10.100.1.2      100        3          Yes    00:00:15 Never    Never

10003  0.0.0.0         0          4          Yes    00:00:15 Never    Never

10004  0.0.0.0         0          5          Yes    00:00:15 Never    Never

PE1#show l2vpn atom summary

Destination address: 10.100.1.2, total number of vc: 1

0 unknown, 1 up, 0 down, 0 admin down, 0 recovering, 0 standby, 0 hotstandby

1 active vc on MPLS interface Et1/0

1 つの VFI の PE ルータからアドバタイズされた複数の L2VPN VPLS プレフィックス

1 つの PE から 1 つの仮想転送インスタンス（VFI）に対して複数のラベル ブロックをアドバタイズすることが必要になる場合があります。

リモート PE の VE-ID がローカル PE によってアドバタイズされた範囲内にない場合、リモート PE では PW のリモート ラベルを選択できません。先に説明したように、この計算は VBO <= VE-ID < VBO + VBS です。

この確認が失敗すると、リモート PE の VE-ID は範囲外ということになります。リモート PE では、ローカル PE から受信したこのプレフィックスを無視します。ローカル PE は、リモート PE がアドバタイズしているプレフィックスを受信したときに、リモート PE が範囲外であることを認識します。ローカル PE は、このリモート PE ルータに使用するリモート ラベルを決定する必要があります。さらに、ローカル PE は、ローカル ラベルの新しいブロックの新しい 2 番目のプレフィックスをリモート PE に送信します。これはリモート PE がリモート ラベルを選択するために使用できる必要があります。

PE1 の設定

次に示すのは前の例の続きです。PE1 は、次の設定のままです。

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1001

ve range 50

route-target export 32:64

route-target import 32:64

!

mpls label range 10000 20000

PE2 の設定

PE2 は、VE-ID が 1002 になり、次の設定になっています。

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 10002

ve range 50

!

mpls label range 3000 60000

最初のラベル ブロック

PE1 と PE2 の両方とも、先頭は次の最初のラベル ブロックです。

PE1#show bgp l2vpn vpls rd 1:100

BGP table version is 2, local router ID is 10.100.1.1

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,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-1001:Blk-1000/136

0.0.0.0                            32768 ?

PE2#show bgp l2vpn vpls rd 1:100

BGP table version is 3, local router ID is 10.100.1.2

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,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-10002:Blk-10000/136

0.0.0.0                            32768 ?

PE1 と PE2 の交換

PE1 と PE2 の交換を確認するために debug bgp l2vpn vpls updates コマンドを使用した後に、show bgp l2vpn vpls rd 1:100 コマンドを使用して詳細を確認します。

PE1#

%BGP-5-ADJCHANGE: neighbor 10.100.1.4 Up

BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID

1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:

LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100

RT:32:64 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,

localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended

community RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136

BGP(9): bump net 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136, non bpath  added

BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136

BGP(9): best path[0] 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 source

10.100.1.1 nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500

BGP(9): add XC RIB route 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 masklen 136

L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2

RT:1:100

BGP(9): bump net 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136, non bpath  added

BGP(9): nlri update add VBS 50 LB 10053

BGP(9): nlri update add export extcomm count 4

BGPSSA ssacount is 0

BGP(9): update formatted for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 VE ID

10002 VE Block Offset 10000 VE Block Size 50 Label Base 3000 /136

BGP(9): nettable_walker called for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136

BGP(9): nettable_walker 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 route sourced

locally

BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 VE ID

1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:VBS-50:

LB-10053/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100

RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref 100,

metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended community

RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136

BGP(9): bump net 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136, non bpath  added

BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136

BGP(9): best path[0] 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 source 10.100.1.1

nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500

BGP(9): add XC RIB route 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 masklen 136

L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2

RT:1:100

BGP(9): update formatted for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 VE ID

10002 VE Block Offset 1000 VE Block Size 50 Label Base 3053 /136

BGPSSA ssacount is 0

PE1#show bgp l2vpn vpls rd 1:100

BGP table version is 5, local router ID is 10.100.1.1

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,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-1001:Blk-1000/136

0.0.0.0                            32768 ?

*>  1:100:VEID-1001:Blk-10000/136

0.0.0.0                            32768 ?

*>i 1:100:VEID-10002:Blk-1000/136

10.100.1.2               0    100      0 ?

*>i 1:100:VEID-10002:Blk-10000/136

10.100.1.2               0    100      0 ?

PE2#show bgp l2vpn vpls rd 1:100

BGP table version is 6, local router ID is 10.100.1.2

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,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>i 1:100:VEID-1001:Blk-1000/136

10.100.1.1               0    100      0 ?

*>i 1:100:VEID-1001:Blk-10000/136

10.100.1.1               0    100      0 ?

*>  1:100:VEID-10002:Blk-1000/136

0.0.0.0                            32768 ?

*>  1:100:VEID-10002:Blk-10000/136

0.0.0.0                            32768 ?

PE1 と PE2 の交換の分析

ここまでで、PE1 および PE2 は、相互にアドバタイズした 2 つのラベル ブロックを持つようになっています。

最初に、PE1 が、PE2 に対して最初の BGP アップデートをアドバタイズします。

BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID

1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:

LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community

RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

このアップデートには、PE1 の設定に応じて設定された NLRI が含まれます。

次に、PE1 が、PE2 から最初の BGP アップデートを受信します。

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref

100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended

community RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136

PE2 が、VE-ID が 10002、VBO = 10000、VBS = 50、LB = 3000 の値を持つ最初のプレフィックスをアドバタイズします。

PE1 は、PE1 が開始するのがラベル ブロック LB から（LB + VBS - 1）の範囲である、言い替えれば 10000 から（10000 + 50 - 1）= 10049 の範囲であるため、PE2 は範囲外であると検知します。

PE1 は、VBO が設定の範囲内にあるかどうかを判別する必要があります。したがって、PE2のVE-IDをPE1によってアドバタイズされた範囲と照合する必要があります。計算はVBO <= VE-ID < VBO + VBSです。この場合、1000 <= 10002 < 1000 + 50 となり、条件を満たしません。そのため、PE1はPE2の範囲外のVE-IDに対応するために新しいラベルブロックを送信する必要があります。PE2からの初期アップデートに対して、PE1は新しい追加のBGPアップデートをPE2に送信します。

BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136

VE ID 1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:

VBS-50:LB-10053/136, next 10.100.1.1, metric 0, path Local, extended

community RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500

PE1の場合、VBOは10000、VBSは50、LBは10053です。PE2のチェックはVBO <= VE-ID < VBO + VBSです。この場合、10000 <= 10002 < 10000 + 50 となり、条件を満たします。PE2は、PE1からこの新しいラベルブロック[10053 - 10102]からリモートラベルを選択できます。つまり、PE1はPE2に対応するために新しいラベルブロックを追加し、2つのBGP更新メッセージを送信しました。

逆向きでも同じことが起きます。PE2はPE1から初期BGPアップデートを受信します。このアップデートの値は、VE-ID 1001、VBO = 1000、VBS = 50、LB = 10000です。

PE2 は、PE1 の VE-ID が PE2 の最初のアップデートの範囲外であることを検知します。PE1のチェックは、VBO <= VE-ID < VBO + VBSまたは10000 <= 1001 < 10000 + 50です。応答として、PE2は新しいラベルブロック[3053 - 310 2] PE1のチェックがVBO <= VE-ID < VBO + VBSまたは1000 <= 1001 < 1000 + 50であるため、PE1のVE-ID 1001に対応します。

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,

localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4,

extended community RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136

プレフィックス詳細

以下に示すのは、PE1 によって発信される 2 つのプレフィックス詳細です。

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000

BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 2

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.1)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best

AGI version(0), VE Block Size(50) Label Base(10000)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

rx pathid: 0, tx pathid: 0x0

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 10000

BGP routing table entry for 1:100:VEID-1001:Blk-10000/136, version 4

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.1)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best

AGI version(0), VE Block Size(50) Label Base(10053)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

L2VPN L2:0x0:MTU-1500

rx pathid: 0, tx pathid: 0x0

ここでは、2 つの PE ルータが不連続の番号付け方式になっているため、各 PE が 2 つの BGP アップデートを送信することになります。不連続の番号付け方式の PE のルータが数多くある場合、BGP アップデートの数は短時間でかなり大きくなります。

www.cisco.com に、このような記述があります。「たとえば、1、2、3、または 501、502、503 などの VE-ID の番号付けシーケンスは、VE ID が連続しているので問題ありません。100、200、300 などの番号付け方式は、不連続であるためよくありません。」

最初の 1、2、3、または 501、502、503 の例は連続した番号のため、各 PE ルータは L2VPN VPLS プレフィックスを 1 回だけ送信すれば済みます。3 番目の例（100、200、300）では、各 PE は多くの L2VPN VPLS プレフィックスを送信する必要があります。非連続番号に対しては、VE の範囲を十分に大きくすれば、アドバタイズされるプレフィックスの数を少なく抑えることができます。しかし、予約される（浪費される）ラベルの量がさらに多くなります。

相互運用性

BGP ルート リフレクタ（RR）で、RFC 4761 を認識しないものの RFC 4762 をサポートするソフトウェアを実行している場合、RFC 4761 に使用する BGP アップデートを反映できるようにするには、特定の BGP ネイバーの x.x.x.x prefix-length-size 2 コンフィギュレーション コマンドがこの RR 上で必要です。

プレフィックスは通常 1 バイト長で送信されます。Cisco IOS ソフトウェアはドラフト「draft-ietf-l2vpn-signaling-08」を実装していましたが、これが後に RFC 6074 になりました。当時は 1 バイトの長さフィールドが選択され、長さはビット単位で示されていました。

「RFC 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)」では、BGP の自動検出の NLRI エンコードは 2 バイト長とすることが指定されています。 この 2 バイトは、後に続く可変長プレフィックスのバイト数を示します。

RFC 6074 の 7 項「BGP-AD and VPLS-BGP Interoperability」には次のように記載されています。

「BGP-AD と VPLS-BGP [RFC4761] は、両方とも同じ AFI/SAFI を使用します。BGP-AD および VPLS-BGP を共存させるには、NLRI 長をデマルチプレクサとして使用する必要があります。

BGP-AD NLRI の NLRI 長は 12 バイトで、8 バイトの RD および 4 バイトの VSI-ID のみが含まれています。VPLS-BGP [RFC4761] は、17 バイトの NLRI 長を使用します。そのため、BGP-AD の実装では、12 バイトより大きい NLRI は無視する必要があります。」

neighbor x.x.x.x prefix-length-size 2 コマンドが RR 上にない場合、BGP ネイバーは表示されず、RR によって長さフィールドは 1 バイトと解釈されます。次の通知が RR に表示されます。

%BGP-3-NOTIFICATION: sent to neighbor 10.100.1.2 3/10 (illegal network) 1 bytes FF

%BGP-4-MSGDUMP: unsupported or mal-formatted message received from 10.100.1.2:

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 005E 0200 0000 4780 0E1C 0019 4104 0A64

0102 0000 1100 0000 0100 0000 6427 1227 1000 3200 BB80 4001 0102 4002 0080 0404

*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 L2VPN Vpls

topology base removed from session  BGP Notification sent

*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 IPv4 Unicast

topology base removed from session  BGP Notification sent

次の通知が PE ルータに表示されます。

%BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 3/10 (illegal network)

1 bytes FD

これは、Cisco IOS ソフトウェアの BGP 自動検出の最初の実装では、length フィールドが 1 バイトであるためです。

RR 上に neighbor x.x.x.x prefix-length-size 2 コマンドを配置している場合、この通知は表示されません。

router bgp 1

neighbor 10.100.1.2 remote-as 1

neighbor 10.100.1.2 update-source Loopback0

!

address-family l2vpn vpls

neighbor 10.100.1.2 activate

neighbor 10.100.1.2 send-community extended

neighbor 10.100.1.2 prefix-length-size 2

neighbor 10.100.1.2 route-reflector-client