BGP-VPLS
BGP-VPLS
In This Chapter
This section describes advanced BGP VPLS configurations.
Applicability
This example is applicable to all of the 7450-ESS, 7750-SR and 7710-SR series and was tested on
Release 12.0.R1. There are no pre-requisites for this configuration.
Summary
There are currently two IETF standards for the provisioning of Virtual Private LAN Services
(VPLS). RFC 4762, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling, describes Label Distribution Protocol (LDP) VPLS, where VPLS pseudowires are
signaled using LDP between VPLS Provider Edge (PE) routers, either configured manually or
auto-discovered using BGP.
RFC 4761, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,
describes the use of Border Gateway Protocol (BGP) for both the auto-discovery of VPLS PEs and
signaling of pseudowires between such PEs.
The purpose of this section is to describe the configuration and troubleshooting for BGP-VPLS.
Knowledge of BGP-VPLS RFC 4761 architecture and functionality is assumed throughout this
section, as well as knowledge of Multi-Protocol BGP.
Overview
RR-1
192.168.7.2/30 P-1 192.168.0.1/30 PE-1
192.0.2.20 192.168.7.1/30 192.0.2.10 192.168.0.2/30 192.0.2.1
192.168.1.1/30 192.168.2.1/30
192.168.1.2/30 192.168.2.2/30
192.168.4.1/30 192.168.5.1/30
192.168.4.2/30 192.168.5.2/30
BGP_VPLS_01
The network topology is displayed in Figure 36. The configuration uses seven 7750/7450/7710
Service Router (SR) nodes located in the same Autonomous System (AS). There are three
Provider Edge (PE) routers, and RR-1 will act as a Route Reflector (RR) for the AS. The PE
routers are all VPLS-aware, the Provider (P) routers are VPLS unaware and do not take part in the
BGP process.
• ISIS or OSPF on each of the network interfaces between the PE/P routers and RR.
• MPLS should be configured on all interfaces between PE routers and P routers. MPLS is
not required between P-1 and RR-1.
• LDP should be configured on interfaces between PE and P routers. It is not required
between P-1 and the RR-1.
• The RSVP protocol should be enabled.
BGP VPLS
In this architecture a VPLS instance is a collection of local VPLS instances present on a number of
PEs in a provider network. In this context, any VPLS-aware PE is also known as a VPLS Edge
(VE) device.
The PEs communicate with each other at the control plane level by means of BGP updates
containing BGP-VPLS Network Layer Reachability Information (NLRI). Each update contains
enough information for a PE to determine the presence of other local VPLS instances on peering
PEs and to set-up pseudowire connectivity for data flow between peers containing a local VPLS
within the same VPLS instance. Therefore, auto-discovery and pseudowire signaling are achieved
using a single BGP update message.
Each PE within a VPLS instance is identified by a VPLS Edge identifier (ve-id) and the presence
of a VPLS instance is determined using the exchange of standard BGP extended community route
targets between PEs.
Each PE will advertise, via the route reflectors, the presence of each VPLS instance to all other
PEs, along with a block of multiplexer labels that can be used to communicate between such
instances plus a BGP next hop that determines a labelled transport tunnel between PEs.
Each VPLS instance is configured with import and export route target extended communities for
topology control, along with VE identification.
Configuration
The first step is to configure an MP-iBGP session between each of the PEs and the RR.
The configuration for the other PE nodes is very similar. The IP addresses can be derived from
Figure 36.
On PE-1, verify that the BGP session with RR-1 is established with address family l2-vpn
capability negotiated:
On RR-1, show that BGP sessions with each PE are established, and have a negotiated the l2-vpn
address family capability.
148 0
192.0.2.2
65536 167 0 00h25m28s 10/0/24 (L2VPN)
86 0
192.0.2.3
65536 167 0 01h16m16s 7/0/24 (L2VPN)
213 0
-------------------------------------------------------------------------------
A:RR-1#
The MPLS and LSP configuration for PE-2 and PE-3 are similar to that of PE-1 with the
appropriate interfaces and LSP names configured.
Pseudowire Templates
Pseudowire templates are used by BGP to dynamically instantiate SDP bindings, for a given
service, to signal the egress service de-multiplexer labels used by remote PEs to reach the local
PE.
The template determines the signaling parameters of the pseudowire, control word presence,
MAC-pinning, filters etc., plus other usage characteristics such as split horizon groups.
The MPLS transport tunnel between PEs can be signaled using LDP or RSVP-TE.
LDP based pseudowires can be automatically instantiated. RSVP-TE based SDPs have to be pre-
provisioned.
Using this mechanism SDPs can be auto-instantiated with SDP-ids starting at the higher end of the
SDP numbering range, such as 17407. Any subsequent SDPs created use SDP-ids decrementing
from this value.
A pseudowire template is required containing a split horizon group. Each SDP created with this
template is contained within a split horizon group so that traffic cannot be forwarded between
them.
exit
The pseudowire template also has the following options available when used for BGP-VPLS:
• The control word will determine whether the C flag is set in the Layer 2 extended
community and, therefore, if a control word is used in the pseudowire.
• The encap type in the Layer 2 extended community is always 19 (VPLS encap), therefore,
the vc-type will always be ether regardless of the configured value on the vc-type.
• The force-vlan-vc-forwarding command will add a tag (equivalent to vc-type vlan) and
will allow for customer QoS transparency (dot1p+DE bits).
Note that the signaling bgp parameter is required for BGP-VPLS to be able to use this SDP.
Conversely, SDPs that are bound to RSVP-based LSPs with signaling set to the default value of
tldp will not be used as SDPs within BGP-VPLS.
PE-1
SDP
192.0.2.1
RR-1 CE
SDP
192.0.2.20
SDP
PE-3
VPLS 1
192.0.2.3
CE
SDP
SDP
PE-2
SDP 192.0.2.2
CE
BGP_VPLS_02
Figure 37 shows a VPLS instance where SDPs are auto-provisioned. In this case, the transport
tunnels are LDP signaled.
The following output shows the configuration required on PE-1 for a BGP-VPLS service using a
pseudowire template configured for auto-provisioning of SDPs.
The bgp context specifies parameters which are valid for all of the VPLS BGP applications, such
as BGP-multi-homing, BGP-auto-discovery as well as BGP-VPLS.
Within the bgp context, parameters are configured that are used by neighboring PEs to determine
membership of a given VPLS instance, such as the auto-discovery of PEs containing the same
VPLS instance; the route-distinguisher is configured, along with the route target extended
communities.
Route target communities are used to determine membership of a given VPLS instance. Note that
the import route target at the BGP level is mandatory. The pseudowire template bind is then
applied by the service manager on the received routes matching the route target value.
Also within the bgp-vpls context, the signaling parameters are configured. These determine the
service labels required for the data plane of the VPLS instance.
The VPLS edge ID (ve-id) is a numerical value assigned to each PE within a VPLS instance. This
value should be unique for a given VPLS instance, no two PEs within the same instance should
have the same ve-id values.
Note that a more specific route target can be applied to a pseudowire template in order to define a
specific pseudowire topology, rather than only a full mesh, using the command within the bgp
context:
It is also worth noting that changes to the import policies are not taken once the pseudowire has
been setup (changes on route-target are refreshed though). Pseudowire templates can be re-
evaluated with the command tools perform eval-pw-template. The eval-pw-template command
checks whether all the bindings using this pseudowire template policy are still meant to use this
policy.
If the policy has changed and allow-service-impact is true, then the old binding is removed and it
is re-added with the new template.
The max-ve-id value determines the range of the ve-id value that can be configured. If a PE
receives a BGP-VPLS update containing a ve-id with a greater value than the configured max-ve-
id, then the update is dropped and no service labels are installed for this ve-id.
The max-ve-id command also checks the locally-configured ve-id, and prevents a higher value
from being used.
Each PE allocates blocks of labels per VPLS instance to remote PEs, in increments of eight labels.
It achieves this by advertising three parameters in a BGP update message,
This defines a block of labels in the range (LB, LB+1, ..., LB+VBS-1).
As an example, if the label base (LB) = 131055, then the range for the block is 131055 to 131062,
which is exactly eight labels, as per the block size.
The label allocated by the PE to each remote PE within the VPLS is chosen from this block and is
determined by its ve-id. In this way, each remote PE has a unique de-multiplexer label for that
VPLS.
To reduce label wastage, contiguous ve-ids in the range (N..N+7) per VPLS should be chosen,
where N>0.
Assuming a collection of PEs with contiguous ve-ids, the following labels will be chosen by PEs
from the label block allocated by PE-1 which has a ve-id =1.
VE-ID Label
2 131056
3 131057
4 131058
VE-ID Label
5 131059
6 131060
7 131061
8 131062
This shows that the label allocated to a given PE is (LB+veid-1). The “1” is the VE block offset
(VBO).
This means that the label allocated to a PE router within the VPLS can now be written as (LB +
veid - VBO), which means that (ve-id - VBO) calculation must always be at least zero and be less
than the block size, which is always 8.
For the next block of 8 ve-ids (ve-id 9 to ve-id 16) a new block of 8 labels must be allocated, so a
new BGP update is sent, with a new label base, and a block offset of 9.
Table 3 shows how the choice of ve-ids can affect the number of label blocks allocated, and hence
the number of labels:
1-8 1 8
9-16 9 8
17-24 17 8
25-32 25 8
33-40 33 8
41-48 41 8
49-56 49 8
This shows that the most efficient use of labels occurs when the ve-ids for a set of PEs are chosen
from the same block offset.
Note that if ve-ids are chosen that map to different block offsets, then each PE will have to send
multiple BGP updates to signal service labels. Each PE sends label blocks in BGP updates to each
of its BGP neighbors for all label blocks in which at least one ve-id has been seen by this PE (it
does not advertise label blocks which do not contain an active ve-id, where active ve-id means the
ve-id of this PE or any other PE in this VPLS).
The max-ve-id must be configured first, and determines the maximum value of the ve-id that can
be configured within the PE. The ve-id value cannot be higher than this within the PE
configuration, ve-id <= max-ve-id. Similarly, if the ve-id within a received NLRI is higher than
the max-ve-id value, it will not be accepted as valid consequently the max-ve-id configured on all
PEs must be greater than or equal to any ve-id used in the VPLS.
Only one ve-id value can be configured. If the ve-id value is changed, BGP withdraws the NLRI
and sends a route-refresh.
Note that if the same ve-id is used in different PEs for the same VPLS, a Designated Forwarder
election takes place.
Executing the shutdown command triggers an MP-UNREACH-NLRI from the PE to all BGP
peers
Note that the max-ve-id value is set to 10 to allow an increase in the number of PEs that could be
a part of this VPLS instance.
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:1.0 qinq 1522 1522 Up Up
sdp:17401:4294967274 SB(192.0.2.2) BgpVpls 0 1556 Up Up
sdp:17404:4294967286 SB(192.0.2.3) BgpVpls 0 1556 Up Up
===============================================================================
*A:PE-1#
The SAP and SDPs are all operationally up. Note that the SB flags signify Spoke and BGP.
Further verification can be seen below where the ingress labels for PE-2 and PE-3, the labels
allocated by PE-1, can be seen.
As can be seen from the following output, a BGP-VPLS NLRI update is sent to the route reflector
(192.0.2.20) and is received by each PE.
The following debug trace from PE-1 shows the BGP NLRI update for VPLS 1 sent by PE-1 to
the route reflector.
Note the presence of the control flags within the extended community which indicates the status of
the VPLS instance.
New control flags have been introduced to allow support for BGP multi-homing, D indicates that
all attachment circuits are Down, or the VPLS is shutdown. The flags are used in BGP Multi-
homing when determining which PEs are designated forwarders.
When flags=none, then all attachment circuits are up. In the example above no flags are present,
but should all SAPs become operationally down, then the following debug would be seen:
The BGP VPLS signaling parameters are also present, namely the ve-id of the PE within the
VPLS instance, the VBO and VBS, and the label base. The target indicates the VPLS instance,
which must be matched against the import route targets of the receiving PEs.
The signaling parameters can be seen within the BGP update with following command:
*A:PE-1# show router bgp routes l2-vpn rd 65536:1 hunt
.. snipped ..
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Route Type : VPLS
Route Dist. : 65536:1
VeId : 1 Block Size : 8
Base Offset : 1 Label Base : 131063
Nexthop : 192.0.2.1
To : 192.0.2.20
Res. Nexthop : n/a
Local Pref. : 100 Interface Name : NotAvailable
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : 0
AIGP Metric : None
Connector : None
Community : target:65536:1
l2-vpn/vrf-imp:Encap=19: Flags=none: MTU=1514: PREF=0
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 192.0.2.20
Origin : IGP
AS-Path : No As-Path
Neighbor-AS : N/A
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
*A:PE-1#
In this configuration example, PE-1 (192.0.2.1) with ve-id =1 has sent an update with base offset
(VBO) =1, block size (VBS) = 8 and label base 131063. This means that labels 131063 (LB) to
131070 (LB+VBS-1) are available as de-multiplexer labels, egress labels to be used to reach PE-1
for VPLS 1.
PE-2 receives this update from PE-1. This is seen as a valid VPLS BGP route from PE-1 through
the route reflector with nexthop 192.0.2.1.
PE-2 uses this information in conjunction with its own ve-id to calculate the egress label towards
PE-1, using the condition VBO ≤ ve-id < (VBO+VBS).
The ve-id of PE-2 is in the Label Block covered by VBO =1, thus,
This is verified using the following command on PE-2 where the egress label toward PE-1
(192.0.2.1) is 131064.
PE-3 also receives this update from PE-1 by the route reflector. This is seen as a valid VPLS BGP
route from PE-1 with nexthop 192.0.2.1.
===============================================================================
BGP L2VPN Routes
===============================================================================
Flag RouteType Prefix MED
RD SiteId Label
Nexthop VeId BlockSize LocalPref
As-Path BaseOffset vplsLabelBa
se
-------------------------------------------------------------------------------
u*>i VPLS - - 0
65536:1 - -
192.0.2.1 1 8 100
No As-Path 1 131063
u*>i VPLS - - 0
65536:1 - -
192.0.2.2 2 8 100
No As-Path 1 131063
i VPLS - - 0
65536:1 - -
192.0.2.3 3 8 100
No As-Path 1 131063
-------------------------------------------------------------------------------
Routes : 3
===============================================================================
A:PE-3#
The ve-id of PE-3 is also in the label block covered by block offset VBO =1.
This is verified using the following command on PE-3 where egress label towards 192.0.2.1 is
131065.
This is verified using the following command on PE-1 to show the egress label towards PE-2
(192.0.2.2) where the egress label towards PE-2 = 131063 + 1- 1 = 131063.
This is also verified using the following command on PE-3 to show the egress label towards PE-2
(192.0.2.2) where the egress label towards PE - 2 = 131063 + 3 - 1 = 131065.
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:1.0 qinq 1522 1522 Up Up
sdp:17399:4294967268 SB(192.0.2.2) BgpVpls 0 1556 Up Up
sdp:17403:4294967281 SB(192.0.2.1) BgpVpls 0 1556 Up Up
===============================================================================
A:PE-3#
This is verified using the following command on PE-1 to show the egress label towards PE-3
(192.0.2.3) where egress label towards PE-2 = 131063.
This is also verified using the following command on PE-2 to show the egress label towards PE-3
(192.0.2.3) which is using auto-provisioned SDP 17406.
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:PE-2#
This example has shown that for VPLS instance with 3 PEs, not all labels allocated by a PE will be
used by remote PEs as de-multiplexor service labels. There will be some wastage of label space,
so there is a necessity to choose ve-ids that keep this waste to a minimum.
The next example will show an even more wasteful use of labels by using random choice of ve-
ids.
This example also examines the effect of using ve-ids that are not all within the same contiguous
block.
PE-1
SDP 42
192.0.2.1
RR-1 CE
SDP 33
192.0.2.20
SDP 38
PE-3
VPLS 2
192.0.2.3
CE
SDP 39
SDP 40
PE-2
SDP 41 192.0.2.2
CE
BGP_VPLS_03
Figure 38 shows an example of a VPLS instance where SDPs are pre-provisioned with LDP
signalled transport tunnels.
SDPs on PE-1
configure service
sdp 33 mpls create
description "from-192.0.2.1-id-33"
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
sdp 42 mpls create
description "from-192.0.2.1-id-42"
far-end 192.0.2.3
lsp "LSP-PE-1-PE-3"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
exit
SDPs on PE-2
configure service
sdp 40 mpls create
far-end 192.0.2.1
lsp "LSP-PE-2-PE-1"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
sdp 41 mpls create
far-end 192.0.2.3
lsp "LSP-PE-2-PE-3"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
exit
SDPs on PE-3
configure service
sdp 38 mpls create
description "from-192.0.2.3-id-38"
far-end 192.0.2.1
lsp "LSP-PE-3-PE-1"
signaling bgp
keep-alive
shutdown
exit
collect-stats
no shutdown
exit
sdp 39 mpls create
description "from-192.0.2.3-id-39"
far-end 192.0.2.2
lsp "LSP-PE-3-PE-2"
signaling bgp
keep-alive
shutdown
exit
collect-stats
no shutdown
exit
exit
Note that pre-provisioned BGP-SDPs can also be used with BGP-VPLS. For reference, they are
configured as follows:
To create an SDP within a service that uses the RSVP transport tunnel, a pseudowire template is
required that has the use-provisioned-sdp parameter set.
Once again, a split horizon group is included to prevent forwarding between pseudowires.
The pseudowire template must be provisioned on all PEs and looks like:
The following output shows the configuration required for a BGP-VPLS service using a
pseudowire template configured for using pre-provisioned RSVP-TE SDPs.
Note that the route distinguisher and route target extended community values for VPLS 2 are
different from that in VPLS 1. The ve-id value for PE-1 can be the same as that in VPLS 1, but
these must be different within the same VPLS instance on the other PEs — PE-2 should not have
ve-id = 1.
Similarly, on PE-2 the configuration example shows where the ve-id value is 20:
and on PE-3:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:2.0 qinq 1522 1522 Up Up
sdp:38:4294967282 S(192.0.2.1) BgpVpls 0 1556 Up Up
sdp:39:4294967266 S(192.0.2.2) BgpVpls 0 1556 Up Up
===============================================================================
A:PE-3#
As the label allocation is block-dependent, multiple labels blocks must be advertised by each PE
to encompass this.
Two NLRIs updates are sent to the route reflector, with the following label parameters
PE-2 has a ve-id of 20. Applying the condition VBO ≤ ve-id < (VBO+VBS)
The egress label chosen is verified by examining the egress label towards PE-1 (192.0.2.1) on PE-
2.
PE-3 has a ve-id of 3. Applying the condition VBO ≤ ve-id < (VBO+VBS)
The egress label chosen is verified by examining the egress label towards PE-1 (192.0.2.1) on PE-
3.
To illustrate the allocation of label blocks by a PE, against the actual use of the same labels,
consider the following. When BGP updates from each PE signal the multiplexer labels in blocks
of eight, the allocated label values are added to the in-use pool. The label pool of PE-1 can be
verified as per the following output which shows labels used along with the associated protocol:
This shows that 32 labels have been allocated for use by BGP. Of this number, 16 labels have been
allocated for use by PEs within VPLS 2 to communicate with PE-1, the blocks with label base
131028 and with label base 131055.
There are only two neighboring PEs within this VPLS instance, so only two labels will ever be
used in the data plane for traffic destined to PE-1. These are 131031 and 131057. The remaining
labels have no PE with the associated ve-id that can use them.
Once again, this case emphasizes that to reduce label wastage, contiguous ve-ids in the range
(N..N+7) per VPLS should be chosen, where N>0.
Conclusion
BGP-VPLS allows the delivery of Layer 2 VPN services to customers where BGP is commonly
used. The examples presented in this section show the configuration of BGP-VPLS together with
the associated show outputs which can be used for verification and troubleshooting.