Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configure MPLS-Based Layer 2 VPNs

 

This example shows how to configure and validate an MPLS-based Layer 2 VPN on routers or switches running Junos OS.

Note

Our content testing team has validated and updated this example.

You can deploy an MPLS-based Layer 2 virtual private network using routers and switches running Junos OS to interconnect customer sites with Layer 2 connectivity. Layer 2 VPNs give customers complete control over their choice of transport and routing protocols.

MPLS-based VPNs require baseline MPLS functionality in the provider network. Once basic MPLS is operational, you are able to configure VPNs that use Label-switched paths (LSPs) for transport over the provider’s core.

The addition of VPN services does not affect the basic MPLS switching operations in the provider network. In fact, the provider (P) devices require only a baseline MPLS configuration because they are not VPN aware. VPN state is maintained only on the PE devices. This is a key reason why MPLS-based VPNs are so scalable.

Requirements

This example uses the following hardware and software components:

  • Junos OS Release 15.1 or later

    • Revalidated on Junos OS Release 20.1R1

  • Two Provider edge (PE) devices

  • One provider (P) device

  • Two customer edge (CE) devices

The example focuses on how to add Layer 2 VPN to a pre-existing MPLS baseline. A basic MPLS configuration is provided in case your network does not already have MPLS deployed.

To support MPLS-based VPNs the underlying MPLS baseline must provide the following functionality:

  • Core-facing and loopback interfaces operational with MPLS family support

  • An interior gateway protocol such as OSPF or IS-IS to provide reachability between the loopback addresses of the provider (P and PE) devices

  • An MPLS signalling protocol such as LDP or RSVP to signal LSPs

  • LSPs established between PE device loopback addresses

LSPs are needed between each pair of PE devices that participate in a given VPN. Its a good idea to build LSPs between all PE devices to accommodate future VPN growth. You configure LSPs at the [edit protocols mpls] hierarchy level. Unlike an MPLS configuration for circuit cross-connect (CCC) , you do not need to manually associate the LSP with the PE device’s customer-facing (edge) interface. Instead, Layer 2 VPNs use BGP signalling to convey Layer 2 site reachability. This BGP signaling automates the mapping of remote Layer 2 VPN sites to LSP forwarding next hops. This means that with a Layer 2 VPN explicit mapping of an LSP to a PE device’s edge-facing interface is not required.

For details on CCC, refer to Configuring an MPLS-Based VLAN CCC Using a Layer 2 Circuit.

Overview and Topology

A Layer 2 VPN provides complete separation between the provider and customer networks. The benefits of a Layer 2 VPN include support for nonstandard transport protocols and the isolation of link addressing and routing protocol operation between the customer and provider networks.

Definition of a VPN involves changes to the local and remote PE devices only. No additional configuration is needed on the provider devices (aside from baseline MPLS support), because these devices only provide basic MPLS switching functions. The CE devices do not use MPLS. They require only a basic interface, and if desired, protocol configuration, to operate over the Layer 2 VPN. For a Layer 2 VPN you configure the CE devices as if they were attached to a shared link.

Once an MPLS baseline is in place, you must configure the following functionality on the PE devices to establish an MPLS-based Layer 2 VPN:

  • A BGP group with family l2vpn signaling

  • A routing instance with instance type l2vpn

  • The customer-facing interfaces on the PE devices must be configured as follows:

    • Specify ethernet-ccc or vlan-ccc physical layer encapsulation depending on whether VLAN tagging is in use.

    • Configure a matching encapsulation type in the routing instance configuration.

    • Configure the logical interface (unit) used for the Layer 2 VPN with family ccc.

Figure 1 provides the topology for this MPLS-based Layer 2 VPN example. The figure details the interface names, IP addressing, and protocols used in the provider network. It also highlights the end-to-end nature of the CE device addressing and protocol stack operation. Unlike a Layer 3 VPN, CE device operation is opaque to the provider network in a Layer 2 VPN. There is no peering relationship between the CE devices and the provider network. As a result you expect the CE devices to form an OSPF adjacency across, not to, the provider network.

Figure 1: An MPLS-Based Layer 2 VPN
An MPLS-Based Layer 2 VPN

Quick Configurations

Use the configurations in this section to quickly get your MPLS-based Layer 2 VPN up and running. The configurations include a functional MPLS baseline to support your Layer 2 VPN. This example focuses on the VPN aspects of the configuration. Refer to the following links for additional information on the baseline MPLS functionality used in this example:

CLI Quick Configuration

Note

The device configurations omit the management interface, static routes, system logging, system services, and user login information. These parts of the configuration vary by location and are not directly related to MPLS or VPN functionality.

Edit the following commands as needed for the specifics of your environment and paste them into the local CE (CE1) device terminal window:

The complete configuration for the CE1 device.

Edit the following commands as needed for the specifics of your environment and paste them into the local PE (PE1) device terminal window:

The complete configuration for PE1 device.

The complete configuration for the P device.

The complete configuration for the PE2 device.

The complete configuration for the CE2 device.

Be sure to commit the configuration changes on all devices when satisfied with your work. Congratulations on your new MPLS-based Layer 2 VPN! Refer to the Verification section for the steps needed to confirm your VPN is working as expected.

Step-by-Step Procedure

A step by step procedure is not needed for the quick configuration section. If used, the configurations should be pasted directly into the device CLI.

Configure the Local PE (PE1) Device for a MPLS-Based Layer 2 VPN

This section covers the steps needed to configure the PE1 device for this example. Refer to the Quick Configurations section for the CE device and P device configurations used in this example.

Configure the MPLS Baseline (if Needed)

Before you configure the Layer 2 VPN make sure the PE device has a working MPLS baseline. If you already having a an MPLS baseline you can skip to the step-by-step procedure to add the Layer 2 VPN to the local PE device.

  • Configure the hostname.

    [edit]

    user@pe1# set system host-name pe1
  • Configure the interfaces.

    [edit]

    user@pe1# set interfaces lo0 unit 0 family inet address 192.168.0.1/32
    [edit]

    user@pe1# set interfaces ge-0/0/1 description "Link from PE1 to P-router"
    [edit]

    user@pe1# set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24
    [edit]

    user@pe1# set interfaces ge-0/0/1 mtu 4000
    [edit]

    user@pe1# set interfaces ge-0/0/1 unit 0 family mpls
    Caution

    Layer 2 VPNs don’t support fragmentation in the provider network. It is critical that the provider network supports the largest frame that the CE devices can generate after the MPLS and virtual routing and forwarding (VRF) labels are added by the PE devices. This example leaves the CE devices at the default 1500-byte maximum transmission unit (MTU) while configuring the provider core to support a 4000 byte MTU. This configuration avoids discards by ensuring the CE devices cannot exceed the MTU in the provider’s network.

  • Configure the protocols.

    Note

    Traffic engineering is supported for RSVP-signaled LSPs but is not required for basic MPLS switching or VPN deployment. The provided MPLS baseline uses RSVP to signal LSPs, and enables traffic engineering for OSPF. However, no path constraints are configured so you expect the LSPs to be routed over the interior gateway protocol’s shortest path.

    [edit]

    user@pe1# set protocols ospf area 0.0.0.0 interface lo0.0
    [edit]

    user@pe1# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
    [edit]

    user@pe1# set protocols ospf traffic-engineering
    [edit]

    user@pe1# set protocols mpls interface ge-0/0/1.0
    [edit]

    user@pe1# set protocols rsvp interface lo0.0
    [edit]

    user@pe1# set protocols rsvp interface ge-0/0/1.0
  • Define the LSP to the remote PE device’s loopback address.

    [edit]

    user@pe1# set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.3

Step-by-Step Procedure

Follow these steps to configure the PE1 device for a Layer 2 VPN.

  1. Configure the edge-facing interface. Specify a physical encapsulation type of ethernet-ccc with family ccc on unit 0. This is the only valid unit number for an untagged Ethernet interface. If you are using VLAN tagging specify vlan-ccc encapsulation and add the CCC family to the desired unit(s).Tip

    You can configure both an MPLS-based Layer 2 VPN and an MPLS-based Layer 3 VPN on the same PE device. However, you cannot configure the same customer edge-facing interface to support both a Layer 2 VPN and a Layer 3 VPN.

    [edit]

    user@pe1# set interfaces ge-0/0/0 encapsulation ethernet-ccc
    [edit]

    user@pe1# set interfaces ge-0/0/0 unit 0 family ccc
    [edit]

    user@pe1# set interfaces ge-0/0/0 description "Link from PE1 to CE1"
    Note

    A Layer 2 VPN requires that the PE device’s edge-facing interfaces be configured with CCC encapsulation at the physical device level with the CCC family configured at the unit level. The provider devices are configured in the same way whether you are deploying CCC, an MPLS-based Layer 2 VPN, or an MPLS-based Layer 3 VPN. This is because they have no edge-facing interfaces or VPN awareness.

  2. Configure a BGP group for the peering between the local and remote PE devices. Use the PE device’s loopback address as the local address and enable family l2vpn signaling.
    [edit protocols bgp]

    user@pe1# set group ibgp local-address 192.168.0.1 family l2vpn signaling
  3. Configure the BGP group type as internal.
    [edit protocols bgp]

    user@pe1# set group ibgp type internal
  4. Configure the remote PE device’s loopback address as a BGP neighbor.
    [edit protocols bgp]

    user@pe1# set group ibgp neighbor 192.168.0.3
  5. Configure the BGP autonomous system number.
    [edit routing-options]

    user@pe1# set autonomous-system 65412
  6. Configure the routing instance. Start by specifying the instance name l2vpn1, with an instance-type of l2vpn.
    [edit routing-instances]

    user@pe1# set l2vpn1 instance-type l2vpn
  7. Configure the PE device’s customer-facing interface to belong to the routing instance.
    [edit routing-instances]

    user@pe1# set l2vpn1 interface ge-0/0/0
  8. Configure the routing instance’s route distinguisher. This setting is used to distinguish the routes sent from a particular VRF on a particular PE device. It should be unique for each routing instance on each PE device.
    [edit routing-instances]

    user@pe1# set l2vpn1 route-distinguisher 192.168.0.1:12
  9. Configure the instance’s virtual routing and forwarding (VRF) table route target. The vrf-target statement adds the specified community tag to all advertised routes while automatically matching the same value for route import. Configuring matching route targets on the PE devices that share a given VPN is required for proper route exchange.
    [edit routing-instances]

    user@pe1# set l2vpn1 vrf-target target:64512:12
    Note

    You can create more complex policies by explicitly configuring VRF import and export policies using the import and export options. See vrf-import and vrf-export for details.

  10. Configure the l2vpn protocol in the instance and specify the encapsulation that is used on the edge-facing link. If the edge interface is VLAN tagged, be sure to specify ethernet-vlan.
    [edit routing-instances]

    user@pe1# set l2vpn1 protocols l2vpn encapsulation-type ethernet
  11. Add the edge-facing interface under the instance’s l2vpn stanza along with a description.
    [edit routing-instances]

    user@pe1# set l2vpn1 protocols l2vpn interface ge-0/0/0.0 description "L2vpn Link Between PE1 and CE1"
  12. Configure the Layer 2 VPN site information and associate the edge-facing interface with the local customer site.
    [edit routing-instances]

    user@pe1# set l2vpn1 protocols l2vpn site CE-1 site-identifier 1 interface ge-0/0/0.0 remote-site-id 2
    Note

    In this example, the site ID for the PE1 device is 1 and the site ID for the PE2 device is 2. For the local PE device (PE1), the remote site is correctly configured with a remote-site-id value of 2.

  13. Commit your changes at the PE1 device and return to CLI operational mode.
    [edit]

    user@pe1# commit and-quit

Results

Display the results of the configuration on the PE1 device. The output reflects only the functional configuration added in this example.

user@pe1> show configuration

Configure the Remote PE (PE2) Device for a MPLS-Based Layer 2 VPN

This section covers the steps needed to configure the PE2 device for this example. Refer to the Quick Configurations section for the CE device and P device configurations used in this example.

Configure the MPLS Baseline (if Needed)

Before you configure the Layer 2 VPN make sure the PE device has a working MPLS baseline. If you already having an MPLS baseline you can skip to the step-by-step procedure to add the Layer 2 VPN to the local PE device.

  • Configure the hostname.

    [edit]

    user@pe2# set system host-name pe2
  • Configure the interfaces.

    [edit]

    user@pe2# set interfaces lo0 unit 0 family inet address 192.168.0.3/32
    [edit]

    user@pe2# set interfaces ge-0/0/1 description "Link from PE2 to P-router"
    [edit]

    user@pe2# set interfaces ge-0/0/1 unit 0 family inet address 10.1.34.2/24
    [edit]

    user@pe2# set interfaces ge-0/0/1 mtu 4000
    [edit]

    user@pe2# set interfaces ge-0/0/1 unit 0 family mpls
    Caution

    Layer 2 VPNs don’t support fragmentation in the provider network. It is critical that the provider network supports the largest frame that the CE devices can generate after the MPLS and virtual routing and forwarding (VRF) labels are added by the PE devices. This example leaves the CE devices at the default 1500-byte maximum transmission unit (MTU) while configuring the provider core to support a 4000 byte MTU. This configuration avoids discards by ensuring the CE devices cannot exceed the MTU in the provider’s network.

  • Configure the protocols.

    Note

    Traffic engineering is supported for RSVP-signaled LSPs but is not required for basic MPLS switching or VPN deployment. The provided MPLS baseline uses RSVP to signal LSPs, and enables traffic engineering for OSPF. However, no path constraints are configured so you expect the LSPs to be routed over the interior gateway protocol’s shortest path.

    [edit]

    user@pe2# set protocols ospf area 0.0.0.0 interface lo0.0
    [edit]

    user@pe2# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
    [edit]

    user@pe2# set protocols ospf traffic-engineering
    [edit]

    user@pe2# set protocols mpls interface ge-0/0/1.0
    [edit]

    user@pe2# set protocols rsvp interface lo0.0
    [edit]

    user@pe2# set protocols rsvp interface ge-0/0/1.0
  • Define the LSP to the remote PE device’s loopback address.

    [edit]

    user@pe2# set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1

Step-by-Step Procedure

Follow these steps to configure the PE2 device for a Layer 2 VPN.

  1. Configure the edge-facing interface encapsulation and family. Recall this is an untagged interface, therefore only unit 0 is valid for the ccc family.
    [edit]

    user@pe2# set interfaces ge-0/0/0 encapsulation ethernet-ccc
    [edit]

    user@pe2# set interfaces ge-0/0/0 unit 0 family ccc
    [edit]

    user@pe1# set interfaces ge-0/0/0 description "Link from PE2 to CE2"
  2. Configure a BGP group. Specify the PE device’s loopback address as the local address and enable family l2vpn signaling.
    [edit protocols bgp]

    user@pe2# set group ibgp local-address 192.168.0.3 family l2vpn signaling
  3. Configure the BGP group type as internal.
    [edit protocols bgp]

    user@pe2# set group ibgp type internal
  4. Configure the PE1 device as a BGP neighbor. Be sure to specify PE1’s loopback address as the BGP neighbor.
    [edit protocols bgp]

    user@pe2# set group ibgp neighbor 192.168.0.1
  5. Configure the BGP autonomous system number.
    [edit routing-options]

    user@pe2# set autonomous-system 65412
  6. Configure the routing instance. Start by specifying the instance name l2vpn1 with an instance-type of l2vpn.
    [edit routing-instances]

    user@pe2# set l2vpn1 instance-type l2vpn
  7. Configure the PE device’s customer edge-facing interface to belong to the routing instance.
    [edit routing-instances]

    user@pe2# set l2vpn1 interface ge-0/0/0
  8. Configure the instance’s route distinguisher.
    [edit routing-instances]

    user@pe2# set l2vpn1 route-distinguisher 192.168.0.3:12
  9. Configure the instance’s VPN virtual routing and forwarding (VRF) table route target. The assigned target must match the one configured at the PE1 device.
    [edit routing-instances]

    user@pe2# set l2vpn1 vrf-target target:64512:12
  10. Configure the instance for the l2vpn protocol and specify the encapsulation used on the edge-facing link.
    [edit routing-instances]

    user@pe2# set l2vpn1 protocols l2vpn encapsulation-type ethernet
  11. Add the PE device’s edge-facing interface under the instance’s l2vpn hierarchy along with a description .
    [edit routing-instances]

    user@pe2# set l2vpn1 protocols l2vpn interface ge-0/0/0.0 description "L2vpn Link Between PE2 and CE2"
  12. Configure the instance’s Layer 2 VPN site information and list the PE device's edge-facing interface under the local site. The local site ID configured on the PE2 device must match the remote site ID you configured on the PE1 device, and vice versa.
    [edit routing-instances]

    user@pe1# set l2vpn1 protocols l2vpn site CE-2 site-identifier 2 interface ge-0/0/0.0 remote-site-id 1
    Note

    In this example, the site ID for the PE2 device is 2 and the site ID for the PE1 device is 1. For the PE2 device the remote site is correctly configured with a remote-site-id value of 1.

  13. Commit your changes at the PE2 device and return to CLI operational mode.
    [edit]

    user@pe1# commit and-quit

Results

Display the results of the configuration on the PE2 device.

user@pe2# show

Verification

Perform these tasks to verify that the MPLS-based Layer 2 VPN works properly:

Verify Provider OSPF Adjacencies and Route Exchange

Purpose

Confirm the OSPF protocol is working properly in the provider network by verifying adjacency status and OSPF learned routes to the loopback addresses of the remote provider devices. Proper IGP operation is critical for the successful establishment of MPLS LSPs.

Action

user@pe1> show route protocol ospf | match 192.168

Meaning

The output shows that the PE1 device has established an OSPF adjacency to the P device (192.168.0.2). It also shows that the P and remote PE device loopback addresses (192.168.0.2) and (192.168.0.3) are learned via OSPF at the local PE device.

Verify MPLS and RSVP Interface Settings

Purpose

Verify that the RSVP and MPLS protocols are configured to operate on the PE device’s core-facing interfaces. This step also verifies that family mpls is correctly configured at the unit level of the core-facing interfaces.

Action

Meaning

The output shows that MPLS and RSVP are correctly configured on the local PE device’s core-facing and loopback interfaces.

Verify RSVP Signaled LSPs

Purpose

Verify that the RSVP sessions (ingress and egress) are properly established between the PE devices.

Action

Meaning

The output shows that both the ingress and egress RSVP sessions are correctly established between the PE devices. Successful LSP establishment indicates the MPLS baseline is operational.

Verify BGP Session Status

Purpose

Verify that the BGP session between the PE devices is correctly established with support for Layer 2 VPN network layer reachability information (NLRI).

Action

Meaning

The output shows the BGP session to the remote PE device (192.168.0.3) has been correctly established (Establ), and through the Up/Dwn field, how long the session has been in the current state (1:34). It also shows the number of BGP packets sent to (5) and received from (6) the remote PE device. The flaps field confirms that no state transitions have occurred (0), indicating the session is stable. Also note that Layer 2 VPN NLRI is correctly exchanged between the PE devices. This output confirms the BGP peering between the PE devices is ready to support a Layer 2 VPN.

Verify Layer 2 VPN Routes in the Routing Table

Purpose

Verify that the routing table on the PE1 device is populated with the Layer 2 VPN routes used to forward traffic between the CE devices.

Action

user@pe1> show route table bgp.l2vpn.0
user@pe1> show route table l2vpn1.l2vpn.0

Meaning

The command show route table bgp.l2vpn.0 displays all Layer 2 VPN routes that have been received on the PE device. The command show route table l2vpn1.l2vpn.0 shows the Layer 2 VPN routes that have been imported into the l2vpn1 routing instance as a result of a matching route target. The l2vpn1.l2vpn.0 table contains both the local PE device’s Layer 2 VPN route as well as a remote route learned via the BGP peering to the remote PE device. Both tables show the remote Layer 2 VPN route is correctly associated with the lsp_to_pe2 LSP as a forwarding next hop. The outputs confirm the local PE device has learned about the remote customer site from the PE2 device. It also shows that it can forward Layer 2 VPN traffic to the PE2 device using MPLS transport over the provider network.

Verify Layer 2 VPN Connection Status

Purpose

Verify the status of the Layer 2 VPN connection.

Action

Meaning

The St field in the output shows that the Layer 2 VPN connection to Remote PE 192.168.0.3 at connection-site 2 is Up. The output also confirms the PE device’s edge-facing interface name ge-0/0/0.0 and operational status as up. You also verify that Ethernet encapsulation is configured on the PE device’s customer-facing interface. This is the correct encapsulation for the untagged Ethernet interfaces used in this example. The verification steps performed thus far indicate that the Layer 2 VPN’s control plane is operational. You verify the data plane of the Layer 2 VPN in the following steps.

Ping the Remote PE Device Using the Layer 2 VPN Connection

Purpose

Verify Layer 2 VPN connectivity between the local and remote PE devices. Two forms of the ping mpls l2vpn command are shown. Both test Layer 2 VPN routing and MPLS forwarding between the PE devices. The first command assumes a single remote site while the second specifies the local and remote site identifiers, which is useful when testing a multi-site Layer 2 VPN. This is because the remote site ID can be used to target the desired remote PE device.

Note

The ping mpls l2vpn command validates Layer 2 VPN route exchange and MPLS forwarding between the PE devices. This is done by generating traffic from the local PE’s Layer 2 VPN routing instance to the remote PE device’s 127.0.0.1 loopback address. This command does not validate the operation of the CE device interfaces or their configuration. This is because CE device operation is opaque to the provider network in a Layer 2 VPN.

Action

user@pe1> ping mpls l2vpn interface ge-0/0/0.0 reply-mode ip-udp
user@pe1> ping mpls l2vpn instance l2vpn1 remote-site-id 2 local-site-id 1 detail

Meaning

The output confirms that the Layer 2 VPN forwarding plane is operating correctly between the PE devices.

Verify End-to-End Operation of the CE Devices Over the Layer 2 VPN

Purpose

Verify Layer 2 VPN connectivity between the CE devices. This step confirms the CE devices have operational interfaces and are properly configured for Layer 2 connectivity. This is done by verifying the CE devices have established an OSPF adjacency and are able to pass traffic end-to-end between their loopback addresses.

Action

user@ce1> show ospf neighbor
user@ce1> show ospf route | match 172
user@ce1> ping 172.16.255.2 size 1472 do-not-fragment count 2

Meaning

The output shows that Layer 2 VPN connectivity is working correctly between the CE devices. It confirms that the local CE device has established an OSPF adjacency over the provider core to the remote CE device 172.16.1.2, and that the local CE device has learned a route to the remote CE device's loopback address 172.16.255.2 via OSPF. The output also shows that the CE devices are able to pass 1500-byte IP packets without evoking local fragmentation. The successful pings also verify the frames did not exceed the MTU supported by the provider’s network.

Note

The size argument added to the ping command generates 1472 bytes of echo data. An additional 8 bytes of Internet Control Message Protocol (ICMP) and 20 bytes of IP header are added to bring the total packet size to 1500-bytes. Adding the do-not-fragment switch ensures the CE device cannot perform fragmentation based on its local MTU. This method confirms that no fragmentation is possible, or needed, when sending standard length Ethernet frames between the CE devices.