Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configure a Basic MPLS-Based Layer 3 VPN

This example shows how to configure and validate a basic MPLS-based Layer 3 VPN on routers or switches running Junos OS. The IPv4 based example uses EBGP as the routing protocol between the provider and customer edge devices.

Note:

Our content testing team has validated and updated this example.

You can deploy an MPLS-based Layer 3 virtual private network (VPN) using routers and switches running Junos OS to interconnect customer sites with Layer 3 connectivity. While static routing is supported, Layer 3 VPNs typically have the customer devices exchange routing information with the provider network and require support for IP protocols, i.e., IPv4 and/or IPv6.

This is in contrast with a Layer 2 VPN, where the customer devices may not be based on IP protocols, and where routing, if any, occurs between the customer edge (CE) devices. Unlike a Layer 3 VPN where the CE device interacts (peers) with the provider edge device, in a Layer 2 VPN the customer traffic passes transparently through the provider core with any routing protocols running end-to-end between the CE devices.

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 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 provider edge (PE) devices. This is a key reason why MPLS-based VPNs scale so well.

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 12.3 or later for routing and switching devices

    • Revalidated on Junos OS release 20.3R1

  • Two Provider edge (PE) devices

  • One provider (P) device

  • Two customer edge (CE) devices

The example focuses on how to add a Layer 3 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 a circuit cross-connect (CCC) connection, you do not need to manually associate the LSP with the PE device’s customer-facing (edge) interface. Instead, Layer 3 VPNs use BGP signaling to advertise site reachability. This BGP signaling automates the mapping of remote VPN sites to LSP forwarding next hops. This means that with a Layer 3 VPN explicit mapping of an LSP to a PE device’s edge-facing interface is not required.

Overview and Topology

Layer 3 VPNs allow customers to leverage the service provider’s technical expertise to ensure efficient site-to-site routing. The customer edge (CE) device typically uses a routing protocol, such as BGP or OSPF, to exchange routes with the service provider edge (PE) device. Static routing is supported for Layer 3 VPNs, but a dynamic routing protocol is generally preferred.

Definition of a VPN involves changes to the local and remote PE devices only. No additional configuration is needed on the provider devices (assuming they already have a working MPLS baseline), because these devices only provide basic MPLS switching functions. The CE devices do not use MPLS and require only a basic interface and routing protocol configuration so they can interact with the PE devices.

In a Layer 3 VPN you configure the CE devices to peer with the local PE device. This is in contrast to a Layer 2 VPN, where the CE devices peer to each other as if they were on a shared link, despite their being connected through an MPLS-based provider core.

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

  • A BGP group with family inet-vpn unicast support

  • A routing instance with instance type vrf and a routing protocol definition that is compatible with the attached CE device

  • The customer-facing interfaces on the PE devices configured with family inet along with an IPv4 address that places the interface on the same subnet as the attached CE device. If desired VLAN encapsulation and a corresponding VLAN ID can also be configured.

For proper end-to-end connectivity the CE device needs to be configured with a compatible IP subnet and routing protocol parameters to support peering with the PE device.

Figure 1 shows the topology used in this example. The figure details the interface names, IP addressing, and routing protocols used in the provider and customer networks. It also highlights the peering relationship between the CE and PE devices. In this example you expect each CE device to form an EBGP peering session to the local PE device. Note that the provider network and both customer sites have an assigned autonomous system number to support BGP operation. In this example routing policy is applied at the CE devices to have them advertise the direct routes for their provider facing and loopback interfaces.

Figure 1: An MPLS-Based Layer 3 VPN with EBGP as the PE-CE Routing ProtocolAn MPLS-Based Layer 3 VPN with EBGP as the PE-CE Routing Protocol

Quick Configurations

Use the configurations in this section to quickly get your MPLS-based Layer 3 VPN up and running. The configurations include a functional MPLS baseline to support your Layer 3 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 when in configuration mode at the [edit] hierarchy:

The complete configuration for the CE1 device.

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 3 VPN! Refer to the Verification section for the steps needed to confirm your Layer 3 VPN is working as expected.

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

This section covers the steps needed to configure the PE1 device for this example. The focus in on the PE devices because that is where the VPN configuration is housed. 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 a Layer 3 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 3 VPN to the PE devices.

  • Configure the hostname.

  • Configure the core and loopback interfaces:

    Best Practice:

    While a Layer 3 VPN can perform fragmentation at the ingress PE, its best practice to design the network so the CE can send a maximum sized frame without needing fragmentation. To ensure fragmentation does not occur the provider network should support the largest frame that the CE devices can generate after the MPLS and virtual routing and forwarding (VRF) labels are added by the PE device. 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 ensures the CE devices cannot exceed the MTU in the provider's network even with the MPLS and VRF encapsulation overhead.

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

  • Define the LSP to the remote PE device's loopback address:

The MPLS baseline is now configured on the PE1 device. Keep going to configure the Layer 3 VPN.

Procedure

Step-by-Step Procedure

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

  1. Configure the customer-facing interface:

    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.

  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 the inet-vpn unicast address family to support Layer 3 VPN route exchange. A routing policy for BGP is not needed on the PE devices in this example. By default the PE devices readvertise into IBGP the routes they learn over their EBGP peering to the CE device.

    Tip:

    You can specify other address families if the PE to PE IBGP session needs to support non-VPN route exchange, such as regular IPv4 or IPv6 routes using the inet or inet6 families, respectively.

  3. Configure the BGP group type as internal.

  4. Configure the remote PE device’s loopback address as a BGP neighbor.

  5. Configure the router ID to match its loopback address, and define the BGP autonomous system number needed for BGP peering.

  6. Configure the routing instance. Specify an instance name of CE1_L3vpn, and configure an instance-type of vrf.

  7. Configure the PE device’s customer-facing interface to belong to the routing instance.

  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.

  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.

    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 routing instance to support EBGP peering to the CE1 device. Direct interface peering to the CE1 end of the VRF link is used, and CE1’s autonomous system number is correctly specified with the peer-as parameter.

  11. Commit your changes at the PE1 device and return to CLI operational mode.

Results

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

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

This section covers the steps needed to configure the PE1 device for this example. The focus in on the PE devices because that is where the VPN configuration is housed. 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 a Layer 3 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 3 VPN to the PE devices.

  • Configure the hostname.

  • Configure the core and loopback interfaces:

    Best Practice:

    While a Layer 3 VPN can perform fragmentation at the ingress PE, its best practice to design the network so the CE can send a maximum sized frame without needing fragmentation. To ensure fragmentation does not occur the provider network should support the largest frame that the CE devices can generate after the MPLS and virtual routing and forwarding (VRF) labels are added by the PE device. 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 ensures the CE devices cannot exceed the MTU in the provider's network even with the MPLS and VRF encapsulation overhead.

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

  • Define the LSP to the remote PE device's loopback address:

The MPLS baseline is now configured on the PE1 device. Keep going to configure the Layer 3 VPN.

Procedure

Step-by-Step Procedure

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

  1. Configure the customer-facing interface:

    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.

  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 the inet-vpn unicast address family to support Layer 3 VPN route exchange.

    Tip:

    You can specify other address families if the PE to PE IBGP session needs to support non-VPN route exchange, such as regular IPv4 or IPv6 routes using the inet or inet6 families, respectively.

  3. Configure the BGP group type as internal.

  4. Configure the PE1 device’s loopback address as a BGP neighbor.

  5. Configure the router ID to match its loopback address, and define the BGP autonomous system number.

  6. Configure the routing instance. Specify an instance name of CE2_L3vpn, with an instance-type of vrf.

  7. Configure the PE device’s customer-facing interface to belong to the routing instance.

  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.

  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.

    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 routing instance to support EBGP peering to the CE2 device. Direct interface peering to the CE2 end of the VRF link is used, and CE2’s autonomous system number is correctly specified with the peer-as parameter.

  11. Commit your changes at the PE2 device and return to CLI operational mode.

Results

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

Verification

Perform these tasks to verify that the MPLS-based Layer 3 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

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 correctly 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 interface. This step also verifies that family mpls is correctly configured at the unit level of the PE device’s core-facing interface.

Action

Meaning

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

Verify RSVP Signaled LSPs

Purpose

Verify that RSVP signaled ingress and egress LSPs are correctly established between the PE device’s loopback addresses.

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 IBGP session between the PE devices is correctly established with support for Layer 3 VPN network layer reachability information (NLRI). In this step you also confirm the local PE to CE EBGP session is established and correctly configured to exchange IPv4 routes.

Action

Meaning

The output shows the IBGP 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 (6:18). The flaps field confirms that no state transitions have occurred (0), indicating the session is stable. Also note that Layer 3 VPN routes (NLRI) have been learned from the remote PE as shown by the presence of a bgp.l3vpn.0 table.

The display also confirms the EBGP session to the local CE1 device (172.16.1.1) is established and that IPv4 routes have been received from the CE1 device and installed in the CE1 device routing instance (CE1_L3vpn.inet.0)

This output confirms that the BGP peering between the PE devices, and to the CE device, is working properly to support your Layer 3 VPN.

Verify Layer 3 VPN Routes in the Routing Table

Purpose

Confirm that the routing table on the PE1 device is populated with Layer 3 VPN routes advertised by the remote PE. These routes are used to forward traffic to the remote CE device.

Action

Meaning

The show route table bgp.l3vpn.0 command displays the Layer 3 VPN routes that have been received from the remote PE device. The show route table CE1_L3vpn.inet.0 command lists the all routes that have been imported into the CE1_L3vpn routing instance. These entries represent the routes learned from the local EBGP peering to the CE1 device, in addition to those routes received from the remote PE2 device with a matching route target.

Both tables show the remote Layer 3 VPN routes are correctly associated with the lsp_to_pe2 LSP as a forwarding next hop. The outputs confirm the local PE device has learned the routes associated with the remote CE2 location from the PE2 device. It also shows that the local PE will forward Layer 3 VPN traffic to the remote PE2 device using MPLS transport over the provider network.

Ping the Remote PE Device Using the Layer 3 VPN Connection

Purpose

Verify Layer 3 VPN connectivity between the local and remote PE devices using ping. This command verifies the Layer 3 VPN routing and MPLS forwarding operation between the PE devices.

Action

Meaning

The output confirms that the Layer 3 VPN control and forwarding planes are operating correctly between the PE devices.

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

Purpose

Verify Layer 3 VPN connectivity between the CE devices. This step confirms the CE devices have operational interfaces and are properly configured for EBGP based Layer 3 connectivity. This is done by verifying the local CE1 device has learned the remote CE device’s routes, and by confirming the CE devices are able to pass traffic end-to-end between their loopback addresses.

Action

Meaning

The output shows that Layer 3 VPN based connectivity is working correctly between the CE devices. The local CE device has learned the remote CE device’s VRF interface and loopback routes through BGP. The ping is generated to the loopback address of the remote CE device, and is sourced from the local CE device’s loopback address using the source 172.16.255.1 argument. Adding the do-not-fragment and size 1472 switches confirms that the CE devices are able to pass 1500-byte IP packets without evoking fragmentation in the local PE device.

Note:

The size 1472 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 payload size to 1500-bytes. Adding the do-not-fragment switch ensures that the local CE and PE devices cannot perform fragmentation. This ping method confirms that fragmentation is not needed when exchanging standard 1500-byte maximum length Ethernet frames between the CE devices.

These results confirm the MPLS-based Layer 3 VPN is working correctly.