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
VPNs contain the following types of network devices (see Figure 12.1 on page 616):
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:
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:
The following routing policies, which are defined in VRF import and export statements, are specific to VRF tables:
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):
Figure 12.2. Using MPLS LSPs to Tunnel between PE Routers
Figure 12.3 illustrates how the labels are assigned and removed:
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:
|