|
|
You do not need to configure Logical Link Control, type 2 (LLC2) Protocol because it is already enabled on Token Ring interfaces. This chapter describes how to modify the default settings of LLC2 parameters as needed.
To support the Synchronous Data Link Control (SDLC) protocol, you must configure the router to act as a primary or secondary SDLC station. You also can change default settings on any SDLC parameters. Configuration examples for both LLC2 and SDLC are given at the end of the chapter.
For a complete description of the LLC2 and SDLC commands mentioned in this chapter, refer to the "LLC2 and SDLC Commands" chapter in the Cisco IOS Bridging and IBM Networking Command Reference, Volume I. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
This chapter contains the following sections:
The LLC2 and SDLC protocols provide data link layer support for higher-layer network protocols and features such as SDLC Logical Link Control (SDLLC) and RSRB with local acknowledgment. The features that are affected by LLC2 parameter settings are listed in the next section, "Cisco's Implementation of LLC2." The features that require SDLC configuration and use SDLC parameters are listed in the section "Cisco's Implementation of SDLC" later in this chapter.
SDLC is used as the primary SNA link-layer protocol for WAN links. SDLC defines two types of network nodes: primary and secondary. Primary nodes poll secondary nodes in a predetermined order. Secondary nodes then transmit any outgoing data. When configured as primary and secondary nodes, our routers are established as SDLC stations.
Cisco's LLC2 implementation supports the following features:
Cisco's SDLC implementation supports the following features:
The Cisco IOS software includes the following media translation features that enable network communications across heterogeneous media:
SDLLC is a Cisco Systems proprietary software feature that enables a device on a Token Ring to communicate with a device on a serial link by translating between LLC2 and SDLC at the link layer.
SNA uses SDLC and LLC2 as link layer protocols to provide a reliable connection. The translation function between these industry-standard protocols takes place in the proprietary Cisco software.
Figure 161 illustrates how SDLLC provides data link layer support for SNA communication.
The SDLLC feature allows a PU 4, PU 2.1, or PU 2 to communicate with a PU 2 SDLC device as follows:
In all these topologies, each IBM end node (the FEP and cluster controller) has no indication that its counterpart is connected to a different medium running a different protocol. The 37x5 FEP responds as if the 3x74 cluster controller were communicating over a Token Ring, whereas the 3x74 responds as though the 37x5 FEP were communicating over a serial line. That is, the SDLLC software makes translation between the two media transparent to the end nodes.
Central to Cisco's SDLLC feature is the concept of a virtual Token Ring device residing on a virtual Token Ring. Because the Token Ring device expects the node with which it is communicating also to be on a Token Ring, each SDLLC device on a serial line must be assigned an SDLLC virtual Token Ring address (SDLLC VTRA). Like real Token Ring addresses, SDLLC VTRAs must be unique across the network.
In addition to the SDLLC VTRA, an SDLLC virtual ring number must be assigned to each SDLLC device on a serial line. (The SDLLC virtual ring number differs from the virtual ring group numbers that are used to configure RSRB and multiport bridging.)
As part of its virtual telecommunications access method (VTAM) configuration, the IBM node on the Token Ring has knowledge of the SDLLC VTRA of the serial device with which it communicates. The SDLC VTRA and the SDLLC virtual ring number are a part of the SDLLC configuration for the router's serial interface. When the Token Ring host sends out explorer packets with the SDLLC VTRA as the destination address in the MAC headers, the router configured with that SDLLC VTRA intercepts the frame, fills in the SDLLC virtual ring number address and the bridge number in the RIF, then sends the response back to the Token Ring host. A route is then established between the Token Ring host and the router. After the Cisco IOS software performs the appropriate frame conversion, the system uses this route to forward frames to the serial device.
IBM nodes on Token Ring media normally use frame sizes greater than 1 KB, whereas the IBM nodes on serial lines normally limit frame sizes to 265 or 521 bytes. To reduce traffic on backbone networks and provide better performance, Token Ring nodes should send frames that are as large as possible. As part of the SDLLC configuration on the serial interface, the largest frame size the two media can support should be selected. The Cisco IOS software can fragment the frames it receives from the Token Ring device before forwarding them to the SDLC device, but it does not assemble the frames it receives from the serial device before forwarding them to the Token Ring device.
SDLLC maintains a dynamic RIF cache and caches the entire RIF; that is, the RIF from the source station to destination station. The cached entry is based on the best path at the time the session begins. SDLLC uses the RIF cache to maintain the LLC2 session between the router and the host FEP. SDLLC does not age these RIF entries. Instead, SDLLC places an entry in the RIF cache for a session when the session begins and flushes the cache when the session terminates. You cannot flush these RIFs because if you flush the RIF entries randomly, the Cisco IOS software cannot maintain the LLC2 session to the host FEP.
The following are additional facts regarding SDLC and SDLLC:
Qualified Logical Link Control (QLLC) is a data link protocol defined by IBM that allows Systems Network Architecture (SNA) data to be transported across X.25 networks. (Although IBM has defined other protocols for transporting SNA traffic over an X.25 network, QLLC is the most widely used.) Figure 162 illustrates how QLLC conversion provides data link layer support for SNA communication.
As shown in Figure 163, any devices in the SNA communication path that use X.25, whether end systems or intermediate systems, require a QLLC implementation.
As shown in Figure 164, the QLLC conversion feature eliminates the need to install the X.25 software on local IBM equipment. A device attached locally to a Token Ring network can communicate through a router running the QLLC Conversion feature with a remote device attached to an X.25 network using QLLC. Typically, the locally attached device is an FEP, an AS 400, or a PS/2, and the remote device is a terminal controller or a PS/2. In this case, only the remote device needs an X.25 interface and the FEP can communicate with the terminal controller as if it were directly attached via a Token Ring network.
More elaborate configurations are possible. The router that implements QLLC conversion need not be on the same Token Ring network as the FEP. As shown in Figure 165, QLLC/LLC2 conversion is possible even when an intermediate IP WAN exists between the router connected to the X.25 network and the router connected to the Token Ring.
SNA uses QLLC and X.25 as link layer protocols to provide a reliable connection. QLLC itself processes QLLC control packets. In a Token Ring environment, SNA uses LLC to provide a reliable connection. The LAN-to-X.25 (LNX) software provides a QLLC conversion function to translate between LLC and QLLC.
Figure 166 shows the simplest QLLC conversion topology: a single Token Ring device (for example, a 37x5 FEP) communicates with a single remote X.25 device (in this case a 3x74 cluster controller). In this example, a router connects the Token Ring network to the X.25 network.
In Figure 166, each IBM end node has no indication that its counterpart is connected to a different medium running a different protocol. The 37x5 FEP responds as if the 3x74 cluster controller were communicating over a Token Ring, whereas the 3x74 responds as though the 37x5 FEP were communicating over an X.25 network. This is accomplished by configuring the router's X.25 interface as a virtual Token Ring, so that the X.25 virtual circuit appears to the Token Ring device (and to the router itself) as if it were a Token Ring to which the remote X.25 device is attached.
Also in this figure, the LLC2 connection extends from the 37x5 FEP across the Token Ring network to the router. The QLLC/X.25 session extends from the router across the X.25 network to the 3x74 cluster controller. Only the SNA session extends across the Token Ring and X.25 networks to provide an end-to-end connection from the 37x5 FEP to the 3x74 cluster controller.
As Figure 167 shows, a router need not directly connect the two IBM end nodes; instead, some type of backbone WAN can connect them. Here, RSRB transports packets between Router A and Router B, while Router B performs all conversion between the LLC2 and X.25 protocols. Only the router attached to the serial line (Router B) needs to be configured for QLLC conversion. Both Router A and Router B are configured for normal RSRB.
How communication sessions are established over the communication link varies depending on whether or not LLC2 local acknowledgment has been configured on Router A's Token Ring interface. In both cases, the SNA session extends end-to-end and the QLLC/X.25 session extends from Router B to the 3x74 cluster controller. If LLC2 local acknowledgment has not been configured, the LLC2 session extends from the 37x5 FEP across the Token Ring network and the arbitrary WAN to Router B. In contrast, when LLC2 local acknowledgment has been configured, the LLC2 session extends from the 37x5 FEP Router A, where it is locally terminated. A TCP session is then used across the arbitrary WAN to Router B.
Although the procedures you use to configure QLLC are similar to those used to configure SDLLC, there are structural and philosophical differences between the point-to-point links that SDLC uses and the multiplexed virtual circuits that X.25 uses.
The most significant structural difference between QLLC conversion and SDLLC is the addressing. To allow a device to use LLC2 to transfer data, both SDLLC and QLLC provide virtual MAC addresses. In SDLLC, the actual MAC address is built by combining the defined virtual MAC (whose last byte is 0x00) with the secondary address used on the SDLC link; in this way, SDLLC supports multidrop. In QLLC conversion, multidrop is meaningless, so the virtual MAC address represents just one session and is defined as part of the X.25 configuration. Because one physical X.25 interface can support many simultaneous connections for many different remote devices, you only need one physical link to the X.25 network. The different connections on different virtual circuits all use the same physical link.
The most significant difference between QLLC conversion and SDLLC is the fact that a typical SDLC/SDLLC operation uses a leased line. In SDLC, dial-up connections are possible, but the maximum data rate is limited. In QLLC, both switched virtual circuits (SVCs) and permanent virtual circuits (PVCs) are available, but the favored use is SVC. While the router maintains a permanent connection to the X.25 network, a remote device can use each SVC for some bounded period of time and then relinquish it for use by another device. Using a PVC is very much like using a leased line.
shows how the QLLC commands correspond to the SDLLC commands.
| QLLC Command | Analogous SDLLC Command |
|---|---|
qllc largest-packet | sdllc ring-largest-frame, sdllc sdlc-largest-frame |
qllc partner | sdllc partner |
qllc sap | sdllc sap |
qllc srb, x25 map qllc, x25 pvc qllc | sdllc traddr |
qllc xid | sdllc xid |
source-bridge qllc-local-ack | source-bridge sdllc-local-ack |
Consider the following when implementing QLLC conversion:
You can configure DLSw+ for QLLC connectivity, which enables the following scenarios:
For information on configuring DLSw+ for QLLC conversion, refer to the "Configuring DLSw+" chapter.
You can configure DSPUs for QLLC. For more information on this configuration, refer to the "Configuring DSPU and SNA Service Point Support" chapter.
Because LLC2 is already enabled on a Token Ring, you do not need to enable it on the router. However, you can enhance LLC2 performance by completing the following tasks:
Control the number of information frames (I-frames) and acknowledgments sent on the LLC2 network by completing the tasks described in the following sections.
You can reduce overhead on the network by increasing the maximum number of frames the Cisco IOS software can receive at once before it must send the sender an acknowledgment. To do so, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 ack-max packet-count | Sets maximum number of I-frames the router can receive before it sends an acknowledgment. |
You can ensure timely receipt of acknowledgments so that transmission of data is not delayed. Even if the maximum amount of frames has not been reached, you can set a timer forcing the router to send an acknowledgment and reset the maximum amount counter to 0.
To set the maximum delay time, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 ack-delay-time milliseconds | Sets the I-frame acknowledgment time. |
You can set the maximum number of I-frames that the router sends to an LLC2 station before the software requires an acknowledgment from the receiving end. A higher value reduces overhead on the network. Ensure that the receiving LLC2 station can handle the number of frames set by this value.
To set this value, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 local-window packet-count | Sets the maximum number of I-frames the router sends before it requires an acknowledgment. |
You can set the number of times the router will re-send a frame when the receiving station does not acknowledge the frame. Once this value is reached, the session is dropped. This value also is used to determine how often the software will retry polling a busy station. Use this command in conjunction with the llc2 t1-time command described in the section "Setting the Time for Resending I-Frames." Using them together ensures that frame transmission is monitored at a reasonable level, while limiting the number of unsuccessful repeated tries.
To set the number of retries, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 n2 retry-count | Establishes the number of times the router will re-send unacknowledged frames or try polling a busy station. |
To set the T1 time, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 t1-time milliseconds | Controls how long the router waits for an acknowledgment of transmitted I-frames. |
 |
NoteEnsure that you allow enough time for the round trip between the router and its LLC2-speaking stations. Under heavy network loading conditions, resending I-frames every 3000ms is appropriate. |
To set the reject timer, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 trej-time milliseconds | Sets the time the Cisco IOS software waits for a re-send of a rejected frame before sending a reject command to the remote station. |
You can control the amount of polling that occurs on the LLC2 network by completing the tasks described in the following sections:
You can set the optimum interval of time after which the router sends Receiver Ready messages or frames that tell other LLC2 stations that the router is available. These polls occur during periods of idle time on the network.
To set polling frequency, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 idle-time milliseconds | Controls the polling frequency during idle traffic. |
The amount of time the router waits until re-polling a busy station can also be set. Use this command in conjunction with setting the number of retries. Typically, you do not need to use this command unless an LLC2 station has unusually long busy periods before clearing the busy state. In this case, you should increase the value so that the station does not time out.
To set the polling interval, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 tbusy-time milliseconds | Sets the amount of time the router will wait before re-polling a busy station. |
When the router sends a command that must receive a response, a poll bit is sent in the frame. When the software sends the poll bit, it cannot send any other frame with the poll bit set until the receiver replies to that poll frame with a frame containing a final bit set. When the timer expires, the software assumes that it can send another frame with a poll bit.
Set the transmit-poll-frame timer to reduce problems with receiving stations that are faulty and cannot send the frame with the final bit set by using the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 tpf-time milliseconds | Sets the amount of time the router waits for a final response to a poll frame before the resending it. |
This value should be larger than the T1 time. The T1 time determines how long the software waits for receipt of an acknowledgment before sending the next set of frames. See the section "Setting the Time for Resending I-Frames" earlier in this chapter for more information.
You can control the number of frames used for identification on the LLC2 network by completing the tasks described in the following sections:
| Command | Purpose |
|---|---|
llc2 xid-neg-val-time milliseconds | Sets the frequency of XID transmissions. |
 |
CautionDo not change the value unless requested by your technical support representative. |
To set the time for XID retries, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
llc2 xid-retry-time milliseconds | Sets how long the router waits for a reply to the XID frames it sends to remote stations. |
You can display the configuration of LLC2 stations to determine which LLC2 parameters need adjustment. Use the following command in EXEC mode:
| Command | Purpose |
|---|---|
show llc2 | Displays the configuration of LLC2 stations. |
SDLC defines two types of network nodes: primary and secondary. Primary nodes poll secondary nodes in a predetermined order. Secondaries then transmit if they have outgoing data. When configured as primary and secondary nodes, our devices are established as SDLC stations.
Depending on your particular network needs, perform the tasks in one of the following sections to enable the router as an SDLC station:
You can establish the router to be any of the following:
To establish devices as SDLC stations when you plan to configure Frame Relay access support, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step1 | encapsulation sdlc1 | Sets the encapsulation type of the serial interface to SDLC. |
Step2 | sdlc role {none | primary | secondary | prim-xid-poll} | Establishes the role of the interface. |
| 1For information on the nrzi-encoding interface configuration command, refer to the Cisco IOS Configuration Fundamentals Configuration Guide. |
If the interface does not play a role, the router can be either primary or secondary, depending on the end stations. The SDLC end station must be configured as negotiable or primary NT2.1. When the end stations are configured as physical unit (PU) type 2, you can set the role of the interface to primary or secondary. When the end station is configured as secondary NT2.1, you must set the role of the interface to poll the primary XID.
|
NoteCurrently, Frame Relay access support does not support the secondary role. |
To establish devices as SDLC stations when you plan to configure our DLSw+ feature, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step1 | encapsulation sdlc | Sets the encapsulation type of the serial interface to SDLC. |
Step2 | sdlc role {none | primary | secondary | prim-xid-poll} | Establishes the role of the interface. |
Step3 | sdlc vmac mac-address | Configures a MAC address for the serial interface. |
Step4 | sdlc partner mac-address sdlc-address | Specifies the destination address with which an LLC session is established for the SDLC station. |
Step5 | sdlc dlsw {sdlc-address | default | partner
mac-address [inbound | outbound]}
| Attaches SDLC addresses to DLSw+. |
For additional DLSw+ configuration commands, refer to the "Configuring DLSw+" chapter in this publication.
To establish devices as SDLC stations when you plan to configure our SDLLC media translation feature, use the commands in the order listed in the following table. One serial interface can have two or more secondary stations attached to it through a modem sharing device. Each secondary station address must be assigned to the primary station. You must use the following commands in interface configuration mode for the serial interface:
| Command | Purpose | |
|---|---|---|
Step1 | encapsulation sdlc-primary | Establishes a router as the primary SDLC station on the serial line. |
Step2 | encapsulation sdlc-secondary | Establishes other routers as secondary SDLC stations. |
Step3 | sdlc address hexbyte [echo] | Assigns secondary stations to a primary station. |
Use the show interfaces command to list the configuration of the SDLC serial lines. Use the no sdlc address command to remove a secondary address assignment. Addresses are hexadecimal (base 16).
SDLC two-way simultaneous mode allows a primary SDLC link station to achieve more efficient use of a full-duplex serial line. With two-way simultaneous mode, the primary link station can send data to one secondary link station while there is a poll outstanding. Two-way simultaneous mode works on the SDLC primary side only. On a secondary link station, it responds to a poll from the primary station.
SDLC two-way simultaneous mode operates in either a multidrop link environment or point-to-point link environment.
In a multidrop link environment, a two-way simultaneous primary station is able to poll a secondary station and receive data from the station, and send data (I-frames) to other secondary stations.
In a point-to-point link environment, a two-way simultaneous primary station can send data (I-frames) to the secondary station although there is a poll outstanding, as long as the window limit is not reached.
To enable two-way simultaneous mode, use either of the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc simultaneous full-datamode | Enables the primary station to send data to and receive data from the polled secondary station. Prohibits the primary stations from sending data to the polled secondary station. |
To determine handling of frame rejects, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc frmr-disable | Specifies that this secondary station does not support frame rejects. |
To specify that the secondary station does support frame rejects, use the no sdlc frmr-disable command.
When an SDLC station sends a frame, it waits for an acknowledgment from the receiver indicating that this frame has been received. You can modify the time the router allows for an acknowledgment before resending the frame. You can also determine the number of times that a software re-sends a frame before terminating the SDLC session. By controlling these values, you can reduce network overhead while continuing to check transmission of frames.
To set the SDLC timer and retry counts, use one or both of the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc t1 milliseconds | Controls the amount of time the CiscoIOS software waits for a reply. |
sdlc n2 retry-count | Sets the number of times the Cisco IOS software will retry an operation that has timed out. |
You can set the maximum size of an incoming frame and set the maximum number of I-frames (or window size) the router will receive before sending an acknowledgment to the sender. By using higher values, you can reduce network overhead.
To set SDLC frame and window sizes, use any of the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc n1 bit-count | Sets the maximum size of an incoming frame. |
sdlc k window-size | Sets the local window size of the router. |
sdlc poll-limit- value count | Sets how many times a primary station will poll a secondary station. |
To control backlogs that can occur during periods of high data transfer from the Token Ring to the serial line, use the following command in interface configuration mode on a per-address basis:
| Command | Purpose |
|---|---|
sdlc holdq address queue-size | Sets the maximum number of packets held in queue before transmitting. |
You can control the intervals at which the router polls secondary stations, the length of time a primary station can send data to a secondary station, and how often the software polls one secondary station before moving on to the next station.
Keep the following points in mind when using these commands:
To control polling of secondary stations, use one or more of the following commands in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc poll-pause-timer milliseconds | Sets the length of time the router pauses between sending each poll frame to secondary stations on a single serial interface. |
sdlc poll-limit- value count | Sets how many times a primary station will poll a secondary station. |
To retrieve default polling values for these operations, use the no forms of these commands.
By default, SDLC interfaces operate in full-duplex mode. To configure an SDLC interface for half-duplex mode, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
half-duplex | Configures an SDLC interface for half-duplex mode. |
On an interface that is in half-duplex mode and that has been configured for DCE, you can adjust the delay between the detection of a Request To Send (RTS) signal and the assertion of the Clear To Send (CTS) signal. To do so, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
half-duplex timer cts-delay value | Delays the assertion of a CTS. |
On an interface that is in half-duplex mode and that has been configured for DTE, you can adjust the time the interface waits for the DCE to assert CTS before dropping an RTS. To do so, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
half-duplex timer rts-timeout value | Adjusts the amount of time before interface drops an RTS. |
The exchange of identification (XID) value you define on the router must match that of the IDBLK and IDNUM system generation parameters defined in VTAM on the Token Ring host to which the SDLC device will be communicating. To specify the XID value, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc xid address xid | Specifies the XID value to be associated with the SDLC station. |
Generally, the router and the SDLC device with which it communicates should support the same maximum SDLC I-frame size. The larger this value, the more efficient the line usage, thus increasing performance.
After the SDLC device has been configured to send the largest possible I-frame, you must configure the router to support the same maximum I-frame size. The default is 265 bytes. The maximum value the software can support must be less than the value of the LLC2 largest frame value defined when setting the largest LLC2 I-frame size.
To set the largest SDLC I-frame size, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
sdlc sdlc-largest-frame address size | Sets the largest I-frame size that can be sent or received by the designated SDLC station. |
To monitor the configuration of SDLC stations to determine which SDLC parameters need adjustment, use the following command in EXEC mode:
| Command | Purpose |
|---|---|
show interfaces | Displays SDLC station configuration information. |
You determine the status of end stations by sending an SDLC test frame to a physical unit via its SDLC address and router interface. You can either send out the default information string or a predefined one. You can send a preset number of test frames a continuous stream that can later be halted. The sdlc test serial command pre-check for correct interface and SDLC address of the end station. You can view the results of the test frames after the frames have been sent or a SDLC test frame stop has been executed. To send an SDLC test frame, use the following command in EXEC mode:
| Command | Purpose |
|---|---|
sdlc test serial number address [iterations | continuous | stop | string string] | Sends an SDLC test frame. |
|
NoteOnly a device configured as primary is allowed to send test frames. |
The following sections provide LLC2 and SDLC configuration examples:
You can configure the number of LLC2 frames received before an acknowledgment. For this example, assume that at time 0, two I-frames are received. The maximum amount of three has not been reached, so no acknowledgment for these frames is sent. If a third frame, which would force the router to send an acknowledgment, is not received within 800 ms, an acknowledgment is sent anyway, because the delay timer alarm is activated.
interface tokenring 0 llc2 ack-max 3 llc2 ack-delay-time 800
At this point, because all frames are acknowledged, the counter for the maximum amount of I-frames will be reset to zero.
The following configuration defines serial interface 0 as the primary SDLC station with two SDLC secondary stations, C1 and C2, attached to it through a modem-sharing device. Two-way simultaneous mode is enabled.
interface serial 0 encapsulation sdlc-primary sdlc address c1 sdlc address c2 sdlc simultaneous full-datamode
The network for this configuration is shown in Figure 168.
The following examples describe possible SDLC encapsulation configurations if you plan to configure Frame Relay access support.
The following configuration is appropriate if the SDLC station is a negotiable or primary Node Type2.1 station:
interface serial 2/6 no ip address encapsulation sdlc clockrate 9600 fras map sdlc C1 serial 2/0 frame-relay 32 4 4 sdlc address C1
The following configuration is appropriate if the SDLC station is a secondary Node Type 2.1 station:
interface serial 2/6 no ip address encapsulation sdlc clockrate 9600 fras map sdlc C1 serial 2/0 frame-relay 32 4 4 sdlc role prim-xid-poll sdlc address C1
The following configuration is appropriate if the SDLC station is a secondary PU 2 station:
interface serial 2/6 no ip address encapsulation sdlc clockrate 9600 fras map sdlc C1 serial 2/0 frame-relay 32 4 4 sdlc role primary sdlc address C1 sdlc xid C1 01700001
The following example describes an SDLC configuration if you plan to implement DLSw+ support. In this example, 4000.3745.001 is the MAC address of the host. The router serves as the primary station for the remote secondary stations, c1 and c2. Both c1 and c2 are reserved for DLSw+ and cannot be used by any other data link user.
interface serial 0 encapsulation sdlc sdlc vmac 4000.3174.0000 sdlc address c1 sdlc xid c1 01712345 sdlc partner 4000.3745.0001 c1 sdlc address c2 sdlc xid c2 01767890 sdlc partner 4000.3745.0001 c2 sdlc dlsw c1 c2 sdlc role primary
In the following example, an SDLC interface has been configured for half-duplex mode:
encapsulation sdlc-primary half-duplex
Posted: Thu Jul 20 10:32:38 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.