Configuring SDLC


You want to configure a serial port to connect to an SDLC device so that it can use DLSw to talk to a central mainframe.


The global configuration commands in this example are identical to those shown in Recipe 15.1 for using DLSw+ to connect two Token Rings. The central router's configuration is identical to what was used in Recipe 15.1, so the following only shows the remote branch configuration:

dlsw-branch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
dlsw-branch(config)#interface Loopback0
dlsw-branch(config-if)#ip address
dlsw-branch(config)#access-list 200 permit 0x0000 0x0D0D
dlsw-branch(config)#source-bridge ring-group 101
dlsw-branch(config)#dlsw local-peer peer-id
dlsw-branch(config)#dlsw timer explorer-wait-time 5
dlsw-branch(config)#dlsw remote-peer 0 tcp lsap-output-list 200
dlsw-branch(config)#dlsw allroute-sna
dlsw-branch(config)#interface Serial1
dlsw-branch(config-if)#description Connection to one remote SDLC device
dlsw-branch(config-if)#encapsulation sdlc
dlsw-branch(config-if)#no keepalive
dlsw-branch(config-if)#clock rate 4800
dlsw-branch(config-if)#sdlc role primary
dlsw-branch(config-if)#sdlc vmac 4000.CCCC.0000
dlsw-branch(config-if)#sdlc poll-pause-timer 200
dlsw-branch(config-if)#sdlc address 20
dlsw-branch(config-if)#sdlc xid 20 017A0006
dlsw-branch(config-if)#sdlc partner 4000.3745.AAAA 20
dlsw-branch(config-if)#sdlc dlsw 20



SDLC is a serial protocol that is commonly used for SNA devices. It is extremely popular in financial environments for devices such as banking machines, card readers, and account printers. Using SDLC in conjunction with DLSw is becoming increasingly common in these sorts of situations. This allows the remote SDLC devices to communicate with the Token Ring Interface Coupler (TIC) on a mainframe computer through an IP network. There is a huge advantage to this because it means that you don't have to have a separate serial port on your mainframe's Front End Processor (FEP) for every remote SDLC connection. Instead, you can have a single Token Ring interface supporting hundreds of remote devices that are connected through a reliable routed TCP/IP network.

Although it is essentially a synchronous serial protocol, there are several ways of constructing SDLC links. The simplest is a point-to-point connection from the router to an SDLC device, perhaps even another router. The SDLC link can also connect several devices in a long serial bus connection called a multidrop, and it can even be set up in a ring topology. To accomplish this SDLC requires that each device have a unique 8-bit address between 0x01 and 0xFF in hexadecimal (1-255 in decimal notation). Each device is configured to respond to one of these SDLC addresses. A primary SDLC device polls every known address in turn to ask the devices if they have data to send. So despite having many physical devices sharing a serial connection, there is no danger of collisions from two devices sending simultaneously. One of the advantages to DLSw is that it takes care of local acknowledgement of these SDLC polls. So if you connect two SDLC circuits by using DLSw, the polling traffic doesn't cross the WAN, which saves bandwidth.

The example above sets up the SDLC encapsulation on the port, provides the Data Communications Equipment (DCE) clock, and acts as the master device to a downstream SDLC device. The example also defines an artificial Token Ring MAC address for this device so that the FEP will be able to communicate with it through its Token Ring port. Let's look at these functions separately:

dlsw-branch(config)#interface Serial1
dlsw-branch(config-if)#encapsulation sdlc
dlsw-branch(config-if)#clock rate 4800

First, the command encapsulation sdlc sets up the interface to use SDLC framing. This is accompanied by the nrzi-encoding command that specifies the electrical characteristics of the signaling. Nonreturn to Zero Inverted (NRZI) is often required with IBM equipment. The default behavior for SDLC connections on Cisco routers is Nonreturn to Zero (NRZ), which you can set by just turning off NRZI encoding, no nrzi-encoding.

Next, this example assumes that the router is the DCE for this SDLC line, so it must supply the clock with the clock rate command. In the example, the clock rate is set to 4,800 bits per second. In general, you want the clock rate to be as high as the downstream devices can support to facilitate better data transfer rates. However, it is relatively common to see SDLC devices that work only intermittently at higher rates such as 19,200 bps. So a good practice when having problems with SDLC equipment is to turn the clock rate down somewhat and see if the problems go away.

Note also that anytime that you configure a router serial interface to be the DCE device, you must use a DCE cable. The router will not even accept the clock rate command if you have a DTE cable connected to the interface.

The command sdlc role primary is used with multidrop SDLC connections to define how the router's function in the multidrop network:

dlsw-branch(config-if)#sdlc role primary

A multidrop connection simply means that several devices are connected in series to the same serial port. You lose nothing by using this command with a single downstream device connected directly to the router, however. The different options for the sdlc role command are primary, secondary, and prim-xid-poll. Configuring the router to be the SDLC primary requires that all downstream devices are either PU 2.0, PU 2.1, or a mixture, and that the router will be the master. You should specify prim-xid-poll only if all downstream devices use PU 2.1 and you want the router to be the master device of the group.

In this example there is only one SDLC device connected to the router, and its SDLC address is specified as 0x20 in hex. This is specified by the sdlc address command. Recipe 15.6 shows how to configure the router for several downstream SDLC devices.

The SDLC address is purely local to this SDLC connection. So to uniquely identify a particular remote device anywhere in the network, the mainframe needs more information. Each device is identified in VTAM in a Switched Major Node definition using two parameters called IDBLK and IDNUM. Cisco concatenates these two identifiers together to form the Exchange of Identification (XID). The example shows how to associate a particular IDBLK/IDNUM with a particular SDLC address by using the following command:

dlsw-branch(config-if)#sdlc xid 20 017A0006

The IDBLK is contained in the first three digits of the XID field017, in this case, and the IDNUM appears in the remaining five digits, A0006. Typographical errors in the XID string are some of the most common SDLC problems. Make sure that this 8-digit hexadecimal number precisely matches the IDBLK/IDNUM configured for this device in VTAM.

Next, look at the commands that work with DLSw to allow this particular device to communicate with the mainframe. First, there must be a virtual Token Ring MAC address, which is defined using the sdlc vmac command:

dlsw-branch(config-if)#sdlc vmac 4000.CCCC.0000

Recall that the mainframe thinks that this SDLC device is actually a Token Ring device. This command defines the fake Token Ring address that the mainframe will use to communicate with it. However, there could be several devices on this port, all of which must have unique MAC addresses. To solve this problem, the last two digits of this address are replaced by the SDLC address. So the last two hex characters in this configuration statement must be zero. In this particular case, the sdlc vmac command defines a MAC address of 4000.CCCC.0000 for the serial interface. The one configured downstream device has an SDLC address of 20 (in hex). So it will appear on the mainframe's ring with the MAC address 4000.CCCC.0020.

Just as the SDLC device must appear to be a Token Ring device to the mainframe, the mainframe must appear to be an SDLC device on this serial port. So your router must insert the FEP's MAC address into the LLC packet. This is configured with the sdlc partner command:

dlsw-branch(config-if)#sdlc partner 4000.3745.AAAA 20

Note that the SDLC address is specifically included in this command to allow the different devices on a multidrop SDLC circuit to communicate with different FEPs.

DLSw has to know to pick up this particular SDLC address and share it with its DLSw peer routers. You set this with the sdlc dlsw command:

dlsw-branch(config-if)#sdlc address 20
dlsw-branch(config-if)#sdlc dlsw 20

The router will reject this command if you have not previously defined this address with the sdlc address command.

In this example, we have modified one of the important SDLC timing parameters by using the sdlc poll-pause-timer command:

dlsw-branch(config-if)#sdlc poll-pause-timer 200

In SDLC, the primary device must poll the downstream devices to see if they have something to send. The example uses this command with an argument of 200, which instructs the router to wait a period of 200 milliseconds between these polls. The default value is 100 milliseconds. The reason for using a longer interval between polls is simply to allow the downstream devices more time to respond. In some cases, particularly if the SDLC line is long or involves modems or line drivers to reach a physically remote device, the default value is not sufficient to account for the natural latency of the line. Note, however, that this polling does not cross the DLSw bridge, only the SDLC side of the network. This ability to terminate the local polling saves bandwidth and makes the network more tolerant of WAN latency.

There is one important final note on SDLC to Token Ring bridging. In Example 15.3, when bridging Ethernet to Token Ring, we had to make a restriction on the MTU in the dlsw remote-peer command. This is not necessary for SDLC. The SDLC frame size is normally either 265 or 521 bytes, much smaller than even the Ethernet frame size. But the difference here is that DLSw can fragment the larger Token Ring packets when sending them out of the SDLC port. However, it cannot combine several smaller SDLC frames into a larger Token Ring frame. So these packets remain small.

See Also

Recipe 15.1; Recipe 15.3; Recipe 15.6

Router Configuration and File Management

Router Management

User Access and Privilege Levels


IP Routing





Frame Relay

Handling Queuing and Congestion

Tunnels and VPNs

Dial Backup

NTP and Time


Router Interfaces and Media

Simple Network Management Protocol





First Hop Redundancy Protocols

IP Multicast

IP Mobility




Appendix 1. External Software Packages

Appendix 2. IP Precedence, TOS, and DSCP Classifications


Cisco IOS Cookbook
Cisco IOS Cookbook (Cookbooks (OReilly))
ISBN: 0596527225
EAN: 2147483647
Year: 2004
Pages: 505 © 2008-2020.
If you may any questions please contact us: