IBM BC-201 User Manual
Overview of IBM Networking
The IBM networking technologies described in this publication can be categorized as network-related
or host-related technologies. The IBM Networking section of the Cisco IOS Bridging and IBM
Networking Configuration Guide discusses the following network-related software components:
• RSRB, page 202
• DLSw+, page 204
• STUN and BSTUN, page 211
• LLC2 and SDLC Parameters, page 215
• IBM Network Media Translation, page 217
• SNA FRAS, page 223
• NCIA, page 226
• ALPS, page 229
The IBM Networking section of the Cisco IOS Bridging and IBM Networking Configuration Guide
discusses the following host-related software and hardware components:
• DSPU and SNA Service Point, page 230
• SNA Switching Services, page 232
• Cisco Transaction Connection, page 239
• CMCC Adapter Hardware, page 242
The following Cisco IOS software features are supported on the CMCC adapters:
–
Common Link Access to Workstation, page 245
–
TCP/IP Offload, page 245
–
IP Host Backup, page 246
–
Cisco Multipath Channel+, page 246
–
Cisco SNA, page 247
–
Cisco Multipath Channel, page 248
–
TN3270 Server, page 248
This overview chapter gi v es a high-level description of each technology. For configuration information,
refer to the corresponding chapters in this publication.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-201
RSRB
S2327
RSRB
Overview of IBM Networking
Note All commands supported on the Cisco 7500 series routers are also supported on the Cisco 7000 series
routers.
In contrast to Source-Route Bridging (SRB), which involves bridging between Token Ring media only,
RSRB is a Cisco technique for connecting T ok en Ring networks o ver non-Token Ring network segments.
(DLSw+ is the Cisco strategic method for providing this function.)
The Cisco RSRB software implementation includes the following features:
• Provides for multiple routers separated by non-Token Ring segments. Three options are available:
–
Encapsulate the Token Ring traffic inside IP datagrams passed over a Transmission Control
Protocol (TCP) connection between two routers.
–
Use Fast-Sequenced Transport (FST) to transport RSRB packets to their peers without TCP or
User Datagram Protocol (UDP) header or processor overhead.
–
Use data link layer encapsulations over a single serial line, Ethernet, Token Ring, or Fiber
Distributed Data Interface (FDDI) ring connected between two routers attached to Token Ring
networks.
• Provides for configurable limits to the size of the TCP backup queue.
Figure 85 shows an RSRB topology. The virtual ring can extend across any non-Token Ring media
supported by RSRB, such as serial, Ethernet, FDDI, and WANs. The type of media you select determines
the way you set up RSRB.
Figure 85 RSRB Topology
Virtual ring
Token
Ring
Token
Ring
Note If you bridge across Token Ring media, it is recommended that you do not use RSRB. Use SRB
Non-Token Ring
Media
Token
Ring
Token
Ring
instead. Refer to the chapter “Configuring Source-Route Bridging” for more information.
BC-202
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Overview of IBM Networking
Configuration Considerations
Use IP encapsulation only over a TCP connection within complex meshed networks to support
connections between peers that are separated by multiple hops and can potentially use multiple paths,
and where performance is not an issue. Use direct encapsulation in point-to-point connections. In a
point-to-point configuration, using TCP adds unnecessary processing overhead. Multiple peer types,
however, can be combined to in a single router by following the directions for each peer type. For
example, for a peer to support both TCP and FST remote-peers, you would need to define both a
source-bridge fst peername and a source-bridge remote-peer command for the local router, using the
same local IP address.
FST is fast-switched when it receives or sends frame s from Ethernet, Token Ring, or FDDI interfaces. It
is also fast-switched when it sends and receives from serial interfaces configured with the High-Level
Data Link Control (HDLC) encapsulat ion. In all other cases, FST is s low-switched.
In cases where FST is fast-switched, in either the Cisco routers configured for FST or in the routers
contained within the IP “cloud” between a pair of FST peers, only one path is used at a given time
between the two FST peers. A single path greatl y decrease s the likelihood that frames arrive out of
sequence. In the rare cases where frames do arrive out of sequence, the FST code on the receiving peer
discards the out-of-order frame. Thus the Token Ring end hosts rarely lose a frame over the FST router
cloud, and performance levels remain adequate.
The same conditions are true for any slow-switched topology that provides only a single path (for
example, a single X.25 network cloud) between the peers. Similarly, if two slow-switched paths are of
very different costs such that one always will be chosen over the other, the chances of having frames
received out of sequence are also rare.
RSRB
However, if two or more slow-switche d paths of eq ual cost exist be tween the two routers (such a s two
parallel X.25 networks), the routers alternate in s ending packets between the two or more equal-cost
paths. This results in a high probability of frames arri ving out of sequence at the recei v er. In such cases,
the FST code disposes of every out-of-sequence packet, leadi ng to a large number of drops. This requires
that the end hosts resend frames, greatly reducing overall throughput.
When parallel paths exist, we strongly recommend choosing one as the preferred path. Choose a
preferred path by specifying a higher bandw idth for th e path t hat con tains t he direct co nnec tions to the
two or more parallel paths on the router.
Do not use FST when the probability exists for frames to lose their order in your network. If you have a
network where frames are routinely reordered, it is better to use the TCP protocol for RSRB. TCP
provides the overhead necessary to bring frames back in order on the receiving router. FST, to remain
fast, does not provide for such a mechanism, and will discard out-of-order frames.
Logical Link Control, type 2 (LLC2) local acknowle dgment can be enabled only with TCP remote peers
(as opposed to LAN or direct serial interface remote peers) because the Cisco IOS software needs the
reliability of TCP to provide the same reliability that an LLC2 LAN end-to-end connection provides.
Therefore, the direct media encapsulation options for the source-bridge re mote-peer command cannot
be used.
If the LLC2 session between the local host and the router terminat es on either side of the co nnection, the
other device 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, they
send Receiver-not-Ready (RNR) messages to the local hosts until the queue limit is reduced to below
this limit.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall
performance. Refer to the “Configuring LLC2 and SDLC Parameters” chapter for more details about
fine-tuning your network through the LLC2 parameters.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-203
DLSw+
Overview of IBM Networking
Note As previously stated, local acknowledgment for LLC2 is meant only for extreme cases in which
communication is not possible otherwise. Because the router must maintain a full LLC2 session, the
number of simultaneous sessions it can support before performance degrades depends on the mix of
other protocols and their loads.
The routers at each end of the LLC2 session execute the full LLC2 protocol, which can result in some
overhead. The decision to turn on local acknowledgment for LLC2 should be based on the speed of the
backbone network in relation to the T ok en Ring speed. For LAN segments separated b y slow-speed serial
links (for example, 56 kbps), the T1 timer problem could occur more frequently. In such cases, it might
be wise to turn on local acknowledgment for LLC2. For LAN segments separated by a FDDI backbone,
backbone delays will be minimal; in such cases, local acknowledgment for LLC2 should not be turned
on. Speed mismatch between the LAN segments an d the backbone netw ork is on e criterio n to be used in
the decision to use local acknowledgment for LLC2.
There are some situations (such as host B failing between the time host A sends data and the time host
B receives it) in which host A would behave as if, at the LLC2 layer, data was received when it actually
was not, because the device acknowledges that it received data from host A before it confirms that host
B can actually receive the data. But because both NetBIOS and SNA have error recovery in situations
where an end device goes down, these higher-level protocols will resend any missing or lost data. These
transaction request/confirmation pr otocols e xist abo ve LLC2 , so the y are not af fected by ti ght timers, as
is LLC2. They also are transparent to local acknowledgment.
If you are using NetBIOS applications, note that there are two NetBIOS timers—one at the link level
and one at the next higher level. Local acknowledgment for LLC2 is designed to solv e session timeouts
at the link level only. If you are experiencing NetBIOS session timeouts, you have two options:
• Experiment with increasing your NetBIOS timers.
DLSw+
• Avoid using NetBIOS applications on slow serial lines.
In a configuration scenario where RSRB is configured between Router A and Router B and both routers
are not routing IP, a Host connected to router A through Token Ring (or other LAN media) has no IP
connectivity to router B. This restriction exists because IP datagrams received from the Host by Router
A are encapsulated and sent to router B where they can only be de-encapsulat ed and sourc e-bridged to
a Token Ring. In this scenario, IP routing is recommended. To enable the Host to reach Router B in this
scenario, IP routing should be enabled on Router A’s Token Ring interface to which the Host is attached.
Data-Link Switching Plus (DLSw+) is a method of transpo rting SN A and NetBIOS. It complies wi th the
DLSw standard documented in RFC 1795 and the DLSw Version 2 standard. DLSw+ is an alternative to
RSRB that addresses several inherent problems that exist in RSRB, such as:
• SRB hop-count limits (SRB’s limit is seven)
• Broadcast traffic (including SRB explorer frames or NetBIOS name queries)
• Unnecessary traffic (acknowledgments and keepalives)
• Data-link control timeouts
BC-204
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Overview of IBM Networking
This section contains a brief overview of DLSw+:
DLSw Standard
The DLSw standard, documented in RFC 1795, defines the switch-to-switch protocol between DLSw
routers. The standard also defines a mechanism to terminate data-link control connections locally and
multiplex the traffic from the data-link control connections to a TCP connection. The standard always
calls for the transport protocol to be TCP and always requires that data-link control connections be
locally terminated (the equiv alent of the Cisco l ocal acknowled gment option). The standard also requi res
that the SRB RIF be terminated at the DLSw router. The standard describes a means for prioritization
and flow control and defines error recovery procedures that ensure data-link control connections are
appropriately disabled if any part of their associated circuits breaks.
The DLSw standard does not specify when to establish TCP connections. The capabilities exchange
allows compliance to the standard, bu t at different levels of support. The standard does not specify how
to cache learned information about MAC addresses, RIFs, or NetBIOS names. It also does not describe
how to track either capable or preferred DLSw partners for either backup or load-balancing purposes.The
standard does not provide the specifics of media conversion, but leaves the details up to the
implementation. It does not define how to map switch congestion to the flow control for data-link
control. Finally, the MIB is documented under a separate RFC.
DLSw+
• DLSw Standard, page 205
• DLSw Versio n 2 Standard, pa ge 205
• DLSw+ Features, page 206
DLSw Version 2 Standard
In the Version 1 standard, a network design requires fully meshed connectivity so that all peers were
connect to every other peer. This design creates unnecessary broadcast traffic because an explorer
propagates to every peer for every broadcast.
The Version 2 standard is documented in RFC 2166. It includes RFC 1795 and adds the following
enhancements:
• IP Multicast, page 206
• UDP Unicast, page 206
• Enhanced Peer-on-Demand Routing Feature, page 206
• Expedited TCP Connection, page 2 06
Users implement DLSw+ Version 2 for scalability if they are using multivendor DLSw devices with an
IP multicast network. DLSw Version 2 requires complex planning because it involves configuration
changes across an IP network.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-205
DLSw+
IP Multicast
UDP Unicast
Overview of IBM Networking
Multicast service avoids duplication and excessive bandwidth of broadcast traffic because it replicates
and propagates messages to its multicast members only as necessary. It re duces the amount of network
overhead in the following ways:
• A v oids the need to maintain TCP Switch-to-Switch Protocol (SSP) connections between two DLSw
peers when no circuits are available
• Ensures that each broadcast results in only a single explorer over every link
DLSw Version 2 is for customers who run a multicast IP network and do not need the advantages of
border peering.
DLSw Version 2 uses UDP unicast in response to a IP multicast. When address resolution packets
(CANUREACH_EX, NETBIOS_NQ_ex, NETBIOS_ANQ, and DATAFRAME) are sent to multiple
destinations (IP multicast service) DLSw Version 2 sends the response frames (ICANREACH_ex and
NAME_RECOGNIZED_ex) via UDP unicast.
Enhanced Peer-on-Demand Routing Feature
DLSw V ersion 2 establishes TCP connections only when necessary and the TCP connections are brought
down when there are no circuits to a DLSw peer for a specified amount of time. This method, known as
peer-on-demand routing, was recently introduced in DLSw Version 2, but has been implemented in Cisco
DLSw+ border peer technology since Cisco IOS Release 10.3.
Expedited TCP Connection
DLSw Version 2 efficiently establishes TCP connections. Previously, DLSw created two unidirectional
TCP connections and then disconnected one after the capabilities exchange took place. With DLSw
Version 2, a single bidirectional TCP connection establishes if the peer is brought up as a result of an IP
multicast/UDP unicast information exchange.
DLSw+ Features
DLSw+ is the Cisco version of DLSw and it supports several additional features and enhancements.
DLSw+ is a means of transporting SNA and NetBIOS traffic over a campus or WAN. The end systems
can attach to the network over T ok en Ring, Ethernet, Synchronous Data Link Control (SDLC) Protocol,
Qualified Logical Link Control (QLLC), or FDDI. See the DLSw+ Design and Implementation Guide
Appendix B, “DLSw+ Support Matrix, ” fo r details. DLSw+ switches between div erse media and locally
terminates the data links, keeping acknowledgments, keepalives, and polling off the WAN. Local
termination of data links also eliminates data-link control timeouts that can occur during transient
network congestion or when rerouting around failed links. Finally, DLSw+ provides a mechanism for
dynamically searching a network for SNA or NetBIOS resources and includes caching algorithms that
minimize broadcast traffic.
BC-206
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Overview of IBM Networking
This section contains information on the following topics related to DLSw+ features:
DLSw+ is fully compatible with any vendor’s RFC 1795 implementation and the following features are
available when both peers are using DLSw+:
DLSw+
• Local Acknowledgment, page 207
• Notes on Using LLC2 Local Acknowledgment, page 209
• DLSw+ Support for Other SNA Features, page 210
• Peer groups and border peers
• Backup peers
• Promiscuous and on-demand peers
• Explorer firewalls and location learning
• NetBIOS dial-on-demand routing feature support
• UDP unicast support
• Load balancing
• Support for LLC1 circuits
• Support for multiple bridge groups
• Support for RIF Passthru
• SNA type of service feature support
• Local acknowledgment for Ethernet-attached devices and media conversion for SNA PU 2.1 and
PU 2.0 devices
• Conversion between LLC2 to SDLC between PU 4 devices
• Local or remote media conversion between LANs and either the SDLC Protocol or QLLC
• SNA View, Blue Maps, and Internetwork Status Monitor (ISM) support
MIB enhancements that allow DLSw+ features to be managed by the CiscoWorks Blue products, SNA
Maps, and SNA V ie w. Also, new traps alert network management stations of peer or circuit failures. For
more information, refer to the current Cisco IOS release note for the location of the Cisco MIB website.
Local Acknowledgment
When you have LANs separated b y wide geographic distances, an d you want to a void multiple resending
or loss of user sessions that can occur with time delays, encapsulate the source-route bridged traffic
inside IP datagrams passed over a TCP connection between two routers with local acknowledgment
enabled.
LLC2 is an ISO standard data-link level protocol used in Token Ring networks. LLC2 was designed to
provide reliable sending of data across LAN media and to cause minimal or at least predictable time
delays. However, RSRB and WAN backbones created LANs that are separated by wide, geographic
distances-spanning countries and continents. As a result, LANs have time delays that are longer than
LLC2 allows for bidirectional communication between hosts. Local acknowledgment addresses the
problem of unpredictable time delays, multiple resending, and loss of user sessions.
In a typical LLC2 session, when one host sends a frame to another host, the sending host expects the
receiving host to respon d positi ve ly or ne gati v ely in a pred ef ined period of time commonly called th e T1
time. If the sending host does not receive an acknowledgment of the frame it sent within the T1 time, it
retries a few times (normally 8 to 10). If there is still no response, the sending host drops the session.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-207
DLSw+
SNA session
3
Overview of IBM Networking
Figure 86 illustrates an LLC2 session in which a 37x5 on a LAN segment communicates with a 3x74 on
a different LAN segment separated via a wide-area backbone network. Frames are transported between
Router A and Router B by means of DLSw+. Howe v er , the LLC2 session b etween the 37x5 and the 3x74
is still end-to-end; that is, every frame generated by the 37x5 traverses the backbone network to the 3x74,
and the 3x74, on receipt of the frame, acknowledges it.
Figure 86 LLC2 Session Without Local Acknowledgment
Router B
Token
Ring
3x74
S1106a
37x5
Token
Ring
Router A
WAN
LLC2 session
On backbone networks consisting of slow serial lin ks, the T1 timer on end hosts could e xpire before th e
frames reach the remote hosts, causing the end host to resend . Resending results in duplicate frames
reaching the remote host at the same time as the first frame reaches the remote host. Such frame
duplication breaks the LLC2 protocol, resulting in the loss of sessions between the two IBM machines.
One way to solve this time delay is to increase the timeout value on the end nodes to account for the
maximum transit time between the two end machines. However, in networks consisting of hundreds or
even thousands of nodes, every machine would need to be reconfigured with new values. With local
acknowledgment for LLC2 enabled, the LLC2 session between the two end nodes would not be not
end-to-end, but instead, would terminate at two local routers. Figure 87 shows the LLC2 session with
the 37x5 ending at Router A and the LLC2 session with the 3x74 end ing at Router B. Both Rou ter A and
Router B execute the full LLC2 protocol as part of local acknowledgment for LLC2.
Figure 87 LLC2 Session with Local Acknowledgment
TCP session
7x5
Token
Ring
Router A
LLC2 session LLC2 session
WAN
Router B
SNA session
Token
Ring
3x74
S1107a
With local ackno wledgment for LLC2 enabled in both routers, Router A ackno wledges frames received
from the 37x5. The 37x5 still operates as if the acknowledgments it receives are from the 3x74. Router
A looks like the 3x74 to the 37x5. Similarly, Router B acknowledges frames received from the 3x74. The
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-208
78-11737-02
Overview of IBM Networking
3x74 operates as if the acknowledgments it receives are from the 37x5. Router B looks like the 3x74 to
37x5. Because the frames do not have to travel the WAN backbone networks to be acknowledged, but
are locally acknowledged by routers, the end machines do not time out, resulting in no loss of sessions.
Enabling local acknowledgment for LLC2 has the following advantages:
DLSw+
• Local acknowledgment for LLC2 solves the T1 timer problem without having to change any
configuration on the end nodes. The end nodes are unaware that the sessions are locally
acknowledged. In networks consisting of hun dreds or even thousands of machines, this is a definite
advantage. All the frames acknowledged by the Cisco IOS software appear to the end hosts to be
coming from the remote IBM machine. In fact, by looking at a trace from a protocol analyzer, one
cannot say whether a frame was acknowl edged by the local router or b y a remote IBM machine. The
MAC addresses and the RIFs generated by the Cisco IOS software are identical to those generated
by the remote IBM machine. The only way to f ind out whether a session is locall y acknowledged is
to use either a show local-ack command or a show source-bridge command on the router.
• All the supervisory (RR, RNR, REJ) frames that are locally acknowledged go no farther than the
router. Without local acknowledgment for LLC2, every frame traverses the backbone. With local
acknowledgment, only data (I-frames) traverse the backbone, resulting in less traffic on the
backbone network. For installations in which customers pay for the amount of traffic passing
through the backbone, this could be a de finite cost-saving measure. A simple protocol exists
between the two peers to bring up or down a TCP session.
Notes on Using LLC2 Local Acknowledgment
LLC2 local acknowledgment is enabled with TCP and DLSw+ Lite remote peers.
If the LLC2 session between the loca l host and the router terminates in either router, the other will be
informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two routers reaches the high-water mark, the
routers sends Receiver -Not- Ready (RNR) messages to the local hosts un til the queue limit is r educed to
below this limit. It is possible, ho we ver, to prevent the RNR messages from being sent by using the dlsw
llc2 nornr command.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall
performance. Refer to the chapter “Configuring LLC2 and SDLC Parameters” in this manual for more
details about fine-tuning your network through the LLC2 parameters.
The routers at each end of the LLC2 session execute the full LLC2 protocol, which could result in some
overhead. The decision to use local acknowledgment for LLC2 should be based on the speed of the
backbone network in relation to the Token Ring speed. For LAN segments separated by slo w-speed serial
links (for example, 56 kbps), the T1 timer probl em could occur more frequently. In such cases, it might
be wise to turn on local acknowledgment for LLC2. For LAN segments separated by a T1, backbone
delays will be minimal; in such cases, FST or direct should be considered. Speed mismatch between t he
LAN segments and the backbone network is one criterion to help you decide to use local
acknowledgment for LLC2.
There are some situations (such as the receiving host failing between the time the sending host sends
data and the time the receiving host receives it), in which the sending host would determine, at the LLC2
layer, that data was recei ved when it actually was not. This error occurs because the router ackno wledges
that it received data from the sending host before it determines that the receiving host can actually
receive the data. But because both NetBIOS and SNA have error recovery in situations where an end
device goes down, these higher-level protocols will resend any missing or lost data. Because these
transaction request/confirmation prot ocols exist above LLC2, they are not affected by tight timers, as is
LLC2. They also are transparent to local acknowledgment.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-209
DLSw+
If you are using NetBIOS applications, note that there are two NetBIOS timers—one at the link level
and one at the next high er lev el. Local acknow ledgment for LLC2 is designed to solv e link timeouts only .
If you are experiencing NetBIOS session timeouts, you have two options:
• Experiment with increasing your NetBIOS timers and decreasing your maximum NetBIOS frame
size.
• Avoid using NetBIOS applications on slow serial lines.
Note By default, the Cisco IOS software translates Token Ring LLC2 to Ethernet 802.3 LLC2. To
configure the router to translat e Token Ring LLC2 frames into Ethernet 0x80d5 format frames, refer
to the section “Enable T ok en Ring LLC2-to-Ethernet Con v ersion” in the “Conf iguring Source-Ro ute
Bridging” chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 1
of 2).
DLSw+ Support for Other SNA Features
DLSw+ can be used as a transport for SNA features such as LAN Network Manager (LNM), DSPU, SNA
service point, and SNA Switching Services (SNASw) through a Cisco IOS feature called virtual
data-link control (VDLC).
LNM over DLSw+ allows DLSw+ to be used i n Token Ring networks that are managed by IBM’s LNM
software. Using this feature, LNM can be used to manage Token Ring LANs, control access units, and
Token Ring attached devices over a DLSw+ network. All management functions continue to operate as
they would in a source-route bridged network or an RSRB network.
Overview of IBM Networking
DSPU over DLSw+ allows the Cisco DSPU feature to operate in conjunction with DLSw+ in the same
router. DLSw+ can be used either upstream (toward the mainframe) or downstream (away from the
mainframe) of DSPU. DSPU concentration consolidates the appearance of multiple physical units (PUs)
into a single PU appearance to VTAM, minimizing memory and cycles in central site resources (VTAM,
NCP, and routers) and speeding network startup.
SNA service point over DLSw+ allows the Cisco SNA service point feature to be used in conjunction
with DLSw+ in the same router. Using this feature, SNA service point can be configured in remote
routers, and DLSw+ can provide the path for the remote service point PU to communicate with NetView.
This allows full management visibility of resources from a NetView 390 console, while concurrently
offering the value-added features of DLSw+ in an SNA network.
SNASw over DLSw+ allows the Cisco APPN Branch Extender functionality to be used in conjunction
with DLSw+ in the same router. With this feature, DLSw+ can be used to access SNASw in the data
center. DLSw+ can also be used as a transport SNASw upstream connectivity, providing nondisruptive
recovery from failures. The DLSw+ network can appear as a connection network to the SNASw nodes.
Using DLSw+ as a transport for other Cisco IOS SNA features requires a feature called VDLC. Cisco
IOS data-link users (such as LNM, DSPU, SNA service point, and SNASw) write to a virtual data-link
control interface. DLSw+ then reads from this interface an d sends out the traffic. Similarly, DLSw+ can
receive traffic destined for one of these Data Link Users and write it to the virtual data-link control
interface, from which the appropriate Data Link User will read it.
In Figure 88, SNASw and DLSw+ use Token Ring and Ethernet, respectively, as “real” data-link
controls, and use virtual data-link control to communicate between themselves. When one of the
high-layer protocols passes data to the virtual data-link control, the virtual data-link control must pass
it to a higher-layer protocol; nothing leaves the virtual data-link control without going through a
data-link user.
BC-210
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Overview of IBM Networking
5
ls
Figure 88 VDLC Interaction with Higher-Layer Protocols
STUN and BSTUN
Token
Ring
The higher-layer protocols make no distinction between the VDLC and any other data-link control, but
they do identify the VDLC as a destin ation . In the e xample sho wn in , SNASw has two ports: a physical
port for Token Ring and a logical (virtual) port for the VDLC. In the case of the SNASw VDLC port,
when you define the SNASw VDLC port, you can also specify the MAC address assigned to it. That
means data going from DLSw+ to SNASw b y way of the VDLC is di rected to th e VDLC MAC address.
The type of higher-layer protocol you use determines how the VDLC MAC address is assigned.
STUN and BSTUN
The Cisco IOS software supports serial tunnel (STUN) and block serial tunnel (BSTUN). Our BSTUN
implementation enhances Cisco 2500, 4000, 4500, 4700, 7200 series routers to support devices that use
the Binary Synchronous Communication (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 interf ace module (NIM) on the Cisco 4000
and 4500 series routers. Our support of the bisync protocol enables enterprises to transport Bisync traffic
and SNA multiprotocol traffic over the same network.
This section contains the following topics:
• STUN Networks, page 211
SNASw
VDLC
DLSw+ Data-link users
CLSI
Ethernet
Data-link contro
1909
• STUN Features, page 212
• BSTUN Networks, page 215
• BSTUN Features, page 215
STUN Networks
STUN operates in two modes: passthrough and local acknowledgment. Figure 89 shows the difference
between passthrough mode and local acknowledgment mode.
The upper half of Figure 89 shows STUN configured in passthrough mode. In passthrough mode, the
routers act as a wire and the SDLC session remains between the end stations. In this mode, STUN
provides a straight passthrough of all SDLC traffic, including control frames.
The lower half of Figure 89 shows STUN configured in local acknowledgment mode. In local
acknowledgment mode, the routers terminate the SDLC sessions and send only data across the WAN.
Control frames no longer travel the WAN backbone networks.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-211
STUN and BSTUN
I
SNA session
Overview of IBM Networking
Figure 89 Comparison of STUN in Passthrough Mode and Local Acknowledgment Mode
37x5
BM 1
WAN
3x74
IBM1
SDLC session
SNA session
TCP session
37x5
IBM 1
SDLC session
Note To enable STUN local acknowledgment, you first enable the routers for STUN and configure them
WAN
IBM 2
SDLC session
to appear on the network as primary or secondary SDLC nodes. TCP/IP encapsulation must be
enabled. The Cisco STUN local acknowledgment feature also provides priority queueing for
TCP-encapsulated frames.
3x74
S2839
STUN Features
The Cisco STUN implementation provides the following features:
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-212
• Encapsulates SDLC frames in either the Transmission Control Protocol/Internet Protocol (TCP/IP)
or the HDLC protocol.
• 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, reducing leased-line costs.
When you replace direct serial links with routers, serial frames can be propagated over arbitrary
media and topologies to another router with a STUN link to an appropriate endpoint. 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.
• Supports local acknowledgment for direct Frame Relay connectivity between routers, without
requiring TCP/IP.
78-11737-02
Overview of IBM Networking
STUN and BSTUN
• 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 SNA and
allows IBM SDLC frames to be sent across the network media and shared serial links. illustrates a
typical network configuration without STUN and the same network configured with STUN.
• Encapsulates SDLC frame traffic packets and routes them ov er an y of the support ed netw ork 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.
• Copies frames to destinations based on address. STUN in passthrough mode does not modify the
frames in any way or participate in SDLC windowing or resending; these functions are left to the
communicating hosts. However, STUN in local acknowledgment mode does participate in SDLC
windowing and resending through local termination of the SDLC session.
• Ensures reliable sending of data across serial media ha ving minimal or predictable time del ays. With
the advent of STUN and 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 STUN local
acknowledgment feature addresses the problems of unpredictable time delays, multiple resending,
or loss of sessions.
• Allows for configuration of redundant links to provide transport paths if part of the network goes
down.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-213
STUN and BSTUN
Overview of IBM Networking
Figure 90 shows the difference between an IBM network with STUN and one without STUN.
Figure 90 IBM Network Configuration without STUN and with STUN
Without
STUN
IBM mainframe
37x5
3x74
IBM 3x78 terminals
IBM mainframe
Workstation
Ethernet
Local
site
T1 serial link
Remote
site
Ethernet
Workstation
With
STUN
37x5
Ethernet
T1 serial link
Ethernet
3x74
IBM 3x78 terminals
Workstation
Local
site
Remote
site
Workstation
S2075
BC-214
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Overview of IBM Networking
BSTUN Networks
The Bisync feature enables your Cisco 2500, 3600, 4000, 45 00, 4700, and 7200 series router to support
devices that use the Bisync data-link protocol. Th is protoco l enables ente rprises to tran sport Bisync
traffic over the same network that supports their SNA and multiprotocol traffic, eliminating the need for
separate Bisync facilities.
At the access router, traff ic from the attached Bisync device is encapsulated in IP. The Bisync traffic can
then be routed across arbitrary media to the host site where another router supporting Bisync will remov e
the IP encapsulation headers and present the Bisync traffic to the Bisync host or controller over a serial
connection. HDLC can be used as an alternative encapsulation method for point-to-point links.
BSTUN Features
The Cisco implementation of BSTUN provides the following features:
• Encapsulates Bisync, Adplex, ADT Security Systems, Inc., Diebold, asynchronous generic, and
LLC2 and SDLC Parameters
Monitor Dynamics Inc., traffic for tran sfer over router l inks. The tunneling of asynchronous security
protocols (ASP) feature enables your Cisco 2500, 3600, 4000, 4 500, or 7200 series router to support
devices that use the following asynchronous security protocols:
–
adplex
–
adt-poll-select
–
adt-vari-poll
–
diebold
–
async-generic
–
mdi
• Provides a tunnel mechanism for BSTUN over Frame Relay, without using TCP/IP encapsul ation.
• Supports Bisync devices and host applications without modification.
• Uses standard synchronous serial interfaces on Cisco 2500 series and the 4T network interface
module (NIM) on the Cisco 4000 series and Cisco 4500 series.
• Supports point-to-point, multidrop, and virtual multidrop configurations.
Note The async-generic item is not a protocol name. It is a command keyword used to indicate generic
support of other asynchronous security protocols that are not explicitly supported.
LLC2 and SDLC Parameters
The LLC2 and SDLC protocols provide data link layer support for higher-layer network protocols and
features such as SDLC Logical Link Control (SDLLC) and RSRB with local acknowledgment. The
features that are affected by LLC2 parameter settings are listed in the “The Cisco Implementation of
LLC2” section on page 216. The features that require SDLC configuration and use SDLC parameters are
listed in the “The Cisco Implementation of SD LC” section on page 21 7.
LLC2 and SDLC package data in frames. LLC2 and SDLC stations require acknowledgments from
receiving stations after a set amount of frames have been sent before sending further data. The tasks
described in this chapter modify default settings regarding the control field of the data frames. By
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-215
Loading...