Summary of the content on the page No. 1
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 204
� DLSw+, page 206
� STUN and BSTUN, page 213
� LLC2 and SDLC Parameters, page 217
� IBM Network Media Translation, page 219
� SNA FRAS, page 226
� NCIA, page 228
� ALPS,
Summary of the content on the page No. 2
Overview of IBM Networking RSRB Note All commands supported on the Cisco 7500 series routers are also supported on the Cisco 7000 series routers. RSRB In contrast to Source-Route Bridging (SRB), which involves bridging between Token Ring media only, RSRB is Cisco’s first technique for connecting Token Ring networks over non-Token Ring network segments. (DLSw+ is Cisco’s strategic method for providing this function.) Cisco’s RSRB software implementation includes the following features: � Pro
Summary of the content on the page No. 3
Overview of IBM Networking RSRB 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 ro
Summary of the content on the page No. 4
Overview of IBM Networking DLSw+ 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
Summary of the content on the page No. 5
Overview of IBM Networking DLSw+ This section contains a brief overview of DLSw+ which is described in the following topics: � DLSw Standard, page 207 � DLSw Version 2 Standard, page 207 � DLSw+ Features, page 208 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 co
Summary of the content on the page No. 6
Overview of IBM Networking DLSw+ IP Multicast Multicast service avoids duplication and excessive bandwidth of broadcast traffic because it replicates and propagates messages to its multicast members only as necessary. It reduces the amount of network overhead in the following ways: � Avoids 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 lin
Summary of the content on the page No. 7
Overview of IBM Networking DLSw+ This section contains information on the following topics related to DLSw+ features: � Local Acknowledgment, page 209 � Notes on Using LLC2 Local Acknowledgment, page 211 � DLSw+ Support for Other SNA Features, page 212 DLSw+ is fully compatible with any vendor’s RFC 1795 implementation and the following features are available when both peers are using DLSw+: � Peer groups and border peers � Backup peers � Promiscuous and on-demand peers � Explorer firewalls a
Summary of the content on the page No. 8
Overview of IBM Networking DLSw+ 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+. However, the LLC2 session between 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. Fi
Summary of the content on the page No. 9
Overview of IBM Networking DLSw+ 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: � Local acknowledgment for LLC2 solves the T1 timer problem without having to change any
Summary of the content on the page No. 10
Overview of IBM Networking DLSw+ 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 solve 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
Summary of the content on the page No. 11
Overview of IBM Networking STUN and BSTUN Figure 88 VDLC Interaction with Higher-Layer Protocols DLSw+ Data-link users SNASw CLSI Token Data link controls VDLC Ethernet 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 destination. In the example shown 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
Summary of the content on the page No. 12
Overview of IBM Networking STUN and BSTUN Figure 89 Comparison of STUN in Passthrough Mode and Local Acknowledgment Mode 37x5 3x74 WAN IBM 1 IBM1 SDLC session SNA session TCP session 37x5 WAN 3x74 IBM 1 IBM 2 SDLC session SDLC session SNA session Note To enable STUN local acknowledgment, you first enable the routers for STUN and configure them to appear on the network as primary or secondary SDLC nodes. TCP/IP encapsulation must be enabled. Cisco’s STUN local acknowledgment feature also prov
Summary of the content on the page No. 13
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 transmitted 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 over any of th
Summary of the content on the page No. 14
Overview of IBM Networking STUN and BSTUN Figure 90 IBM Network Configuration without STUN and with STUN Workstation IBM mainframe Ethernet 37x5 Local site Without STUN T1 serial link 3x74 Remote site Ethernet IBM 3x78 terminals Workstation IBM mainframe 37x5 Workstation Local Ethernet site With STUN T1 serial link Remote Ethernet site Workstation 3x74 IBM 3x78 terminals Cisco IOS Bridging and IBM Networking Configuration Guide BC-216 S2075
Summary of the content on the page No. 15
Overview of IBM Networking LLC2 and SDLC Parameters BSTUN Networks The Bisync feature enables your Cisco 2500, 3600, 4000, 4500, 4700, and 7200 series router to support devices that use the Bisync data-link protocol. This protocol enables enterprises to transport Bisync traffic over the same network that supports their SNA and multiprotocol traffic, eliminating the need for separate Bisync facilities. At the access router, traffic from the attached Bisync device is encapsulated in IP. The B
Summary of the content on the page No. 16
Overview of IBM Networking LLC2 and SDLC Parameters 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 modifying the control field parameters, you can determine the number of acknowledgments sent for frames received and the level of polling used to det
Summary of the content on the page No. 17
Overview of IBM Networking IBM Network Media Translation Cisco’s Implementation of SDLC Cisco’s SDLC implementation supports the following features: � Frame Relay Access Support (FRAS) With FRAS, a router functions as a Frame Relay Access Device (FRAD) for SDLC, Token Ring, and Ethernet-attached devices over a Frame Relay Boundary Network Node (BNN) link. Frame Relay access support is described in the chapter “Configuring SNA Frame Relay Access Support.” � SDLLC media translation The SDLLC f
Summary of the content on the page No. 18
Overview of IBM Networking IBM Network Media Translation Figure 91 SNA Data Link Layer Support SNA Upper layers Data link layer SDLC SDLLC LLC LNX QLLC X.25 SDLLC Media Translation Features The SDLLC feature allows a PU 4, PU 2.1, or PU 2 to communicate with a PU 2 SDLC device as follows: � SDLLC with direct connection—A 37x5 front-end processor (FEP) on a Token Ring and the 3x74 cluster controller connected to a serial line are each connected to an interface on the same router configured wi
Summary of the content on the page No. 19
Overview of IBM Networking IBM Network Media Translation As part of its virtual telecommunications access method (VTAM) configuration, the IBM node on the Token Ring has knowledge of the SDLLC VTRA of the serial device with which it communicates. The SDLC VTRA and the SDLLC virtual ring number are a part of the SDLLC configuration for the router’s serial interface. When the Token Ring host sends out explorer packets with the SDLLC VTRA as the destination address in the MAC headers, the rou
Summary of the content on the page No. 20
Overview of IBM Networking IBM Network Media Translation QLLC Conversion Qualified Logical Link Control (QLLC) is a data link protocol defined by IBM that allows SNA data to be transported across X.25 networks. (Although IBM has defined other protocols for transporting SNA traffic over an X.25 network, QLLC is the most widely used.) Figure 92 illustrates how QLLC conversion provides data link layer support for SNA communication. Figure 92 SNA Data Link Layer Support SNA Upper layers Data li
