|
|
This chapter describes Cisco's Serial Tunneling (STUN) and SDLC Transport implementations. The following topics are included in this chapter:
This chapter also provides STUN configuration examples and describes how to monitor and debug STUN. Command summaries are included at the end of the chapter.
For a description of SNA terminology refer to the following IBM documents:
IBM Corporation, Synchronous Data Link Control-Concepts, GA27-3073.
IBM Corporation, Systems Network Architecture-Technical Overview, GC30-3073
IBM Corporation, Systems Network Architecture-Session between Logical Units, GC20-1868
The Cisco Serial Tunnel (STUN) function allows two devices using SDLC- or HDLC-compliant protocols that are normally connected by a direct serial link, to be connected through one or more Cisco routers.
The SDLC Transport function, which is a variation of STUN, allows sessions that are using SDLC protocols and TCP/IP encapsulation to be locally terminated. SDLC Transport replaces proxy polling, a method used in prior releases to limit traffic transmitted across a network backbone.
By replacing direct serial links with routers, serial frames can be propagated over arbitrary media and topologies to another Cisco router with a STUN link to an appropriate end point. The intervening network is not restricted to STUN traffic, but rather, is multiprotocol. For example, instead of running parallel backbones for DECnet and SNA/SDLC traffic, this traffic now can be integrated into an enterprise backbone network.
As another example, using the SDLC protocol, STUN allows networks with IBM mainframes and communications controllers to share data using Cisco routers and existing network links. As an SDLC function, STUN fully supports the IBM Systems Network Architecture (SNA), and allows IBM Synchronous Data Link Control (SDLC) frames to be transmitted across the network media and and/or shared serial links. Figure 1-1 illustrates a typical network configuration with and without SDLC serial tunneling.
The software encapsulates SDLC frame traffic into IP packets and routes them over any of the IP-supported network media--serial, FDDI, Ethernet, and Token Ring, X.25, SMDS, and T1/T3--using TCP/IP encapsulation. Because TCP/IP encapsulation is used, you can use any of the Cisco routing protocols to route the packets.
STUN copies frames to destinations based on address, but does not modify the frames in any way or participate in SDLC windowing or retransmission; these functions are left to the communicating hosts. However, SDLC Transport does participate in SDLC windowing and retransmission through local termination of the SDLC session.
SDLC was designed to ensure reliable data transmission across serial media having minimal or predictable time delays. With the advent of STUN and wide area network (WAN) backbones, serial links now can be separated by wide, geographic distances spanning countries and continents. As a result, these serial links have time delays that are longer than SDLC allows for bidirectional communication between hosts. The SDLC Transport in router/bridges supporting STUN addresses the problems of unpredictable time delays, multiple retransmissions, or loss of sessions.
The STUN function also provides for configuration of redundant links to provide transport paths in the event part of the network goes down.
Proxy polling is supported for compatability with prior software releases; however, the functions previously implemented in proxy polling now are more fully supported by the SDLC Local Acknowledgment function of STUN with TCP/IP encapsulation.
The STUN software provides several methods by which devices using ISO 3309-compliant protocols can exchange data via links connected to one or more routers.
SDLC serial tunneling (STUN) transports SDLC frames across arbitrary, intermediate network media unchanged, thereby expecting the host to take care of SDLC windowing and retransmission functions. In this manner SDLC STUN acts like a multidrop or point-to-point serial line. SDLC frames can be encapsulated in either a TCP/IP encapsulation or an HDLC encapsulation.
Non-SDLC STUN transports arbitrary ISO 3309-compliant frames (such as HDLC) across arbitrary, intermediate network media unchanged. Similar to SDLC STUN, these arbitrary frames can be encapsulated using the TCP/IP encapsulation over any IP network media or HDLC serial encapsulation.
When using SDLC STUN, you can decrease traffic that flows across the backbone network and increase session reliability by optionally configuring local termination, using the Local Acknowledgment feature. When Local Acknowledgment is enabled, you also can define priorities based on the local LU address, enabling one session to have precedence over another.
The software also supports configuration of redundant links and provides commands to monitor and debug the STUN.
The following sections outline the steps you must take to configure your router for these features. These are followed by sections that describe the tasks and provide configuration examples, and the commands to maintain the links. An alphabetically arranged summary of the configuration commands also is provided at the end of the chapter.
Follow these steps to configure the SDLC serial tunneling function:
Step 1: Enable STUN and define the transport peers using the stun peer-name command.
Step 2: Specify the SDLC transport protocol using the stun protocol-group command and the sdlc keyword.
The SDLC transport mechanism uses TCP/IP encapsulation and simple serial transport mechanisms. You assign transport peers using IP addresses or serial interface names, and transport groups by assigning group numbers and listing the protocol. Continue with these steps to configure STUN's SDLC transport on the interface:
Step 3: Configure STUN encapsulation on the interface using the encapsulation stun command.
Step 4: Specify the group in which the interface will participate using the stun group command. This step and step 3 together assign the STUN protocol to be used.
Step 5: Define how the frames will be forwarded using the stun route command. An option to this command provides local termination using the Local Acknowledgment function.
Step 6: Configure transport-specific features such as local LU address prioritization or SDLC address prioritization, if needed.
Follow these steps to configure serial tunneling:
Step 1: Enable STUN and define the transport peers using the stun peer-name command.
Step 2: Define the protocol to be used. You can choose from predefined protocols, or define your own protocol. (If you define your own protocol, this must be done before step 1 using the stun schema command.)
Step 3: Assign the predefined or new protocols to a group using the stun protocol-group command.
The non-SDLC transport mechanism uses TCP/IP encapsulation and simple serial transport mechanisms. You assign transport peers using IP addresses or serial interface names, and transport groups by assigning group numbers and listing the protocol. Continue with these steps to configure STUN on the interface:
Step 4: Configure STUN encapsulation on the interface using the encapsulation stun command.
Step 5: Specify the group in which the interface will participate using the stun group command. This step and step 4 together assign the STUN protocol to be used.
Step 6: Define how the frames will be forwarded using the stun route command.
Keep the following caveats in mind when configuring STUN:
Use the stun peer-name global configuration command to enable the STUN function. The command syntax follows.
stun peer-name ip-addressEnter the IP address by which this STUN peer is known to other STUN peers that are using the TCP transport for the argument ip-address. (Even if you do not use the TCP transport, you must issue this command to define a peer name.)
Use the no stun peer-name command with the appropriate IP address to disable the STUN function.
This command assigns IP address 131.108.254.6 as the STUN peer:
stun peer-name 131.108.254.6
Each STUN interface is placed in a group that defines the ISO 3309-compliant framed protocol running on that link. Use the stun protocol-group global configuration command to define the group number and protocol. The command has this syntax:
stun protocol-group group-number protocol-keywordThe stun protocol-group command associates group numbers with protocol names. The group-number argument can be any number you select between 1 and 255. There are three predefined STUN protocols: basic, SDLC, and SDLC transmission group. The protocols are specified by supplying the keyword basic, sdlc, or sdlc-tg for the protocol-keyword argument. You also can define your own STUN protocol. See the section "Defining Your Own STUN Protocols" later in this chapter.
If you specify the keyword sdlc in the stun protocol-group command, you cannot specify the stun route all command on that interface.
Use the no stun protocol-group command with the appropriate group number and protocol to remove an interface from the group.
The SDLC serial tunneling protocol is used for placing the routers in the midst of either point-to-point or multipoint (multidrop) SDLC links. Currently, only full-duplex links are supported. An example of how to set up the SDLC STUN protocol follows.
This example command specifies that group 7 use the SDLC STUN protocol:
stun protocol-group 7 sdlc
The basic STUN protocol is unconcerned with details of serial protocol addressing and is used when addressing is unimportant. Use this when your goal with STUN is to replace one or more sets of point-to-point (not multidrop) serial links by using a protocol other than SDLC. An example of how to set up the basic STUN protocol follows.
This command specifies that group 5 use the basic protocol:
stun protocol-group 5 basic
To enable and configure the STUN function on a particular serial interface, use the interface subcommand. The command has this syntax:
encapsulation stunThis command must be specified. It is not possible to further configure the interface without first specifying this command.
These commands enable interface serial 0 for STUN:
interface serial0 encapsulation stun
Each STUN-enabled interface on a router must be placed in a previously defined STUN group. Packets will only travel between STUN-enabled interfaces that are in the same group. Use this interface subcommand to do this:
stun group group-numberThe argument group-number is a number that you assign and that must be a decimal integer between 1 and 255 (inclusive).
These commands place serial interface 2 in STUN group 1, which is defined to run the SDLC transport:
stun protocol-group 1 sdlc ! interface serial 2 encapsulation stun stun group 1
To define how frames will be forwarded on the interface, use one of the following variations of the stun route interface subcommand:
stun route all tcp ip-addressUse the command forms with the all keyword when all STUN traffic received on the input interface will be propagated regardless of what address is contained in the serial frame. (These are the only stun route command forms allowed with the basic STUN transport protocol.)
The tcp keyword causes TCP/IP encapsulation to be used to propagate frames that match the entry. TCP/IP encapsulation allows movement of serial frames across arbitrary media types and topologies. This is particularly useful for building shared, multiprotocol enterprise network backbones. Enter the address that identifies the remote STUN peer that is connected to the far serial link for the ip-address argument.
The local-ack keyword specifies that SDLC sessions are locally terminated, as described later. The priority keyword may be specified along with local-ack to enable priority queuing for the SDLC frames. The prioritization feature does add overhead, so be selective in its use.
The interface serial keywords cause the HDLC encapsulation to be used to propagate the serial frame. There must be an appropriately configured router on the other end of the designated serial line. The outgoing serial link still can be used for other kinds of traffic (the frame is not TCP encapsulated). This mode is used when TCP/IP encapsulation is not needed or when higher performance is required. Enter the serial line number connected to the router for the interface-number argument.
Use the command forms with the address keyword to specify how a serial frame that contains a particular address is to be propagated. The address you enter for the address-number argument varies with the protocol type. The argument will accept octal, decimal, or hexadecimal addresses, as appropriate, in the range allowed by the protocol. As an example, SDLC uses hexadecimal digits and has a one-byte address field. The allowable addresses for this protocol must be between 00 and FF, inclusive.
It is possible to use both the all and address keywords for the same input serial interface. When this is done, the address specifications take effect first. If none of these match, the all keyword will be used to propagate the frame.
Use the command form with the direct keyword at the end of the command to indicate that the specified interface is also a direct STUN link, rather than a serial connection to another peer.
The global command stun cos-enable specifies "Class of Service." The syntax of the command is as follows:
stun cos-enableSpecifying cos-enable will force the router to read the contents of the Format Identification 4 (FID4) frames to prioritize traffic. All FEP-to-FEP (Front-End Processor) frames contain priority information. This priority information is encoded in two bits of the FID4 header. The router will read the two bits of the frame if it is an FID4 frame and will decode the priority information. Once decoded, the frames will be placed on the correct priority queue to be sent out on the backbone network. Thus, with this feature, you can prioritize your SNA traffic allowing your important FEP traffic to flow on high-priority queues. Note that this is useful only between FEP-to-FEP (PU4-to-PU4) communications across the non-SNA backbone.
When a PU4 device communicates with a PU2/PU2.1 device, it uses FID2 frames that do not contain COS or priority information. This priority traffic is only for the backbone network that separates the "peers."
Use the priority-list global configuration command to establish queuing priorities based on the address of the serial link on a STUN connection. The full syntax of this command follows.
priority-list list stun queue-keyword address group-number address-numberThe argument list is an arbitrary integer between 1 and 10 that identifies the priority list selected by the user.
The keyword stun indicates that this is a serial tunnel feature.
The argument queue-keyword is a priority queue name, one of high, medium, normal, or low.
The keyword address is used with the two arguments group-number and address-number, which uniquely identify a STUN serial link.
The keyword sdlc indicates that the next byte, sa, represents the secondary SDLC address. The argument sa is a hexadecimal value.
The argument group-number is the group number used in the stun group interface configuration subcommand.
The argument address-number is the address of the serial link. The format of the address number is either a one-byte hex value (for example, C1) for a SDLC link or one that is specified by the stun schema configuration command.
The priority-group interface subcommand is used to assign a priority group to the output interface.
priority-group listThe argument list is the priority list number of the output interface.
Assume that the link between Cisco A and Cisco B is a serial tunnel that uses the simple serial transport mechanism as shown in Figure 1-2.
Device A is to communicate with device C (SDLC address C1) with priority high. Device B is to communicate with device D (SDLC address A7) with normal priority. The router configurations would be as follows:
stun peer-name 1.0.0.1 stun protocol-group 1 sdlc stun protocol-group 2 sdlc ! interface serial 0 no ip address encapsulation stun stun group 1 stun route address C1 interface serial 2 ! interface serial 1 no ip address encapsulation stun stun group 2 stun route address A7 interface serial 2 ! interface serial 2 ip address 1.0.0.1 255.0.0.0 priority-group 1 ! priority-list 1 stun high address 1 C1 priority-list 1 stun low address 2 A7
stun peer-name 1.0.0.2 stun protocol-group 1 sdlc stun protocol-group 2 sdlc ! interface serial 0 no ip address encapsulation stun stun group 1 stun route address C1 interface serial 1 ! interface serial 1 ip address 1.0.0.2 255.0.0.0 priority-group 1 ! interface serial 2 no ip address encapsulation stun stun group 2 stun route address A7 interface serial 1 ! priority-list 1 stun high address 1 C1 priority-list 1 stun low address 2 A7
The priority-group interface subcommand is used to assign a priority group to the input interface. Rather than using priority-group as an output interface subcommand, it is used as an input interface subcommand for STUN. This is because the IP network could be connected to multiple input interfaces of the router.
priority-group listThe argument list is the priority list number of the input interface.
You must use the priority-list command, described in the "Adjusting Interface Characteristics" chapter to assign priorities to the ports as shown in Table 1-1.
| Priority | Port |
|---|---|
| STUN high priority | 1994 |
| STUN medium priority | 1990 |
| STUN normal priority | 1991 |
| STUN low priority | 1992 |
Assume the link between Cisco A and Cisco B is a serial tunnel that uses the TCP/IP encapsulation as shown in Figure 1-3.
Device A is to communicate with device C (SDLC address C1) with priority high. Device B is to communicate with device D (SDLC address A7) with normal priority. The router configuration would be as follows:
stun peer-name 1.0.0.1 stun protocol-group 1 sdlc stun protocol-group 2 sdlc ! interface serial 0 no ip address encapsulation stun stun group 1 stun route address C1 tcp 1.0.0.2 local-ack priority priority-group 1 ! interface serial 1 no ip address encapsulation stun stun group 2 stun route address A7 tcp 1.0.0.2 local-ack priority priority-group 2 ! interface ethernet 0 ip address 1.0.0.1 255.0.0.0 ! interface ethernet 1 ip address 1.0.0.3 255.0.0.0 ! priority-list 1 protocol ip high tcp 1994 priority-list 1 protocol ip medium tcp 1990 priority-list 1 protocol ip normal tcp 1991 priority-list 1 protocol ip low tcp 1992 priority-list 1 stun high address 1 C1 ! priority-list 2 protocol ip high tcp 1994 priority-list 2 protocol ip medium tcp 1990 priority-list 2 protocol ip normal tcp 1991 priority-list 2 protocol ip low tcp 1992 priority-list 2 stun normal address 2 A7 ! hostname ciscoA router igrp network 1.0.0.0
stun peer-name 1.0.0.2 stun protocol-group 1 sdlc stun protocol-group 2 sdlc ! interface serial 0 no ip address encapsulation stun stun group 1 stun route address C1 tcp 1.0.0.1 local-ack priority priority-group 1 ! interface serial 2 no ip address encapsulation stun stun group 2 stun route address A7 tcp 1.0.0.1 local-ack priority priority-group 2 ! interface ethernet 0 ip address 1.0.0.2 255.0.0.0 ! interface ethernet 1 ip address 1.0.0.4 255.0.0.0 ! priority-list 1 protocol ip high tcp 1994 priority-list 1 protocol ip medium tcp 1990 priority-list 1 protocol ip normal tcp 1991 priority-list 1 protocol ip low tcp 1992 priority-list 1 stun high address 1 C1 ! priority-list 2 protocol ip high tcp 1994 priority-list 2 protocol ip medium tcp 1990 priority-list 2 protocol ip normal tcp 1991 priority-list 2 protocol ip low tcp 1992 priority-list 2 stun normal address 2 A7 ! hostname ciscoB router igrp 109 network 1.0.0.0
The Serial Tunneling function and encapsulation protocol selection are described earlier in this chapter. SDLC STUN with TCP/IP encapsulation must be enabled in order to use SDLC Local Acknowledgment.
SDLC connections for STUN can be terminated locally at the router. By locally acknowledging these sessions, you can avoid the delays of the wide area network that can affect normal STUN or STUN with proxy polling. SDLC Local Acknowledgment removes all of the SDLC session keepalives (nonproductive Receiver Ready (RR) exchanges) from the wide area network, resulting in reduced overhead on the IP network.
With SDLC Local Acknowledgment, also known as local termination, the end-to-end connection is composed of three sessions:
These three sessions are concatenated to form a logical end-to-end connection.
Although this feature is part of the STUN feature set, the SDLC Local Acknowledgment capability applies only to SDLC tunneling across TCP/IP networks. The current release of SDLC Local Acknowledgment does not apply to HDLC tunneling or to transfer of SDLC across HDLC serial links. Functionally, it is the SDLC counterpart of the LLC2 Local Acknowledgment feature for Token Ring networks.
The default mode for STUN is straight passthrough of all SDLC connection traffic (including RRs) end-to-end between SNA end devices. To invoke SDLC local termination, the local-ack parameter must be specified on the STUN command that defines the tunnel.
Figure 1-4 illustrates an SDLC session. IBM 1 (for example, a 37x5) using a serial link can communicate with IBM 2 (for example, a 3x74) on a different serial link separated via a wide area backbone network. Frames are transported between Router A and Router B using STUN. However, the SDLC session between IBM 1 and IBM 2 is still end-to-end; that is, every frame generated by IBM 1 traverses the backbone network to IBM 2, and IBM 2, on receipt of the frame, acknowledges it.
With Local Acknowledgment turned on, the SDLC session between the two IBM end nodes is not end-to-end but instead terminates at the two local routers, as shown in Figure 1-5. The SDLC session with IBM 1 ends at Router A, and the SDLC session with IBM 2 ends at Router B. Both Router A and Router B execute the full SDLC protocol as part of SDLC Local Acknowledgment.
With SDLC Local Acknowledgment enabled in both routers, Router A acknowledges frames received from IBM 1. The node IBM 1 treats the acknowledgments it receives as if they are from IBM 2. Similarly, Router B acknowledges frames received from IBM 2. The node IBM 2 treats the acknowledgments it receives as if they are from IBM 1. With local acknowledgment, frames no longer travel the WAN backbone networks to be acknowledged. This means the end machines do not time out, resulting in no loss of sessions.
The advantages of enabling SDLC Local Acknowledgment are as follows:
The default mode for STUN is straight passthrough of all SDLC traffic (including RRs) end-to-end between SNA devices. In order to activate SDLC Local Acknowledgment, the local-ack parameter of the stun route address command must be specified on the STUN command that defines the tunnel.
Local Acknowledgment can only be enabled with TCP remote peers (as opposed to LAN or direct serial-interface remote peers), because the routers need the reliable transmission of TCP to provide the same reliability of the pre-Local Acknowledgment end-to-end connection. Therefore, the direct media encapsulation options for the stun route address command cannot be used.
If the SDLC session between the local host and the router terminates in either router, the other router will be informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two routers reaches 90 percent of its limit, the routers will send Receiver-Not-Ready (RNR) messages to the local hosts until the queue limit is reduced below this limit.
The configuration of the SDLC parameters for the local serial interfaces can affect overall performance. Refer to the "LLC2 and SDLC Link-Level Support" chapter of this manual for more details about fine-tuning your network through the SDLC parameters.
To set up SDLC Local Acknowledgment for a serial tunnel, specify the local-ack keyword of the interface stun route address command.
stun route address address-number tcp ip-address [local-ack] [priority]The stun route address subcommand provides the options local-ack and priority. The keyword local-ack indicates that SDLC sessions destined to a specific STUN peer are to be locally acknowledged. The keyword priority allow prioritization features such as SNA class of services, SNA LU address prioritization, and SDLC address prioritization to function on STUN over TCP/IP encapsulation.
The following example shows a sample configuration for a pair of Cisco routers performing SDLC Local Acknowledgment:
.. stun peer-name 150.136.64.92 stun protocol-group 1 sdlc ... interface Serial 0 no ip address encapsulation stun stun group 1 stun sdlc-role secondary sdlc address C1 stun route address C1 tcp 150.136.64.93 local-ack clockrate 19200 ...
... stun peer-name 150.136.64.93 stun protocol-group 1 sdlc ... interface Serial 0 no ip address encapsulation stun stun group 1 stun sdlc-role primary sdlc address C1 stun route address C1 tcp 150.136.64.92 local-ack clockrate 19200 ...
The show stun command shows the current state of any current Local Acknowledgment connections.
show stunrouter#show stunThis peer: 150.136.64.93*Serial0 (group 1 [sdlc])state l rx_pkts tx_pkts drops pollC1 TCP 150.136.64.92 open * 922 343 0SDLC Local Acknowledgement:*Serial0 (group 1 [sdlc])slack_state conn disc iframe_s iframe_rC1 TCP 150.136.64.92 Active 2 1 918 340dino#
Table 1-2 describes the fields shown in the preceding example.
| Field | Description |
|---|---|
| slack_state | The current state of this locally terminated SDLC session. |
| The normal values for slack_state are: | |
| Active | The locally terminated SDLC session is currently active and able to pass I-Frames between STUN peers. |
| Disconnected | The session is currently disconnected. |
| Other values for the slack_state session are: | |
| AwaitLinkupRequest | An SNRM has been received and a LinkupRequest has been sent to the STUN peer. This side of the session is awaiting a LinkupResponse. |
| AwaitSdlcOpen | A LinkupRequest has been received from the STUN peer and a SNRM has been sent to the SDLC device. This side of the session is awaiting a UA response from the SDLC device. |
| AwaitLinkdownResponse | An RD has been received from the SDLC device and a RequestDisconnectRequest has been sent to the STUN peer. This side is awaiting a LinkdownRequest from the STUN peer. |
| AwaitLinkdownUa | A LinkdownRequest has been received from the STUN peer and a DISC has been sent to the SDLC device. This side is awaiting a UA from the SDLC device. |
| AwaitLinkdownResponse | A DISC has been received from the SDLC device and a LinkdownRequest has been sent to the STUN peer. This side is awaiting a LinkdownResponse from the STUN peer. |
| AwaitDisc | An AbortRequest has been received from the STUN peer and an RD has been sent to the SDLC device. This side is awaiting a DISC from the SDLC device. |
| AwaitAbortResponse | The SDLC session has been lost and an AbortRequest has been sent to the STUN peer. This side is awaiting an AbortResponse from the STUN peer. |
| conn | The number of times this SDLC session has gone through the session initiation sequence (the SNRM/UA exchanges). |
| disc | The number of times this SDLC session has gone through the session termination sequence (the DISC/UA exchanges). |
iframe_s
| The number of I-Frames that have been received from the STUN peer and sent to the SDLC device.
|
iframe_r
| The number of I-Frames that have been received from the SDLC device and sent to the STUN peer.
|
There is one debug command for Local Acknowledgment: debug sdlc-local-ack.
debug sdlc-local-ackThis command displays Local Acknowledgment debugging information that is useful for Cisco staff.
There is a corresponding undebug command that stops the output. There are three levels of debug output, as shown in Table 1-3. The numbers 1, 2, 4, and 7 are bit flags that you can combine in any manner. The default is 7 for all events.
| Debug Command | Meaning |
|---|---|
| debug sdlc-local-ack 1 | Only U-Frame events |
| debug sdlc-local-ack 2 | Only I-Frame events |
| debug sdlc-local-ack 4 | Only S-Frame events |
| debug sdlc-local-ack 7 | All SDLC Local Ack events (default setting) |
SNA Local LU Address Prioritization is specific to IBM SNA connectivity and is used to prioritize SNA traffic on either Serial Tunnel (STUN) or Remote Source-Route Bridging (RSRB).
The SNA Local LU address prioritization feature allows SNA traffic to be prioritized according to the address of the Logical Units (LU) on the FID2 transmission headers. Currently, only dependent LUs are supported. The prioritization takes place on LU-LU traffic between an SNA Node type 5 or Node type 4, and Node type 2.
An example on the use of SNA Local Address Prioritization is shown in Figure 1-6.
The IBM mainframe is channel-attached to a 3745 communications controller that is connected to a 3174 cluster controller via the serial tunnel. Multiple 3270 terminals and printers, each with a unique local LU address, are then attached to the 3174. By applying SNA Local LU Address Prioritization, each LU associated with a terminal or printer can be assigned a priority; that is, certain users can have terminals that have better response time than others, and printers can have lowest priority.
SNA Local LU Address Prioritization works on both the serial tunnel (STUN) and Remote Source-Route Bridging (RSRB). The configuration commands are described in the next section.
Use the locaddr-priority-list global configuration command to establish queuing priorities based on the address of the logical unit. The full syntax of this command follows.
locaddr-priority-list list address-number [sdlc sa]The argument list is an arbitrary integer from 1 through 10 that identifies the LU priority list.
The argument address-number is the value of the LOCADDR= parameter on the LU macro, which is a 1-byte address of the LU in hexadecimal.
The locaddr-priority interface subcommand is used to assign a priority group to an input interface.
locaddr-priority listThe argument list is the priority list number of the input interface.
You must use the priority-list command, described in the "Adjusting Interface Characteristics" chapter of this manual to assign priorities to the ports as shown in Table 1-4.
| Priority | Port |
|---|---|
| STUN high priority | 1994 |
| STUN medium priority | 1990 |
| STUN normal priority | 1991 |
| STUN low priority | 1992 |
The configuration for the network as illustrated in Figure 1-6 would be as follows:
stun peer-name 1.0.0.1 stun protocol-group 1 sdlc ! interface serial 0 no ip address encapsulation stun stun group 1 stun route address C1 tcp 1.0.0.2 local-ack priority clockrate 19200 locaddr-priority 1 ! interface Ethernet 0 ip address 1.0.0.1 255.255.255.0 ! locaddr-priority-list 1 02 high locaddr-priority-list 1 03 high locaddr-priority-list 1 04 medium locaddr-priority-list 1 05 low priority-group 1 ! priority-list 1 protocol ip high tcp 1994 priority-list 1 protocol ip medium tcp 1990 priority-list 1 protocol ip normal tcp 1991 priority-list 1 protocol ip low tcp 1992
stun peer-name 1.0.0.2 stun protocol-group 1 sdlc ! interface serial 0 no ip address encapsulation stun stun group 1 stun route address C1 tcp 1.0.0.1 local-ack priority clockrate 19200 locaddr-priority 1 ! interface Ethernet 0 ip address 1.0.0.2 255.255.255.0 ! locaddr-priority-list 1 02 high locaddr-priority-list 1 03 high locaddr-priority-list 1 04 medium locaddr-priority-list 1 05 low priority-group 1 ! priority-list 1 protocol ip high tcp 1994 priority-list 1 protocol ip medium tcp 1990 priority-list 1 protocol ip normal tcp 1991 priority-list 1 protocol ip low tcp 1992
You can configure multilink SDLC Transmission Groups (TGs) across STUN connections between IBM communications controllers such as IBM 37x5s. Multilink TGs allow you to collapse multiple WAN leased lines into one leased line.
SDLC multilink TGs support provides the following features:
To identify the serial links that are part of a TG, use the following global configuration command:
stun protocol-group group-number sdlc-tgThe argument group-number identifies the TG. STUN connections that are part of the same TG must have the same group number.
STUN connections that are part of a TG must have local acknowledgment enabled. Local acknowledgment keeps SDLC poll traffic off the WAN and reduces store-and-forward delays through the router. It also may minimize the number of NCP timers that expire due to network delay. To enable local acknowledgment, you specify the local-ack keyword in the stun route interface subcommand. Also, these STUN connections must go to the same IP address. This is because SNA TGs are parallel links between the same pair of IBM communications controllers.
The following example configures two routers that support a double-link TG. (See Figure 1-7.) Router A is the SDLC primary router, and Router B is the SDLC secondary router. The IBM1 37x5 is acting as the SDLC secondary 37x5, and the IBM2 37x5 is acting as the SDLC primary 37x5. The comments at the end of the example explain the purpose of each command.
stun peer-name 150.136.112.13 stun remote-peer-keepalive stun protocol-group 91 sdlc-tg stun cos-enable interface serial 1 mtu 4400 hold-queue 150 in no ip address encapsulation stun stun group 91 stun sdlc-role primary sdlc line-speed 56000 sdlc address 01 echo stun route address 1 tcp 150.136.112.10 local-ack priority tcp-queue-max 75 interface serial 2 mtu 4400 hold-queue 150 in no ip address encapsulation stun stun group 91 stun sdlc-role primary sdlc line-speed 56000 sdlc address 02 echo stun route address 2 tcp 150.136.112.10 local-ack priority tcp-queue-max 75
stun peer-name 150.136.112.10 stun remote-peer-keepalive stun protocol-group 91 sdlc-tg stun cos-enable interface serial 1 mtu 4400 hold-queue 150 in no ip address encapsulation stun stun group 91 stun sdlc-role secondary sdlc address 01 echo stun route address 1 tcp 150.136.112.13 local-ack priority tcp-queue-max 75 interface serial 2 mtu 4400 hold-queue 150 in no ip address encapsulation stun stun group 91 stun sdlc-role primary sdlc address 02 echo stun route address 2 tcp 150.136.112.13 local-ack priority tcp-queue-max 75
The following paragraphs explain the use of some of the commands in the previous example.
The stun remote-peer-keepalive global command synchronizes the state machines of the STUN remote peer routers. Routers A and B will exchange keepalive messages where there is no data traffic (I-frames) between NCPs on each SDLC line. NCP end stations are not involved in the keepalive traffic. Keepalives allow routers to detect when their STUN peer has disappeared. This can happen when the WAN connection is lost or if the STUN peer router becomes inoperative.
The stun protocol-group 91 sdlc-tg global command establishes TG 91, and alerts the router that it should route the SDLC broadcast address and perform TG rerouting.
The stun cos-enable global command, in conjunction with the priority keyword in the stun route command, causes SNA network priority traffic to flow at a higher priority than SNA data traffic. All other SNA traffic flows at the same router priority in an attempt to preserve the COS specified by the sending NCP.
The mtu 4400 interface subcommand is used to accommodate the NCP's data MTU of the attached NCP. An MTU of 4400 is the highest recommended router MTU. Therefore, it also is the largest size you should make the NCP's data MTU. Note that the NCP's data MTU may or may not take into account PIU headers. You should consider then when synchronizing the two MTU values. It is recommended that you set the WAN link's MTU to be at least 100 bytes larger than the largest SDLC line's MTU to avoid TCP/IP fragmentation of SDLC frames.
The hold-queue 150 in interface subcommand increases the SDLC link's input queue size from 75 to 150 packets. This parameter should be greater than the value you specify for tcp-queue-max (described below).
The sdlc line-speed 56000 interface subcommand is needed for the SDLC primary router only. It is used to adjust the SDLC poll timer based on the line speed. This speed should be the same as the speed of the line on this interface, regardless of whether the line is DCE or DTE.
The echo keyword in the sdlc address 01 echo interface subcommand treats nonecho and echo SDLC addresses as the same address. This command is valid only for STUN interfaces configured for TGs. The echo keyword is optional for TGs. Primary NCPs send frames with the high-order echo bit off (for example, 0x01), and secondary NCPs send frames with the echo bit on (for example, 0x81). Some versions of NCP do not use echo addressing on TG SDLC links.
The stun route address 1 tcp 150.136.112.10 local-ack priority tcp-queue-max 75 interface subcommand enabled local acknowledgment and TCP encapsulation. Both these options are required to use TGs. You should specify the SDLC address with the echo bit turned off. The SDLC broadcast address 0xFF is routed automatically for TG interfaces. The priority keyword creates multiple TCP sessions for this route and, in conjunction with the stun cos-enable command, prioritizes SNA network priority and router synchronization traffic over SNA data traffic. The tcp-queue-max 75 keyword sets the maximum size of the outbound TCP queue for this SDLC link to 75. The default TCP queue size is 100. The value for hold-queue in must be greater than the value for tcp-queue-max.
This section provides some recommendations that are useful in configuring SDLC multilink Transmission Groups.
The bandwidth of the WAN should be larger than or equal to the aggregate bandwidth of all serial lines to avoid excessive flow control and ensure no degradation in response time. If other protocols also are using the WAN, ensure that the WAN bandwidth is significantly greater than the aggregate SNA serial line bandwidth to ensure that the SNA traffic does not monopolize the WAN.
When you are using a combination of routed TGs and directly connected NCPs TGs, you need to plan the configuration carefully to ensure that SNA sessions do not stop unexpectedly. Assuming that hardware reliability is not an issue, from a software point of view, single-link routed TGs are as reliable as direct NCP-to-NCP single-link TGs.This is true because neither the NCP nor the router can reroute I-frames when a TG has only one link. Additionally, multilink TGs directed between NCPs and multilink TGs through router are equally reliable. Both can perform rerouting.
However, you may run into problems if you have a configuration in which two NCPs are directly connected (via one or more TG links) and one link in the TG is routed. The NCPs will view this as a multilink TG. However, the router views the TG as a single-link TG. A problem can arise in the following situation: Assume that an I-frame is being transmitted from NCP A (connected to router A) to NCP B (connected to router B) and that all SDLC links are currently active. Router A will acknowledge the I-frame sent from NCP A and will send if over the WAN. If, before the I-frame reaches router B, the SDLC link between router B and NCP B goes down, router B will attempt to reroute the I-frame on another link in the TG when it receives the I-frame. However, because this is a single-link TG, there are no other routes, and router B drops the I-frame. NCP B will never receive this I-frame because router A acknowledged its receipt, and NCP A marked it as transmitted and deleted it. NCP B detects a gap in the TG sequence numbers and waits to receive the missing I-frame. It will wait forever for this I-frame, and in the meantime will not send or receive any other frames. This means that NCP B is technically inoperational and that all SNA sessions through NCP B will be lost.
One final design recommendation note concerns a configuration in which one or more lines of an NCP TG are router and one or more lines are directly connected between NCPs. If the network delay associated with one line of an NCP TG is different from the delay of another line in the same NCP TG, the receiving NCP will spend additional time resequencing PIUs.
This section contains configuration examples illustrating use of the commands described in this chapter.
Figure 1-8 depicts a typical IBM network configuration.
The configuration has a 3090 mainframe channel-attached to a 3745 controller. These are connected by SDLC link to 3274 and 3174 cluster controllers.
Figure 1-9 modifies the configuration by placing the routers between the devices connected via SDLC link, thus expanding the network capabilities. The configuration files for connecting the routers to the IBM network follow.
stun peer-name 131.108.10.1 stun protocol-group 1 sdlc ! interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address 7 interface serial 1 stun route address 10 tcp 131.108.8.1 ! interface serial 1 ip address 131.108.62.1 255.255.255.0 ! interface ethernet 0 ip address 131.108.10.1 255.255.255.0 ! hostname ciscoA router igrp 161 network 131.108.0.0
stun peer-name 131.108.8.1 stun protocol-group 1 sdlc ! interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address 10 tcp 131.108.10.1 ! interface ethernet 0 ip address 131.108.8.1 255.255.255.0 ! hostname ciscoB router igrp 161 network 131.108.0.0
stun peer-name 131.108.62.2 stun protocol-group 1 sdlc ! interface serial 0 ip address 131.108.62.2 255.255.255.0 ! interface serial 1 encapsulation stun no ip address no keepalive stun group 1 stun route address 7 interface serial 0 ! hostname ciscoC router igrp 161 network 131.108.0.0
As another example, the previous configuration can be extended by connecting a remote 3745 to another serial interface connected to Router B. All other traffic from the primary node (the 3745 connected to the 3090), other than addresses 7 and 10, should go to this remote 3745. Figure 1-10 illustrates this configuration.
The following configuration changes would need to be made to the serial interface in the router labeled Router B.
interface serial 1 encapsulation stun no ip address no keepalive stun group 1 stun route all tcp 131.108.10.1 !
Serial 0 on Router A now looks like this:
interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address 7 interface serial 1 stun route address 10 tcp 131.108.8.1 stun route all tcp 131.108.8.1 !
Notice in the preceding examples that the same STUN group number is used in all cases. If these numbers differ between the three routers, attempts at communication will be unsuccessful. There are times, however, when having multiple groups can be useful. Such an example is illustrated in Figure 1-11.
In the following configuration, the AS/400 device labeled A wants to communicate with the 3174 device labeled A, as do the AS/400 device labeled B and 3174 device labeled B. Notice that both of the 3174 devices are at SDLC address C1. A first attempt at the configuration files for the routers labeled A and B could be as follows:
stun peer-name 131.108.1.1 stun protocol-group 1 sdlc ! interface ethernet 0 ip address 131.108.1.1 255.255.0.0 ! interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 131.108.1.2 ! interface serial 1 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 131.108.1.2
stun peer-name 131.108.1.2 stun protocol-group 1 sdlc ! interface ethernet 0 ip address 131.108.1.2 255.255.0.0 ! interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 131.108.1.1 ! interface serial 1 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 131.108.1.1 !
A problem occurs when the router labeled A transfers an SDLC frame with address C1 from the AS/400 A device to the router labeled B. There would be no way to determine whether it came from the AS/400 device A and was therefore destined to the 3174 device A, or that it came from the AS/400 device B and was therefore destined to the 3174 device B.
The use of distinct group numbers solves this problem. The next configuration will ensure correct communication, because frames that come in on group 1 links will only go out of group 1 links. The same holds true for frames coming in on group 2, or any other numbered group link. The new configuration follows.
stun peer-name 131.108.1.1 stun protocol-group 1 sdlc stun protocol-group 2 sdlc ! interface ethernet 0 ip address 131.108.1.1 255.255.0.0 ! interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 131.108.1.2 ! interface serial 1 encapsulation stun no ip address no keepalive stun group 2 stun route address C1 tcp 131.108.1.2
stun peer-name 131.108.1.2 stun protocol-group 1 sdlc stun protocol-group 2 sdlc ! interface ethernet 0 ip address 131.108.1.2 255.255.0.0 ! interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 131.108.1.1 ! interface serial 1 encapsulation stun no ip address no keepalive stun group 2 stun route address C1 tcp 131.108.1.1
At times, you may wish to prioritize STUN traffic in your network over that of other protocols. The use of priority output queuing, described in the "Adjusting Interface Characteristics" chapter of this manual, enables this function. STUN uses a special serial line protocol called STUN for the simple serial encapsulation and TCP port 1994 for the TCP encapsulation. Therefore, to fully specify STUN traffic on priority list 4 for high priority, the following configuration is used.
priority-list 4 protocol stun high priority-list 4 protocol ip high tcp 1994
The serial link address prioritization feature allows STUN traffic to be prioritized based on the address of a serial frame.
Figure 1-12 shows device A communicating with device C and device B communicating with device D. With the serial link address prioritization turned on, the user may choose to give A-C a higher priority over B-D across the serial tunnel.
How the serial link address prioritization is configured varies slightly depending on whether the STUN uses the HDLC encapsulation or TCP/IP encapsulation. The first step, however, is always to configure the STUN priority list.
In the sample network shown in Figure 1-13, there are two redundant links between the routers.
However, if you were to specify remote peers on network 1 for the two routers, the redundancy would be in effect only as long as network 1 was available. The following example shows the network configuration.
The configuration for the router labeled A is as follows:
stun peer-name 1.0.0.1 stun protocol-group 1 sdlc interface ethernet 0 ip address 1.0.0.1 255.0.0.0 interface ethernet 1 ip address 2.0.0.1 255.0.0.0 interface ethernet 2 ip address 4.0.0.1 255.0.0.0 interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 1.0.0.2 !
The configuration for the router labeled B is as follows:
stun peer-name 1.0.0.2 stun protocol-group 1 sdlc interface ethernet 0 ip address 1.0.0.2 255.0.0.0 interface ethernet 1 ip address 2.0.0.2 255.0.0.0 interface ethernet 2 ip address 3.0.0.2 255.0.0.0 interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 1.0.0.1 !
In the event that network 1 went down, the access to network 1.0.0.1 from the router labeled ciscoB (and to network 1.0.0.2 from ciscoA) would be lost. Therefore, connectivity would be lost for the 3745 and the 3174 even though a second path exists.
When you configure redundant links, keep the following in mind: ensure that the STUN peer names you choose on each router are the IP addresses of interfaces that are not part of the normal path between the two routers.
In the preceding case, specifying the following configuration would allow connectivity between the 3745 and 3174 in all cases, when either network 1.0.0.0 or network 2.0.0.0 or both were working.
The configuration for the router labeled A is as follows:
stun peer-name 4.0.0.1 stun protocol-group 1 sdlc interface ethernet 0 ip address 1.0.0.1 255.0.0.0 interface ethernet 1 ip address 2.0.0.1 255.0.0.0 interface ethernet 2 ip address 4.0.0.1 255.0.0.0 interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 3.0.0.2 !
The configuration for the router labeled B is as follows:
stun peer-name 3.0.0.2 stun protocol-group 1 sdlc interface ethernet 0 ip address 1.0.0.2 255.0.0.0 interface ethernet 1 ip address 2.0.0.2 255.0.0.0 interface ethernet 2 ip address 3.0.0.2 255.0.0.0 interface serial 0 encapsulation stun no ip address no keepalive stun group 1 stun route address C1 tcp 4.0.0.1 !
There still may be cases where such remote networks do not exist. Consider the network illustrated in Figure 1-14:
In this situation, keep this rule in mind: IP addresses can be specified for serial links that have STUN encapsulation enabled. This remote reference allows connections from remote devices into the router onto this IP address when this SDLC serial interface is up.
Both networks 1.0.0.0 and 2.0.0.0 in the preceding example would be available when the following configuration is used.
Example configuration for the router labeled A:
stun peer-name 4.0.0.1 stun protocol-group 1 sdlc interface ethernet 0 ip address 1.0.0.1 255.0.0.0 interface ethernet 1 ip address 2.0.0.1 255.0.0.0 interface serial 0 encapsulation stun no ip address no keepalive stun group 1 ip address 4.0.0.1 255.0.0.0 stun route address C1 tcp 3.0.0.2 !
Example configuration for the router labeled B:
stun peer-name 3.0.0.2 stun protocol-group 1 sdlc interface ethernet 0 ip address 1.0.0.2 255.0.0.0 interface ethernet 1 ip address 2.0.0.2 255.0.0.0 interface serial 0 encapsulation stun no ip address no keepalive stun group 1 ip address 3.0.0.2 255.0.0.0 stun route address C1 tcp 4.0.0.1
In normal communication between an SDLC primary node and its secondary node, the secondary node is only allowed to send data to the primary node in response to a poll from the primary node. In Figure 1-15, an AS/400 host is attached to a 3174 controller that handles transfers from several attached 3270 terminals.
If one of the 3270-style terminals attached to the 3174 controller wants to initiate a data transfer, (usually the result of a user at the terminal pressing the Enter key), the 3174 device would not be able to immediately transfer the data back to the host AS/400 because the 3174 is the secondary node on the link. Instead, it must hold the data until a poll is received from the AS/400, which is the primary node in this example. Once the poll is received, the data can be transmitted.
The primary host ensures a reasonable response time for its secondary nodes by sending out polls at a rate that is often more than 20 times per second. With two devices sharing a single, dedicated serial line, as in the preceding example, this poses no problem, because the link would be idle without the polls.
In the example illustrated in Figure 1-16, the frequent polls and their replies would constantly travel between the two routers across the shared Ethernet.
Such constant traffic can create bottlenecks and loads that may not be appropriately handled.
The proxy polling feature alleviates the load across the network by allowing the routers to act as proxies for the primary and secondary nodes, thus keeping polling traffic off of the shared links.
With proxy polling enabled, the router labeled A inFigure 1-16 would reply to the AS/400 poll requests as a proxy for the secondary node, thereby keeping the polls and requests off of the shared Ethernet. Similarly, the router labeled B would act as a proxy for the primary node and periodically send polls to the secondary 3174 device, thereby keeping its replies off of the shared cable. Only significant information is passed across the shared Ethernet.
Use these interface subcommands to enable proxy polling:
stun proxy-poll address address modulus modulus {primary|secondary}Enter the address of the device on which to enable proxy polling with the address argument.
Enter the modulus of the link as defined by the MODULUS parameter specified in the line descriptions on your SDLC host with the modulus argument. (This most often will be eight.)
Use the primary or secondary keyword to indicate which role the SDLC device is playing.
Use the command form with the discovery keyword when you do not want to specify the primary and secondary ends and the modulus used on an SDLC link, or when such connections are negotiable.
Use of the discovery keyword is not recommended except where you cannot avoid end hosts that negotiate the status, because proxying will be disabled on the link until session start-up, when the appropriate primary and secondary status, as well as modulus on the link, can be discovered. Until this time, all polls travel through the network.
By default, proxy polling is disabled. Once enabled, use the no stun proxy-poll command with the appropriate arguments to return to the default state.
This command enables proxy polling for a secondary device at address C1 on interface serial 2 running with modulus 8:
interface serial 2 stun proxy-poll address C1 modulus 8 secondary
You can change the number of milliseconds between each sequence of proxy polls generated on the secondary side of a connection. Use the global configuration command stun poll-interval to do so. The command has this syntax:
stun poll-interval millisecondsThe command applies to all secondary proxy sessions in the router.
Enter the number of milliseconds desired with the milliseconds argument. The default value is 100 milliseconds, and the minimum value is 50 milliseconds.
The no stun poll-interval command returns the default state.
This example sets the poll interval to 100 milliseconds, or 10 times per second:
stun poll-interval 100
Periodically, even when proxy polling is enabled, the router on the primary side of an SDLC connection will pass through a poll from the primary SDLC device through the network to the secondary SDLC device. This action causes the secondary device's reply to also traverse the entire network. This periodic pass-through provides an insurance mechanism that makes sure the primary SDLC device maintains an accurate notion of the secondary SDLC device status.
You can change the number of seconds between each pass-through of polls between the primary and secondary SDLC devices. Use the global configuration command stun primary-pass-through to do so. The full command syntax follows.
stun primary-pass-through secondsThe stun primary-pass-through command applies to all primary proxy sessions in the router. Use the no stun primary-pass-through command to return to the default state of 20 seconds.
This example sets the primary pass-through interval to 30 seconds.
stun primary-pass-through 30
The STUN implementation allows you to define your own STUN protocols. This step must be done before defining the protocol group using the stun protocol-group command.
This feature allows you to transport any serial protocol that meets the following criteria across a Cisco router internetwork.
In addition, if you want to use anything but the predefined, basic protocol that does not allow the specification and routing by an address to achieve a virtual multidrop result, your protocol also must meet the following constraints:
As an overview, SDLC frames have two formats, basic and extended. In the basic SDLC frame shown in Figure 1-17, the Address and Control fields are both 8 bits (also one byte or octet) wide. In the Extended Control format, the Control field is 16 bits wide.
The Address field contains the address of a sending or receiving station, depending upon the procedure. The Control field contains information that determines the type of SDLC frame being transmitted, either:
The Frame Check Sequence (FCS) field is always 16 bits long. A Flag is a special bit sequence that defines the beginning and end of a frame. The bytes in the SDLC frame, except for the FCS, are always transmitted low-order bit first. The FCS bits are transmitted high-order bit first.
Use the stun schema global configuration command to specify the format, or schema, for your protocol. The command syntax follows.
stun schema name offset constant-offset length address-length format format-keywordThe argument name is a name that defines your protocol. It can be up to 20 characters in length.
The argument constant-offset specifies the constant offset, in bytes, for the address to be found in the frame. The argument address-length specifies the length of that address in bytes. The length is limited. These limits are described in Table 1-5.
| If format-keyword is: | the address-length is: |
|---|---|
| decimal | 4 |
| hexadecimal | 8 |
| octal | 4 |
The argument format-keyword specifies the format to be used to specify and display addresses for routes on interfaces that use this STUN protocol. The allowable formats are listed in Table 1-6.
| Format | Allowable Base |
|---|---|
| decimal | base 10 addresses (0-9) |
| hexadecimal | base 16 addresses (0-f) |
| octal | base 8 addresses (0-7) |
The command no stun schema removes the schema.
This command defines a format of SDLC as a new STUN protocol. (This definition of SDLC would not support the proxy polling option available with the predefined protocol definition.)
stun schema new-sdlc offset 0 length 1 format hexadecimal
Once defined, new protocols can be used in the stun protocol-group interface subcommands to tie STUN groups to the new protocols.
This section describes the EXEC commands you use to monitor the state of the STUN.
Use the show stun command to examine the current status of the STUN. The command has this format:
show stunSample output is as follows:
ciscoA# show stun
This peer: 131.108.10.1
Serial0 -- 3174 Controller for test lab (group 1 [sdlc]) state rx_pkts tx_pkts drops poll
7[ 1] IF Serial1 open 20334 86440 5 8P
10[ 1] TCP 131.108.8.1 open 6771 7331 0
all[ 1] TCP 131.108.8.1 open 612301 2338550 1005
The first entry reports that proxy polling is enabled for address 7 and that Serial 0 is running with modulus 8 on the primary side of the link. The link has received 20,334 packets, transmitted 86,440 packets, and dropped 5 packets. See Table 1-7.
| Field | Descriptions |
|---|---|
| This peer | Lists the peer-name or address. The interface name (as defined by the interface description subcommand), its STUN group number, and the protocol associated with the group are shown on the header line. |
| STUN address | Address or the word "all" if the default forwarding entry is specified, followed by a repeat of the group number given for the interface. |
| Type of link | Description of link, either a serial interface using Serial Transport ("IF" followed by interface name), or a TCP connection to a remote router ("TCP" followed by IP address). |
| state | State of the link: open is the normal, working state; direct indicates a direct link to another line, as specified with the direct keyword on the stun route interface subcommand. |
| rx_pkts | Number of received packets. |
| tx_pkts | Number of transmitted packets. |
| drops | Number of packets that for whatever reason had to be dropped. |
| poll | Report of the proxy poll parameters, if any. A "P" indicates a primary and an "S" indicates a secondary node. The number before the letter is the modulus of the link. |
Use the show stun sdlc command to examine the proxy state of various interfaces on an address-by-address basis. The command has this format:
show stun sdlcSample output is as follows:
ciscoA# show stun sdlc
Serial 1 -- 3174 controller for test lab
B3: s2 C1: p4 DE: d6
This example output shows that Serial 1 has three addresses for which proxy polling is enabled. These are B3, for which this end is a secondary link in state 2; C1 for which this end is a primary link and in state 4; and DE, which is in the primary/secondary/modulus in discovery state 6.
The display reports the status of the interfaces using SDLC encapsulation and tells whether proxy polling is enabled for that interface. Interfaces with proxy polling enabled are noted with the address followed by an indication of node type, "s" for secondary, "p" for primary, or "d" for discovery and the state of the node. Possible node states are defined in Table 1-8.
| State | Description |
|---|---|
| 0 | Significant data traveling between the primary and secondary node. No proxy polling occurring. |
| 1-3 | Proxy polling in process of being initiated. |
| 4 | Proxy polling is activated for the link at this time. If this in the primary node, the router responds to the primary's poll. If this is the secondary node, the router will periodically generate polls for potential response by the secondary. |
| 5 | The primary router has data from the secondary to send to the primary SDLC machine, but is waiting for a poll from that machine before transmitting the data. |
| 6-7 | This router still is trying to determine the primary/secondary character and modulus of the SDLC hosts attached to it. No proxying is done in these states. |
This section describes the privileged EXEC debugging commands you use to debug operation of the STUN. Generally, you will enter these commands during troubleshooting sessions with Cisco staff. For each debug command, there is a corresponding undebug command to disable the reports.
debug stun-packet [group] [address]
The debug stun-packet command enables debugging of packets traveling through the STUN links. When enabled, it will produce numerous messages showing every packet travelling through the links. The optional argument group is the decimal integer assigned to a group. When the group parameter is given, output will be limited to only packets associated with STUN group specified. If the optional address argument is also specified, output will be further limited to only those packets with the STUN address specified. The address argument is in the format appropriate for the STUN protocol running for the group for which it is specified.
The debug stun command enables debugging of STUN connections and status. When enabled, it will cause messages showing connection establishment and other overall status message to be displayed.
Following are the global configuration commands used to configure the STUN function. These commands can appear anywhere in the configuration file.
[no] locaddr-priority-list list address-number queue-keyword
Establish queuing priorities based on the address of the logical unit. The argument list is an arbitrary integer between 1 and 10 that identifies the LU address priority list selected by the user. The argument address-number is the value of the LOCADDR= parameter on the LU macro, which is a one-byte address of the LU in hex. The argument queue-keyword is a priority queue name, one of high, medium, normal, or low.
[no] priority-list list stun queue-keyword address group-number address-number
Establishes queuing priorities based on the address of the serial link on a STUN connection. The argument list is an arbitrary integer between 1 and 10 that identifies the priority list selected by the user. The keyword stun indicates that this is a serial tunnel feature. The argument queue-keyword is a priority queue name, one of high, medium, normal, or low. The keyword address is used with the two arguments group-number and address-number that uniquely identify a STUN serial link. The argument group-number is the group number used in the stun group interface configuration subcommand. The argument address-number is the address of the serial link.
[no] stun cos-enable
Enables SNA class of service (COS), which allows prioritization of FEP (NCP) traffic. When used in conjunction with the priority keyword on the stun route command, the stun cos-enable command causes SNA network priority traffic to flow at a higher priority than other SNA data traffic.
[no] stun peer-name ip-address
Enables or disables STUN. The argument ip-address is the IP address by which this STUN peer is known to other STUN peers that are using TCP/IP encapsulation.
[no] stun poll-interval milliseconds
Changes the interval between each sequence of proxy polls generated on the secondary side of the connection. The argument milliseconds is the interval desired, in milliseconds. Default and minimum value is 20, or 1/50th of a second, which is returned by use of the no keyword.
[no] stun primary-pass-through seconds
Changes the number of seconds between each pass through of polls between the primary and secondary SDLC devices. The argument seconds defines the interval. The no version of the command restores the default value of 20 seconds.
[no] stun protocol-group group-number protocol-keyword sdlc-tg
Associates or removes group numbers with protocol names. The group-number argument can be any number you select between 1 and 255. The protocol-keyword argument is any predefined protocol, or protocol you define. Any STUN connections that are members of an sdlc-tg group must be locally acknowledged; that is, local-ack must be specified as a parameter on the stun route interface command. The no version of the command with the appropriate group number and protocol removes an interface from the group.
[no] stun remote-peer-keepalive
Synchronizes the state machines of the STUN remote peer routers. The primary and secondary will exchange keepalive messages where there is no data traffic (I-frames) between NCPs on each SDLC line. NCP end stations are not involved in the keepalive traffic. Keepalives allow routers to detect when their STUN peer has disappeared. This can happen when the WAN connection is lost or if the STUN peer router becomes inoperative.
[no] stun schema name offset constant-offset length address-length format format-keyword
Specifies or removes a format, or schema, for a user-defined protocol. The argument name defines the protocol. The argument constant-offset specifies the constant offset, in bytes, for the address to be found in the frame. The argument address-length specifies the length of that offset. The argument format-keyword specifies the format to be used to specify and display addresses for routes on interfaces that use this STUN protocol. The no stun schema name command removes the schema. The allowable formats and their maximum lengths are described in Table 1-9.
| Formats | Base | Length |
|---|---|---|
| decimal | base 10 addresses (0-9) | 4 |
| hexadecimal | base 16 addresses (0-f) | 8 |
| octal | base 8 addresses (0-7) | 4 |
Following are the interface subcommands used to configure STUN. These commands follow an interface command.
encapsulation stun
Enables the STUN function. This command must be specified in order to use STUN.
[no] locaddr-priority list
Assigns local address priority list to the output interface. The argument list is the priority list number of the input interface.
[no] priority-group list
Assigns a priority group to the output interface. The argument list is the priority list number of the output interface.
[no] stun group group-number
Places STUN-enabled interface in a previously defined group. The argument group-number is user-defined and must be between 1 and 255 (decimal).
[no] stun proxy-poll address address modulus modulus {primary|secondary}
[no] stun proxy-poll address address discovery
Enables or disables proxy polling.
The address argument is the address of the device on which to enable proxy polling. The modulus argument is the modulus of the link as defined by the MODULUS parameter specified in the line descriptions on the SDLC host.
The primary or secondary keyword indicate which role the SDLC device is playing.
The discovery keyword is used when primary and secondary ends are not specified and connections are negotiated.
Default is proxy polling disabled.
[no] stun route all tcp ip-address
[no] stun route all interface serial interface-number
[no] stun route all interface serial interface-number direct
[no] stun route address address-number tcp ip-address [local-ack] [priority]
[tcp-queue-max packets]
[no] stun route address address-number interface serial interface-number
[no] stun route address address-number interface serial interface-number direct
Enables or disables forwarding of frames on the interface.
The all keyword is used when all STUN traffic received on the input interface will be propagated regardless of what address is contained in the SDLC frame.
The tcp keyword causes the TCP/IP encapsulation to be used to propagate frames that match the entry. Enter the address that identifies the remote STUN peer that is connected to the far SDLC link for the ip-address argument.
The local-ack keyword specifies that SDLC sessions are locally terminated. The priority keyword may be specified along with local-ack to enable priority queuing for the SDLC frames. The prioritization feature does add overhead, so be selective in its use.
The interface serial keywords cause the STUN TCP/IP encapsulation function to be used to propagate the SDLC frame. There must be an appropriately configured router on the other end of the designated serial line. Enter the serial line number connected to the router for the interface-number argument.
The address keyword specifies how an SDLC frame that contains a particular address is to be propagated. The address-number argument varies with the protocol type. The argument will accept any octal, decimal, or hexadecimal address in the range allowed by the protocol.
The all and address keywords are used for the same input serial interface. When this is done, the address specifications take effect first. If none of these match, the all keyword will be used to propagate the frame.
The direct keyword is used to indicate that the specified interface is also a direct STUN link, rather than a serial connection to another peer.
The tcp-queue-max keyword sets the maximum size of the output TCP queue for the serial line. The default value of packets is 100. The minimum recommended value is 70 packets, and the maximum is 500.
|
|