Related Concepts

• Site
  The concept of “site” is frequently mentioned in the VPN technology. The following describes a site from different aspects:
  • A site is a group of IP systems that can communicate without using carrier networks.
    As shown in Figure 2, on the networks of the left side, the headquarters network of company X in City A is a site; the branch network of company X in City B is another site. IP devices within each site can communicate without using the SP network.
    
    Figure 2 Schematic diagram of sites
  • Sites are classified based on the topological relationships between devices rather than the geographical locations of devices, although devices in a site are geographically adjacent to each other in general. If two geographically separated IP systems are connected over a leased line instead of a carrier network, the two systems compose a site.
    As shown in Figure 2, if the branch network in City B connects to the headquarters network in City A over a leased line instead of a carrier network, the branch network and the headquarters network compose a site.
  • The devices at a site may belong to multiple VPNs. In other words, a site may belong to more than one VPN.
    As shown in Figure 3, the decision-making department of company X in City A (Site A) is allowed to communicate with the R&D department in City B (Site B) and the financial department in City C (Site C). Site B and Site C are not allowed to communicate with each other. In this case, two VPNs, VPN1 and VPN2, can be established, with Site A and Site B belonging to VPN1 and Site A and Site C belonging to VPN2. In this manner, Site A is configured to belong to multiple VPNs.
    
    Figure 3 One site belonging to multiple VPNs
  • A site connects to a carrier network through the CE and may contain more than one CE, but a CE belongs only to one site.
    It is recommended that you determine the devices to be used as CEs based on the following principles:
    If the site is a host, use the host as the CE.
    If the site is a subnet, use switches as CEs.
    If the site comprises multiple subnets, use routers as CEs.
    Sites connecting to the same carrier’s network can be categorized into different sets based on configured policies. Only sites that belong to the same set can access each other, and this set is a VPN.
• Address space overlapping
  As a private network, a VPN independently manages an address space. Address spaces of different VPNs may overlap. For example, if both VPN1 and VPN2 use addresses on network segment 10.110.10.0/24, address space overlapping occurs.
   NOTE:

  VPNs can use overlapped address spaces in the following situations:

  • Two VPNs do not cover the same site.
  • Two VPNs cover the same site, but devices at the site and devices using addresses in overlapped address spaces in the VPNs do not access each other.
• VPN instance
  CEs are user-side devices and need to send only local VPN routes to PEs, irrespective of whether the PEs connect to the public network or other VPNs. PEs are network-side devices, and a PE generally connects to multiple CEs from different VPNs. A PE may receive routes from different VPNs. Because address spaces used by different VPNs may overlap, routes sent from different VPNs may carry the same destination address. If a PE maintains only one routing and forwarding table, this table will accept only one of the routes from different VPNs but with the same destination address. To prevent this problem, the VPN technology uses VPN instances.
  A VPN instance is also called a VPN routing and forwarding (VRF) table. A PE maintains multiple routing and forwarding tables, including a public routing and forwarding table and one or more VRF tables. In other words, a PE has multiple instances, including a public network instance and one or more VPN instances, as shown in Figure 4. Each VPN instance maintains routes from the corresponding VPN. The public network instance maintains public network routes. This enables a PE to keep all routes from VPNs, irrespective of whether their address spaces overlap.
  
  Figure 4 Schematic diagram of VPN instances
  The differences between a public routing and forwarding table and a VRF table are as follows:
  • A public routing table contains the IPv4 routes of all PEs and Ps. These IPv4 routes are static routes configured on the backbone network or are generated by routing protocols configured on the backbone network.
  • A VPN routing table contains the routes of all sites that belong to the corresponding VPN instance. The routes are obtained through exchange of VPN routes between PEs or between CEs and PEs.
  • According to route management policies, a public forwarding table contains the minimum forwarding information extracted from the corresponding routing table, whereas a VPN forwarding table contains the minimum forwarding information extracted from the corresponding VPN routing table.
    The VPN instances on a PE are independent of each other. They are also independent of the public routing and forwarding table.
    Each VPN instance can be regarded as a virtual router, which maintains an independent address space and has one or more interfaces connected to the router.
    In RFC 4364 (BGP/MPLS IP VPNs), a VPN instance is called a per-site forwarding table. As the name suggests, one VPN instance corresponds to one site. To be specific, every connection between a CE and a PE corresponds to a VPN instance, but this is not a one-to-one mapping. The VPN instance is manually bound to the PE interface that directly connects to the CE.
    A VPN instance uses an RD to identify an independent address space and uses VPN targets to manage VPN memberships and routing principles of directly connected sites and remote sites.
• Relationships between VPNs, sites, and VPN instances
  The relationships between VPNs, sites, and VPN instances are as follows:
  • A VPN consists of multiple sites. A site may belong to multiple VPNs.
  • A site is associated with a VPN instance on a PE. A VPN instance integrates the VPN member relationships and routing principles of its associated sites. Multiple sites form a VPN based on VPN instance rules.
• RD and VPN-IPv4 address
  Traditional BGP cannot process the routes of VPNs with overlapped address spaces. Assume that VPN1 and VPN2 use addresses on the network segment 10.110.10.0/24, and each of them advertises a route destined for this network segment. The local PE identifies the two VPN routes based on VPN instances and sends them to the remote PE. Because routes from different VPNs cannot work in load-balancing mode, the remote PE adds only one of the two routes to its VRF table based on BGP route selection rules.
  This is because BGP cannot distinguish VPN routes with the same IP address prefix. To solve this problem, BGP/MPLS IP VPN uses the VPN-IPv4 address family.
  A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD and the last four bytes represent the IPv4 address prefix, as shown in Figure 5.
  
  Figure 5 VPN-IPv4 address
  RDs are used to distinguish IPv4 prefixes using the same address space. The format of RDs enables carriers to allocate RDs independently. An RD, however, must be unique on the entire network to ensure correct routing if CEs are dual-homed to PEs. IPv4 addresses with RDs are called VPN-IPv4 addresses. After receiving IPv4 routes from a CE, a PE converts the routes to globally unique VPN-IPv4 routes and advertises the routes on the public network.
• VPN target
  The VPN target, also called the route target (RT), is a 32-bit BGP extended community attribute. BGP/MPLS IP VPN uses VPN targets to control the advertisement of VPN routing information.
  A VPN instance is associated with one or more VPN targets, which are of the following types:
  • Export VPN target: After learning an IPv4 route from a directly connected site, a PE converts the route to a VPN-IPv4 route and sets the export VPN target for the route. As an extended community attribute, the export VPN target is advertised with the route.
  • Import VPN target: After receiving a VPN-IPv4 route advertised by another PE, the local PE checks the export VPN target of the route. If the export VPN target is identical with the import VPN target of a VPN instance on the PE, the PE adds the route to the VPN instance.
  The VPN target defines the sites that can receive a VPN route, and the sites from which the PE can receive routes.
  After receiving a route from a directly connected CE, a PE sets the export VPN targets of the route. The PE then uses BGP to advertise the route with export VPN targets to related PEs. After receiving the route, the related PEs compare the export VPN targets with the import VPN targets of all their VPN instances. If an export VPN target is identical with an import VPN target, the route is added to the corresponding VPN instance.
  The reasons for using VPN targets instead of RDs as the extended community attributes are as follows:
  • A VPN-IPv4 route has only one RD, but can be associated with multiple VPN targets. With multiple extended community attributes, BGP can greatly improve network flexibility and expansibility.
  • VPN targets are used to control route advertisement between different VPNs on a PE. After being configured with matching VPN targets, different VPN instances on a PE can import routes from each other.
  On a PE, different VPNs have different RDs, but the extended community attributes allowed by BGP are limited. Using RDs for route importing limits network expansibility.
  On a BGP/MPLS IP VPN, VPN targets can be used to control exchange of VPN routes between sites. Export VPN targets and import VPN targets are independent of each other and can be configured with multiple values, ensuring flexible VPN access control and diversified VPN networking modes.
• Multiprotocol Border Gateway Protocol (MP-BGP)
  Traditional BGP-4 defined in RFC 1771 can manage IPv4 routes, but not the routes of VPNs with overlapped address spaces.
  To correctly process VPN routes, VPNs use MP-BGP defined in RFC 4760 (Multiprotocol Extensions for BGP-4). MP-BGP supports multiple network layer protocols. Network layer protocol information is contained in the Network Layer Reachability Information (NLRI) field and the Next Hop field of an MP-BGP Update message.
  MP-BGP uses the address family to differentiate network layer protocols. An address family can be a traditional IPv4 address family or any other address family, such as a VPN-IPv4 address family or an IPv6 address family. For the values of address families, see RFC 3232 (Assigned Numbers).

Route Advertisement on a Basic BGP/MPLS IP VPN

• Route advertisement from the local CE to the ingress PE
• Route advertisement from the ingress PE to the egress PE
• Route advertisement from the egress PE to the remote CE

1. Route advertisement from the local CE to the ingress PE
   After the peer relationship is set up between a CE and the directly connected PE, the CE advertises the local IPv4 routes to the PE. The CE can communicate with the PE over static routes or routes established using Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), or BGP. Routes advertised by the CE to the PE are standard IPv4 routes, regardless of which routing protocol is used.
   VPN instances on a PE are isolated from each other and independent of the public routing and forwarding table, so as to prevent problems caused byaddress space overlapping. After learning routes from CEs, a PE decides to which routing and forwarding table the routes should be installed.
2. Route advertisement from the ingress PE to the egress PE
   Route advertisement from the ingress PE to the egress PE consists of the following phases:
   • After learning VPN routes from a CE, a PE stores these routes in corresponding VRFs and adds RDs to these standard IPv4 routes. The VPN-IPv4 routes are then generated.
   • The ingress PE advertises VPN-IPv4 routes to the egress PE by sending MP-BGP Update messages. The MP-BGP Update messages also contain VPN targets and MPLS labels.
   Before the next-hop PE receives the VPN-IPv4 routes, the routes are first filtered by BGP routing policies, including the export policy configured on the VPN instance and the peer export policy.
   After these routes arrive at the egress PE, if they match the BGP peer import policy and their next hops are reachable or they can be iterated, the egress PE performs local route crossing and filters these routes based on a VRF import policy. The egress PE then decides which routes are to be added to its VPN routing tables. Routes received from other PEs are added to a VPN routing table based on VPN targets. The egress PE stores the following information for subsequent packet forwarding:
   • Values of MPLS labels contained in MP-BGP Update messages
   • Tunnel IDs generated after tunnel iteration
3. Route advertisement from the egress PE to the remote CE
   A remote CE can learn VPN routes from an egress PE over static routes or routes established using RIP, OSPF, IS-IS, or BGP. Route advertisement from the egress PE to a remote CE is similar to that from a local CE to the ingress PE. The details are not described here. Note that the routes advertised by the egress PE to the remote CE are standard IPv4 routes.

Packet Forwarding on a BGP/MPLS IP VPN

Benefits