|
|
This chapter describes Cisco's implementation of SDLC to LLC2 Media Translation, also known as SDLLC. The topics covered in this chapter include:
For information on Fast Sequenced Transport (FST) and SNA LU local address prioritization through source-route bridging, refer to the "Configuring Source-Route Bridging" chapter in this manual.
SDLLC is Cisco's term for media translation between IBM's Synchronous Data Link Control (SDLC) data link protocol for serial lines and the IEEE Logical Link Control (LLC) Type 2 data link protocol used over Token Ring networks. The media conversion occurs between Token Ring and serial lines. The protocol conversion occurs between LLC Type 2 protocol used over Token Rings and the SDLC protocol used by IBM machines in an SNA network over serial lines. Any router that supports bridging can support the translation between SDLC on serial links and LLC2 on Token Rings using SDLLC.
The basic function of SDLLC is to consolidate the traditionally disparate SNA/SDLC networks into a LAN-based, multiprotocol, multimedia backbone network.
Using the SDLLC feature, Cisco routers terminate SDLC sessions, translate SDLC to LLC Type 2 protocol, and then forward the LLC Type 2 traffic through RSRB (Remote Source Route Bridging) over a point-to-point or IP network. Since a router-based IP network can use arbitrary media, such as FDDI, Frame Relay, X.25, and leased lines, Cisco supports SDLLC over all such media through IP encapsulation.
SDLLC does not apply to SNA subarea networks, for example front-end processor to front-end processor (FEP to FEP). SDLLC can be used with Token Ring interface coupler (TIC)-attached host connectivity devices such as IBM's 3172 Interconect Controller and 3174 Establishment Controller. Moreover, SDLLC is not limited to mainframe connectivity. IBM midrange computers, such as the AS/400, can be attached directly to Token Ring or Ethernet, while its controllers, such as the 5394, can only be SDLC attached. By using SDLLC, you can avoid or delay upgrading from the IBM 5394 to the 5494. The same applies to the 3274 to 3174 upgrade.
A major difference between SDLLC and SDLC Serial Tunneling (STUN) is that in SDLLC, the Cisco router acts as an SDLC station, while in STUN, the Cisco router merely passes SDLC frames between two SDLC devices. Performance tuning of SDLC and LLC 2 protocols applies only to SDLLC.
The sections that follow provide tips for tuning SDLLC to provide maximum performance. These tips include the following:
In some situations, you may discover that default settings for LLC2 and SDLC configurations are not acceptable. In such a case, you can configure LLC2 and SDLC for optimal use. The LLC2 commands and how you use them are described in the "LLC2 and SDLC Link-Level Support" chapter of this manual. The "Configuring Serial Tunneling and SDLC Transport" chapter of this manual describes the SDLC commands and how to use them to optimize performance.
You can significantly improve network performance by carefully using the LLC2 commands described in the "LLC2 and SDLC Link-Level Support" chapter of this manual. Table 25-1 shows alternative parameters you can consider when tuning LLC2 performance.
| Parameter | Alternate value | Description |
|---|---|---|
| ack-delay-time | 50-100 | The amount of time the router will wait before acknowledging frames. In 9.0, the default is 3200, which may be too long. |
| ack-max | Experiment with different values | Number of frames the router will accept before acknowledging frames. SNA and NetBIOS applications use different values (NetBIOS = 1, SNA > 1). Fine- tuning this number to different environments may improve overall performance. |
You can significantly improve network performance by carefully using the commands described in the "Configuring Serial Tunneling and SDLC Transport" chapter of this manual to tune the SDLC side of your network. Table 25-2 shows alternative parameters you can consider when tuning the SDLC performance.
| Parameter | Alternate value | Reason |
|---|---|---|
| fair-poll-timer | 2000 | To help ensure that output, once begun, will complete before polling resumes. |
| local-window (k) | 1 | Prior to NCP V5R4, the input window size has a max value of 1. Sending more results in traffic that must be resent. V5R4+ uses a value of 2. |
| t1-timer | 4000 | Add up link transit times in the network for a packet size of 521. |
The following suggestions might help improve end-user response time and overall performance:
Figure 25-1 illustrates a simple configuration of a Front-End Processor (37x5) on a Token Ring and a cluster controller (3x74) on a serial line communicating with each other through a router containing SDLLC software. The two IBM end nodes do not know that their partners are on different media using a different protocol; that is, the 37x5 thinks that the 3x74 it is communicating to is on a Token Ring, and the 3x74 thinks that the 37x5 it is communicating to is on a serial line.
A complete LLC2 session is maintained between the IBM Token Ring node and the router. The LLC2 session terminates at the router. Similarly, a complete SDLC session is maintained between the router and the SDLC station. The SDLC session also terminates at the router. The initial release of SDLLC supported in software release 9.0 required the SDLC station on the serial line to be a secondary node of an SDLC session (such as a 3x74 controller). In software release 9.1 and later, the SDLC station on the serial line can be a primary node (such as 37xx front end processor). End nodes on the Token Rings must be configured to be the primary node, and end nodes on the serial links must be configured as secondary nodes.
The two end IBM nodes need not be directly connected through their respective media to each other through a router, but could be separated by a wide area backbone network, as shown in Figure 25-2. Remote source-route bridging (RSRB) would be used to transport packets between Router A and Router B, and Router B performs all conversion between the Token Ring and serial media. This configuration also illustrates that only the router attached to the serial line (Router B) needs to be configured for SDLLC. Both Router A and Router B would be configured for normal remote source-route bridging. Support for multiple serial lines is provided, limited only by the router hardware used to attach to the serial devices. Only routers directly attached to the SDLC devices need to be configured with SDLLC commands. However, both routers--A and B--must be running software release 9.0 or later.
Because the IBM node on the Token Ring thinks it is talking to its partner also on a Token Ring, every station attached to a serial line is assigned a virtual Token Ring address (VTRA). The virtual Token Ring addresses, like real Token Ring addresses, must be unique across the network. In normal SNA networks, even real Token Ring devices have locally administered addresses, so the system administrators are well versed in address assignments.
In addition to providing a VTRA, a virtual ring number (SDLLC virtual ring number) must be provided, because this virtual Token Ring station, which is actually the serial station, appears as though it is connected to a virtual ring. The SDLLC virtual ring number is different from virtual ring group numbers that are used by remote source-route and multiport bridging.
The IBM node on the Token Ring must be aware of the virtual token address of the serial station, because it will be a part of its configuration. The VTRA and the SDLLC virtual ring number are part of the SDLLC configuration on the Cisco router. When the IBM node on the Token Ring sends out explorer packets for host-initiated connections with the VRTA as its destination address in the MAC header, the router configured with the VTRA intercepts the frame, fills in both the SDLLC virtual ring number and the bridge number in the Routing Information Field (RIF), then sends the response back to the IBM Token Ring node.
There is also a mismatch in the frame sizes supported by the two media. IBM nodes on Token Ring media normally use frame sizes greater than 1K, whereas IBM nodes on serial lines normally limit frame sizes to 265 or 521 bytes. To reduce traffic on backbone networks and provide better performance, nodes on Token Rings should send as large a frame as possible. The router would then segment the frames into multiple data frames and forward them to the SDLC station. No assembly or fragmentation of frames is done when they are forwarded from the SDLC station.
When using SDLLC media translation for nonlocally terminated sessions, you can choose any remote source-route bridging (RSRB) encapsulation between the routers that connect the two IBM end nodes. For locally terminated SDLLC sessions (and also locally terminated LLC2 sessions), you must use TCP/IP encapsulation for RSRB.
With SDLLC Media Translation, the router attached to the SDLC-speaking station terminates the LLC2 session and translates it into the SDLC session. Figure 25-2 is an example of this network configuration.
Follow these steps to configure SDLLC:
Step 1: Ensure that source-route bridging is enabled on your router/bridge. (This topic is covered in the "Configuring Source-Route Bridging" chapter of this manual.)
Step 2: Determine the serial interfaces that you are going to attach to your SDLC-speaking devices and configure them for SDLC.
Step 3: Configure these same interfaces for SDLLC with the sdllc traddr command.
Step 4: Specify any optional sdllc commands for the interface.
Remember the following when configuring SDLLC:
The following required commands apply only to situations where SDLC is enabled on an interface to support SDLLC Media Translation. All of the commands are serial-interface specific.
sdllc traddr xxxx.xxxx.xx00 lr bn trThe sdllc traddr command enables the use of SDLLC Media Translation on this serial interface. The address specified is a MAC address to be assigned to the serial station. The no version of this command disables SDLLC Media Translation on the interface.
Every control unit (3x74) hooked off the serial line will require a virtual Token Ring MAC address (VTRA).This usually is assigned by the system administrator as a locally administered address (unique across the network).
The last byte, that is, the last two hex digits of the address must be 00. This last byte will contain the SDLC address of the station on the serial link to help support multipoint configurations and debugging of problems. This is shown in the example that follows.
The variables lr, bn, and tr represent the SDLLC virtual ring number, bridge number, and target ring number, respectively, that you assign to the interface. In design, the serial interface appears to be a ring, lr, on a source-route bridged network, and ties in through the bridge, bn, to the virtual ring-group, tr. This provides access to other, real rings, through remote source-route bridging source-bridge remote-peer commands. Note that SDLLC can be configured on a router containing no Token Ring interface cards.
The sdllc traddr command automatically turns on the LLC2 process with default values. To change any of the LLC2 parameters (described in the "LLC2 and SDLC Link-Level Support" chapter of this manual) specify their values on the serial interface that is being enabled for SDLLC. This is done on the serial interface, even though LLC2 does not technically run on the serial interface, but on the SDLLC virtual ring associated with the serial interface. LLC2 commands can be configured after specifying the sdllc traddr command. Some examples follow.
When you enable SDLLC Media Translation by specifying the sdllc traddr command on a serial interface, you must specify a VTRA for each serial station attached to the serial line. The last two hexadecimal digits (that is, the last byte) of the VTRA must be 00. The router uses this byte to represent the SDLC address of a station on the serial link. That is, addresses in the range xxxx.xxxx.xx00 to xxxx.xxxx.xxFF are served for use by the router. It is very important that you adhere to this addressing requirement. If you do not, there may be a conflict between the VTRA and the addresses reserved by the router for the SDLC link.
In the following example, a host wants to communicate with two 3174s that its front-end processor (FEP) sees as hosts on a Token Ring network. However, these are in fact SDLC devices c1 and c2 that are connected via a serial link through a router. (See Figure 25-2.)
If router A were the sole router in this configuration, you could configure it as follows to support SDLLC. Note that 1000.5a7d.8123 is the address of the 37x5 in Figure 25-2.
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.1.1 255.255.255.0 source-bridge 1 1 100 ! interface serial 0 encapsulation sdlc-primary sdllc traddr 0110.2222.3300 8 1 100 sdllc partner 1000.5a7d.8123 c1 sdllc xid c1 1720061
These commands configure router A so that the FEP sees SDLC device c1 at MAC address 0110.2222.33c1 and so that the RIF from the REP to the devices would appear as follows:
ring 1--bridge 1--ring 100--bridge 1--ring 8In the configuration shown in Figure 25-2, you could configure routers A, B, and C as follows:
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 8 1 100 sdllc partner 1000.5a7d.8123 c2 sdllc xid c2 17200c2
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 sdllc xid c3 17200c3
There are three optional SDLLC serial interface commands. Each is described in this section.
The sdllc sdlc-largest-frame command indicates the largest information frame (I-frame) size that can be sent or received by the SDLC station at address address. The following is the command syntax:
sdllc sdlc-largest-frame address valueMost SDLC devices are limited to 265 bytes. The default value for this is 265. This default behavior can be retrieved by specifying the no version of the command. I-frames received from the Token Ring station that are larger than this will be properly fragmented.
The sdllc ring-largest-frame command indicates the largest I-frame size that can be sent or received from the LLC2 primary station. The following is the command syntax:
sdllc ring-largest-frame valueThe possible values for this are the same as are possible for the largest-frame parameter of the source-bridge remote-peer command. The default value is 516. This default behavior can be retrieved by specifying the no version of the command. Refer to "Performance Tuning," earlier in this chapter for information on improving performance.
SDLLC supports two connection modes:
To support device-initiated connections for SDLLC, you must specify the sdllc partner command. This is an interface subcommand that must be specified for the serial line that is attached to the serial line device.
sdllc partner mac-address sdlc-addressBoth the MAC address of the Token Ring host and the SDLC serial line address are required to initiate connections with the Token Ring host. The argument mac-address is the 48-bit MAC address of the Token Ring host. It is written as a dotted triple of four-digit hexadecimal numbers. The sdlc-address argument is the SDLC address of the serial device that will communicate with the Token Ring host. These two devices talk to each other through the Cisco router.
Although the device is said to initiate connections, the router actually initiates connections with the Token Ring host on behalf of the serial device. As part of Cisco's SDLLC implementation, the serial device "thinks" that it is communicating with a host also on a serial line. It is actually the router that does all the frame and protocol conversions between serial and Token Ring devices.
There are two conditions under which a router will attempt to initiate a connection to a host on behalf of a serial device:
The router will continue trying once a minute to initiate a connection whenever one of these two conditions is met, until the host responds to its requests. When you no longer want the router to initiate connections with a host, use the no sdllc partner command.
The sdllc xid subcommand allows you to specify an XID value to be associated with the SDLC station at address address. This value is used to reply to XIDs received on the Token Ring (LLC2) side of the connection. XID requests and responses are usually exchanged before sessions are started.
Be sure that the XID configured on the router matches the IDBLK and IDNUM parameters configured on the host. The XID response to an XID request from the Token Ring host will contain the information you configured in the sdllc xid subcommand. The host will check the XID response it receives with the IDBLK and IDNUM parameters (that is configured in the VTAM). If they match, the Token Ring host will initiate a session with the router. If they do not match, the host will not initiate a session with the router. The XID must be four bytes (eight digits) in length, and is specified with hexadecimal digits.
The following is the command syntax:
sdllc xid address xxxxxxxxThe no version of this command disables XID processing for this address.
SDLC and LLC2 sessions that are part of SDLLC can be locally acknowledged, or terminated. Software release 9.1 provides a great deal of flexibility and allows both SDLC and LLC2 to be locally acknowledged as shown in Figure 25-3. The benefits of local acknowledgment include no timeouts and less traffic, which results in more bandwidth on the backbone.
As shown in Figure 25-3, the SDLC session terminates at the router to which the serial device is attached, the LLC2 session terminates at the router to which the Token Ring device is attached, and the two routers maintain a TCP session across the WAN.
To activate Local Acknowledgment for SDLLC sessions, use the following global configuration command:
source-bridge sdllc-local-ackThis command must be issued only on the router with the serial interfaces(s). Once the command is issued, all SDLLC sessions between the two routers will be locally acknowledged. You cannot selectively choose which SDLLC sessions are to be locally acknowledged and which are not.
The configuration parameters that follow apply to the side of the router that supports the SDLC connections.
The following configuration parameters apply to the side of the router that supports the LLC2 connections:
An example configuration for the network shown in Figure 25-2 follows. It includes the router configurations for Cisco A, Cisco B, and Cisco C. In this configuration, local acknowledgment is enabled for Cisco B, which means that the LLC session terminates at Cisco A. However, the LLC2 session between Cisco A and Cisco C is not locally acknowledged and terminates at Cisco C.
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.0b00 7 1 100 sdllc partner 1000.5a7d.8123 c1 sdllc xid c1 017200c1 ! interface serial 1 encapsulation sdlc-primary sdlc address c2 sdllc traddr 0110.2222.3200 8 1 100 sdllc partner 1000.5a7d.8123 c2 sdllc xid c2 017200c2
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 sdllc xid c3 017200c3
The sample system generation (sysgen) parameters in this section show typical NCP and VTAM values that correspond with the Cisco A, Cisco B, and Cisco C router configurations shown earlier in this chapter in Figure 25-2.
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=400001220001, 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=20001, 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=20002, 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=20003, XID PARM, NOTE 4 MAXOUT=7, MAXDATA=265, MODETAB=AMODETAB, DLOGMOD=US327X, PUTYPE=2, USSTAB=USS327X * VLU3A LU LOCADDR=2, VLU3B LU LOCADDR=3 *
NOTE 1: REMOTTO is the NCP's T1 timer for remote token rings. All SDLLC connections use RIF information and therefore look like remote Token Ring devices. The default is 2.5 seconds, which is adequate for most situations; however, when slow speed links are used this parameter should be reviewed to ensure enough time for link-level acknowledgements.
NOTE 2: The LOCADD parameter defines the locally administered address of the TIC in the NCP. The Cisco routers, configured for SDLLC, will insert this address as the 802.5 Destination Address field in TEST and XID frames to establish connectivity and then in data frames during the session. The sdllc partner command defines this connection in the Cisco routers. Each SDLC control unit is defined with an sdllc partner command.
NOTE 3: The AUTOGEN parameter specifies the number of LINE and PU pairs that are automatically generated by NDF (Network Definition Facility). Each SDLLC attached controller requires a LINE and PU definition in the ELCTYPE LOGICAL group. These represent control block space in the NCP simulating switched line as described earlier.
NOTE 4: The IDBLK and IDNUM parameters in VTAM are used to identify incoming connection requests. IDBLK is typically unique for each type of IBM device. IDNUM is any five hex digit combination. The Cisco routers configured for SDLLC must associate an IDBLK/IDNUM combination with a controller by using the sdllc xid command. During activation, an XID will be sent to the NCP containing the specific IDBLK/IDNUM. NCP will send these values to VTAM in an SNA command called REQCONT. VTAM will search its switched major nodes to find a match. If found, VTAM will establish sessions with the device by sending activation commands (ACTPU, ACTLUs).
This section describes the EXEC commands you use to monitor the state of SDLLC.
show llc2 The show llc2 command shows the state of the LLC2 connections associated with SDLLC.
The "LLC2 and SDLC Link-Level Support" chapter of this manual describes the output of this command. Look for the LLC2 connections that correspond to the MAC addresses you assigned to the SDLLC interfaces with the sdllc traddr command.
When local acknowledgment is enabled, the show llc2 command shows the state of any LLC2 sessions.
The command show local-ack shows the current state of any current Local Acknowledgment for both LLC2 and SDLLC connections, as well as any configured pass-through rings.
show local-ackIn this example, the first two lines of the show local-ack command state that there is a Local Acknowledgment session for LLC2 between two Token Ring devices. The device on the local ring has a MAC address of 1000.5A59.04F9 with a SAP of 04. The remote device has a MAC address of 4000.2222.4444 with a SAP of 04. The state of the Local Acknowledgment session for LLC2 is connected.
The Passthrough Rings display is independent of the rest of the show local-ack command. The Passthrough Rings display indicates that there are two rings, 4 and 7, configured for Passthrough. This means that stations on these rings will not have their sessions locally acknowledged but will instead have their acknowledgments end-to-end.
router# show local-ack
local 1000.5a59.04f9, lsap 04, remote 4000.2222.4444, dsap 04
llc2 = 1798136, local ack state = connected
Passthrough Rings: 4 7
Table 25-3 describes the fields shown in the preceding example.
| Field | Description |
|---|---|
| Local | Indicates the MAC address of the local Token Ring station with which the router has the LLC2 session. |
| Lsap | The local SAP (service access point) value of the Token Ring station with which the router has the LLC2 session. |
| Remote | The MAC address of the remote Token Ring station on whose behalf the router is providing acknowledgments. The remote Token Ring station is separated from the router via the TCP backbone. |
| Dsap | The destination SAP value of the remote Token Ring station on whose behalf the router is providing acknowledgments. |
| LLC2 | A pointer to an internal data structure used by the manufacturer for debugging. |
| Local ack state: | Any of: |
| disconnected | No session between the two end hosts. |
| connected | Full data transfer possible between the two. |
| awaiting connect | This router is waiting for the other end to confirm a session establishment with the remote host. |
This command shows the SDLLC statistics for SDLLC configured interfaces. An example of output follows.
show interface serial unit
Serial 0 is up, line protocol is up
Hardware is MCI Serial
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation SDLC-PRIMARY, loopback not set
Timers (msec): poll pause 100 fair poll 500. Poll limit 1
[T1 3000, N1 12016, N2 20, K 7] timer: 56608 Last polled device: none
SDLLC [ma: 0000.0C01.14--, ring: 7 bridge: 1, target ring: 10
largest token ring frame 2052]
SDLC addr C1 state is CONNECT
VS 6, VR 3, RCNT 0, Remote VR 6, Current retransmit count 0
Hold queue: 0/12 IFRAMEs 77/22 RNRs 0/0 SNRMs 1/0 DISCs 0/0
Poll: clear, Poll count: 0, chain: p: C1 n: C1
SDLLC [largest SDLC frame: 265, XID: disabled]
Last input 00:00:02, output 00:00:01, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 517 bits/sec, 30 packets/sec
Five minute output rate 672 bits/sec, 20 packets/sec
357 packets input, 28382 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
926 packets output, 77274 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
2 carrier transitions
Most of this output is generic to all SDLC-encapsulated interfaces and is described in the "LLC2 and SDLC Link-Level Support" chapter of this manual. Table 25-4 shows the parameters specific to SDLLC.
| Parameter | Description |
|---|---|
| SDLLC ma | Lists the MAC address configured for this interface. The last byte is shown as "--" to indicate that it is filled in with the SDLC address of the connection. |
| ring, bridge, target ring | Lists the parameters as configured by the sdllc traddr command |
| largest token ring frame | Shows the largest Token Ring frame that is accepted on the LLC2 side of the connection |
| largest SDLC frame | Shows the largest SDLC frame that is accepted and will be generated on the SDLC side of the connection |
| XID | Enabled or disabled: Shows whether XID processing is enabled on the SDLC side of the connection. If enabled, it will show the XID value for this address. |
This command shows state transition information on SDLLC Media Translation. This information is primarily useful to Cisco support and development staff. The debugging output can be disabled with the undebug sdllc command.
This command shows state transition information of any current local acknowledgment for both LLC2 and SDLC connections. This information is primarily useful to Cisco support and development staff. The debugging output can be disabled with the undebug local-ack command.
Following is an alphabetical list of the global configuration commands for SDLLC.
[no] source-bridge sdllc-local-ack
Activate Local Acknowledgment for SDLLC sessions. Must be issued on the router connected to the serial line.
Following is an alphabetical list of the SDLLC interface subcommands that specify parameters for interfaces configured for SDLLC Media Translation. These commands must follow an interface command.
[no] sdllc partner mac-address sdlc-address
Sets up a device-initiated connection for the serial line that is attached to the serial line device. Both the MAC address of the Token Ring host and the SDLC serial line address are required to initiate connections with the Token Ring host. The argument mac-address is the 48-bit MAC address of the Token Ring host. It is written as a dotted triple of four-digit hexadecimal numbers. The sdlc-address argument is the SDLC address of the serial device that will communicate with the Token Ring host. These two devices talk to each other through the router.
[no] sdllc ring-largest-frame value
Indicates the largest I-frame size that can be sent or received by the LLC2 side of the SDLLC connection. The possible values for this are the same as are possible for the largest-frame parameter of the source-bridge remote-peer command. The default value is 516 bytes.
[no] sdllc sdlc-largest-frame address value
Indicates the largest I-frame size that can be sent or received by the SDLC station at address address. The variable value is the size in bytes; the default is 265 bytes.
[no] sdllc traddr xxxx.xxxx.xx00 lr bn tr
Enables the use of SDLLC on a serial interface. The address is a MAC address to be assigned to the serial interface. The variables lr, bn, and tr represent the SDLLC virtual ring number, bridge number, and target ring number, respectively, that you assign to the interface.
[no] sdllc xid address xxxxxxxx
Specifies an XID value to be associated with the SDLC station at address address. This value is used to reply to XIDs received on the Token Ring (LLC2) side of the connection. The default is not to support XIDs. The XID must by four bytes (eight digits) in length, and is specified with hexadecimal digits.
|
|