Example: Configuring FEC 129 BGP Autodiscovery for VPWS
Understanding VPWS
Virtual private wire service (VPWS) Layer 2 VPNs employ Layer 2 services over MPLS to build a topology of point-to-point connections that connect end customer sites in a VPN. These Layer 2 VPNs provide an alternative to private networks that have been provisioned by means of dedicated leased lines or by means of Layer 2 virtual circuits that employ ATM or Frame Relay. The service provisioned with these Layer 2 VPNs is known as VPWS. You configure a VPWS instance on each associated edge device for each VPWS Layer 2 VPN.
Traditional VPNs over Layer 2 circuits require the provisioning and maintenance of separate networks for IP and for VPN services. In contrast, VPWS enables the sharing of a provider’s core network infrastructure between IP and Layer 2 VPN services, reducing the cost of providing those services.
Junos OS supports two types of VPWS Layer 2 VPNs:
-
Kompella Layer 2 VPNs, which use BGP for autodiscovery and signaling.
-
FEC 129 BGP autodiscovery for VPWS, which uses BGP for autodiscovery and LDP as the signaling protocol.
FEC 129 BGP autodiscovery for VPWS requires the
l2vpn-id,
source-attachment-identifier, and
target-attachment-identifier
statements. Kompella Layer 2 VPNs require the
site-identifier and
remote-site-id statements.
VPWS creates pseudowires that emulate Layer 2 circuits. A virtual private LAN service (VPLS) network is similar to VPWS, but provides point-to-multipoint traffic forwarding in contrast to the VPWS Layer 2 VPN’s point-to-point traffic forwarding. If you need point-to-multipoint service instead of point-to-point service, consider using VPLS instead of VPWS.
A VPWS Layer 2 VPN can have either a full-mesh or a hub-and-spoke topology. The tunneling mechanism in the core network typically is MPLS. However, VPWS can also use other tunneling protocols, such as GRE. VPWS is similar to Martini Layer 2 services over MPLS, and employs a similar encapsulation scheme for forwarding traffic.
Figure 1 illustrates an example of a simple VPWS Layer 2 VPN topology.
In this example, the service provider offers VPWS services to Customer A and Customer B. Customer A wants to create a full mesh of point-to-point links between Westford and Bengaluru. Customer B needs only a single point-to-point link between Westford and Sunnyvale. The service provider uses BGP and MPLS signaling in the core, and creates a set of unidirectional pseudowires at each provider edge (PE) device to separately cross-connect each customer’s Layer 2 circuits.
In order to provision this service, the provider configures two VPWS
Layer 2 VPNs, Layer 2 VPN A and Layer 2 VPN B. The circuit
cross-connect (CCC) encapsulation type
(ethernet-ccc or
vlan-ccc) is configured for each
VPWS Layer 2 VPN. All interfaces in a given VPWS Layer 2 VPN
must be configured with the VPWS Layer 2 VPN’s encapsulation
type.
Local and remote site information for the interfaces identifies the cross-connect. Local cross-connects are supported when the interfaces that are connected belong to two different sites configured in the same VPWS instance and on the same PE device.
BGP advertises reachability for the VPNs. The BGP configuration is similar to that used for other VPN services, such as Layer 3 VPNs and VPLS. MPLS is configured to set up base LSPs to the remote PE devices similarly to the other VPN services.
Junos OS provides VPWS support the following configuration methods:
-
Pseudowires are manually configured using Forwarding Equivalence Class (FEC) 128.
-
Pseudowires are signaled by LDP using FEC 129. This arrangement reduces the configuration burden that is associated with statically configured Layer 2 circuits while still using LDP as the underlying signaling protocol.
Supported and Unsupported Features
Junos OS supports the following features with VPWS :
-
Intra-AS VPWS functionality using BGP for autodiscovery and FEC 129 LDP for pseudowire signaling.
-
Graceful Routing Engine switchover.
-
Operation, administration, and maintenance (OAM) mechanisms, including Bidirectional Forwarding Detection and MPLS ping.
-
FEC 128 LDP signaling with static configuration (in Junos OS this is configured within
protocols l2circuit). With this option, there is no BGP autodiscovery.
Junos OS does not support the following VPWS functionality:
-
Multihoming of customer sites to multiple PE devices using the BGP site model of multihoming.
-
Terminating FEC 129 VPWS into a mesh group of an FEC 129 VPLS instance.
-
Intra-AS VPWS functionality using BGP for autodiscovery and FEC 128 LDP for pseudowire signaling.
-
FEC 129 VPWS without BGP autodiscovery.
-
Static configuration of VPWS with FEC 129 signaling.
-
Nonstop active routing.
-
Multi-segment pseudowires.
-
Interworking of FEC 128 and FEC 129 VPWS.
-
Statically configured Layer 2 circuit-style pseudowire redundancy.
-
Inter-AS deployments.
See Also
Understanding FEC 129 BGP Autodiscovery for VPWS
The major functional components in a VPWS with FEC 129 are BGP, LDP, and the Layer 2 VPN module of Junos OS. BGP is responsible for distributing the local autodiscovery routes created on each PE device to all other PE devices. LDP is responsible for using the autodiscovery information provided by BGP to set up targeted LDP sessions over which to signal the pseudowires. The Layer 2 VPN is the glue that binds the BGP and LDP functionalities together.
- Supported Standards in FEC 129 BGP Autodiscovery for VPWS
- Routes and Routing Table Interaction in FEC 129 BGP Autodiscovery for VPWS
- Layer 2 VPN Behavior in FEC 129 BGP Autodiscovery for VPWS
- BGP Autodiscovery Behavior in FEC 129 BGP Autodiscovery for VPWS
- LDP Signaling Behavior in VPWS in FEC 129 BGP Autodiscovery for VPWS
Supported Standards in FEC 129 BGP Autodiscovery for VPWS
The relevant RFCs for this feature are as follows:
RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
RFC 6074, Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)
Routes and Routing Table Interaction in FEC 129 BGP Autodiscovery for VPWS
BGP, LDP, and Layer 2 VPNs interact through different types of routes installed in the instance.l2vpn.0 table. Theroutes that are present in the table are autodiscovery routes and pseudowire routes.
Autodiscovery routes are used by BGP to allow autodiscovery of remote source access individual identifiers (SAIIs) (the sources of the point-to-point pseudowires) and PE device addresses. Autodiscovery routes are advertised when you configure the
l2vpn auto-discovery-onlyaddress family.The format of the autodiscovery routes is a combination of the route distinguisher and the SAII. For example: 10.255.0.1:100:0.0.0.1/96 AD.
Table 1 lists the route elements and the number of associated bytes allocated to each element.
Table 1: Autodiscovery Route Format Route Element
Bytes
RD
8 bytes
SAII
4 bytes
The
l2vpn-idof the FEC 129 VPWS instance is attached to the route in a BGP extended community. One autodiscovery route is advertised for each source attachment identifier (SAI) in the instance.Pseudowire routes are installed by the Layer 2 VPN (local) and LDP (remote) to represent the bidirectional components of the pseudowire. For example: NoCtrlWord:5:100:200:2:0.0.0.1/176. The format of the routes is described in Table 2.
Field Name |
Field Description |
|---|---|
Pseudowire type + control word bit |
2 bytes |
Remote PE address |
4 bytes |
Attachment group identifier (AGI) The AGI field of the pseudowire route is always set to the |
8 bytes |
SAII |
4 bytes |
Target attachment individual identifier (TAII) |
4 bytes |
Layer 2 VPN Behavior in FEC 129 BGP Autodiscovery for VPWS
A Layer 2 VPN installs a locally generated autodiscovery route
into the instance.l2vpn.0 table for every SAII configured in an FEC
129 VPWS instance. The extended community containing the l2vpn-id is attached when the route is added to the instance.l2vpn.0 table.
For each autodiscovered SAII from a remote neighbor where the l2vpn-id matches the local l2vpn-id and the received
SAII matches a locally configured TAII, the Layer 2 VPN obtains an
MPLS label and generates a pseudowire route and adds it to the instance.l2vpn.0
table. The remote PE address is copied from the BGP protocol next
hop for the autodiscovery route.
The Layer 2 VPN module of Junos OS is responsible for installing the forwarding routes into the mpls.0 table as usual.
BGP Autodiscovery Behavior in FEC 129 BGP Autodiscovery for VPWS
Local autodiscovery routes installed by the Layer 2 VPN in the
instance.l2vpn.0 table are advertised by BGP to remote PE devices
sl2vpn auto-discovery-only address family according to
the instance and BGP export policies.
On the receiving side, BGP accepts autodiscovery routes from remote peers and installs them in the local bgp.l2vpn.0 table, if they are allowed by inbound policy. The route is installed, and a secondary route is imported into the instance.l2vpn.0 table when an import route target match between the route and instance is found.
LDP Signaling Behavior in VPWS in FEC 129 BGP Autodiscovery for VPWS
In the Junos OS implementation of LDP, the router monitors for
routes from instance.l2vpn.0 for any instance configured for FEC 129
VPWS. These routes are identified by the instance-type l2vpn statement in the routing instance and the presence of the l2vpn-id statement.
When a BGP autodiscovery route is installed, LDP sets up a targeted session with the remote peer, where the peer address is identified as the protocol next hop of the BGP autodiscovery route.
When a pseudowire route is installed in the instance.l2vpn.0 table, LDP uses the parameters associated with the route to signal the creation of the pseudowire using FEC 129. Upon receiving an FEC 129 label mapping message from a remote peer, LDP installs the pseudowire route in the ldp.l2vpn.0 table.
Upon a successful l2vpn-id match with a configured
FEC 129 VPWS instance, a secondary pseudowire route is imported to
the instance.l2vpn.0 table. If an outgoing pseudowire has not already
been set up when the incoming pseudowire signaling is received, LDP
initiates the outgoing pseudowire creation as well.
See Also
Example: Configuring FEC 129 BGP Autodiscovery for VPWS
This example shows how to configure the virtual private wire service (VPWS), where remote provider edge (PE) devices are automatically discovered dynamically by BGP, and pseudowires are signaled by LDP using FEC 129. This arrangement reduces the configuration burden that is associated with statically configured Layer 2 circuits while still using LDP as the underlying signaling protocol.
Requirements
This example requires Junos OS Release 13.2 or later on the PE devices.
Overview
Because VPWS is a point-to-point service, FEC 129 VPWS routing
instances are configured as instance-type l2vpn. As with
FEC 129 VPLS, FEC 129 VPWS uses the l2vpn-id statement
to define the Layer 2 VPN of which the routing instance is a member.
The presence of the l2vpn-id statement designates that
FEC 129 LDP signaling is used for the routing instance. The absence
of l2vpn-id indicates that BGP signaling is used instead.
The point-to-point nature of VPWS requires that you specify the source access individual identifier (SAII) and the target access individual identifier (TAII). This SAII-TAII pair defines a unique pseudowire between two PE devices.
The SAII is specified with the source-attachment-identifier statement within the FEC 129 VPWS routing instance. You configure
the source attachment identifier and the interfaces to associate with
that source attachment identifier. Under each interface, you can configure
the TAII with the target-attachment-identifier statement.
If the configured target identifier matches a source identifier advertised
by a remote PE device by way of a BGP autodiscovery message, the pseudowire
between that source-target pair is signaled. If there is no match
between an advertised source identifier and the configured target
identifier, the pseudowire is not established.
Sample: VPWS Configuration with Multiple Interfaces and Sites
routing-instances {
FEC129-VPWS {
instance-type l2vpn;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
route-distinguisher 10.255.0.1:200;
l2vpn-id l2vpn-id:100:200;
vrf-target target:100:200;
protocols l2vpn {
site CUSTOMER-1 {
source-attachment-identifier 1;
interface ge-0/0/1.0 {
target-attachment-identifier 2;
}
interface ge-0/0/2.0 {
target-attachment-identifier 3;
}
}
}
}
}
You can configure multiple interfaces within a site, because
each SAII-TAII pair defines a unique pseudowire, as shown with pseudowires
1-2 and 1-3 in the sample configuration. Both the source and target
access identifiers are 4-byte numbers and can only be configured in
FEC 129 VPWS instances where the instance-type is l2vpn and the l2vpn-id configuration statement is
present.
You can specify the source and target identifiers as plain unsigned integers in the range 1 through 4,292,967,295.
The Layer 2 circuit and Layer 2 VPN services allow many optional parameters to be included on a per-pseudowire basis. FEC 129 VPWS allows such parameters as MTU settings, community tagging, and inclusion of a control word, as shown in this sample configuration:
Sample: VPWS Configuration with Optional Configuration Parameters
routing-instances {
FEC129-VPWS {
instance-type l2vpn;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
route-distinguisher 10.255.0.1:200;
l2vpn-id l2vpn-id:100:200;
vrf-target target:100:200;
protocols l2vpn {
site CUSTOMER-1 {
source-attachment-identifier 1;
community COMM;
control-word ;
encapsulation-type ethernet;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
mtu 1500;
no-control-word;
interface ge-0/0/1.0 {
target-attachment-identifier 2;
}
interface ge-0/0/2.0 {
target-attachment-identifier 3;
community COMM;
control-word;
encapsulation-type ethernet;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
mtu 1500;
no-control-word;
}
}
}
}
}
When configured within the site, the defined parameters affect any pseudowire originating from that site. When configured under an interface, the defined parameters affect that single specific pseudowire. This allows you to manipulate the parameters across all pseudowires associated with a particular local site in one place in the configuration.
Like other point-to-point services, the interfaces configured as members of the FEC 129 VPWS instance must be configured for CCC encapsulation and the CCC address family, as shown here:
interfaces {
ge-0/0/1 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
ge-0/0/2 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
ge-0/0/3 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
}
You can use vlan-ccc instead of ethernet-ccc.
To support the basic FEC 129 VPWS functionality, the BGP sessions
on the PE devices also need to be configured with the BGP auto-discovery-only address family to allow exchange of the autodiscovery routes. If
traditional BGP VPLS or Layer 2 VPN service is also provisioned on
the PE devices, the address family l2vpn signaling is also
required, as shown here:
bgp {
group pe {
type internal;
local-address 10.255.0.1;
family l2vpn {
auto-discovery-only;
signaling;
}
neighbor 10.255.0.2;
neighbor 10.255.0.3;
}
}
The following configuration sample shows an FEC 129 VPWS routing instance with the operation, administration, and maintenance (OAM) (ping and BFD) configuration options:
Sample: VPWS Configuration with OAM
routing-instances {
FEC129-VPWS {
instance-type l2vpn;
interface ge-0/0/1.0;
route-distinguisher 10.255.0.1:200;
l2vpn-id l2vpn-id:100:200;
vrf-target target:100:200;
protocols l2vpn {
oam {
ping-interval 600;
bfd-liveness-detection {
minimum-interval 200;
}
}
site CUSTOMER {
source-attachment-identifier 1;
oam {
ping-interval 600;
bfd-liveness-detection {
minimum-interval 200;
}
}
interface ge-0/0/1.0 {
oam {
ping-interval 600;
bfd-liveness-detection {
minimum-interval 200;
}
}
target-attachment-identifier 2;
}
}
}
}
}
OAM options configured under protocols l2vpn apply
to all sites and pseudowires in the routing instance. OAM options
configured under a particular site apply to the pseudowires configured
under that site. OAM options configured under a particular interface
apply to the pseudowire configured under that interface.
Topology Diagram
Figure 2 shows the topology used in this example.
This example uses a simple topology with two PE devices and two customer edge (CE) devices.
CLI Quick Configuration shows the configuration for all of the devices in Figure 2. The section Step-by-Step Procedure describes the steps on Device PE1 and Device PE2.
Configuration
CLI Quick Configuration
To quickly configure
this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match
your network configuration, and then copy and paste the commands into
the CLI at the [edit] hierarchy level.
Device CE1
set interfaces ge-2/0/8 unit 0 description CE1_to_PE1 set interfaces ge-2/0/8 unit 0 family inet address 172.16.0.1/24 set interfaces lo0 unit 0 family inet address 192.0.2.5/24 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-2/0/8.0
Device CE2
set interfaces ge-2/1/6 unit 0 description CE2_to_PE2 set interfaces ge-2/1/6 unit 0 family inet address 172.16.0.4/24 set interfaces lo0 unit 0 family inet address 192.0.2.6/24 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-2/1/6.0
Device PE1
set interfaces ge-2/0/5 encapsulation ethernet-ccc set interfaces ge-2/0/5 unit 0 description PE1_to_CE1 set interfaces ge-2/0/5 unit 0 family ccc set interfaces fe-2/0/10 unit 0 description to_PE2 set interfaces fe-2/0/10 unit 0 family inet address 10.0.0.1/30 set interfaces fe-2/0/10 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.1/24 set protocols mpls interface fe-2/0/10.0 set protocols bgp local-address 192.0.2.1 set protocols bgp group pe-pe type internal set protocols bgp group pe-pe family l2vpn auto-discovery-only set protocols bgp group pe-pe family l2vpn signaling set protocols bgp group pe-pe neighbor 192.0.2.2 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-2/0/10.0 set protocols ldp interface fe-2/0/10.0 set protocols ldp interface lo0.0 set routing-instances FEC129-VPWS instance-type l2vpn set routing-instances FEC129-VPWS interface ge-2/0/5.0 set routing-instances FEC129-VPWS route-distinguisher 192.0.2.1:100 set routing-instances FEC129-VPWS l2vpn-id l2vpn-id:100:100 set routing-instances FEC129-VPWS vrf-target target:100:100 set routing-instances FEC129-VPWS protocols l2vpn site ONE source-attachment-identifier 1 set routing-instances FEC129-VPWS protocols l2vpn site ONE interface ge-2/0/5.0 target-attachment-identifier 2 set routing-options autonomous-system 64510
Device PE2
set interfaces ge-2/1/7 encapsulation ethernet-ccc set interfaces ge-2/1/7 unit 0 description PE2_to_CE2 set interfaces ge-2/1/7 unit 0 family ccc set interfaces fe-2/0/10 unit 0 description to_PE1 set interfaces fe-2/0/10 unit 0 family inet address 10.0.0.2/30 set interfaces fe-2/0/10 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.2/24 set protocols mpls interface fe-2/0/10.0 set protocols bgp local-address 192.0.2.2 set protocols bgp group pe-pe type internal set protocols bgp group pe-pe family l2vpn auto-discovery-only set protocols bgp group pe-pe family l2vpn signaling set protocols bgp group pe-pe neighbor 192.0.2.1 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface fe-2/0/10.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface fe-2/0/10.0 set protocols ldp interface lo0.0 set routing-instances FEC129-VPWS instance-type l2vpn set routing-instances FEC129-VPWS interface ge-2/1/7.0 set routing-instances FEC129-VPWS route-distinguisher 192.0.2.2:100 set routing-instances FEC129-VPWS l2vpn-id l2vpn-id:100:100 set routing-instances FEC129-VPWS vrf-target target:100:100 set routing-instances FEC129-VPWS protocols l2vpn site TWO source-attachment-identifier 2 set routing-instances FEC129-VPWS protocols l2vpn site TWO interface ge-2/1/7.0 target-attachment-identifier 1 set routing-options autonomous-system 64510
Procedure
Step-by-Step Procedure
To configure a FEC 129 VPWS:
-
Configure the interfaces.
[edit interfaces] user@PE1# set ge-2/0/5 encapsulation ethernet-ccc user@PE1# set ge-2/0/5 unit 0 description PE1_to_CE1 user@PE1# set ge-2/0/5 unit 0 family ccc user@PE1# set fe-2/0/10 unit 0 description to_PE2 user@PE1# set fe-2/0/10 unit 0 family inet address 10.0.0.1/30 user@PE1# set fe-2/0/10 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 192.0.2.1/24
-
Configure MPLS on the core-facing interface.
[edit protocols mpls] user@PE1# set interface fe-2/0/10.0
-
Configure BGP.
[edit protocols bgp] user@PE1# set local-address 192.0.2.1 user@PE1# set group pe-pe type internal user@PE1# set group pe-pe family l2vpn auto-discovery-only user@PE1# set group pe-pe family l2vpn signaling user@PE1# set group pe-pe neighbor 192.0.2.2
-
Configure an interior gateway protocol, such as IS-IS or OSPF.
If you use OSPF, enable traffic engineering. Traffic engineering is supported by IS-IS by default.
[edit protocols ospf] user@PE1# set traffic-engineering user@PE1# set area 0.0.0.0 interface lo0.0 passive user@PE1# set area 0.0.0.0 interface fe-2/0/10.0
-
Configure LDP on the core-facing interface and on the loopback interface.
[edit protocols ldp] user@PE1# set interface fe-2/0/10.0 user@PE1# set interface lo0.0
-
Configure the VPWS routing instance.
LDP listens for routes from instance.l2vpn.0 for any instance configured for FEC 129 VPWS. These routes are identified by the
instance-type l2vpnstatement in the routing instance and the presence of thel2vpn-idstatement.Make sure that the
target-attachment-identifiermatches thesource-attachment-identifierin the remote PE device’s corresponding site. In this example, the pseudowire is established between Device PE1 and Device PE2. Device PE1 uses SAI 1 and TAI 2, while Device PE2 uses the opposite, SAI 2 and TAI 1.[edit routing-instances FEC129-VPWS] user@PE1# set instance-type l2vpn user@PE1# set interface ge-2/0/5.0 user@PE1# set route-distinguisher 192.0.2.1:100 user@PE1# set l2vpn-id l2vpn-id:100:100 user@PE1# set vrf-target target:100:100 user@PE1# set protocols l2vpn site ONE source-attachment-identifier 1 user@PE1# set protocols l2vpn site ONE interface ge-2/0/5.0 target-attachment-identifier 2
-
Configure the autonomous system (AS) number.
[edit routing-options] user@PE1# set autonomous-system 64510
-
If you are done configuring the device, commit the configuration.
[edit] user@PE1# commit
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, show routing-instances, and show routing-options command. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@PE1# show interfaces
ge-2/0/5 {
encapsulation ethernet-ccc;
unit 0 {
description PE1_to_CE1;
family ccc;
}
}
fe-2/0/10 {
unit 1 {
description to_PE2;
family inet {
address 10.0.0.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.1/24;
}
}
}
user@PE1# show protocols
mpls {
interface fe-2/0/10.0;
}
bgp {
local-address 192.0.2.1;
group pe-pe {
type internal;
family l2vpn {
auto-discovery-only;
inactive: signaling;
}
neighbor 192.0.2.2;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fe-2/0/10.0;
}
}
ldp {
interface fe-2/0/10.0;
interface lo0.0;
}
user@PE1# show routing-instances
FEC129-VPWS {
instance-type l2vpn;
interface ge-2/0/5.0;
route-distinguisher 192.0.2.1:100;
l2vpn-id l2vpn-id:100:100;
vrf-target target:100:100;
protocols {
l2vpn {
site ONE {
source-attachment-identifier 1;
interface ge-2/0/5.0 {
target-attachment-identifier 2;
}
}
}
}
}
user@PE1# show routing-options autonomous-system 64510;
Verification
Confirm that the configuration is working properly.
- Verifying the Routes
- Checking Connectivity Between the CE Devices
- Checking the VPWS Connections
- Checking Connectivity Between the PE Devices
Verifying the Routes
Purpose
Verify that the expected routes are learned.
Action
From operational mode, enter the show route command.
user@PE1> show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/24 *[Direct/0] 6d 21:16:32
> via lo0.0
192.0.2.2/24 *[OSPF/10] 6d 21:15:31, metric 1
> to 10.0.0.2 via fe-2/0/10.0
10.0.0.0/30 *[Direct/0] 6d 21:16:31
> via fe-2/0/10.0
10.0.0.1/32 *[Local/0] 6d 21:16:32
Local via fe-2/0/10.0
203.0.113.0/24 *[OSPF/10] 6d 21:16:34, metric 1
MultiRecv
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.2/24 *[LDP/9] 5d 22:25:19, metric 1
> to 10.0.0.2 via fe-2/0/10.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 6d 21:16:33, metric 1
Receive
1 *[MPLS/0] 6d 21:16:33, metric 1
Receive
2 *[MPLS/0] 6d 21:16:33, metric 1
Receive
13 *[MPLS/0] 6d 21:16:33, metric 1
Receive
299808 *[LDP/9] 5d 22:25:19, metric 1
> to 10.0.0.2 via fe-2/0/10.0, Pop
299808(S=0) *[LDP/9] 5d 22:25:19, metric 1
> to 10.0.0.2 via fe-2/0/10.0, Pop
299824 *[L2VPN/7] 5d 22:25:18
> via ge-2/0/5.0, Pop
ge-2/0/5.0 *[L2VPN/7] 5d 22:13:02, metric2 1
> to 10.0.0.2 via fe-2/0/10.0, Push 299872
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.2:100:0.0.0.2/96 AD
*[BGP/170] 6d 20:51:23, localpref 100, from 192.0.2.2
AS path: I, validation-state: unverified
> to 10.0.0.2 via fe-2/0/10.0
ldp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.2:NoCtrlWord:5:100:100:0.0.0.2:0.0.0.1/176
*[LDP/9] 5d 22:13:02
Discard
FEC129-VPWS.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1:100:0.0.0.1/96 AD
*[L2VPN/170] 6d 20:53:26, metric2 1
Indirect
192.0.2.2:100:0.0.0.2/96 AD
*[BGP/170] 6d 20:51:23, localpref 100, from 192.0.2.2
AS path: I, validation-state: unverified
> to 10.0.0.2 via fe-2/0/10.0
192.0.2.2:NoCtrlWord:5:100:100:0.0.0.1:0.0.0.2/176
*[L2VPN/7] 6d 20:51:23, metric2 1
> to 10.0.0.2 via fe-2/0/10.0
192.0.2.2:NoCtrlWord:5:100:100:0.0.0.2:0.0.0.1/176
*[LDP/9] 5d 22:13:02
DiscardMeaning
The output shows all the learned routes, including the autodiscovery (AD) routes.
Checking Connectivity Between the CE Devices
Purpose
Verify that Device CE1 can ping Device CE2.
Action
user@CE1> ping 192.0.2.6 PING 192.0.2.6 (192.0.2.6): 56 data bytes 64 bytes from 192.0.2.6: icmp_seq=0 ttl=64 time=0.679 ms 64 bytes from 192.0.2.6: icmp_seq=1 ttl=64 time=0.524 ms ^C --- 192.0.2.6 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.524/0.602/0.679/0.078 ms
Meaning
The output shows that the VPWS is operational.
Checking the VPWS Connections
Purpose
Make sure that all of the FEC 129 VPWS connections come up correctly.
Action
user@PE1> show l2vpn connections
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not available
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
LB -- Local site not best-site RB -- Remote site not best-site
VM -- VLAN ID mismatch
Legend for interface status
Up -- operational
Dn -- down
Instance: FEC129-VPWS
L2vpn-id: 100:100
Local source-attachment-id: 1 (ONE)
Target-attachment-id Type St Time last up # Up trans
2 rmt Up Nov 28 16:16:14 2012 1
Remote PE: 192.0.2.2, Negotiated control-word: No
Incoming label: 299792, Outgoing label: 299792
Local interface: ge-2/0/5.0, Status: Up, Encapsulation: ETHERNETMeaning
As expected, the connection is up. The output includes the source attachment ID and the target attachment ID.
Checking Connectivity Between the PE Devices
Purpose
Verify that Device PE1 can ping Device PE2. The ping mpls l2vpn fec129 command accepts SAIs and TAIs as integers
or IP addresses and also allows you to use the CE-facing interface
instead of the other parameters (instance, local-id, remote-id, remote-pe-address).
Action
user@PE1> ping mpls l2vpn fec129 instance FEC129-VPWS remote-id 2 remote-pe-address 192.0.2.2 local-id 1 !!!!! --- lsping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss
user@PE1> ping mpls l2vpn fec129 interface ge-2/0/5.0 !!!!! --- lsping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss
Meaning
The output shows that the VPWS is operational.