Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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.

Note

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.

Figure 1: VPWS Sample Topology
VPWS Sample 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.

  • 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.

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

    Route Element

    Bytes

    RD

    8 bytes

    SAII

    4 bytes

    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

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 l2vpn-id of the instance.

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.

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

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.

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.

Figure 2: Simple VPWS Topology
Simple VPWS Topology

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.

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

Device CE2

Device PE1

Device PE2

Step-by-Step Procedure

To configure a FEC 129 VPWS:

  1. Configure the interfaces.

  2. Configure MPLS on the core-facing interface.

  3. Configure BGP.

  4. 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.

  5. Configure LDP on the core-facing interface and on the loopback interface.

  6. 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.

  7. Configure the autonomous system (AS) number.

  8. If you are done configuring the device, commit the configuration.

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.

Verification

Confirm that the configuration is working properly.

Verifying the Routes

Purpose

Verify that the expected routes are learned.

Action

From operational mode, enter the show route command.

user@PE1> show route

Meaning

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

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

Meaning

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


user@PE1> ping mpls l2vpn fec129 interface ge-2/0/5.0

Meaning

The output shows that the VPWS is operational.