Table Of Contents
This chapter shows the basic configuration of several of the most common networks. The chapter covers network design and explains why and when to use a particular network design. It briefly describes how to migrate from, or coexist with, a FEP for each of the sample networks. In some cases, before and after pictures of the network and step-by-step configuration instructions are included.
This chapter includes the following scenarios:
•Scenario 1—Replacing a FEP with a single CMCC on a single host
•Scenario 2—Replacing a FEP with a redundant CMCC on a single host
•Scenario 3—Replacing a FEP with a single CMCC on multiple hosts
•Scenario 4—Combining SNASw with DLSw+
•Scenario 5—Migrating to SNASw only
•Scenario 6—Migrating to TCP/IP across CLAW
•Scenario 7—Migrating to TCP/IP across CMPC+
To use the scenarios, you must include the VTAM definitions and configure your routers, which are discussed in the following sections.
Using SNA Communication over CSNASNA nodes communicate with the CMCC using LLC2, a connection-oriented data-link protocol for LANs. An LLC2 stack on the CMCC card communicates with either the adjacent SNA device (over a physical Token Ring) or to DLSw+ or SNASw running in the channel-attached router, as illustrated in Figure 6-1.
Figure 6-1 Communication between CSNA in the CMCC and SNA Nodes
The CMCC running CSNA can support multiple internal LAN interfaces, each appearing as a LAN port to the VTAM. Although VTAM supports a maximum of 18 LAN ports, only a single LAN port is required. CSNA also supports up to 256 open LLC2 service access points (SAPs) per LAN port.
Using VTAM DefinitionsThe CMCC running CSNA is not an SNA-addressable node, because it has no PU or LU appearance. CSNA is defined to the host control program (MVS or VM) as a channel-to-channel machine (an IBM 3088). CSNA provides VTAM with a physical connection to the LAN through a subchannel.
To enable VTAM communication over the CMCC to SNA devices, you must configure an XCA major node and a switched major node to VTAM. The XCA major node allows VTAM to communicate with the CMCC, and the switched major node definition allows SNA devices to communicate with VTAM over the CMCC.
XCA Major Node DefinitionDefine an XCA major node for each connection (port) between the VTAM and a CSNA. A single XCA major node can support up to 4096 LLC2 connections, although better results are achieved with 3000 or fewer LLC2 connections per XCA major node. If more LLC2 connections are needed, define additional XCA major nodes as well. You can configure multiple XCA major nodes for availability, with each node pointing to a different CMCC.
The CSNA feature is defined to the host control program (MVS or VM) as being a channel-to-channel adapter (CTCA) or machine; for example, an IBM 3088. VTAM identifies the CSNA gateway through a combination of the following:
• ADAPNO—Adapter number
• SAPADDR—SAP address
The following configuration provides an example:
Switched Major Node DefinitionConfigure one or more switched major nodes. Within a switched major node definition, configure every SNA PU that will access VTAM through the CMCC. For each PU, configure its associated LUs. Many networks today already include SNA devices defined in a switched major node. For example, if the devices attach to a FEP over Token Ring, the devices are defined as part of a switched major node. In this case, the only change is to add the XCA major node.
The following configuration provides an example:
Configuring RoutersYou must configure the router to:
•Bridge the traffic from a physical LAN or a router component (DLSw+, SRB, SR/TLB, and so on) onto the router virtual ring
• Bridge the data from the router virtual ring to one of the CMCC internal rings, or connect a data-link user (APPN or DSPU) to one of the CMCC internal rings
•Connect the CMCC to VTAM
Figure 6-2 shows the major configuration parameters of CMCC and Token Ring interfaces and how they are logically combined using the source-bridge definition. The CMCC ring is referred to as an internal ring. The Route Switch Processor (RSP) ring is referred to as a virtual ring.
Figure 6-2 Using Virtual Rings to Provide Connectivity
Configure an adapter on the CMCC to associate with the XCA major node definition. For each adapter you configure, CSNA creates an internal Token Ring. A virtual bridge connects the CSNA internal ring to a virtual ring group in the router. The Token Ring Interface Processor (TRIP) is also configured to connect to the same virtual ring group as the CMCC.
Understanding Configuration Relationships in the ESCON EnvironmentFigure 6-3 shows the relationship among router configuration, VTAM parameters, and MVS IOCP generation commands when the CMCC connects via an ESCON Director.
Figure 6-3 Configuration Relationship in an ESCON Environment
Understanding Configuration Relationships in the Bus and Tag EnvironmentFigure 6-4 shows the relationship among router configuration, VTAM parameters, and MVS IOCP generation commands when the CMCC connects via bus and tag.
Figure 6-4 Configuration Relationship in a Bus and Tag Environment
Scenario 1—Replacing a FEP with a Single CMCC on a Single HostThe first scenario describes a network that replaces a FEP with a CMCC. As shown in Figure 6-5, a single mainframe exists in this network. Historically, IBM SNA networks were built using the IBM FEP, and remote terminals were connected via SDLC links. In the Before scenario, a second FEP was in place only for backup. In the After scenario, one FEP is replaced with a channel-attached router with a CMCC. Both the CMCC and the remaining FEP have the same MAC address. Eventually, the second FEP also will be replaced, but for now it provides SNI connectivity to a supplier and functions as a backup to the CMCC. DLSw+ is used to transport SNA traffic from remote sites to the central site. When data reaches the headquarters site, DLSw+ sends the traffic to the CMCC, which is the first to respond to explorers. In the event the CMCC is not available, the FEP is used automatically.
Figure 6-5 Single CMCC to Single Host
Reasons for ChangeThe FEP was at capacity and the company preferred to use its IS dollars on technology that would carry the company into the future while addressing today's requirement. In addition, the Cisco channel-attached router replacing the leased FEP would pay for itself in 18 months—with savings coming from lease costs and monthly NCP licensing costs. Migrating from an SDLC/FEP network to a LAN/channel-attached router network simplified SNA system configuration significantly and reduced the downtime for planned outages. Finally, this infrastructure enabled the customer to use TCP mainframe applications in the near future.
Design ChoicesThis customer opted to combine SNA functionality (DLSw+) and WAN connections in the CMCC router because the network was very small (25 sites). The design provided a very safe fallback to the FEP, but at the same time enabled SRB dynamics and configuration simplicity.
XCA Major Node Configuration
Implementation OverviewThe first step is to implement DLSw+ from the remote site to the central site and to change the FEP access from SDLC to Token Ring. As part of this step, configure the VTAM switched major nodes. Next, perform the following steps to enable the CMCC in this configuration:
Step 1. Perform IOCP generations to configure the channel definitions, as shown in Figure 6-5.
Step 2. Configure the VTAM XCA major node.
Step 3. Configure the attached router with the CMCC definitions and bridge traffic from the internal ring group to the CMCC virtual ring.
Step 4. Vary the channel online (Vary E00,ONLINE).
Step 5. Confirm the CMCC is online (Display U,,,E00,1).
Step 6. Activate the VTAM XCA (Vary NET,ACT,ID=name_of_member).
Scenario 2—Replacing a FEP with a Redundant CMCC on a Single Host
Initially this site had an IBM 3745-410 running in twin-standby mode to provide better network resiliency. In this case there is one active NCP while the second one is in standby mode. The second NCP takes over only if the first NCP has problems. This allows quick recovery from storage-related failures and from a CCU hardware check. Note that the idle CCU is inactive unless a failure is detected. With the inclusion of duplicate Token Ring addressing, this design provides another level of network redundancy.
Optionally, the IBM 3745-410 could be configured in twin-backup mode, where each CCU controls approximately half the network. It is the equivalent of having two IBM 210s running at half capacity. If there is a failure in one CCU, the other takes over, just as in the first example. However, only half the resources are impacted, resulting in a faster recovery.
Regardless of the current configuration, the use of CSNA on two Cisco 7500 Series routers with one or more CMCC cards can provide better load sharing and redundancy features, as described in the Designing for High Availability section.
The After scenario is designed without a single point of failure in the network. The redundant CMCC to a single host scenario is often used when the end systems cannot afford the downtime of a failure. For many companies that require online access to provide 24-by-7 customer support, the loss of host access for even a short period can incur a significant loss in both income and credibility. It is important for these networks to implement a solution that avoids or minimizes the amount of downtime due to network problems. Also, for these companies the redundancy option provides the necessary network configuration to perform maintenance or configuration changes with minimal impact on the end-system users.
Providing redundancy to the single CMCC to single host solution is quite straightforward. In Figure 6-6, two Cisco 7500 Series routers, each with a CMCC, are deployed in place of the IBM 3745-410. In this example both CMCCs have the same virtual MAC address. When one router is unavailable, the SNA end system automatically finds the backup router using standard SRB protocols. Note that in both the Before and the After networks, the loss of a channel-attached gateway is disruptive.
Figure 6-6 Redundant CMCCs to Single Host
Reasons for ChangeThe IBM 3745-410 did not have the capacity to support the entire network if one of the processors was down. During outages, the entire network slowed down. To address this problem with more FEPs was not cost-effective. In addition, this enterprise was considering migrating to FDDI, which the IBM 3745 does not support. With the Cisco channel-attached routers, the company could migrate its campus to FDDI, ATM, or Gigabit Ethernet in the future.
Design ChoicesIn this network they opted to separate DLSw+ from the channel-attached router, thus minimizing both scheduled and unscheduled outages in their network. Also, they already had DLSw+ installed in these routers before they installed the CMCCs, which simplified migration. Finally, as their DLSw+ routers (Cisco 3600s) reach capacity, it would be less costly to add a Cisco 3600 Series router than a Cisco 7500 Series router with a CMCC. Either of the channel-attached routers could handle their entire capacity today, and if the network were to grow, they would have sufficient slots in their Cisco 7500 Series routers to add CMCCs.
The network uses load balancing across central site DLSw+ routers and duplicate Token Rings to ensure there is no single point of failure, as shown in Figure 6-7.
Figure 6-7 Dual Routers with Duplicate MACs
Router ConfigurationThis configuration uses the same MAC address on internal Token Ring LANs of two different routers:
Scenario 3—Replacing a FEP with a Single CMCC on Multiple HostsThis scenario reflects a legacy SNA network with several remote sites connected via SDLC links to cluster controllers. Also, a high-speed line was connected to a remote IBM 3745 at a site that demanded high-speed connection back to the mainframe, but had more remote users than a cluster controller could support. This enterprise also had a separate multiprotocol network running in parallel.
At the data center, there are two VTAM's. One is used primarily for production and the other for testing. There is little, if any, cross-domain routing. Figure 6-8 shows the Before and After networks.
Figure 6-8 Replacing a Single FEP with a Channel-Attached Router
Reasons for ChangeThe primary reasons for change were to minimize costs and increase throughput and flexibility. The remote IBM 3745 was replaced with a lower-cost Cisco 4500 Series router to eliminate recurring NCP and maintenance charges, consolidate multiprotocol and SNA WAN traffic, and simplify network configuration. The central site FEP was replaced with a channel-attached router to increase channel throughput and to enable TCP/IP on the mainframe in the future.
Design ChoicesThis enterprise chose not to implement APPN despite having multiple mainframes. The reason is that all SNA sessions were in the same domain. The VTAM in the second mainframe was used just for testing and backup. They decided against implementing two channel-attached routers for redundancy, but did use two CMCCs in a single channel-attached router. This created higher availability than they had previously and provided an option to separate CMCC functionality across multiple CMCCs in the future. They plan eventually to add TN3270 Server capability to the CMCC to allow access to VTAM applications from Web-based clients. They also anticipate a need for TCP/IP on the mainframe. Figure 6-9 shows the logical configuration.
Figure 6-9 Dual CIPs in a Single Router
Scenario 4—Combining SNASw with DLSw+In this case study, the enterprise wants to leverage its Parallel Sysplex complex and achieve the high availability it affords. The customer is migrating to Gigabit Ethernet in the data center and the applications are being rewritten to run TCP/IP natively. However, it will be several years before that migration is complete, and in the interim, the customer wants the high availability and design simplicity afforded by having an all-IP data center.
Reasons for ChangeThis enterprise already uses DLSw+ to transport SNA traffic over an IP backbone. The customer chose not to make an additional investment in SNASw for the branch because the DLSw+ network has been very stable, and if outages occur, they affect only a small portion of the network (by design) and are recovered automatically. However, the customer wants to ensure that a CMCC or channel outage (which today would bring down almost the entire network) can be handled transparently. Hence, the customer is adding SNASw to the SNA routers. The SNA routers use DLSw+ to transport SNA traffic to and from the branch routers and use HPR over IP to transport SNA traffic to and from VTAM. By using HPR over IP directly to VTAM, the customer eliminates any potential looping problems that can occur in a bridged Ethernet environment. In addition, should a channel failure occur, IP immediately reroutes traffic and SNA sessions are not impacted. Finally, this design positions the customer to use a Gigabit Ethernet OSA-Express for SNA traffic.
This enterprise chose to keep the SNA data center router separate from the WAN distribution router to simplify change management and maximize availability. Two CIPs (one primary and one backup) run IP to handle all the SNA traffic, and six Cisco 7200 Series routers run DLSw+ (to handle a 1000-branch network), including one DLSw+ router used only for backup. Figure 6-10 shows the basic components of this design.
Figure 6-10 Combined SNASw and DLSw+ Design
DLSw+/SNASw Data Center Router ConfigurationThe following configuration is for the SNASw router named Coppito:
IP Channel-Attached Router Configuration
Scenario 5—Migrating to SNASw onlyIn this case study, the enterprise demands the highest availability for its SNA applications.
Reasons for ChangeThe customer has invested a great deal in developing SNA LU 6.2 applications over the years and wants to continue to leverage that investment. The customer has been running separate networks for SNA and IP and has decided to consolidate using SNASw with HPR over IP. The network is already at the latest operating system level and is running APPN in VTAM.
The OSA-Express Gigabit Ethernet card is for TCP/IP environments only. This card supports SNA traffic when SNA is encapsulated in IP using the EE support in OS/390 Version 2, Release 7 or higher.
Design ChoicesThe customer has 200 regional offices that will run SNASw. From the branch into the S/390, the SNA traffic is transported in IP. Hence, there is no need for SNA routers in the data center. The customer leverages the Cisco IOS QoS features to ensure that the interactive SNA and Telnet traffic take precedence over SNA batch and FTP traffic. Figure 6-11 shows this design.
Figure 6-11 SNASw Design
SNASw Branch Router Configuration
IP Channel-Attached Router Configuration
Scenario 6—Migrating to TCP/IP across CLAWIn this scenario, a customer wants to increase the reliability and robustness of the network by migrating to TCP/IP.
Reasons for ChangeMany companies implement a client/server environment by using the database applications available on distributed UNIX or Windows NT servers. Companies also leverage the centralized nature of mainframes to back up this distributed data. IBM's backup product, Tivoli Storage Manager, previously known as ADSTAR Distributed Storage Manager (ADSM), is used to store large amounts of data from distributed platforms to a central mainframe resource (either direct access storage device [DASD] or tape).
Figure 6-12 shows the schematic for this scenario, in which four Sun servers are used for distributed database applications. Each night, the servers use Tivoli Storage Manager to transfer 250 GB data to the centralized mainframe for backup during a three-hour window.
Figure 6-12 Bulk Data Transfer from Distributed UNIX Servers to Central Mainframe
Testing of a CIP in IP Datagram mode determined that a single CIP processor can transfer 18.4 MBps across two ESCON channels. Therefore, two CIP processors can transfer 36.8 MBps. In one hour, the data center router can transfer 133 GB per hour:
36.8 MB per second x 60 seconds per minute x 60 minutes per hour = 133 GB per hour
Therefore, a Cisco 7507 with two CIP cards with dual ESCON interfaces (four ESCON channels) and two Asynchronous Transfer Mode (ATM) interface processors is capable of transferring 133 GB per hour. To determine the amount of time required to transfer the 250 GB of data in the bulk data transfer application example:
250 GB / 133 GB per hour = 1.88 hours, or 112 minutes
As these calculations demonstrate, the Cisco data center router can support the required data transfer rate.
Design ChoicesThe customer considered several factors before choosing the appropriate components to implement this solution. Although speed and cost were certainly important, the overriding concerns were robustness and reliability. For these reasons, the customer chose CLAW as the channel protocol, because it has been implemented in thousands of data centers and been in widespread use for more than five years.
If your OS/390 host environment supports the use of the Gigabit Ethernet OSA-Express, you should consider the use of OSA-Express with the Tivoli Storage Manager. This solution is optimized to provide very high throughput for bulk data transfer using Large Format Ethernet Frames (also known as Jumbo Frames) and can achieve data transfer rates approaching Gigabit Ethernet speed.
Router ConfigurationFor configuration examples, see www.cisco.com/warp/public/650/8.html.
Scenario 7—Migrating to TCP/IP across CMPC+This scenario describes a customer who wants to redesign the OS/390-based data center. This customer wants to migrate from SNA to pure IP using CMPC+.
Reasons for ChangeThe network architecture group needed to redesign its OS/390-based data center to be the core of a fully enabled e-business and multiservice environment. They had been using CMCC technology for several years to connect both TCP/IP and SNA clients to the S/390s using CLAW channel protocol for the IP traffic and using CSNA for the SNA traffic.
The customer carefully considered and decided that the requirement for successfully moving forward was the ability to control QoS across all applications, from traditional SNA through voice over IP. The customer realized that achieving acceptable QoS would be impossible without removing the protocols that depend on OSI Layer 2 mechanisms for flow control, and that moving to a purely IP transport-based solution would be the best way to optimize positioning for the future.
Design ChoicesTo reach the goal of building an IP-based backbone network, the customer needed to find a way to transport significant amounts of SNA traffic without depending on the traditional Layer 2-based protocols. EE, which transports SNA data directly over IP, provided the answer. Because this group had extensive experience with CMCC technology, the decision was then largely a matter of deciding which of the IP-capable channel protocols to choose. They decided that CMPC+ provided the best balance of performance for the resulting mix of interactive, batch, and streaming traffic.
Router ConfigurationFor configuration examples, see www.cisco.com/warp/public/650/8.html.
CMPC+ with TCP/IP Stack ExampleThis example demonstrates the TCP/IP link for CMPC+ between a host and a Cisco router with a CMCC adapter. The following configuration is for the CIP in the Cisco 7500 Series router:
In this configuration, the CMPC+ configuration is for the TCP/IP stack on the host. The host IP address of 126.96.36.199 in the transmission group statement corresponds to the IP address for the TCP/IP stack in the
TCP/IP profile on the host. The IP address for the CIP is 188.8.131.52.
TCP/IP ProfileThe following example shows the TCP/IP profile on the host:
In this TCP/IP profile, the DEVICE specifies the VTAM TRLE mpc4b00 and LINK specifies the link name (MPCPLNK2) associated with the IP address (184.108.40.206) for that link. The host IP address 220.127.116.11 that is specified for the transmission group in the router configuration must be identical to the IP address specified for the transmission group in the router configuration.
TRL Major Node ExampleThe following configuration shows the TRL major node example:
In this TRL major node example, the parameter MPC4B00 must be identical to the LINK parameter in the