Contents

Introduction

Problem

Architecture of the Solution

PE Router Endpoint Identification

VPLS Identity and MPLS Labels

Encapsulation Information

VPLS BGP Auto-Discovery Prefix and VPLS BGP Signaling Prefix

Sample Cisco IOS Software Configuration

Advertised Label Block

Route Distinguisher and Route Targets

Example Configuration of PE1

Check Label Range

Check Labels

Check Label Block

Check Advertised Prefix

View Prefix in Detail

Advertise, Receive, and Process Label Blocks in BGP Update Messages

PE2: Receive BGP Update

PE2: Find a Label

PE2: Send Prefix to PE1

PE1: Find a Label

Additional Verification Commands

Multiple L2VPN VPLS Prefixes Advertised by PE Router for One VFI

PE1 Configuration

PE2 Configuration

Initial Label Blocks

PE1 and PE2 Exchange

Analysis of PE1 and PE2 Exchange

Prefix Details

Interoperability

Introduction

This document describes Border Gateway Protocol (BGP)-based auto-discovery for a Virtual Private LAN Service (VPLS) with BGP signaling. Auto-discovery is a means for a provider edge (PE) to learn which remote PEs are members of a given VPLS domain.Signaling is a means for a PE to learn the pseudowire label expected by a given remote PE for a given VPLS domain.

Refer to these Internet Engineering Task Force documents:

RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling describes BGP auto-discovery with Label Distribution Protocol (LDP) signaling for VPLS (also known as Martini).

RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling describes BGP auto-discovery and BGP signaling for VPLS (also known as Kompella).

This document focuses on RFC 4761. With RFC 4761, the BGP Network Layer Reachability Information (NLRI) of the BGP updates holds the information for both auto-discovery and signaling. When remote PE routers receive this BGP update, they have all the information necessary in order to set up a full mesh of pseudowires for VPLS. BGP auto-discovery and BGP signaling use the same BGP address-family.

The command-line interface (CLI) and output is from Cisco IOS® Software. The configuration and functionality is very similar in Cisco IOS-XR software and Cisco NX-OS software.

Problem

VPLS consists of a set of pseudowires (PW) in a point-to-multipoint fashion. Until now, LDP was used to signal the pseudowires between the PE routers. So, a targeted LDP session signaled which labels to use for which pseudowire between one pair of PE routers. You could manually configure the set of PE routers that participated in one VPLS domain, or you could use BGP to discover the configuration automatically. In order to perform this auto-discovery, BGP advertised which PE was a member of which VPLS domain. However, even with BGP auto-discovery, LDP was used to signal the Multiprotocol Label Switching (MPLS) virtual circuit (VC) labels and pseudowire ID.

It is now possible to use BGP in order to signal the pseudowires between the PE routers.

When one pseudowire is to be set up between a pair of routers, the other routers do not need the information related to this pseudowire. For example, such information is the VC label to be used.

With LDP as the signaling protocol to set up pseudowires, the information is only received by the pair of routers, because LDP does the signaling in a point-to-point fashion.

With BGP as the signaling protocol to set up pseudowires, the information is received by all other routers because internal BGP (iBGP) does the signaling in a point-to-multipoint fashion. iBGP has a full mesh requirement, so one router sends an iBGP update to all other iBGP routers. This could also be done with a route reflector.

With iBGP as the signaling protocol, there would be two methods to send updates:

Each PE router advertises one BGP update to all iBGP neighbors for each PW; each time, one MPLS VC label is attached. Thus, one PE router would send as many BGP updates as there are PE routers. However, the VC label attached to the BGP update could be used by only one of the PE routers - the PE router at the other end of the PW.

To avoid this issue of a high number of BGP updates, an architecture was designed whereby one local PE router sends a set or a block of local VC labels to all remote PE routers. Each remote PE router picks one of the VC labels to use as a remote VC label for the PW toward the local PE router. The remote PE router must pick a remote VC label in a unique fashion so that no other PE router picks the same VC label from the advertised block of labels. Since a block of labels is sent, there must be enough labels available in order to serve all possible PWs that could be set up, but there should not be so many labels reserved that they are unused and wasted.

This document describes how BGP is used in order to signal the pseudowires; note that BGP is also used for auto-discovery at the same time.

Architecture of the Solution

Because this is VPLS, there is still a hop-by-hop signaling protocol needed in the core in order to carry the labeled packets from PE to PE router. This transport function in the core must still be fulfilled by LDP or MPLS traffic engineering.

BGP needs to send the necessary information in order to set up the pseudowires in a point-to-multipoint fashion needed by VPLS. This signaling information includes:

PE router endpoint identification

VPLS identity

Block of MPLS labels

Encapsulation information

PE Router Endpoint Identification

The PE router endpoint identification is determined from the PE router that is the BGP sender of the update.

The BGP update pertaining to Layer 2 Virtual Private Networks (L2VPN) VPLS is identified by AFI/SAFI 25/65. This address family is negotiated when BGP sends the OPEN message.

VPLS Identity and MPLS Labels

The NLRI, also known as the prefix, holds the information on VPLS identity and the block of MPLS labels. Its encoding has a total length of 19 bytes:

      +------------------------------------+
      |  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)             |
      +------------------------------------+

The Route Distinguisher (RD) relates to the identity of the VPLS.

Note: In the Cisco IOS and Cisco NX-OS software implementation, all the PE routers must have the same RD within the same VPLS domain.

The virtual expansion (VE) ID, VE Block Offset, VE Block Size, and the Label Base (LB) relate to the advertised block of labels, as explained in the next section.

Encapsulation Information

Encapsulation information is also attached to the prefix and is encoded as an extended community 'Layer2 Info Extended Community' to the BGP update. The value is 0x800A and is encoded as:

      +------------------------------------+
      | Extended community type (2 octets) |
      +------------------------------------+
      |  Encaps Type (1 octet)             |
      +------------------------------------+
      |  Control Flags (1 octet)           |
      +------------------------------------+
      |  Layer-2 MTU (2 octet)             |
      +------------------------------------+
      |  Reserved (2 octets)               |
      +------------------------------------+

The Encaps Type for VPLS is 19.

The Control Flags (bit vector) is encoded this way:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |   MBZ     |C|S|      (MBZ = MUST Be Zero)
      +-+-+-+-+-+-+-+-+

Name | Value | Meaning
C | 1 | A control word MUST be present when VPLS packets are sent to this PE.
0 | A control word MUST NOT be present when VPLS packets are sent to this PE.
S | 1 | Sequenced delivery of frames MUST be used when VPLS packets are sent to this PE.
0 | Sequenced delivery of frames MUST NOT be used when VPLS packets are sent to this PE.

There are also route targets (RTs) attached to the BGP update. RTs control the import into and export from the L2VPN, in the same manner as MPLS L3VPN.

VPLS BGP Auto-Discovery Prefix and VPLS BGP Signaling Prefix

A VPLS BGP auto-discovery prefix is a /96 prefix, whereas a VPLS BGP signaling prefix is a /136 prefix. These are examples of each:

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

Sample Cisco IOS Software Configuration

This is a sample Cisco IOS software configuration:

!
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

Advertised Label Block

One PE router must advertise at least one label block. The label block is a continuous set of MPLS labels and is used by the remote PE routers in order to select one remote VC label. The remote label is used for the PW between the local and remote PE router. (A PE router can advertise multiple label blocks, as explained in later sections.)

The VE-ID must be configured on each PE. It identifies the PE routers within the VPLS domain.

The VE Block Size (VBS) is the size of the label block and has a default value of 10. If 've range' is configured, it is that value. 've range' can be configured to be [11 -100].

The Label Base (LB) is the first label value of a free set of labels that can be reserved by the PE router to be used for this VPLS domain.

VE Block Offset (VBO) is the offset value to be used when multiple label blocks must be created by a PE router. VBO is calculated with this equation: VBO = RND(VE-ID/VBS) * VBS

These are example calculations:

If VBS = 8 and VE-ID = 2, VBO = RND(2/8) * 8 = 1

If VBS = 8 and VE-ID = 20, VBO = RND (20/8) * 8 = 16

If VBS = 50 and VE-ID = 199, VBO = RND (199/50) * 50 = 150

If VBS = 50 and VE-ID = 1002, VBO = RND (1002/50) * 50 = 1000

The label block advertised to the remote PE routers is {LB, LB + 1, ? , LB + VBS - 1}. The label block is defined by the LB and the VBS; the block starts at LB and ends with (LB + VBS - 1).

Multiple label blocks can be created by each PE router, when needed. The router must ensure that it is a continuous set of free labels.

Route Distinguisher and Route Targets

Example Configuration of 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

This is an explanation of the configuration values:

The VPN ID is configured as 100.

The RD is taken from [ASN:vpn id], unless a RD is explicitely configured. Here, the RD is 1:100.

The import/export route targets are 32:64.

The LB is from the range [10000 20000]. The exact value of LB depends on the first set of free continuous local labels that is large enough to hold all the labels determined by the VBS.

The VE-ID is configured as 1001.

The VBS is configured as 50.

The VBO is calculated to be: VBO = RND(VE-ID/VBS) * VBS or RND(1001/50) * 50 = 1000.

Check Label Range

You can check the label range with the show mpls label range command:

PE1#show mpls label range
Downstream Generic label region: Min/Max label: 10000/20000

There is default label range by platform, which you can change with the mpls label range command.

Check Labels

You can check the actual used labels for one label block in the label forwarding information base (LFIB) with the show mpls forwarding-table command.

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

In this example, PE1, the local router, reserved 50 local labels for the label block. 'lbl-blk-id(1:0)' means a block-id of 1 and a block-instance of 0, which identifies the first label of the block. The last label of this block is label 10049.

The 'Outgoing' interface in the LFIB is 'drop' as long as there is no PW set up for that local label. If a PW is set up, the 'Outgoing' interface is 'none point2point.'

Check Label Block

The assigned label block can also be checked with the show mpls infrastructure lfd block-database summary command when 'service internal' is configured.

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 is 10000. In this example, the label block is from LB to (LB + VBS - 1) or from 10000 to (10000 + 50 - 1) = 10049.

Check Advertised Prefix

You can check the advertised prefix with the show bgp l2vpn vpls rd 1:100 command:

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 ?

View Prefix in Detail

To view this prefix in detail, use the show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000 command. Note that you specify the VE-ID and the label block, which can be found in the 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 shows the RD of 1:100, the VE-ID of 1001, the VBO of 1000, the VBS of 50, and the LB of 10000.

The Layer2 Info Extended Community holds this information:

Encap type is 19 (VPLS)

Control flags: C = 0 (a Control Word must not be set); S = 0 (no sequenced delivery of frames)

MTU is 1500

The RT extended community holds this information:

RT 1:100

RT 32:64

Note: The default VBS (10) is small so that local labels are not wasted.

Advertise, Receive, and Process Label Blocks in BGP Update Messages

When a local PE router advertises a L2VPN VPLS prefix/label block, each remote PE router must try to pick one label from that range in order to use as a remote VC label.

If the remote PE router succeeds, it uses that remote VC label and programs it in the data plane. There is no further signaling by BGP.

If the remote PE router fails, it must wait for another L2VPN VPLS prefix to be advertised by the local PE router, then try to pick another remote VC label from that label block.

Assume that PE1 is a local PE with the previous configuration and that PE2 is a remote PE with this configuration:

l2vpn vfi context one
 vpn id 100
 autodiscovery bgp signaling bgp
  ve id 1002
  ve range 50
!
mpls label range 3000 60000

PE2: Receive BGP Update

PE2 receives this BGP update from PE1:

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: Find a Label

PE2 needs to find a label it can use as a remote VC label for the PW towards PE1.

PE2 must first determine if the VBO is within the range of its configuration. PE2 checks its VE-ID against the range advertised by PE1 with the calculation VBO <= VE-ID < VBO + VBS. In this case, 1000 <= 1002 < 1000 + 50, so PE2 succeeds.

PE2 then needs to pick a remote VC label. The demultiplexer (VC) label to be used by the remote PE is computed as (LB + VE-ID - VBO).

From the earlier prefix, LB is 10000, and VBO is 1000. The VE-ID is the one from PE2 and is 1002. So, PE2 picks label (LB + VE-ID - VBO) = (10000 + 1002 - 1000) = 10002.

Use the show l2vpn vfi name one command in order to verify this:

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: Send Prefix to PE1

PE2 then sends its prefix to 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: Find a Label

PE1 is now the remote PE and needs to find a label it can use as a remote VC label for the PW towards PE2.

PE1 must first determine if the VBO is within the range of its configuration. PE1 checks its VE-ID against the range advertised by PE2 with the calculation VBO <= VE-ID < VBO + VBS. In this case, 1000 <= 1001 < 1000 + 50, so PE1 succeeds.

PE1 then needs to pick a remote VC label. The demultiplexer (VC) label to be used by the remote PE is computed as (LB + VE-ID - VBO).

From the earlier prefix, LB is 3100, and VBO is 1000. The VE-ID is the one from PE1 and is 1001. So, PE1 picks label (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.

Use the show l2vpn vfi name one command in order to verify this:

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

Additional Verification Commands

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

Multiple L2VPN VPLS Prefixes Advertised by PE Router for One VFI

It is possible that one PE might need to advertise multiple label bocks for one virtual forwarding instance (VFI).

If the VE-ID of the remote PE does not fall in the range advertised by the local PE, the remote PE cannot pick a remote label for the PW. This calculation, described earlier, is VBO <= VE-ID < VBO + VBS.

If this check fails, the VE-ID of the remote PE is out of range. The remote PE ignores the prefix received from the local PE. The local PE learns that the remote PE is out of range when it receives the prefix which the remote PE is advertising. The local PE needs to determine what remote label to use for that remote PE router. The local PE also sends a new, second prefix for a new block of local labels to the remote PE, which the remote PE should be able to use in order to select a remote label.

PE1 Configuration

The previous example is continued here; PE1 still has:

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 Configuration

PE2 now has a VE-ID of 1002 and this configuration:

l2vpn vfi context one
 vpn id 100
 autodiscovery bgp signaling bgp
  ve id 10002
  ve range 50
!
mpls label range 3000 60000

Initial Label Blocks

Both PE1 and PE2 start with these initial label blocks.

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 and PE2 Exchange

Use the debug bgp l2vpn vpls updates command in order to review the PE1 and PE2 exchange, then use the show bgp l2vpn vpls rd 1:100 command in order to review details.

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 ?

Analysis of PE1 and PE2 Exchange

PE1 and PE2 now have advertised two label blocks each to each other.

PE1 first advertises an initial BGP update to PE2:

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

This update has the NLRI set according to the configuration on PE1.

PE1 then receives the initial BGP update from PE2.

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 advertises the initial prefix with the values VE-ID 10002, VBO = 10000, VBS = 50, LB = 3000.

PE1 notices that PE2 is out of range since PE1 started off with label block LB to (LB + VBS - 1) or from 10000 to (10000 + 50 - 1) = 10049.

PE1 must determine if the VBO is within the range of its configuration. So, the VE-ID of PE2 needs to be checked against the range advertised by PE1. The calculation is VBO <= VE-ID < VBO + VBS. In this case, 1000 <= 10002 < 1000 + 50, which is not true. So, PE1 needs to send a new label block in order to accomodate the out-of-range VE-ID of PE2. In reaction to the initial update from PE2, PE1 formats and sends a new, additional BGP update to PE2. PE1 now uses a new VBO of 10000.

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

For PE1, the VBO is 10000, VBS is 50, LB is 10053. The check for PE2 is VBO <= VE-ID < VBO + VBS. In this case, 10000 <= 10002 < 10000 + 50, which is true. PE2 is able to pick a remote label from this new label block [10053 - 10102] from PE1. In other words, PE1 added a new label block in order to accommodate PE2 and sent two BGP update messages.

The same happens in the opposite direction. PE2 receives the initial BGP update from PE1. This update has these values VE-ID 1001, VBO = 1000, VBS = 50, LB = 10000.

PE2 notices that VE-ID of PE1 is out-of-range with PE2's initial update. PE1?s check is VBO <= VE-ID < VBO + VBS or 10000 <= 1001 < 10000 + 50. In response, PE2 sends this second BGP update, with a new label block [3053 - 3102] that accommodates the VE-ID of 1001 of PE1 because PE1?s check is VBO <= VE-ID < VBO + VBS or 1000 <= 1001 < 1000 + 50.

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

Prefix Details

These are the details of the two prefixes originated by PE1:

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

Here, two PE routers have discontiguous number schemes, which causes each PE to send out two BGP updates. If there are many PE routers with discontiguous number schemes, the number of BGP updates quickly grows very large.

www.cisco.com says: "For example, VE-ID numbering sequences such as 1, 2, 3 or 501, 502, 503 are good because the VE-IDs are contiguous. A numbering scheme such as 100, 200, 300 is bad because it is non-contiguous."

The first examples of 1, 2, 3 or 501, 502, 503 are contiguous numbers, so each PE router needs to send only one L2VPN VPLS prefix. With the third example (100, 200, 300), each PE has to send out many L2VPN VPLS prefixes. For non-contiguous numbers, a large enough VE range would keep the number of prefixes to be advertised lower. However, the amount of reserved (wasted) labels is still larger.

Interoperability

If the BGP Route Reflector (RR) runs software that does not understand RFC 4761, but does have support for RFC 4762, the special BGP neighbor x.x.x.x prefix-length-size 2 configuration command is needed on the RR so it can reflect the BGP updates used for RFC 4761.

Prefixes are usually sent with a length of 1 byte. Cisco IOS software implemented the draft 'draft-ietf-l2vpn-signaling-08,' which later became RFC 6074. A length field of 1 byte was chosen at the time, indicating the length in bits.

RFC 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) specifies that the NLRI encoding for BGP auto-discovery should be a length of 2 bytes. The 2 bytes indicate how many bytes of prefix follow in variable length prefix.

Section 7 of RFC 6074, "BGP-AD and VPLS-BGP Interoperability," states:

"Both BGP-AD and VPLS-BGP [RFC4761] use the same AFI/SAFI. In order for both BGP-AD and VPLS-BGP to co-exist, the NLRI length must be used as a demultiplexer.

The BGP-AD NLRI has an NLRI length of 12 bytes, containing only an 8-byte RD and a 4-byte VSI-ID. VPLS-BGP [RFC4761] uses a 17-byte NLRI length. Therefore, implementations of BGP-AD must ignore NLRI that are greater than 12 bytes."

If the neighbor x.x.x.x prefix-length-size 2 command is not present on the RRs, the BGP neighbor does not come up, and the RR interprets the length field as 1 byte only. This notification appears on the 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

This notification appears on the PE router:

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

This occurs because, in the original implementation of BGP auto-discovery in Cisco IOS software, the length field was 1 byte.

If you put the neighbor x.x.x.x prefix-length-size 2 command on the RR, the notifications do not appear.

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