BGP シグナリングと VPLS のテクニカル ノート
内容
概要
このドキュメントでは、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 つがあります。
- 各 PE ルータが、1 つの BGP アップデートを各 PW のすべての iBGP ネイバーにアドバタイズします。毎回、1 つの MPLS VC ラベルが添付されます。したがって、存在する PE ルータと同じ数の BGP アップデートが 1 台の PE ルータから送信されます。ただし、BGP アップデートに添付される VC ラベルは、PE ルータのうち 1 台だけで使用されます。この PE ルータは、PW の他方の端の PE ルータです。
- 大量の 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 に関連しています。
仮想拡張（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
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
フィードバック