VPN Concepts

A VPN consists of two topological areas, the provider's network and the customer's network. The provider's network, which runs across the public Internet infrastructure, consists of routers that provide VPN services to a customer's network as well as routers that provide other services. The customer's network is commonly located at multiple physical sites. The provider's network acts to connect the various customer sites in what appears to the customer and the provider to be a private network. To ensure that VPNs remain private and isolated from other VPNs and from the public Internet, the provider's network maintains policies that keep routing information from different VPNs separate. A provider can service multiple VPNs as long as its policies keep routes from different VPNs separate. Similarly, a site can belong to multiple VPNs as long as it keeps routes from the different VPNs separate.

Table 12.1 lists the VPN standards supported by the JUNOS software.

Table 12.1. VPN Standards Supported by JUNOS Software

Standard	Title
Internet Draft draft-kompella-ppvpn-l2vpn-00.txt	MPLS-based Layer 2 VPNs
RFC 2547	BGP/MPLS VPNs
Internet Draft draft-rosen-rfc2547bis	BGP/MPLS VPNs
RFC 2283	Multiprotocol Extensions for BGP4

VPNs contain the following types of network devices (see Figure 12.1 on page 616):

• Provider edge (PE) routers ”Routers in the provider's network that connect to CE devices located at customer sites. PE routers support VPN and label functionality. (The label functionality can be provided either by RSVP or LDP.) Within a single VPN, pairs of PE routers are connected through a tunnel, which can be either an MPLS LSP or an LDP tunnel.

• Provider (P) routers ”Routers within the core of the provider's network that are not connected to any routers at a customer site but that are part of the tunnel between pairs of PE routers. Provider routers support MPLS LSP or LDP functionality but do not need to support VPN functionality.

• Customer edge (CE) devices ”Routers or switches located at the customer's site that connect to the provider's network. CE devices are typically IP routers.

Figure 12.1. VPN Router Components

VPN functionality is provided by the PE routers; the provider and CE routers have no special configuration requirements for VPNs.

Because VPNs connect private networks ”which can use either public addresses or private addresses, as defined in RFC 1918 ”over the public Internet infrastructure, when the private networks use private addresses, the addresses might overlap with the addresses of another private network. To avoid overlapping private addresses, you can configure the network devices to use public addresses instead of private addresses. However, this is a large and complex undertaking. The solution provided in RFC 2547bis uses the existing private network numbers to create a new address that is unambiguous. The new address is part of the VPN-IPv4 address family, which is a BGP address family added as an extension to the BGP protocol. In VPN-IPv4 addresses, a value that identifies the VPN, called a route distinguisher, is prefixed to the private IPv4 address, providing an address that uniquely identifies a private IPv4 address.

Only the PE routers need to support the VPN-IPv4 address extension to BGP. When an ingress PE router receives an IPv4 route from a device within a VPN, it converts it into a VPN-IPv4 route by prefixing the route distinguisher to the route. The VPN-IPv4 addresses are used only for routes exchanged between PE routers. When an egress PE router receives a VPN-IPv4 route, it converts it back to an IPv4 route, by removing the route distinguisher, before announcing the route to its connected CE routers.

VPN-IPv4 addresses have the following format:

• Route distinguisher ”8-byte value that identifies the VPN. The route distinguisher consists of the following fields:

  • Type field (2 bytes) ”Determines the length of the other two fields. If the value in the type field is 0, the administrator (Adm) field is 4 bytes, and the assigned number (AN) field is 2 bytes. If the value in the type field is 1, the administrator (Adm) field is 2 bytes, and the assigned number (AN) field is 4 bytes.

  • Administrator field ”Identifies an assigned number authority.

    For a type field value of 0, the administrator field contains an IPv4 address. RFC 2547bis recommends that you use the router's IP address (the address you configure in the router-id statement), which is a nonprivate address.

    For a type field value of 1, the administrator field contains an AS number. RFC 2547bis recommends that you use an IANA-assigned, nonprivate AS number, preferably the ISP's or customer's own AS number.

  • Assigned number field ”Number assigned by the service provider. For a type field value of 0, the assigned number field is 2 bytes long. For a type field value of 1, the assigned number field is 4 bytes.

• IPv4 address ”4-byte address of a device within the VPN.

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 CE router. Any customer or site that belongs to the VPN can access only the routes in the VRF tables for that VPN. Each VRF table is populated from routes received from directly connected CE sites associated with that VRF and from routes received from other PE routers that passed BGP community filtering and are in the same VPN. Each PE router also maintains one global routing table ( inet.0 ) to reach other routers in and outside the provider's core network. Each customer connection (that is, logical interface) is associated with one VRF table. Only the VRF table associated with a customer site is consulted for packets from that site. You can configure the router so that if a next hop to a destination is not found in the VRF table, the router performs a lookup in the global routing table, which is used for Internet access.

The JUNOS software uses the following routing tables for VPNs:

• bgp.l3vpn.0 ” Stores all VPN-IPv4 unicast routes received from other PE routers. (This table does not store routes received from directly connected CE routers.) This table is present only on PE routers.

  When a PE router receives a route from another PE router, it places the route into its bgp.l3vpn.0 routing table. The route is resolved using the information in the inet.3 routing table. The resultant route is converted into IPv4 format and redistributed to all routing-instance- name .inet.0 routing tables on the PE router if it matches the VRF import policy.

  The bgp.l3vpn.0 table is also used to resolve routes over the MPLS tunnels that connect the PE routers. These routes are stored in the inet.3 routing table. PE-PE router connectivity must exist in inet.3 (not just in inet.0 ) for VPN routes to be resolved properly.

  To determine whether to add a route to the bgp.l3vpn.0 routing table, the JUNOS software checks it against the VRF import policies for all the VPNs configured on the PE router. If the VPN-IPv4 route matches one of the policies, it is added to the bgp.l3vpn.0 table. To display the routes in the bgp.l3vpn.0 routing table, use the show route table bgp.l3vpn.0 command.

• routing-instance-name .inet.0 ” Stores all unicast IPv4 routes received from directly connected CE routers in a routing instance (that is, in a single VPN) and all explicitly configured static routes in the routing instance. This is the VRF table and is present only on PE routers. For example, for a routing instance named VPN-A , the routing table for that instance is named VPN-A.inet.0 .

  When a CE router advertises to a PE router, the PE router places the route into the corresponding routing-instance-name .inet.0 routing table and advertises the route to other PE routers if it passes a VRF export policy. Among other things, this policy tags the route with the route distinguisher (route target) that corresponds to the VPN site to which the CE belongs. A label is also allocated and distributed with the route. The bgp.l3vpn.0 routing table is not involved in this process.

  The routing-instance-name .inet.0 table also stores routes announced by a remote PE router that match the VRF import policy for that VPN. The remote PE router redistributes these routes from its bgp.l3vpn.0 table.

  Routes are not redistributed from the routing-instance-name .inet.0 table to the bgp.l3vpn.0 table; they are directly advertised to other PE routers.

  For each routing-instance-name .inet.0 routing table, one forwarding table is maintained in the router's Packet Forwarding Engine. This table is maintained in addition to the forwarding tables that correspond to the router's inet.0 and mpls.0 routing tables. As with the inet.0 and mpls.0 routing tables, the best routes from the routing-instance-name .inet.0 routing table are placed into the forwarding table. To display the routes in the routing-instance-name .inet.0 table, use the show route table routing-instance-name .inet.0 command.

• inet.3 ” Stores all MPLS routes learned from LDP and RSVP signaling done for VPN traffic. The routing table stores the MPLS routes only if the traffic-engineering bgp-igp option is not enabled.

  For VPN routes to be resolved properly, the inet.3 table must contain routes to all the PE routers in the VPN. To display the routes in the inet.3 table, use the show route inet.3 command.

  Note that IGP shortcuts do not work in VPN environments and should not be configured. IGP shortcuts move routes in inet.3 to inet.0 . VPN IBGP (family inet-vpn ) relies on next hops that are in the inet.3 table; thus, IGP shortcuts are incompatible with VPNs.

• inet.0 ” Stores routes learned by the IBGP sessions between the PE routers. To provide Internet access to the VPN sites, configure the routing-instance-name .inet.0 routing table to contain a default route to the inet.0 routing table.

  To display the routes in the inet.0 table, use the show route inet.0 command.

The following routing policies, which are defined in VRF import and export statements, are specific to VRF tables:

• Import policy ”Applied to VPN-IPv4 routes learned from another PE router to determine whether the route should be added to the PE router's bgp.l3vpn.0 routing table. Each routing instance on a PE router has a VRF import policy.

• Export policy ”Applied to VPN-IPv4 routes that are announced to other PE routers. The VPN-IPv4 routes are IPv4 routes that have been announced by locally connected CE routers.

VPN route processing differs from normal BGP route processing in one way. In BGP, routes are accepted if they are not explicitly rejected by import policy. However, because many more VPN routes are expected, the JUNOS software does not accept (and hence store) VPN routes unless the route matches at least one VRF import policy. If no VRF import explicitly accepts the route, it is discarded and not even stored in the bgp.l3vpn.0 table. As a result, if a VPN change occurs on a PE router ”such as adding a new VRF table or changing a VRF import policy ”the PE router sends a BGP route refresh message to the other PE routers (or to the route reflector if this is part of the VPN topology) to retrieve all VPN routes so that they can be reevaluated to determine whether they should be kept or discarded.

Within a VPN, the distribution of VPN-IPv4 routes occurs between the PE and CE routers and between the PE routers.

A CE router announces its routes to the directly connected PE router. The announced routes are in IPv4 format. The PE router places the routes into the VRF table for the VPN. In the JUNOS software, this is the routing-instance-name .inet.0 routing table, where routing-instance-name is the configured name of the VPN. The connection between the CE and PE routers can be a remote connection (a WAN connection) or a direct connection (such as a Frame Relay or Ethernet connection). CE routers can communicate with PE routers using OSPF, RIP, BGP, or static routes.

When one 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 [route target] is added to the route). The PE router then announces the route in VPN-IPv4 format to the remote PE routers. The routes are distributed using IBGP sessions, which are configured in the provider's core network. If the route does not match, it is not exported to other PE routers but 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. The remote PE router places the route into its bgp.l3vpn.0 table if the route passes the import policy on the IBGP session between the PE routers. At the same time, it checks the route against the VRF import policy for the VPN. If it matches, the route distinguisher is removed from the route, and it is placed into the VRF table (the routing-instance-name .inet.0 table) in IPv4 format.

The remote PE router announces the routes in its VRF tables, which are in IPv4 format, to its directly connected CE routers. PE routers can communicate with CE routers using OSPF, RIP, BGP, or static routes.

The PE routers in the provider's core network are the only routers that are configured to support VPNs and hence are the only routers that know about the existence of the VPNs. From the point of view of VPN functionality, the provider routers in the core ”those provider routers that are not directly connected to CE routers ”are merely routers along the tunnel between the ingress and egress PE routers. The tunnels can be either LDP or MPLS. Any provider routers along the tunnel must support the protocol used for the tunnel, either LDP or MPLS. When PE-router-to-PE-router forwarding is tunneled over MPLS LSPs, the MPLS packets have a two-level label stack (see Figure 12.2):

• Outer label ”Label assigned to the address of the BGP next hop by the IGP next hop

• Inner label ”Label that the BGP next hop assigned for the packet's destination address

Figure 12.2. Using MPLS LSPs to Tunnel between PE Routers

Figure 12.3 illustrates how the labels are assigned and removed:

1. When CE Router X forwards a packet to Router PE1 with a destination of CE Router Y, the PE router identifies the BGP next hop to Router Y and assigns a label that corresponds to the BGP next hop and identifies the destination CE router. This label is the inner label.

2. Router PE1 then identifies the IGP route to the BGP next hop and assigns a second label that corresponds to the LSP of the BGP next hop. This label is the outer label.

3. The inner label remains the same as the packet traverses the LSP tunnel. The outer label is swapped at each hop along the LSP and is then popped by the penultimate hop router (the third provider router).

4. Router PE2 pops the inner label from the route and forwards the packet to Router Y.

Figure 12.3. Label Stack

To implement Layer 3 VPNs in the JUNOS software, you configure one routing instance for each VPN. You configure the routing instances on PE routers only. Each VPN routing instance consists of the following components:

• VRF table ”On each PE router, you configure one VRF table for each VPN.

• Set of interfaces that use the VRF table ”The logical interface to each directly connected CE router must be associated with a VRF table. You can associate more than one interface with the same VRF table if more than one CE router in a VPN is directly connected to the PE router.

• Policy rules ”These control the import of routes into and the export of routes from the VRF table.

• One or more routing protocols that install routes from CE routers into the VRF table ”You can use the BGP, OSPF, and RIP routing protocols, and you can use static routes.