Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring MPLS-Based Layer 2 VPNs

You can implement an MPLS-based Layer 2 virtual private network (VPN) using Junos OS routing devices to interconnect customer sites with Layer 2 technology. Layer 2 VPNs give customers complete control of their own routing. To support an MPLS-based Layer 2 VPN, you need to add components to the configuration of the two provider edge (PE) routing devices. You do not need to change the configuration of the provider devices.

This example shows how to configure an MPLS-based Layer 2 VPN.

Note: You can configure both an MPLS-based Layer 2 VPN and an MPLS-based Layer 3 VPN on the same device. However, you cannot configure the same customer edge interface to support both a Layer 2 VPN and a Layer 3 VPN. The core interfaces and the loopback interfaces are configured in the same way for Layer 2 VPNs and Layer 3 VPNs.

Requirements

This example uses the following hardware and software components:

• Junos OS Release 11.1 or later if you are using EX Series switches
• Two PE routing devices

Before you configure the Layer 2 VPN components, configure the basic components for an MPLS network:

• Configure two PE routing devices. See Configuring MPLS on Provider Edge Switches Using Circuit Cross-Connect (CLI Procedure).
• Configure one or more provider devices. See Configuring MPLS on Provider Switches (CLI Procedure).

Note: A Layer 2 VPN requires that the PE routing devices be configured using circuit cross-connect (CCC). The provider routing devices are configured in the same way for MPLS using CCC and for IP over MPLS.

Overview and Topology

A Layer 2 VPN provides complete separation between the provider’s network and the customer’s network—that is, the PE devices and the CE devices do not exchange routing information. Some benefits of a Layer 2 VPN are that it is private, secure, and flexible.

This example shows how to configure Layer 2 VPN components on the local and remote PE devices. This example does not include configuring a provider device, because there are no specific Layer 2 VPN components on the provider devices.

In the basic MPLS configuration of the PE devices using a circuit cross-connect (CCC), the PE devices are configured to use an interior gateway protocol (IGP), such as OSPF or IS-IS, as the routing protocol between the MPLS devices and LDP or RSVP as the signaling protocol. Traffic engineering is enabled. A label-switched path (LSP) is configured within the [edit protocols] hierarchy. However, unlike the basic MPLS configuration using a CCC, you do not need to associate the LSP with the customer edge interface. When you are configuring a Layer 2 VPN, you must use BGP signaling. The BGP signaling automates the connections, so manual configuration of the association between the LSP and the customer edge interface is not required.

The following components must be added to the PE routing devices for an MPLS-based Layer 2 VPN:

• BGP group with family l2vpn signaling
• Routing instance using instance type l2vpn
• The physical layer encapsulation type (ethernet) must be specified on the customer edge interface and the encapsulation type must also be specified in the configuration of the routing instance.

Figure 1 illustrates the topology of this MPLS-based Layer 2 VPN.

Figure 1: MPLS-Based Layer 2 VPN

Table 1 shows the settings of the customer edge interface on the local CE device.

Table 2 shows the settings of the customer edge interface on the remote CE routing device.

Table 3 shows the Layer 2 VPN components of the local PE routing device.

Table 4 shows the Layer 2 VPN components of the remote PE routing device.

Configuring the Local PE Routing Device

CLI Quick Configuration

To quickly configure the Layer 2 VPN components on the local PE routing device, copy the following commands and paste them into the routing device terminal window:

Step-by-Step Procedure

1. Configure the customer edge interface to use the physical encapsulation type ethernet-ccc:
   [edit]
user@PE1# set interfaces ge-5/0/0 encapsulation ethernet-ccc
2. Configure BGP, specifying the loopback address as the local address and enabling family l2vpn signaling:
   [edit protocols bgp]
user@PE1# set local-address 21.21.21.21 family l2vpn signaling
3. Configure the BGP group, specifying the group name and type:
   [edit protocols bgp]
user@PE1# set group ibgp type internal
4. Configure the BGP neighbor, specifying the loopback address of the remote PE routing device as the neighbor’s address:
   [edit protocols bgp]
user@PE1# set neighbor 22.22.22.22
5. Configure the routing instance, specifying the routing-instance name and using l2vpn as the instance type:
   [edit routing-instances]
user@PE1# set vpn1 instance-type l2vpn
6. Configure the routing instance to apply to the customer edge interface:
   [edit routing-instances]
user@PE1# set vpn1 interface ge-5/0/0
7. Configure the routing instance to use a route distinguisher:
   [edit routing-instances]
user@PE1# set vpn1 route-distinguisher 21.21.21.21:21
8. Configure the VPN routing and forwarding (VRF) target of the routing instance:
   [edit routing-instances]
user@PE1# set vpn1 vrf-target target:21:21

   Note: You can create more complex policies by explicitly configuring VRF import and export policies using the import and export options. See the Junos OS VPNs Configuration Guide.

9. Configure the protocols and encapsulation type used by the routing instance:
   [edit routing-instances]
user@PE1# set vpn1 protocols l2vpn encapsulation-type ethernet
10. Apply the routing instance to a customer edge interface and specify a description for it:
    [edit routing-instances]
user@PE1# set vpn1 protocols interface ge-5/0/0.0 description "BETWEEN PE1 AND PE2"
11. Configure the routing-instance protocols site:
    [edit routing-instances]
user@PE1# set vpn1 protocols l2vpn site JE-V21 site-identifier 21remote-site-id 26

    Note: The remote site ID (configured with the remote-site-id statement) corresponds to the site ID (configured with the site-identifier statement) configured on the other PE routing device.

Results

Display the results of the configuration:

Configuring the Remote PE Routing Device

CLI Quick Configuration

To quickly configure the Layer 2 VPN components on the remote PE routing device, copy the following commands and paste them into the routing device terminal window:

Step-by-Step Procedure

1. Configure the customer edge interface to use the physical encapsulation type ethernet-ccc:
   [edit]
user@PE1# set interfaces ge-11/0/0 encapsulation ethernet-ccc
2. Configure BGP, specifying the loopback address as the local-address and specifying family l2vpn signaling:
   [edit protocols bgp]
user@PE2# set local-address 22.22.22.22 family l2vpn signaling
3. Configure the BGP group, specifying the group name and type:
   [edit protocols bgp]
user@PE2# set group ibgp type internal
4. Configure the BGP neighbor, specifying the loopback address of the remote PE routing device as the neighbor’s address:
   [edit protocols bgp]
user@PE2# set neighbor 21.21.21.21
5. Configure the routing instance, specifying the routing-instance name and using l2vpn as the instance-type:
   [edit routing-instances]
user@PE2# set vpn1 instance-type l2vpn
6. Configure the routing instance to apply to the customer edge interface:
   [edit routing-instances]
user@PE2# set vpn1 interface ge-11/0/0.0
7. Configure the routing instance to use a route distinguisher, using the format ip-address:number:
   [edit routing-instances]
user@PE2# set vpn1 route-distinguisher 21.21.21.21:21
8. Configure the VPN routing and forwarding (VRF) target of the routing instance:
   [edit routing-instances]
user@PE2# set vpn1 vrf-target target:21:21
9. Configure the protocols and encapsulation type used by the routing instance:
   [edit routing-instances]
user@PE2# set vpn1 protocols l2vpn encapsulation-type ethernet
10. Apply the routing instance to a customer edge interface and specify a description for it:
    [edit routing-instances]
user@PE1# set vpn1 protocols interface ge-11/0/0.0 description "BETWEEN PE1 AND PE2"
11. Configure the routing-instance protocols site:
    [edit routing-instances]
user@PE2# set vpn1 protocols l2vpn site T26-VPN1 site-identifier 26 remote-site-id 21

    Note: The remote site ID (configured with the remote-site-id statement) corresponds to the site ID (configured with the site-identifier statement) configured on the other PE routing device.

Results

Display the results of the configuration:

Verification

To confirm that the MPLS-based Layer 2 VPN is working properly, perform these tasks:

• Verifying the Layer 2 VPN Connection
• Verifying the Status of MPLS Label-Switched Paths
• Verifying BGP Status
• Verifying the Status of the RSVP Sessions
• Verifying the Routes in the Routing Table
• Pinging the Layer 2 VPN Connections

Verifying the Layer 2 VPN Connection

Purpose

Verify that the Layer 2 VPN connection is up.

Action

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 availble
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor

Legend for interface status
Up -- operational
Dn -- down

Instance: vpn1
  Local site: JE-V21 (21)
    connection-site           Type  St     Time last up          # Up trans
    26                        rmt   Up     Apr 16 05:53:21 2010           1
      Remote PE: 22.22.22.22, Negotiated control-word: Yes (Null)
      Incoming label: 800000, Outgoing label: 800001
      Local interface: ge-5/0/0.0, Status: Up, Encapsulation: ETHERNET

Meaning

The St field in the output shows that the Layer 2 VPN connection to Remote PE (22.22.22.22) is up.

Verifying the Status of MPLS Label-Switched Paths

Purpose

Verify that the MPLS label-switched paths (ingress and egress) are up.

Action

Ingress LSP: 1 sessions

To              From            State Rt P     ActivePath       LSPname
22.22.22.22     21.21.21.21     Up     0 *                      lsp_to_pe2

Total 1 displayed, Up 1, Down 0


Egress LSP: 1 sessions

To              From            State   Rt Style Labelin Labelout LSPname

21.21.21.21     22.22.22.22     Up       0  1 FF       3        - lsp_to_pe1

Total 1 displayed, Up 1, Down 0


Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning

The State field in the output shows that the Ingress LSP to Remote PE (22.22.22.22) is up, and the Egress LSP from the remote PE routing device to this PE routing device (21.21.21.21) is also up.

Verifying BGP Status

Purpose

Verify that BGP is up.

Action

Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l2vpn.0            1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
22.22.22.22              10         33         34       0       1       13:24 Establ
  bgp.l2vpn.0: 1/1/1/0
  vpn2.l2vpn.0: 1/1/1/0

Meaning

The output shows that the remote PE routing device (22.22.22.22) is listed as the BGP peer and that a protocol session has been established. It also shows the number of packets received from the remote PE routing device (33) and the number of packets sent (34) to the remote PE routing device.

Verifying the Status of the RSVP Sessions

Purpose

Verify that the RSVP sessions (ingress and egress) are up.

Action

Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
22.22.22.22     21.21.21.21     Up       0  1 FF       -   462880 lsp_to_pe2
Total 1 displayed, Up 1, Down 0


Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
21.21.21.21     22.22.22.22     Up       0  1 FF       3        - lsp_to_pe1
Total 1 displayed, Up 1, Down 0


Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning

The output shows that both the ingress RSVP session and the egress RSVP session are up.

Verifying the Routes in the Routing Table

Purpose

On routing device PE 1, use the show route table command to verify that the routing table is populated with the Layer 2 VPN routes used to forward the traffic.

Action

bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


2:2:27:27/96
                   *[BGP/170] 00:13:55, localpref 100, from 22.22.22.22
                      AS path: I
                    > to 60.2.0.24 via ge-6/0/46.0, label-switched-path lsp_to_pe2

vpn1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


2:2:27:27/96

                   *[BGP/170] 00:14:00, localpref 100, from 22.22.22.22
                      AS path: I

                    > to 60.2.0.24 via ge-6/0/46.0, label-switched-path lsp_to_pe2
2:2:28:27/96

                   *[L2VPN/170/-101] 00:15:55, metric2 1
                      Indirect

Meaning

The command show route table bgp.l2vpn.0 displays all Layer 2 VPN routes that have been created on this routing device. The command show route table vpn1.l2vpn.0 shows the Layer 2 VPN routes that have been created for the routing instance vpn1.

Pinging the Layer 2 VPN Connections

Purpose

Verify connectivity.

Action

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

Request for seq 1, to interface 68, labels <800001, 100176>
Reply for seq 1, return code: Egress-ok
Request for seq 2, to interface 68, labels <800001, 100176>
Reply for seq 2, return code: Egress-ok
Request for seq 3, to interface 68, labels <800001, 100176>
Reply for seq 3, return code: Egress-ok
Request for seq 4, to interface 68, labels <800001, 100176>
Reply for seq 4, return code: Egress-ok
Request for seq 5, to interface 68, labels <800001, 100176>
Reply for seq 5, return code: Egress-ok

--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

Meaning

The output shows that connectivity is established.