|
|
This document describes the Dynamic Multiple Encapsulations for Dial-In over ISDN feature. It includes the following sections:
The Dynamic Multiple Encapsulations feature allows incoming calls over ISDN to be assigned an encapsulation type such as Frame Relay, PPP, and X.25 based on calling line identification (CLID) or DNIS. It also allows various encapsulation types and per-user configurations on the same ISDN B channel at different times according to the type of incoming call.
The Dynamic Multiple Encapsulations feature allows per-user configuration for each dial-in caller on any ingress ISDN B channel on which encapsulation can be run independently from other
B channels on the same ISDN link. The caller is identified by CLID or DNIS to ensure that only incoming calls with authorization and valid user profiles are accepted. When PPP is used, authentication and profile binding can also be done by PPP name.
In addition, a large set of user profiles can be stored in dialer profiles locally or on a remote AAA server. (For large scale dial-in, storing user-specific configurations on a remote server becomes necessary for enhancing expandability and local memory efficiency.) However, whether stored locally or on a remote AAA server, the user-specific encapsulation and configuration can be applied to individual B channels dynamically and independently.
Dynamic multiple encapsulation is especially important in Europe where ISDN is relatively inexpensive and maximum use of all 30 B channels on the same ISDN link is desirable. Further, the feature removes the need to statically dedicate channels to a particular encapsulation and configuration type, and improves channel usage.
Figure 1 shows a typical configuration for an X.25 network in Europe. The Dynamic Multiple Encapsulations feature allows use of all 30 B channels, and supports calls that originate in diverse areas of the network and converge on the same ISDN PRI.
Although the Dynamic Multiple Encapsulations feature enhances large-scale dial-in functionality, the feature also works well in smaller-scale dial-in situations.
The following sections describe the enhancements to the dial-on-demand routing (DDR) software that enable the Dynamic Multiple Encapsulations feature.
Before Cisco IOS software Release 12.0(7)T, encapsulation techniques such as Frame Relay, HDLC, LAPB-TA, and X.25 could support only one ISDN B-channel connection over the entire link. HDLC and PPP could support multiple B channels, but the entire ISDN link needed to use the same encapsulation. With the Dynamic Multiple Encapsulations feature, once CLID binding is completed, the topmost interface is always used for all configuration and data structures. The ISDN B channel becomes a forwarding device, and the configuration on the D channel is ignored, thereby allowing the different encapsulation types and per-user configurations.
For X.25 encapsulations, the configurations reside on the dialer profile. Dynamic multiple encapsulations provide support for PAD traffic and X.25 encapsulated and switched packets.
In previous Cisco IOS software releases, dialer profiles in the same dialer pool needed encapsulation-specific configuration information entered under both the dialer profile interface and the ISDN interface. If any conflict arose between the logical and the physical interfaces, the dialer profile failed to work.
In the new dialer profile model introduced by the Dynamic Multiple Encapsulations feature, the configuration on the ISDN interface is ignored and only the configuration on the profile interface is used, unless PPP name binding is used. Before a successful bind by CLID occurs, no encapsulation type and configuration are assumed or taken from the physical interfaces.
When PPP is used and a CLID bind fails, a dialer profile still can be matched by PPP name authentication. In the new dialer profile model, multiple attempts are made to find a matching profile.
PPP encapsulation on an ISDN link is different from other encapsulation types because it runs on the B channel rather than the dialer profile interface. There are two possible configuration sources in a profile bind: the D and the dialer profile interfaces. Hence, a configuration conflict between the sources is possible. If a successful bind is accomplished by name authentication, the configuration used to bring PPP up is the one on the D interface. This is the name used to locate a dialer profile for the bind. The configuration on an ISDN interface goes under the D rather than a B channel, although B channels inherit the configuration from their D interface.
However, the configuration on this found dialer profile could be different from the one on the D interface. For example, the ppp multilink command is configured on the D interface, but not on the dialer profile interface. The actual per-user configuration is the one on the dialer profile interface. In this case, per-user configuration is not achieved unless LCP and authentication are renegotiated. Because PPP client software often does not accept renegotiation, this workaround is not acceptable. Therefore, the D interface configuration takes precedence over the dialer profile interface configuration. This is the only case where the configuration of the dialer profile is overruled.
The changes to the virtual profile model are similar to those for the new dialer profile model. If a B interface is bound by CLID to a created virtual access interface cloned from a virtual profile or a virtual template interface, only the configuration from the virtual profile or the virtual template takes effect. The configuration on the D interface is ignored unless successful binding occurs by PPP name. Both the link and network protocols run on the virtual access interface instead of the B channel, unless the encapsulation is PPP.
Additionally, the old virtual profile model supported only PPP encapsulations. The new virtual profile model in Cisco IOS Release 12.0(7)T supports HDLC, LAPB, X.25, and Frame Relay encapsulations. Any commands for these encapsulations that can be configured under a serial interface can be configured under a virtual profile stored in a user file on an AAA server and a virtual profile virtual template configured locally. The AAA server daemon downloads the commands as text to the network access server, and is able to handle multiple download attempts.
Moreover, in the old virtual profile model, downloading a profile from an AAA server and creating and cloning a virtual access interface were always done after the PPP call answer and LCP up processes. The AAA download is part of authorization. But in the new model, these operations must be performed before the call is answered and the link protocol goes up. This is a new AAA nonauthenticated authorization step. The virtual profile code handles multiple download attempts, and identifies whether a virtual access interface was cloned from a downloaded virtual profile.
When a download succeeds through nonauthenticated authorization, and the configuration on the virtual profile has encapsulation PPP and PPP authentication, authentication is negotiated as a separate step after LCP comes up.
Table 1 lists the Frame Relay features that are supported by the Dynamic Multiple Encapsulations feature in Cisco IOS software release 12.0(7)T. This feature supports at least four Frame Relay PVCs on two dialer interfaces and subinterfaces.
| Frame Relay Feature | Supported? |
|---|---|
| Frame Relay Basic Features: | |
Frame Relay MIBs (RFC 1315 and Cisco Proprietary) | Yes |
Frame Relay PVC Support | Yes |
Frame Relay Subinterface | Yes |
Frame Relay Switching --- Packet Forwarding | No |
IP over Frame Relay (RFC 1490 and Cisco Encapsulation) | Yes |
LMI --- DTE Support | Yes |
LMI --- NNI, DCE Support | No |
Syslog for Frame Relay DLCI and Subinterface Status Changes | Yes |
| Multiprotocol Support: | |
ANSI T1.617 Encapsulation for X.25 (Annex G) | No |
Frame Relay Inverse ARP for Multiprotocol (RFC 1293/2390) | Yes |
Multiprotocol over Frame Relay (RFC 1490/2427 and Cisco Encapsulation) | Yes |
PPP over Frame Relay (RFC 1973) | No |
| Frame Relay QOS Support: | |
DE Bit Support | No |
DLCI Prioritization | Yes |
Enhanced Local Management Interface | No |
Frame Relay Fragmentation (FRF. 12) | No |
Frame Relay Router ForeSight (Same as CLLM) | No |
Frame Relay Traffic Shaping | No |
| Frame Relay Compression: | |
Cisco Proprietary Payload Compression | No |
Frame Relay Payload Compression (FRF. 9) | No |
Frame Relay RTP Header Compression (RFC 1889) | Yes |
Frame Relay TCP/IP Header Compression | Yes |
| Frame Relay Dial Support: | |
Frame Relay Interface/Subinterface Backup | No |
Legacy DDR over Frame Relay | Yes |
| Frame Relay Utilities: | |
AutoInstall over Frame Relay | No |
Frame Relay Broadcast Queue | Yes |
Frame Relay End-to-End Keepalive | No |
| Frame Relay Voice Support: | |
Voice over Frame Relay (FRF. 11) | No |
| Frame Relay Switching: | |
Advanced Frame Relay Switching with Traffic Management | No |
Frame Relay Switching over IP Tunnels | No |
| Frame Relay and ATM Interworking: | |
Frame Relay/ATM Network Interworking (FRF. 5) PVCs/Soft-VCs | No |
Frame Relay/ATM Service Interworking (FRF. 8) PVCs/Soft-VCs | No |
| Frame Relay SVC Support: | No |
Frame Relay SVC Support for DTE | No |
See the sections "Frame Relay Encapsulation on a Main Interface" and "Frame Relay Encapsulation on a Subinterface" in "Configuration Examples" for examples of Frame Relay encapsulations with the Dynamic Multiple Encapsulations feature.
Previously, when MLP was used in a dialer profile, a virtual access interface was always created as the bundle. It was bound to both the B channel and the dialer profile interfaces after creation and cloning. The dialer profile interface could act as the bundle without help from a virtual access interface. But with the current software enhancements available in Cisco IOS
Release 12.0(7)T, it is no longer the virtual access interface that is added into the connected group of the dialer profile, but the dialer profile itself. The dialer profile becomes a connected member of its own connected group.
Before the Dynamic Multiple Encapsulations feature, calls were screened in the ISDN process. ISDN accepted all synchronous calls and performed some minimal CLID screening before accepting or rejecting a call. With the Dynamic Multiple Encapsulations feature, DDR provides a separate process that screens for the profile of the caller. The new screening process also checks that enough resources are available to accept the call and that the call conforms to predetermined rules. When the call is found acceptable, the screening process searches for a matching profile for the caller. The call is accepted only when there is a matching profile.
In the old dialer profile model, fancy queueing and traffic shaping were configured under the physical interfaces. For ISDN, this was the D interface. Thus, the same queueing or traffic shaping scheme needed to be applied to all users that were sharing the same ISDN link.
The new dialer profile model moves all the per-user encapsulation configuration to the dialer profile interfaces, separating it from hardware interfaces to make it dynamic and also to make per-user queueing and traffic shaping configuration possible. You need only configure the queueing and traffic shaping schemes you desire on the dialer profile interface and the interface will take precedence over those configured on the ISDN B-channel interface. Per-user fancy queueing and traffic shaping work with both process switching and fast switching in the new dialer profile model. However, Frame Relay Traffic Shaping (FRTS) is not supported on the new dialer profile model.
Cisco IOS software Release 12.0(5)T enabled circuit-switched X.25 clients---PAD, X.25 switching, and QLLC---to initiate calls and dynamically bring the X.25 context (which runs the X.25 protocol) up or down as needed. This capability allowed packet-switched traffic over a digital link like ISDN.
Before Release 12.0(5)T, X.25 circuit-switched clients were required to perform an X.25 route lookup to forward a call. If the lookup resulted in a route to a dialer interface, the client would check the X.25 protocol state on the dialer interface. If the interface was not already bound to run the X.25 protocol, the software would reroute the call instead of bringing up a link and running the X.25 protocol. With this new feature, the X.25 context is dynamically created on demand and then removed when the X.25 session is cleared on the dialer interface.
For dialer profile interfaces, the X.25 context is created on the dialer interface, because X.25 protocol functions run on the dialer interface itself. Member links act like forwarding devices, because their topmost interface runs the actual encapsulated protocol. But for legacy dialer interfaces, the X.25 context is created on the member links once they come up and bind to a dialer.
See the section "Outbound Circuit-Switched X.25" in "Configuration Examples" for an example of how to set up this feature.
The Dynamic Multiple Encapsulations feature continues to support load balancing for the HDLC and PPP encapsulations, but not for LAPB, X.25, or Frame Relay. Load balancing is a Cisco-proprietary feature that brings up additional channels to handle intense packet traffic when a traffic threshold is configured with the dialer load-threshold command.
Previous releases of the DDR software allowed only one bind between a dialer profile and an ISDN B channel. If DNIS binding was used over an ISDN link, and only one dialer profile interface was configured with this DNIS, no other ISDN B channels could bind to the dialer profile interface after it was bound to another B channel because DNIS is not a user identification.
To overcome this problem, Cisco IOS Release 12.0(4)T provided a new dialer called command that allows DNIS-plus-ISDN-subaddress binding for the dialer profile in which the ISDN subaddress is a user identification. DNIS binding is allowed only when the ISDN subaddress is present in an incoming call and configured in a dialer profile. ISDN subaddresses are used mainly in Europe and Australia.
The list of authorized CLIDs and DNIS-plus-ISDN-subaddresses for each user is stored in a local dialer profile. The highest binding priority is configured as follows:
1. CLID binding
2. DNIS-plus-ISDN-subaddress binding
3. Name binding
4. Default binding (for no security check)
The Dynamic Multiple Encapsulations feature provides bidirectional support of all serial encapsulations except Frame Relay.
This feature also supports IP and IPX fast switching for HDLC and PPP encapsulations. There is no fast switching for LAPB, X.25, or Frame Relay; packets encapsulated by these protocols are always process switched.
The Dynamic Multiple Encapsulations feature changes the behavior of the DDR software functionality and serial line encapsulation. See the documents listed in the section "Related Documents" for background information about DDR and encapsulation methods.
For related information on the Dynamic Multiple Encapsulations feature, refer to the following documents:
None
No new or modified MIBs are supported by this feature.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
None
Before beginning the configuration tasks in this document, you must:
See the documents listed in the section "Related Documents" for additional references.
The Dynamic Multiple Encapsulations feature requires no new command to configure. It introduces new dialer profile behaviors over ISDN, rather than new configuration tasks. The only command added, dialer called, is not for configuring the Dynamic Multiple Encapsulations feature, but for configuring DNIS-plus-ISDN-subaddress profile binding.
To understand how dialer profiles work and how to configure them, see the Cisco IOS Release 12.0 Dial Solutions Configuration Guide and its chapters "Configuring Peer-to-Peer DDR with Dialer Profiles" and "Enterprise Dial Scenarios & Configurations." To understand the changes that the Dynamic Multiple Encapsulations feature and the Cisco IOS Release 12.0(4)T, 12.0(5)T, and 12.0(7)T software have made to the dialer profile model, see the section "Dial-on-Demand Routing Software Enhancements" earlier in this document.
To configure DNIS-plus-ISDN-subaddress binding, if appropriate for your network, perform the task described in the section "Configuring DNIS-plus-ISDN-Subaddress Binding" later in this document.
To verify that the Dynamic Multiple Encapsulations feature is operating, view the physical interface bindings in effect as a result of the Dynamic Multiple Encapsulations feature. This task is described in the section "Verifying the Dynamic Multiple Encapsulations Feature" later in this document.
To configure DNIS-plus-ISDN-subaddress binding, use the following command in dial-on-demand routing mode, which allows multiple binds between a dialer profile and an ISDN B channel. This configuration requires an ISDN subaddress, which is used in Europe and Australia.
| Command | Purpose |
|---|---|
Router(config)# dialer called | Binds a DNIS to an ISDN subaddress. |
To verify dialer interfaces configured for binding and see statistics on each physical interface bound to the dialer interface, use the show interfaces EXEC command. Look for the reports "Bound to:" and "Interface is bound to..." and remember that this feature only applies to ISDN.
Router# show interfaces dialer0
Dialer0 is up, line protocol is up Hardware is Unknown Internet address is 21.1.1.2/8 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 1 seconds on reset Interface is bound to BRI0:1 Last input 00:00:38, output never, output hang never Last clearing of "show interface" counters 00:05:36 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 38 packets input, 4659 bytes 34 packets output, 9952 bytesBound to:BRI0:1 is up, line protocol is up Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation PPP)LCP Open, multilink Open Last input 00:00:39, output 00:00:11, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 78 packets input, 9317 bytes, 0 no buffer Received 65 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 93 packets output, 9864 bytes, 0 underruns 0 output errors, 0 collisions, 7 interface resets 0 output buffer failures, 0 output buffers swapped out 4 carrier transitions
At the end of Dialer0 display, the show interfaces command is executed on each physical interface bound to it.
In the next example, the physical interface is the B1 channel of the BRI0 link. This example also illustrates that the output under the B channel keeps all hardware counts that are not displayed under any logical or virtual access interface. The line in the report that states "Interface is bound to Dialer0 (Encapsulation LAPB)" indicates that this B interface is bound to the dialer 0 interface and the encapsulation running over this connection is LAPB, not PPP, which is the encapsulation configured on the D interface and inherited by the B channel.
Router# show interfaces bri0:1
BRI0:1 is up, line protocol is up
Hardware is BRI
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation PPP, loopback not set, keepalive not set
Interface is bound to Dialer0 (Encapsulation LAPB)
LCP Open, multilink Open
Last input 00:00:31, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 1 packets/sec
110 packets input, 13994 bytes, 0 no buffer
Received 91 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
135 packets output, 14175 bytes, 0 underruns
0 output errors, 0 collisions, 12 interface resets
0 output buffer failures, 0 output buffers swapped out
8 carrier transitions
Any protocol configuration and states should be displayed from the dialer 0 interface.
This section provides the following configuration examples:
In the following configuration example, a network access server named NAS1 has dialer profiles, and LAPB, X.25, and PPP encapsulations configured. Although the BRI0 D interface uses X.25 encapsulation, the actual encapsulations running over the ISDN B channels are determined by the encapsulations configured on the profile interfaces bound to them.
When an ISDN B channel connects to remote user RU2 using CLID 60043, Dialer1 is bound to this ISDN B channel by CLID binding. The protocol used is PPP; the X.25 configuration on the D interface has no effect. Because the ppp authentication chap command is configured, even though the binding is done by CLID, PPP authentication is still performed over the name RU2 before the protocol is allowed to proceed.
The Dialer2 interface uses DNIS-plus-ISDN-subaddress binding, and is bound to a B channel with an incoming call with DNIS 60045 and ISDN subaddress 12345. Also note that the HDLC encapsulation has no username associated. It is no longer necessary to configure the dialer remote-name command, as in the previous dialer profile model.
When there is an ISDN B-channel connection to remote user RU1 using CLID 60036, LAPB encapsulation will run on this connection once CLID binding to Dialer0 takes place. This connection will operate as a standalone link independent of other activities over other ISDN B channels.
! version 12.0(4)T service timestamps debug datetime msec service timestamps log datetime msec service password-encryption service udp-small-servers service tcp-small-servers ! virtual-profile virtual-template 1 virtual-profile aaa ! hostname NAS1 ! aaa new-model aaa authentication ppp default radius aaa authorization network radius enable secret 5 $1$0Ced$YYJJl2p8f94lc/.JSgw8n1 enable password 7 153D19270D2E ! username RU1 password 7 11260B2E1E16 username RU2 password 7 09635C221001 no ip domain-lookup ip domain-name cisco.com ip name-server 198.92.30.32 ip name-server 171.69.2.132 isdn switch-type basic-5ess ! int Virtual-Template 1 encapsulation ppp ppp authentication chap ! interface Ethernet0 ip address 172.21.17.11 255.255.255.0 no ip mroute-cache no cdp enable ! interface Serial0 ip address 2.2.2.1 255.0.0.0 shutdown clockrate 56000 ppp authentication chap ! interface Serial1 ip address 10.0.0.1 255.0.0.0 shutdown ! interface BRI0 description PBX 60035 no ip address encapsulation x25 no ip mroute-cache no keepalive dialer pool-member 1 dialer pool-member 2 ! interface Dialer0 ip address 21.1.1.1 255.0.0.0 encapsulation lapb dce multi no ip route-cache no ip mroute-cache no keepalive dialer remote-name RU1 dialer idle-timeout 300 dialer string 60036 dialer caller 60036 dialer pool 1 dialer-group 1 no fair-queue ! interface Dialer1 ip address 22.1.1.1 255.0.0.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer remote-name RU2 dialer string 60043 dialer caller 60043 dialer pool 2 dialer-group 1 no fair-queue no cdp enable ppp authentication chap ! interface Dialer2 ip address 23.1.1.1 255.0.0.0 encapsulation hdlc dialer called 60045:12345 dialer pool 1 dialer-group 1 fair-queue ! radius-server host 171.69.61.87 radius-server key foobar snmp-server community public RO ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 password 7 10611B320C13 login ! end
The following example shows how to configure dynamic X.25 on an ISDN interface. Figure 2 illustrates the configuration.
version 12.0(5)T service timestamps debug uptime service timestamps log uptime no service password-encryption service udp-small-servers service tcp-small-servers ! hostname yen ! enable secret 5 $1$K32j$4AZW2oMDivpUeuMa/Fdcd. enable password poPPee ! username mark password 0 cisco username dinar password 0 cisco ip subnet-zero no ip domain-lookup ip domain-name cicso.com ip name-server 171.69.1.148 ! isdn switch-type basic-5ess x25 routing ! interface Loopback0 no ip address no ip directed-broadcast no ip mroute-cache ! interface Ethernet0 ip address 172.21.75.2 255.255.255.0 no ip directed-broadcast no ip mroute-cache media-type 10BaseT ! interface BRI1 no ip address no ip directed-broadcast no ip mroute-cache dialer pool-member 1 isdn switch-type basic-5ess no fair-queue ! interface Dialer0 ip address 2.1.1.1 255.0.0.0 no ip directed-broadcast encapsulation x25 no ip mroute-cache dialer remote-name dinar dialer idle-timeout 180 dialer string 81060 dialer caller 81060 dialer max-call 1 dialer pool 1 dialer-group 1 x25 address 11111 x25 map ip 2.1.1.2 22222 ! ip default-gateway 172.21.75.1 no ip classless ip route 0.0.0.0 0.0.0.0 172.21.75.1 no ip http server ! access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! x25 route 22222 interface Dialer0 x25 route 33333 interface Dialer0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 transport input all line vty 0 4 password cisco login line vty 5 100 password cisco login ! end
version 12.0(5)T service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname peso ! enable secret 5 $1$.Q00$h3vIhbOwO1fPvA2LYx2gE. enable password cisco ! ip subnet-zero ! isdn switch-type primary-5ess x25 routing ! controller T1 0 cablelength short cablelength short 133 ! controller T1 1 framing esf clock source line primary pri-group timeslots 1-24 ! controller T1 2 cablelength short cablelength short 133 ! controller T1 3 cablelength short cablelength short 133 ! interface Ethernet0 ip address 172.21.75.3 255.255.255.0 no ip directed-broadcast ! interface Serial1:23 no ip address no ip directed-broadcast encapsulation ppp dialer pool-member 1 isdn switch-type primary-5ess isdn incoming-voice modem no fair-queue no cdp enable ppp authentication chap ! interface Dialer0 no ip address no ip directed-broadcast encapsulation x25 dce no ip mroute-cache dialer remote-name yen dialer idle-timeout 180 dialer string 61401 dialer caller 61401 dialer max-call 1 dialer pool 1 x25 address 33333 ! interface Dialer1 no ip address no ip directed-broadcast encapsulation x25 dce no ip mroute-cache dialer remote-name dinar dialer idle-timeout 180 dialer string 61403 dialer caller 61403 dialer max-call 1 dialer pool 1 x25 address 44444 ! ip default-gateway 172.21.75.1 no ip classless ip route 0.0.0.0 0.0.0.0 172.21.75.1 no ip http server ! x25 route 11111 interface Dialer0 x25 route 22222 interface Dialer1 x25 route source 11111 interface Dialer1 x25 route input-interface Dialer0 interface Dialer1 ! line con 0 transport input none line 1 48 line aux 0 line vty 0 4 password cisco login line vty 5 100 password cisco login ! end
version 12.0(5)T service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname dinar ! logging buffered 16384 debugging enable secret 5 $1$8EjF$4.S0AoMOVa5OIAYEMrrFI/ enable password cisco ! username yen password 0 cisco username 7701 username drachma password 0 cisco username AODI password 0 cisco ip subnet-zero ip rcmd rcp-enable ip rcmd rsh-enable ip rcmd remote-username atirumal ! isdn switch-type basic-5ess x25 routing ! controller T1 0/0 ! interface BRI3/1 no ip address no ip directed-broadcast no ip mroute-cache dialer pool-member 1 isdn switch-type basic-5ess no fair-queue ! interface Dialer0 ip address 2.1.1.2 255.0.0.0 no ip directed-broadcast encapsulation x25 no ip mroute-cache dialer remote-name yen dialer idle-timeout 180 dialer string 81060 dialer caller 81060 dialer max-call 1 dialer pool 1 dialer-group 1 x25 address 22222 x25 map ip 2.1.1.1 11111 ! interface Dialer1 ip address 6.1.1.10 255.0.0.0 no ip directed-broadcast no ip mroute-cache dialer in-band dialer-group 1 no fair-queue ! ip default-gateway 172.21.75.1 no ip classless ip route 0.0.0.0 0.0.0.0 172.21.75.1 no ip http server ! access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! x25 route 11111 interface Dialer0 x25 route 44444 interface Dialer0 !
The following example shows a configuration for Frame Relay encapsulation on a main interface.
version 12.0(7)T service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname honda ! ip subnet-zero ip domain-name cisco.com ip name-server 171.69.2.132 ip name-server 198.92.30.32 ! isdn switch-type basic-5ess ! interface Loopback1 no ip address no ip directed-broadcast ! interface Ethernet0 ip address 172.21.17.18 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache media-type 10BaseT no cdp enable ! interface BRI0 description PBX 60043 no ip address no ip directed-broadcast no keepalive dialer pool-member 10 max-link 1 isdn switch-type basic-5ess no fair-queue ! interface Dialer10 ip address 8.1.1.1 255.255.255.0 no ip directed-broadcast encapsulation frame-relay dialer remote-name audi dialer string 60035 dialer caller 60035 dialer max-call 1 dialer pool 10 dialer-group 1 no fair-queue pulse-time 0 frame-relay map ip 8.1.1.2 200 ! dialer-list 1 protocol ip permit dialer-list 1 protocol ipx permit ! ip default-gateway 172.21.17.1 ip classless ip route 0.0.0.0 0.0.0.0 172.21.17.1 no ip http server ! line con 0 transport input none line aux 0 line vty 0 4 login ! end
The following example shows a configuration for Frame Relay encapsulation on a subinterface.
! version 12.0(7)T service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname honda ! interface Loopback1 no ip address no ip directed-broadcast ! interface Ethernet0 ip address 172.21.17.18 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache media-type 10BaseT no cdp enable ! interface BRI0 description PBX 60043 no ip address no ip directed-broadcast no keepalive dialer pool-member 10 max-link 1 isdn switch-type basic-5ess no fair-queue no cdp enable ! interface Dialer10 ip address 8.1.1.1 255.0.0.0 no ip directed-broadcast encapsulation frame-relay dialer remote-name audi dialer string 60035 dialer caller 60035 dialer max-call 1 dialer pool 10 dialer-group 1 no fair-queue pulse-time 0 ! interface Dialer10.1 point-to-point ip address 1.1.1.1 255.0.0.0 no ip directed-broadcast frame-relay interface-dlci 100 ! interface Dialer10.2 multipoint ip address 2.1.1.1 255.0.0.0 no ip directed-broadcast frame-relay interface-dlci 200 ! ip default-gateway 172.21.17.1 ip classless ip route 0.0.0.0 0.0.0.0 172.21.17.1 no ip http server ! dialer-list 1 protocol ip permit dialer-list 1 protocol ipx permit ! line con 0 transport input none line aux 0 line vty 0 4 login ! end
This section documents the following new and modified commands that configure the Dynamic Multiple Encapsulations feature. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
In Cisco IOS Release 12.0(1)T or later, you can search and filter the output for show and more commands. This functionality is useful when you need to sort through large amounts of output, or if you want to exclude output that you do not need to see.
To use this functionality, enter a show or more command followed by the "pipe" character (|), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expression
Following is an example of the show atm vc command in which you want the command output to begin with the first line where the expression "PeakRate" appears:
show atm vc | begin PeakRate
For more information on the search and filter functionality, refer to the Cisco IOS Release 12.0(1)T feature module titled CLI String Search.
To configure dial-on-demand routing (DDR) to perform DNIS-plus-ISDN-subaddress binding for dialer profile interfaces, use the dialer called dial-on-demand routing configuration command. To disable DNIS-plus-ISDN-subaddress binding, use the no form of this command.
dialer called DNIS:subaddress
DNIS:subaddress | Dialed Number Identification Service, or the called party number, a colon, and the ISDN subaddress. |
No default behavior or values.
Dial-on-demand routing
| Release | Modification |
|---|---|
12.0(4)T | This command was introduced. |
If you have more than one DNIS-plus-ISDN-subaddress number to configure under the same dialer profile interface, you can configure multiple dialer called commands.
The parser accepts a dialer called command with a DNIS and without the subaddress; however, the call will fail. For a successful call, enter the DNIS, a colon, and the ISDN subaddress after the dialer called command.
The following example configures a dialer profile for a receiver with DNIS 12345 and ISDN subaddress 6789:
dialer called 12345:6789
| Command | Description |
dial caller | Configures caller ID screening and enables ISDN caller ID callback for the dialer profiles DDR feature. |
To display statistics for all interfaces configured on the router or access server, use the show interfaces EXEC command. The resulting output varies, depending on the network for which an interface has been configured.
show interfaces [type number] [first] [last] [accounting]
type | (Optional) Interface type. Allowed values for type include async, bri0, dialer, ethernet, fastethernet, fddi, hssi, loopback, null, serial, tokenring, and tunnel. For Cisco 4000 series routers, type can be e1, ethernet, fastethernet, fddi, serial, t1, and token. For Cisco 4500 series routers, type can also include atm. For Cisco 7000 series routers, type can be atm, e1, ethernet, fastethernet, fddi, serial, t1, and tokenring. For Cisco 7500 series routers, type can also include pos. |
number | (Optional) Port number on the selected interface. |
first last | (Optional) For Cisco 2500 and 3000 series routers, ISDN BRI only. The argument first can be either 1 or 2. The argument last can only be 2, indicating B channels 1 and 2. D-channel information is obtained by using the show interfaces command without the optional arguments. |
accounting | (Optional) Displays the number of packets of each protocol type that have been sent through the interface. |
slot/port | (Optional) Refer to the appropriate hardware manual for slot and port information. |
port-adapter | (Optional) Refer to the appropriate hardware manual for port adapter compatibility information. |
Statistical display of all network interfaces.
EXEC
| Release | Modification |
|---|---|
Cisco IOS Release 10.0 | This command was introduced. |
Cisco IOS Release 12.0(4)T | The display was enhanced to report dialer bound interfaces. |
The report from this command for the Cisco 7200 series routers shows the interface processors in slot order. If you add interface processors after booting the system, they will appear at the end of the list, in the order in which they were inserted.
If you use the show interfaces command on the Cisco 7200 series routers without the slot/port arguments, information for all interface types will be shown. For example, if you use show interfaces ethernet you will receive information for all Ethernet, FDDI, serial, and Token Ring interfaces. Only by adding the type slot/port argument can you specify a particular interface.
If you use the show interfaces command for an interface type that has been removed from the router or access server, interface statistics will be displayed accompanied by the following text: "Hardware has been removed."
If you use the show interfaces command on a router or access server for which interfaces are configured to use weighted fair queueing through the fair-queue interface command, additional information is displayed containing the current and high-water mark number of flows.
If you use the show interfaces command on dialer interfaces configured for binding, the display will report statistics on each physical interface bound to the dialer interface; see the following examples for more information.
You will use the show interfaces command frequently while configuring and monitoring devices. The various forms of the show interfaces commands are described in detail in the following sections.
The following is sample output from the show interfaces command. Because your display will depend on the type and number of interface cards in your router or access server, only a portion of the output is shown.
Router# show interfaces
Ethernet 0 is up, line protocol is up
Hardware is MCI Ethernet, address is 0000.0c00.750c (bia 0000.0c00.750c)
Internet address is 131.108.28.8, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 10000 Kbit, DLY 100000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 4:00:00
Last input 0:00:00, output 0:00:00, output hang never
Last clearing of "show interface" counters 0:00:00
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 2000 bits/sec, 4 packets/sec
1127576 packets input, 447251251 bytes, 0 no buffer
Received 354125 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
5332142 packets output, 496316039 bytes, 0 underruns
0 output errors, 432 collisions, 0 interface resets, 0 restarts
---More---
When the show interfaces command is issued on an unbound dialer interface, the output looks as follows:
Router# show interfaces dialer0
Dialer0 is up (spoofing), line protocol is up (spoofing) Hardware is Unknown Internet address is 21.1.1.2/8 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 3/255 Encapsulation PPP, loopback not set DTR is pulsed for 1 seconds on reset Last input 00:00:34, output never, output hang never Last clearing of "show interface" counters 00:05:09 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 0 packets/sec 18 packets input, 2579 bytes 14 packets output, 5328 bytes
But when the show interfaces command is issued on a bound dialer interface, you will get an additional report indicating the binding relationship. The output looks as follows:
Router# show interfaces dialer0
Dialer0 is up, line protocol is up Hardware is Unknown Internet address is 21.1.1.2/8 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 1 seconds on reset Interface is bound to BRI0:1 Last input 00:00:38, output never, output hang never Last clearing of "show interface" counters 00:05:36 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 38 packets input, 4659 bytes 34 packets output, 9952 bytes Bound to: BRI0:1 is up, line protocol is up Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive not set Interface is bound to Dialer0 (Encapsulation PPP) LCP Open, multilink Open Last input 00:00:39, output 00:00:11, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 78 packets input, 9317 bytes, 0 no buffer Received 65 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 93 packets output, 9864 bytes, 0 underruns 0 output errors, 0 collisions, 7 interface resets 0 output buffer failures, 0 output buffers swapped out 4 carrier transitions
At the end of Dialer0 output, the show interfaces command is executed on each physical interface bound to it.
In the next example, the physical interface is the B1 channel of the BRI0 link. This example also illustrates that the output under the B channel keeps all hardware counts that are not displayed under any logical or virtual access interface. The line in the report that states "Interface is bound to Dialer0 (Encapsulation LAPB)" indicates that this B interface is bound to Dialer0 and the encapsulation running over this connection is LAPB, not PPP, which is the encapsulation configured on the
D interface and inherited by the B channel.
Router# show interfaces bri0:1
BRI0:1 is up, line protocol is up Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation LAPB)LCP Open, multilink Open Last input 00:00:31, output 00:00:03, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 110 packets input, 13994 bytes, 0 no buffer Received 91 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 135 packets output, 14175 bytes, 0 underruns 0 output errors, 0 collisions, 12 interface resets 0 output buffer failures, 0 output buffers swapped out 8 carrier transitions
Any protocol configuration and states should be displayed from the Dialer0 interface.
To enable virtual profiles by authentication, authorization, and accounting (AAA) configuration, use the virtual-profile aaa global configuration command. To disable virtual profiles, use the no form of this command.
virtual-profile aaaThis command has no arguments or keywords.
Disabled
Global configuration
| Release | Modification |
|---|---|
11.2 F | This command was introduced. |
12.0(7)T | This command was enhanced to allow virtual profiles to be downloaded from an AAA server using the HDLC, LAPB-TA, X.25, and Frame Relay encapsulations, in addition to the originally supported PPP encapsulation. |
Effect of this command for any specific user depends on the router being configured for AAA and the AAA server being configured for the specific configuration information of that user.
The following example configures virtual profiles by AAA configuration only:
virtual-profile aaa
| Command | Description |
aaa authentication | Enables AAA authentication. |
virtual-profile virtual-template | Enables virtual profiles by virtual interface template. |
AAA---authentication, authorization, and accounting. Suite of network security services that provide the primary framework through which access control can be set up on your Cisco router or access server.
Asynchronous Transfer Mode---See ATM.
ATM---Asynchronous Transfer Mode. International standard for cell relay in which multiple service types (such as voice, video, or data) are conveyed in fixed-length (53-byte) cells. Fixed-length cells allow cell processing to occur in hardware, thereby reducing transit delays. ATM is designed to take advantage of high-speed transmission media such as E3, SONET, and T3.
authentication, authorization, and accounting---See AAA.
calling line identification---See CLID.
CLID---calling line identification. A unique number that informs the called party of the phone number identification of the calling party. Also known as caller ID.
data circuit-terminating equipment---See DCE.
data terminal equipment---See DTE.
DCE---data circuit-terminating equipment (ITU-T expansion). Devices and connections of a communications network that comprise the network end of the user-to-network interface. The DCE provides a physical connection to the network, forwards traffic, and provides a clocking signal used to synchronize data transmission between DCE and DTE devices. Modems and interface cards are examples of DCE.
DDR---dial-on-demand routing. Technique whereby a router can automatically initiate and close a circuit-switched session as transmitting stations demand. The router spoofs keepalive messages so that end stations treat the session as active. DDR permits routing over ISDN or telephone lines using an external ISDN terminal adapter or modem.
DE bit---discard eligible bit. ATM cells can have this bit set to determine the probability of a cell being dropped if the network becomes congested.
Dialed Number Identification Service---See DNIS.
dialer profile---Dialer profiles allow the configuration of physical interfaces to be separated from the logical configuration required for a call, and they also allow the logical and physical configurations to be bound together dynamically on a per-call basis. A dialer profile has the following elements: a dialer interface (a logical entity) configuration including one or more dial strings (each of which is used to reach one destination subnetwork), a dialer map class that defines all the characteristics for any call to the specified dial string, and an ordered dialer pool of physical interfaces to be used by the dialer interface.
dial-on-demand routing---See DDR.
DNIS---Dialed Number Identification Service. The called party number. Typically, this is a number used by call centers or a central office where different numbers are each assigned to a specific service.
DTE---data terminal equipment. Device at the user end of a user-network interface that serves as a data source, destination, or both. DTE connects to a data network through a DCE device (for example, a modem) and typically uses clocking signals generated by the DCE. DTE includes such devices as computers, protocol translators, and multiplexers.
Frame Relay---Industry-standard, switched data link layer protocol that handles multiple virtual circuits using HDLC encapsulation between connected devices. Frame Relay is more efficient than X.25, the protocol for which it is generally considered a replacement.
HDLC---High-Level Data Link Control. Popular ISO standard bit-oriented, link-layer protocol derived from the Synchronous Data Link Control Protocol. HDLC specifies an encapsulation method of data on synchronous serial data links.
High-Level Data Link Control---See HDLC.
Integrated Services Digital Network---See ISDN.
ISDN---Integrated Services Digital Network. Communication protocol, offered by telephone companies, that permits telephone networks to carry data, voice, and other source traffic.
LAPB-TA---Link Access Procedure, Balanced-terminal adapter. LAPB is a bit-oriented protocol derived from HDLC.
LCP---Link Control Protocol. Protocol that establishes, configures, and tests data-link connections for use by PPP.
Link Access Procedure, Balanced-terminal adapter---See LAPB-TA.
Link Control Protocol---See LCP.
LMI---Local Management Interface. Set of enhancements to the basic Frame Relay specification. LMI includes support for a keepalive mechanism, which verifies that data is flowing; a multicast mechanism, which provides the network server with its local DLCI and the multicast DLCI; global addressing, which gives DLCIs global rather than local significance in Frame Relay networks; and a status mechanism, which provides an ongoing status report on the DLCIs known to the switch. Known as LMT in ANSI terminology.
Local Management Interface---See LMI.
MLP---Multilink PPP. Method of splitting, recombining, and sequencing datagrams across multiple logical data links.
Multilink PPP---See MLP.
NCP---Network Control Protocol. Series of protocols for establishing and configuring different network layer protocols, such as for AppleTalk over PPP.
Network Control Protocol---See NCP.
packet assembler/disassembler---See PAD.
PAD---packet assembler/disassembler. Device used to connect simple devices (like character-mode terminals) that do not support the full functionality of a particular protocol to a network. PADs buffer data and assemble and disassemble packets sent to such end devices.
permanent virtual circuit---See PVC.
per-user configuration---Ties together virtual interfaces configuration, AAA per-user security, and virtual profiles to provide a flexible, scalable, easily maintained solution for large-scale dial-in networks.
Point-to-Point Protocol---See PPP.
PPP---Point-to-Point Protocol. Provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. PPP also has built-in security mechanisms, such as the Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). PPP relies on two protocols: LCP and NCP.
PVC---permanent virtual circuit or permanent virtual connection. Virtual circuit that is permanently established. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time. In ATM terminology, called a permanent virtual connection.
Qualified Logical Link Control---See QLLC.
QLLC---Qualified Logical Link Control. Data link layer protocol defined by IBM that allows SNA data to be transported across X.25 networks.
RTP header compression---Real-Time Transport Protocol header compression. Compresses the IP/UDP/RTP header in an RTP data packet from 40 bytes to approximately 2 to 5 bytes. It is a hop-by-hop compression scheme similar to RFC 1144 for TCP header compression. RTP header compression is supported on serial lines using Frame Relay, HDLC, or PPP encapsulation. It is also supported over ISDN interfaces.
virtual access interface---Instance of a unique virtual interface that is created dynamically and exists temporarily. Virtual access interfaces can be created and configured differently by different applications, such as virtual profiles and virtual dialup networks.
virtual interface template---Generic configuration of an interface for a certain purpose or configuration common to certain users, plus router-dependent information. This configuration takes the form of a list of Cisco IOS interface commands to be applied to the virtual interface as needed. Several applications can apply virtual templates, but generally each application uses a single template. Each virtual template is identified by number.
virtual profile---A virtual profile defines and applies per-user configuration information for users that 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.
X.25---ITU-T standard that defines how connections between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) are maintained for remote terminal access and computer communications in public data networks (PDNs). X.25 specifies LAPB, a data link layer protocol, and packet level protocol (PLP), a network layer protocol.
Posted: Mon Jan 3 10:29:45 PST 2000
Copyright 1989-1999©Cisco Systems Inc.