Dial-Up Access: MMP

Peter J. Welcher

Mentor Technologies' news:

Mentor Technologies' is now up to six CCIE's, with Jon Kadis, Tom Van Meter, and Kennedy Clark joining us.
We're offering ATM weeks combining CATV and ATMS in one week (the Catalyst 5000 course and the Cisco ATM / LS1010 course).

As I write this (in late May), we've just done our first public CMTD class. Our lead instructor for this course, Bob Lyons, put a lot of energy into preparing and shaking out the labs, which configure and test both analog and ISDN BRI dial-up access. Bob's now really built up his dial-up skills (as in, lots of practice). Bob plans to take his CCIE exam in late June (no pressure, Bob)!

Bob's comment about CMTD: lots of hands-on dial-up labs working with the Cisco 766 and 2500 models and our Madge (formerly Teleos) phone switch. We see this course as requiring a solid understanding of at least the ICRC materials: those who come well-prepared will get a lot more out of it. Having some post-ICRC experience would also be useful. (As with all the Cisco courses: don't let one of the other Training Partners talk you into taking the courses too soon after one another!)

I thought this month we'd talk about some of the more advanced material in the course (labs, optional). Namely, MultiLink PPP (MLP) and Multichassis Multilink PPP (MMP). Of course, this is all compressed to fit in the space available -- all the explanation that fits in print!

What is MLP?

Multilink PPP (MLP) load-balances over dialer interfaces (ISDN, synchronous, and asynchronous). It allows the use of multiple ISDN B channels for greater bandwidth, retaining proper packet sequencing. And it's a multi-vendor standard (RFC 1990). If you've heard of "bonding", well it's not really a standard, and some vendors claim it's not appropriate for data (just video). MLP even allows mixed transmission channels, for example asynchronous and synchronous links, which simplifies life for an ISP (Internet Service Provider).

MLP works by splitting and re-assembling upper-layer PDU's (protocol data units) between the participating devices. That is, datagrams are split, sequenced, transmitted, and reassembled. The several links used are referred to as a bundle.

Sample MLP Configuration

To configure MLP, set up a standard Dial-on-Demand Routing (DDR) configuration, and then add the multilink commands. Here's a configuration fragment showing the additional commands needed:

interface bri 0
ip address 1.2.3.4 255.255.255.0
encapsulation ppp
ppp multilink
ppp authentication chap
no ip route-cache
dialer map ip 1.2.3.5 name mlpPeer 5551212
dialer-group 1
dialer load-threshold 128 either
username mlpPeer password sharedSecret

The new commands here are:

ppp multilink: specifies that we're doing MLP on the rotary group (remember, ISDN BRI ports are automatically their own rotary group).
dialer load-threshold 128 either: specifies that when load hits 128 of 255, another call should be placed to the PPP peer. The keyword "either" specifies this should happen based on either inbound or outbound traffic.

Note that multilink rotary groups dialing the same destination will combine into one large bundle, based on the CHAP authentication name (mlpPeer in the example).

Trouble-Shooting MLP

There's the usual complement of useful show and debug commands to help diagnose problems. Some of the commands available:

show ppp multilink
show interface b0 1
debug dialer
debug ppp negotiation
debug ppp authentication
debug isdn events

Why MMP?

Multichassis Multilink PPP (MMP) is useful when there's a single dialup number, a phone hunt group, and multiple devices in the dialup pool. It scales in that the network manager or designer no longer needs to be concerned with keeping the Multilink PPP (MLP) calls from one client confined to one dialup server. This is important to medium to large sites with dialup access, especially ISP points-of-presence. (If you're working on this scale, you're probably using PRI connections to the access devices). Instead, the site uses one telephone hunt group for all lines into the access servers.

The key to MMP is Stack Group Bidding Protocol (SGBP). This permits the stack group peers to bid for which router is bundle master. The bundle master might well be a router with more CPU capacity than the access devices. It might even have no access interfaces. Or it might be one of a collection of access devices.

When the first call from User A comes in, SGBP determines which router becomes bundle master, handling reassembly of datagrams for that client. Subsequent calls also use SGBP, to determine which device (if any) is bundle master for the client.

Behind the scenes, the bidding process causes automatic tunneling of the PPP data across the LAN media from the access device(s) to the bundle master. The tunneling uses L2F (see last month's article). The L2F is sent to a dialer virtual interface, cloned from a template as needed.

The SGBP bidding process can be controlled by the administrator. Options include:

greatest CPU capacity wins
first call receiver wins
a specific stack group member wins (offload server; see the picture)

Configuring MMP

Once again, we assume you've already set up DDR (Dial On Demand Routing). Additional configuration steps are needed to:

define the stack group
specify its peers
define a virtual template interface
define a multilink virtual template

The first two of these steps might be configured as follows:

sgbp group mystack
sgbp member router1 10.1.1.1
sgbp member router2 10.1.1.2
sgbp member router3 10.1.1.3
username mystack password secretstack

Note that a router does not need to list itself as a peer.

As far as defining the virtual template and virtual template interface:

multilink virtual-template 1
!
interface virtual-template 1
ip unnumbered ethernet 0
encapsulation ppp
ppp multilink
ppp authentication chap

The "interface" portion of this sets up the virtual template interface. The first part specifies which template multilink is to use to clone the interface parameters. Note that the virtual-template interface does not have an IP address, because we don't want that address to get cloned.

Optional MMP Commands

sgbp seed-bid offload

The SGBP bid is based on the system CPU. This causes SGBP to offload to the peer with the fastest CPU.

sgbp seed-bid number

The SGBP bid is based on a numerical value. Highest number wins. This can be used for clients that expect a fixed address (as in DECnet), since you can force the master bundle peer to be a specific access server.

sgbp seed-bid default

The SGBP bid defaults. If all peers default, peer that received first call from a user wins the master bundle for this user's calls.

sgbp seed-bid forward-only

The SGBP bid requires forwarding to another peer. Access server will hang up if it can't forward the packets to another.

Trouble-Shooting MMP

There are of course some new MMP trouble-shooting commands:

show ppp multilink (when SGBP is configured, it shows MMP information)
show sgbp
debug sgbp hellos
debug sgbp queries
debug sgbp error

More Info

If you have login access to Cisco's CCO, you might look at: http://www.cisco.com/warp/customer/131/3.html

The documents 4, 5, and 6.html are also useful. Take them with a grain of salt: this is all new, so they're not going to be perfect on the first try. For that matter, since I'm writing this a week after the CMTD class, I can't get access to the equipment to test the configurations. As soon as we can capture some "real" configurations in the lab, we'll post them in our sample configs area.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .