Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.1 - Configuring Serial Tunnel and Block Serial Tunnel

Table Of Contents

Configuring Serial Tunnel and Block Serial Tunnel

Serial Tunnel (STUN) Overview

STUN Configuration Task List

Enabling STUN

Specifying STUN Protocol Group

Specifying a Basic STUN Group

Specifying an SDLC Group

Specifying an SDLC Transmission Group

Creating and Specifying a Custom STUN Protocol

Enabling STUN Keepalive

Enabling STUN Remote Keepalive

Enabling STUN Quick-Response

Enabling STUN Interfaces

Configuring SDLC Broadcast

Establishing the Frame Encapsulation Method

Configuring HDLC Encapsulation without Local Acknowledgment

Configuring TCP Encapsulation without Local Acknowledgment

Configuring TCP Encapsulation with SDLC Local Acknowledgment and Priority Queueing

Assigning the Router an SDLC Primary or Secondary Role

Enabling the SDLC Local Acknowledgment Feature

Establishing Priority Queueing Levels

Configuring Local Acknowledgment for Direct Frame Relay Connectivity

Configuring STUN with Multilink Transmission Groups

Design Recommendations

Setting Up STUN Traffic Priorities

Assigning Queueing Priorities

Prioritizing by Serial Interface Address or TCP Port

Prioritizing by Logical Unit Address

Prioritizing STUN Traffic over All Other Traffic

Monitoring and Maintaining STUN Network Activity

STUN Configuration Examples

STUN Priorities Using HDLC Encapsulation Example

SDLC Broadcast Example

Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example

STUN Multipoint Implementation Using a Line-Sharing Device Example

STUN Local Acknowledgment for SDLC Example

STUN Local Acknowledgment for Frame Relay Example

LOCADDR Priority Groups—Simple Example

LOCADDR Priority Groups for STUN Example

Block Serial Tunneling (BSTUN) Overview

Bisync Network Overview

Point-to-Point and Multidrop Support

Asynchronous Network Overview

Virtual Multidrop Support for Multipoint Security Network Configurations

Frame Sequencing

Frame Sequencing in Bisync Networks

Frame Sequencing in Asynchronous Networks

BSTUN Configuration Task List

Enabling BSTUN

Defining the Protocol Group

Enabling BSTUN Keepalive

Enabling BSTUN Remote Keepalive

Enabling Frame Relay Encapsulation

Defining Mapping Between BSTUN and DLCI

Configuring BSTUN on the Serial Interface

Placing a Serial Interface in a BSTUN Group

Specifying How Frames Are Forwarded

Setting Up BSTUN Traffic Priorities

Configuring Protocol Group Options on a Serial Interface

Configuring Bisync Options on a Serial Interface

Configuring Asynchronous Security Protocol Options on a Serial Interface

Configuring Direct Serial Encapsulation for Passthru Peers

Configuring Local Acknowledgment Peers

Monitoring and Maintaining the Status of BSTUN

BSTUN Configuration Examples

Simple Bisync Configuration Example

Bisync Addressing on Contention Interfaces Example

Nonstandard Bisync Addressing Example

Priority Queueing: With Priority Based on BSTUN Header Example

Priority Queueing: With Priority Based on BSTUN Header and Packet Sizes Example

Priority Queueing: With Priority Based on BSTUN Header and Bisync Address Example

Priority Queueing: With Priority Based on BSTUN TCP Ports Example

Priority Queueing: With Priority Based on BSTUN TCP Ports and Bisync Address Example

Custom Queueing: With Priority Based on BSTUN Header Example

Custom Queueing: With Priority Based on BSTUN Header and Packet Size Example

Custom Queueing: With Priority Based on BSTUN Header and Bisync Address Example

Custom Queueing: With Priority Based on BSTUN TCP Ports Example

Custom Queueing: With Priority Based on BSTUN TCP Ports and Bisync Address Example

Asynchronous Configuration Example

BSTUN over Frame Relay Configuration with Local Acknowledgment Example

BSTUN over Frame Relay Configuration with Passthru Example

Configuring Serial Tunnel and Block Serial Tunnel

This chapter describes how to configure serial tunnel (STUN) and block serial tunnel (BSTUN). For a complete description of the STUN and BSTUN commands in this chapter, refer to the "STUN and BSTUN Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference, Volume I. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

This chapter contains the following sections:

•Serial Tunnel (STUN) Overview

•STUN Configuration Task List

•Monitoring and Maintaining STUN Network Activity

•STUN Configuration Examples

•Block Serial Tunneling (BSTUN) Overview

•BSTUN Configuration Task List

•Monitoring and Maintaining the Status of BSTUN

•BSTUN Configuration Examples

Serial Tunnel (STUN) Overview

Cisco's STUN implementation allows Synchronous Data Link Control (SDLC) protocol devices and High-Level Data Link Control (HDLC) devices to connect to one another through a multiprotocol internetwork rather than through a direct serial link. STUN encapsulates SDLC frames in either the Transmission Control Protocol/Internet Protocol (TCP/IP) or the HDLC protocol. STUN provides a straight passthru of all SDLC traffic (including control frames, such as Receiver Ready) end-to-end between Systems Network Architecture (SNA) devices.

Cisco's SDLC local acknowledgment provides local termination of the SDLC session so that control frames no longer travel the WAN backbone networks. This means end nodes do not time out, and a loss of sessions does not occur. You can configure your network with STUN, or with STUN and SDLC local acknowledgment. To enable SDLC local acknowledgment, the Cisco IOS software must first be enabled for STUN and routers configured to appear on the network as primary or secondary SDLC nodes. TCP/IP encapsulation must be enabled. Cisco's SDLC Transport feature also provides priority queueing for TCP encapsulated frames.

Cisco's block serial tunnel (BSTUN) implementation enables Cisco series 2500, 4000, 4500, 4700 and 7200 series routers to support devices that use the Binary Synchronous Communications (Bisync) data-link protocol and asynchronous security protocols that include Adplex, ADT Security Systems, Inc., Diebold, and asynchronous generic traffic. BSTUN implementation is also supported on the 4T network interface module (NIM) on the Cisco router 4000 and 4500 series. Our support of the Bisync protocol enables enterprises to transport Bisync traffic and SNA multiprotocol traffic over the same network.

STUN Configuration Task List

To configure and monitor STUN or STUN local acknowledgment, perform the tasks in the following sections:

•Enabling STUN

•Specifying STUN Protocol Group

•Enabling STUN Keepalive

•Enabling STUN Remote Keepalive

•Enabling STUN Quick-Response

•Enabling STUN Interfaces

•Configuring SDLC Broadcast

•Establishing the Frame Encapsulation Method

•Configuring STUN with Multilink Transmission Groups

•Setting Up STUN Traffic Priorities

The "STUN Configuration Examples" section follows these configuration tasks.

Enabling STUN

To enable STUN, use the following command in global configuration mode:

Command

Purpose

stun peer-name ip-address

Enables STUN for a particular IP address.

When configuring redundant links, ensure that the STUN peer names you choose on each router are the IP addresses of the most stable interfaces on each device, such as a loopback or Ethernet interface. See the "STUN Configuration Examples" section.

You must also configure SDLC address FF on Router A for each of the STUN peers. To do so, use the following command in interface configuration mode:

Command

Purpose

stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max] [passive]

Configures SDLC address FF on Router A for each STUN peer.

Specifying STUN Protocol Group

Place each STUN interface in a group that defines the ISO 3309-compliant framed protocol running on that link. Packets will only travel between STUN interfaces that are in the same protocol group.

There are three predefined STUN protocols:

•Basic

•SDLC

•SDLC transmission group

You can also specify a custom STUN protocol.

To specify STUN protocols, you must perform the tasks in the following sections:

•Specifying a Basic STUN Group

•Specifying an SDLC Group

•Specifying an SDLC Transmission Group

•Creating and Specifying a Custom STUN Protocol

If you want to use the STUN Local Acknowledgment feature, you must specify either the SDLC protocol or the SDLC transmission group protocol.

Note Before you can specify a custom protocol, you must first define the protocol; see the "Creating and Specifying a Custom STUN Protocol" section for the procedure.

Specifying a Basic STUN Group

The basic STUN protocol does not depend on the details of serial protocol addressing and is used when addressing is not important. Use this when your goal is to replace one or more sets of point-to-point (not multidrop) serial links by using a protocol other than SDLC. Use the following command in global configuration mode:

Command

Purpose

stun protocol-group group-number basic

Specifies a basic protocol group and assigns a group number.

Specifying an SDLC Group

You can specify SDLC protocol groups to associate interfaces with the SDLC protocol. Use the SDLC STUN protocol to place the routers in the midst of either point-to-point or multipoint (multidrop) SDLC links. To define an SDLC protocol group, enter the following command in global configuration mode:

Command

Purpose

stun protocol-group group-number sdlc

Specifies an SDLC protocol group and assigns a group number.

If you specify an SDLC protocol group, you cannot specify the stun route all command on any interface of that group.

For an example of how to configure an SDLC protocol group, see the "Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example" section.

Specifying an SDLC Transmission Group

An SNA transmission group is a set of lines providing parallel links to the same pair of SNA front-end-processor (FEP) devices. This provides redundancy of paths for fault tolerance and load sharing. To define an SDLC transmission group, use the following command in global configuration mode:

Command

Purpose

stun protocol-group group-number sdlc sdlc-tg

Specifies an SDLC protocol group, assigns a group number, and creates an SNA transmission group.

All STUN connections in a transmission group must connect to the same IP address and use the SDLC local acknowledgment feature.

Creating and Specifying a Custom STUN Protocol

To define a custom protocol and tie STUN groups to the new protocol, use the following commands in global configuration mode:

Command

Purpose

Step 1

stun schema name offset constant-offset length address-length format format-keyword

Creates a custom protocol.

Step 2

stun protocol-group group-number schema

Specifies the custom protocol group and assigns a group number.

Enabling STUN Keepalive

To define the number of times to attempt a peer connection before declaring the peer connection to be down, use the following command in global configuration mode:

Command

Purpose

stun keepalive-count

Specifies the number of times to attempt a peer connection.

Enabling STUN Remote Keepalive

To enable detection of the loss of a peer, use the following command in global configuration mode:

Command

Purpose

stun remote-peer-keepalive seconds

Enables detection of the loss of a peer.

Enabling STUN Quick-Response

You can enable STUN quick-response, which improves network performance when used with local acknowledgment. When STUN quick-response is used with local acknowledgment, the router responds to an exchange identification (XID) or a Set Normal Response Mode (SNRM) request with a Disconnect Mode (DM) response when the device is not in the CONNECT state. The request is then passed to the remote router and, if the device responds, the reply is cached. The next time the device is sent an XID or SNRM, the router replies with the cached DM response.

Note Using STUN quick-response avoids an AS/400 line reset problem by eliminating the Non-Productive Receive Timer (NPR) expiration in the AS/400. With STUN quick-response enabled, the AS/400 receives a response from the polled device, even when the device is down. If the device does not respond to the forwarded request, the router continues to respond with the cached DM response.

To enable STUN quick-response, use the following command in global configuration mode:

Command

Purpose

stun quick-response

Enables STUN quick-response.

Enabling STUN Interfaces

Caution When STUN encapsulation is enabled or disabled on an RSP platform, the memory reallocates memory pools (recarve) and the interface shuts down and restarts. The recarve is caused by the change from STUN to another protocol, which results in a change in the MTU size. No user configuration is required.

You must enable STUN on serial interfaces and place these interfaces in the protocol groups you have defined. To enable STUN on an interface and to place the interface in a STUN group, use the following commands in interface configuration mode:

Command

Purpose

Step 1

encapsulation stun

Enables STUN function on a serial interface.

Step 2

stun group group-number

Places the interface in a previously defined STUN group.

When a given serial link is configured for the STUN function, it is no longer a shared multiprotocol link. All traffic that arrives on the link will be transported to the corresponding peer as determined by the current STUN configuration.

Configuring SDLC Broadcast

The SDLC broadcast feature allows SDLC broadcast address FF to be replicated for each of the STUN peers, so each of the end stations receives the broadcast frame. For example, in Figure 146, the FEP views the end stations 1, 2, and 3 as if they are on an SDLC multidrop link. Any broadcast frame sent from the FEP to Router A is duplicated and sent to each of the downstream routers (B and C).

Figure 146 SDLC Broadcast across Virtual Multidrop Lines

To enable SDLC broadcast, use the following command in interface configuration mode:

Command

Purpose

sdlc virtual-multidrop

Enables SDLC broadcast.

Only enable SDLC broadcast on the device that is configured to be the secondary station on the SDLC link (Router A in Figure 146).

Establishing the Frame Encapsulation Method

To allow SDLC frames to travel across a multimedia, multiprotocol network, you must encapsulate them using one of the methods in the following sections:

•Configuring HDLC Encapsulation without Local Acknowledgment

•Configuring TCP Encapsulation without Local Acknowledgment

•Configuring TCP Encapsulation with SDLC Local Acknowledgment and Priority Queueing

•Configuring Local Acknowledgment for Direct Frame Relay Connectivity

Configuring HDLC Encapsulation without Local Acknowledgment

You can encapsulate SDLC or HDLC frames using the HDLC protocol. The outgoing serial link can still be used for other kinds of traffic. The frame is not TCP encapsulated. To configure HDLC encapsulation, use one of the following commands in interface configuration mode:

Command

Purpose

stun route all interface serial number
or

stun route all interface serial number direct

or
stun route address address-number interface serial number
or

stun route address address-number interface serial number direct

Forwards all HDLC or SDLC traffic of the identified interface number.

or

Forwards all HDLC or SDLC traffic on a direct STUN link.

or

Forwards HDLC or SDLC traffic of the identified address.

or

Forwards HDLC or SDLC traffic of the identified address across a direct STUN link.

Use the no forms of these commands to disable HDLC encapsulation.

Note You can forward all traffic only when you are using basic STUN protocol groups.

Configuring TCP Encapsulation without Local Acknowledgment

If you do not want to use SDLC local acknowledgment and only need to forward all SDLC frames encapsulated in TCP, use the following commands in interface configuration mode:

Command

Purpose

Step 1

stun route all tcp ip-address [passive]

Forwards all TCP traffic for this IP address.

Step 2

stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max] [passive]

Specifies TCP encapsulation.

Use the no form of these commands to disable forwarding of all TCP traffic.

This configuration is typically used when two routers can be connected via an IP network as opposed to a point-to-point link.

Configuring TCP Encapsulation with SDLC Local Acknowledgment and Priority Queueing

You configure SDLC local acknowledgment using TCP encapsulation. When you configure SDLC local acknowledgment, you also have the option to enable support for priority queueing.

Note To enable SDLC local acknowledgment, you must specify an SDLC or SDLC transmission group.

SDLC local acknowledgment provides local termination of the SDLC session so that control frames no longer travel the WAN backbone networks. This means that time-outs are less likely to occur.

Figure 147 illustrates an SDLC session. IBM 1, using a serial link, can communicate with IBM 2 on a different serial link separated by a wide-area backbone network. Frames are transported between Router A and Router B using STUN, but the SDLC session between IBM 1 and IBM 2 is still end-to-end. Every frame generated by IBM 1 traverses the backbone network to IBM 2, which, upon receipt of the frame, acknowledges it.

Figure 147 SDLC Session Without Local Acknowledgment

With SDLC local acknowledgment, the SDLC session between the two end nodes is not end-to-end, but instead terminates at the two local routers, as shown in Figure 148. 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. 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.

Figure 148 SDLC Session with Local Acknowledgment

To configure TCP encapsulation with SDLC local acknowledgment and priority queueing, perform the tasks in the following sections:

•Assigning the Router an SDLC Primary or Secondary Role

•Enabling the SDLC Local Acknowledgment Feature

•Establishing Priority Queueing Levels

Assigning the Router an SDLC Primary or Secondary Role

To establish local acknowledgment, the router must play the role of an SDLC primary or secondary node. Primary nodes poll secondary nodes in a predetermined order. Secondaries then transmit if they have outgoing data.

For example, in an IBM environment, an FEP is the primary station and cluster controllers are secondary stations. If the router is connected to an FEP, the router should appear as a cluster controller and must be assigned the role of a secondary SDLC node. If the router is connected to a cluster controller, the router should appear as an FEP and must be assigned the role of a primary SDLC node. Devices connected to SDLC primary end-stations must play the role of an SDLC secondary and routers attached to SDLC secondary end stations must play the role of an SDLC primary station.

To assign the router a primary or secondary role, use one of the following commands in interface configuration mode:
Command

Purpose
stun sdlc-role primary
or

stun sdlc-role secondary
Assigns the STUN-enabled router an SDLC primary role.
or
Assigns the STUN-enabled router an SDLC secondary role.
Enabling the SDLC Local Acknowledgment Feature

To enable SDLC local acknowledgment, use the following command in interface configuration mode:

Command

Purpose

stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max] [passive]

Establishes SDLC local acknowledgment using TCP encapsulation.

The stun route address 1 tcp local-ack priority tcp-queue-max interface configuration command enables local acknowledgment and TCP encapsulation. Both options are required to use transmission groups. You should specify the SDLC address with the echo bit turned off for transmission group interfaces. The SDLC broadcast address 0xFF is routed automatically for transmission group interfaces. The priority keyword creates multiple TCP sessions for this route. The tcp-queue-max keyword sets the maximum size of the outbound TCP queue for the SDLC. The default TCP queue size is 100. The value for hold-queue in should be greater than the value for tcp-queue-max.

You can use the priority keyword (to set up the four levels of priorities to be used for TCP encapsulated frames) at the same time you enable local acknowledgment. The priority keyword is described in the following section. Use the no form of this command to disable SDLC Local Acknowledgment. For an example of how to enable local acknowledgment, see the "Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example" section.

Establishing Priority Queueing Levels

With SDLC local acknowledgment enabled, you can establish priority levels used in priority queueing for serial interfaces. The priority levels are as follows:

•Low

•Medium

•Normal

•High

To set the priority queueing level, use the following command in interface configuration mode:

Command

Purpose

stun route address address-number tcp ip-address [local-ack] priority [tcp-queue-max] [passive]

Establishes the four levels of priorities to be used in priority queueing.

Use the no form of this command to disable priority settings. For an example of how to establish priority queueing levels, see the "Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example" section.

Configuring Local Acknowledgment for Direct Frame Relay Connectivity

To implement STUN with local acknowledgment using direct Frame Relay encapsulation, use the following command in interface configuration mode:

Command

Purpose

stun route address sdlc-addr interface frame-relay-port dlci number localsap local-ack cls

Configures Frame Relay encapsulation between STUN peers with local acknowledgment.

Configuring STUN with Multilink Transmission Groups

You can configure multilink SDLC transmission groups across STUN connections between IBM communications controllers such as IBM 37x5s. Multilink transmission groups allow you to collapse multiple WAN leased lines into one leased line.

SDLC multilink transmission groups provide the following features:

•Network Control Program (NCP) SDLC address allowances, including echo and broadcast addressing.

•Remote NCP load sequence. After a SIM/RIM exchange but before a SNRM/UA exchange, NCPs send numbered I-frames. During this period, I-frames are not locally acknowledged, but instead are passed through. After the SNRM/UA exchange, local acknowledgment occurs.

•Rerouting of I-frames sent by the Cisco IOS software to the NCP if a link is lost in a multilink transmission group.

•Flow control rate tuning causes a sending NCP to "feel" WAN congestion and hold frames that would otherwise be held by the Cisco IOS software waiting to be transmitted on the WAN. This allows the NCP to perform its class-of-service algorithm more efficiently based on a greater knowledge of network congestion.

STUN connections that are part of a transmission group 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 might minimize the number of NCP timers that expire due to network delay. Also, these STUN connections must go to the same IP address. This is because SNA transmission groups are parallel links between the same pair of IBM communications controllers.

Design Recommendations

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 to ensure response timed does not degrade. If other protocols are also 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 use a combination of routed transmission groups and directly connected NCP transmission groups, you need to plan the configuration carefully to ensure that SNA sessions do not stop unexpectedly. Assuming that hardware reliability is not an issue, single-link routed transmission groups are as reliable as direct NCP-to-NCP single-link transmission groups. This is true because neither the NCP nor the Cisco IOS software can reroute I-frames when a transmission group has only one link. Additionally, a multilink transmission group directed between NCPs and a multilink transmission group through a router are equally reliable. Both can perform rerouting.

However, you might run into problems if you have a configuration in which two NCPs are directly connected (via one or more transmission group links) and one link in the transmission group is routed. The NCPs treat this as a multilink transmission group. However, the Cisco IOS software views the transmission group as a single-link transmission group.

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 acknowledges the I-frame sent from NCP A and sends it over the WAN. If, before the I-frame reaches Router B, the SDLC link between router B and NCP B goes down, Router B attempts to reroute the I-frame on another link in the transmission group when it receives the I-frame. However, because this is a single-link transmission group, there are no other routes, and Router B drops the I-frame. NCP B never receives this I-frame because Router A acknowledges its receipt, and NCP A marks it as transmitted and deletes it. NCP B detects a gap in the transmission group sequence numbers and waits to receive the missing I-frame. NCP B waits forever for this I-frame, and does not send or receive any other frames. NCP B is technically not operational and all SNA sessions through NCP B are lost.

Finally, consider a configuration in which one or more lines of an NCP transmission group are connected to a router and one or more lines are directly connected between NCPs. If the network delay associated with one line of an NCP transmission group is different from the delay of another line in the same NCP transmission group, the receiving NCP spends additional time resequencing PIUs.

Setting Up STUN Traffic Priorities

To determine the order in which traffic should be handled on the network, use the methods described in the following sections:

•Assigning Queueing Priorities

•Prioritizing STUN Traffic over All Other Traffic

Assigning Queueing Priorities

To assign queueing priorities, perform the tasks in one of the following sections:

•Prioritizing by Serial Interface Address or TCP Port

•Prioritizing by Logical Unit Address

Prioritizing by Serial Interface Address or TCP Port

You can prioritize traffic on a per-serial-interface address or TCP port basis. You might want to do this so that traffic between one source-destination pair is always sent before traffic between another source-destination pair.

Note You must first enable local acknowledgment and priority levels as described earlier in this chapter.

To prioritize traffic, use one of the following commands in global configuration mode:
Command

Purpose
priority-list list-number protocol stun queue address group-number address-number
or

priority-list list-number protocol ip queue tcp tcp-port-number
Assigns a queueing priority to the address of the STUN serial interface.

or

Assigns a queueing priority to a TCP port.
You must also use the following command in interface configuration mode:

Command

Purpose

priority-group list-number

Assigns a priority list to a priority group.

Figure 149 illustrates serial link address prioritization. Device A communicates with Device C, and Device B communicates with Device D. With the serial link address prioritization, you can choose to give A-C a higher priority over B-D across the serial tunnel.

Figure 149 Serial Link Address Prioritization

To disable priorities, use the no forms of these commands.

For an example of how to prioritize traffic according to serial link address, see the "Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example" section.

Prioritizing by Logical Unit Address

SNA local logical unit (LU) address prioritization is specific to IBM SNA connectivity and is used to prioritize SNA traffic on either STUN or remote source-route bridging (RSRB). To set the queueing priority by LU address, use the following command in global configuration mode:

Command

Purpose

locaddr-priority-list list-number address-number queue-keyword

Assigns a queueing priority based on the LU address.

In Figure 150, LU address prioritization can be set so that particular LUs receive data in preference to others or so that LUs have priority over the printer, for example.

Figure 150 SNA LU Address Prioritization

To disable this priority, use the no form of this command.

For an example of how to prioritize traffic according to logical unit address, see the "LOCADDR Priority Groups for STUN Example" section.

Prioritizing STUN Traffic over All Other Traffic

You can prioritize STUN traffic to be routed first before all other traffic on the network. To give STUN traffic this priority, use the following command in global configuration mode:

Command

Purpose

priority-list list-number protocol stun queue address group-number address-number

Prioritizes STUN traffic in your network over that of other protocols.

To disable this priority, use the no form of this command.

For an example of how to prioritize STUN traffic over all other traffic, see the "Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example" section.

Monitoring and Maintaining STUN Network Activity

You can list statistics regarding STUN interfaces, protocol groups, number of packets sent and received, local acknowledgment states, and more. To get activity information, use the following command in EXEC mode:

Command

Purpose

show stun

Lists the status display fields for STUN interfaces.

STUN Configuration Examples

The following sections provide STUN configuration examples:

•STUN Priorities Using HDLC Encapsulation Example

•SDLC Broadcast Example

•Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example

•STUN Multipoint Implementation Using a Line-Sharing Device Example

•STUN Local Acknowledgment for SDLC Example

•STUN Local Acknowledgment for Frame Relay Example

•LOCADDR Priority Groups—Simple Example

•LOCADDR Priority Groups for STUN Example

STUN Priorities Using HDLC Encapsulation Example

Assume that the link between Router A and Router B in Figure 151 is a serial tunnel that uses the simple serial transport mechanism. Device A communicates with Device C (SDLC address C1) with a high priority. Device B communicates with Device D (SDLC address A7) with a normal priority.

Figure 151 STUN Simple Serial Transport

The following configurations set the priority of STUN hosts A, B, C, and D.

Router A
stun peer-name 10.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 10.0.0.1 255.0.0.0
 priority-group 1
!
priority-list 1 protocol stun high address 1 C1
priority-list 1 protocol stun low address 2 A7
Router B
stun peer-name 10.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 10.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 protocol stun high address 1 C1
priority-list 1 protocol stun low address 2 A7
SDLC Broadcast Example

In the following example, an FEP views end stations 1, 2, and 3 as if they were on an SDLC multidrop link. Any broadcast frame sent from the FEP to Router A is duplicated and sent to each of the downstream routers (B and C.)
stun peer-name xxx.xxx.xxx.xxx
stun protocol-group 1 sdlc
interface serial 1
encapsulation stun
 stun group 1
 stun sdlc-role secondary
 sdlc virtual-multidrop
 sdlc address 1
 sdlc address 2
 sdlc address 3
 stun route address 1 tcp yyy.yyy.yyy.yyy local-ack
 stun route address 2 tcp zzz.zzz.zzz.zzz local-ack
 stun route address 3 tcp zzz.zzz.zzz.zzz local-ack
 stun route address FF tcp yyy.yyy.yyy.yyy
 stun route address FF tcp zzz.zzz.zzz.zzz
Serial Link Address Prioritization Using STUN TCP/IP Encapsulation Example

Assume that the link between Router A and Router B is a serial tunnel that uses the TCP/IP encapsulation as shown in Figure 152. Device A communicates with Device C (SDLC address C1) with a high priority. Device B communicates with Device D (SDLC address A7) with a normal priority. The configuration file for each router follows the figure.

Figure 152 STUN TCP/IP Encapsulation

Router A
stun peer-name 10.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 10.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 10.0.0.2 local-ack priority
 priority-group 2
!
interface ethernet 0
 ip address 10.0.0.1 255.0.0.0
 priority-group 3
!
interface ethernet 1
 ip address 10.0.0.3 255.0.0.0
priority-group 3
! This list tells interface Serial 0 which tcp port numbers
! on the WAN interface correspond to the high, medium, normal
! and low priority queues.
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 protocol stun high address 1 C1
! This list tells interface Serial 1 which tcp port numbers
! on the WAN interface correspond to the high, medium, normal
! and low priority queues.
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 protocol stun normal address 2 A7
! This list establishes the high, medium, normal, and low
! priority queues on the WAN interfaces.
priority-list 3 protocol ip high tcp 1994
priority-list 3 protocol ip medium tcp 1990
priority-list 3 protocol ip normal tcp 1991
priority-list 3 protocol ip low tcp 1992
!
hostname routerA
router igrp
network 1.0.0.0
Router B
stun peer-name 10.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 10.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 10.0.0.1 local-ack priority
 priority-group 2
!
interface ethernet 0
 ip address 10.0.0.2 255.0.0.0
priority-group 3
!
interface ethernet 1
 ip address 10.0.0.4 255.0.0.0
priority-group 3
! This list tells interface Serial 0 which tcp port numbers
! on the WAN interface correspond to the high, medium, normal
! and low priority queues.
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 protocol stun high address 1 C1
! This list tells interface Serial 2 which tcp port numbers
! on the WAN interface correspond to the high, medium, normal
! and low priority queues.
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 protocol stun normal address 2 A7
! This list establishes the high, medium, normal, and low
! priority queues on the WAN interface(s).
priority-list 3 protocol ip high tcp 1994
priority-list 3 protocol ip medium tcp 1990
priority-list 3 protocol ip normal tcp 1991
priority-list 3 protocol ip low tcp 1992
!
hostname routerB
router igrp 109
network 1.0.0.0
STUN Multipoint Implementation Using a Line-Sharing Device Example

In Figure 153, four separate PS/2 computers are connected to a line-sharing device off of Router B. Each PS/2 computer has four sessions open on an AS/400 device attached to Router A. Router B functions as the primary station, while Router A functions as the secondary station. Both routers locally acknowledge packets from the IBM PS/2 systems.

Figure 153 STUN Communication Involving a Line-Sharing Device

The configuration file for the routers shown in Figure 153 follows.

Router A
! enter the address of the stun peer 
stun peer-name 172.16.134.86
! specify that group 4 uses the SDLC protocol
stun protocol-group 4 sdlc
stun remote-peer-keepalive
interface ethernet 1
! enter the IP address for the Ethernet interface
 ip address 172.16.134.86 255.255.255.0
!
! description of IBM AS/400 link
interface serial 2
! description of IBM AS/400 link; disable the IP address on a serial interface 
 no ip address
! enable STUN encapsulation on this interface 
 encapsulation stun
! apply previously defined stun group 4 to serial interface 2
 stun group 4
! establish this router as a secondary station
stun sdlc-role secondary
! wait up to 63000 msec for a poll from the primary before timing out
 sdlc poll-wait-timeout 63000
! list addresses of secondary stations (PS/2 systems) attached to link
sdlc address C1
sdlc address C2
sdlc address C3
sdlc address C4
! use tcp encapsulation to send frames to SDLC stations C1, C2, C3, or 
! C4 and locally terminate sessions with these stations 
stun route address C1 tcp 172.16.134.58 local-ack
stun route address C2 tcp 172.16.134.58 local-ack
stun route address C3 tcp 172.16.134.58 local-ack
stun route address C4 tcp 172.16.134.58 local-ack
Router B
! enter the address of the stun peer 
stun peer-name 172.16.134.58
! this router is part of SDLC group 4
stun protocol-group 4 sdlc
stun remote-peer-keepalive
!
interface ethernet 1
! enter the IP address for the Ethernet interface
ip address 172.16.134.58 255.255.255.0
!
! description of PS/2 link 
interface serial 4
! disable the IP address on a serial interface 
 no ip address
! enable STUN encapsulation on this interface 
 encapsulation stun
! apply previously defined stun group 4 to serial interface 2
stun group 4
! establish this router as a primary station
stun sdlc-role primary
sdlc line-speed 9600
! wait 2000 milliseconds for a reply to a frame before resending it
sdlc t1 2000
! resend a frame up to four times if not acknowledged
sdlc n2 4
! list addresses of secondary stations (PS/2 systems) attached to link
sdlc address C1
sdlc address C2
sdlc address C3
sdlc address C4
! use tcp encapsulation to send frames to SDLC stations C1, C2, C3, or 
! C4 and locally terminate sessions with these stations 
stun route address C3 tcp 172.16.134.86 local-ack
stun route address C1 tcp 172.16.134.86 local-ack
stun route address C4 tcp 172.16.134.86 local-ack
stun route address C2 tcp 172.16.134.86 local-ack
! set the clockrate on this interface to 9600 bits per second 
clockrate 9600
STUN Local Acknowledgment for SDLC Example

The following example shows a sample configuration for a pair of routers performing SDLC local acknowledgment.

Router A
stun peer-name 172.16.64.92
stun protocol-group 1 sdlc
stun remote-peer-keepalive
!
interface Serial 0
 no ip address
 encapsulation stun
 stun group 1
 stun sdlc-role secondary 
 sdlc address C1
 stun route address C1 tcp 172.16.64.93 local-ack
 clockrate 19200
Router B
stun peer-name 172.16.64.93
stun protocol-group 1 sdlc
stun remote-peer-keepalive
!
interface Serial 0
 no ip address
 encapsulation stun
 stun group 1
 stun sdlc-role primary 
 sdlc line-speed 19200
 sdlc address C1
 stun route address C1 tcp 172.16.64.92 local-ack
 clockrate 19200
STUN Local Acknowledgment for Frame Relay Example

The following example describes an interface configuration for Frame Relay STUN with local acknowledgment:
stun peer-name 10.1.21.1 cls 4
stun protocol-group 120 sdlc
!
interface Serial1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay map llc2 22
!
interface Serial4
 no ip address
 encapsulation stun
 clockrate 9600
 stun group 120
 stun sdlc-role secondary
 sdlc address C1
 sdlc address C2
 stun route address C1 interface Serial1 dlci 22 04 local-ack
 stun route address C2 interface Serial1 dlci 22 08 local-ack
!
LOCADDR Priority Groups—Simple Example

The following example shows how to establish queueing priorities on a STUN interface based on an LU address:
! sample stun peer-name global command
stun peer-name 131.108.254.6
! sample protocol-group command for reference
stun protocol-group 1 sdlc 
! give locaddr-priority-list 1 a high priority for LU 02
locaddr-priority-list 1 02 high
! give locaddr-priority-list 1 a low priority for LU 05 
locaddr-priority-list 1 05 low
!
interface serial 0
! disable the ip address for interface serial 0
 no ip address
! enable the interface for STUN
 encapsulation stun
! sample stun group command 
 stun group 2 
! sample stun route command 
 stun route address 10 tcp 131.108.254.8 local-ack priority
! assign priority group 1 to the input side of interface serial 0
locaddr-priority 1
priority-group 1
LOCADDR Priority Groups for STUN Example

The following configuration example shows how to assign a priority group to an input interface:

Router A
stun peer-name 10.0.0.1
stun protocol-group 1 sdlc
locaddr-priority-list 1 02 high
locaddr-priority-list 1 03 high
locaddr-priority-list 1 04 medium
locaddr-priority-list 1 05 low
!
interface serial 0
 no ip address
 encapsulation stun
 stun group 1
 stun route address C1 tcp 10.0.0.2 local-ack priority
 clockrate 19200
 locaddr-priority 1
 priority-group 1
!
interface Ethernet 0
 ip address 10.0.0.1 255.255.255.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
Router B
stun peer-name 10.0.0.2
stun protocol-group 1 sdlc
locaddr-priority-list 1 02 high
locaddr-priority-list 1 03 high
locaddr-priority-list 1 04 medium
locaddr-priority-list 1 05 low
!
interface serial 0
 no ip address
 encapsulation stun
 stun group 1
 stun route address C1 tcp 10.0.0.1 local-ack priority
 clockrate 19200
 locaddr-priority 1
 priority-group 1
!
interface Ethernet 0
 ip address 10.0.0.2 255.255.255.0
!
 priority-list 1 protocol ip high tcp 1994