Basic BGP/MPLS IP VPN

A basic BGP/MPLS IP VPN is an L3VPN network that covers only one carrier's network, which is an MPLS backbone network that does not span multiple ASs, as shown in Figure 1. A basic BGP/MPLS IP VPN has the following characteristics:
  • Transmits packets using extended BGP.
  • Encapsulates and transmits VPN packets over MPLS LSPs serving as public network tunnels.
  • Allows a device that can play PE, P, and CE roles to play only one role at a time.
Figure 1 Basic BGP/MPLS IP VPN networking

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

On a basic BGP/MPLS IP VPN, CEs and PEs are responsible for advertising VPN routes, whereas Ps only need to maintain backbone network routes without knowing VPN routing information. Generally, a PE maintains the routes of VPNs that the PE accesses, rather than all VPN routes.
VPN route advertisement consists of the following phases:
  • 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
After the process of route advertisement is complete, the local and remote CEs can set up reachable routes, and VPN routing information can be advertised on the backbone network.
The following describes the three phases of route advertisement in detail:
  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.
After a PE receives routes of different VPNs from a local CE, if the next hops of these routes are reachable or these routes can be iterated, the PE matches the export VPN targets of these routes with the import VPN targets of its local VPN instances. This process is called local route crossing. During local route crossing, the PE filters these routes based on a VRF import policy and modifies the attributes of eligible routes.

Packet Forwarding on a BGP/MPLS IP VPN

On a BGP/MPLS IP VPN backbone network, a P does not know VPN routing information. VPN packets are forwarded between PEs over tunnels. Figure 6 shows an example of packet forwarding on a BGP/MPLS IP VPN. A packet is transmitted from CE1 to CE2. I-L indicates an inner label, and O-L indicates an outer label. The outer label directs the packet to the BGP next hop, and the inner label identifies the outbound interface for the packet or the VPN to which the packet belongs.
Figure 6 Forwarding of a VPN packet from CE1 to CE2
The forwarding process is as follows:
  1. CE1 sends a VPN packet to the ingress PE.
  2. After receiving the packet from an interface bound to a VPN instance, the ingress PE performs the following steps:
    • Searches the corresponding VPN forwarding table based on the RD of the bound VPN instance.
    • Matches the destination IPv4 address with forwarding entries and searches for the corresponding tunnel ID.
    • Adds an I-L to the packet and finds the tunnel to be used based on the tunnel ID.
    • Adds an outer label to the packet and sends the packet over the tunnel. In this example, the tunnel is an LSP, and the outer label is an MPLS label.
    • Transmits the double-tagged packet over the backbone network. Each P on the forwarding path swaps the outer label of the packet.
  3. After receiving the packet, the egress PE removes the outer label of the packet.
     NOTE:
    In this example, the final outer label of the packet is O-L2. If PHP is configured, O-L2 is removed on the penultimate hop, and the egress PE receives a packet with the inner label only.
  4. The egress PE removes the inner label residing at the bottom of the label stack.
  5. The egress PE sends the packet from the corresponding outbound interface to CE2. After its labels are removed, the packet becomes a pure IP packet.
In this manner, the packet is sent from CE1 to CE2. CE2 forwards the packet to the destination in the way it sends other IP packets.

Benefits

BGP/MPLS IP VPN offers the following benefits:
  • Enables users to communicate with each other over networks of geographically different regions.
  • Ensures the security of VPN user data during transmission over the public network.
Posted by at No comments:
Labels: , , , ,

BGP Route Reflector " RR"

Fully meshed connections need to be established between IBGP peers to ensure the connectivity between IBGP peers. If there are n CX devices in an AS, n x (n-1)/2 IBGP connections need to be established. When there are a lot of IBGP peers, network resources and CPU resources are greatly consumed. Route reflection can solve the problem.
In an AS, one CX device functions as a Route Reflector (RR) and the other CX devices as clients. The clients establish IBGP connections with the RR. The RR and its clients form a cluster. The RR reflects routes among clients, and BGP connections do not need to be established between the clients.
A BGP peer that functions as neither an RR nor a client is called a non-client. A non-client must establish full meshed connections with the RR and all the other non-clients, as shown in Figure 1.
Figure 1 Networking with an RR

Applications

After an RR receives routes from its peers, it selects the optimal route based on BGP route selection policies and performs one of the following operations:
  • If the optimal route is from a non-client IBGP peer, the RR advertises the route to all clients.
  • If the optimal route is from a client, the RR advertises the route to all non-clients and clients.
  • If the optimal route is from an EBGP peer, the RR advertises the route to all clients and non-clients.
An RR is easy to configure because it only needs to be configured on the RR itself, and clients do not need to know whether they are clients.
On some networks, if fully meshed connections have already been established among clients of an RR, they can exchange routing information directly. In this case, route reflection among the clients is unnecessary and occupies bandwidth. For example, on the CX600, route reflection can be disabled, but the routes between clients and non-clients are still exchanged. By default, route reflection between clients is enabled.
On the CX600, an RR can change various attributes of BGP routes, such as the AS_Path, MED, Local_Pref, and community attributes.

Originator_ID

Originator_ID and Cluster_List, defined in RFC 2796, are used to detect and prevent routing loops.
The Originator_ID attribute is four bytes long and is generated by an RR. It carries the router ID of the route originator in the local AS.
  • When a route is reflected by an RR for the first time, the RR adds the Originator_ID to this route. If a route already carries the Originator_ID attribute, the RR does not create a new one.
  • After receiving the route, a BGP speaker checks whether the Originator_ID is the same as its router ID. If Originator_ID is the same as its router ID, the BGP speaker discards this route.

Cluster_List

To prevent routing loops between ASs, a BGP CX device uses the AS_Path attribute to record the ASs through which a route passes. Routes with the local AS number are discarded by the CX device. To prevent routing loops within an AS, IBGP peers do not advertise routes learned from the local AS.
With RR, IBGP peers can advertise routes learned from the local AS to each other. However, the Cluster_List attribute must be deployed to prevent routing loops within the AS.
An RR and its clients form a cluster. In an AS, each RR is uniquely identified by a Cluster_ID.
Similar to an AS_Path, a Cluster_List is composed of a series of Cluster_IDs and is generated by an RR. The Cluster_List records all the RRs through which a route passes.
  • Before an RR reflects a route between its clients or between its clients and non-clients, the RR adds the local Cluster_ID to the head of the Cluster_List. If a route does not carry any Cluster_List, the RR creates one for the route.
  • After the RR receives an updated route, it checks the Cluster_List of the route. If the RR finds that its cluster ID is included in the Cluster_List, the RR discards the route. If its cluster ID is not included in the Cluster_List, the RR adds its cluster ID to the Cluster_List and then reflects the route.

Backup RR

To enhance network reliability and prevent single points of failure, more than one route reflector needs to be configured in a cluster. The route reflectors in the same cluster must share the same Cluster_ID to prevent routing loops.
With backup RRs, clients can receive multiple routes to the same destination from different RRs. The clients then apply route selection policies to choose the optimal route.
Figure 2 Backup RR
On the network shown in Figure 2, RR1 and RR2 are in the same cluster. RR1 and RR2 establish an IBGP connection so that each RR is a non-client of the other RR.
  • If Client 1 receives an updated route from an external peer, Client 1 advertises the route to RR1 and RR2 through IBGP.
  • After receiving the updated route, RR1 reflects the route to other clients (Client 2 and Client 3) and the non-client (RR2) and adds the local Cluster_ID to the head of the Cluster_List.
  • After receiving the reflected route, RR2 checks the Cluster_List. RR2 finds that its Cluster_ID is contained in the Cluster_List; therefore, it discards the updated route.
If RR1 and RR2 are configured with different Cluster_IDs, each RR receives both the route from Client 1 and the updated route reflected from the other RR. Therefore, configuring the same Cluster_ID for RR1 and RR2 reduces the number of routes that each RR receives and memory consumption.
 NOTE:
The application of Cluster_List prevents routing loops among RRs in the same AS.

Multiple Clusters in an AS

Multiple clusters may exist in an AS. RRs are IBGP peers of each other. An RR can be configured as a client or non-client of another RR.
For example, the backbone network shown in Figure 3 is divided into multiple clusters. Each RR is configured as a non-client of the other RRs, and these RRs are fully meshed. Each client establishes IBGP connections with only the RR in the same cluster. In this manner, all BGP peers in the AS can receive reflected routes.
Figure 3 Multiple clusters in an AS

Hierarchical Reflector

Hierarchical reflectors are deployed on live networks. On the network shown in Figure 4, the ISP provides Internet routes for AS 100. Two EBGP connections are established between the ISP and AS 100. AS 100 is divided into two clusters. The four CX devices in Cluster 1 are core routers.
  • Two Level-1 RRs (RR-1s) are deployed in Cluster 1, which ensures the reliability of the core layer of AS 100. The other two CX devices in the core layer are clients of RR-1s.
  • One Level-2 RR (RR-2) is deployed in Cluster 2. RR-2 is a client of RR-1.
Figure 4 Hierarchical reflector
Posted by at No comments:
Labels: , , ,

What is the VPN connection


During the initial stages of information technologies, telecom carriers used leased lines to provide Layer 2 connections for enterprises. The disadvantages of leased lines are as follows:
  • Constructing leased lines takes a long period.
  • Leased lines require huge investments.
  • Leased lines are difficult to manage.
After the emergence of asynchronous transfer mode (ATM) and frame relay (FR) technologies, telecom carriers begun to use virtual circuits (VCs) to provide point-to-point (P2P) Layer 2 connections for clients. Clients can set up Layer 3 networks and transmit IP data over the P2P Layer 2 connections. Compared with leased lines, VCs are less expensive and can be constructed within a short period. In addition, VCs enable users of different private networks to share the same carrier's network.
Despite their advantages over leased lines, VCs also have their disadvantages:
  • VCs are dependent on media such as ATM or FR. To provide VPN services based on ATM or FR, carriers must construct ATM networks covering all service areas. This implementation results in heavy capital expense.
  • The speed of ATM or FR networks is lower than that required by the Internet.
  • The deployment of ATM or FR networks is complex. To add a site to an existing ATM or FR network, you must modify the configurations of the edge nodes that connect to the site.
Traditional private networks help to boost enterprise profits, but do not meet the requirements for flexibility, security, economy, and scalability. To solve these problems, VPNs, emulated private networks carried over IP networks, have been introduced as a substitution to traditional private networks.
VPNs are virtual communication channels set up over public networks by Internet service providers (ISPs) or network service providers (NSPs).

Characteristics

A VPN has the following characteristics:
  • Privacy
    VPNs and traditional private networks make no difference to users in terms of privacy. VPN resources are separated from bearer network resources and are exclusive to VPN users. In addition, VPNs offer sufficient security measures to protect internal information against external interference.
  • Virtuality
    VPN users communicate with each other over public networks, which are used by non-VPN users at the same time. A VPN is only a logical private network. A public network that carries a VPN is called a VPN backbone network.
The VPN technology can flexibly segment an existing IP network into several logically isolated networks. This feature allows an enterprise to flexibly interconnect or isolate different departments or branches. This feature also facilitates service provisioning. For example, creating a VPN for the IP phone service can solve the problem of inadequate IP addresses while guaranteeing quality of service (QoS).
VPNs, especially Multiprotocol Label Switching (MPLS) VPNs, are highly valued by carriers in terms of providing interworking between enterprises and providing other enhanced services. VPNs have, as never before, become an important means for carriers to provide value-added services (VASs) over IP networks.

Benefits

VPNs offer the following benefits to users:
  • Guaranteed data security
    A VPN provides reliable connections between remote users, branches, business partners, suppliers, and company headquarters to ensure data transmission security. High security is becoming increasingly important as e-business and financial networks converge with communication networks.
  • High cost-effectiveness
    An enterprise can connect its headquarters with branches, personnel on business, and business partners over public networks at low costs.
  • Increased office mobility
    Enterprise employees can access the enterprise network from anywhere and at any time, meeting the increasing demand for office mobility.
  • QoS guarantee
    A QoS-capable VPN, such as an MPLS VPN, can provide users with different levels of QoS guarantee.
VPNs offer the following benefits to carriers:
  • Easy operation
    VPNs increase carriers' profits by improving resource utilization.
  • Flexible configuration
    Carriers can add or delete VPN users by means of software configurations without hardware modifications.
  • Diversified services
    In addition to basic VPN interworking services, carriers can also provide enhanced services, such as network outsourcing, service outsourcing, and customized services.
VPNs allow enterprises to direct less attention to network operation and maintenance and more attention to the achievement of their business goals. This feature enables VPNs to be increasingly popular with enterprises. A carrier can provide multiple types of services, such as best-effort IP services, VPNs, traffic engineering, and differentiated services (DSs), over only one network, reducing network construction, maintenance, and operation costs.
VPNs improve the scalability and flexibility of networks in addition to providing security, reliability, and manageability. Users can enjoy VPN services as long as they have Internet access, regardless of their location.

Classification

With the development of network technologies, the VPN technology is widely applied and many new VPN technologies emerge. VPNs can be divided into different types.

Classification Based on Applications

VPNs are divided into the following types based on applications:
  • Intranet VPN
    An intranet VPN connects the headquarters, branches, regional offices, and mobile personnel of an enterprise over public networks. Intranet VPNs are the extension to or substitute for traditional private networks or other enterprise networks.
    Intranet VPNs can be used by banks and governments to construct their intranets.
    Chain businesses, such as chain stores, storage and logistics companies, and gas station chains, are typical examples of enterprises using intranet VPNs.
  • Extranet VPN
    An extranet VPN extends selected resources and applications from an enterprise network to users outside the enterprise, such as suppliers, business partners, and clients. The extranet VPN is established between enterprises with common interests over public networks.
    An extranet established with traditional leased lines requires complex network management and access control, or even the installation of compatible user-side network devices. Although an extranet can be established in dialing mode, different extranet users must be configured respectively. In addition, an extranet in dialing mode is expensive to construct and maintain, especially if the business partners and customers are scattered far and wide. As a result, many enterprises have given up on extranets, which leads to complex and inefficient business processes between enterprises.
    Extranet VPNs are a solution to the problems of extranets. Similar to intranet VPNs in terms of technical implementation, extranet VPNs are easy to construct and manage. Currently, enterprises generally use VPNs to construct extranets. Extranet VPNs provide better QoS guarantee and higher data transmission security than the Internet. In addition, the extranet VPN owner can configure the access rights of extranet VPN users using firewalls or by other means.

Architecture

The VPN technology is much more complex than the P2P technology. VPN implementation requires construction of network connections between users, which includes network topology planning, route calculation, and maintenance of VPN users joining or leaving. The VPN architecture comprises the following parts:
  • VPN tunnels
    • Establishment of tunnels
    • Management of tunnels
  • VPN management
    • VPN configuration management
    • VPN member management
    • VPN attribute management: management of attributes of multiple VPNs on provider edges (PEs) and differentiation of VPN address spaces
  • VPN signaling protocol
    • Exchange and share of VPN resources between customer edges (CEs) on a VPN
    • VPN member discovery in some applications

Typical Networking

A typical VPN has the following layers:
  • Access layer
    The devices on the access layer provide access services for users. These devices do not need to implement many functions, but must provide many access interfaces. For metropolitan area networks (MANs) in big cities, the access layer needs to provide more functions besides the access function.
    Generally, a CE is dual-homed or multi-homed to access nodes on the access layer. Dual homing can be either physical or logical. In physical dual homing, a CE accesses two nodes over two physical links; in logical dual homing, a CE accesses two nodes that reside on a ring.
  • Convergence layer
    The convergence layer has either a mesh topology or a ring topology.
  • Backbone layer
    The backbone layer must have a full-mesh topology and multi-level backup. The devices on the backbone layer are generally connected through high-speed interfaces.
Posted by at No comments:
Labels: ,
Subscribe to: Posts (Atom)