-
Bridging and IBM Networking Configuration Guide
-
About The Cisco IOS Software Documentation
-
Bridging and IBM Networking Overview
- Part 1: Bridging
-
Part 2: IBM Networking
-
Configuring Remote Source-Route Bridging
-
Configuring DLSw+
-
Configuring STUN and BSTUN
-
Configuring LLC2 and SDLC Parameters
-
Configuring IBM Network Media Translation
-
Configuring DSPU and SNA Service Point Support
-
Configuring SNA Frame Relay Access Support
-
Configuring APPN
-
Configuring NCIA Client/Server Topologies
-
Configuring IBM Channel Attach
-
-
Table Of Contents
Bridging and IBM Networking Overview
Transparent and Source-Route Transparent Bridging
Integrated Routing and Bridging
Bridge-Group Virtual Interface (BVI)
Source-Route Transparent (SRT) Bridging Features
Source-Route Bridging Features
Remote Source-Route Bridging (RSRB)
Data-Link Switching Plus (DLSw+)
Enhanced Peer-on-Demand Routing Feature
DLSw+ Support for Other SNA Features
Serial Tunnel and Block Serial Tunnel
Cisco's Implementation of LLC2
Cisco's Implementation of SDLC
SDLLC Media Translation Features
Resolving Differences in LLC2 and SDLC Frame Size
Maintaining a Dynamic RIF Cache
Cisco's Implementation of QLLC Conversion
Comparing QLLC Conversion to SDLLC
Other Implementation Considerations
Downstream Physical Unit and SNA Service Point
SNA Frame Relay Access Support
RFC 1490 Routed Format for LLC2 (BNN)
RFC 1490 Bridged Format for LLC2 (BAN)
Advanced Peer-to-Peer Networking
APPN Directory and APPN Searches
APPN Intermediate Session Routing
Dependent Logical Unit Requester/Server
Native Client Interface Architecture (NCIA)
Advantages of the Client/Server Model
IBM Channel Interface Processor
Common Link Access for Workstations (CLAW) Support
CIP Systems Network Architecture Support
IBM Channel Attach Hardware Requirements
IBM Channel Attach Host Software Requirements
Bridging and IBM Networking Overview
The Bridging and IBM Networking Configuration Guide discusses the following software components:
•
Transparent and Source-Route Transparent Bridging
•
•
•
•
•
•
•
•
•
This overview chapter gives a high-level description of each technology. For configuration information, refer to the appropriate chapter in this publication.
Note
Transparent and Source-Route Transparent Bridging
Cisco IOS software supports transparent bridging for Ethernet, Fiber Distributed Data Interface (FDDI), and serial media, and supports source-route transparent (SRT) bridging for Token Ring media. In addition, Cisco supports all the mandatory Management Information Base (MIB) variables specified for transparent bridging in RFC 1286.
Transparent Bridging Features
Cisco's transparent bridging software implementation has the following features:
•
•
•
•
•
•
•
•
•
•
•
•
Cisco access servers and routers can be configured to serve as both multiprotocol routers and Media Access Control (MAC)-level bridges, bridging any traffic that cannot otherwise be routed. For example, a router routing the Internet Protocol (IP) can also bridge Digital's LAT protocol or NetBIOS traffic.
Cisco routers also support remote bridging over synchronous serial lines. As with frames received on all other media types, dynamic learning and configurable filtering applies to frames received on serial lines.
Transit bridging of Ethernet frames across FDDI media is also supported. The term transit refers to the fact that the source or destination of the frame cannot be on the FDDI media itself. This allows FDDI to act as a highly efficient backbone for the interconnection of many bridged networks. The configuration of FDDI transit bridging is identical to the configuration of transparent bridging on all other media types.
Integrated Routing and Bridging
While concurrent routing and bridging makes it possible to both route and bridge a specific protocol on separate interfaces within a router, the protocol is not switched between bridged and routed interfaces. Routed traffic is confined to the routed interfaces; bridged traffic is confined to bridged interfaces. A specified protocol may be either routed or bridged on a given interface, but not both.
Integrated routing and bridging makes it possible to route a specific protocol between routed interfaces and bridge groups, or route a specific protocol between bridge groups. Local, or unroutable, traffic can be bridged among the bridged interfaces in the same bridge group, while routable traffic can be routed to other routed interfaces or bridge groups. Figure 2 illustrates how integrated routing and bridging in a router interconnects a bridged network with a routed network.
Figure 2 IRB Interconnects a Bridged Network with a Routed Network
You can configure the Cisco IOS software to route a specific protocol between routed interfaces and bridge groups, or to route a specific protocol between bridge groups. Specifically, local or unroutable traffic is bridged among the bridged interfaces in the same bridge group, while routable traffic is routed to other routed interfaces or bridge groups. Using integrated routing and bridging, you can:
•
•
•
Bridge-Group Virtual Interface (BVI)
Because bridging operates in the data link layer and routing operates in the network layer, they follow different protocol configuration models. Taking the basic IP model as an example, all bridged interfaces would belong to the same network, while each routed interface represents a distinct network.
In integrated routing and bridging, the BVI is introduced to avoid confusing the protocol configuration model when a specific protocol is both bridged and routed in a bridge group. Figure 3 illustrates the BVI as a user-configured virtual interface residing within a router.
Figure 3 The Bridge-Group Virtual Interface in the Router
The BVI is a normal routed interface that does not support bridging, but does represent its corresponding bridge group to the routed interface. It has all the network layer attributes (such as a network layer address and filters) that apply to the corresponding bridge group. The interface number assigned to this virtual interface corresponds to the bridge group that this virtual interface represents. This number is the link between the virtual interface and the bridge group.
When you enable routing for a given protocol on the BVI, packets coming from a routed interface, but destined for a host in a bridged domain, are routed to the BVI and are forwarded to the corresponding bridged interface. All traffic routed to the BVI is forwarded to the corresponding bridge group as bridged traffic. All routable traffic received on a bridged interface is routed to other routed interfaces as if it is coming directly from the BVI.
Note
To be able to receive routable packets arriving on a bridged interface, but destined for a routed interface, or to receive routed packets, the BVI must also have the appropriate addresses. MAC addresses and network addresses are assigned to the BVI as follows:
•
•
Because there can be only one BVI representing a bridge group, and the bridge group can be made up of different media types configured for several different encapsulation methods, you may need to configure the BVI with the particular encapsulation methods required to switch packets correctly.
For example, the BVI has default data link and network layer encapsulations that are the same as those available on Ethernet interfaces, but you can configure the BVI with encapsulations that are not supported on an Ethernet interface. In some cases, the default encapsulations provide appropriate results; in other cases they do not. For example, with default encapsulation, ARPA packets from the BVI are translated to SNAP when bridging IP to a Token Ring or FDDI bridged interface. But for IPX, Novell-ether encapsulation from the BVI is translated to raw-token or raw-FDDI when bridging IPX to a Token Ring or FDDI bridged interface. Because this behavior is usually not what you want, you must configure IPX SNAP or SAP encapsulation on the BVI.
Other Considerations
•
•
•
•
•
Source-Route Transparent (SRT) Bridging Features
Cisco routers support transparent bridging on Token Ring interfaces that support SRT bridging. Both transparent and SRT bridging are supported on all Token Ring interface cards that can be configured for either 4- or 16-MB transmission speeds.
As with other media, all the features that use bridge-group commands can be used on Token Ring interfaces. As with other interface types, the bridge group can be configured to run either the IEEE or Digital Spanning-Tree Protocols. When configured for the IEEE Spanning-Tree Protocol, the bridge cooperates with other SRT bridges and constructs a loop-free topology across the entire extended LAN.
You can also run the Digital Spanning-Tree Protocol over Token Ring. Use it when you have other non-IEEE bridges on other media and you do not have any SRT bridges on Token Ring. In this configuration, all the Token Ring transparent bridges must be Cisco routers. This is because the Digital Spanning-Tree Protocol has not been standardized on Token Ring.
As specified by the SRT bridging specification, only packets without a routing information field (RIF) (RII = 0 in the SA field) are transparently bridged. Packets with a RIF (RII = 1) are passed to the source-route bridging module for handling. An SRT-capable Token Ring interface can have both source-route bridging and transparent bridging enabled at the same time. However, with SRT bridging, frames that did not have a RIF when they were produced by their generating host never gain a RIF, and frames that did have a RIF when they were produced never lose that RIF.
Note
Bridging between Token Ring and other media requires certain packet transformations. In all cases, the MAC addresses are bit-swapped because the bit ordering on Token Ring is different from that on other media. In addition, Token Ring supports one packet format, logical link control (LLC), while Ethernet supports two formats (LLC and Ethernet).
The transformation of LLC frames between media is simple. A length field is either created (when the frame is transmitted to non-Token Ring) or removed (when the frame is transmitted to Token Ring). When an Ethernet format frame is transmitted to Token Ring, the frame is translated into an LLC-1 Subnetwork Access Protocol (SNAP) packet. The destination service access point (DSAP) value is AA, the source service access point (SSAP) value is AA, with the organizational unique identifier (OUI) value is 0000F8. Likewise, when a packet in LLC-1 format is bridged onto Ethernet media, the packet is translated into Ethernet format.
CautionBridging between dissimilar media presents several problems that can prevent communication from occurring. These problems include bit order translation (or using MAC addresses as data), maximum transmission unit (MTU) differences, frame status differences, and multicast address usage. Some or all these problems might be present in a multimedia bridged LAN. Because of differences in the way end nodes implement Token Ring, these problems are most prevalent when bridging between Token Ring and Ethernet or between Ethernet and FDDI LANs.
Problems currently occur with the following protocols when bridged between Token Ring and other media: Novell IPX, DECnet Phase IV, AppleTalk, Banyan VINES, XNS, and IP. Further, problems can occur with the Novell IPX and XNS protocols when bridged between FDDI and other media. We recommend that these protocols be routed whenever possible.
Source-Route Bridging (SRB)
Our bridging software includes SRB capability. A source-route bridge connects multiple physical Token Rings into one logical network segment. If the network segment bridges only Token Ring media to provide connectivity, the technology is termed source-route bridging. If the network bridges Token Ring and non-Token Ring media is introduced into the bridged network segment, the technology is termed remote source-route bridging (RSRB).
Source-route bridging enables our routers to simultaneously act as a Level 3 router and a Level 2 source-route bridge. Thus, protocols such as Novell's Internetwork Packet Exchange (IPX) or Xerox Network Systems (XNS) can be routed on Token Rings, while other protocols such as Systems Network Architecture (SNA) or NetBIOS are source-route bridged.
Source-route bridging technology is a combination of bridging and routing functions. A source-route bridge can make routing decisions based on the contents of the MAC frame header. Keeping the routing function at the MAC, or Level 2, layer allows the higher-layer protocols to execute their tasks more efficiently and allows the LAN to be expanded without the knowledge of the higher-layer protocols.
As designed by IBM and the IEEE 802.5 committee, source-route bridges connect extended Token Ring LANs. A source-route bridge uses the RIF in the IEEE 802.5 MAC header of a datagram (see Figure 4) to determine which rings or Token Ring network segments the packet must transit. The source station inserts the RIF into the MAC header immediately following the source address field in every frame, giving this style of bridging its name. The destination station reverses the routing field to reach the originating station.
Figure 4 IEEE 802.5 Token Ring Frame Format
The information in a RIF is derived from explorer packets generated by the source node. These explorer packets traverse the entire source-route bridge network, gathering information on the possible paths the source node might use to send packets to the destination.
Transparent spanning-tree bridging requires time to recompute a topology in the event of a failure; source-route bridging, which maintains multiple paths, allows fast selection of alternate routes in the event of failure. Most importantly, source-route bridging allows the end stations to determine the routes the frames take.
Source-Route Bridging Features
Cisco's source-route bridging implementation has the following features:
•
•
•
•
•
•
•
•
•
•
•
•
Remote Source-Route Bridging (RSRB)
In contrast to 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:
•
•
•
•
•
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 5 Remote Source-Route Bridged Topology
Note
Data-Link Switching Plus (DLSw+)
DLSw+ is a method of transporting SNA and NetBIOS. It complies with the DLSw standard documented in RFC 1795 as well as the DLSw Version 2 standard. DLSw+ is an alternative to RSRB that addresses several inherent problems that exist in RSRB, such as:
•
•
•
•
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 equivalent of our local acknowledgment option). The standard also requires 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, but 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 both 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 Version 2 Standard
In the Version 1 standard, the network design was required to be fully meshed so that all peers were connected to every other peer. This design created unnecessary broadcast traffic because an explorer was sent to every peer for every broadcast.
DLSw Version 2 addresses this problem and improves scalability in DLSw networks with the following enhancements:
•
UDP/IP Multicast Service
IP multicast service reduces the amount of network overhead because it avoids the need to maintain TCP Switch-to-Switch Protocol (SSP) connections between two DLSw peers when no circuits are available and it ensures that each broadcast results in only a single explorer over every link. Furthermore, multicast service avoids duplication and excessive bandwidth of broadcast traffic because it replicates and propagates messages only as necessary to its multicast members. This functionality is a subset of Cisco's existing DLSw+ border peering feature. In a border peer network, address resolution packets are sent via the border peer network and can take advantage of border peer caching to minimize bandwidth usage. DLSw Version 2 is for customers who run a multicast IP network and do not need the advantages of border peering.
With UDP Unicast, explorer frames and unnumbered information frames are sent via UDP rather than TCP. This feature eliminates retransmission of explorers and unnumbered information frames that could occur during congestion. Cisco's DLSw+ introduced the UDP Unicast feature prior to the release of DLSw Version 2 in Cisco IOS Release 11.2(6)F. One difference between the two enhancements is that the Release 11.2(6)F UDP Unicast feature requires that a TCP connection exist before packets are sent via UDP. Because the TCP session is up and capabilities have been exchanged, the peers know exclusive reachability information which will permit them to further reduce the explorer load on the network. DLSw Version 2, on the other hand, sends UDP/IP multicast and unicast before the TCP connection exists. Although DLSw Version 2 employs IP multicast service when address resolution packets (CANUREACH_EX, NETBIOS_NQ_ex, NETBIOS_ANQ, and DATAFRAME) are sent to multiple destinations; the response frames (ICANREACH_ex and NAME_RECOGNIZED_ex), are sent via UDP unicast.
Enhanced Peer-on-Demand Routing Feature
DLSw Version 2 now 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 more 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 is established if the associated peer is known to support DLSw Version 2.
DLSw+ Features
DLSw+ is Cisco's version of DLSw and it supports several additional features and enhancements. DLSw+ is fully compatible with any vendors RFC 1795 implementation and the following features are available when both peers are using DLSw+:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
DLSw+ Enhancements
DLSw+ goes beyond the standard to include additional functionality in the following areas:
•
•
•
•
Modes of Operation
DLSw+ operates in two modes:
•
•
Note
Some enhanced DLSw+ features are also available when a Cisco router is operating in standards compliance mode with another vendor's router. In particular, enhancements that are locally controlled options on a router can be accessed even though the remote router does not have DLSw+. These include reachability caching, explorer firewalls and media conversion.
Improved Scalability
One significant factor that limits the size of Token Ring internetworks is the amount of explorer traffic that traverses the WAN. DLSw+ includes the following features to reduce the number of explorers:
•
•
•
•
•
•
Note
•
•
•
Figure 6 Scalability with DLSw+
Improved Performance
DLSw+ improves performance by offering higher-performance transport options in the following areas:
Transport Connection Type
The transport connection between DLSw+ routers can vary according to the needs of the network and is not necessarily tied to TCP/IP as the DLSw standard is. We support three different transport protocols between DLSw+ devices:
•
•
•
SNA Type of Service
Performance is further enhanced with the SNA Type of Service feature. Although DLSw+ priority queuing provides prioritization on the output queue of the interface, the priority characteristics are lost once the packet leaves the DLSw+ router and traverses the network. SNA Type of Service sets IP precedence in all DLSw+ frames, either setting all DLSw+ to a high precedence, or building multiple pipes for different priority traffic and setting each one appropriately. Also, when running APPN over DLSw+, APPN Class of Service (COS) characteristics are lost once the packet is delivered to the DLSw+ router for bridging over an IP network. With the new DLSw+ SNA TOS feature, however, SNA TOS works in conjunction with weighted fair queuing to reduce the response time for SNA sessions and, therefore, ensures that DLSw+ gets more bandwidth. DLSw+ traffic is prioritized and APPN COS characteristics are preserved across the network.
With the SNA Type of Service feature, DLSw+ sets the precedence bits in the IP header of outbound DLSw+ packets. When DLSw+ is used in conjunction with APPN, SNA TOS maps APPN COS to IP TOS, and preserves SNA COS across an IP backbone. If priority queuing is not configured on DLSw+, the IP precedence value of "Network" is used for all DLSw+ packets. This default value ensures more bandwidth for DLSw+ packets than for other types of packets.
describes the various IP precedence values that map to the TCP ports.
Table 1 IP Precedence Values
When the priority option on the dlsw remote-peer command is configured, DLSw+ automatically activates four TCP ports to that remote peer (ports 2065, 1981, 1982 and 1983) and assigns traffic to specific ports according to the rules defined in . Alternately, SAP prioritization, LOCADDR prioritization, or APPN COS can be used to customize how traffic is assigned to these ports.
If the priority option is not configured in the dlsw remote peer command, then all DLSw+ traffic defaults to port 2065 and is assigned IP precedence "network." The default TOS settings can be changed by using policy routing based on the TCP ports that the DLSw+ router uses. For more information on policy routing see the Network Protocols Configuration Guide, Part 1. For an example configuration of DLSw+ with policy routing see the dlsw remote peer tcp command in the Bridging and IBM Networking Command Reference.
Please note the following design considerations with the SNA Type of Service feature:
•
•
•
Enhanced Availability
DLSw+ offers enhanced availability by caching a table of multiple paths to a given MAC address or NetBIOS name (where a path is either a remote peer or a local port). Furthermore, with the Border Peer Caching feature, border peers build an additional cache (group), which is checked before forwarding explorers for other routers.
Maintaining multiple paths per destination is especially attractive in SNA networks. A common technique used in the hierarchical SNA environment is assigning the same MAC address to different Token Ring interface couplers (TICs) on the IBM front-end processors (FEPs). DLSw+ ensures that duplicate TIC addresses are found, and, if multiple DLSw+ peers can be used to reach the FEPs, they are cached.
The way that multiple capable peers are handled with DLSw+ can be biased to meet either of the following network needs:
•
•
shows a peer table of preferred (pref) and capable (cap) routes.
Figure 7 Enhanced Availability and Performance
In addition to supporting multiple active peers, DLSw+ supports backup peers for all encapsulation types (including direct, FST, and TCP), which are connected only when the primary peer cannot be reached.
DLSw+ Support for Other SNA Features
DLSw+ can be used as a transport for SNA features such as LNM, DSPU, SNA service point, and APPN through a Cisco IOS feature called VDLC.
LNM over DLSw+ allows DLSw+ to be used in 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.
DSPU over DLSw+ allows Cisco's 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 Cisco's 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.
APPN over DLSw+ allows Cisco's APPN feature to be used in conjunction with DLSw+ in the same router. With this feature, DLSw+ can be used to access an APPN backbone or APPN in the data center. DLSw+ can also be used as a transport for APPN, providing nondisruptive recovery from failures and high-speed intermediate routing. The DLSw+ network can appear as a connection network to the APPN network nodes.
To use DLSw+ as a transport for other Cisco IOS SNA features requires a feature called virtual data- link control. Cisco IOS data-link users (such as LNM, DSPU, SNA service point, and APPN) write to a virtual data-link control interface. DLSw+ then reads from this interface and sends out the traffic. Similarly, DLSw+ can receive traffic destined for one of these DLUS and write it to the virtual data-link control interface, from which the appropriate DLU will read it.
In Figure 8, APPN 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.
Figure 8 VDLC Interaction with Higher-Layer Protocols
The higher-layer protocols make no distinction between the virtual data link control and any other data-link control, but they do identify the virtual data link control as a destination. In the example shown in Figure 8, APPN has two ports: a physical port for Token Ring and a logical (virtual) port for the virtual data link control. In the case of the APPN virtual data link control port, when you define the APPN virtual data link control port, you can also specify the MAC address assigned to it. That means data going from DLSw+ to APPN by way of the virtual data link control is directed to the virtual data link control MAC address. The type of higher-layer protocol you use determines how the virtual data link control MAC address is assigned.
Serial Tunnel and Block Serial Tunnel
The Cisco IOS software supports serial tunnel (STUN) and block serial tunnel (BSTUN). Our BSTUN implementation enhances Cisco series 2500, 4000, 4500, 4700, 7200 routers to support devices that use the Binary Synchronous Communication (Bisync) datalink 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 series 4000 and 4500. Our support of the bisync protocol enables enterprises to transport Bisync traffic and SNA multiprotocol traffic over the same network.
STUN Networks
STUN operates in two modes: passthrough and local acknowledgment. Figure 9 shows the difference between passthrough mode and local acknowledgment mode.
The upper half of 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 pass-through of all SDLC traffic, including control frames.
The lower half of 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.
Figure 9 Comparison of STUN in Passthrough Mode and Local Acknowledgment Mode
Note
Serial Tunnel
Our STUN implementation provides the following features:
•
•
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 end point. The intervening network is not restricted to STUN traffic, but rather, is multiprotocol. For example, instead of running parallel backbones for DECnet and SNA/SDLC traffic, this traffic now can be integrated into an enterprise backbone network.
•
•
•
•
•
•
Figure 10 IBM Network Configuration without STUN and with STUN
BSTUN Networks
The Bisync feature enables your Cisco 2500, 3600, 4000, 4500, or 7200 series router router to support devices that use the Bisync datalink 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 Bisync traffic can then be routed across arbitrary media to the host site where another router supporting Bisync will remove 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.
Block Serial Tunnel
Cisco's implementation of BSTUN provides the following features:
•
•
•
•
•
•
•
•
•
•
•
SDLC and LLC2 Parameters
The Logical Link Control, type 2 (LLC2) and SDLC protocols provide data-link-level support for higher-level network protocols and features such as SDLLC and RSRB with local acknowledgment. The features that are affected by LLC2 parameter settings are listed in the next section, "Cisco's Implementation of LLC2." The features that require SDLC configuration and use SDLC parameters are listed in the section "Cisco's Implementation of SDLC" later in this chapter.
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 determine available stations. In this manner, you can set the amount of resources used for frame checking and optimize the network load.
SDLC is used as the primary SNA link-layer protocol for WAN links. SDLC defines two types of network nodes: primary and secondary. Primary nodes poll secondary nodes in a predetermined order. Secondary nodes then transmit any outgoing data. When configured as primary and secondary nodes, our routers are established as SDLC stations.
Cisco's Implementation of LLC2
Cisco's LLC2 implementation supports the following features:
•
This feature is used in our implementation of RSRB as described in the chapter "Configuring Source-Route Bridging."
Because LANs are now connected through RSRB and WAN backbones, the delays that occur are longer than LLC2 allows for bidirectional communication between hosts. Our local acknowledgment feature addresses the problem of delays, retransmissions, and loss of user sessions.
•
Routers using 4- or 16-Mbps Token Ring interfaces configured for SRB support LNM and provide all IBM Bridge Program functions. With LNM, a router appears as an IBM source-route bridge, and can manage or monitor any connected Token Ring interface.
LNM support is described in the chapter "Configuring Source-Route Bridging."
•
The SDLLC feature provides media translation between the serial lines running SDLC and Token Rings running LLC2. SDLLC consolidates the IBM SNA networks running SDLC into a LAN-based, multiprotocol, multimedia backbone network.
SDLLC is described in the chapter "Configuring IBM Network Media Translation."
•
Our CMNS implementation runs X.25 packets over LLC2 so that X.25 can be extended to Ethernet, FDDI, and Token Ring media.
Cisco's Implementation of SDLC
Cisco's SDLC implementation supports the following features:
•
With our Frame Relay access support feature, 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."
•
Our SDLLC feature provides media translation between the serial lines running SDLC and Token Rings running LLC2. SDLLC consolidates the IBM SNA networks running SDLC into a LAN-based, multiprotocol, multimedia backbone network.
SDLLC is described in the chapter "Configuring IBM Network Media Translation."
•
SDLC local acknowledgment is used with SDLC serial tunnel (STUN). The Transmission Control Protocol/Internet Protocol (TCP/IP) must be enabled. With local acknowledgment, STUN SDLC connections can be terminated locally at the router, eliminating the need for acknowledgments to be sent across a WAN.
SDLC local acknowledgment is described in the section "Establish the Frame Encapsulation Method" in the "Configuring STUN and BSTUN" chapter.
IBM Network Media Translation
The Cisco IOS software includes the following media translation features that enable network communications across heterogeneous media:
•
•
SDLLC is a Cisco Systems proprietary software feature that enables a device on a Token Ring to communicate with a device on a serial link by translating between LLC2 and SDLC at the link layer.
SNA uses SDLC and LLC2 as link-layer protocols to provide a reliable connection. The translation function between these industry-standard protocols takes place in the proprietary Cisco software.
illustrates how SDLLC provides data-link layer support for SNA communication.
Figure 11 SNA Data Link Layer Support
SDLLC Media Translation Features
The SDLLC software allows a physical unit (PU) 4, PU 2.1, or PU 2 to communicate with a PU 2 SDLC device as follows:
•
•
•
In all these topologies, each IBM end node (the FEP and cluster controller) has no indication that its counterpart is connected to a different medium running a different protocol. The 37x5 FEP responds as if the 3x74 cluster controller were communicating over a Token Ring, whereas the 3x74 responds as though the 37x5 FEP were communicating over a serial line. That is, the SDLLC software makes translation between the two media transparent to the end nodes.
Virtual Token Ring Concept
Central to Cisco's SDLLC feature is the concept of a virtual Token Ring device residing on a virtual Token Ring. Because the Token Ring device expects the node with which it is communicating also to be on a Token Ring, each SDLLC device on a serial line must be assigned an SDLLC virtual token ring address (SDLLC VTRA). Like real Token Ring addresses, SDLLC VTRAs must be unique across the network.
In addition to the SDLLC VTRA, an SDLLC virtual ring number (SDLLC VRN) must be assigned to each SDLLC device on a serial line. (The SDLLC VRN differs from the virtual ring group numbers that are used to configure RSRB and multiport bridging.)
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 VRN 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 router configured with that SDLLC VTRA intercepts the frame, fills in the SDLLC VRNA and the bridge number in the RIF, then sends the response back to the Token Ring host. A route is then established between the Token Ring host and the router. After the Cisco IOS software performs the appropriate frame conversion, the system uses this route to forward frames to the serial device.
Resolving Differences in LLC2 and SDLC Frame Size
IBM nodes on Token Ring media normally use frame sizes greater than 1 KB, whereas the IBM nodes on serial lines normally limit frame sizes to 265 or 521 bytes. To reduce traffic on backbone networks and provide better performance, Token Ring nodes should send frames that are as large as possible. As part of the SDLLC configuration on the serial interface, the largest frame size the two media can support should be selected. The Cisco IOS software can fragment the frames it receives from the Token Ring device before forwarding them to the SDLC device, but it does not assemble the frames it receives from the serial device before forwarding them to the Token Ring device.
Maintaining a Dynamic RIF Cache
SDLLC maintains a dynamic RIF cache and caches the entire RIF; that is, the RIF from the source station to destination station. The cached entry is based on the best path at the time the session begins. SDLLC uses the RIF cache to maintain the LLC2 session between the router and the host FEP. SDLLC does not age these RIF entries. Instead, SDLLC places an entry in the RIF cache for a session when the session begins and flushes the cache when the session terminates. You cannot flush these RIFs because if you flush the RIF entries randomly, the Cisco IOS software cannot maintain the LLC2 session to the host FEP.
Other Considerations
•
•
•
•
•
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.) illustrates how QLLC conversion provides data link layer support for SNA communication.
Figure 12 SNA Data Link Layer Support
As shown in , any devices in the SNA communication path that use X.25, whether end systems or intermediate systems, require a QLLC implementation.
Figure 13 SNA Devices Running QLLC
As shown in , the QLLC conversion feature eliminates the need to install the X.25 software on local IBM equipment. A device attached locally to a Token Ring network can communicate through a router running the QLLC Conversion feature with a remote device attached to an X.25 network using QLLC. Typically, the locally attached device is a front-end processor (FEP), an AS 400, or a PS/2, and the remote device is a terminal controller or a PS/2. In this case, only the remote device needs an X.25 interface and the FEP can communicate with the terminal controller as if it were directly attached via a Token Ring network.
Figure 14 Router Running QLLC Conversion Feature
More elaborate configurations are possible. The router that implements QLLC conversion need not be on the same Token Ring network as the FEP. As shown in , QLLC/LLC2 conversion is possible even when an intermediate IP WAN exists between the router connected to the X.25 network and the router connected to the Token Ring.
Figure 15 QLLC Conversion Running on Router with Intermediate IP Network
Cisco's Implementation of QLLC Conversion
SNA uses QLLC and X.25 as link-layer protocols to provide a reliable connection. QLLC itself processes QLLC control packets. In a Token Ring environment, SNA uses LLC to provide a reliable connection. The LAN-to-X.25 (LNX) software provides a QLLC conversion function to translate between LLC and QLLC.
shows the simplest QLLC conversion topology: a single Token Ring device (for example, a 37x5 FEP) communicates with a single remote X.25 device (in this case a 3x74 cluster controller). In this example, a router connects the Token Ring network to the X.25 network.
Figure 16 QLLC Conversion between a Single 37x5 and a Single 3x74
In , each IBM end node has no indication that its counterpart is connected to a different medium running a different protocol. The 37x5 FEP responds as if the 3x74 cluster controller were communicating over a Token Ring, whereas the 3x74 responds as though the 37x5 FEP were communicating over an X.25 network. This is accomplished by configuring the router's X.25 interface as a virtual Token Ring, so that the X.25 virtual circuit appears to the Token Ring device (and to the router itself) as if it were a Token Ring to which the remote X.25 device is attached.
Also in this figure, the LLC2 connection extends from the 37x5 FEP across the Token Ring network to the router. The QLLC/X.25 session extends from the router across the X.25 network to the 3x74 cluster controller. Only the SNA session extends across the Token Ring and X.25 networks to provide an end-to-end connection from the 37x5 FEP to the 3x74 cluster controller.
As shows, a router need not directly connect the two IBM end nodes; instead, some type of backbone WAN can connect them. Here, RSRB transports packets between Router A and Router B, while Router B performs all conversion between the LLC2 and X.25 protocols. Only the router attached to the serial line (Router B) needs to be configured for QLLC conversion. Both Router A and Router B are configured for normal RSRB.
Figure 17 QLLC Conversion between a Single 37x5 and Multiple 3x74s across an Arbitrary WAN
How communication sessions are established over the communication link varies depending on whether or not LLC2 local acknowledgment has been configured on Router A's Token Ring interface. In both cases, the SNA session extends end-to-end and the QLLC/X.25 session extends from Router B to the 3x74 cluster controller. If LLC2 local acknowledgment has not been configured, the LLC2 session extends from the 37x5 FEP across the Token Ring network and the arbitrary WAN to Router B. In contrast, when LLC2 local acknowledgment has been configured, the LLC2 session extends from the 37x5 FEP Router A, where it is locally terminated. A TCP session is then used across the arbitrary WAN to Router B.
Comparing QLLC Conversion to SDLLC
Although the procedures you use to configure QLLC are similar to those used to configure SDLLC, there are structural and philosophical differences between the point-to-point links that SDLC uses and the multiplexed virtual circuits that X.25 uses.
The most significant structural difference between QLLC conversion and SDLLC is the addressing. To allow a device to use LLC2 to transfer data, both SDLLC and QLLC provide virtual MAC addresses. In SDLLC, the actual MAC address is built by combining the defined virtual MAC (whose last byte is 0x00) with the secondary address used on the SDLC link; in this way, SDLLC supports multidrop. In QLLC conversion, multidrop is meaningless, so the virtual MAC address represents just one session and is defined as part of the X.25 configuration. Because one physical X.25 interface can support many simultaneous connections for many different remote devices, you only need one physical link to the X.25 network. The different connections on different virtual circuits all use the same physical link.
The most significant difference between QLLC conversion and SDLLC is the fact that a typical SDLC/SDLLC operation uses a leased line. In SDLC, dial-up connections are possible, but the maximum data rate is limited. In QLLC, both switched virtual circuits (SVCs) and permanent virtual circuits (PVCs) are available, but the favored use is SVC. While the router maintains a permanent connection to the X.25 network, a remote device can use each SVC for some bounded period of time and then relinquish it for use by another device. Using a PVC is very much like using a leased line.
shows how the QLLC commands correspond to the SDLLC commands.
Table 3
QLLC and SDLLC Command Comparison
Other Implementation Considerations
Consider the following when implementing QLLC conversion:
•
•
•
You can configure DLSw+ for QLLC connectivity, which enables the following scenarios:
•
•
For information on configuring DLSw+ for QLLC conversion, refer to the "Configuring DLSw+" chapter.
You can configure DSPUs for QLLC. For more information on this configuration, refer to the "Configuring DSPU and SNA Service Point Support" chapter.
Downstream Physical Unit and SNA Service Point
Downstream physical unit (DSPU) is a software feature that enables the router to function as a physical unit (PU) concentrator for SNA PU type 2 nodes. PU concentration at the device simplifies the task of PU definition at the upstream host while providing additional flexibility and mobility for downstream PU devices.
The DSPU feature allows you to define downstream PU type 2 devices in the Cisco IOS software. DSPU reduces the complexity of host configuration by letting you replace multiple PU definitions that represent each downstream device with one PU definition that represents the router.
Because you define the downstream PUs at the router rather than the host, you isolate the host from changes in the downstream network topology. Therefore you can insert and remove downstream PUs from the network without making any changes on the host.
The concentration of downstream PUs at the router also reduces network traffic on the WAN by limiting the number of sessions that must be esta
