|
|
SDLLC is a software feature that enables a device on a Token Ring to communicate with a device on a serial link by translating between Logical Link Control, Type 2 (LLC2) and Synchronous Data Link Control (SDLC) at the link layer. SDLLC is proprietary to Cisco Systems.
For a complete description of the commands in this chapter, refer to the chapter "SDLLC Commands" in the Router Products Command Reference publication.
Figure 1-1 illustrates how SDLLC provides link-level support for Systems Network Architecture (SNA) communication.
As Figure 1-1 shows, 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.
The SDLLC software allows a physical unit (PU) 4, PU 2.1, or PU 2 to communicate with a PU 2 SDLC device as follows:
In all of 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 provides translation between the two media to be transparent to the end nodes.
Central to Cisco's SDLLC implementation 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 (SDLLC VRN) also must be assigned to each SDLLC device on a serial line. (The SDLLC VRN 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 VRN 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 Media Access Control (MAC) headers, the router configured with that SDLLC VTRA intercepts the frame, fills in the SDLLC VRNA and the bridge number in the routing information field (RIF), and 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 router performs the appropriate frame conversion, it uses this route to forward frames to this 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 as large frames as possible. As part of the SDLLC configuration on the router's serial interface, the largest frame size the two media will support should be selected. The router can fragment the frames it receives from the Token Ring device before forwarding them to the SDLC device; however, it does not assemble the frames it receives from the serial device before forwarding them to the Token Ring device.
SDLCC maintains a dynamic RIF cache. SDLLC 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 began. 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 flushed the RIF entries randomly, the router would not be able to maintain the LLC2 session to the host FEP.
You can perform the tasks in the following sections to configure SDLLC:
See the end of this chapter for SDLLC configuration examples.
In the SDLLC configuration with direct connection, a 37x5 FEP on a Token Ring and a 3x74 cluster controller connected to a serial line are each connected to an interface on the same router configured with SDLLC. In this configuration, the LLC2 session extends from the 37x5 FEP across the Token Ring to the router. The SDLLC session extends from the router across the serial line to the 3x74 cluster controller. The SNA session extends across the Token Ring and the serial line to provide an end-to-end connection. The router is configured with source-route bridging (SRB).
To configure SDLLC with direct connection, you must perform the tasks in the following sections:
For an example of how to configure SDLLC with direct connection, see the "Example of SDLLC with Direct Connection" later in this chapter.
The interfaces you will configure for SDLLC media translation are the serial interfaces that connect to the serial lines linking the remote SDLC devices. To configure them, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable SDLLC media translation on a serial interface. | sdllc traddr xxxx.xxxx.xx00 lr bn tr |
You can associate a SAP value by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Associate a SAP value. | sdllc sap sdlc-address ssap dsap |
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 of the Token Ring host to which the SDLC device will be communicating. To define XID on the router, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the XID value appropriate for the SDLC station to match VTAM values. | sdllc xid address xxxxxxxx |
The Token Ring host is always kept in a state ready to accept a connection from the remote serial device. The remote serial device is responsible for initiating connections. The advantage of this scheme is that the serial device can communicate with the Token Ring host whenever it chooses without requiring personnel to be on the host site.
The router actually initiates the connection on behalf of the serial device. To initiate connections, both the MAC address of the Token Ring host and the SDLC line address are required. You must configure the router to define the Token Ring host as the partner of the serial device. To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable connections for SDLLC. | sdllc partner mac-address sdlc-address |
A router need not directly connect the two IBM end nodes: a 37x5 FEP on a Token Ring and a 3x74 cluster controller connected to a serial line can be connected to different routers. However, the router to which the 3x74 is connected must be configured with SDLLC. The routers communicate via RSRB using direct encapsulation, RSRB over an FST connection, or RSRB over a TCP connection. RSRB transports packets between Router A and Router B, while Router B performs all conversion between the LLC2 and SDLC protocols by means of the SDLLC software.
To configure the router for SDLLC with RSRB you must perform all the tasks in the "Configure SDLLC with Direct Connection" section earlier in this chapter. In addition, you must perform one of the sets of tasks in the following sections:
For more information about configuring RSRB, see the chapter "Configuring Source-Route Bridging" in this manual and "Source-Route Bridging Commands" in the Router Products Command Reference publication.
For an example of how to configure SDLLC with RSRB, see the section "Example of SDLLC with RSRB (Multiple 3x74s)" later in this chapter.
To configure SDLLC with RSRB using direct encapsulation, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Define a ring group. | source-bridge ring-group ring-group |
| Define a remote peer. | source-bridge remote-peer ring-group interface interface-name [mac-address] |
To configure SDLLC with RSRB over an FST connection, perform the following tasks in global configuration mode:
To configure SDLLC with RSRB over a TCP connection, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Define a ring group. | source-bridge ring-group ring-group |
| Define a remote peer. | source-bridge remote-peer ring-group tcp ip-address |
RSRB can be configured for only local acknowledgment with RSRB using IP encapsulation over a TCP connection. Configuring SDLLC local acknowledgment can reduce time-outs and keepalive traffic on the connection.
If LLC2 local acknowledgment is configured, it must be configured on the serial interface of the router on the 3x74 cluster controller side of the connection and on the Token Ring interface of the router on the 37x5 FEP side of the connection. Whether or not local acknowledgment is configured, the SNA session extends end-to-end and the SDLC session extends from the router configured with the serial interface to the 3x74 cluster controller. However, the LLC2 session extends from the 37x5 FEP to the router with the Token Ring interface configured. The LLC2 session is locally terminated at that router. A TCP session is then established across the wide-area network (WAN) to router on the 3x74 side of the connection.
To configure the router for SDLLC with RSRB and local acknowledgment, you must perform all the tasks in the "Configure SDLLC with Direct Connection" section earlier in this chapter. In addition, you must perform the following tasks in global configuration mode:
Local acknowledgment is not supported when the LLC2 device is attached to an Ethernet rather than to a Token Ring.
For an example of how to configure SDLCC with RSRB and local acknowledgment, see the section "Example of SDLLC with RSRB and Local Acknowledgment" later in this chapter.
For more information about configuring RSRB and local acknowledgment, see the chapter "Configuring Source-Route Bridging" in this manual and "Source-Route Bridging Commands" in the Router Products Command Reference publication.
SDLLC support over Ethernet combines translational bridging with Ethernet support of 37x5 FEP connections. Figure 1-2 shows SDLLC with Ethernet and translational bridging. The 3x75 FEP is attached to Router A through Ethernet. The same router is configured for translational bridging, which translates Ethernet packets into Token Ring packets and passes them across the WAN to Router B connected to the 3x74 cluster controller via a serial line. The LLC2 session terminates at the Router B connected to the 3x74 cluster controller. In addition, Router B maintains an SDLC session from itself to the cluster controller.
To increase performance on connections involving SDLLC media translation, perform the tasks in the following sections:
Note the additional information in the section "Other Customizing Considerations" later in this chapter.
Generally, the router and the LLC2 device with which it communicates should support the same maximum SDLC I-frame size. The larger this value, the better the line is used, thus increasing performance.
Faster screen updates to 3278-style terminals often result by configuring the Token Ring FEP to send as large an I-frame as possible and then allowing the router to segment the frame into multiple SDLC I-frames.
After the Token Ring FEP has been configured to send the largest possible I-frame, it is best to configure the router to support the same maximum I-frame size. The default is 516 bytes. The maximum value the router can support is 8144 bytes.
To set the largest LLC2 I-frame size, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the largest I-frame size that can be sent or received by the designated LLC2 primary station. | sdllc ring-largest-frame value |
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 better the line is utilized, 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 router 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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the largest I-frame size that can be sent or received by the designated SDLC station. | sdlc sdlc-largest-frame address value |
You can increase the data transfer rate by increasing the SDLC line speed on the serial interface. If possible, increase the link speed of the 3x74 to 19.2 kbps on older units, or to 64 kbps on new units.
To increase the SDLC line speed, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Adjust the clock rate on the serial interface of the SCI and MCI cards to an acceptable bit rate. | clockrate speed1 |
In addition to adjusting the SDLLC parameters described in this section, you can improve performance on the connection by adjusting the LLC2 and SDLC parameters described in the chapter, "Configuring LLC2 and SDLC Parameters."
For IBM host configuration consider changing the default MAXOUT (window size) value. Widely used installation guides for IBM equipment show a MAXOUT value of 1 in the VTAM-switched major node for the 3174 PU. Changing this value to 7 improves the performance, because VTAM can send seven frames before requiring an acknowledgment.
To monitor connections using SDLLC media translation, perform the following monitoring tasks in EXEC mode:
| Task | Command |
|---|---|
| Display information about SDLC and LLC2 connections involving interfaces on which SDLLC media translation has been enabled. | show interfaces |
| Display the current state of any connections using local acknowledgment for LLC2 and SDLLC connections. | show sdllc local-ack |
| Display information about LLC2 connections involving interfaces on which SDLLC media translation has been enabled. | show llc21 |
In show llc2 output, look for the LLC2 connections that correspond to the MAC addresses you assigned to the SDLLC interfaces using the sdllc traddr command. For information about these commands, see the chapter "LLC2 and SDLC Commands" and "SDLLC Commands" in the Router Products Command Reference publication.
The following sections provide SDLLC configuration examples:
Figure 1-3 shows a router configuration when the router directly connects the Token Ring and the serial line. The router is configured with SRB.
A configuration file that enables direct connection follows:
source-bridge ring-group 100
!
interface tokenring 0
source-bridge 111 1 100
!
interface serial 0
encapsulation sdlc-primary
sdlc address c1
sdllc traddr 0110.2222.3300 222 2 100
sdllc partner 4000.0122.0001 c1
sdllc xid c1 1720001
Figure 1-4 shows a router configuration in which the router directly connects the Token Ring and the serial line but uses RSRB to create a virtual ring 100. This configuration has the following characteristics:
The following sample configuration file is for SDLLC with a single router using RSRB:
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.1.1
source-bridge remote-peer 100 tcp 131.108.2.2
interface tokenring 0
ip address 131.108.2.2 255.255.255.0
source-bridge 111 1 100
interface serial 0
encapsulation sdlc-primary
sdlc address c1
sdllc traddr 0110.2222.3300 8 1 100
sdllc partner 1000.5a7d.8123 c1
sdllc xid c1 17200c1
In Figure 1-5, SDLLC with RSRB connects an FEP and a single 3x74 cluster controller. The host wants to communicate with a single 3174 that its FEP sees on a Token Ring. However, the 3x74 seen by the FEP is in fact SDLC device C1 connected by means of a serial link through a remote router.
The configuration files for the network shown in Figure 1-5 follow.
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.2
!
interface tokenring 0
ip address 131.108.1.1 255.255.255.0
source-bridge 10 1 100
!
interface ethernet 0
ip address 131.108.2.1 255.255.255.0
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.1.1
source-bridge remote-peer 100 tcp 131.108.2.2
!
interface tokenring 0
ip address 131.108.2.2 255.255.255.0
source-bridge 1 1 100
!
interface serial 0
encapsulation sdlc-primary
sdlc address c1
sdllc traddr 0110.2222.3300 8 1 100
sdllc partner 1000.5a7d.8123 c1
sdllc xid c1 17200c1
In the setup shown in Figure 1-6, Router A needs no SDLLC configuration, Router B has the SDLLC configuration and supports multipoint on the SDLC link with a modem-sharing device and Router C is also configured with SDLLC. For information about the NCP and VTAM system generation (sysgen) parameters that are used in this configuration see the "NCP and VTAM Sysgen Parameters" section later in this chapter
.
The following configuration files describe the network shown in Figure 1-6. The note references to the right of the configuration files refer to the "Notes" section at the end of this chapter.
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.1
source-bridge remote-peer 100 tcp 131.108.2.2
source-bridge remote-peer 100 tcp 131.108.2.3
!
interface tokenring 0
ip address 131.108.1.1 255.255.255.0
source-bridge 10 1 100
!
interface ethernet 0
ip address 131.108.2.1 255.255.255.0
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.1
source-bridge remote-peer 100 tcp 131.108.2.2
source-bridge remote-peer 100 tcp 131.108.2.3
!
interface ethernet 0
ip address 131.108.2.2 255.255.255.0
!
interface serial 0
encapsulation sdlc-primary
sdlc address c1
sdllc traddr 0110.2222.3300 7 1 100
sdllc partner 1000.5a7d.8123 c1
sdllc xid c1 17200c1
!
interface serial 1
encapsulation sdlc-primary
sdlc address c2
sdllc traddr 0220.3333.4400 7 1 100
sdllc partner 1000.5a7d.8123 c2 MUST MATCH TIC LOCADD, NOTE 2
sdllc xid c2 17200c2 MUST MATCH VTAM IDBLK/IDNUM, NOTE 4
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.1
source-bridge remote-peer 100 tcp 131.108.2.2
source-bridge remote-peer 100 tcp 131.108.2.3
!
interface ethernet 0
ip address 131.108.2.3 255.255.255.0
!
interface serial 0
encapsulation sdlc-primary
sdlc address c3
sdllc traddr 0110.2222.3300 9 1 100
sdllc partner 1000.5a7d.8123 c3 MUST MATCH TIC LOCADD, NOTE 2
sdllc xid c3 17200c3 MUST MATCH VTAM IDBLK/IDNUM, NOTE 4
The configuration shown in Figure 1-7 enables local acknowledgment for Router B, which means that the LLC session terminates at Router A. However, the LLC2 session between Router A and Router C is not locally acknowledged and terminates at Router C.
For information about the NCP and VTAM system generation (sysgen) parameters that are used in this configuration see the "NCP and VTAM Sysgen Parameters" section later in this chapter.
The following sample configuration files describe the network shown in Figure 1-7. (The notes in the sample configuration files refer to the "Notes" section at the end of this chapter.)
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.1
source-bridge remote-peer 100 tcp 131.108.2.2 local-ack
source-bridge remote-peer 100 tcp 131.108.2.3
!
interface tokenring 0
ip address 131.108.1.1 255.255.255.0
source-bridge 1 1 100
!
interface ethernet 0
ip address 131.108.2.1 255.255.255.0
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.1 local-ack
source-bridge remote-peer 100 tcp 131.108.2.2
source-bridge remote-peer 100 tcp 131.108.2.3
source-bridge sdllc local-ack
!
interface ethernet 0
ip address 131.108.2.2 255.255.255.0
!
interface serial 0
encapsulation sdlc-primary
sdlc address c1
sdllc traddr 4000.3174.0b0d 7 1 100
sdllc partner 1000.5a7d.8123 c1
!Must match TIC LOCADD [See NOTE 2]
sdllc xid c1 017200c1
!Must match VTAM IDBLK/IDNUM [See NOTE 4]
interface serial 1
encapsulation sdlc-primary
sdlc address c2
sdllc traddr 0110.2222.3200 8 1 100
sdllc partner 1000.5a7d.8123 c2
!Must match TIC LOCADD [See NOTE 2]
sdllc xid c2 017200c2
!Must match VTAM IDBLK/IDNUM [See NOTE 4]
source-bridge ring-group 100
source-bridge remote-peer 100 tcp 131.108.2.1
source-bridge remote-peer 100 tcp 131.108.2.2
source-bridge remote-peer 100 tcp 131.108.2.3
!
interface ethernet 0
ip address 131.108.2.3 255.255.255.0
!
interface serial 0
encapsulation sdlc-primary
sdlc address c3
sdllc traddr 4000.3174.0c00 9 1 100
sdllc partner 1000.5a7d.8123 c3
Must match TIC LOCADD [See NOTE 2]
sdllc xid c3 017200c3
!Must match VTAM IDBLK/IDNUM [See NOTE 4]
The sample system generation (sysgen) parameters in this section show typical NCP and VTAM values that correspond with the Router A, Router B, and Router C configurations shown in
Figure 1-6 and Figure 1-7.
IBM's ACF/NCP uses a function called NTRI (NCP/Token Ring Interconnection) to support Token Ring-attached SNA devices. NTRI also provides translation from Token Ring-attached SNA devices (Physical Units) to switched (dial-up) devices. VTAM provides the resolution for these devices in a Switched Major Node. VTAM treats these devices on NTRI logical lines as switched devices. (For more information consult IBM documentation NCP/SSP/EP Resource Definition Reference, SC30-3448-04.)
Using SDLLC, the Cisco router translates SDLC leased line protocol into Token Ring LLC2 protocol, then the NTRI function in ACF/NCP translates Token Ring LLC2 protocol into an SNA switched protocol.
*****************************************************************
*** SAMPLES BASED ON ACF/NCP V5 R4.
*** NOT ALL NCP PARAMETERS ARE SHOWN
*****************************************************************
* *****************************************************************
* OPTIONS DEFINITION STATEMENT
*****************************************************************
NCPOPT OPTIONS NEWDEFN=YES NTRI GENERATION, MUST BE FIRST STMT
*
*****************************************************************
* BUILD MACRO
*****************************************************************
NCPBU BUILD LOCALTO=1.5, NTRI ACK TIMER FOR LOCAL TOKEN RINGS
REMOTTO=2.5, NTRI ACK TIMER FOR REMOTE TOKEN RINGS
USED IN SDLLC CONFIGURATIONS, NOTE 1
*
*****************************************************************
* DYNAMIC RECONFIGURATION POOL SPACE
*****************************************************************
DRPOOL LUDRPOOL NUMTYP2=50 RESERVE 50 LUS ON PU. T2 PUS
*
*****************************************************************
* PHYSICAL GROUP FOR NTRI TIC #1, DEFINITIONS FOR THE TOKEN RING
* ADAPTER TO ESTABLISH PHYSICAL CONNECTIVITY
*****************************************************************
EPHYG GROUP ECLTYPE=PHYSICAL
*
EPHYL LINE ADAPTER=TIC2, TYPE OF ADAPTER
ADDRESS=(16,FULL), INTERNAL FEP TIC ADDRESS
PORTADD=0,
LOCADD=10005a7d8123, TIC ADDRESS, NOTE 2
RCVBUFC=1440,
MAXTSL=2012,
TRSPEED=16 TOKEN RING SPEED
*
EPHYPU PU
*
EPHYLU LU ISTATUS=INACTIVE
*
*****************************************************************
* NTRI PERIPHERAL LOGICAL LINE GROUP, LINE AND PU PAIRS ARE
* GENERATED BY THE AUTOGEN PARAMETER.
*****************************************************************
ELOGG GROUP ECLTYPE=LOGICAL,
PHYPORT=0,
CALL=INOUT,
AUTOGEN=3 ONE PER SDLLC CONTROLLER,
NOTE 3
*****************************************************************
*****************************************************************
* VTAM SWITCHED MAJOR NODE, BASED ON ACF/VTAM V3 R4.
* THE CODING BELOW SUPPORTS DIAL IN OPERATION ONLY. TYPICALLY,
* NTRI IMPLEMENTATIONS USE ONLY DIAL IN. IF DIAL OUT FROM AN
* APPLICATION IS REQUIRED, PATH MACROS MUST BE USED. CONSULT
* THE APPROPRIATE VTAM INSTALLATION REFERENCE MANUAL.
*****************************************************************
VSWITCH VBUILD TYPE=SWNET
*
VPU1 PU ADDR=13, COULD BE ANYTHING (NOT USED)
IDBLK=017, XID PARM, NOTE 4
IDNUM=200c1, XID PARM, NOTE 4
MAXOUT=7,
MAXDATA=265,
MODETAB=AMODETAB,
DLOGMOD=US327X,
PUTYPE=2,
USSTAB=USS327X
*
VLU1A LU LOCADDR=2,
VLU1B LU LOCADDR=3
*
VPU2 PU ADDR=13, COULD BE ANYTHING (NOT USED)
IDBLK=017, XID PARM, NOTE 4
IDNUM=200c2, XID PARM, NOTE 4
MAXOUT=7,
MAXDATA=265,
MODETAB=AMODETAB,
DLOGMOD=US327X,
PUTYPE=2,
USSTAB=USS327X
*
VLU2A LU LOCADDR=2,
VLU2B LU LOCADDR=3
*
VPU3 PU ADDR=13, COULD BE ANYTHING (NOT USED)
IDBLK=017, XID PARM, NOTE 4
IDNUM=200c3, XID PARM, NOTE 4
MAXOUT=7,
MAXDATA=265,
MODETAB=AMODETAB,
DLOGMOD=US327X,
PUTYPE=2,
USSTAB=USS327X
*
VLU3A LU LOCADDR=2,
VLU3B LU LOCADDR=3
*
In these sample definitions:
|
|