MPLS L3VPN Concepts

I. Site

Site is often mentioned in the VPN. Its meanings are described as follows:-

  • A site is a group of IP systems with IP connectivity that does not rely on any service provider network to implement.
  • The classification of a site depends on the topology relationship of the devices, rather than the geographical positions, though the devices at a site are adjacent to each other geographically in most cases.
  • The devices at a site can belong to multiple VPNs.
  • A site is connected to a provider network through one or more CEs. A site can contain many CEs, but a CE can belong to only one site.
  • Sites connected to the same provider network can be classified into different sets by policies. Only the sites in the same set can access each other through the provider network. Such a set is called a VPN.
II. Address space overlapping

  • Each VPN independently manages the addresses that it uses. The assembly of such addresses for a VPN is called an address space.
  • The address spaces of VPNs may overlap. For example, if both VPN 1 and VPN 2 use the addresses on network segment 10.110.10.0/24, address space overlapping occurs.
III. VPN instance
  • In MPLS VPN, routes of different VPNs are identified by VPN instance.
  • A PE creates and maintains a separate VPN instance for each VPN at a directly connected site. Each VPN instance contains the VPN membership and routing rules of the corresponding site. If a user at a site belongs to multiple VPNs at the same time, the VPN instance of the site contains information about all the VPNs.
  • For independency and security of VPN data, each VPN instance on a PE maintains a relatively independent routing table and a separate label forwarding information base (LFIB). 
  • VPN instance information contains these items: the LFIB, IP routing table, interfaces bound to the VPN instance, and administration information of the VPN instance. 
  • The administration information of the VPN instance includes the route distinguisher (RD), route filtering policy, and member interface list.
IV. VPN-IPv4 address

  • Traditional BGP cannot process VPN routes which have overlapping address spaces. If, for example, both VPN 1 and VPN 2 use addresses on the segment 10.110.10.0/24 and each advertise a route to the segment, BGP selects only one of them, which results in loss of the other route.
  • PEs use MP-BGP to advertise VPN routes, and use VPN-IPv4 address family to solve the problem with traditional BGP.
  • A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a 4-byte IPv4 address prefix
 VPN-IPv4 address structure

  • When a PE receives an ordinary IPv4 route from a CE, it must advertise the VPN route to the peer PE. 
  • The uniqueness of a VPN route is implemented by adding an RD to the route.
  • A service provider can independently assign RDs provided the assigned RDs are unique. Thus, a PE can advertise different routes to VPNs even if the VPNs are from different service providers and are using the same IPv4 address space.
  • You are recommended to configure a distinct RD for each VPN instance on a PE, guaranteeing that routes to the same CE use the same RD. 
  • The VPN-IPv4 address with an RD of 0 is in fact a globally unique IPv4 address.
  • By prefixing a distinct RD to a specific IPv4 address prefix, you get a globally unique VPN IPv4 address prefix.
  • An RD can be related to an autonomous system (AS) number, in which case it is the combination of the AS number and a discretionary number; or be related to an IP address, in which case it is the combination of the IP address and a discretionary number.
An RD can be in either of the following two formats distinguished by the Type field:

  • When the value of the Type field is 0, the Administrator subfield occupies two bytes, the Assigned number subfield occupies four bytes, and the RD format is: 16-bit AS number:32-bit user-defined number. For example, 100:1.
  • When the value of the Type field is 1, the Administrator subfield occupies four bytes, the Assigned number subfield occupies two bytes, and the RD format is: 32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
  • For the global uniqueness of an RD, you are not recommended to set the Administrator subfield to any private AS number or private IP address.
V. VPN target attributes

MPLS L3VPN uses the BGP extended community attributes called VPN target attributes, or route target attributes, to control the advertisement of VPN routing information.

A VPN instance on a PE supports two types of VPN target attributes:-

  • Export target attribute: A local PE sets this type of VPN target attribute for VPN-IPv4 routes learnt from directly connected sites before advertising them to other PEs.
  • Import target attribute: A PE checks the export target attribute of VPN-IPv4 routes advertised by other PEs. If the export target attribute matches the import target attribute of the VPN instance, the PE adds the routes to the VPN routing table.
  • In other words, VPN target attributes define which sites can receive VPN-IPv4 routes, and from which sites that a PE can receive routes.
Like RDs, VPN target attributes can be of two types of formats:-

  • 16-bit AS number:32-bit user-defined number. For example, 100:1.
  • 32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
VI. MP-BGP

  • Multiprotocol extensions for BGP-4 (MP-BGP) advertises VPN composition information and routes between PEs. It is backward compatible and supports both traditional IPv4 address family and other address families, such as VPN-IPv4 address family.
  • Using MP-BGP can guarantee that private routes of a VPN are advertised only in the VPN and implement communications between MPLS VPN members.

VII. Routing policy

  • In addition to the import and export extended communities for controlling VPN route advertisement, you can also configure import and export routing policies to control the injection and advertisement of VPN routes more precisely.
  • An import routing policy can further filter the routes that can be advertised to a VPN instance by using the VPN target attribute of import target attribute. It can reject the routes selected by the communities in the import target attribute. An export routing policy can reject the routes selected by the communities in the export target attribute.
  • After a VPN instance is created, you can configure import and/or export routing policies as needed.
VIII. Tunneling policy

  • A tunneling policy is used to select the tunnel for the packets of a specific VPN instance to use.
  • After a VPN instance is created, you can optionally configure a tunneling policy. By default, LSPs are used as tunnels and no load balancing occurs (in other words, the number of tunnels for load balancing is 1). In addition, a tunneling policy takes effect only within the local AS.

No comments:

Post a Comment