Internetwork Design Guide -- STUN for Front-End Processors

From DocWiki

(Difference between revisions)
Jump to: navigation, search
(added metadata)
 
(4 intermediate revisions not shown)
Line 1: Line 1:
 +
{{Template:Required Metadata}}
 +
<meta name="keywords" content="stun, front end processor, internetworking"></meta>
Serial tunneling (STUN) enables the integration of traditional systems network architecture (SNA) networks with multiprotocol networks. STUN also lowers operating costs by reducing the need for redundant remote wide-area links. This case study explores three implementations of STUN between Cisco routers and front-end processors (FEPs):
Serial tunneling (STUN) enables the integration of traditional systems network architecture (SNA) networks with multiprotocol networks. STUN also lowers operating costs by reducing the need for redundant remote wide-area links. This case study explores three implementations of STUN between Cisco routers and front-end processors (FEPs):
* [[Internetwork Design Guide  -- STUN for Front-End Processors#Basic STUN|Basic STUN]]-Presents a STUN implementation that is simple and quick to configure because it does not require the specification of addresses. This implementation is recommended for networks that do not require synchronous data link control (SDLC) address checking or local acknowledgment.
* [[Internetwork Design Guide  -- STUN for Front-End Processors#Basic STUN|Basic STUN]]-Presents a STUN implementation that is simple and quick to configure because it does not require the specification of addresses. This implementation is recommended for networks that do not require synchronous data link control (SDLC) address checking or local acknowledgment.
Line 7: Line 9:
{{note|This case study introduces basic SNA concepts, but does not discuss them in detail. }}
{{note|This case study introduces basic SNA concepts, but does not discuss them in detail. }}
 +
 +
 +
{| align="right" border="1"
 +
|align="center"|'''Guide Contents'''
 +
|-
 +
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]]<br>[[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]]<br>[[Internetwork Design Guide#Network Enhancements|Network Enhancements]]<br>[[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]]<br>[[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]]<br>[[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]]<br>[[Internetwork Design Guide#LAN Switching|LAN Switching]] <br>[[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] <br>[[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] <br>[[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
 +
|}
== Understanding FEP Configuration ==
== Understanding FEP Configuration ==
Line 532: Line 541:
[[Category: Internetwork Design]]
[[Category: Internetwork Design]]
 +
[[Category:Internetworking Case Studies]]

Latest revision as of 21:29, 16 October 2012

Serial tunneling (STUN) enables the integration of traditional systems network architecture (SNA) networks with multiprotocol networks. STUN also lowers operating costs by reducing the need for redundant remote wide-area links. This case study explores three implementations of STUN between Cisco routers and front-end processors (FEPs):

  • Basic STUN-Presents a STUN implementation that is simple and quick to configure because it does not require the specification of addresses. This implementation is recommended for networks that do not require synchronous data link control (SDLC) address checking or local acknowledgment.
  • SDLC STUN-Presents a STUN implementation that includes the configuration of addresses. This implementation is recommended for networks that require SDLC address checking.
  • SDLC-Transmission Group STUN-Presents a STUN implementation that supports enhanced FEP-to-FEP communications features, such as transmission groups, as well as advanced router features. This implementation is recommended for networks that require local acknowledgment.


Note Note: This case study introduces basic SNA concepts, but does not discuss them in detail.


Guide Contents
Internetworking Design Basics
Designing various internetworks
Network Enhancements
IP Routing Concepts
UDP Broadcast Flooding
Large-Scale H.323 Network Design for Service Providers
LAN Switching
Subnetting an IP Address Space
IBM Serial Link Implementation Notes
References and Recommended Reading

Contents

Understanding FEP Configuration

In a traditional SNA environment, serial lines connect FEPs in a master-slave topology, as shown in Figure: Map of a traditional SNA network. The primary FEP is connected to the IBM host, which is typically an IBM 3090 mainframe. Synchronous modems connect the FEPs.

Figure: Map of a traditional SNA network

Nd202001.jpg

The software running on the FEP is called the Network Control Program (NCP). This section describes NCP configuration parameters and optional NCP features that network administrators must consider when they introduce routers into an FEP environment.

Serial Connections

Typically, a serial port on a line interface card in the FEP connects the FEP to a synchronous modem. Depending on the type of line interface card, the serial port may be EIA/TIA-232 or V.35. The modem acts as data communications equipment (DCE) and provides clocking and synchronization. The FEP acts as data terminal equipment (DTE). The NCP statement that configures the FEP for DTE is CLOCKNG=EXT.

Primary and Secondary Roles

The FEPs dynamically determine their primary and secondary roles. Typically, the FEP with the higher subarea address becomes the primary FEP. In some versions of NCP, the role parameter is configurable. Typically, the local FEP (the closest to the mainframe) is the primary FEP, whereas the remote FEP is the secondary FEP.

NRZ and NRZI Encoding

The NRZI parameter specifies whether the FEP should operate in nonreturn-to-zero inverted (NRZI) mode or in nonreturn-to-zero (NRZ) mode. Both techniques encode binary data on a synchronous serial line. The specification depends on the way the modem operates. Old modems and satellite links that are not sensitive to a pattern of repeated binary ones and zeros (that is, 101010...) operate in NRZI mode. Modems that are sensitive to repeated patterns operate in NRZ mode.

The NCP statement that configures the FEP for NRZI is NRZI=YES, which is the default and is correct for most IBM modems. The NCP statement that configures the FEP for NRZ is NRZI=NO, which is correct for most non-IBM modems.


Note Note: All devices on the same SDLC link must use the same encoding scheme.


MODULO and MAXOUT Parameters

The MODULO parameter specifies the number of information frames (I-frames) that NCP can send to the remote device before receiving an acknowledgment. The statement MODULO=8 allows NCP to send seven unacknowledged I-frames, whereas the statement MODULO=128 and the statement MAXOUT=127 allows NCP to send 127 unacknowledged I-frames. (Note that when the MODULO parameter is set to 128, the NCP MAXOUT parameter specifies the number of I-frames that can be sent before receiving an acknowledgment. MAXOUT can range from 8 [the default] to 127.)

Typically, network administrators configure NCP to allow a high number of outstanding I-frames (that is, MODULO=128 and MAXOUT=127) for slow links or for satellite links. Allowing a high number of outstanding I-frames uses the link more efficiently by reducing the number of acknowledgments and by preventing session timeouts. When the MODULO parameter is 128, make sure the TCP output queue on the router is greater than 128.

The SDLC STUN implementation supports setting the MODULO parameter to 8 as well as 128. Note, however, that setting the MODULO parameter to any legal value other than 8 causes the router to use additional buffers to store unacknowledged I-frames.

When local acknowledgment is configured to reduce supervisory frame traffic and to prevent session timeouts, 8 is the only supported value of the MODULO parameter. When the MODULO value is 8, the router does not use additional buffers unnecessarily.

ADDRESS Parameter

The ADDRESS parameter has the following format: ADDRESS=(line-number, mode).

If mode is FULL, the FEP can send and receive data at the same time. When mode is HALF, the FEP is limited to sending data and then receiving data. The default value of mode is FULL. The value of mode affects the operation of the DUPLEX parameter. For more information, see the "DUPLEX Parameter" section later. The value of line-number specifies the channel adapter position or the relative line number of all the telecommunication links defined for this NCP.

When implementing SDLC STUN or SDLC-Transmission Group STUN, the network administrator must specify SDLC addresses in the configuration of the router. The addresses specified in the router configuration are based on the order in which the ADDRESS parameter appears in the NCP configuration. Consider the following NCP configuration:

********************************************************************* 

*        LOCAL NCP LINKS -- PRIMARY FEP                             * 

********************************************************************* 
                                                                      
LINK04   GROUP LNCTL=SDLC,                GROUP LEVEL               X 
               NPACOLL=YES,               <== 3745 Dallas           X 
               DUPLEX=FULL,                                         X 
               NEWSYNC=NO,                                          X 
               NRZI=NO,                                             X 
               SDLCST=(CPRI4,CSEC4),                                X 
               RETRIES=(10,5,10),         PU LEVEL                  X 
               IRETRY=YES,                                          X 
               MAXOUT=7,                                            X 
               PASSLIM=254,                                         X 
               SERVLIM=254,                                         X 
               ISTATUS=ACTIVE,            VTAM-ONLY LEVEL           X 
               OWNER=CMC                                              
*                                                                     
*-------------------------------------------------------------------- 
*                                                                     
X1010442 LINE  ADDRESS=(005,FULL)         <== 3745 Chicago (01)       
S1010442 PU    PUTYPE=4                                               
*                                                                     
X1030442 LINE  ADDRESS=(132,FULL)         <== 3745 Raleigh (02)       
S1030442 PU    PUTYPE=4                                               
*                                                                     
X1010446 LINE  ADDRESS=(068,FULL),MODULO=128,ISTATUS=ACTIVE, <== 3745 Houston (03) X 
               SPEED=56000,SDLCST=(S04PRI,S04SEC)                     
S1010446 PU    PUTYPE=4,MAXOUT=63                                     
*                                                                     
X1020412 LINE  ADDRESS=(100,FULL),MODULO=128,ISTATUS=ACTIVE, <== 3745 Lafayette (04) X 
               SPEED=56000,SDLCST=(S04PRI,S04SEC)                     
S1020412 PU    PUTYPE=4,MAXOUT=63                                     
*                                                                     
X1010412 LINE  ADDRESS=(112,FULL),SPEED=56000,ISTATUS=ACTIVE <== 3745 Atlanta (05) X 
S1010412 PU    PUTYPE=4                                               
*                                                                     
X1010462 LINE  ADDRESS=(080,FULL),       <== 3745 San Francisco (06) X 
               NRZI=NO,                                              X 
               NEWSYNC=NO,                                           X 
               DUPLEX=FULL,                                          X 
               ISTATUS=ACTIVE,                                       X 
               SERVLIM=254,                                          X 
               SDLCST=(S04PRI,S04SEC),                               X 
               MODULO=128,                                           X 
               SPEED=56000                                             
S1010462 PU    PUTYPE=4,                                             X 
               MAXOUT=63                                               
*                                                                      
********************************************************************** 

Given this configuration, the router configuration uses address 01 for Chicago, address 02 for Raleigh, address 03 for Houston, address 04 for Lafayette, address 05 for Atlanta, and address 06 for San Francisco.

DUPLEX Parameter

The DUPLEX parameter specifies whether the communication line and the modem operate in full- or half-duplex mode, and controls the Request To Send (RTS) signal. If the ADDRESS parameter specifies that the mode is FULL, the value of the DUPLEX parameter has no effect, and RTS is always high (that is, permanent RTS). If the ADDRESS parameter specifies that the mode is HALF, the following applies:

  • The statement DUPLEX=FULL causes RTS to be permanently high regardless of whether the FEP is sending or receiving data.
  • The statement DUPLEX=HALF causes RTS to be high only when the FEP is sending data.

Enhanced NCP Features

This section describes the following enhanced NCP features that are supported by Cisco routers: transmission groups, echo addressing, and remote NCP loading. Note, however, that the basic STUN and SDLC STUN implementations do not support transmission groups.

Transmission Groups

A transmission group is one or more parallel SDLC links that connect FEPs. Transmission groups increase the reliability of the logical link connection between FEPs and provide additional bandwidth. When one link fails or congests, NCP uses one of the other links in the group to send data (see Figure: Map of a network that uses transmission groups).

Figure: Map of a network that uses transmission groups

Nd202002.jpg

NCP uses virtual routes to provide more than one route between two FEPs. This multiple active routing mechanism increases the probability that an SDLC route is available when a session needs to be established.


Note Note: SDLC-TG STUN is the only implementation that supports transmission groups.


Echo Addressing

Later versions of NCP use echo addressing. With echo addressing, the secondary FEP sets the high-order bit of the SDLC address when sending a response to the primary FEP. For example, the primary FEP sends frames with address 0x01, and the secondary FEP sends frames with address 0x81. This addressing scheme limits the range of SDLC addresses from 0x01 to 0x7F. Although echo addressing is a violation of the SDLC standard, it is supported because it occurs only between FEPs.


Note Note: Echo addressing is implicitly supported by the basic STUN implementation because that implementation does not perform any address checking. The echo keyword of the sdlc address interface configuration command configures support for echo addressing in the SDLC STUN and SDLC-TG STUN implementations.


Remote NCP Loading

When a local FEP is loading a remote FEP with a new NCP configuration, the local FEP uses a nonstandard form of SDLC to complete the remote NCP load. This violation of the SDLC standard is supported because it occurs only between FEPs.


Note Note: The basic STUN implementation implicitly supports remote NCP loading. When used with the stun protocol-group command, the sdlc-tg keyword automatically includes support for remote NCP loading in the SDLC-TG STUN implementation.


Understanding FEP-to-FEP Communications with Routers

Figure: Map showing the addition of routers illustrates the topology of an FEP-based network that includes routers. In this multiprotocol topology, the routers already handle traffic between Token Rings and the IBM host. When used to handle traffic between the FEPs, the routers replace the modems and lines that formerly connected the FEPs.

Figure: Map showing the addition of routers

Nd202003.jpg

An EIA/TIA-232 (formerly RS-232) cable or a V.35 cable connects each router to its FEP, and a serial T1 line connects each router to the wide-area network (WAN). The FEPs continue to act as DTE devices, and, by providing clocking and synchronization, the serial interfaces on the routers act as DCE devices.

Advanced Router Features

When configured for STUN, Cisco routers can take advantage of the following advanced router features: priority queuing, custom queuing, and local acknowledgment.


Note Note: When priority queuing or custom queuing is enabled, the router takes longer to switch packets because the processor card has to classify each packet.


Priority Queuing

Priority queuing allows the network administrator to set priorities on the traffic that passes through the network. Packets are classified according to various criteria, including protocol and subprotocol type, and then queued on one of four output queues: high, medium, normal, or low.

A FEP-to-FEP STUN implementation can use priority queuing to prioritize SNA traffic over other protocols that share the same link. The following commands distribute transmission control protocol (TCP) traffic among the four queues and assign STUN traffic encapsulated in TCP to the high queue:

 priority-list 1 ip high tcp 1994 
priority-list 1 ip medium tcp 1990 
priority-list 1 ip normal tcp 1991 
priority-list 1 ip low tcp 1992 
priority-list 1 stun high 
! 
interface serial 0 
encapsulation stun 
stun group 1 
sdlc address 01 
stun route address 01 tcp 1.1.1.2 local-ack 
priority-group 1 


Note Note: Configure the priority-group interface configuration command on the STUN input interface.


Custom Queuing

Custom queuing, available in Software Release 9.21 and subsequent software releases, is a queuing strategy that imparts a measure of fairness not provided by priority queuing. The network administrator can control on each interface the minimum percentage of bandwidth allocated to a particular kind of traffic.

When custom queuing is enabled on an interface, the router maintains for that interface eleven output queues (numbered 0 to 10). The router reserves queue number 0 for its own use. The router cycles sequentially through queue numbers 1 to 10, delivering packets in the current queue before moving to the next queue.

Each output queue has an associated configurable byte count that specifies how many bytes of data the router should deliver from the current queue before it moves to the next queue. When the router processes a particular queue, it sends packets until the number of bytes sent exceeds the queue byte count or until the queue is empty.

Custom queuing can be used instead of, but not in addition to, the priority-group interface configuration command in a single interface. The following configuration commands place STUN traffic on queue 1 with a byte-count limit of 4000 bytes and a maximum of 40 queues:

stun peer-name 1.1.1.1 
stun protocol-group 1 sdlc-tg 
! 
interface serial 0 
encapsulation stun 
stun route address 01 tcp 1.1.1.2 local-ack 
! 
interface serial 1 
encapsulation hdlc 
custom-queue-list 1 
! 
queue-list 1 protocol stun 1 
queue-list 1 protocol novell 2 
queue-list 1 default 3 
queue-list 1 queue 1 byte-count 4000 
queue-list 1 queue 1 limit 40 


Note Note: Configure the custom-queue-list interface configuration command on the output interface that connects to the WAN.


Local Acknowledgment

Local acknowledgment is a router feature that prohibits supervisory frames from traversing the WAN, as shown in Figure: Local acknowledgment limits the range of supervisory frames.

Figure: Local acknowledgment limits the range of supervisory frames

Nd202004.jpg

Cisco recommends the use of local acknowledgment when one or both of the following conditions exist:

  • WAN link use is high-When local acknowledgment is configured, supervisory frames, such as Receiver Ready (RR), Receiver Not Ready (RNR), and Reject (REJ), do not traverse the WAN link. Instead, supervisory frames are locally acknowledged by the router, which reduces the amount of traffic on the WAN link.
  • Network delay causes NCP timers to expire-Link congestion, busy local-area networks, or high end-station use can cause excessive network delays, which can result in delayed acknowledgment of I-frames. When configured for local acknowledgment, the router acknowledges I-frames locally, which helps to prevent NCP timers from timing out and closing existing sessions.

Basic STUN

Basic STUN is easy to configure because it does not require the router configuration to match line addresses that may be configured on the FEPs. The mainframe sends data to the primary FEP, which passes the data to its router. The router for the primary FEP passes the data over an arbitrary medium (serial, fiber distributed data interface [FDDI], Token Ring, or Ethernet) to the router for the secondary FEP, and the router for the secondary FEP sends the data to the secondary FEP. Data from the secondary FEP flows to the mainframe by the reverse path. Network administrators use basic STUN for three purposes:

  • To accommodate existing addressing schemes-Some NCP configurations use nonstandard addresses. For example, some configurations use address 0x00 or 0xFF for broadcasts and address 0xC1 for communication. By configuring the router for basic STUN, the network administrator does not have to configure the router to match existing addressing schemes.
  • To test connectivity-When network administrators plan to implement SDLC STUN or SDLC-TG STUN, they often implement basic STUN first to verify physical connections.
  • To improve performance-Because basic STUN requires minimal processing, it passes frames faster than SDLC STUN and SDLC-TG STUN.

The basic STUN implementation has the following limitations:

  • Lack of support for transmission groups, as well as lack of support for advanced router features. For information about advanced router features, see the "SDLC-Transmission Group STUN" section later in this article.
  • Limited output from the router debugging commands.
  • Lack of support for multidrop environments. (However, multidrop support is usually a requirement for cluster controller environments rather than FEP environments.)

Basic STUN Configuration: Example 1

In Figure: Topology for basic STUN: example 1, the routers pass data over an IP WAN. The FEPs are configured for DTE, full-duplex mode, and NRZ encoding. The serial interfaces on the routers are configured for DCE.

Figure: Topology for basic STUN: example 1

Nd202005.jpg

The following commands configure basic STUN (example 1) for Router A:

stun peer-name 1.1.1.1 
stun protocol-group 1 basic 
! 
interface serial 0 
no ip address 
encapsulation stun 
stun group 1 
stun route all tcp 1.1.2.1 
clockrate 19200  
! 
interface tokenring 0 
ip address 1.1.4.1 255.255.255.0 
! 
interface serial 1 
ip address 1.1.3.1 255.255.255.0 
! 
interface loopback 0 
ip address 1.1.1.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

The following commands configure basic STUN (example 1) for Router B:

stun peer-name 1.1.2.1 
stun protocol-group 1 basic 
! 
interface serial 0 
no ip address 
encapsulation stun 
stun group 1 
stun route all tcp 1.1.1.1 
clockrate 19200 
  
interface tokenring 0 
ip address 1.1.5.1 255.255.255.0 
! 
interface serial 1 
ip address 1.1.3.2 255.255.255.0 
! 
interface loopback 0 
ip address 1.1.2.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

Basic STUN Configuration: Example 2

In Figure: Topology for basic STUN: example 2, the routers transmit data over a Frame Relay WAN. The FEPs are configured for DTE, full-duplex mode, and NRZI encoding. The serial interfaces on the routers are configured for DCE.

Figure: Topology for basic STUN: example 2

Nd202006.jpg

The following commands configure basic STUN (example 2) for Router A:

stun peer-name 1.1.1.1 
stun protocol-group 1 basic 
! 
interface serial 0 
no ip address 
encapsulation stun 
stun group 1 
stun route all tcp 1.1.2.1 
nrzi-encoding 
clockrate 56000 
! 
interface tokenring 0 
ip address 1.1.4.1 255.255.255.0 
! 
interface serial 1 
ip address 1.1.3.1 255.255.255.0 
encapsulation frame-relay 
frame-relay map ip 1.1.3.2 40 broadcast 
! 
interface loopback 0 
ip address 1.1.1.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

The following commands configure basic STUN (example 2) for Router B:

stun peer-name 1.1.2.1 
stun protocol-group 1 basic 
! 
interface serial 0 
no ip address 
encapsulation stun 
stun group 1 
stun route all tcp 1.1.1.1 
nrzi-encoding 
clockrate 56000 
! 
interface tokenring 0 
ip address 1.1.5.1 255.255.255.0 
interface serial 1 
ip address 1.1.3.2 255.255.255.0 
encapsulation frame-relay 
frame-relay map ip 1.1.3.1 40 broadcast 
! 
interface loopback 0 
ip address 1.1.2.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 


Note Note: NRZ encoding is the default for all Cisco routers. NRZI encoding is software configurable for Cisco 250x, Cisco 3x04, Cisco 4000 4T, and Cisco 7000 routers. NRZI encoding is hardware configurable for Cisco 4000 2T and AGS+ routers. Full-duplex mode is the default for all router serial cards. Half-duplex mode is software configurable for the Cisco 4000 4T and Cisco 250x routers and is hardware configurable on the EIA/TIA-232/H applique for the AGS+.


SDLC STUN

SDLC STUN is the most commonly used tunneling configuration in Cisco multiprotocol networks. It is frequently implemented for gateways and cluster controllers. SDLC STUN uses the standard SDLC protocol. In most cases, IBM FEPs and compatible FEPs comply with that standard. If an FEP uses a nonstandard form of SDLC, the router must be configured for basic STUN.

The SDLC STUN implementation requires coordination of SDLC addresses between the router and the NCP configuration. To configure the router for SDLC STUN, the network administrator must know the relative position of the ADDRESS parameters in the NCP configuration. For details, see the earlier "ADDRESS Parameter" section. Network administrators use SDLC STUN for two purposes:

  • To support specific addressing schemes-SDLC STUN allows the network administrator to configure specific line addresses. SDLC STUN is required in certain environments, such as multidrop, that depend on specific addresses.
  • To support network tuning and monitoring-Occasionally, the network administrator needs to tune and monitor the SNA SDLC and multiprotocol network.

SDLC STUN is limited by its lack of support for transmission groups.

Configuring SDLC STUN

In Figure: SDLC STUN topology, the routers transmit data over a serial line. The FEPs are configured for DTE, full-duplex mode, and NRZ encoding. The router serial interfaces are configured as DCE devices.

Figure: SDLC STUN topology

Nd202007.jpg

The following commands configure SDLC STUN for Router A:

stun peer-name 1.1.1.1 
stun protocol-group 1 sdlc 
! 
interface serial 0 
no ip address 
encapsulation stun 
sdlc address 04 
stun route address 04 interface s1 
stun route address ff interface s1 
clockrate 19200 
! 
interface tokenring 0 
ip address 1.1.4.1 255.255.255.0 
! 
interface serial 1  
ip address 1.1.3.1 255.255.255.0 
! 
interface loopback 0 
ip address 1.1.1.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

The following commands configure SDLC STUN for Router B:

stun peer-name 1.1.2.1 
stun protocol-group 1 sdlc 
! 
interface serial 0 
no ip address 
encapsulation stun 
sdlc address 04 
stun route address 04 interface s1 
stun route address ff interface s1 
clockrate 19200 
! 
interface tokenring 0 
ip address 1.1.5.1 255.255.255.0 
! 
interface serial 1 
ip address 1.1.3.2 255.255.255.0 
! 
interface loopback 0 
ip address 1.1.2.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

SDLC-Transmission Group STUN

SDLC-Transmission Group (TG) STUN is a complex implementation that supports enhanced NCP features.When configuring STUN-TG, many network administrators also configure the routers to take advantage of the advanced features described in the "Advanced Router Features" section earlier in this article. Because these features increase memory and processor use, they should be used only when necessary to support the existing network or to relieve congestion. SDLC-TG STUN forces local acknowledgment. If you do not want to configure local acknowledgment, use the basic STUN or the SDLC STUN implementation.

The SDLC-TG implementation requires coordination of SDLC addresses between the router and the NCP configuration. To configure the router for SDLC-TG, the network administrator must know the relative position of the ADDRESS parameters in the NCP configuration. For details, see the "ADDRESS Parameter" section earlier in this article.

Configuring SDLC-TG STUN

Figure: The SDLC-TG STUN topology illustrates a network that implements SDLC-TG STUN. The routers transmit data over an IP WAN. The FEPs are configured for DTE, full-duplex mode, and NRZ encoding. The serial interfaces on the routers are configured as DCE devices.

Figure: The SDLC-TG STUN topology

Nd202008.jpg

To the primary FEP, Router A looks like a secondary FEP. To the secondary FEP, Router B looks like a primary FEP. The following commands configure SDLC-TG STUN for Router A:

stun peer-name 1.1.1.1 
stun remote-peer-keepalive 
stun protocol-group 1 sdlc-tg 
! 
interface tokenring 0 
ip address 1.1.4.1 255.255.255.0 
! 
interface serial 1 
mtu 4400 
hold-queue 150 in 
no ip address 
encapsulation stun 
stun group 1 
stun sdlc-role secondary 
sdlc n1 35200 
sdlc address 01 echo 
stun route address 1 tcp 1.1.2.1 local-ack tcp-queue-max 120 
clockrate 56000 

interface serial 2 
mtu 4400 
hold-queue 150 in 
no ip address 
encapsulation stun 
stun group 1 
stun sdlc-role secondary 
sdlc n1 35200 
sdlc address 02 echo 
stun route address 2 tcp 1.1.2.1 local-ack tcp-queue-max 120 
clockrate 56000 
! 
interface serial 3 
ip address 1.1.3.1 
interface loopback 0 
ip address 1.1.1.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

The following commands configure SDLC-TG STUN for Router B:

stun peer-name 1.1.2.1 
stun remote-peer-keepalive  
stun protocol-group 1 sdlc-tg 
! 
interface tokenring 0 
ip address 1.1.5.1 255.255.255.0 
! 
interface serial 1 
mtu 4400 
hold-queue 150 in 
no ip address 
encapsulation stun 
stun group 1 
stun sdlc-role primary 
sdlc line-speed 56000 
sdlc n1 35200 
sdlc address 01 echo 
stun route address 1 tcp 1.1.1.1 local-ack tcp-queue-max 120 
clockrate 56000 
! 
interface serial 2 
mtu 4400 
hold-queue 150 in 
no ip address 
encapsulation stun 
stun group 1 
stun sdlc-role primary 
sdlc line-speed 56000 
sdlc n1 35200 
sdlc address 02 echo 
stun route address 2 tcp 1.1.1.1 local-ack tcp-queue-max 120 
clockrate 56000 
! 
interface serial 3 
ip address 1.1.3.2 
! 
interface loopback 0 
ip address 1.1.2.1 255.255.255.0 
! 
router igrp 1 
network 1.0.0.0 

The stun peer-name global configuration command identifies this router as a peer to its peer group.

The stun remote-peer-keepalive global configuration command causes Router A and Router B to exchange keepalive messages on each idle line. (An idle line is a line over which no I-frames are flowing.) Keepalive messages allow a router to detect when its peer router is not longer available. A peer router might become unavailable if it goes down or if the line goes down. The routers do not send keepalive traffic to the FEPs.

Routers send keepalive messages over an idle line at a default interval of 30 seconds and waits three times that interval for a response. If the router does not receive a response, it closes the STUN session.

The stun protocol-group global configuration command establishes a protocol group that is part of an SNA transmission group. The sdlc-tg keyword can be used only when the stun route address tcp interface configuration command is used to configure local acknowledgment and TCP encapsulation. The SDLC broadcast address 0xFF is routed automatically for interfaces on which the sdlc-tg keyword is configured. The stun protocol-group global configuration command also alerts the router that it should support transmission group features, such as the following:

  • Echo addressing
  • Transmission group rerouting if a single link in a multilink transmission group goes down
  • Remote NCP load
  • Broadcast addressing

The mtu interface configuration command specifies a maximum transmission unit (MTU) of 4400 bytes, which is the highest recommended value, for the interface. The value of the NCP MAXDATA parameter should be no more than the MTU on the router interface. The recommended value of MAXDATA is 4096 bytes.


Note Note: Depending on the version of NCP, the MAXDATA parameter may or may not take into account the number of bytes in the frame header (which, for example, includes the source and destination address of the frame), so the MTU on the router interface should be at least 100 bytes larger than the value of MAXDATA in the NCP configuration.


The hold-queue interface configuration command increases the size of the input hold queue from 75 packets (the default) to 150 packets. The specified value should be greater than the depth of the TCP output queue (as specified by the tcp-queue-max keyword of the stun route address tcp interface configuration command). Increasing the size of the input hold queue allows flow control to activate when the TCP output queue reaches a threshold of 90 percent, which occurs before the input interface throttling mechanism can activate.

The stun sdlc-role primary interface configuration command is used when the router is connected to a secondary FEP. The stun sdlc-role secondary interface configuration command is used when the router is connected to a primary FEP.

On the primary router, the sdlc line-speed interface configuration command adjusts the SDLC poll timer based on the line speed. The line speed argument should be equal to the speed of the line connected to the interface, regardless of whether the interface is configured as a DCE or a DTE.

The sdlc n1 interface configuration command specifies the maximum size (in bits) of an incoming frame on the SDLC link and is required when the MTU is not 1500 bytes (the default). The sdlc n1 command must be eight times larger than the value specified by the stun command.

The sdlc address interface configuration command specifies an SDLC address. The specified address must be the same as the relative line number at which the ADDRESS parameter is specified in the NCP configuration of the FEP to which the router is connected. (For more information, see the "ADDRESS Parameter" section earlier in this article.) The echo keyword causes the router to treat nonecho (for example, 0x01) and echo (for example, 0x81) SDLC addresses as the same address. The sdlc address interface configuration command is valid only for interfaces on which the stun protocol-group command with the sdlc-tg keyword is configured. Only one sdlc address interface configuration command with echo keyword is required per interface.

The stun route address tcp interface configuration command specifies TCP encapsulation. The value of address specifies the SDLC address, which must be specified with the echo bit turned off. The local-ack keyword causes the router to perform local acknowledgment and is required when the sdlc-tg keyword appears with the stun protocol-group command. The tcp-queue-max keyword sets the maximum size of the TCP output queue for a serial line. The default is 100 packets. The recommended minimum is 70, and the recommended maximum is 500. The clockrate interface configuration command specifies the clocking speed when the serial interface is in DCE mode.

Summary

This case study presents three types of STUN implementations in SNA environments: basic STUN, SDLC STUN, and SDLC-TG STUN. Although basic STUN is the easiest to configure because it does not require the configuration of line addresses on the router, it does not support local acknowledgment. Compared to basic STUN, the SDLC STUN implementation is the most flexible because it supports, but does not require, local acknowledgment. However, the use of SDLC STUN is limited because it does not support transmission groups. SDLC-TG STUN is not as flexible as SDLC STUN because it enforces local acknowledgment. At the same time, SDLC-TG STUN is the only STUN implementation that supports transmission groups.

Rating: 4.0/5 (1 vote cast)

Personal tools