|
|
This chapter describes how to make adjustments to, or how to fine tune, the interfaces, and how to enable loopback tests. You will find information about the following processes in this chapter:
To adjust or test an interface, you must be in the configuration command collection mode. To enter this mode, type the EXEC command configure at the EXEC prompt. Once in the command collection mode, start configuring the interface by entering the interface command.
A command summary is included at the end of the chapter.
The following sections describe adjustments that can be made to serial interfaces.
Since the MCI interface card can send back-to-back data packets over serial interfaces faster than some hosts can receive them, you can specify a minimum dead-time after transmitting a packet. Do this using the transmitter-delay interface subcommand. It is especially useful for serial interfaces. The full syntax of the command follows.
transmitter-delay microsecondsThe argument microseconds specifies the approximate number of microseconds of minimum delay after transmitting a packet. The default value is zero; the no transmitter-delay command restores this default.
This command specifies a delay of 300 microseconds on interface serial 0:
interface serial 0 transmitter-delay 300
The pulse-time interface subcommand enables pulsing DTR signals on the MCI serial interface. The full syntax of the command follows.
pulse-time secondsThe argument seconds specifies the interval.When the serial line protocol goes down (for example, because of loss of synchronization) the interface hardware is reset and the DTR signal is held inactive for at least the specified interval. This function is useful for handling encrypting or other similar devices that use the toggling of the DTR signal to resynchronize.
The default interval is zero seconds, which is restored by the no pulse-time command.
This command enables DTR pulse signals for three seconds on interface serial 2:
interface serial 2 pulse-time 3
You can configure the clock rate for appliques (connector hardware) on the serial interface of the MCI and SCI cards to an acceptable bit rate using the clockrate interface subcommand. The full syntax is as follows:
clockrate speedThe argument speed is the desired clock rate, and can be one of any of the rates in Table 1-1.
| 1200 | 2400 | 4800 |
| 9600 | 19200 | 34800 |
| 56000 | 64000 | 72000 |
| 125000 | 148000 | 500000 |
| 800000 | 1000000 | 1300000 |
| 2000000 | 4000000 |
Be aware that the fastest speeds might not work if your cable is too long, and that speeds faster than 148,000 bits per second are too fast for RS-232 signaling. It is recommended that you only use the synchronous serial RS-232 signal at speeds up to 64,000 bits per second. To permit a faster speed, use an RS-449 or V.35 applique.
Use the no clockrate command to remove the clock rate if you change the interface from a DCE to a DTE device.
These sample commands set the clock rate on the first serial interface to 64,000 bits per second.
interface serial 0 clockrate 64000
The following sections describe adjustments that apply to all interface types.
The normal operation of the network server allows the switching operations to use as much of the central processor as is required. If the network is running unusually heavy loads that do not allow the processor the time to handle the routing protocols, give priority to the system process scheduler using the scheduler-interval global configuration command. The full command syntax follows:
scheduler-interval millisecondsThe scheduler-interval command controls the maximum amount of time that may elapse without running the lowest priority system processes. The minimum interval that you can specify is 500 milliseconds; there is no maximum value. The default is to allow high-priority operations to use as much of the central processor as needed. The no scheduler-interval command restores that default.
This command changes the low-priority process schedule to an interval of 750 milliseconds.
scheduler-interval 750
Priority output queuing is a mechanism that allows the administrator to set priorities on the type of traffic passing through the network. It is a mechanism for prioritizing packets transmitted on an interface. Packets are classified according to various criteria, including protocol and subprotocol type, and then queued on one of four output queues.
When the network server is ready to transmit a packet, it scans the priority queues in order, from highest to lowest, to find the highest priority packet. After that packet is completely transmitted, the network server scans the priority queues again. If a priority output queue fills up, packets will be dropped and, for IP, quench indications will be sent to the original transmitter.
Although you can enable priority output queuing for any interface, the intended application was for low bandwidth, congested serial interfaces.
Cisco's priority output queuing mechanism allows traffic control based on protocol or interface type. Commands are also offered to set the size of the queue, and defaults for what happens to packets that are not defined by priority output queue rules.
The priority output queuing mechanism can be used to manage traffic from all networking protocols. Additional fine-tuning is available for IP and for setting boundaries on the packet size.
There are four priority queues--high, medium, normal, and low--listed in order from highest to lowest priority.
Keepalives sourced by the network server are always assigned to the high priority queue; all other management traffic (such as IGRP updates) must be configured. Packets that are not classified by the priority list mechanism are assigned to the normal queue.
A priority list is a set of rules that describes how packets should be assigned to priority queues. A priority list may also describe a default priority or the queue size limits of the various priority queues.
Use the priority-list global configuration command to establish queuing priorities based upon the protocol type. The full syntax of this command follows:
priority-list list protocol protocol-name queue-keyword [args]The argument list is an arbitrary integer between one and ten that identifies the priority list selected by the user.
The keyword protocol is used with the argument protocol-name to specify the protocol you are using.
The argument queue-keyword is a priority queue name, high, medium, normal, or low.
Optional arguments (args) may be specified, depending on the protocol-name keyword, as follows:
| Service | Port |
|---|---|
| Telnet | 23 |
| SMTP | 25 |
| Service | Port |
|---|---|
| TFTP | 69 |
| NFS | 2049 |
| SNMP | 161 |
| RPC | 111 |
| DNS | 53 |
Use the no priority-list global configuration command with the appropriate arguments to remove an entry from the list.
The following example assigns a high priority to traffic that matches IP access list 10:
! priority-list 1 protocol ip high list 10 !
The following example assigns a medium priority level to Telnet packets:
! priority-list 4 protocol ip medium tcp 23 !
The following example assigns a medium priority level to UDP Domain Name service packets:
! priority-list 4 protocol ip medium udp 53 !
When using multiple rules for a single protocol, remember that the order of the rules matters.
Use this variation of the priority-list global configuration command to establish queuing priorities on packets entering from a given interface (full syntax follows):
priority-list list interface interface-name queue-keywordThe argument list is an arbitrary integer between one and ten that identifies the priority list selected by the user.
The keyword interface applies to the priority queuing mechanism to packets arriving from an interface. The argument interface-name specifies the name of the interface and can be serial, ethernet, tokenring, or async.
The argument queue-keyword is a priority queue name, either high, medium, normal, or low.
Use the no priority-list command with the appropriate arguments to remove an entry from the list.
The following example sets any packet type entering on interface Ethernet 0 to a medium priority:
! priority-list 3 interface ethernet 0 medium !
Use the following global configuration command to assign a priority queue for those packets that did not match any other rule in the priority list:
priority-list list default queue-keywordThe argument list is an arbitrary integer between one and ten that identifies the priority list selected by the user.
The argument queue-keyword is a priority queue name, either high, medium, normal, or low.
If you do not specify a default to use the no form of the command, the normal queue is assumed.
Use this variation of the priority-list global configuration command to specify the maximum number of packets that may be waiting in each of the priority queues:
priority-list list queue-limit {high|medium|normal|low}If a priority queue overflows, excess packets are discarded and quench messages may be sent, if appropriate, for the protocol. The default queue-limit arguments are 20 packets for the high priority queue, 40 for medium, 60 for normal, and 80 for low.
The no priority-list command with the appropriate keywords and arguments restores these defaults.
Use the priority-group interface subcommand to assign the specified priority list to an interface.
priority-group listThe argument list is the priority list number assigned to the interface. Multiple lists can be assigned per interface. The no version of this command removes a specific priority-group assignment if it includes a list argument. It removes all priority-group assignments if specified without the list argument.
This example causes packets exiting synchronous interface serial 0 to be classified by priority list 1.For an asynchronous interface, the first line of the configuration would be interface async 0.
interface serial 0 priority-group 1
When priority queuing is enabled on an interface, the EXEC command show interfaces displays information about the input and output queues. This information is a triplet of numbers: the first is the number of packets currently in the queue, the second is the maximum number of packets permitted in the queue, and the third is the number of packets discarded because the queue is full.
Input queue: 0/75/4 (size/max/drops); Total output drops: 0 Output queue: high 0/20/0, medium 0/40/00, normal 0/60/0, low 0/80/0
The total output drops number is the sum of the discarded numbers from the output queues, plus the count of packets discarded before being prioritized, or because of fast-switching activity.
Each network interface in a network server has a hold-queue limit. This limit is the number of data packets that the interface can store in its hold queue before rejecting new packets. When the interface empties one or more packets from the hold queue, the interface can accept new packets again.
To specify the hold-queue limit of an interface, use the hold-queue interface subcommand. Its full syntax is as follows:
hold-queue length {in|out}The argument length is the maximum number of packets in the queue. The in keyword specifies the input queue; the out keyword specifies the output queue.
The input hold queue prevents a single interface from flooding the network server with too many input packets. Further input packets are discarded if the interface has too many input packets outstanding in the system. The default input hold queue is 75 packets. The default output hold-queue limit is 40 packets. This limit prevents a malfunctioning interface from consuming an excessive amount of memory.
The no hold-queue command with the appropriate keyword restores the default values for an interface. There is no fixed upper limit to a queue size.
If priority output queueing is being used, the length of the four output queues is set using the priority-list global configuration command. The hold-queue command cannot be used to set an output hold queue length in this situation.
For slow links, use a small output hold-queue limit. This approach prevents storing packets at a rate that exceeds the transmission capability of the link. For fast links, use a large output hold-queue limit. A fast link may be busy for a short time (and thus require the hold queue), but can empty the output hold queue quickly when capacity returns.
To display the current hold queue setting and the number of packets discarded because of hold queue overflows, use the EXEC command show interfaces.
Higher-level protocols use bandwidth information to make operating decisions. For example, IGRP uses the minimum path bandwidth to determine a routing metric. The TCP protocol adjusts initial retransmission parameters based on the apparent bandwidth of the outgoing interface.
To set a bandwidth value for an interface, use the bandwidth interface subcommand. Its full syntax follows:
bandwidth kilobitsThe argument kilobits specifies the intended bandwidth in kilobits per second. For a full bandwidth DS3, enter the value 44736. Default bandwidth values are set during startup and can be displayed with the EXEC command show interfaces.
The bandwidth subcommand sets an informational parameter only; you cannot adjust the actual bandwidth of an interface with this subcommand. For some media, such as Ethernet, the bandwidth is fixed; for other media, such as serial lines, you can change the actual bandwidth by adjusting hardware. For both classes of media, you can use the bandwidth subcommand to communicate the current bandwidth to the higher-level protocols.
Use the no bandwidth command to restore the default values.
Higher-level protocols may use delay information to make operating decisions. For example, IGRP can use delay information to differentiate between a satellite link and a land link.
To set a delay value for an interface, use the delay interface subcommand. The full syntax of this command follows.
delay tens-of-microsecondsThe argument tens-of-microseconds specifies the delay for an interface or network segment in tens of microseconds. Default delay values may be displayed with the EXEC command show interfaces. The no delay command restores the default.
Each interface has a default maximum packet size or maximum transmission unit (MTU) size. This number generally defaults to the largest size possible for that type interface. On serial interfaces, the MTU size varies, but cannot be set smaller than 64 bytes. You can adjust the MTU using the mtu interface subcommand:
mtu bytesThe arguments bytes is the desired size in bytes. The no mtu command restores this value to its original default value. Table 1-4 lists default MTU values according to media type.
| Media Type | Default MTU |
|---|---|
| Ethernet | 1500 |
| Serial | 1500 |
The following is an example of specifying the MTU on serial port to 300 bytes:
interface serial 1 mtu 1000
You can use a loopback test on lines to detect and distinguish equipment malfunctions between line and modem or CSU/DSU (Channel Service Unit/Digital Service Unit) problems on the network server. If correct data transmission is not possible when an interface is in loopback mode, the interface is the source of the problem. The DSU may have similar loopback functions you can use to isolate the problem, if the interface loopback test passes. If the device does not support local loopback, then this function will have no effect.
You can specify hardware loopback tests on the Ethernet and synchronous serial interfaces, and all Token Ring interfaces except the CSC-R 4 megabit card that are attached to
CSU/DSUs, and that support the local loopback signal. The CSU/DSU acts as a DCE device; the communication server acts as a DTE device. The local loopback test generates a CSU loop--a signal that goes through the CSU/DSU to the line, then back through the CSU/DSU to the communication server.
The ping command can also be useful during loopback operation; it is described in the section on "Testing Connectivity with the Ping Command" in the "System Management" chapter.
The following sections describe the various loopback tests available for the supported interfaces.
The MCI serial interface card supports the loopback function when a CSU/DSU or equivalent device is attached to the communication server. Use the loopback command to enable loopback on the interface. The full syntax of this command follows:
loopbackThe loopback interface subcommand loops the packets through the CSU/DSU to configure a CSU loop, when the device supports this feature. The no loopback command disables the function.
Cisco-designed Ethernet interfaces can also be placed into loopback mode. During loopback operation, the interface receives back every packet it sends. Loopback operation has the additional effect of disconnecting network server functionality from the network. Use these commands to enable or disable the loopback test:
loopbackAll of Cisco's Token Ring interface cards (except the four megabit CSC-R card) may also be placed into loopback mode. During loopback operation, the interface receives back every packet it sends. Loopback operation has the additional effect of "disconnecting" network server functionality from the network. Use these commands to enable or disable loopback on the interface:
loopbackThe communication server provides an Ethernet loopback server that supports Xerox, Intel, and DEC systems specified by the "blue book," a joint specification written by Xerox, Digital Equipment Corporation, and Intel that defines the Ethernet protocol. The loopback server responds to forward data loopback messages sent either to the server's MAC address, or to the broadcast address. Currently, the Ethernet loopback server does not respond to the loopback assistance multicast address.
Use the Ethernet loopback server to test communications between Cisco internetworking products and DEC systems that do not support the IP ping command, such as DECnet-only VMS systems.
To originate a loop test on your VMS system with a Cisco server, use the DEC Network Control Program (NCP) command Loop Circuit. For more information about the Loop Circuit command, consult the DECnet VAX documentation. Cisco network servers support all options that can be specified by the VMS hosts.
This section provides an alphabetical list of all the interface commands described in this chapter.
Sets a bandwidth value for an interface. The argument kilobits specifies the intended bandwidth in kilobits per second. Default bandwidth values are set during startup and can be displayed with the EXEC command show interfaces. The no form of the command restores the default.
Configures the clock rate on the serial interface of the MCI card to an acceptable bit rate. The argument speed is the desired clock rate in bits per second. The no form removes the command from the configuration.
[no] delay tens-of-microseconds
Sets a delay value for an interface. The argument tens-of-microseconds specifies the delay for an interface or network segment in tens of microseconds. Default delay values may be displayed with the EXEC command show interfaces. The no form of the command restores the default. The delay subcommand sets an informational parameter only; you cannot adjust the actual delay of an interface with this subcommand.
[no] hold-queue length {in|out}
Specifies the hold-queue limit of an interface. The argument length is the maximum number of packets in the queue. The in keyword specifies the input queue; the out keyword specifies the output queue. Use the no hold-queue command to restore the default values for an interface. There is no fixed upper limit to a queue size.
On MCI serial card--Loops the packets through the CSU/DSU to configure a "CSU loop," when the device supports this feature. This is similar to the loopback line command on the HSSI.
On MCI and MEC Ethernet cards--Loops the packets at the interface within the communication server.
On the CSC-R16 card--Loops the packets at the interface within the communication server.
The no form of the command disables the loopback test.
Adjusts the maximum transmission unit (MTU). The arguments bytes is the desired size in bytes. The no mtu subcommand restores this value to its original default value.
Assign the specified priority list to an interface. The argument list is the priority list number assigned to the interface. Multiple lists can be assigned per interface. The no version of this command removes a specific priority-group assignment if it includes a list argument. It removes all priority-group assignments if specified without the list argument.
[no] priority-list list default queue-keyword
Assigns a priority queue for those packets that did not match any other rule in the priority list. If no default or the no form of the command is specified, the normal queue is assumed.
[no] priority-list list interface interface-name queue-keyword
Sets up priority queuing on the specified interface. The keyword interface applies to the priority queuing mechanism to an interface. The argument interface-name specifies the name of the interface. The arguments list and queue-keyword are described in the section"Assigning Priority by Interface Type" The no form of the command removes the item from the list.
[no] priority-list list protocol protocol-name queue-keyword [args]
Sets up priority queuing on the specified interface. The keyword protocol applies to the priority queuing mechanism to a protocol. The argument protocol-name specifies the name of the protocol. The arguments list, queue-keyword, and the optional args are described in the section "Assigning Priority by Protocol Type" earlier in this chapter. The no form of the command removes the item from the list.
[no] priority-list list queue-limit high-limit medium-limit normal-limit low-limit
Specifies the maximum number of packets that might be waiting in each of the priority queues. If a priority queue overflows, excess packets are discarded and quench messages might be sent, if appropriate, for the protocol. The no form of the command resets all four queue sizes to their default values as follows: high-limit = 20; medium-limit = 40; normal-limit = 60; low-limit = 80.
Enables pulsing DTR signals on the MCI serial interface for a minimum interval of seconds.
[no] scheduler-interval milliseconds
Controls the maximum amount of time that may elapse without running the lowest priority system processes. The minimum interval that may be specified is 500 milli-seconds; there is no maximum value. The default is to allow high priority operations to use as much of the central processor as needed. The no scheduler-interval command restores that default.
[no] transmitter-delay microseconds
Specifies a minimum dead-time after transmitting a packet. The argument microseconds specifies the approximate number of microseconds of minimum delay after transmitting a packet. This command is used for MCI serial card only. The no form of the command restores the default value of zero microseconds.
|
|