Overview

Layer 2 VPNs

Implementing a Layer 2 VPN on a router is similar to implementing a VPN using a Layer 2 technology such as ATM or Frame Relay. However, for a Layer 2 VPN on a router, traffic is forwarded to the router in Layer 2 format. It is carried by MPLS over the service provider’s network and then converted back to Layer 2 format at the receiving site. You can configure different Layer 2 formats at the sending and receiving sites. The security and privacy of an MPLS Layer 2 VPN are equal to those of an ATM or Frame Relay VPN.

On a Layer 2 VPN, routing occurs on the customer’s routers, typically on the CE router. The CE router connected to a service provider on a Layer 2 VPN must select the appropriate circuit on which to send traffic. The PE router receiving the traffic sends it across the service provider’s network to the PE router connected to the receiving site. The PE routers do not need to store or process the customer’s routes; they only need to be configured to send data to the appropriate tunnel.

For a Layer 2 VPN, customers need to configure their own routers to carry all Layer 3 traffic. The service provider needs to know only how much traffic the Layer 2 VPN needs to carry. The service provider’s routers carry traffic between the customer’s sites using Layer 2 VPN interfaces. The VPN topology is determined by policies configured on the PE routers.

Layer 3 VPNs

In a Layer 3 VPN, the routing occurs on the service provider’s routers. Therefore, Layer 3 VPNs require more configuration on the part of the service provider, because the service provider’s PE routers must store and process the customer’s routes.

In the Junos OS, Layer 3 VPNs are based on RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs). This RFC defines a mechanism by which service providers can use their IP backbones to provide Layer 3 VPN services to their customers. The sites that make up a Layer 3 VPN are connected over a provider’s existing public Internet backbone.

VPNs based on RFC 4364 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 private addresses used by other network users. BGP/MPLS VPNs solve this problem by prefixing a VPN identifier to each address from a particular VPN site, thereby creating an address that is unique both within the VPN and within the public Internet. In addition, each VPN has its own VPN-specific routing table that contains the routing information for that VPN only.

VPLS

Virtual private LAN service (VPLS) allows you to connect geographically dispersed customer sites as if they were connected to the same LAN. In many ways, it works like a Layer 2 VPN. VPLS and Layer 2 VPNs use the same network topology and function similarly. A packet originating within a customer’s network is sent first to a CE device. It is then sent to a PE router within the service provider’s network. The packet traverses the service provider’s network over an MPLS LSP. It arrives at the egress PE router, which then forwards the traffic to the CE device at the destination customer site.

The key difference in VPLS is that packets can traverse the service provider’s network in a point-to-multipoint fashion, meaning that a packet originating from a CE device can be broadcast to PE routers in the VPLS. In contrast, a Layer 2 VPN forwards packets in a point-to-point fashion only. The destination of a packet received from a CE device by a PE router must be known for the Layer 2 VPN to function properly.

In a Layer 3 network only, you can configure virtual private LAN service (VPLS), to connect geographically dispersed Ethernet local area networks (LAN) sites to each other across an MPLS backbone. For ISP customers who implement VPLS, all sites appear to be in the same Ethernet LAN even though traffic travels across the service provider's network. VPLS is designed to carry Ethernet traffic across an MPLS-enabled service provider network. In certain ways, VPLS mimics the behavior of an Ethernet network. When a PE router configured with a VPLS routing instance receives a packet from a CE device, it first checks the appropriate routing table for the destination of the VPLS packet. If the router has the destination, it forwards it to the appropriate PE router. If it does not have the destination, it broadcasts the packet to all the other PE routers that are members of the same VPLS routing instance. The PE routers forward the packet to their CE devices. The CE device that is the intended recipient of the packet forwards it to its final destination. The other CE devices discard it.

Virtual-Router Routing Instances

A virtual-router routing instance, like a VPN routing and forwarding (VRF) routing instance, maintains separate routing and forwarding tables for each instance. However, many configuration steps required for VRF routing instances are not required for virtual-router routing instances. Specifically, you do not need to configure a route distinguisher, a routing table policy (the vrf-export, vrf-import, and route-distinguisher statements), or MPLS between the P routers.

However, you need to configure separate logical interfaces between each of the service provider routers participating in a virtual-router routing instance. You also need to configure separate logical interfaces between the service provider routers and the customer routers participating in each routing instance. Each virtual-router instance requires its own unique set of logical interfaces to all participating routers.

Figure 1 shows how this works. The service provider routers G and H are configured for virtual-router routing instances Red and Green. Each service provider router is directly connected to two local customer routers, one in each routing instance. The service provider routers are also connected to each other over the service provider network. These routers need four logical interfaces: a logical interface to each of the locally connected customer routers and a logical interface to carry traffic between the two service provider routers for each virtual-router instance.

Figure 1: Logical Interface per Router in a Virtual-Router Routing Instance

Layer 3 VPNs do not have this configuration requirement. If you configure several Layer 3 VPN routing instances on a PE router, all the instances can use the same logical interface to reach another PE router. This is possible because Layer 3 VPNs use MPLS (VPN) labels that differentiate traffic going to and from various routing instances. Without MPLS and VPN labels, as in a virtual-router routing instance, you need separate logical interfaces to separate traffic from different instances.

One method of providing this logical interface between the service provider routers is by configuring tunnels between them. You can configure IP Security (IPsec), generic routing encapsulation (GRE), or IP-IP tunnels between the service provider routers, terminating the tunnels at the virtual-router instance.

Components of a Layer 3 VPN

There are three primary types of MPLS VPNs: Layer 2 VPNs, Layer 2 circuits, and Layer 3 VPNs. All types of MPLS VPNs share certain components:

• CE devices—Customer Edge (CE) devices at the customer premises that connect to the provider’s network. Some models call these Customer Premises Equipment (CPE) devices.

• Customer network—Customer sites with CE devices that belong to the VPN.

• Provider network—The service provider backbone network running the MPLS backbone.

• P devices—Provider (P) devices within the core of the provider’s network. Provider devices are not connected to any device at a customer site and are part of the tunnel between pairs of PE devices. Provider devices support label-switched path (LSP) functionality as part of the tunnel support, but do not support VPN functionality.

• PE devices—Provider Edge (PE) devices within a service provider core network that connect directly to a CE device at the customer's site.

• MP-BGP— PE devices use MP-BGP to distribute customer routes to the proper PE devices across the MPLS backbone.

Layer 3 VPN Terminology

VPNs use a distinct terminology to identify components of the network:

• IP routing table (also called the global routing table)—This table contains service provider routes not included in a VRF. Provider devices need this table to be able to reach each other, while the VRF table is needed to reach all customer devices on a particular VPN. For example, a PE router with Interface A to a CE router and Interface B to a backbone P router places the Interface A addresses in the VRF and the Interface B addresses in the global IP routing table.

• Route Distinguisher—A 64-bit value prepended to an IP address. This unique tag helps identify the different customers’ routes as packets flow across the same service provider tunnel.

  Because a typical transit network is configured to handle more than one VPN, the provider routers are likely to have multiple VRF instances configured. As a result, depending on the origin of the traffic and any filtering rules applied to the traffic, the BGP routing tables can contain multiple routes for a particular destination address. Because BGP requires that exactly one BGP route per destination to be imported into the forwarding table, BGP must have a way to distinguish between potentially identical network layer reachability information (NLRI) messages received from different VPNs.

  A route distinguisher is a locally unique number that identifies all route information for a particular VPN. Unique numeric identifiers allow BGP to distinguish between routes that are otherwise identical.

  Each routing instance that you configure on a PE router must have a unique route distinguisher. There are two possible formats:

  • as-number:number—Where, as-number is an autonomous system (AS) number (a 2–byte value) in the range 1 through 65,535, and number is any 4–byte value. We recommend that you use an Internet Assigned Numbers Authority (IANA)-assigned, nonprivate AS number, preferably the ISP or the customer AS number.

  • ip-address:number—Where, ip-address is an IP address (a 4–byte value), and number is any 2–byte value. The IP address can be any globally unique unicast address. We recommend that you use the address that you configure in the router-id statement, which is a public IP address in your assigned prefix range.

• Route Target (RT)—A 64-bit value used to identify the final egress PE device for customer routes in a particular VRF to enable complex sharing of routes. The route target defines which route is part of a VPN. A unique route target helps distinguish between different VPN services on the same router. Each VPN also has a policy that defines how routes are imported into the VRF table on the router. A Layer 2 VPN is configured with import and export policies. A Layer 3 VPN uses a unique route target to distinguish between VPN routes. For example, the RT enables the sharing of routes in a shared service network to multiple customers. Each VPN route can have one or more RTs. A PE device handles RTs as extended BGP community values and uses the RTs to install customer routes.

• VPN-IPv4 routes—A route consisting of a 96-bit sequence composed of a 64-bit RD tag prepended to a 32-bit IPv4 address. The PE devices export the VPN-IPv4 routes in IBGP sessions to the other provider devices.These routes are exchanged across the MPLS backbone using iBGP. When the outbound PE device receives the route, it strips off the route distinguisher and advertises the route to the connected CE devices, typically through standard BGP IPv4 route advertisements.

• VRF—The virtual routing and forwarding (VRF) table distinguishes the routes for different customers, as well as customer routes from provider routes on the PE device. These routes can include overlapping private network address spaces, customer-specific public routes, and provider routes on a PE device useful to the customer.

  A VRF instance consists of one or more routing tables, a derived forwarding table, the interfaces that use the forwarding table, and the policies and routing protocols that determine what goes into the forwarding table. Because each instance is configured for a particular VPN, each VPN has separate tables, rules, and policies that control its operation.

  A separate VRF table is created for each VPN that has a connection to a CE router. The VRF table is populated with routes received from directly connected CE sites associated with the VRF instance, and with routes received from other PE routers in the same VPN.

Layer 3 VPN Architecture

A Layer 3 VPN links customer-edge routers (CE routers) to routers on the edge of the service provider network (PE routers). A Layer 3 VPN uses a peer routing model between local PE and CE routers that directly connect. That is, without needing multiple hops on the provider backbone to connect PE and CE router pairs. The PE routers distribute routing information to all CE routers belonging to the same VPN, based on the BGP route distinguisher, locally and across the provider network. Each VPN has its own routing table for that VPN, coordinated with the routing tables in the CE and PE peer routers. The CE and PE routers have different VRF tables. Each CE router has only a single VRF table because the other VPNs are invisible to the CE. A PE router can connect to more than one CE router, so the PE router has a general IP routing table and VRF table for each attached CE with a VPN.

Figure 2 shows the general architecture of a Layer 3 VPN.

Figure 2: General Layer 3 VPN Architecture.

The PE router knows which VRF table to use for packets arriving from remote VPN sites because every VRF table has one or more extended community attributes associated with hit. The community attributes identify the route as belonging to a specific collection of routers. The route target community attribute identifies a collection of sites (more accurately, the collection of their VRF tables) to which a PE router distributes routes. The PE router uses the route target to import the correct remote VPN routes into its VRF tables.

The import and export of VPN routes between VPN sites is not automatic. This process is controlled by BPG routing polices. The routing policies establish the rules for exchanging routing information across the service provider’s MPLS network and must be configured correctly and maintained when the network topology changes.

The PE router classifies IPv4 routes announced by a peer CE router and received by the PE router as VPN-IPv4 routes. When an ingress PE router receives routes advertised from a directly connected peer CE router, the ingress PE router checks the received route against the VRF export policy for that VPN. That is, the ingress PE router decides which remote PE routers need to know about the advertised routes. This is a two-step process:

• If the established export policy accepts the route, the PE router converts the information to VPN-IPv4 format by adding the route distinguisher to the IPv4 address. The PE router then announces the VPN-IPv4 route to the remote PE routers. The configured export target policy of the VRF table determines the value of the attached route target. IBGP sessions distribute the VNP-IPv4 routes across the service provider’s core network.

• If the established export policy does not accept the route, the PE router does not export the route to other PE routers, but the PE router uses the route locally. This happens, for example, when two CE routers in the same VPN connect directly to the same PE router so general traffic can flow from one CE site to another.

When an egress PE router on the other side of the service provider network receives a route, the egress PE router checks the route against the IBGP import policy in place between the PE routers. If the egress PE router accepts the route, then the egress PE router adds the route to the bgp.l3vpn.0 routing table. The router also checks the route against the VRF import policy for the VPN. If the route is accepted, the egress PE router removes the route distinguisher and places the route into the correct VRF table. The VRF tables use the routing-instance-name.inet.0 naming convention, so “VPN A” usually configures the table as vpna.inet.0).