|
|
This chapter describes the use of Multichassis Multilink Point-to-Point Protocol (MMP) on the Cisco AccessPath Integrated Access System. The chapter begins with the principles of MMP and how it works and then includes procedures for configuring MMP.
To enable MMP on the AccessPath system, you must configure both the Access Server Shelves and the Router Shelves. This chapter begins with a general discussion of and cont.
Topics in this section include the following:
This section presents a brief overview of MMP operations and includes the following topics:
MMP is a new feature in Cisco IOS Release 11.2 that extends Multilink PPP Protocol (MP, also known as MLP) functionality across multiple chassis.
MP gives users additional bandwidth on demand by splitting and recombining packets across a logical pipe (bundle) formed by multiple links. On the transmit end, MP provides for the fragmentation of a single packet into multiple packets for transmission across multiple PPP links. On the receive end, MP provides packet reassembly from multiple PPP links.
MMP enhances MP by permitting MP links from a single client to terminate on different access servers. The whole process is invisible to the user.
MMP allows Internet Service Providers (ISPs) and Enterprise system administrators the flexibility to group multiple access servers into a single rotary group that users can access from a single number. The MMP client is unaware that the MP bundle is made up of links terminating on different access servers.
MMP is particularly suited to the Cisco AccessPath Integrated Access System for the following reasons:
MMP works with the Stack Group Bidding Protocol (SGBP), which supports bidding and arbitration across multiple shelves in the AccessPath system. When you have a higher-powered CPU available as a stack member relative to the other stack members, you can leverage the more powerful CPU of that stack. The designated stack member can be configured as the offload server with the command sgbp seed-bid offload.
In the AccessPath system, this is how the Router Shelves are designated as the offload servers and made to host the master bundle for MMP calls. All MP calls from the Access Server Shelves are offloaded to the Router Shelves. See Figure 5-1.

In Figure 5-1, User X (connected to Router Y) takes advantage of the added bandwidth provided by MP when dialing into the AccessPath system stack. The following sequence illustrates a typical scenario when the AccessPath system is configured to offload MP traffic to the Router Shelf:
To enable MMP and terminate all MP calls in an Router Shelf, in global configuration mode configure the Access Server Shelves as follows:
Step 1 Define a case-sensitive user name for the stack group and set a password for authentication between stack members.
In the following example, "stack" is defined as the user name, and "stackpass" is set as the password.
Step 2 Define a named stack group and make the system a member of that stack group. The stack group name must be unique within a domain. You cannot define multiple stack groups on the AccessPath system. In the following example, the stack group name is defined as "stack," and the Access Server Shelf is made a member.
Step 3 Specify the case-sensitive host name and IP address of the Router Shelf (or Shelves). In the following example, "offload01" with IP address 192.168.23.45 is defined as a member of the stack group.
Repeat Step 3 for other Router Shelves in the stack group.
Step 4 Use the sgbp seed-bid command to configure the weight that the stack member will use when bidding to be a bundle master. In the following example, all Access Server Shelves will always be configured as "forward-only."
Step 5 Enable MP.
Step 6 Repeat Step 1 through Step 5 for each Access Server Shelf in the stack.
To enable MMP and define the Router Shelves as offload processors, in global configuration mode configure each Router Shelf as follows:
Step 1 Define a case-sensitive user name for the stack group and set a password for authentication between stack members. In the following example, "myname" is defined as the user name, and "stackpass" is set as the password.
Step 2 Define a named stack group and make the system a member of that stack group. The stack group name must be unique within a domain. You cannot define multiple stack groups on the AccessPath system.
In the following example, the stack group name is defined as "stack," and the Router Shelf is made a member.
Step 3 Specify the case-sensitive host name and IP address of all Access Server Shelves in the stack group. It is also necessary to list the other Router Shelf (if you have a dual Router Shelf configuration).
In the following example, "nas01" with IP address 192.168.2.5 is defined as a member of the stack group.
Repeat Step 3 for all members of the stack group.
Step 4 Use the sgbp seed-bid command to set the Router Shelf to be used when bidding to be a bundle master.
In the following example, offload01 is defined as an offload processor.
Step 5 Enable PPP multilink for Virtual template 1.
Step 6 Define a virtual template interface. A virtual template interface is used to provide the configuration for dynamically created Virtual-Access interfaces.
The following example defines virtual template 1.
Step 7 Enable MP.
Step 8 Repeat Step 1 through Step 7 for each Router Shelf in the stack.
|
|