MMP

With Cisco IOS Software Release 11.2, Cisco provided support for MMP. MLP is enhanced in MMP to enable different MLP links to terminate on different NASs. This enables ISPs and enterprises to design multiple network access servers that process calls for one single phone number, which is usually a telephone company (telco) hunt group, or for the leading phone number of the group of circuits. MMP also allows the network administrator to specify a router with greater CPU capacity to handle the reassembling and resequencing of the MLP packets, while leaving the routers with less CPU capacity to handle the call terminations. Another advantage of this design is scalability because a new NAS can be added to the existing environment to meet user demand, with minimal changes required to the existing design and configuration.

Cisco's Stack Group Bidding Protocol (SGBP) is designed to enable MMP features. As only one router can handle the reassembling and resequencing of MLP packets for any given bundle, a mechanism is required to determine which router in the group (stack) owns the master bundle (also called the call master) to perform the tasks for that bundle. SGBP is used between all members (peers) of the stack group to determine the call master when any PPP link is connected. Each router's seed-bid can be manually configured from 0 to 9999 with the higher number winning the bid to be the call master. If there's a tie, the router that has the physical link is selected as the call master. If neither router has the physical connection, SGBP randomly picks one to be the call master for that user.

After a router wins the bid for a specific user, it changes its bid for that user to 10,000, so it is guaranteed that it will win the bid for all subsequent calls from that user. SGBP uses UDP port 9900 to communicate. When a second call comes in from the same user and is terminated on a different router, a Layer 2 Forwarding (L2F) tunnel is built between the two routers, and the raw PPP data is forwarded over this tunnel from the call terminator to the call master. This is called projecting the PPP link to the call master. Eventually, this will be changed to use L2TP, which is an industry standard. Figure 10-3 shows an example of how SGBP works where RouterA, RouterB, and RouterC are in a stack group with equal seed-bids, and UserA is connecting.

Figure 10-3. SGBP with No Off-Load Server

As shown in Figure 10-3, the following 13 steps show the steps which Routers A, B, and C, with no off-load server, bid to be the call-master for UserA's PPP bundle:

1.	UserA places the first call. This is Call 1.
2.	RouterB answers a call.
3.	RouterB negotiates LCP up to the authentication challenge and identifies the caller as UserA.
4.	RouterB informs the stack group of a call from UserA.
5.	Group members bid for the call, and because all seed-bids are equal, RouterB wins because RouterB terminates the call.
6.	RouterB finishes authentication of UserA and finishes PPP negotiation.
7.	UserA places a second call. This is Call 2.
8.	The new MLP link connects to RouterC.
9.	RouterC negotiates LCP up to the authentication challenge and identifies the caller as UserA.
10.	RouterC informs the stack group of a call from UserA.
11.	The group bids for the call, and because RouterB is already the call master for UserA, RouterB wins.
12.	RouterC creates a L2F tunnel to RouterB and projects the PPP link to RouterB.
13.	RouterB reassembles and resequences the MPPP packets.

The default seed-bid is 50. A more powerful router can also be configured as an offload server with the seed-bid value, depending on the platform. (For example, a 7200 has a value of 2620, a 3600 has a value of 1050, and a 2500 has a value of 80.) Configuring a seed-bid on a router for forward-only causes the router to never bid for a call. It even hangs up the call rather than win the bid. Figure 10-4 shows an example of SGBP where RouterA, RouterB, and RouterC are in a stack group and RouterA is the off-load server that does not terminate any calls, and UserA is connecting.

Figure 10-4. SGBP with an Off-Load Server

Referring to Figure 10-4, the following 14 steps show the steps that Routers A, B, and C, with A as the off-load server bid, follow to be the call-master for UserA's PPP bundle:

1.	UserA starts the first call. This is Call 1.
2.	RouterB answers the call.
3.	RouterB negotiates LCP up to the authentication challenge and identifies the caller as UserA.
4.	RouterB informs the stack group of a call from UserA.
5.	Group bids are made for the call, and because RouterA is the off-load, RouterA becomes the call master.
6.	RouterB creates a L2F tunnel and forwards the raw PPP data to RouterA.
7.	RouterA finishes authentication of UserA and finishes PPP negotiations.
8.	UserA starts a second call. This is Call 2.
9.	New MLP links connect to RouterC.
10.	RouterC negotiates LCP up to the authentication challenge and identifies the caller as UserA.
11.	RouterC informs the stack group of a call from UserA.
12.	Group bids are made for the call, and because RouterA is already the call master, RouterA wins.
13.	RouterC creates a L2F tunnel and forwards the raw PPP data to RouterA.
14.	RouterA reassembles and resequences the MLP packets.

All described operations and the protocol interactions are transparent to the end user. From the user's debug information, it is impossible to determine if the other party is using MLP or MMP.

MMP Configuration

Example 10-24 shows the SGBP- related configuration items for each router in Figure 10-4.

Example 10-24. SGBP-Related Configuration for RouterA, RouterB, and RouterC in Figure 10-4

  hostname routerA   !   username dialin-group password cisco   !   sgbp group dialin-group   sgbp seed-bid offload   sgbp member routerB 192.168.0.2   sgbp member routerC 192.168.0.3   sgbp source-ip 192.168.0.1  ________________________________________________________________  hostname routerB   !   username dialin-group password cisco   username userA password knockknock   !   sgbp group dialin-group   sgbp member routerA 192.168.0.1   sgbp member routerC 192.168.0.3   sgbp source-ip 192.168.0.2  ________________________________________________________________  hostname routerC   !   username dialin-group password cisco   username userA password knockknock   !   sgbp group dialin-group   sgbp member routerA 192.168.0.1   sgbp member routerB 192.168.0.2   sgbp source-ip 192.168.0.3  

Authentication of the SGBP group, and of the individual users, can be done through Terminal Access Controller Access Control System (TACACS).

NOTE

Each member is authenticating the stack group rather than each other. Also, each router does not specify itself as a member of the stack group, but does need to specify all other members in the stack group to create a fully meshed group.

There is nothing to configure to enable the L2F tunnels. If no dialer interfaces are defined, a virtual template and a virtual template interface must be configured, so that when a virtual access interface needs to be created for each bundle, there is a template to clone.

MMP Sample Implementation

In the sample implementation shown in Example 10-25, you need a solution for a company with thousands of telecommuters across the U.S. who want to connect to the corporate network through an ISDN BRI from each of their homes . You are going to use two 7200 routers (7200-isdn-a and 7200-isdn-b) to terminate the ISDN calls with no offload server.

Example 10-25. MMP Sample Implementation

  hostname 7200-isdn-a   !   username isdnservers password cisco   username user1-isdn password user1   username user2-isdn password user2   !   sgbp group isdnservers   sgbp member 7200-isdn-b 172.30.253.253   sgbp source-ip 172.30.253.254   !   ! many T1 controllers   !   controller T1 2/0   framing esf   linecode b8zs   pri-group timeslots 1-24   !   ! a Serial interface for each T1   !   interface Serial2/0:23   no ip address   encapsulation ppp   dialer rotary-group 1   isdn switch-type primary-4ess   no cdp enable   !   interface Dialer1   bandwidth 128   ip unnumbered Loopback0   encapsulation ppp   dialer in-band   dialer hold-queue 20   dialer-group 1   peer default ip address pool ISDN-POOL   fair-queue   no cdp enable   ppp authentication chap isdn   ppp chap hostname 7200-isdn   ppp multilink   !  ________________________________________________________________  hostname 7200-isdn-b   !   username isdnservers password cisco   username user1-isdn password user1   username user2-isdn password user2   !   sgbp group isdnservers   sgbp member 7200-isdn-a 172.30.253.254   sgbp source-ip 172.30.253.253   !   ! many T1 controllers   !   controller T1 2/0   framing esf   linecode b8zs   pri-group timeslots 1-24   !   ! a Serial interface for each T1   !   interface Serial2/0:23   no ip address   encapsulation ppp   dialer rotary-group 1   isdn switch-type primary-4ess   no cdp enable   !   interface Dialer1   bandwidth 128   ip unnumbered Loopback0   encapsulation ppp   dialer in-band   dialer hold-queue 20   dialer-group 1   peer default ip address pool ISDN-POOL   fair-queue   no cdp enable   ppp authentication chap isdn   ppp chap hostname 7200-isdn   ppp multilink   !  

The T1 controller configuration, along with the serial and dialer interface configuration, are standard ISDN and PPP configurations. The MMP-specific commands are the username and passwords for the SGBP group, and the three lines that start with sgbp commands.

Verifying MMP

The show sgbp command displays the status of the stack group members, as shown in Example 10-26.

Example 10-26. Displaying Stack Group Member Status

 7200-isdn-b#  show sgbp  Group Name: isdnservers Ref: 0xC973B000 Seed bid: default, 50, default seed bid setting   Member Name: 7200-isdn-a  State: active  Id: 1   Ref: 0x8ECD9400   Address: 172.30.253.254 

The output includes the name of the stack group, the locally configured seed-bid, and each peer and its status. The five possible states for a peer are as follows :

• IDLE

• CONNECTING

• WAIT_INFO

• AUTHOK

• ACTIVE

In Example 10-26, if the state is IDLE, it means that the stack group isdnservers cannot detect 7200-isdn-a as a peer. The other three states are transition states from IDLE to ACTIVE. ACTIVE indicates a fully functional peer. If problems or misconfigurations exist on the local router, all configured peers might be in the IDLE state.

Example 10-27 shows output from 7200-isdn-b, where the master bundle is owned by 7200-isdn-b, and one of the MLP links is connected to 7200-isdn-a. In show ppp multilink , the second member link is connected to 7200-isdn-a and is forwarded to the Virtual-Access 17 interface of 7200-isdn-b. In show users , that Vi17 is the L2F tunnel.

Example 10-27. Verifying Master Bundle Ownership, Stack Member Connection Information, and L2F Tunnel Identification

 7200-isdn-b#  show ppp multilink   begin user2-isdn  Virtual-Access76, bundle name is user2-isdn   Bundle up for 00:06:35   Using relaxed lost fragment detection algorithm.   Dialer interface is Dialer1   0 lost fragments, 1431 reordered, 0 unassigned   0 discarded, 0 lost received, 23/255 load   0x12CC received sequence, 0x8B8 sent sequence   Member links: 2 (max not set, min not set)     Serial3/3:20, since 00:06:35, last rcvd seq 0012CB     7200-isdn-a:Virtual-Access17  (172.30.253.254), since 00:06:25,     last rcvd seq 0012C4, unsequenced 7200-isdn-b#  show users   include user2  Vi17         user2-isdn   Virtual PPP (L2F   )        -   Vi76         user2-isdn   Virtual PPP (Bundle) 00:00:00 10.70.200.137   Se3/3:20     user2-isdn   Sync PPP                    -   Bundle: Vi76 

On 7200-isdn-a, shown in Example 10-28, you see only the physical link, but nothing else.

Table 10-1. Output of the show users Command Reveals Only the Physical Link

[View full width]

 7200-isdn-a#  show users   include user2  Se5/0:8      user2-isdn   Sync PPP  -