- play_arrow Common Configuration for All VPNs
- play_arrow VPNs Overview
- play_arrow Assigning Routing Instances to VPNs
- play_arrow Distributing Routes in VPNs
- play_arrow Distributing VPN Routes with Target Filtering
- Configuring BGP Route Target Filtering for VPNs
- Example: BGP Route Target Filtering for VPNs
- Example: Configuring BGP Route Target Filtering for VPNs
- Configuring Static Route Target Filtering for VPNs
- Understanding Proxy BGP Route Target Filtering for VPNs
- Example: Configuring Proxy BGP Route Target Filtering for VPNs
- Example: Configuring an Export Policy for BGP Route Target Filtering for VPNs
- Reducing Network Resource Use with Static Route Target Filtering for VPNs
- play_arrow Configuring Forwarding Options for VPNs
- play_arrow Configuring Graceful Restart for VPNs
- play_arrow Configuring Class of Service for VPNs
- play_arrow Pinging VPNs
-
- play_arrow Common Configuration for Layer 2 VPNs and VPLS
- play_arrow Overview
- play_arrow Layer 2 VPNs Configuration Overview
- play_arrow Configuring Layer 2 Interfaces
- play_arrow Configuring Path Selection for Layer 2 VPNs and VPLS
- play_arrow Creating Backup Connections with Redundant Pseudowires
- play_arrow Configuring Class of Service for Layer 2 VPNs
- play_arrow Monitoring Layer 2 VPNs
- Configuring BFD for Layer 2 VPN and VPLS
- BFD Support for VCCV for Layer 2 VPNs, Layer 2 Circuits, and VPLS
- Configuring BFD for VCCV for Layer 2 VPNs, Layer 2 Circuits, and VPLS
- Connectivity Fault Management Support for EVPN and Layer 2 VPN Overview
- Configure a MEP to Generate and Respond to CFM Protocol Messages
-
- play_arrow Configuring Group VPNs
- play_arrow Configuring Public Key Infrastructure
- play_arrow Configuring Digital Certificate Validation
- play_arrow Configuring a Device for Certificate Chains
- play_arrow Managing Certificate Revocation
-
- play_arrow Configuring Layer 2 Circuits
- play_arrow Overview
- play_arrow Layer 2 Circuits Configuration Overview
- play_arrow Configuring Class of Service with Layer 2 Circuits
- play_arrow Configuring Pseudowire Redundancy for Layer 2 Circuits
- play_arrow Configuring Load Balancing for Layer 2 Circuits
- play_arrow Configuring Protection Features for Layer 2 Circuits
- Egress Protection LSPs for Layer 2 Circuits
- Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services
- Example: Configuring an Egress Protection LSP for a Layer 2 Circuit
- Example: Configuring Layer 2 Circuit Protect Interfaces
- Example: Configuring Layer 2 Circuit Switching Protection
- play_arrow Monitoring Layer 2 Circuits with BFD
- play_arrow Troubleshooting Layer 2 Circuits
-
- play_arrow Configuring VPWS VPNs
- play_arrow Overview
- play_arrow Configuring VPWS VPNs
- Understanding FEC 129 BGP Autodiscovery for VPWS
- Example: Configuring FEC 129 BGP Autodiscovery for VPWS
- Example: Configuring MPLS Egress Protection Service Mirroring for BGP Signaled Layer 2 Services
- Understanding Multisegment Pseudowire for FEC 129
- Example: Configuring a Multisegment Pseudowire
- Configuring the FAT Flow Label for FEC 128 VPWS Pseudowires for Load-Balancing MPLS Traffic
- Configuring the FAT Flow Label for FEC 129 VPWS Pseudowires for Load-Balancing MPLS Traffic
-
- play_arrow Configuring VPLS
- play_arrow Overview
- play_arrow VPLS Configuration Overview
- play_arrow Configuring Signaling Protocols for VPLS
- VPLS Routing and Virtual Ports
- BGP Signaling for VPLS PE Routers Overview
- Control Word for BGP VPLS Overview
- Configuring a Control Word for BGP VPLS
- BGP Route Reflectors for VPLS
- Interoperability Between BGP Signaling and LDP Signaling in VPLS
- Configuring Interoperability Between BGP Signaling and LDP Signaling in VPLS
- Example: VPLS Configuration (BGP Signaling)
- Example: VPLS Configuration (BGP and LDP Interworking)
- play_arrow Assigning Routing Instances to VPLS
- Configuring VPLS Routing Instances
- Configuring a VPLS Routing Instance
- Support of Inner VLAN List and Inner VLAN Range for Qualified BUM Pruning on a Dual-Tagged Interface for a VPLS Routing Instance Overview
- Configuring Qualified BUM Pruning for a Dual-Tagged Interface with Inner VLAN list and InnerVLAN range for a VPLS Routing Instance
- Configuring a Layer 2 Control Protocol Routing Instance
- PE Router Mesh Groups for VPLS Routing Instances
- Configuring VPLS Fast Reroute Priority
- Specifying the VT Interfaces Used by VPLS Routing Instances
- Understanding PIM Snooping for VPLS
- Example: Configuring PIM Snooping for VPLS
- VPLS Label Blocks Operation
- Configuring the Label Block Size for VPLS
- Example: Building a VPLS From Router 1 to Router 3 to Validate Label Blocks
- play_arrow Associating Interfaces with VPLS
- play_arrow Configuring Pseudowires
- Configuring Static Pseudowires for VPLS
- VPLS Path Selection Process for PE Routers
- BGP and VPLS Path Selection for Multihomed PE Routers
- Dynamic Profiles for VPLS Pseudowires
- Use Cases for Dynamic Profiles for VPLS Pseudowires
- Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions
- Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions
- Configuring the FAT Flow Label for FEC 128 VPLS Pseudowires for Load-Balancing MPLS Traffic
- Configuring the FAT Flow Label for FEC 129 VPLS Pseudowires for Load-Balancing MPLS Traffic
- Example: Configuring H-VPLS BGP-Based and LDP-Based VPLS Interoperation
- Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke Router
- Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate the Layer 2 Circuits
- Example: Configuring H-VPLS With VLANs
- Example: Configuring H-VPLS Without VLANs
- Configure Hot-Standby Pseudowire Redundancy in H-VPLS
- Sample Scenario of H-VPLS on ACX Series Routers for IPTV Services
- play_arrow Configuring Multihoming
- VPLS Multihoming Overview
- Advantages of Using Autodiscovery for VPLS Multihoming
- Example: Configuring FEC 129 BGP Autodiscovery for VPWS
- Example: Configuring BGP Autodiscovery for LDP VPLS
- Example: Configuring BGP Autodiscovery for LDP VPLS with User-Defined Mesh Groups
- VPLS Multihoming Reactions to Network Failures
- Configuring VPLS Multihoming
- Example: VPLS Multihoming, Improved Convergence Time
- Example: Configuring VPLS Multihoming (FEC 129)
- Next-Generation VPLS for Multicast with Multihoming Overview
- Example: Next-Generation VPLS for Multicast with Multihoming
- play_arrow Configuring Point-to-Multipoint LSPs
- play_arrow Configuring Inter-AS VPLS and IRB VPLS
- play_arrow Configuring Load Balancing and Performance
- Configuring VPLS Load Balancing
- Configuring VPLS Load Balancing Based on IP and MPLS Information
- Configuring VPLS Load Balancing on MX Series 5G Universal Routing Platforms
- Example: Configuring Loop Prevention in VPLS Network Due to MAC Moves
- Understanding MAC Pinning
- Configuring MAC Pinning on Access Interfaces for Bridge Domains
- Configuring MAC Pinning on Trunk Interfaces for Bridge Domains
- Configuring MAC Pinning on Access Interfaces for Bridge Domains in a Virtual Switch
- Configuring MAC Pinning on Trunk Interfaces for Bridge Domains in a Virtual Switch
- Configuring MAC Pinning for All Pseudowires of the VPLS Routing Instance (LDP and BGP)
- Configuring MAC Pinning on VPLS CE Interface
- Configuring MAC Pinning for All Pseudowires of the VPLS Site in a BGP-Based VPLS Routing Instance
- Configuring MAC Pinning on All Pseudowires of a Specific Neighbor of LDP-Based VPLS Routing Instance
- Configuring MAC Pinning on Access Interfaces for Logical Systems
- Configuring MAC Pinning on Trunk Interfaces for Logical Systems
- Configuring MAC Pinning on Access Interfaces in Virtual Switches for Logical Systems
- Configuring MAC Pinning on Trunk Interfaces in Virtual Switches for Logical Systems
- Configuring MAC Pinning for All Pseudowires of the VPLS Routing Instance (LDP and BGP) for Logical Systems
- Configuring MAC Pinning on VPLS CE Interface for Logical Systems
- Configuring MAC Pinning for All Pseudowires of the VPLS Site in a BGP-Based VPLS Routing Instance for Logical Systems
- Configuring MAC Pinning on All Pseudowires of a Specific Neighbor of LDP-Based VPLS Routing Instance for Logical Systems
- Example: Prevention of Loops in Bridge Domains by Enabling the MAC Pinnning Feature on Access Interfaces
- Example: Prevention of Loops in Bridge Domains by Enabling the MAC Pinnning Feature on Trunk Interfaces
- Configuring Improved VPLS MAC Address Learning on T4000 Routers with Type 5 FPCs
- Understanding Qualified MAC Learning
- Qualified Learning VPLS Routing Instance Behavior
- Configuring Qualified MAC Learning
- play_arrow Configuring Class of Service and Firewall Filters in VPLS
- play_arrow Monitoring and Tracing VPLS
-
- play_arrow Configuration Statements and Operational Commands
Example: Interconnecting a Layer 2 VPN with a Layer 3 VPN
This example provides a step-by-step procedure and commands for interconnecting and verifying a Layer 2 VPN with a Layer 3 VPN. It contains the following sections:
Requirements
This example uses the following hardware and software components:
Junos OS Release 9.3 or later
Five MX Series routers
Three M Series routers
Two T Series routers
Overview and Topology
A Layer 2 VPN is a type of virtual private network (VPN) that uses MPLS labels to transport data. The communication occurs between the provider edge (PE) routers.
Layer 2 VPNs use BGP as the signaling protocol and, consequently, have a simpler design and require less provisioning overhead than traditional VPNs over Layer 2 circuits. BGP signaling also enables autodiscovery of Layer 2 VPN peers. Layer 2 VPNs can have either a full-mesh or a hub-and-spoke topology. The tunneling mechanism in the core network is, typically, MPLS. However, Layer 2 VPNs can also use other tunneling protocols, such as GRE.
Layer 3 VPNs are based on RFC 2547bis, BGP/MPLS IP VPNs. RFC 2547bis defines a mechanism by which service providers can use their IP backbones to provide VPN services to their customers. A Layer 3 VPN is a set of sites that share common routing information and whose connectivity is controlled by a collection of policies. The sites that make up a Layer 3 VPN are connected over a provider’s existing public Internet backbone. RFC 2547bis VPNs are also known as BGP/MPLS VPNs because BGP is used to distribute VPN routing information across the provider’s backbone, and MPLS is used to forward VPN traffic across the backbone to remote VPN sites.
Customer networks, because they are private, can use either public addresses or private addresses, as defined in RFC 1918, Address Allocation for Private Internets. When customer networks that use private addresses connect to the public Internet infrastructure, the private addresses might overlap with the same private addresses used by other network users. MPLS/BGP VPNs solve this problem by adding a route distinguisher. A route distinguisher is a VPN identifier prefix that is added to each address from a particular VPN site, thereby creating an address that is unique both within the VPN and within the Internet.
In addition, each VPN has its own VPN-specific routing table that contains the routing information for that VPN only. To separate a VPN’s routes from routes in the public Internet or those in other VPNs, the PE router creates a separate routing table for each VPN called a VPN routing and forwarding (VRF) table. The PE router creates one VRF table for each VPN that has a connection to a customer edge (CE) router. Any customer or site that belongs to the VPN can access only the routes in the VRF tables for that VPN. Every VRF table has one or more extended community attributes associated with it that identify the route as belonging to a specific collection of routers. One of these, the route target attribute, identifies a collection of sites (VRF tables) to which a PE router distributes routes. The PE router uses the route target to constrain the import of remote routes into its VRF tables.
When an ingress PE router receives routes advertised from a directly connected CE router, it checks the received route against the VRF export policy for that VPN.
If it matches, the route is converted to VPN-IPv4 format—that is, the route distinguisher is added to the route. The PE router then announces the route in VPN-IPv4 format to the remote PE routers. It also attaches a route target to each route learned from the directly connected sites. The route target attached to the route is based on the value of the VRF table’s configured export target policy. The routes are then distributed using IBGP sessions, which are configured in the provider’s core network.
If the route from the CE router does not match, it is not exported to other PE routers, but it can still be used locally for routing, for example, if two CE routers in the same VPN are directly connected to the same PE router.
When an egress PE router receives a route, it checks it against the import policy on the IBGP session between the PE routers. If it is accepted, the router places the route into its bgp.l3vpn.0 table. At the same time, the router checks the route against the VRF import policy for the VPN. If it matches, the route distinguisher is removed from the route and the route is placed into the VRF table (the routing-instance-name.inet.0 table) in IPv4 format.
Topology
Figure 1 shows the physical topology of a Layer 2 VPN-to-Layer 3 VPN interconnection.

The logical topology of a Layer 2 VPN-to-Layer 3 VPN interconnection is shown in Figure 2.

The following definitions describe the meaning of the device abbreviations used in Figure 1 and Figure 2.
Customer edge (CE) device—A device at the customer premises that provides access to the service provider’s VPN over a data link to one or more provider edge (PE) routers.
Typically the CE device is an IP router that establishes an adjacency with its directly connected PE routers. After the adjacency is established, the CE router advertises the site’s local VPN routes to the PE router and learns remote VPN routes from the PE router.
Provider edge (PE) device—A device, or set of devices, at the edge of the provider network that presents the provider's view of the customer site.
PE routers exchange routing information with CE routers. PE routers are aware of the VPNs that connect through them, and PE routers maintain VPN state. A PE router is only required to maintain VPN routes for those VPNs to which it is directly attached. After learning local VPN routes from CE routers, a PE router exchanges VPN routing information with other PE routers using IBGP. Finally, when using MPLS to forward VPN data traffic across the provider’s backbone, the ingress PE router functions as the ingress label-switching router (LSR) and the egress PE router functions as the egress LSR.
Provider (P) device—A device that operates inside the provider's core network and does not directly interface to any CE.
Although the P device is a key part of implementing VPNs for the service provider’s customers and may provide routing for many provider-operated tunnels that belong to different VPNs, it is not itself VPN-aware and does not maintain VPN state. Its principal role is allowing the service provider to scale its VPN offerings, for example, by acting as an aggregation point for multiple PE routers.
P routers function as MPLS transit LSRs when forwarding VPN data traffic between PE routers. P routers are required only to maintain routes to the provider’s PE routers; they are not required to maintain specific VPN routing information for each customer site.
Configuration
To interconnect a Layer 2 VPN with a Layer 3 VPN, perform these tasks:
Configuring the Base Protocols and Interfaces
Step-by-Step Procedure
On each PE and P router, configure OSPF with traffic engineering extensions on all interfaces. Disable OSPF on the fxp0.0 interface.
content_copy zoom_out_map[edit protocols] ospf { traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } }
On all the core routers, enable MPLS on all interfaces. Disable MPLS on the fxp0.0 interface.
content_copy zoom_out_map[edit protocols] mpls { interface all; interface fxp0.0 { disable; } }
On all the core routers, create an internal BGP peer group and specify the route reflector address (192.0.2.7) as the neighbor. Also enable BGP to carry Layer 2 VPLS network layer reachability information (NLRI) messages for this peer group by including the
signaling
statement at the[edit protocols bgp group group-name family l2vpn]
hierarchy level.content_copy zoom_out_map[edit protocols] bgp { group RR { type internal; local-address 192.0.2.2; family l2vpn { signaling; } neighbor 192.0.2.7; } }
On Router PE3, create an internal BGP peer group and specify the route reflector IP address (192.0.2.7) as the neighbor. Enable BGP to carry Layer 2 VPLS NLRI messages for this peer group and enable the processing of VPN-IPv4 addresses by including the
unicast
statement at the[edit protocols bgp group group-name family inet-vpn]
hierarchy level.content_copy zoom_out_map[edit protocols] bgp { group RR { type internal; local-address 192.0.2.3; family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 192.0.2.7; } }
For the Layer 3 VPN domain on Router PE3 and Router PE5, enable RSVP on all interfaces. Disable RSVP on the fxp0.0 interface.
content_copy zoom_out_map[edit protocols] rsvp { interface all; interface fxp0.0 { disable; } }
On Router PE3 and Router PE5, create label-switched paths (LSPs) to the route reflector and the other PE routers. The following example shows the configuration on Router PE5.
content_copy zoom_out_map[edit protocols] mpls { label-switched-path to-RR { to 192.0.2.7; } label-switched-path to-PE2 { to 192.0.2.2; } label-switched-path to-PE3 { to 192.0.2.3; } label-switched-path to-PE4 { to 192.0.2.4; } label-switched-path to-PE1 { to 192.0.2.1; } }
On Routers PE1, PE2, PE3, and PE5, configure the core interfaces with an IPv4 address and enable the MPLS address family. The following example shows the configuration of the xe-0/1/0 interface on Router PE2.
content_copy zoom_out_map[edit] interfaces { xe-0/1/0 { unit 0 { family inet { address 10.10.2.2/30; } family mpls; } } }
On Router PE2 and Router PE3, configure LDP for the Layer 2 VPN MPLS signaling protocol for all interfaces. Disable LDP on the fxp0.0 interface. (RSVP can also be used.)
content_copy zoom_out_map[edit protocols] ldp { interface all; interface fxp0.0 { disable; } }
On the route reflector, create an internal BGP peer group and specify the PE routers IP addresses as the neighbors.
content_copy zoom_out_map[edit] protocols { bgp { group RR { type internal; local-address 192.0.2.7; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } cluster 192.0.2.7; neighbor 192.0.2.1; neighbor 192.0.2.2; neighbor 192.0.2.4; neighbor 192.0.2.5; neighbor 192.0.2.3; } } }
On the route reflector, configure MPLS LSPs towards Routers PE3 and PE5 to resolve the BGP next hops from inet.3 routing table.
content_copy zoom_out_map[edit] protocols { mpls { label-switched-path to-pe3 { to 192.0.2.3; } label-switched-path to-pe5 { to 192.0.2.5; } interface all; } }
Configuring the VPN Interfaces
Step-by-Step Procedure
Router PE2 is one end of the Layer 2 VPN. Router PE3 is performing the Layer 2 VPN stitching between the Layer 2 VPN and the Layer 3 VPN. Router PE3 uses the logical tunnel interface (lt interface) configured with different logical interface units applied under two different Layer 2 VPN instances. The packet is looped though the lt interface configured on Router PE3. The configuration of Router PE5 contains the PE-CE interface.
On Router PE2, configure the ge-1/0/2 interface encapsulation. Include the encapsulation statement and specify the
ethernet-ccc
option (vlan-ccc
encapsulation is also supported) at the[edit interfaces ge-1/0/2]
hierarchy level. The encapsulation should be the same in a whole Layer 2 VPN domain (Routers PE2 and PE3). Also, configure interface lo0.content_copy zoom_out_map[edit] interfaces { ge-1/0/2 { encapsulation ethernet-ccc; unit 0; } lo0 { unit 0 { family inet { address 192.0.2.2/24; } } } }
On Router PE2, configure the routing instance at the [
edit routing-instances]
hierarchy level. Also, configure the Layer 2 VPN protocol at the [edit routing-instances routing-instances-name protocols]
hierarchy level. Configure the remote site ID as 3. Site ID 3 represents Router PE3 (Hub-PE). The Layer 2 VPN is using LDP as the signaling protocol. Be aware that in the following example, both the routing instance and the protocol are namedl2vpn
.content_copy zoom_out_map[edit] routing-instances {
l2vpn
{ # routing instance instance-type l2vpn; interface ge-1/0/2.0; route-distinguisher 65000:2; vrf-target target:65000:2; protocols {l2vpn
{ # protocol encapsulation-type ethernet; site CE2 { site-identifier 2; interface ge-1/0/2.0 { remote-site-id 3; } } } } } }On Router PE5, configure the Gigabit Ethernet interface for the PE-CE link
ge-2/0/0
and configure thelo0
interface.content_copy zoom_out_map[edit interfaces] ge-2/0/0 { unit 0 { family inet { address 198.51.100.8/24; } } } lo0 { unit 0 { } }
On Router PE5, configure the Layer 3 VPN routing instance (
L3VPN
) at the[edit routing-instances]
hierarchy level. Also configure BGP at the[edit routing-instances L3VPN protocols]
hierarchy level.content_copy zoom_out_map[edit] routing-instances { L3VPN { instance-type vrf; interface ge-2/0/0.0; route-distinguisher 65000:5; vrf-target target:65000:2; vrf-table-label; protocols { bgp { group ce5 { neighbor 198.51.100.2 { peer-as 200; } } } } } }
In an MX Series router, such as Router PE3, you must create the tunnel services interface to be used for tunnel services. To create the tunnel service interface, include the
bandwidth
statement and specify the amount of bandwidth to reserve for tunnel services in gigabits per second at the[edit chassis fpc slot-number pic slot-number tunnel-services]
hierarchy level.content_copy zoom_out_map[edit] chassis { dump-on-panic; fpc 1 { pic 1 { tunnel-services { bandwidth 1g; } } } }
On Router PE3, configure the Gigabit Ethernet interface.
Include the
address
statement at the[edit interfaces ge-1/0/1.0 family inet]
hierarchy level and specify198.51.100.9/24
as the IP address.content_copy zoom_out_map[edit] interfaces { ge-1/0/1 { unit 0 { family inet { address 198.51.100.9/24; } } } }
On Router PE3, configure the
lt-1/1/10.0
logical tunnel interface at the[edit interfaces lt-1/1/10 unit 0]
hierarchy level. Router PE3 is the router that is stitching the Layer 2 VPN to the Layer 3 VPN using the logical tunnel interface. The configuration of the peer unit interfaces is what makes the interconnection.To configure the interface, include the
encapsulation
statement and specify theethernet-ccc
option. Include thepeer-unit
statement and specify the logical interface unit1
as the peer tunnel interface. Include thefamily
statement and specify theccc
option.content_copy zoom_out_map[edit] interfaces { lt-1/1/10 { unit 0 { encapsulation ethernet-ccc; peer-unit 1; family ccc; } } }
On Router PE3, configure the
lt-1/1/10.1
logical tunnel interface at the[edit interfaces lt-1/1/10 unit 1]
hierarchy level.To configure the interface, include the
encapsulation
statement and specify theethernet
option. Include thepeer-unit
statement and specify the logical interface unit0
as the peer tunnel interface. Include thefamily
statement and specify theinet
option. Include theaddress
statement at the[edit interfaces lt-1/1/10 unit 0]
hierarchy level and specify198.51.100.7/24
as the IPv4 address.content_copy zoom_out_map[edit] interfaces { lt-1/1/10 { unit 1 { encapsulation ethernet; peer-unit 0; family inet { address 198.51.100.7/24; } } } }
On Router PE3, add the
lt
interface unit 1 to the routing instance at the[edit routing-instances L3VPN]
hierarchy level. Configure the instance type asvrf
withlt
peer-unit 1 as a PE-CE interface to terminate the Layer 2 VPN on Router PE2 into the Layer 3 VPN on Router PE3.content_copy zoom_out_map[edit] routing-instances { L3VPN { instance-type vrf; interface ge-1/0/1.0; interface lt-1/1/10.1; route-distinguisher 65000:33; vrf-target target:65000:2; vrf-table-label; protocols { bgp { export direct; group ce3 { neighbor 198.51.100.10 { peer-as 100; } } } } } }
On Router PE3, add the
lt
interface unit 0 to the routing instance at the[edit routing-instances protocols l2vpn]
hierarchy level. Also configure the same vrf target for the Layer 2 VPN and Layer 3 VPN routing instances, so that the routes can be leaked between the instances. The example configuration in the previous step shows the vrf target for theL3VPN
routing instance. The following example shows the vrf target for thel2vpn
routing instance.content_copy zoom_out_map[edit] routing-instances { l2vpn { instance-type l2vpn; interface lt-1/1/10.0; route-distinguisher 65000:3; vrf-target target:65000:2; protocols { l2vpn { encapsulation-type ethernet; site CE3 { site-identifier 3; interface lt-1/1/10.0 { remote-site-id 2; } } } } } }
On Router PE3, configure the
policy-statement
statement to export the routes learned from the directly connectedlt
interface unit 1 to all the CE routers for connectivity, if needed.content_copy zoom_out_map[edit] policy-options { policy-statement direct { term 1 { from protocol direct; then accept; } } }
Results
The following output shows the full configuration of Router PE2:
Router PE2
interfaces { xe-0/1/0 { unit 0 { family inet { address 10.10.2.2/30; } family mpls; } } xe-0/2/0 { unit 0 { family inet { address 10.10.5.1/30; } family mpls; } } xe-0/3/0 { unit 0 { family inet { address 10.10.4.1/30; } family mpls; } } ge-1/0/2 { encapsulation ethernet-ccc; unit 0; } fxp0 { apply-groups [ re0 re1 ]; } lo0 { unit 0 { family inet { address 192.0.2.2/24; } } } } routing-options { static { route 172.0.0.0/8 next-hop 172.19.59.1; } autonomous-system 65000; } protocols { mpls { interface all; interface fxp0.0 { disable; } } bgp { group RR { type internal; local-address 192.0.2.2; family l2vpn { signaling; } neighbor 192.0.2.7; } } ospf { traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } ldp { interface all; interface fxp0.0 { disable; } } } routing-instances { l2vpn { instance-type l2vpn; interface ge-1/0/2.0; route-distinguisher 65000:2; vrf-target target:65000:2; protocols { l2vpn { encapsulation-type ethernet; site CE2 { site-identifier 2; interface ge-1/0/2.0 { remote-site-id 3; } } } } } }
The following output shows the final configuration of Router PE5:
Router PE5
interfaces { ge-0/0/0 { unit 0 { family inet { address 10.10.4.2/30; } family mpls; } } xe-0/1/0 { unit 0 { family inet { address 10.10.6.2/30; } family mpls; } } ge-1/0/0 { unit 0 { family inet { address 10.10.9.1/30; } family mpls; } } xe-1/1/0 { unit 0 { family inet { address 10.10.3.2/30; } family mpls; } } ge-2/0/0 { unit 0 { family inet { address 198.51.100.8/24; } } } lo0 { unit 0 { family inet { address 192.0.2.5/24; } } } } routing-options { static { route 172.0.0.0/8 next-hop 172.19.59.1; } autonomous-system 65000; } protocols { rsvp { interface all { link-protection; } interface fxp0.0 { disable; } } mpls { label-switched-path to-RR { to 192.0.2.7; } label-switched-path to-PE2 { to 192.0.2.2; } label-switched-path to-PE3 { to 192.0.2.3; } label-switched-path to-PE4 { to 192.0.2.4; } label-switched-path to-PE1 { to 192.0.2.1; } interface all; interface fxp0.0 { disable; } } bgp { group to-rr { type internal; local-address 192.0.2.5; family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 192.0.2.7; } } ospf { traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } ldp { interface all; interface fxp0.0 { disable; } } } routing-instances { L3VPN { instance-type vrf; interface ge-2/0/0.0; route-distinguisher 65000:5; vrf-target target:65000:2; vrf-table-label; protocols { bgp { group ce5 { neighbor 198.51.100.2 { peer-as 200; } } } } } }
The following output shows the final configuration of Router PE3:
Router PE3
chassis { dump-on-panic; fpc 1 { pic 1 { tunnel-services { bandwidth 1g; } } } network-services ip; } interfaces { ge-1/0/1 { unit 0 { family inet { address 198.51.100.9/24; } } } lt-1/1/10 { unit 0 { encapsulation ethernet-ccc; peer-unit 1; family ccc; } unit 1 { encapsulation ethernet; peer-unit 0; family inet { address 198.51.100.7/24; } } } xe-2/0/0 { unit 0 { family inet { address 10.10.20.2/30; } family mpls; } } xe-2/1/0 { unit 0 { family inet { address 10.10.6.1/30; } family mpls; } } xe-2/2/0 { unit 0 { family inet { address 10.10.5.2/30; } family mpls; } } xe-2/3/0 { unit 0 { family inet { address 10.10.1.2/30; } family mpls; } } lo0 { unit 0 { family inet { address 192.0.2.3/24; } } } } routing-options { static { route 172.0.0.0/8 next-hop 172.19.59.1; } autonomous-system 65000; } protocols { rsvp { interface all; interface fxp0.0 { disable; } } mpls { label-switched-path to-RR { to 192.0.2.7; } label-switched-path to-PE2 { to 192.0.2.2; } label-switched-path to-PE5 { to 192.0.2.5; } label-switched-path to-PE4 { to 192.0.2.4; } label-switched-path to-PE1 { to 192.0.2.1; } interface all; interface fxp0.0 { disable; } } bgp { group RR { type internal; local-address 192.0.2.3; family inet-vpn { unicast; } family l2vpn { signaling; } neighbor 192.0.2.7; } } ospf { traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } ldp { interface all; interface fxp0.0 { disable; } } } policy-options { policy-statement direct { term 1 { from protocol direct; then accept; } } } routing-instances { L3VPN { instance-type vrf; interface ge-1/0/1.0; interface lt-1/1/10.1; route-distinguisher 65000:33; vrf-target target:65000:2; vrf-table-label; protocols { bgp { export direct; group ce3 { neighbor 198.51.100.10 { peer-as 100; } } } } } l2vpn { instance-type l2vpn; interface lt-1/1/10.0; route-distinguisher 65000:3; vrf-target target:65000:2; protocols { l2vpn { encapsulation-type ethernet; site CE3 { site-identifier 3; interface lt-1/1/10.0 { remote-site-id 2; } } } } } }
Verification
Verify the Layer 2 VPN-to-Layer 3 VPN interconnection:
- Verifying Router PE2 VPN Interface
- Verifying Router PE3 VPN Interface
- Verifying End-to-End connectivity from Router CE2 to Router CE5 and Router CE3
Verifying Router PE2 VPN Interface
Purpose
Check that the Layer 2 VPN is up and working at the Router PE2 interface and that all the routes are there.
Action
Use the
show l2vpn connections
command to verify that the connection site ID is 3 for Router PE3 and that the status isUp
.content_copy zoom_out_mapuser@PE2> 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 Legend for interface status Up -- operational Dn -- down Instance: l2vpn Local site: CE2 (2) connection-site Type St Time last up # Up trans 3 rmt Up Jan 7 14:14:37 2010 1 Remote PE: 192.0.2.3, Negotiated control-word: Yes (Null) Incoming label: 800000, Outgoing label: 800001 Local interface: ge-1/0/2.0, Status: Up, Encapsulation: ETHERNET
Use the
show route table
command to verify that the Layer 2 VPN route is present and that there is a next hop of10.10.5.2
through thexe-0/2/0.0
interface. The following output verifies that the Layer 2 VPN routes are present in the l2vpn.l2vpn.0 table. Similar output should be displayed for Router PE3.content_copy zoom_out_mapuser@PE2> show route table l2vpn.l2vpn.0 l2vpn.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 65000:2:2:3/96 *[L2VPN/170/-101] 02:40:35, metric2 1 Indirect 65000:3:3:1/96 *[BGP/170] 02:40:35, localpref 100, from 192.0.2.7 AS path: I > to 10.10.5.2 via xe-0/2/0.0
Verify that Router PE2 has a Layer 2 VPN MPLS label pointing to the LDP label to Router PE3 in both directions (PUSH and POP).
content_copy zoom_out_mapuser@PE2> show route table mpls.0 mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 1w3d 08:57:41, metric 1 Receive 1 *[MPLS/0] 1w3d 08:57:41, metric 1 Receive 2 *[MPLS/0] 1w3d 08:57:41, metric 1 Receive 300560 *[LDP/9] 19:45:53, metric 1 > to 10.10.2.1 via xe-0/1/0.0, Pop 300560(S=0) *[LDP/9] 19:45:53, metric 1 > to 10.10.2.1 via xe-0/1/0.0, Pop 301008 *[LDP/9] 19:45:53, metric 1 > to 10.10.4.2 via xe-0/3/0.0, Swap 299856 301536 *[LDP/9] 19:45:53, metric 1 > to 10.10.4.2 via xe-0/3/0.0, Pop 301536(S=0) *[LDP/9] 19:45:53, metric 1 > to 10.10.4.2 via xe-0/3/0.0, Pop 301712 *[LDP/9] 16:14:52, metric 1 > to 10.10.5.2 via xe-0/2/0.0, Swap 315184 301728 *[LDP/9] 16:14:52, metric 1 > to 10.10.5.2 via xe-0/2/0.0, Pop 301728(S=0) *[LDP/9] 16:14:52, metric 1 > to 10.10.5.2 via xe-0/2/0.0, Pop 800000 *[L2VPN/7] 02:40:35 > via ge-1/0/2.0, Pop Offset: 4 ge-1/0/2.0 *[L2VPN/7] 02:40:35, metric2 1 > to 10.10.5.2 via xe-0/2/0.0, Push 800001 Offset: -4
Meaning
The l2vpn
routing instance is up at interface ge-1/0/2
and the Layer 2 VPN route is shown in table l2vpn.l2vpn.0.
Table mpls.0
shows the Layer 2 VPN routes used to forward
the traffic using an LDP label.
Verifying Router PE3 VPN Interface
Purpose
Check that the Layer 2 VPN connection from Router PE2
and Router PE3 is Up
and working.
Action
Verify that the BGP session with the route reflector for the family
l2vpn-signaling
and the familyinet-vpn
is established.content_copy zoom_out_mapuser@PE3> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l2vpn.0 1 1 0 0 0 0 bgp.L3VPN.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active /Received/Accepted/Damped... 192.0.2.7 65000 2063 2084 0 1 15:35:16 Establ bgp.l2vpn.0: 1/1/1/0 bgp.L3VPN.0: 1/1/1/0 L3VPN.inet.0: 1/1/1/0 l2vpn.l2vpn.0: 1/1/1/0
The following output verifies the Layer 2 VPN route and the label associated with it.
content_copy zoom_out_mapuser@PE3> show route table l2vpn.l2vpn.0 detail l2vpn.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 65000:2:2:3/96 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 65000:2 Next hop type: Indirect Next-hop reference count: 4 Source: 192.0.2.7 Protocol next hop: 192.0.2.2 Indirect next hop: 2 no-forward State: <Secondary Active Int Ext> Local AS: 65000 Peer AS: 65000 Age: 2:45:52 Metric2: 1 Task: BGP_65000.192.0.2.7+60585 Announcement bits (1): 0-l2vpn-l2vpn AS path: I (Originator) Cluster list: 192.0.2.7 AS path: Originator ID: 192.0.2.2 Communities: target:65000:2 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100 Accepted Label-base: 800000, range: 2, status-vector: 0x0 Localpref: 100 Router ID: 192.0.2.7 Primary Routing Table bgp.l2vpn.0
The following output show the L2VPN MPLS.0 route in the mpls.0 route table.
content_copy zoom_out_mapuser@PE3> show route table mpls.0 mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 1w3d 09:05:41, metric 1 Receive 1 *[MPLS/0] 1w3d 09:05:41, metric 1 Receive 2 *[MPLS/0] 1w3d 09:05:41, metric 1 Receive 16 *[VPN/0] 15:59:24 to table L3VPN.inet.0, Pop 315184 *[LDP/9] 16:21:53, metric 1 > to 10.10.20.1 via xe-2/0/0.0, Pop 315184(S=0) *[LDP/9] 16:21:53, metric 1 > to 10.10.20.1 via xe-2/0/0.0, Pop 315200 *[LDP/9] 01:13:44, metric 1 to 10.10.20.1 via xe-2/0/0.0, Swap 625297 > to 10.10.6.2 via xe-2/1/0.0, Swap 299856 315216 *[LDP/9] 16:21:53, metric 1 > to 10.10.6.2 via xe-2/1/0.0, Pop 315216(S=0) *[LDP/9] 16:21:53, metric 1 > to 10.10.6.2 via xe-2/1/0.0, Pop 315232 *[LDP/9] 16:21:45, metric 1 > to 10.10.1.1 via xe-2/3/0.0, Pop 315232(S=0) *[LDP/9] 16:21:45, metric 1 > to 10.10.1.1 via xe-2/3/0.0, Pop 315248 *[LDP/9] 16:21:53, metric 1 > to 10.10.5.1 via xe-2/2/0.0, Pop 315248(S=0) *[LDP/9] 16:21:53, metric 1 > to 10.10.5.1 via xe-2/2/0.0, Pop 315312 *[RSVP/7] 15:02:40, metric 1 > to 10.10.6.2 via xe-2/1/0.0, label-switched-path to-pe5 315312(S=0) *[RSVP/7] 15:02:40, metric 1 > to 10.10.6.2 via xe-2/1/0.0, label-switched-path to-pe5 315328 *[RSVP/7] 15:02:40, metric 1 > to 10.10.20.1 via xe-2/0/0.0, label-switched-path to-RR 315360 *[RSVP/7] 15:02:40, metric 1 > to 10.10.20.1 via xe-2/0/0.0, label-switched-path to-RR 316272 *[RSVP/7] 01:13:27, metric 1 > to 10.10.6.2 via xe-2/1/0.0, label-switched-path Bypass->10.10.9.1 316272(S=0) *[RSVP/7] 01:13:27, metric 1 > to 10.10.6.2 via xe-2/1/0.0, label-switched-path Bypass->10.10.9.1 800001 *[L2VPN/7] 02:47:33 > via lt-1/1/10.0, Pop Offset: 4 lt-1/1/10.0 *[L2VPN/7] 02:47:33, metric2 1 > to 10.10.5.1 via xe-2/2/0.0, Push 800000 Offset: -4
Use the
show route table mpls.0
command with thedetail
option to see the BGP attributes of the route such as next-hop type and label operations.content_copy zoom_out_mapuser@PE5> show route table mpls.0 detail lt-1/1/10.0 (1 entry, 1 announced) *L2VPN Preference: 7 Next hop type: Indirect Next-hop reference count: 2 Next hop type: Router, Next hop index: 607 Next hop: 10.10.5.1 via xe-2/2/0.0, selected Label operation: Push 800000 Offset: -4 Protocol next hop: 192.0.2.2 Push 800000 Offset: -4 Indirect next hop: 8cae0a0 1048574 State: <Active Int> Age: 2:46:34 Metric2: 1 Task: Common L2 VC Announcement bits (2): 0-KRT 2-Common L2 VC AS path: I Communities: target:65000:2 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100
Verifying End-to-End connectivity from Router CE2 to Router CE5 and Router CE3
Purpose
Check the connectivity between Routers CE2, CE3, and CE5.
Action
Ping the Router CE3 IP address from Router CE2.
content_copy zoom_out_mapuser@CE2> ping 198.51.100.10 # CE3 IP address PING 198.51.100.10 (198.51.100.10): 56 data bytes 64 bytes from 198.51.100.10: icmp_seq=0 ttl=63 time=0.708 ms 64 bytes from 198.51.100.10: icmp_seq=1 ttl=63 time=0.610 ms
Ping the Router CE5 IP address from Router CE2.
content_copy zoom_out_mapuser@CE2> ping 198.51.100.2 # CE5 IP address PING 198.51.100.2 (198.51.100.2): 56 data bytes 64 bytes from 198.51.100.2: icmp_seq=0 ttl=62 time=0.995 ms 64 bytes from 198.51.100.2: icmp_seq=1 ttl=62 time=1.005 ms