|
|
This chapter describes how to configure a modem and set up advanced asynchronous features, such as asynchronous dynamic routing and chat scripts. These tasks are presented in the following main sections:
For a complete description of the modem support commands in this chapter, see the Cisco IOS Dial Services Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Perform the following tasks to configure modem support for high-end access servers, such as the Cisco AS5800, AS5300, and AS5200. The first task is required; the second task is optional but recommended.
You must configure the modem lines and set the country code to enable asynchronous connections into your access server.
To configure the modems and line, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | modem country mica country or modem country microcom_hdms country | Depending on the type of modems loaded in your access server, specifies the modem vendor and country code.1 This step is only for high-end access servers, such as the CiscoAS5300. |
Step 2 | line line-number ending-line-number | Enters the number of modem lines to configure. Usually this range is equal to the number of modems in the access server.2 |
Step 3 | transport {input | output} all
| Allows all protocols to be used when connecting to the line. For outgoing calls, choose the output option. For incoming calls, use input. |
Step 4 | autoselect {arap | ppp | slip}
| Configures the line to automatically startup an AppleTalk Remote Access (ARA), Point-to-Point Protocol (PPP), or Serial Line Internet Protocol (SLIP) session. |
Step 5 | autoselect during login | Configures the lines to autodetect the connection-oriented protocol and display the username:password prompt upon login. |
Step 6 | login authentication dialin | Enables authentication across all asynchronous modem logins. |
Step 7 | modem dialin | Enables incoming calls.3 |
Step 8 | exit | Returns to global configuration mode. |
To verify your modem configuration, enter the show line command to display a summary for all the lines:
NAS# show line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
* 0 CTY - - - - - 0 0 0/0
I 1 TTY 115200/115200 - inout - - - 0 0 0/0
I 2 TTY 115200/115200 - inout - - - 0 0 0/0
3 TTY 115200/115200 - inout - - - 0 0 0/0
4 TTY 115200/115200 - inout - - - 0 0 0/0
5 TTY 115200/115200 - inout - - - 0 0 0/0
6 TTY 115200/115200 - inout - - - 0 0 0/0
7 TTY 115200/115200 - inout - - - 0 0 0/0
8 TTY 115200/115200 - inout - - - 0 0 0/0
9 TTY 115200/115200 - inout - - - 0 0 0/0
10 TTY 115200/115200 - inout - - - 0 0 0/0
.
.
.
90 VTY - - - - - 0 0 0/0
NAS# show line 1
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
I 1 TTY 115200/115200 - inout - - - 0 0 0/0
Line 1, Location: "", Type: ""
Length: 24 lines, Width: 80 columns
Baud rate (TX/RX) is 115200/115200, no parity, 1 stopbits, 8 databits
Status: none
Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
Modem Callout, Modem RI is CD, Line usable as async interface
Modem state: Idle
Special Chars: Escape Hold Stop Start Disconnect Activation
^^x none - - none
Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch
00:10:00 never none not set
Idle Session Disconnect Warning
never
Modem type is unknown.
Session limit is not set.
Time since activation: never
Editing is enabled.
History is enabled, history size is 10.
DNS resolution in show commands is enabled
Full user help is disabled
Allowed transports are pad telnet rlogin. Preferred is telnet.
No output characters are padded
No special data dispatching characters
modem(slot/port)=1/0, csm_state(0x00000100)=CSM_IDLE_STATE, bchan_num=-1
modem_status(0x0000): VDEV_STATUS_UNLOCKED
Modem hardware state: CTS noDSR DTR RTS
Depending upon the problems you experience, take the appropriate action:
NAS# debug modem NAS# debug modem csm NAS# debug isdn q931 NAS# no debug modem NAS# no debug modem csm NAS# no debug isdn q931
NAS# debug modem ? b2b Modem Special B2B csm CSM activity maintenance Modem maintenance activity mica MICA Async driver debugging oob Modem out of band activity tdm B2B Modem/PRI TDM trace Call Trace Upload
You need to test the dial-in connection when the access server and modem are configured correctly for dial-in access, before configuring any additional protocols for the line such as SLIP, PPP, or ARA.
 |
Note The same configuration issues exist between the client DTE and client modem. Make sure you have the correct EIA/TIA-232 cabling and modem initialization string for your client modem. |
The following is an example of a successful connection from a PC using a US Robotics Courier modem to dial in to a Cisco 2500 series access server:
at&f&c1&d3&h1&r2&b1&m4&k1&w OK atdt9,5551234 CONNECT 14400/ARQ/V32/LAPM/V42BIS User Access Verification Username: janedoe Password: router>
The following sections describe configuring modem line characteristics and modem features and tasks. Perform the configuration tasks, as required, for your particular modem and network.
The EIA/TIA-232 output signals are Transmit Data (TXDATA), Data Terminal Ready (DTR), and Ready To Send (RTS—Cisco 2500 routers only). The input signals are Receive Data (RXDATA), Clear to Send (CTS), and RING. The sixth signal is ground. Depending on the type of modem control your modem uses, these names may or may not correspond to the standard EIA/TIA-232 signals.
Dialup modems that operate over normal telephone lines at speeds of 28800 bps use hardware flow control to stop the data from reaching the host by toggling an EIA/TIA-232 signal when their limit is reached.
In addition to hardware flow control, modems require special software configuring. For example, they must be configured to create an EXEC session when a user dials in and to hang up when the user exits the EXEC. These modems also must be configured to close any existing network connections if the telephone line hangs up in the middle of a session.
The Cisco IOS software supports hardware flow control on its CTS input signal, which is also used by the normal modem handshake.
Signal and line state diagrams accompany some of the tasks in the following sections to illustrate how the modem control works. The diagrams show two processes:
In the diagrams, the current signal state and the signal the line is watching are listed inside each box. The state of the line (as displayed by the show line EXEC command) is listed next to the box. Events that change that state appear in italics along the event path, and actions that the software performs are described within ovals.
Figure 17 illustrates line states when no modem control is set. The DTR output is always high, and CTS and RING are completely ignored. The Cisco IOS software starts an EXEC session when the user types the activation character. Incoming TCP connections occur instantly if the line is not in use and can be closed only by the remote host.
With the dialup capability, you can set a modem to dial the phone number of a remote router automatically. This feature offers cost savings because phone line connections are made only when they are needed—you only pay for using the phone line when there is data to be received or sent. To configure a line for automatic dialing, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
modem dtr-active | Configures a line to initiate automatic dialing. |
Using the modem dtr-active command causes a line to raise DTR signal only when there is an outgoing connection (such as reverse Telnet, NetWare Asynchronous Support Interface (NASI), or DDR), rather than leave DTR raised all the time. When raised, DTR potentially tells the modem that the router is ready to accept a call.
You can configure a line to answer a modem automatically. You also can configure the modem to answer the telephone on its own (as long as DTR is high), drop connections when DTR is low, and use its Carrier Detect (CD) signal to accurately reflect the presence of carrier. (Configuring the modem is a modem-dependent process.) First, wire the modem CD signal (generally pin-8) to the router RING input (pin-22), then use the following command in line configuration mode:
| Command | Purpose |
|---|---|
modem dialin | Configures a line to automatically answer a modem. |
You can turn on modem hardware flow control independently to respond to the status of router CTS input. Wire CTS to whatever signal the modem uses for hardware flow control. If the modem expects to control hardware flow in both directions, you might also need to wire modem flow control input to some other signal that the router always has high, such as the DTR signal.
Figure 18 illustrates the modem dialin process with a high-speed dialup modem. When the Cisco IOS software detects a signal on the RING input of an idle line, it starts an EXEC or autobaud process on that line. If the RING signal disappears on an active line, the Cisco IOS software closes any open network connections and terminates the EXEC facility. If the user exits the EXEC or the software terminates because of no user input, the line makes the modem hang up by lowering the DTR signal for 5 seconds. After 5 seconds, the modem is ready to accept another call.
To configure a line for both incoming and outgoing calls, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
modem inout | Configures a line for both incoming and outgoing calls. |
Figure 19 illustrates the modem inout command. If the line is activated by raising the data set ready (DSR) signal, it functions exactly as a line configured with the modem dialin line configuration command described in the section "Automatically Answering a Modem" earlier in this chapter. If the line is activated by an incoming TCP connection, the line functions similarly to lines not used with modems.
|
Note If your system incorporates dial-out modems, consider using access lists to prevent unauthorized use. |
To change the interval that the Cisco IOS software waits for the CTS signal after raising the DTR signal in response to the DSR (the default is 15 seconds), use the following command in line configuration mode. The timeout applies to the modem callin command only.
| Command | Purpose |
|---|---|
modem answer-timeout seconds | Configures modem line timing. |
|
Note The DSR signal is called RING on older ASM-style chassis. |
To configure a line to close connections from a user's terminal when the terminal is turned off and prevent inbound connections to devices that are out of service, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
modem cts-required | Configures a line to close connections. |
Figure 20 illustrates the modem cts-required command operating in the context of a continuous CTS signal. This form of modem control requires that the CTS signal be high for the entire session. If CTS is not high, the user input is ignored and incoming connections are refused (or sent to the next line in a rotary group).
|
Note For the Cisco IOS software to reliably detect a CTS signal change, the CTS signal must remain in the new state for at least one full second. |
To configure automatic line disconnect, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
autohangup | Configures automatic line disconnect. |
The autohangup command causes the EXEC facility to issue the exit command when the last connection closes. This feature is useful for UNIX-to-UNIX copy program (UUCP) applications because UUCP scripts cannot issue a command to hang up the telephone. This feature is not often used.
The Cisco IOS software supports dial-in modems that use DTR to control the off-hook status of the telephone line. This feature is supported primarily on old-style modems, especially those in Europe. To configure the line to support this feature, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
modem callin | Configures a line for a dial-in modem. |
Figure 21 illustrates the modem callin command. When a modem dialing line is idle, it has its DTR signal at a low state and waits for a transition to occur on the DSR (RING) input. This transition causes the line to raise the DTR signal and start watching the CTS signal from the modem. After the modem raises CTS, the Cisco IOS software creates an EXEC session on the line. If the timeout interval (set with the modem answer-timeout command) passes before the modem raises the CTS signal, the line lowers the DTR signal and returns to the idle state.
|
Note The modem callin and modem cts-required line configuration commands are useful for SLIP operation. These commands ensure that when the line is hung up or the CTS signal drops, the line reverts from SLIP mode to normal interactive mode. These commands do not work if you put the line in network mode permanently. |
Although you can use the modem callin line configuration command with newer modems, the modem dialin line configuration command described in this section is more appropriate. The modem dialin command frees up CTS input for hardware flow control. Modern modems do not require the assertion of DTR to answer a phone line (that is, to take the line off-hook).
In addition to initiating connections, the Cisco IOS software can receive incoming connections. This capability allows you to attach serial and parallel printers, modems, and other shared peripherals to the router or access server and drive them remotely from other modem-connected systems. The Cisco IOS software supports reverse TCP, XRemote, and local-area transport (LAT) connections.
The specific TCP port or socket to which you attach the device determines the type of service that the Cisco IOS software provides on a line. When you attach the serial lines of a computer system or a data terminal switch to the serial lines of the access server, the access server can act as a network front-end device for a host that does not support the TCP/IP protocols. This arrangement is sometimes called front-ending, or reverse connection mode.
The Cisco IOS software supports ports connected to computers that are connected to modems. To configure the Cisco IOS software to function somewhat like a modem, use the following command in line configuration mode. This command also prevents incoming calls.
| Command | Purpose |
|---|---|
modem callout | Configures a line for reverse connections and prevents incoming calls. |
Figure 22 illustrates the modem callout process. When the Cisco IOS software receives an incoming connection, it raises the DTR signal and waits to see if the CTS signal is raised to indicate that the host has noticed the router DTR signal. If the host does not respond within the interval set by the modem answer-timeout line configuration command, the software lowers the DTR signal and drops the connection.
To configure Cisco IOS software to respond to BOOTP requests from client machines, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
async-bootp tag [:hostname] data | Specifies the router network information that is sent in response to BOOTP requests. |
To specify the mode of a low-speed serial interface as either synchronous or asynchronous, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
physical-layer {sync | async} | Specifies the mode of a low-speed interface as either synchronous or asynchronous. |
This command applies only to low-speed serial interfaces available on Cisco 2520 through Cisco 2523 routers.
In synchronous mode, low-speed serial interfaces support all interface configuration commands available for high-speed serial interfaces, except the following two commands:
When placed in asynchronous mode, low-speed serial interfaces support all commands available for standard asynchronous interfaces. The default is synchronous mode.
Note that when you enter this command, it does not appear in the output of the more system:running-config and more nvram:startup-config commands, because the command is a physical-layer command.
When asynchronous routing is enabled, you might need to conserve network addresses by configuring the asynchronous interfaces as unnumbered. An unnumbered interface does not have an address. Network resources are therefore conserved because fewer network numbers are used and routing tables are smaller.
To configure an unnumbered interface, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ip unnumbered type number | Conserves IP addresses by configuring the asynchronous interfaces as unnumbered, and assigns the IP address of the interface type that you want to leverage. |
Whenever the unnumbered interface generates a packet (for example, a routing update), it uses the address of the specified interface as the source address of the IP packet. It also uses the address of the specified interface to determine which routing processes are sending updates over the unnumbered interface.
You can use the IP unnumbered feature even if the system on the other end of the asynchronous link does not support it. The IP unnumbered feature is transparent to the other end of the link because each system bases its routing activities on information in the routing updates it receives and on its own interface address.
You can control whether addressing is dynamic (the user specifies the address at the EXEC level when making the connection) or whether default addressing is used (the address is forced by the system). If you specify dynamic addressing, the router must be in interactive mode and the user will enter the address at the EXEC level.
It is common to configure an asynchronous interface to have a default address and to allow dynamic addressing. With this configuration, the choice between the default address or a dynamic addressing is made by the users when they enter the slip or ppp EXEC command. If the user enters an address, it is used, and if the user enters the default keyword, the default address is used.
This section describes the following optional tasks:
To assign a permanent default asynchronous address, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
peer default ip address ip-address | Assigns a default IP address to an asynchronous interface. |
Use the no form of this command to disable the default address. If the server has been configured to authenticate asynchronous connections, you are prompted for a password after you enter the slip default or ppp default EXEC command before the line is placed into asynchronous mode.
The assigned default address is implemented when the user enters the slip default or ppp default EXEC command. The transaction is validated by the TACACS server, when enabled, and the line is put into network mode using the address that is in the configuration file.
Configuring a default address is useful when the user is not required to know the IP address to gain access to a system (for example, users of a server that is available to many students on a campus). Instead of each user being required to know an IP address, they only need to enter the slip default or ppp default EXEC command and let the server select the address to use. See the section "Making Additional Remote Node Connections" in the chapter "Configuring Asynchronous SLIP and PPP" in this publication for more information about the slip and ppp EXEC commands.
When a line is configured for dynamic assignment of asynchronous addresses, the user enters the slip or ppp EXEC command and is prompted for an address or logical host name. The address is validated by TACACS, when enabled, and the line is assigned the given address and put into asynchronous mode. Assigning asynchronous addresses dynamically is also useful when you want to assign set addresses to users. For example, an application on a personal computer that automatically dials in using SLIP and polls for electronic mail messages can be set up to dial in periodically and enter the required IP address and password.
To assign asynchronous addresses dynamically, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
async dynamic address | Allows the IP address to be assigned when the protocol is initiated. |
The dynamic addressing features of the internetwork allow packets to get to their destination and back regardless of the access server, router, or network they are sent from. For example, if a host such as a laptop computer moves from place to place, it can keep the same address no matter where it is dialing in from.
Logical host names are first converted to uppercase and then sent to the TACACS server for authentication.
You can configure one or more asynchronous interfaces on your access server (and one on a router) to be in dedicated network interface mode. In dedicated mode, an interface is automatically configured for SLIP or PPP connections. There is no user prompt or EXEC level, and no end-user commands are required to initiate remote-node connections. If you want a line to be used only for SLIP or PPP connections, configure the line for dedicated mode.
In interactive mode, a line can be used to make any type of connection, depending on the EXEC command entered by the user. For example, depending on its configuration, the line could be used for Telnet or XRemote connections, or SLIP or PPP encapsulation. The user is prompted for an EXEC command before a connection is initiated.
You can configure an asynchronous interface to be in dedicated network mode. When the interface is configured for dedicated mode, the end user cannot change the encapsulation method, address, or other parameters.
To configure an interface for dedicated network mode or return it to interactive mode, use one of the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
async mode dedicated | Places the line into dedicated asynchronous network mode. |
async mode interactive | Returns the line to interactive mode. |
By default, no asynchronous mode is configured. In this state, the line is not available for inbound networking because the SLIP and PPP connections are disabled.
To route IP packets on an asynchronous interface, use one of the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
async dynamic routing | Configures an asynchronous interface for dynamic routing. Use this command to manually bring up PPP from an EXEC session. |
async default routing | Automatically configures an asynchronous interface for routing. Use this command to enable two routers to communicate over an asynchronous dial backup link. |
This async dynamic routing command routes IP packets on an asynchronous interface, which permits you to enable the Interior Gateway Routing Protocol (IGRP), Routing Information Protocol (RIP), and Open Shortest Path First (OSPF) routing protocols for use when the user makes a connection using the ppp or slip EXEC commands. The user must, however, specify the /routing keyword at the SLIP or PPP command line.
For asynchronous interfaces in interactive mode, the async default routing command causes the ppp and slip EXEC commands to be interpreted as though the /route switch had been included in the command. For asynchronous interfaces in dedicated mode, the async dynamic routing command enables routing protocols to be used on the line. Without the async default routing command, there is no way to enable the use of routing protocols automatically on a dedicated asynchronous interface.
By default, the Cisco IOS software starts an EXEC process on all lines. However, you can control EXEC processes, as follows:
The EXEC command interpreter waits for a specified amount of time to receive user input. If no input is detected, the EXEC facility resumes the current connection. If no connections exist, it returns the terminal to the idle state and disconnects the incoming connection. To control the EXEC process, use the following commands in line configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | exec | Turns on EXEC processes. |
Step 2 | exec-timeout minutes [seconds] | Sets the idle terminal timeout interval. |
The AUX port sends a DTR signal only when a Telnet connection is established. The auxiliary port does not use RTS/CTS handshaking for flow control. To understand the differences between standard asynchronous interfaces and AUX ports configured as an asynchronous interface, refer to Table 5. To enable the auxiliary port, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
line aux line-number | Enables the auxiliary serial DTE port. |
You cannot use the auxiliary (AUX) port as a second console port. To use the AUX port as a console port, you must order a special cable from your technical support personnel.
On an access server, you can configure any of the available asynchronous interfaces (1 through 8, 16, or 48). The auxiliary port (labeled AUX on the back of the product) can also be configured as an asynchronous serial interface, although performance on the AUX port is much slower than on standard asynchronous interfaces and the port does not support some features. Table 5 illustrates why asynchronous interfaces permit substantially better performance than AUX ports configured as asynchronous interfaces.
| Feature | Asynchronous Interface | Auxiliary Port |
|---|---|---|
Maximum speed | 115200 kbps | 38400 kbps |
Supports DMA buffering1 | Yes | No |
PPP framing on chip2 | Yes | No |
IP fast switching3 | Yes | No |
On routers without built-in asynchronous interfaces, only the AUX port can be configured as an asynchronous serial interface. To configure the AUX port as an asynchronous interface, you must also configure it as an auxiliary line with the line aux 1 command. Access servers do not have this restriction. Use the line command with the appropriate line configuration commands for modem control, such as speed.
Only IP packets can be sent across lines configured for SLIP. PPP supports transmission of IP, Internet Protocol Routing Exchange (IPX), and AppleTalk packets on an asynchronous serial interface.
Autoselect is used by the access server to sense the protocol being received on an incoming line and launch the appropriate protocol. Autoselect can be used for ARA, PPP, or SLIP.
When using Autoselect, "login" authentication is by-passed, so if security is required it must be performed at the protocol level, that is, ARAP or PPP authentication. SLIP does not offer protocol layer authentication.
To configure the Cisco IOS software to allow an ARA, PPP, or SLIP session to start automatically, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
autoselect {arap | ppp | slip | during login} | Configures a line to automatically start an ARA, PPP, or SLIP session. |
The autoselect command enables the Cisco IOS software to start a process automatically when a start character is received.
The autoselect command bypasses the login prompt and enables the specified session to begin automatically. However, when the autoselect command is entered with the during login keyword, the username or password prompt appears without the need to press the Return key, thus "login" users will get a prompt right away instead without needing to press the Return key. While the username or password prompt is displayed, you can choose either to answer these prompts or to send packets from an autoselected protocol.
Normally a router avoids line and modem noise by clearing the initial data received within the first one or two seconds. However, when the autoselect PPP feature is configured, the router flushes characters initially received and then waits for more traffic. This flush causes timeout problems with applications that send only one carriage return. To ensure that the input data sent by a modem or other asynchronous device is not lost after line activation, enter the flush-at-activation line configuration command.
|
Note When the autoselect command is used, the activation character should be set to the default Return, and exec-character-bits to 7. If you change these defaults, the application cannot recognize the activation request. |
The following trace appears when the debug modem command and debug ppp negotiation command are enabled. As PPP calls pass through the access server, you should see this output.
When autoselect is used, "login" authentication is bypassed. If security is required it must be performed at the protocol level (that is, ARAP or PPP authentication). SLIP does not offer protocol layer authentication.
22:21:02: TTY1: DSR came up 22:21:02: tty1: Modem: IDLE->READY 22:21:02: TTY1: Autoselect started 22:21:05: TTY1: Autoselect sample 7E 22:21:05: TTY1: Autoselect sample 7EFF 22:21:05: TTY1: Autoselect sample 7EFF7D 22:21:05: TTY1 Autoselect cmd: ppp default 22:21:05: TTY1: EXEC creation %LINK-3-UPDOWN: Interface Async1, changed state to up 22:21:07: ppp: sending CONFREQ, type = 2 (CI_ASYNCMAP), value = A0000 22:21:07: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 23BE13AA 22:21:08: PPP Async1: state = REQSENT fsm_rconfack(0xC021): rcvd id 0x11 22:21:08: ppp: config ACK received, type = 2 (CI_ASYNCMAP), value = A0000 22:21:08: ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 23BE13AA 22:21:08: ppp: config ACK received, type = 7 (CI_PCOMPRESSION) 22:21:08: ppp: config ACK received, type = 8 (CI_ACCOMPRESSION) 22:21:08: PPP Async1: received config for type = 0x2 (ASYNCMAP) value = 0x0 acked 22:21:08: PPP Async1: received config for type = 0x5 (MAGICNUMBER) value = 0x2A acked 22:21:08: PPP Async1: received config for type = 0x7 (PCOMPRESSION) acked 22:21:08: PPP Async1: received config for type = 0x8 (ACCOMPRESSION) acked 22:21:08: ipcp: sending CONFREQ, type = 3 (CI_ADDRESS), Address = 172.16.1.1 22:21:08: ppp Async1: ipcp_reqci: rcvd COMPRESSTYPE (rejected) (REJ) 22:21:08: ppp Async1: Negotiate IP address: her address 0.0.0.0 (NAK with address 172.16.1.100) (NAK) 22:21:08: ppp: ipcp_reqci: returning CONFREJ. 22:21:08: PPP Async1: state = REQSENT fsm_rconfack(0x8021): rcvd id 0x9 22:21:08: ipcp: config ACK received, type = 3 (CI_ADDRESS), Address = 172.16.1.1 22:21:08: ppp Async1: Negotiate IP address: her address 0.0.0.0 (NAK with address 172.16.1.100) (NAK) 22:21:08: ppp: ipcp_reqci: returning CONFNAK. 22:21:09: ppp Async1: Negotiate IP address: her address 172.16.1.100 (ACK) 22:21:09: ppp: ipcp_reqci: returning CONFACK. %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up
The following trace appears when the debug modem command and debug arap internal command are enabled. As ARA version 2.0 calls pass through the access server, this output is displayed.
20:45:11: TTY3: DSR came up 20:45:11: tty3: Modem: IDLE->READY 20:45:11: TTY3: EXEC creation 20:45:11: TTY3: Autoselect(2) sample 1 20:45:11: TTY3: Autoselect(2) sample 11B 20:45:12: TTY3: Autoselect(2) sample 11B02 20:45:18: ARAP: ---------- SRVRVERSION ---------- 20:45:19: ARAP: ---------- ACKing 0 ---------- 20:45:19: ARAP: ---------- AUTH_CHALLENGE ---------- 20:45:21: ARAP: ---------- ACKing 1 ---------- 20:45:21: ARAP: ---------- AUTH_RESPONSE ---------- 20:45:21: ARAP: ---------- STARTINFOFROMSERVER ---------- 20:45:22: ARAP: ---------- ACKing 2 ---------- 22:45:22: ARAP: ---------- ZONELISTINFO ---------- 22:45:22: ARAP: ---------- ZONELISTINFO ---------- 22:45:22: ARAP: ---------- ZONELISTINFO ----------
The following trace is for ARA version 1.0 calls:
22:31:45: TTY1: DSR came up 22:31:45: tty1: Modem: IDLE->READY 22:31:45: TTY1: Autoselect started 22:31:46: TTY1: Autoselect sample 16 22:31:46: TTY1: Autoselect sample 1610 22:31:46: TTY1: Autoselect sample 161002 22:31:47: ARAP: ---------- SRVRVERSION ---------- 22:31:47: ARAP: ---------- ACKing 0 ---------- 22:31:47: ARAP: ---------- AUTH_CHALLENGE ---------- 22:31:47: ARAP: ---------- ACKing 1 ---------- 22:31:47: ARAP: ---------- AUTH_RESPONSE ---------- 22:31:47: ARAP: ---------- STARTINFOFROMSERVER ---------- 22:31:48: ARAP: ---------- ACKing 2 ---------- 22:31:48: ARAP: ---------- ZONELISTINFO ---------- 22:31:48: ARAP: ---------- ZONELISTINFO ---------- 22:31:49: ARAP: ---------- ZONELISTINFO ----------
You can set up a command to execute automatically when the router connects to another host. The Cisco IOS software can execute any appropriate EXEC command and any switch or host name that occurs with the EXEC command. To define a command, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
autocommand command | Defines a command to be automatically executed. |
Connections can be made to the next free line in a group of lines, also called a rotary group or hunt group. A line can be in only one rotary group; a rotary group can consist of a single line or several contiguous lines. The console line (line 0) cannot be in a rotary group.
To configure a rotary group, use the following command in line configuration mode:
| Command | Purpose |
|---|---|
rotary group | Adds a line to the specified rotary group. |
Connections to an individual line are most useful when a dial-out modem, parallel printer, or serial printer is attached to that line. To connect to an individual line, the remote host or terminal must specify a particular TCP port on the router.
If reverse XRemote is required, that port is 9000 (decimal) plus the decimal value of the line number.
If a raw TCP stream is required, the port is 4000 (decimal) plus the decimal line number. The raw TCP stream is usually the required mode for sending data to a printer.
If Telnet protocols are required, that port is 2000 (decimal) plus the decimal value of the line number. The Telnet protocol might require that Return characters be translated into Return and line-feed character pairs. You can turn off this translation by specifying the Telnet binary mode option. To specify this option, connect to port 6000 (decimal) plus the decimal line number.
line 10 flowcontrol software no exec
A host that wants to send data to the printer would connect to the router on TCP port 4008, send the data, and then close the connection. (Remember that line number 10 octal equals 8 decimal.)
Asynchronous lines have relatively low bandwidth and can easily be overloaded, resulting in slow traffic across these lines.
To optimize available bandwidth, perform either of the following optional tasks:
One way to optimize available bandwidth is by using TCP header compression. Van Jacobson TCP header compression (defined by RFC 1144) can increase bandwidth availability two- to five-fold when compared to lines not using header compression. Theoretically, it can improve bandwidth availability by a ratio of seven to one.
To configure header compression, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ip tcp header-compression [on | off | passive] | Configures Van Jacobson TCP header compression on the asynchronous link. |
On SLIP interfaces, you can force header compression at the EXEC prompt on a line on which header compression has been set to passive. This option allows more efficient use of the available bandwidth and does not require entering privileged configuration mode.
To implement header compression, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ip tcp header-compression passive | Allows status of header compression to be assigned at the user level. |
For PPP interfaces, the passive option functions the same as the on option.
This section describes the following monitoring and maintenance tasks that you can perform on asynchronous interfaces:
To monitor and maintain asynchronous activity, use the following commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
clear line line-number | Returns a line to its idle state. |
show async bootp | Displays parameters that have been set for extended BOOTP requests. |
show async status | Displays statistics for asynchronous interface activity. |
show line [line-number] | Displays the status of asynchronous line connections. |
To debug asynchronous interfaces, use the following debug command in privileged EXEC mode:
| Command | Purpose |
|---|---|
debug async {framing | state | packets} | Displays errors, changes in interface state, and log input and output. |
To debug PPP links, use any of the following debug commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
debug ppp negotiation | Enables debugging of PPP protocol negotiation process. |
debug ppp error | Displays PPP protocol errors. |
debug ppp packet | Displays PPP packets sent and received. |
debug ppp chap | Displays errors encountered during remote or local system authentication. |
This section defines other settings that might be needed or desirable, depending on your modem.
See the next chapter in this publication, "Managing Modems," for more helpful information about managing modems.
AS5200# modem at-mode 1/1 You are now entering AT command mode on modem (slot 1 / port 1). Please type CTRL-C to exit AT command mode. at%v MNP Class 10 V.34/V.FC Modem Rev 1.0/85 OK at\s IDLE 000:00:00 LAST DIAL NET ADDR: FFFFFFFFFFFF MODEM HW: SA 2W United States 4 RTS 5 CTS 6 DSR - CD 20 DTR - RI MODULATION IDLE MODEM BPS 28800 AT%G0 MODEM FLOW OFF AT\G0 MODEM MODE AUT AT\N3 V.23 OPR. OFF AT%F0 AUTO ANS. ON ATS0=1 SERIAL BPS 115200 AT%U0 BPS ADJUST OFF AT\J0 SPT BPS ADJ. 0 AT\W0 ANSWER MESSGS ON ATQ0 SERIAL FLOW BHW AT\Q3 PASS XON/XOFF OFF AT\X0 PARITY 8N AT
The modem responds with "OK" when the AT command you send is successfully received.
Some of the Cisco lower-end access servers such as the Cisco AS2511-RJ shown in Figure 23, have cable connections to external modems. Notice that the modems and modem cables are outside the chassis. The asynchronous interfaces and lines are inside the access server.
When you configure modems to function with your access server, you must provide initialization strings and other settings on the modem to tell it how to function with the access server. Manually configuring a modem consists of the following tasks:
This section assumes you have already physically attached the modem to the access server. If not, refer to the user guide or installation and configuration guide for your access server for information about attaching modems.
You communicate with an external modem by establishing a direct Telnet session from the asynchronous line on the access server, which is connected to the modem.
|
Note This process is also referred to as reverse Telnet. Performing a reverse Telnet means that you are initiating a Telnet session out the asynchronous line, instead of accepting a connection into the line (called a forward connection). |
To establish a direct Telnet session to an external modem, determine the IP address of your LAN (Ethernet) interface, then enter a Telnet command to port 2000 + n on the access server, where n is the line number to which the modem is connected. For example, to connect to the modem attached to line 1, enter the following command from an EXEC session on the access server:
router# telnet 172.16.1.10 2001 Trying 172.16.1.10, 2001 ... Open
This example enables you to communicate with the modem on line 1 using the AT (attention) command set defined by the modem vendor.
After you make a direct Telnet connection to the modem, you need to test the connection. Send the modem the AT command to request its attention. It should respond with "OK." For example:
at OK
If the modem does not reply to the at command, perform the following tasks:
Step 2 Enter the show line EXEC command. The output should contain the following two lines:
Modem state: Idle Modem hardware state: CTS noDSR DTR RTS
If the output displays "no CTS" for the modem hardware state, the modem is not connected, or is not powered up, or is waiting for data, or the modem might not be configured for hardware flow control.
Step 3 Check whether the virtual terminal connections to lines in the access server require passwords.
Step 4 Verify the line speed and modem transmission rate. Make sure that the line speed on the access server matches the matches transmission rate, as shown in Table 6.
| Modem Transmission Rate (in bits per second) | Line Speed on the Access Server (in bits per second) |
|---|---|
9600 | 38400 |
14400 | 57600 |
28800 | 115200 |
To verify the line speed, use the show run EXEC command. The line configuration fragment appears at the tail end of the output.
The following example shows that lines 7 through 9 are transmitting at 115200 bits per second (bps). Sixteen 28800-kbps modems are connected to a Cisco AS2511-RJ access server via a modem cable. (Refer to Figure 23.)
as2511# show run Building configuration... Current configuration: . . . ! line 1 16 login local modem InOut speed 115200 transport input all flowcontrol hardware script callback callback autoselect ppp autoselect during-login !
Step 5 The speeds of the modem and the access server are likely to be different. If so, switch off the modem, then switch it back on. This action should change the speed of the modem to match the speed of the access server
Step 6 Check your cabling and the modem configuration (echo or result codes might be off). Enter the appropriate at modem command to view the modem configuration, or use the at&f command to return to factory defaults. Refer to your modem documentation to learn the appropriate at command to view your modem configuration.
When you are connected to an external modem, the direct Telnet session must be terminated before the line can accept incoming calls. If you do not terminate the session, it will be indicated in the output of the show users command when it returns a modem state of ready if the line is still in use. If the line is no longer in use, the output of the show line value command will return a state of idle. Terminating the Telnet session requires first suspending it, then disconnecting it.
To suspend and then disconnect a Telnet session, perform the following tasks:
- suspend keystroke - router#
|
Note Ensure that you can reliably issue the escape sequence to suspend a Telnet session. Some terminal emulation packages have difficulty sending the Ctrl-Shift-6 x sequence. Refer to your terminal emulation documentation for more information about escape sequences. |
Step 2 Enter the where EXEC command to check for open sessions:
router# where Conn Host Address Byte Idle Conn Name * 1 172.16.1.10 172.16.1.10 0 0 172.16.1.10 2 172.16.1.11 172.16.1.11 0 12 modem2
Step 3 When you have suspended a session with one modem, you can connect to another modem and suspend it:
router# telnet modem2 Trying modem2 (172.16.1.11, 2002) ... Open - suspend keystroke - router#
Step 4 To disconnect (completely close) a session, issue the disconnect EXEC command:
router# disconnect line 1 Closing connection to 172.16.1.10 [confirm] y router# disconnect line 2 Closing connection to 172.16.1.11 [confirm] y router#
|
Note Before attempting to allow inbound connections, make sure you close all open connections to the modems attached to the access server. If you have a modem port in use, the modem will not accept a call properly. |
The Cisco IOS software can issue initialization strings automatically for most types of modems externally attached to the access server. A modem initialization string is a series of parameter settings that are sent to your modem to configure it to interact with the access server in a specified way. The Cisco IOS software defines seven initialization strings that have been found to properly initialize most modems so that the modems function properly with Cisco access servers. These initialization strings have the following names:
|
Note Internal or integrated modems, such as used by the Cisco AS5300 access server, are preconfigured by Cisco and need not be initialized. |
If you do not know which of these modem strings is appropriate for your modems, enter the modem autoconfigure discovery line configuration command, as shown in the following example:
router# configure terminal router(config)# line 1 16 router(config-line)# modem autoconfigure discovery router(config-line)# Ctrl-Z router# copy system:running-config nvram:startup-config
The Cisco IOS software first tries the first of these strings to learn if the modem initializes properly. If not, the Cisco IOS software cycles to the next string and repeats the process until the appropriate string is found. If none of the strings properly initializes the modem, you must manually configure the modem (see the section "Manually Configuring an External Modem" later in this chapter).
If you know that your modem can be configured using an initialization string from one of these scripts, you can enter the modem autoconfigure type modem-name command, where modem-name is one of the strings in the preceding list. If you list a specific modem type, initialization proceeds more quickly.
Follow these steps to configure an external modem:
You can change a modem value that was returned from the show modemcap EXEC command. For example, you might want to add the factory default, &F, entry to the configuration file. To make a change, enter the modemcap edit modem-name attribute value line configuration command. Configure one attribute of one modem at a time.
The following example shows how to enter line configuration mode and enter the modem autoconfigure type modem-name command for a US Robotics Sportster modem:
router(config-line)# modem autoconfigure type usr_sportster
After the modem initialization string has been determined, perform the following tasks to configure the modem. The following tasks configure a US Robotics Courier modem on line 1 (decimal number 2000 + line number 1 = 2001).
Step 2 Map a host name to a decimal port. The port number is 200x, plus the number of the TTY line. The following example maps port 2001 to the IP address of the Ethernet0 interface on the access server (172.16.1.10):
router(config)# ip host modem1 2001 172.16.1.10 router(config)# exit router#
Step 3 Establish a direct Telnet session to the modem:
router# telnet modem1 Trying modem1 (172.16.1.10, 2001)... Open
Step 4 Return the modem to its factory defaults (this step is optional):
at&f OK
Step 5 Configure the modem with an initialization string. The following example string is for a US Robotics Courier modem:
at&b1&h1&r2&c1&d3&m4&k1s0=1 OK
Step 6 Store the modem settings in NVRAM on the modem:
at&w OK
|
Note Some modems need to be "strapped" so that they start up with saved settings when powered up, rather than using defaults. You should make sure your modem is strapped accordingly. |
Step 7 Suspend and disconnect your Telnet session:
- suspend keystroke - router# disconnect Closing connection to modem1 [confirm] y router#
 |
TimeSaver The script-reset line configuration command can automate the configuration of your modems. See the "Technical Tips" section on CCO for more information. |
If you cannot configure your modem automatically, you must configure it manually. This section describes how to determine and issue the correct initialization string for your modem and configure your modem with it.
Modem command sets vary widely. Although most modems use the Hayes command set (prefixing commands with at), Hayes-compatible modems do not use identical at command sets.
Refer to the documentation that came with your modem to learn how to examine the current and stored configuration of the modem you are using. Generally, you enter at commands such as &v, i4, or *o to view, inspect, or observe the settings.
|
Note You must first create a direct Telnet or connection session to the modem before you can send an initialization string. You can use AT&F as a basic modem initialization string in most cases. |
A sample modem initialization string for a US Robotics Courier modem is as follows:
&b1&h1&r2&c1&d3&m4&k1s0=1
Modem initialization strings enable the following functions:
|
TimeSaver Initialization strings for other modems are listed in the appendix "Configuring and Troubleshooting Modems" in the Cisco IOS Dial Services Command Reference publication. |
|
Note Make sure to turn off automatic baud rate detection because the modem speeds must be set to a fixed value. |
The port speed must not change when a session is negotiated with a remote modem. If the speed of the port on the access server is changed, you must establish a direct Telnet session to the modem and send an at command so that the modem can learn the new speed.
Modems differ in the method they use to lock the EIA/TIA-232 (serial) port speed. In the modem documentation, vendors use terms such as port-rate adjust, speed conversion, or buffered mode. Enabling error correction often puts the modem in the buffered mode. Refer to your modem documentation to learn how your modem locks speed (check the settings &b, \j, &q, \n, or s-register settings).
Chat scripts are strings of text used to send commands for modem dialing, logging in to remote systems, and initializing asynchronous devices connected to an asynchronous line. On a router, chat scripts can be configured on the auxiliary port only.
A chat script must be configured to dial out on asynchronous lines. You also can configure chat scripts so that they can be executed automatically for other specific events on a line, or so that they are executed manually.
Each chat script is defined for a different event. These events can include the following:
|
Note Outbound chat scripts are not supported on lines where modem control is set for inbound activity only (using the modem dialin command). |
The following tasks must be performed before a chat script can be used:
To configure a chat script, perform the tasks in the following sections:
See the section "Using Chat Scripts" later in this chapter for examples of how to use chat scripts.
When you create a script name, include the modem vendor, type, and modulation, separated by hyphens, as follows:
vendor-type-modulationFor example, if you have a Telebit t3000 modem that uses V.32bis modulation, your script name would be:
telebit-t3000-v32bis
We recommend that one chat script (a "modem" chat script) be written for placing a call and another chat script (a "system" or "login" chat script) be written to log in to remote systems, where required.
To define a chat script, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
chat-script script-name expect send... | Creates a script that will place a call on a modem, log in to a remote system, or initialize an asynchronous device on a line. |
The Cisco IOS waits for the string from the modem (defined by the expect portion of the script), and uses it to determine what to send back to the modem (defined by the send portion of the script).
Chat script send strings can include the special escape sequences listed in Table 7.
| Escape Sequence | Description |
|---|---|
" " | Expects a null string. |
EOT | Sends an end-of-transmission character. |
BREAK | Causes a BREAK. This sequence is sometimes simulated with line speed changes and null characters. May not work on all systems. |
\c | Suppresses new line at the end of the send string. |
\d | Delays for 2 seconds. |
\K | Inserts a BREAK. |
\n | Sends a newline or linefeed character. |
\p | Pauses for 0.25 second. |
\r | Sends a return. |
\s | Sends a space character. |
\t | Sends a table character. |
\\ | Sends a backslash (\) character. |
\T | Replaced by phone number. |
\q | Reserved, not yet used. |
Special case script modifiers are also supported; refer to Table 8 for examples.
| Special Case | Function |
|---|---|
ABORT string | Designates a string whose presence in the input indicates that the chat script has failed. (You can have as many active abort entries as you like.) |
TIMEOUT time | Sets the time to wait for input, in seconds. The default is |
For example, if a modem reports BUSY when the number dialed is busy, you can indicate that you want the attempt stopped at this point by including ABORT BUSY in your chat script.
|
Note If you use the expect-send pair ABORT SINK instead of ABORT ERROR, the system terminates abnormally when it encounters SINK instead of ERROR. |
After the connection is established and you press the Return key, you must often press Return a second time before the prompt appears. To create a chat script that enters this additional Return key for you, include the following as part of your chat script:
ssword:-/r-ssword
This part of the script specifies that, after the connection is established, you want ssword to be displayed. If it is not displayed, you must press Return again after the timeout passes. (See the appendix "Regular Expressions" in the Cisco IOS Terminal Services Command Reference publication for more information about expressing characters in chat scripts.)
Chat scripts can be activated by any of five events, each corresponding to a different version of the script line configuration command. To start a chat script manually at any point, see the following section, "Starting a Chat Script Manually on an Asynchronous Line."
To define a chat script to start automatically when a specific event occurs, use one of the following commands in line configuration mode:
| Command | Purpose |
|---|---|
script activation regexp1 | Starts a chat script on a line when the line is activated (every time a command EXEC is started on the line). |
script connection regexp | Starts a chat script on a line when a network connection is made to the line. |
script dialer regexp | Specifies a modem script for DDR on a line. |
script reset regexp | Starts a chat script on a line whenever the line is reset. |
script startup regexp | Starts a chat script on a line whenever the system is started up. |
| 1The regexp argument is a regular expression that is matched to a script name that has already been defined using the chat-script command. |
|
Note Outbound chat scripts are not supported on lines where modem control is set for inbound activity only (using the modem dialin command). |
To start a chat script manually on any line that is currently not active, use the following command in privileged EXEC mode:
| Command | Purpose |
|---|---|
start-chat regexp [line-number [dialer-string]] | Starts a chat script manually on any asynchronous line. |
If you do not specify the line number, the script runs on the current line. If the line specified is already in use, you cannot start the chat script. A message appears indicating that the line is already in use.
The following sections provide examples of how to write and use chat scripts:
The following example chat script includes a pair of empty quotation marks (" "), which means "expect anything," and \r, which means "send a return":
" " \r "name:" "myname" "ord":" "mypassword" ">" "slip default"
The following example shows a configuration in which, when there is traffic, a random line will be used. The dialer code will try to find a script that matches either the modem script .*-v32 or the system script cisco. If there is no match for either the modem script or the system script, you will see a "no matching chat script found" message.
interface dialer 1 ! v.32 rotaries are in rotary 1. dialer rotary-group 1 ! Use v.32 generic script. dialer map ip 1.0.0.1 modem-script .*-v32 system-script cisco 1234
The following example shows line chat scripts being specified for lines connected to Telebit and
US Robotics modems:
! Some lines have telebit modems. line 1 6 script dialer telebit.* ! Some lines have US robotics modems. line 7 12 script dialer usr.*
The following example shows a modem chat script called dial and a system login chat script called login:
chat-script dial ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30 CONNECT \c
chat-script login ABORT invalid TIMEOUT 15 name: myname word: mypassword ">"
"slip default"
interface async 10
dialer in-band
dialer map ip 10.55.0.1 modem-script dial system-script login 96837890
Figure 24 illustrates the configuration.
In the sample script shown, the dialer in-band command enables DDR on asynchronous interface 10, and the dialer map command dials 96837890 after finding the specified dialing and the system login scripts. When a packet is received for 10.55.0.1, the first thing to happen is that the modem script is implemented. Table 9 lists the functions that are implemented with each expect-send pair in the modem script called dial.
| Expect and Send Pair | Implementation |
|---|---|
ABORT ERROR | Ends the script execution if the text "ERROR" is found. (You can have as many active abort entries as you like.) |
" " "AT Z" | Without expecting anything, sends an "AT Z" command to the modem. (Note the use of quotation marks to allow a space in the send string.) |
OK "ATDT \T | Waits to see "OK." Sends "ATDT 96837890." |
TIMEOUT 30 | Waits up to 30 seconds for next expect string. |
CONNECT \c | Expects "connect," but does not send anything. (Note that \c is effectively nothing; " " would have indicated nothing followed by a carriage return.) |
After the modem script is successfully executed, the system login script is executed. Table 10 lists the functions that are executed with each expect-send pair in the system script called login.
| Expect and Send Pair | Implementation |
|---|---|
ABORT invalid | Ends the script execution if the message "invalid username or password" is displayed. |
TIMEOUT 15 | Waits up to 15 seconds. |
name: myname | Waits for "name:" and sends "billw." (Using just "name:" will help avoid any capitalization issues.) |
word: mypassword | Waits for "word:" and sends the password. |
">" "slip default" | Waits for the > prompt and places the line into SLIP mode with its default address. |
The following example shows the use of chat scripts implemented with the system-script and modem-script options of the dialer map command.
If there is traffic for IP address 1.2.3.4, the router will dial the 91800 number using the usrobotics-v32 script, matching the regular expression in the modem chat script. Then the router will run the unix-slip chat script as the system script to log in.
If there is traffic for 4.3.2.1, the router will dial 8899 using usrobotics-v32, matching both the modem script and modem chat script regular expressions. The router will then log in using the cisco-compressed script.
! Script for dialing a usr v.32 modem:
chat-script usrobotics-v32 ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30 CONNECT \c
!
! Script for logging into a unix system and starting up slip:
chat-script unix-slip ABORT invalid TIMEOUT 15 name: billw word: wewpass ">"
"slip default"
!
! Script for logging into a cisco comm server and starting up TCP header
! compression:
chat-script cisco-compressed...
!
line 15
script dialer usrobotics-*
!
interface async 15
dialer map ip 1.2.3.4 system-script *-v32 system-script cisco-compressed 8899
dialer map ip 4.3.2.1 modem-script *-v32 modem-script cisco-compressed 8899
Posted: Fri Aug 25 13:52:07 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.