|
|
This document describes Dynamic Multiple Encapsulations for dial-in over ISDN in the following sections:
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.
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 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.
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.
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).
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.
The Dynamic Multiple Encapsulations feature continues to support load balancing for HDLC and PPP, but not for LAPB or X.25.
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.
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.
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:
Before beginning the configuration tasks in this document, you must:
See the documents listed in the section "Related Documents" for additional references.
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.
None
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:
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 Dialed Number Identification Service 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 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 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.
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)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
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.
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 then 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 Basic Rate Interface (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 information about port adapter compatibility. |
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 interface 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.
The following shows partial sample output when custom output queueing is enabled:
Last clearing of "show interface" counters 0:00:06
Input queue: 0/75/0 (size/max/drops); Total output drops: 21
Output 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/0
6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0 10: 0/20/0
When 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 Table 1.
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 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
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)
Table 1 describes the input queue and output queue fields shown in the preceding output.
| Field | Description |
|---|---|
Input queue: |
|
| Current size of the input queue. |
| Maximum size of the queue. |
| Number of messages discarded in this interval. |
| Total number of messages discarded in this session. |
Output queue: |
|
| Current size of the output queue. |
| Congestive-discard threshold. Number of messages in the queue after which new messages for high-bandwidth conversations are dropped. |
| Number of messages discarded in this interval. |
| Number of currently active conversations. |
| Maximum number of concurrent conversations allowed. |
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.
Table 2 lists the protocols for which per-packet accounting information is kept.
| Protocol | Notes |
|---|---|
Apollo | No note. |
AppleTalk | No note. |
For IP, Apollo, Frame Relay, SMDS. | |
CLNS | No note. |
DEC MOP | The routers use MOP packets to advertise their existence to Digital Equipment Corporation machines that use the MOP protocol. A router periodically broadcasts MOP packets to identify itself as a MOP host. This results in MOP packets being counted, even when DECnet is not being actively used. |
DECnet | No note. |
HP Probe | No note. |
IP | No note. |
LAN Manager | LAN Network Manager and IBM Network Manager. |
Novell | No note. |
Serial Tunnel | SDLC. |
Spanning Tree | No note. |
SR Bridge | No note. |
Transparent Bridge | No note. |
VINES | No note. |
XNS | No note. |
The following is sample output from the show interfaces accounting command:
Router# show interfaces accounting
Interface TokenRing0 is disabled
Ethernet0
Protocol Pkts In Chars In Pkts Out Chars Out
IP 873171 735923409 34624 9644258
Novell 163849 12361626 57143 4272468
DEC MOP 0 0 1 77
ARP 69618 4177080 1529 91740
Interface Serial0 is disabled
Ethernet1
Protocol Pkts In Chars In Pkts Out Chars Out
IP 0 0 37 11845
Novell 0 0 4591 275460
DEC MOP 0 0 1 77
ARP 0 0 7 420
Interface Serial1 is disabled
Interface Ethernet2 is disabled
Interface Serial2 is disabled
Interface Ethernet3 is disabled
Interface Serial3 is disabled
Interface Ethernet4 is disabled
Interface Ethernet5 is disabled
Interface Ethernet6 is disabled
Interface Ethernet7 is disabled
Interface Ethernet8 is disabled
Interface Ethernet9 is disabled
Fddi0
Protocol Pkts In Chars In Pkts Out Chars Out
Novell 0 0 183 11163
ARP 1 49 0 0
When the output indicates an interface is "disabled," the router has received an excessive number of errors (over 5000 in a keepalive period).
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.
Posted: Mon Jan 10 18:41:56 PST 2000
Copyright 1989-2000©Cisco Systems Inc.