Technology Overview

To understand this better, let us quickly create a reference model. In this reference model, we limit the discussion to the connection between the provider edge (PE) and the customer edge (CE) indicated by the remote access arrow in Figure 6-1.

Figure 6-1. Remote Access: Dial-In

IView full size imagel

Remóle Access—Dial-in

Figure 6-1. Remote Access: Dial-In

NA5 ■■ Network Amgsè Service VriG = Virtual Homg fiateivn; CE = CuslDiTier £dgt RspreisrUe ftamote Access devices

Remote Access eacktx^e welwork

NA5 ■■ Network Amgsè Service VriG = Virtual Homg fiateivn; CE = CuslDiTier £dgt RspreisrUe ftamote Access devices

The remote users can connect via cable, dial, or DSL and are terminated either directly on the PE or on another device, commonly referred to as a virtual home gateway (VHG) within the point of presence (POP). The method of access can vary depending on the service provider's facilities, service offerings, and protocols.

Remote access integration involves the mapping of users and their traffic to the appropriate MPLS VPNs. This requires the authentication and termination of sessions and the distribution of customer routes. L2TP or point-to-point tunnels might be required between customers' routers or user PCs and the provider's termination gateways. To understand these better, let us categorize them into three main components for a complete remote access integration solution with MPLS VPNs. They are as follows:

Let us now examine each of those components in some detail. Dial Access

Dial access is used when a user is connected to the corporate VPN via a dial link. Dial access consists of both dial-in and dial-out to and from the PE device. A user can dial in to a network access server (NAS) device that terminates the user connection and maps the associated traffic to a VHG. Because each VRF within the PE holds customer routes, these VRFs must be populated with the dial user/route information. (Refer to Figure 6-1.)

Several components are common to various types of dial access. They are as follows:

• Virtual access interface The virtual access interface is an instance of a virtual profile or template used in the dialer configuration, and it must be VRF-aware.

• Authentication, authorization, and accounting (AAA) By using AAA, users are authenticated and per-user accounting stats can be maintained. Making the AAA servers aware of VRFs enables the sharing of AAA servers for use across AAA functions for multiple VPNs. Otherwise, a separate AAA server must be configured per VRF. The AAA server usually authenticates based on the user's domain and password to identify the VPN and then sends the configuration to the PE for the mapping of the user traffic to a particular VPN. Another authentication mechanism commonly used for dial users is Remote Access Dial-In User Service (RADIUS). RADIUS's usage principles are the same as those of AAA and can easily be adopted to authenticate remote users and map them to MPLS VPNs.

• Address management AAA servers can also perform address management using on-demand address pools (ODAP) and can provide addresses to clients. Address reusability is also possible using overlapping address pools. The Dynamic Host Configuration Protocol (DHCP) can be used to provide addresses to the VPN clients, and VRF-aware DHCP allows the sharing of the same DHCP server among multiple VPNs. Address pools can grow using ODAP for automated address management, and network address translation (NAT) can also be used for address translation from private to public address space.

One or more of these components is needed to enable dial access to MPLS VPN. Dial access can be further subdivided into the following categories:

• Individual users dialing in using an ISDN or PSTN network

• A CE dialing in to a PE creating a backup connection when the primary has failed

• A PE dialing out to remote CEs triggered by incoming traffic from the network

Let us now discuss each in detail.

Individual Access

One of the most common dial-in methods is dialing using public switched telephone network (PSTN) to a local or an 800 number. Figure 6-1 shows individual users dialing in to access a corporate VPN. The networks access server (NAS) then terminates the call and initiates a VPDN tunnel using L2TP to the appropriate customer VPN. This can include PPP, multilink PPP, or multichassis multilink protocols that are used for a better bandwidth connection. The sequence of events is fairly standard: The remote user initiates a PPP connection to the NAS via PSTN dial or ISDN dial. The NAS accepts the connection, authenticates the user, checks to see whether a tunnel exists with the VHG, and extends the user's PPP session to terminate on the VHG or PE in the appropriate VRF. The authentication process determines the specific VRF that this user needs mapped. If the L2TP tunnel does not exist between the NAS and VHG, the NAS establishes a new L2TP session.

The PE must then map remote users' sessions to the correct VRF and forward traffic. The PE can impose another level of authentication for PPP sessions to ensure that the correct users are being mapped to the correct VRFs. Additionally, the SP provides address management in such scenarios via DHCP using the VRF services discussed in the previous chapter. The rest of the route management and advertisement is standard to MPLS VPN operation and has been discussed in detail in the previous chapter.

Another option is to have the user directly dial in to the PE that is also a NAS device. In such a situation, the NAS/PE might authenticate the user and map the traffic to VPNs. This conforms to a collapsed NAS/VHG environment.

CE Dial Backup Access

Should the primary connection fail for any reason, dial backup is a common technique used as a cheap redundancy option for providing PE-to-CE connectivity. (See Figure 6-2 for details.)

Figure 6-2. Remote AccessISDN Dial Backup

[View full size image]

The choice of using a redundant link for connectivity or dial backup is usually based on cost. In many places, using a redundant link is expensive; hence, dial backup is an affordable option especially for lower-speed connectivity between PE-CE devices.

The most common dial backup technique is to use ISDN dial backup to VHG or PE devices from the CE. The dial backup process can be to the same PE (if it also acts as a VHG for remote connections) or another PE that is a dedicated VHG. Either static routing or dynamic routing can be enabled on that dial connection.

The route learning and advertisement process is the same as in regular MPLS VPNs. However, dial backup usually works well with static routes. With dynamic routing protocols, though, the work involved with provisioning static routes can be less than that in a dynamic routing configuration.

If the service involves multiple CoS for the VPN, dial backup needs to take care of multiple classes. Special attention must be paid to address CoS requirements. For example, on the dial backup interface (due to lower available bandwidth) traffic is restricted to either high priority only or just high and medium priority and best effort is discarded or throttled down to accommodate high-priority traffic. This requires that different quality of service (QoS) templates be applied to regular interfaces and dial backup interfaces. In short, you must be sure to address dial backup for multiple classes of service.

Dial-Out Access

Instead of a remote CE initiating a connection to the VHG or PE, in this case, the PE dials out to the remote CE for connectivity. The PE-CE dial-out can be triggered based on incoming traffic from the network destined to the CE or scheduled at a particular time of the day. (See Figure 6-3.)

Figure 6-3. Remote AccessPE Dial-Out

[View full size image]

[View full size image]

For example, a PE might dial out to remote point of sale sites to collect data or remote vending machines to collect inventories and sales data. This is useful for the retail market, where this function is automated. An example is discussed in a later section.

Dial-out uses the following sequence:

• Upon receiving the traffic, the PE brings up an L2TP tunnel and initiates a PPP session with the NAS. The NAS then dials out to the CE based on the information provided as part of the L2TP negotiation.

• In the direct dial-out case, the NAS directly dials out to the CE.

Much more complicated configurations can be easily created for load-balancing of NAS devices with a VHG/PE for large-scale dial-in/dial-out.

+1 0

Post a comment