Table Of Contents
Dynamic Multiple Encapsulations
for Dial-In over ISDNDial-on-Demand Routing Software Enhancements
Dynamic, Multiple HDLC, PPP, and X.25 Encapsulations
DNIS-Plus-ISDN-Subaddress Multiple Call Binding Strategy
More Efficient ISDN Call Screening
Fancy Queueing and Traffic Shaping
Related Features and Technologies
Configuring DNIS-plus-ISDN-Subaddress Binding
Verifying the Dynamic Multiple Encapsulations Feature
Sample Output with DNIS Binding
Sample Output with Custom Output Queueing
Sample Output Including Weighted Fair Queueing Output
Sample Output with Accounting Option
Sample Show Interfaces Accounting Output
Dynamic Multiple Encapsulations
for Dial-In over ISDN
This document describes Dynamic Multiple Encapsulations for dial-in over ISDN in the following sections:
Feature Overview
The Dynamic Multiple Encapsulations feature allows incoming calls over Integrated Services Digital Network (ISDN) to be assigned an encapsulation type such as Point-to-Point Protocol (PPP), and X.25 based on calling line identification (CLID) or Dialed Number Identification Service (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 make sure 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.
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.
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.
Figure 1 European X.25 Network
Although the Dynamic Multiple Encapsulations feature enhances large scale dial-in functionality, the feature also works well in smaller scale dial-in situations.
Dial-on-Demand Routing Software Enhancements
The following sections describe the enhancements to the dial-on-demand routing (DDR) software that enable the Dynamic Multiple Encapsulations feature.
Dynamic, Multiple HDLC, PPP, and X.25 Encapsulations
Before the Dynamic Multiple Encapsulations feature, encapsulation techniques such as X.25 could only support one ISDN B-channel connection over the entire link. High-Level Data Link Control (HDLC) and PPP could support multiple B channels, but the entire ISDN link had 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.
For X.25 encapsulations, the configurations reside on the dialer profile. Dynamic multiple encapsulations provide support for incoming packet assembler/dissassembler (PAD) traffic and X.25 encapsulated and switched packets.
New Dialer Profile Model
In previous Cisco IOS software, dialer profiles in the same dialer pool needed to have 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 them 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 the link control protocol (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 dialer profile's configuration is overruled.
DNIS-Plus-ISDN-Subaddress Multiple Call Binding Strategy
Previous releases of the dial-on-demand routing (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 provides 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: CLID binding, followed by DNIS-plus-ISDN-subaddress binding, followed by name binding, followed by default binding (for no security check).
More Efficient ISDN Call Screening
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 caller's profile. 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.
Load Balancing
The Dynamic Multiple Encapsulations feature continues to support load balancing for HDLC and PPP, but not for LAPB or X.25.
Fancy Queueing and Traffic Shaping
In the old dialer profile model, fancy queueing and traffic shaping were configured under the physical interfaces. In the case of ISDN, it was the D interface. Thus, the same queueing or traffic shaping scheme needed to be applied to all users who 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.
Benefits
•
Allows incoming calls over ISDN to be assigned an encapsulation type such as PPP, or X.25 based on CLID or DNIS.
•
•
•
•
Restrictions
The Dynamic Multiple Encapsulations feature provides bidirectional support of all serial encapsulations except Frame Relay, and only provides inbound support for X.25 traffic.
The Dynamic Multiple Encapsulations feature also supports IP and IPX fast switching for HDLC and PPP encapsulations. There is no fast switching for LAPB or X.25; packets encapsulated by these protocols are always process switched.
Related Features and Technologies
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.
Related Documents
For related information on the Dynamic Multiple Encapsulations feature, refer to the following documents:
•
•
Supported Platforms
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Prerequisites
Before beginning the configuration tasks in this document, you must:
•
•
See the documents listed in the section "Related Documents" for additional references.
Supported MIBs and RFCs
MIBs
None
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.
RFCs
None
Configuration Tasks
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 new command added, dialer called, is not for configuring the Dynamic Multiple Encapsulations feature but for configuring the new type of 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 the 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 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, perform the following task:
•
To verify that the Dynamic Multiple Encapsulations feature is operating, perform the following task:
•
Configuring DNIS-plus-ISDN-Subaddress Binding
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.
Binds a Dialed Number Identification Service to an ISDN subaddress.
Verifying the Dynamic Multiple Encapsulations Feature
To verify dialer interfaces configured for binding and see statistics on each physical interface bound to the dialer interface, use the show interfaces command. Look for the reports "Bound to:" and "Interface is bound to..." while keeping in mind that this feature only applies to ISDN.
Router# show interfaces dialer0Dialer0 is up, line protocol is upHardware is UnknownInternet address is 21.1.1.2/8MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not setDTR is pulsed for 1 seconds on resetInterface is bound to BRI0:1Last input 00:00:38, output never, output hang neverLast clearing of "show interface" counters 00:05:36Queueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec38 packets input, 4659 bytes34 packets output, 9952 bytesBound to:BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation PPP)LCP Open, multilink OpenLast input 00:00:39, output 00:00:11, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec78 packets input, 9317 bytes, 0 no bufferReceived 65 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort93 packets output, 9864 bytes, 0 underruns0 output errors, 0 collisions, 7 interface resets0 output buffer failures, 0 output buffers swapped out4 carrier transitionsAt 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:1BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation LAPB)LCP Open, multilink OpenLast input 00:00:31, output 00:00:03, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 1 packets/sec5 minute output rate 0 bits/sec, 1 packets/sec110 packets input, 13994 bytes, 0 no bufferReceived 91 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort135 packets output, 14175 bytes, 0 underruns0 output errors, 0 collisions, 12 interface resets0 output buffer failures, 0 output buffers swapped out8 carrier transitionsAny protocol configuration and states should be displayed from the dialer 0 interface.
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 user name 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)Tservice timestamps debug datetime msecservice timestamps log datetime msecservice password-encryptionservice udp-small-serversservice tcp-small-servers!virtual-profile virtual-template 1virtual-profile aaa!hostname NAS1!aaa new-modelaaa authentication ppp default radiusaaa authorization network radiusenable secret 5 $1$0Ced$YYJJl2p8f94lc/.JSgw8n1enable password 7 153D19270D2E!username RU1 password 7 11260B2E1E16username RU2 password 7 09635C221001no ip domain-lookupip domain-name cisco.comip name-server 198.92.30.32ip name-server 171.69.2.132isdn switch-type basic-5ess!int Virtual-Template 1encapsulation pppppp authentication chap!interface Ethernet0ip address 172.21.17.11 255.255.255.0no ip mroute-cacheno cdp enable!interface Serial0ip address 2.2.2.1 255.0.0.0shutdownclockrate 56000ppp authentication chap!interface Serial1ip address 10.0.0.1 255.0.0.0shutdown!interface BRI0description PBX 60035no ip addressencapsulation x25no ip mroute-cacheno keepalivedialer pool-member 1dialer pool-member 2!interface Dialer0ip address 21.1.1.1 255.0.0.0encapsulation lapb dce multino ip route-cacheno ip mroute-cacheno keepalivedialer remote-name RU1dialer idle-timeout 300dialer string 60036dialer caller 60036dialer pool 1dialer-group 1no fair-queue!interface Dialer1ip address 22.1.1.1 255.0.0.0encapsulation pppno ip route-cacheno ip mroute-cachedialer remote-name RU2dialer string 60043dialer caller 60043dialer pool 2dialer-group 1no fair-queueno cdp enableppp authentication chap!interface Dialer2ip address 23.1.1.1 255.0.0.0encapsulation hdlcdialer called 60045:12345dialer pool 1dialer-group 1fair-queue!radius-server host 171.69.61.87radius-server key foobarsnmp-server community public RO!line con 0exec-timeout 0 0line aux 0transport input allline vty 0 4password 7 10611B320C13login!endCommand Reference
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 references.
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.
dialer called
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
no dialer called DNIS:subaddressSyntax Description
DNIS:subaddress
Dialed Number Identification Service, or the called party number, a colon, and then the ISDN subaddress.
Defaults
No default behavior or values.
Command Modes
Dial-on-demand routing
Command History
Usage Guidelines
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 .
Examples
The following example configures a dialer profile for a receiver with DNIS 12345 and ISDN subaddress 6789:
dialer called 12345:6789Related Commands
dial caller
Configures caller ID screening and enables ISDN caller ID callback for the dialer profiles DDR feature.
show interfaces
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]
show interfaces [type slot/port] [accounting] (for Cisco 7200 series routers, and for
Cisco 7500 series routers with a Packet-over-SONET Interface Processor)
show interfaces [type slot/port-adapter/port] [ethernet | serial] (for ports on a Versatile
Interface Processor (VIP) in Cisco 7500 series routers)Syntax Description
Defaults
Statistical display of all network interfaces.
Command Modes
EXEC
Command History
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.
Usage Guidelines
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.
Examples
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 interfacesEthernet 0 is up, line protocol is upHardware 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.0MTU 1500 bytes, BW 10000 Kbit, DLY 100000 usec, rely 255/255, load 1/255Encapsulation ARPA, loopback not set, keepalive set (10 sec)ARP type: ARPA, ARP Timeout 4:00:00Last input 0:00:00, output 0:00:00, output hang neverLast clearing of "show interface" counters 0:00:00Output queue 0/40, 0 drops; input queue 0/75, 0 dropsFive minute input rate 0 bits/sec, 0 packets/secFive minute output rate 2000 bits/sec, 4 packets/sec1127576 packets input, 447251251 bytes, 0 no bufferReceived 354125 broadcasts, 0 runts, 0 giants0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort5332142 packets output, 496316039 bytes, 0 underruns0 output errors, 432 collisions, 0 interface resets, 0 restarts---More---Sample Output with DNIS Binding
When the show interfaces command is issued on an unbound dialer interface, the output looks as follows:
Router# show interfaces dialer0Dialer0 is up (spoofing), line protocol is up (spoofing)Hardware is UnknownInternet address is 21.1.1.2/8MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 3/255Encapsulation PPP, loopback not setDTR is pulsed for 1 seconds on resetLast input 00:00:34, output never, output hang neverLast clearing of "show interface" counters 00:05:09Queueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 1000 bits/sec, 0 packets/sec18 packets input, 2579 bytes14 packets output, 5328 bytesBut 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 dialer0Dialer0 is up, line protocol is upHardware is UnknownInternet address is 21.1.1.2/8MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not setDTR is pulsed for 1 seconds on resetInterface is bound to BRI0:1Last input 00:00:38, output never, output hang neverLast clearing of "show interface" counters 00:05:36Queueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec38 packets input, 4659 bytes34 packets output, 9952 bytesBound to:BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation PPP)LCP Open, multilink OpenLast input 00:00:39, output 00:00:11, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec78 packets input, 9317 bytes, 0 no bufferReceived 65 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort93 packets output, 9864 bytes, 0 underruns0 output errors, 0 collisions, 7 interface resets0 output buffer failures, 0 output buffers swapped out4 carrier transitionsAt 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 interface bri0:1BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation LAPB)LCP Open, multilink OpenLast input 00:00:31, output 00:00:03, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 1 packets/sec5 minute output rate 0 bits/sec, 1 packets/sec110 packets input, 13994 bytes, 0 no bufferReceived 91 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort135 packets output, 14175 bytes, 0 underruns0 output errors, 0 collisions, 12 interface resets0 output buffer failures, 0 output buffers swapped out8 carrier transitionsAny protocol configuration and states should be displayed from the Dialer0 interface.
Sample Output with Custom Output Queueing
The following shows partial sample output when custom output queueing is enabled:
Last clearing of "show interface" counters 0:00:06Input queue: 0/75/0 (size/max/drops); Total output drops: 21Output queues: (queue #: size/max/drops)0: 14/20/14 1: 0/20/6 2: 0/20/0 3: 0/20/0 4: 0/20/0 5: 0/20/06: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0 10: 0/20/0When custom queueing is enabled, the drops accounted for in the output queues result from bandwidth limitation for the associated traffic and lead to queue length overflow. Total output drops include drops on all custom queues and the system queue. Fields are described with the weighted fair queueing output in .
Sample Output Including Weighted Fair Queueing Output
For each interface on the router or access server configured to use weighted fair queueing, the show interfaces command displays the information beginning with "Input queue:" in the following output:
Router# show interfacesEthernet 0 is up, line protocol is upHardware 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.0MTU 1500 bytes, BW 10000 Kbit, DLY 100000 usec, rely 255/255, load 1/255Encapsulation ARPA, loopback not set, keepalive set (10 sec)ARP type: ARPA, ARP Timeout 4:00:00Last input 0:00:00, output 0:00:00, output hang neverLast clearing of "show interface" counters 0:00:00Output queue 0/40, 0 drops; input queue 0/75, 0 dropsFive minute input rate 0 bits/sec, 0 packets/secFive minute output rate 2000 bits/sec, 4 packets/sec1127576 packets input, 447251251 bytes, 0 no bufferReceived 354125 broadcasts, 0 runts, 0 giants0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort5332142 packets output, 496316039 bytes, 0 underruns0 output errors, 432 collisions, 0 interface resets, 0 restarts Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Output queue: 7/64/0 (size/threshold/drops) Conversations 2/9 (active/max active)describes the input queue and output queue fields shown in the preceding output.
Sample Output with Accounting Option
To display the number of packets of each protocol type that have been sent through all configured interfaces, use the show interfaces accounting command. When you use the accounting option, only the accounting statistics are displayed.
Note
lists the protocols for which per-packet accounting information is kept.
Sample Show Interfaces Accounting Output
The following is sample output from the show interfaces accounting command:
Router# show interfaces accountingInterface TokenRing0 is disabledEthernet0Protocol Pkts In Chars In Pkts Out Chars OutIP 873171 735923409 34624 9644258Novell 163849 12361626 57143 4272468DEC MOP 0 0 1 77ARP 69618 4177080 1529 91740Interface Serial0 is disabledEthernet1Protocol Pkts In Chars In Pkts Out Chars OutIP 0 0 37 11845Novell 0 0 4591 275460DEC MOP 0 0 1 77ARP 0 0 7 420Interface Serial1 is disabledInterface Ethernet2 is disabledInterface Serial2 is disabledInterface Ethernet3 is disabledInterface Serial3 is disabledInterface Ethernet4 is disabledInterface Ethernet5 is disabledInterface Ethernet6 is disabledInterface Ethernet7 is disabledInterface Ethernet8 is disabledInterface Ethernet9 is disabledFddi0Protocol Pkts In Chars In Pkts Out Chars OutNovell 0 0 183 11163ARP 1 49 0 0When the output indicates an interface is "disabled," the router has received an excessive number of errors (over 5000 in a keepalive period).
Glossary
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.
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.
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.
HDLC—High-Level Data Link Control. Popular ISO standard bit-oriented, link-layer protocol derived from the Synchronous Data Link 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.
LCP—link control protocol. Protocol that establishes, configures, and tests data-link connections for use by PPP.
link control protocol—See LCP.
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.
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.
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.
Guest
