Table Of Contents
Implementing Multichassis Multilink PPP
Contents
Prerequisites for Implementing Multichassis Multilink PPP
Restrictions for Implementing Multichassis Multilink PPP
Information About Multichassis Multilink PPP
Multichassis Multilink PPP
Stack Group Operation
Stack Groups with an Offload Server
Stack Group Bidding Protocol
Layer 2 Tunnel Protocols Used with MMP
How to Implement Multichassis Multilink PPP
Configuring a Stack Group
Restrictions
What to Do Next
Verifying and Troubleshooting Stack Group Configuration
What to Do Next
Configuring MMP
Configuring MMP on a Nondialer Interface
Configuring MMP on an Explicitly Defined Dialer Interface with a T1 Controller
Configuring MMP on an Explicitly Defined Dialer Interface with an E1 Controller
Configuring MMP on a Native Dialer Interface
Verifying and Troubleshooting MMP Configurations
Verifying the LCP and NCP States
Debugging Layer 2 Tunnel Protocols Used with MMP
Configuration Examples for Multichassis Multilink PPP
Configuring a Basic Stack Group: Example
Configuring an L2TP Stack Group with an Offload Server: Example
Configuring MMP on a Nondialer Interface: Example
Configuring MMP on an Explicitly Defined Dialer Interface with a T1 Controller: Example
Configuring MMP on an Explicitly Defined Dialer Interface with an E1 Controller: Example
Configuring MMP on a Native Dialer Interface: Example
Where to Go Next
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Feature Information for Multichassis Multilink PPP
Implementing Multichassis Multilink PPP
Multilink PPP (MLP) provides the capability of splitting and recombining packets to a single end system across a logical pipe formed by multiple links. MLP provides bandwidth on demand, reduces transmission latency across WAN links, and provides a method of increasing the size of the maximum receive unit. Multichassis Multilink PPP (MMP) provides the additional capability for links to terminate at multiple routers with different remote addresses. MMP allows network access servers and routers to be stacked together and to appear as a single network access server chassis. MMP handles both analog and digital traffic. MMP allows for easy expansion and scalability and for assured fault tolerance and redundancy.
Module History
This module was first published on May 2, 2005, and last updated on September 26, 2005.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all features. To find information about feature support and configuration, use the "Feature Information for Multichassis Multilink PPP" section.
Contents
•Prerequisites for Implementing Multichassis Multilink PPP
•Restrictions for Implementing Multichassis Multilink PPP
•Information About Multichassis Multilink PPP
•How to Implement Multichassis Multilink PPP
•Configuration Examples for Multichassis Multilink PPP
•Where to Go Next
•Additional References
•Feature Information for Multichassis Multilink PPP
Prerequisites for Implementing Multichassis Multilink PPP
Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.
MMP support on a group of routers requires that each router be configured to support the following:
•Multilink PPP
•Layer 2 Forwarding Protocol (L2F) or Layer 2 Tunnel Protocol (L2TP)
Restrictions for Implementing Multichassis Multilink PPP
•Dialer profiles are not supported with MMP.
•Dial-out is not supported with MMP.
•MMP supports PRI, BRI, serial, and asynchronous interfaces only.
Information About Multichassis Multilink PPP
To configure MLP you should understand the following concepts:
•Multichassis Multilink PPP
•Stack Group Operation
•Stack Groups with an Offload Server
•Stack Group Bidding Protocol
•Layer 2 Tunnel Protocols Used with MMP
Multichassis Multilink PPP
Multilink PPP (MLP) provides the capability of splitting and recombining packets to a single end system across a logical pipe (also called a bundle) formed by multiple links. MLP provides bandwidth on demand and reduces transmission latency across WAN links, and provides a method of increasing the size of the maximum receive unit.
Multichassis Multilink PPP (MMP) provides the additional capability for links to terminate at multiple routers with different remote addresses. MMP can handle both analog and digital traffic. MMP allows for easy expansion and scalability and for assured fault tolerance and redundancy.
MMP is intended for use in networks that have large pools of dial-in users, where a single chassis cannot provide enough dial ports. MMP allows companies to provide a single dialup number to its users and to apply the same solution to analog and digital calls. This feature allows Internet service providers (ISPs), for example, to allocate a single ISDN rotary number to several ISDN PRIs across several routers. This capability allows for easy expansion and scalability and for assured fault tolerance and redundancy.
MMP allows network access servers to be stacked together and to appear as a single network access server chassis so that if one network access server fails, another network access server in the stack can accept calls.
With large-scale dial-out, these features are available for both outgoing and incoming calls.
Stack Group Operation
Routers or access servers are configured to belong to groups of peers called stack groups. All members of the stack group are peers; stack groups do not need a permanent lead router. Any stack group member can answer calls coming from a single access number, which can be an E1 or T1 hunt group. Calls can come in from remote user devices, such as routers, modems, ISDN terminal adapters, and PC cards.
Once a connection is established with one member of a stack group, that member owns the call. If a second call comes in from the same client and a different router answers the call, the router establishes a tunnel and forwards all packets that belong to the call to the router that owns the call.
If a more powerful router is available, it can be configured as an offload server for the stack group. The other stack group members forward all calls to the offload server.
Figure 1 shows a basic stack group scenario.
Figure 1 Basic Stack Group
In this scenario, the first call coming in to the stack group is answered by router A. Router A wins the bidding because it already has the call. When the remote device that initiated the call needs more bandwidth it makes a second call to the stack group. Router D answers the second call, but router A wins the bidding because it is already handling a session with that remote device. Router D then establishes a tunnel to router A and forwards the raw PPP data to router A, which reassembles and resequences the packets. If router D receives more calls from that remote device, it enlarges the tunnel to router A to handle the additional traffic. Router D will not establish an additional tunnel to router A. If more calls come in from that remote device and they are answered by any other router in the stack, that router also establishes a tunnel to router A and forwards the raw PPP data. Router A reassembles the data from all calls from that remote device and passes it to the corporate network as if it had all come through on a single link.
Note High-latency WAN lines between stack group members can make stack group operation inefficient.
Stack Groups with an Offload Server
Routers or access servers can be configured to belong to groups of peers called stack groups. Any stack group member can answer calls coming from a single access number, which can be an E1 or T1 hunt group. Calls can come in from remote user devices, such as routers, modems, ISDN terminal adapters, and PC cards.
When a more powerful router is available, it can be configured as an offload server for the stack group. The offload server automatically wins the bid for any call. Other members of the stack group answer calls and forward all traffic to the offload server.
Figure 2 shows a stack group scenario with an offload server configured.
Figure 2 Stack Group with an Offload Server
In this scenario, the Cisco 7200 is configured as an offload server. The platform that is configured as an offload server automatically wins the bidding for any call. Other members of the stack group answer calls, establish tunnels, and forward all raw PPP data to the offload server. The offload server reassembles and resequences all the packets that arrive through the stack group and passes it to the corporate network as if it had all come through on a single link.
Note High-latency WAN lines between stack group members can make stack group operation inefficient.
Stack Group Bidding Protocol
Stack group bidding protocol (SGBP) arbitrates between members of a stack group to establish ownership of a call by evaluating the bids that each platform makes for that call. If all members of a stack group present the same bid, the router or access server that accepted the call will win the bid. In practice, SGBP is usually more complex. The SGBP bid from a stack group member is a function of locality, a configurable weighted metric, CPU type, and the number of existing MLP bundles. For more information about manually configuring SGBP bidding, refer to the "Usage Guidelines" section of the sgbp seed-bid command in the Cisco IOS VPDN Command Reference, Release 12.4.
Layer 2 Tunnel Protocols Used with MMP
Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.
When a call must be forwarded from one member of the stack group to the member that owns the call, Layer 2 Forwarding (L2F) or Layer 2 Tunneling Protocol (L2TP) is used. L2F or L2TP performs standard PPP operations up to the authentication phase, but the authentication phase is not completed locally. L2F or L2TP projects the link to the target stack member (the owner of the call), where the authentication phase is resumed and completed.
For more information on the L2TP and L2F protocols, refer to the "VPDN Technology Overview" module in the Cisco IOS VPDN Configuration Guide, Release 12.4.
How to Implement Multichassis Multilink PPP
Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.
This section contains the following tasks:
•Configuring a Stack Group (required)
•Verifying and Troubleshooting Stack Group Configuration (optional)
•Configuring MMP (required)
•Verifying and Troubleshooting MMP Configurations (optional)
Configuring a Stack Group
To configure MMP, you must first configure a stack group. Perform the task in this section to configure a stack group.
Restrictions
•A router or access server can belong to only one stack group.
•All members of a stack group must have the same stack group name and password defined.
•The following tunneling protocols are supported for forwarding SGBP calls between stack group members:
–Releases prior to Cisco IOS Release 12.2(4)T—L2F is the only supported tunneling protocol.
–Cisco IOS Release 12.2(4)T and later releases—Both L2TP and L2F are supported.
•If the stack group will receive incoming MLP calls over a VPDN tunnel, each stack group member must be configured to accept incoming VPDN tunnels, and multihop VPDN must be enabled. For more information about configuring stack group members to accept incoming VPDN tunnels and enabling multihop VPDN, refer to the "Configuring Multihop VPDN" module in the Cisco IOS VPDN Configuration Guide, Release 12.4.
SUMMARY STEPS
1. enable
2. configure terminal
3. username name password secret
4. sgbp group name
5. sgbp member peer-name [peer-ip-address]
6. sgbp protocol {any | l2f | l2tp}
7. sgbp seed-bid {default | offload | forward-only | bid}
DETAILED STEPS
|
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
username name password secret
Example:
Router(config)# username user1 password
mypassword
|
Establishes a username-based authentication system.
|
Step 4
|
sgbp group name
Example:
Router(config)# sgbp group stack1
|
Defines a named stack group and make this router a member of that stack group.
|
Step 5
|
sgbp member peer-name [peer-ip-address]
Example:
Router(config)# sgbp member routera 10.1.1.1
|
Specifies the hostname and IP address of a router or access server that is a peer member of a stack group.
Note You should configure a sgbp member command for each other member of the stack group.
|
Step 6
|
sgbp protocol {any | l2f | l2tp}
Example:
Router(config)# sgbp protocol l2f
|
(Optional) Sets a specific tunneling protocol to use for SGBP.
•This command is available only in Cisco IOS Release 12.2(4)T and later releases.
•The any keyword is the default value. Both L2TP and L2F bids are allowed. There is a preference for L2TP if both devices support it.
Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.
|
Step 7
|
sgbp seed-bid {default | offload | forward-only
| bid}
Example:
Router(config)# sgbp seed-bid offload
|
(Optional) Sets the bidding level that a stack group member can bid with for a bundle.
Note If you configure an offload server using the offload keyword, all other members of the stack group must be configured with the default keyword. The default value for the sgbp seed-bid command is default.
|
What to Do Next
•To verify the configuration of your stack group, you may perform the optional tasks in the "Verifying and Troubleshooting Stack Group Configuration" section.
•You must perform the required task in the "Configuring MMP" section.
Verifying and Troubleshooting Stack Group Configuration
To ensure that your stack group is configured and running correctly, perform the following optional task.
SUMMARY STEPS
1. enable
2. show sgbp
3. debug sgbp hellos
4. debug sgbp error
DETAILED STEPS
Step 1 enable
Enter this command to enable privileged EXEC mode. Enter your password if prompted:
Step 2 show sgbp
Enter this command to display the status of the stack group members.
The following is sample output from the show sgbp command issued on Router A of a four member stack:
Group Name: stack State: 0 Ref: 0xC07B060
Member Name: routerb State: ACTIVE Id: 1
Address: 10.1.1.2 Tcb: 0x60B34538
Member Name: routerc State: ACTIVE Id: 2
Address: 10.1.1.3 Tcb: 0x60B34439
Member Name: routerd State: IDLE Id: 3
Address: 10.1.1.4 Tcb: 0x0
The State field displays the status of the member. The State is 0 for the stack group
itself, and should be ACTIVE for each of the members of the group. IDLE is a valid state
for remote stack members that are intentionally inactive.
Step 3 debug sgbp hellos
Enter this command to enable the display of debug messages for authentication between stack members.
The following output displays successful authentication between two stack members:
Routera# debug sgbp hellos
%SGBP-7-CHALLENGE: Send Hello Challenge to routerb group stack1
%SGBP-7-CHALLENGED: Hello Challenge message from member routerb (10.1.1.2)
%SGBP-7-RESPONSE: Send Hello Response to routerb group stack1
%SGBP-7-CHALLENGE: Send Hello Challenge to routerb group stack1
%SGBP-7-RESPONDED: Hello Response message from member routerb (10.1.1.2)
%SGBP-7-AUTHOK: Send Hello Authentication OK to member routerb (10.1.1.2)
%SGBP-7-INFO: Addr = 10.1.1.2 Reference = 0xC347DF7
%SGBP-5-ARRIVING: New peer event for member routerb
This output shows Router A sending a successful Challenge Handshake Authentication Protocol (CHAP) challenge to and receiving a response from routerb. Similarly, Router B sends out a challenge and receives a response from routera.
If authentication fails, you may see one of the following messages in your debug output:
Routera# debug sgbp hellos
%SGBP-7-AUTHFAILED - Member routerb failed authentication
This error message means that the remote Router B password for the stack group does not match the password defined on Router A. To correct this error, make sure that both Router A and Router B have the same password defined.
Routera# debug sgbp hellos
%SGBP-7-NORESP -Fail to respond to routerb group stack1, may not have password
This error message means that Router A does not have a username or password defined. To correct this error, define a common password across all stack members.
Step 4 debug sgbp error
Enter this command to enable the display of debug messages about routing problems between members of a stack group.
One common configuration error is setting a source IP address for a stack member that does not match the locally defined IP address for the same stack member. The following debug output shows the error message that results from this misconfiguration:
Routera# debug sgbp error
%SGBP-7-DIFFERENT - routerb's addr 10.1.1.2 is different from hello's addr 10.3.4.5
This error message means that the source IP address of the SGBP hello received from Router B does not match the IP address configured locally for Router B (through the sgbp member command). Correct this configuration error by going to Router B and checking for multiple interfaces by which the SGBP hello can transmit the message.
Another common error message is:
Routera# debug sgbp error
%SGBP-7-MISCONF, Possible misconfigured member routerk (10.1.1.6)
This error message means that you do not have Router K defined locally, but another stack member does. Correct this configuration error by defining Router K across all members of the stack group.
The following error message indicates that an SGBP peer is leaving the stack group:
Routera# debug sgbp error
%SGBP-7-LEAVING:Member routerc leaving group stack1
This error message indicates that the peer Router C is leaving the stack group. Router C could be leaving the stack group intentionally, or a connectivity problem may exist.
The following error message indicates that an SGBP event was detected from an unknown peer:
Routera# debug sgbp error
%SGBP-7-UNKNOWPEER:Event 0x10 from peer at 172.21.54.3
An SGBP event came from a network host that was not recognizable as an SGBP peer. Check to see if a network media error could have corrupted the address, or if peer equipment is malfunctioning to generate corrupted packets. Depending on the network topology and firewall, SGBP packets from a nonpeer host could indicate probing and attempts to breach security. If there is a chance your network is under attack, obtain knowledgeable assistance.
What to Do Next
Once your stack group has been configured, proceed to the "Configuring MMP" section.
Configuring MMP
Once a stack group has been configured, you must configure MMP on the members of the stack group. The MMP configuration of the stack group members depends on the type of interfaces you have. You must choose the configuration task that matches the type of interface you are configuring.
If you are configuring MMP on asynchronous, serial, or other nondialer interfaces, you may choose to support MMP without any dialer configuration on those interfaces. In this case, you must define a virtual template to serve as the source of configuration information for the virtual access interfaces. Virtual access interfaces serve as both bundle interfaces and projected PPP links. These interfaces are dynamically created on demand.
If dialers are configured on physical interfaces, or the interface is a native dialer such as ISDN PRIs and BRIs, no virtual template needs to be defined. The virtual access interface acts as a passive interface, buttressed between the dialer interface and the physical interfaces associated with the dialer interface. Only the PPP commands from the dialer interface configuration will be applied to the bundle interface and projected PPP links.
Perform one of the following tasks depending on the type of interface you are configuring:
•Configuring MMP on a Nondialer Interface
•Configuring MMP on an Explicitly Defined Dialer Interface with a T1 Controller
•Configuring MMP on an Explicitly Defined Dialer Interface with an E1 Controller
•Configuring MMP on a Native Dialer Interface
This section also contains an optional Troubleshooting Tips section, which applies to MMP configurations on all types of interfaces.
•Verifying and Troubleshooting MMP Configurations (optional)
Configuring MMP on a Nondialer Interface
Perform this task if you are configuring MMP on a physical interface that is not configured as a dialer.
Prerequisites
A stack group must be configured before MMP is implemented. To configure a stack group, perform the task in the "Configuring a Stack Group" section.
SUMMARY STEPS
1. enable
2. configure terminal
3. multilink virtual-template number
4. ip local pool {default | poolname} [low-ip-address [high-ip-address]] [group group-name] [cache-size size]
5. interface virtual-template number
6. ip unnumbered type number
7. no ip route-cache
8. encapsulation type
9. ppp multilink [bap]
10. ppp authentication protocol1 [protocol2...] [if-needed] [list-name | default] [callin] [one-time] [optional]
DETAILED STEPS
|
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
multilink virtual-template number
Example:
Router(config)# multilink virtual-template 1
|
Specifies a virtual template from which the specified MLP bundle interface can clone its interface parameters.
|
Step 4
|
ip local pool {default | poolname}
[low-ip-address [high-ip-address]] [group
group-name] [cache-size size]
Example:
Router(config)# ip local pool default 10.10.1.1
10.10.1.100
|
Configures a local pool of IP addresses to be used when a remote peer connects to a point-to-point interface.
|
Step 5
|
interface virtual-template number
Example:
Router(config)# interface virtual-template 1
|
Creates a virtual template interface that can be configured and applied dynamically in creating virtual access interfaces and enters interface configuration mode.
|
Step 6
|
ip unnumbered type number
Example:
Router(config-if)# ip unnumbered ethernet 0
|
Enables IP processing on a serial interface without assigning an explicit IP address to the interface.
Note Do not define a specific IP address in the virtual template. If a specific IP address is defined in the virtual template, multiple virtual access interfaces with the same IP address can be established on a stack member. IP will erroneously route between the two virtual access interfaces.
|
Step 7
|
no ip route-cache
Example:
Router(config-if)# no ip route-cache
|
(Optional) Controls the use of high-speed switching caches for IP routing.
|
Step 8
|
encapsulation type
Example:
Router(config-if)# encapsulation ppp
|
Sets the encapsulation method used by the interface.
|
Step 9
|
ppp multilink [bap]
Example:
Router(config-if)# ppp multilink
|
Enables MLP on an interface and, optionally, enables Bandwidth Allocation Control Protocol (BACP) and its Bandwidth Allocation Protocol (BAP) subset for dynamic bandwidth allocation.
|
Step 10
|
ppp authentication protocol1 [protocol2...]
[if-needed] [list-name | default] [callin]
[one-time] [optional]
Example:
Router(config-if)# ppp authentication chap
|
Enables CHAP or Password Authentication Protocol (PAP) or both and specifies the order in which CHAP and PAP authentication is selected on the interface.
|
What to Do Next
You may perform the optional tasks in the "Verifying and Troubleshooting MMP Configurations" section.
Configuring MMP on an Explicitly Defined Dialer Interface with a T1 Controller
Perform this task to configure a physical interface as a dialer interface and enable MMP. Perform this task if you are configuring MMP on a dialer interface that is not a native dialer and you have a T1 PRI controller.
Prerequisites
A stack group must be configured before MMP is implemented. To configure a stack group, perform the task in the "Configuring a Stack Group" section.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface dialer dialer-rotary-group-number
4. ip unnumbered type number
5. dialer in-band [no-parity | odd-parity]
6. dialer-group group-number
7. dialer idle-timeout seconds [inbound | either]
8. encapsulation type
9. ppp multilink [bap]
10. ppp authentication protocol1 [protocol2...] [if-needed] [list-name | default] [callin] [one-time] [optional]
11. exit
12. controller t1 number
13. framing {sf | esf}
14. linecode {ami | b8zs}
15. pri-group timeslots timeslot-range [nfas_d {backup | none | primary {nfas_int number | nfas_group number | rlm-group number}} | service]
16. exit
17. interface serial controller-number:timeslot
18. no ip address
19. encapsulation type
20. ppp multilink [bap]
21. ppp authentication protocol1 [protocol2...] [if-needed] [list-name | default] [callin] [one-time] [optional]
22. dialer rotary-group interface-number
23. dialer-group group-number
DETAILED STEPS
|
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface dialer dialer-rotary-group-number
Example:
Router(config)# interface dialer 1
|
Defines a dialer rotary group and enters interface configuration mode.
|
Step 4
|
ip unnumbered type number
Example:
Router(config-if)# ip unnumbered ethernet 0
|
Enables IP processing on a serial interface without assigning an explicit IP address to the interface.
Note Do not define a specific IP address on the interface. If a specific IP address is defined on the interface, multiple virtual access interfaces with the same IP address can be established on a stack member. IP will erroneously route between the two virtual access interfaces.
|
Step 5
|
dialer in-band [no-parity | odd-parity]
Example:
Router(config-if)# dialer in-band
|
(Optional) Specifies that dial-on-demand routing (DDR) is to be supported.
|
Step 6
|
dialer-group group-number
Example:
Router(config-if)# dialer group 1
|
Controls access by configuring an interface to belong to a specific dialing group.
|
Step 7
|
dialer idle-timeout seconds [inbound | either]
Example:
Router(config-if)# dialer idle timeout 400
|
(Optional) Specifies the duration of idle time before a line is disconnected.
Note The default timeout value is 120 seconds. You may want to configure a higher timeout value to prevent intermittent disconnection issues from occurring.
Note You must configure the dialer in-band command before configuring the dialer idle-timeout command.
|
Step 8
|
encapsulation type
Example:
Router(config-if)# encapsulation ppp
|
Sets the encapsulation method used by the interface.
|
Step 9
|
ppp multilink [bap]
Example:
Router(config-if)# ppp multilink
|
Enables MLP on an interface and, optionally, enables BACP and its BAP subset for dynamic bandwidth allocation.
|
Step 10
|
ppp authentication protocol1 [protocol2...]
[if-needed] [list-name | default] [callin]
[one-time] [optional]
Example:
Router(config-if)# ppp authentication chap
|
Enables CHAP or PAP or both and specifies the order in which CHAP and PAP authentication is selected on the interface.
|
Step 11
|
exit
Example:
Router(config-if)# exit
|
Exits interface configuration mode.
|
Step 12
|
controller t1 number
Example:
Router(config)# controller t1 0
|
Configures a T1 controller and enters controller configuration mode.
Note Specific platforms may have different command syntax available for the controller command. To determine the command syntax that applies to your platform, refer to the controller command documentation in the Cisco IOS Dial Technologies Command Reference, Release 12.4, or use the command line help system.
|
Step 13
|
framing {sf | esf}
Example:
Router(config-controller)# framing esf
|
Selects the frame type for the T1 data line.
|
Step 14
|
linecode {ami | b8zs}
Example:
Router(config-controller)# linecode b8zs
|
Selects the line-code type for T1 lines.
|
Step 15
|
pri-group timeslots timeslot-range [nfas_d
{backup | none | primary {nfas_int number |
nfas_group number | rlm-group number}} |
service]
Example:
Router(config-controller)# pri-group timeslots
1-24
|
Specifies an ISDN PRI group on a channelized T1 or E1 controller and to releases the ISDN PRI signaling time slot.
|
Step 16
|
exit
Example:
Router(config-controller)# exit
|
Exits controller configuration mode.
|
Step 17
|
interface serial controller-number:timeslot
Example:
Router(config)# interface serial 0:23
|
Specifies a serial interface created on a channelized E1 or channelized T1 controller (for ISDN PRI, channel-associated signaling, or robbed-bit signaling) and enters interface configuration mode.
Note Specific platforms may have different command syntax available for the interface serial command. To determine the command syntax that applies to your platform, refer to the interface serial command documentation in the Cisco IOS Dial Technologies Command Reference, Release 12.4, or use the command line help system.
|
Step 18
|
no ip address
Example:
Router(config-if)# no ip address
|
Disables IP processing on an interface.
|
Step 19
|
encapsulation type
Example:
Router(config-if)# encapsulation ppp
|
Sets the encapsulation method used by the interface.
|
Step 20
|
ppp multilink [bap]
Example:
Router(config-if)# ppp multilink
|
Enables MLP on an interface and, optionally, enables BACP and its BAP subset for dynamic bandwidth allocation.
|
Step 21
|
ppp authentication protocol1 [protocol2...]
[if-needed] [list-name | default] [callin]
[one-time] [optional]
Example:
Router(config-if)# ppp authentication chap
|
Enables CHAP or PAP or both and specifies the order in which CHAP and PAP authentication is selected on the interface.
|
Step 22
|
dialer rotary-group interface-number
Example:
Router(config-if)# dialer rotary-group 1
|
Includes a specified interface in a dialer rotary group.
|
Step 23
|
dialer-group group-number
Example:
Router(config-if)# dialer-group 1
|
(Optional) Controls access by configuring an interface to belong to a specific dialing group.
|
What to Do Next
You may perform the optional tasks in the "Verifying and Troubleshooting MMP Configurations" section.
Configuring MMP on an Explicitly Defined Dialer Interface with an E1 Controller
Perform this task to configure a physical interface as a dialer interface and enable MMP. Perform this task if you are configuring MMP on a dialer interface that is not a native dialer and you have an E1 PRI controller.
Prerequisites
A stack group must be configured before MMP is implemented. To configure a stack group, perform the task in the "Configuring a Stack Group" section.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface dialer dialer-rotary-group-number
4. ip unnumbered type number
5. dialer in-band [no-parity | odd-parity]
6. dialer-group group-number
7. dialer idle-timeout seconds [inbound | either]
8. encapsulation type
9. ppp multilink [bap]
10. ppp authentication protocol1 [protocol2...] [if-needed] [list-name | default] [callin] [one-time] [optional]
11. exit
12. controller e1 number
13. framing {crc4 | no-crc4} [australia]
14. linecode {ami | hdb3}
15. pri-group timeslots timeslot-range [nfas_d {backup | none | primary {nfas_int number | nfas_group number | rlm-group number}} | service]
16. exit
17. interface serial controller-number:timeslot
18. no ip address
19. encapsulation type
20. ppp multilink [bap]
21. ppp authentication protocol1 [protocol2...] [if-needed] [list-name | default] [callin] [one-time] [optional]
22. dialer rotary-group interface-number
23. dialer-group group-number
DETAILED STEPS
|
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface dialer dialer-rotary-group-number
Example:
Router(config)# interface dialer 1
|
Defines a dialer rotary group and enters interface configuration mode.
|
Step 4
|
ip unnumbered type number
Example:
Router(config-if)# ip unnumbered ethernet 0
|
Enables IP processing on a serial interface without assigning an explicit IP address to the interface.
Note Do not define a specific IP address on the interface. If a specific IP address is defined on the interface, multiple virtual access interfaces with the same IP address can be established on a stack member. IP will erroneously route between the two virtual access interfaces.
|
Step 5
|
dialer in-band [no-parity | odd-parity]
Example:
Router(config-if)# dialer in-band
|
(Optional) Specifies that dial-on-demand routing (DDR) is to be supported.
|
Step 6
|
dialer-group group-number
Example:
Router(config-if)# dialer group 1
|
Controls access by configuring an interface to belong to a specific dialing group.
|
Step 7
|
dialer idle-timeout seconds [inbound | either]
Example:
Router(config-if)# dialer idle timeout 400
|
(Optional) Specifies the duration of idle time before a line is disconnected.
Note The default timeout value is 120 seconds. You may want to configure a higher timeout value to prevent intermittent disconnection issues from occurring.
Note You must configure the dialer in-band command before configuring the dialer idle-timeout command.
|
Step 8
|
encapsulation type
Example:
Router(config-if)# encapsulation ppp
|
Sets the encapsulation method used by the interface.
|
Step 9
|
ppp multilink [bap]
Example:
Router(config-if)# ppp multilink
|
Enables MLP on an interface and, optionally, enables BACP and its BAP subset for dynamic bandwidth allocation.
|
Step 10
|
ppp authentication protocol1 [protocol2...]
[if-needed] [list-name | default] [callin]
[one-time] [optional]
Example:
Router(config-if)# ppp authentication chap
|
Enables CHAP or PAP or both and specifies the order in which CHAP and PAP authentication is selected on the interface.
|
Step 11
|
exit
Example:
Router(config-if)# exit
|
Exits interface configuration mode.
|
Step 12
|
controller e1 number
Example:
Router(config)# controller e1 0
|
Configures an E1 controller and enters controller configuration mode.
Note Specific platforms may have different command syntax available for the controller command. To determine the command syntax that applies to your platform, refer to the controller command documentation in the Cisco IOS Dial Technologies Command Reference, Release 12.4, or use the command line help system.
|
Step 13
|
framing {crc4 | no-crc4} [australia]
Example:
Router(config-controller)# framing sfadm
|
Selects the frame type for the E1 data line.
|
Step 14
|
linecode {ami | hdb3}
Example:
Router(config-controller)# linecode ami
|
Selects the line-code type for E1 lines.
|
Step 15
|
pri-group timeslots timeslot-range [nfas_d
{backup | none | primary {nfas_int number |
nfas_group number | rlm-group number}} |
service]
Example:
Router(config-controller)# pri-group timeslots
1-31
|
Specifies an ISDN PRI group on a channelized T1 or E1 controller and to releases the ISDN PRI signaling time slot.
|
Step 16
|
exit
Example:
Router(config-controller)# exit
|
Exits controller configuration mode.
|
Step 17
|
interface serial controller-number:timeslot
Example:
Router(config)# interface serial 0:15
|
Specifies a serial interface created on a channelized E1 or channelized T1 controller (for ISDN PRI, channel-associated signaling, or robbed-bit signaling) and enters interface configuration mode.
Note Specific platforms may have different command syntax available for the interface serial command. To determine the command syntax that applies to your platform, refer to the interface serial command documentation in the Cisco IOS Dial Technologies Command Reference, Release 12.4, or use the command line help system.
|
Step 18
|
no ip address
Example:
Router(config-if)# no ip address
|
Disables IP processing on an interface.
|
Step 19
|
encapsulation type
Example:
Router(config-if)# encapsulation ppp
|
Sets the encapsulation method used by the interface.
|
Step 20
|
ppp multilink [bap]
Example:
Router(config-if)# ppp multilink
|
Enables MLP on an interface and, optionally, enables BACP and its BAP subset for dynamic bandwidth allocation.
|
Step 21
|
ppp authentication protocol1 [protocol2...]
[if-needed] [list-name | default] [callin]
[one-time] [optional]
Example:
Router(config-if)# ppp authentication chap
|
Enables CHAP or PAP or both and specifies the order in which CHAP and PAP authentication is selected on the interface.
|
Step 22
|
dialer rotary-group interface-number
Example:
Router(config-if)# dialer rotary-group 1
|
Includes a specified interface in a dialer rotary group.
|
Step 23
|
dialer-group group-number
Example:
Router(config-if)# dialer-group 1
|
(Optional) Controls access by configuring an interface to belong to a specific dialing group.
|
What to Do Next
You may perform the optional tasks in the "Verifying and Troubleshooting MMP Configurations" section.
Configuring MMP on a Native Dialer Interface
Perform this task to configure MMP on a native dialer interface (ISDN PRI or BRI).
Prerequisites
A stack group must be configured before MMP is implemented. To configure a stack group, perform the task in the "Configuring a Stack Group" section.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface serial number
4. ip unnumbered type number
5. dialer-group group-number
6. dialer rotary-group interface-number
7. encapsulation type
8. ppp multilink [bap]
9. ppp authentication protocol1 [protocol2...] [if-needed] [list-name | default] [callin] [one-time] [optional]
DETAILED STEPS
|
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface serial number
Example:
Router(config)# interface serial 0:23
|
Specifies a serial interface created on a channelized E1 or channelized T1 controller (for ISDN PRI, channel-associated signaling, or robbed-bit signaling) and enters interface configuration mode.
Note Specific platforms may have different command syntax available for the interface serial command. To determine the command syntax that applies to your platform, refer to the interface serial command documentation in the Cisco IOS Dial Technologies Command Reference, Release 12.4, or use the command line help system.
|
Step 4
|
ip unnumbered type number
Example:
Router(config-if)# ip unnumbered ethernet 0
|
Enables IP processing on a serial interface without assigning an explicit IP address to the interface.
|
Step 5
|
dialer-group group-number
Example:
Router(config-if)# dialer-group 1
|
Controls access by configuring an interface to belong to a specific dialing group.
|
Step 6
|
dialer rotary-group interface-number
Example:
Router(config-if)# dialer rotary-group 1
|
Includes a specified interface in a dialer rotary group.
|
Step 7
|
encapsulation type
Example:
Router(config-if)# encapsulation ppp
|
Sets the encapsulation method used by the interface.
|
Step 8
|
ppp multilink [bap]
Example:
Router(config-if)# ppp multilink
|
Enables MLP on an interface and, optionally, enables BACP and its BAP subset for dynamic bandwidth allocation.
|
Step 9
|
ppp authentication protocol1 [protocol2...]
[if-needed] [list-name | default] [callin]
[one-time] [optional]
Example:
Router(config-if)# ppp authentication chap
|
Enables CHAP or PAP or both and specifies the order in which CHAP and PAP authentication is selected on the interface.
|
What to Do Next
You may perform the optional tasks in the "Verifying and Troubleshooting MMP Configurations" section.
Verifying and Troubleshooting MMP Configurations
To troubleshoot problems with MMP, perform the following optional tasks:
•Verifying the LCP and NCP States
•Debugging Layer 2 Tunnel Protocols Used with MMP
Verifying the LCP and NCP States
Perform this task to verify the link control protocol (LCP) and Network Control Protocol (NCP) states on the bundle interface.
SUMMARY STEPS
1. enable
2. show interfaces virtual-access number [configuration]
3. show interfaces [type number]
DETAILED STEPS
Step 1 enable
Enter this command to enable privileged EXEC mode. Enter your password if prompted:
Step 2 show interfaces virtual-access number
Enter this command to display status, traffic data, and configuration information about a specified virtual access interface.
The LCP state and IP Control Protocol (IPCP), the NCP for PPP, should be in the Open state. The following output displays the LCP and NCP states for a functional bundle interface:
Router# show interfaces virtual-access 1
Virtual-Access1 is up, line protocol is up
Step 3 show interfaces [type number]
Enter this command to display statistics for all interfaces configured on the router or access server.
To verify the LCP and NCP states on the stack group member interfaces, issue the show interface command. The LCP state should be open on all member interfaces, but IPCP should be closed. The following output displays the LCP and NCP states for a functional interface on a stack group member:
Router# show interfaces Serial 0:4
Serial0:4 is up, line protocol is up
Debugging Layer 2 Tunnel Protocols Used with MMP
Perform this optional task to verify that the Layer 2 protocol is forwarding projected links properly.
SUMMARY STEPS
1. enable
2. debug vpdn event
3. debug vpn error
4. debug vpdn l2f-error
DETAILED STEPS
Step 1 enable
Enter this command to enable privileged EXEC mode. Enter your password if prompted:
Step 2 debug vpdn event
Enter this command to display L2TP errors and events that are a part of normal tunnel establishment or shutdown for VPDNs.
Step 3 debug vpdn error
Enter this command to turn on VPDN error debug messages.
The following debug output shows an incoming call being successfully forwarded to the target stack member from the router that accepted the call:
Serial0:21 VPN Forwarding
Serial0:21 VPN vpn_forward_user userx is forwarded
The following debug output shows the target stack member successfully receiving the projected link:
Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK
If you see the following debug output on the target stack member, verify the definitions of your virtual template interface. The virtual template interface must match the PPP interface parameters of the physical interface that accepted the call.
Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK
Virtual-Access1 VPN PPP LCP not accepting sent CONFACK
Step 4 debug vpdn l2f-error
Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.
Enter this command to enable the display of debug messages used to troubleshoot L2TPv3 and the surrounding Layer 2 tunneling infrastructure.
If you see the following debug output on a stack member, the stack group name and password may not match across all stack members:
Router# debug vpdn l2f-error
L2F Tunnel authentication failed for stackq
Configuration Examples for Multichassis Multilink PPP
This section contains the following configuration examples:
•Configuring a Basic Stack Group: Example
•Configuring an L2TP Stack Group with an Offload Server: Example
•Configuring MMP on a Nondialer Interface: Example
•Configuring MMP on an Explicitly Defined Dialer Interface with a T1 Controller: Example
•Configuring MMP on an Explicitly Defined Dialer Interface with an E1 Controller
•Configuring MMP on a Native Dialer Interface: Example
Configuring a Basic Stack Group: Example
The following configuration example creates a basic stack group with three members:
Router A Configuration
username user1 password mypassword
sgbp member routerb 10.1.1.2
sgbp member routerc 10.1.1.3
Router B Configuration
username user1 password mypassword
sgbp member routera 10.1.1.1
sgbp member routerc 10.1.1.3
Router C Configuration
username user1 password mypassword
sgbp member routera 10.1.1.1
sgbp member routerb 10.1.1.2
Configuring an L2TP Stack Group with an Offload Server: Example
The following configuration example creates a stack group with four members, including an offload server. The stack group is configured to use only the L2TP protocol.
Router A Configuration
username user1 password mypassword
sgbp member routerb 10.1.1.2
sgbp member routerc 10.1.1.3
sgbp member routerd 10.1.1.4
Router B Configuration
username user1 password mypassword
sgbp member routera 10.1.1.1
sgbp member routerc 10.1.1.3
sgbp member routerd 10.1.1.4
Router C Configuration
username user1 password mypassword
sgbp member routera 10.1.1.1
sgbp member routerb 10.1.1.2
sgbp member routerd 10.1.1.4
Router D (Offload Server) Configuration
username user1 password mypassword
sgbp member routera 10.1.1.1
sgbp member routerb 10.1.1.2
sgbp member routerc 10.1.1.3
Configuring MMP on a Nondialer Interface: Example
The following example configures MMP on a physical interface that is not configured as a dialer:
multilink virtual-template 1
ip local pool default 10.10.1.1 10.10.1.100
interface virtual-template 1
Configuring MMP on an Explicitly Defined Dialer Interface with a T1 Controller: Example
The following example configures MMP on a physical interface that is configured as a dialer:
Configuring MMP on an Explicitly Defined Dialer Interface with an E1 Controller: Example
The following example configures MMP on a physical interface that is configured as a dialer:
Configuring MMP on a Native Dialer Interface: Example
The following example configures MMP on a native dialer interface (ISDN PRI or BRI):
Where to Go Next
MMP stack groups that receive calls over L2TP VPDN tunnels can be configured to perform L2TP redirect. Enabling L2TP redirect allows a tunnel server in a stack group to send a redirect message to the NAS if it receives a link that belongs to another tunnel server in the stack group. L2TP redirect increases the scalability of VPDN MMP deployments, and can also be used to load balance calls across a stack group.
For more information about configuring L2TP redirect functionality, refer to the "Configuring Multihop VPDN" module in the Cisco IOS VPDN Configuration Guide, Release 12.4.
Additional References
The following sections provide references related to Multichassis Multilink PPP.
Related Documents
Related Topic
|
Document Title
|
Information about Multilink PPP
|
"Configuring Media-Independent PPP and Multilink PPP" chapter of the Cisco IOS Dial Technologies Configuration Guide, Release 12.4
|
Information about virtual templates
|
The "Configuring Virtual Template Interfaces" chapter of the Cisco IOS Dial Technologies Configuration Guide, Release 12.4
|
Information about L2F and L2TP
|
"VPDN Technology Overview" module in the Cisco IOS VPDN Configuration Guide, Release 12.4
|
Information on multihop VPDN and L2TP redirect
|
"Configuring Multihop VPDN" module in the Cisco IOS VPDN Configuration Guide, Release 12.4
|
VPDN commands: complete command syntax, command mode, defaults, usage guidelines, and examples
|
Cisco IOS VPDN Command Reference, Release 12.4
|
Dial Technologies commands: complete command syntax, command mode, defaults, usage guidelines, and examples
|
Cisco IOS Dial Technologies Command Reference, Release 12.4
|
Standards
MIBs
MIBs
|
MIBs Link
|
None
|
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://www.cisco.com/go/mibs
|
RFCs
Technical Assistance
Description
|
Link
|
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
|
http://www.cisco.com/techsupport
|
Feature Information for Multichassis Multilink PPP
Table 1 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the table.
Not all commands may be available in your Cisco IOS software release. For details on when support for a specific command was introduced, see the command reference documentation.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform. Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Table 1 Feature Information for Multichassis Multilink PPP
Feature Name
|
Releases
|
Feature Configuration Information
|
This table is intentionally left blank because no features were introduced or modified in Cisco IOS Release 12.2(1) or later. This table will be updated when feature information is added to this module.
|
—
|
—
|
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2001--2009 Cisco Systems, Inc. All rights reserved.