Example: Configuring FEC 129 BGP Autodiscovery for 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 Bangalore. 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.
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.
Interworking of FEC 128 and FEC 129 VPWS.
Statically configured Layer 2 circuit-style pseudowire redundancy.
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
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-only address 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
The l2vpn-id of 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.
Table 2: Pseudowire Route Format
Pseudowire type + control word bit
Remote PE address
Attachment group identifier (AGI)
The AGI field of the pseudowire route is always set to the l2vpn-id of the instance.
Target attachment individual identifier (TAII)
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.
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.
This example requires Junos OS Release 13.2 or later on the PE devices.
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
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
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:
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:
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
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.
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
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  hierarchy level.
To configure a FEC 129 VPWS:
Configure the interfaces.[edit interfaces]user@PE1# set ge-2/0/5 encapsulation ethernet-cccuser@PE1# set ge-2/0/5 unit 0 description PE1_to_CE1user@PE1# set ge-2/0/5 unit 0 family cccuser@PE1# set fe-2/0/10 unit 0 description to_PE2user@PE1# set fe-2/0/10 unit 0 family inet address 10.0.0.1/30user@PE1# set fe-2/0/10 unit 0 family mplsuser@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.1user@PE1# set group pe-pe type internaluser@PE1# set group pe-pe family l2vpn auto-discovery-onlyuser@PE1# set group pe-pe family l2vpn signalinguser@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-engineeringuser@PE1# set area 0.0.0.0 interface lo0.0 passiveuser@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.0user@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 l2vpn statement in the routing instance and the presence of the l2vpn-id statement.
Make sure that the target-attachment-identifier matches the source-attachment-identifier in 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 l2vpnuser@PE1# set interface ge-2/0/5.0user@PE1# set route-distinguisher 192.0.2.1:100user@PE1# set l2vpn-id l2vpn-id:100:100user@PE1# set vrf-target target:100:100user@PE1# set protocols l2vpn site ONE source-attachment-identifier 1user@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.user@PE1# commit
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.
Confirm that the configuration is working properly.
Verifying the Routes
Verify that the expected routes are learned.
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 Discard
The output shows all the learned routes, including the autodiscovery (AD) routes.
Checking Connectivity Between the CE Devices
Verify that Device CE1 can ping Device CE2.
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
The output shows that the VPWS is operational.
Checking the VPWS Connections
Make sure that all of the FEC 129 VPWS connections come up correctly.
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: ETHERNET
As expected, the connection is up. The output includes the source attachment ID and the target attachment ID.
Checking Connectivity Between the PE Devices
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).
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
The output shows that the VPWS is operational.