Virtual Access PPP Features in Cisco IOS

Introduction

This document describes the overall architecture of Virtual Access PPP applications in Cisco IOS®. For more information on a particular feature, refer to the documents listed at the end of the Glossary.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Glossary

The following are terms that will appear in this document.

• Access Server: Cisco Access Server platforms, including ISDN and asynchronous interfaces to provide remote access.

• L2F: Layer 2 Forwarding Protocol (Experimental Draft RFC). This is the underlying link-level technology for both Multichassis MP and Virtual Private Networks (VPN).

• Link: A connection point provided by a system. It may be a dedicated hardware interface (such as an async interface) or a channel on a multi-channel hardware interface (such as a PRI or BRI).

• MP: Multilink PPP Protocol (see RFC 1717).

• Multichassis MP: MP + SGBP + L2F + Vtemplate.

• PPP: Point-to-Point Protocol (see RFC 1331).

• Rotary Group: A group of physical interfaces allocated for dialing out or receiving calls. The group acts like a pool from which any link may be used to dial out or receive calls.

• SGBP: Stack Group Bidding Protocol

• Stack Group: A collection of two or more systems that will be configured to operate as a group and support MP bundles with links on different systems.

• VPDN: Virtual Private Dialup Network. The forwarding of PPP links from an Internet Service Provider (ISP) to a Home Gateway.

• Vtemplate: Virtual Template interface.

Note: For information about RFCs referenced in this document, see RFCs Supported in Cisco IOS Release 11.2, a product bulletin; or Obtaining RFCs and Other Standards Documents for a link directly to InterNIC.

Overview of the Virtual Access Interface

In Cisco IOS Release 11.2F, Cisco supports these dial-up access features: VPDN, Multichassis Multilink, VP, Protocol Translation using Virtual-Access, and PPP/ATM. These features use virtual interfaces to carry PPP on their target machines.

A Virtual Access interface is a Cisco IOS interface, just like physical interfaces such as a Serial Interface. A serial interface configuration resides in the serial interface configuration.

#config
  int s0
  ip unnumbered e0
  encap ppp
  :

Physical interfaces have static, fixed configurations. Virtual Access interfaces, however, are created dynamically on demand (the various uses are discussed in the next section of this document). They are also freed when they are no longer needed. Hence, the source of configuration of Virtual Access interfaces must be anchored by other means.

The various methods by which a Virtual Access gains its configuration are via the Virtual Template interface and/or RADIUS and TACAC+ records that reside on an Authentication server. The latter method is called per-user Virtual Profiles. Because Virtual Access interfaces can be configured using a global Virtual Template, Virtual Access interfaces for various users can inherit identical configurations from one Virtual Template interface. For example, the network administrator may choose to define a common PPP authentication method (CHAP) for all Virtual Access users of the system. For specific per-user tailored configurations, the network administrator may define interface configurations – such as PAP authentication – specific to the user in the Virtual Profile. In short, the general-to-specific configuration scheme available to the Virtual Access interfaces allows the network administrator to tailor interface configurations common to all users and/or individually tailored to the user.

Figure 1 above illustrates two of the Virtual Access interfaces for userA and userB. Operation 1 denotes the application of interface configuration from a global Virtual Template interface to the two Virtual Access interfaces. Operation 2 denotes the application of per-user interface configurations from different Virtual Profiles to the two Virtual Access interfaces.

Applications of the Virtual Access Interfaces

This section describes the various ways Cisco IOS uses Virtual Access interfaces.

You will notice a recurrent theme of each application – they allow a general Virtual Template specific to the application (Operation 1). Per-user Virtual profiles are then applied per user (Operation 2)

Multilink PPP

Multilink PPP uses the Virtual Access interface as a bundle interface to reassemble packets received over individual links and to fragment packets sent out over individual links. The bundle interface gets its configuration from Virtual Template specific to Multilink PPP. If the network adminstrator chooses to enable Virtual Profiles, per-username Virtual Profile interface configuration is then applied to the bundle interface for that user.

Figure 2 depicts the use of Multilink PPP of serial interfaces. Because there is no Dialer interface, a Virtual Template interface is defined by:

multilink virtual-template 1

  int virtual-template 1
  ip unnum e0
  encap ppp
  ppp chap authen

Optional per-username Virtual Profile configuration is then applied to the bundle interface. When the dialer interface is involved, the bundle interface is a passive interface – no Virtual template interface is required.

For example, Figure 3 below depicts a PRI se0:23 configured to support Multilink PPP.

Note that if Virtual Profile is enabled, the scheme reverts that shown in Figure 2. That is, if an incoming call is received on a dialer interface and Virtual Profile is enabled, the source of configuration is no longer from the dialer. Instead the Bundle interface (see Figure 2) is the "active" interface to which all protocols will read or be written to. The source of configuration is first the Virtual Template interface, then the Virtual Profile for a particular user.

L2F

Link-Level Layer 2 Forwarding, or L2F, allows PPP to be terminated on a remote destination. Normally, without L2F, PPP is between the client dialed in and the NAS that answered the incoming call. With L2F, the PPP is projected to a destination node. Insofar as the client is concerned, it "thinks" it is connected to the destination node via PPP. The NAS, in effect, becomes a simple PPP frame forwarder. In L2F terminology, the destination node is called a Home-Gateway.

At the Home-Gateway, the Virtual Access interface is used to terminate the PPP link. Again, a Virtual Template is used as the source of configuration. If Virtual Profile is defined, the per-user interface configuration is applied to the Virtual-Access interface.

The L2F Tunnel is currently propagated over UDP/IP.

L2F tunneling technology is currently used in two Cisco IOS 11.2 features: VPDN (Virtual Private Dialup Network) and Multichassis Multilink PPP (MMP).

VPDN

VPDN allows the private networks to span from the client directly to the Home Gateway of choice. For example, mobile users (sales, for example) of HP wish to be able to always connect to the HP Home-Gateway of choice anywhere, anytime. HP would contract for ISPs that would support PDN. These ISPs would be configured such that, if jsmith@hp.com dials into any of the ISP-provided numbers, the NAS automatically forwards to the HP Home-Gateway. The ISP is thus freed from administering the HP users' IP addresses, routing, and other functions tied to the HP user base. The ISP HP administration is reduced to IP connectivity issues for the HP Home-Gateway.

NAS: isp

  vpdn outgoing hp.com isp ip 1.1.1.2 

Home-Gateway: hp-gateway

int virtual-template 1
  ip unnum e0
  encap ppp
  ppp chap authen

  vpdn incoming isp hp-gateway virtual-template 1

Multichassis

PPP Multilink provides users with additional bandwidth on demand, with the ability of splitting and recombining packets across a logical pipe (bundle) formed by multiple links. This reduces transmission latency across the slow WAN links and also provides a method of increasing the maximum receive unit. Multilink is supported on a single Access Server environment.

ISPs, for example, would like to conveniently allocate a single rotary number to multiple PRIs across multiple Access Servers, scalable and flexible to their business needs.

With Multichassis Multilink, multiple Multilink links from the same client may terminate at different Access Servers. While individual MP links of the same bundle may actually terminate at different Access Servers, insofar as the MP client is concerned, it is as if it is terminating at a single Access server. When components are compared to those of VPDN, Mutichassis differs only by an additional StackGroup Bidding Protocol (SGBP) to facilitate bidding and arbitration of Multilink Bundles. Once the destination IP address of the Stack Group winner is decided over SGBP, Multichassis uses L2F to project from the NAS to the other NAS which one is the Stack Group winner.

For example on a Stack Group calls stackq of two NASes: nasa and nasb.

nasa:

  username stackq password hello
  multilink virtual-template 1

  int virtual-template 1
  ip unnum e0
  encap ppp
  ppp authen chap

  sgbp stack stackq
  sgbp member nasb 1.1.1.2

nasb:

username stackq password hello
  multilink virtual-template 1

  int virtual-template 1
  ip unnum e0
  encap ppp
  ppp authen chap

  sgbp stack stackq
  sgbp member nasb 1.1.1.2  

Protocol Translation

Protocol Translation allows PPP encapsulated traffic across a Gateway – such as X.25/TCP – to terminate as a Virtual Access interface (two-step translation). The Virtual Access interface is supported over one-step translation also.

Two-step Protocol Translation example:

  int virtual-template 1
  ip unnum e0
  encap ppp
  ppp authen chap

  vty-async virtual-template 1 

One-step Protocol Translation example:

int virtual-template 1
  ip unnum e0
  encap ppp
  ppp authen chap

  translate tcp 1.1.1.1 virtual-template 1

PPP over ATM

This feature provides support for the termination of multiple PPP connections on a router ATM interface when the data is formatted according to Cisco's (StrataCom) Frame Forwarding encapsulation. The PPP protocol is terminated on the router as if it were received from a typical PPP serial interface. Each PPP connection will be encapsulated in a separate ATM VC. VCs using other types of encapsulation may also be configured on the same interface.

interface Virtual-Template1
  ip unnumbered e0/0
  ppp authentication chap

  interface ATM2/0.2 point-to-point
  atm pvc 34 34 34 aal5ppp virtual-template 1

Virtual Profiles

Virtual Profiles is a unique PPP application that defines and applies per-user configuration information for users who dial in to a router. Virtual Profiles allow user-specific configuration information to be applied irrespective of the media used for the dial-in call. The configuration information for virtual profiles can come from a virtual interface template, per-user configuration information stored on an AAA server, or both, depending on how the router and AAA server are configured. Application of Virtual Profiles can be in a single-box environment, in a VPDN Home-Gateway, or in a Multichassis environment.

To define a Virtual Template as a source of configuration for Virtual Profile:

virtual-profile virtual-template 1
  int virtual-template 1
  ip unnum e0
  encap ppp
  ppp authen chap
  :

To define AAA as a source of configuration for Virtual Profile:

virtual-profile aaa

In this example, the system administrator decides to filter routes being advertised to John and to apply access lists to Rick's dial-in connections. When either John or Rick dials in through interface S1 or BRI 0 and authenticates, a virtual profile is created: route filters are applied to John and access lists are applied to Rick.

AAA Configuration for users John and Rick:

john Password = ``welcome''
       User-Service-Type = Framed-User,
       Framed-Protocol = PPP,
           cisco-avpair = ``ip:rte-fltr-out#0=router igrp 60'',
           cisco-avpair = ``ip:rte-fltr-out#3=deny 171.0.0.0 0.255.255.255'',
           cisco-avpair = ``ip:rte-fltr-out#4=deny 172.0.0.0 0.255.255.255'',
           cisco-avpair = ``ip:rte-fltr-out#5=permit any''
  rick Password = ``emoclew''
       User-Service-Type = Framed-User,
       Framed-Protocol = PPP,
           cisco-avpair = ``ip:inacl#3=permit ip any any precedence immediate'',
           cisco-avpair = ``ip:inacl#4=deny igrp 0.0.1.2 255.255.0.0 any'',
           cisco-avpair = ``ip:outacl#2=permit ip any any precedence immediate'',
           cisco-avpair = ``ip:outacl#3=deny igrp 0.0.9.10 255.255.0.0 any''

In a nutshell, the AAA cisco-avpairs contain Cisco IOS per-interface commands to be applied for a particular user.