Communications Server allows for two types of AnyNet support:
The AnyNet SNA over TCP/IP function in Communications Server enables SNA applications to communicate over interconnected IP and SNA networks.
The SNA over TCP/IP access node function enables SNA applications residing on an IP network to communicate. This function supports independent LU 6.2 and dependent LU 0, 1, 2, 3, or 6.2 either with or without dependent LU requester (DLUR). In addition, the SNA over TCP/IP access node can be used in conjunction with SNA gateway to enable SNA gateway sessions over TCP/IP.
The SNA over TCP/IP gateway function extends the reach of SNA applications by enabling SNA applications in an SNA network to communicate with SNA applications in an IP network. The SNA over TCP/IP gateway supports independent LU 6.2 sessions.
For more information on how to configure AnyNet SNA over TCP/IP, see Configuring AnyNet SNA over TCP/IP.
The Sockets over SNA access node function enables TCP/IP application programs using the WinSock 1.1 and WinSock 2.0 socket interface to communicate over an SNA network.
The Sockets over SNA gateway function enables sockets applications in SNA and TCP/IP networks to communicate. Sockets over SNA gateways are often used to connect isolated TCP/IP networks using an SNA backbone network.
Refer to Configuring AnyNet Sockets over SNA for more information about configuring Sockets over SNA.
This section contains detailed information about configuring AnyNet SNA over TCP/IP.
One of the most crucial steps to enable SNA over TCP/IP communication is not done through Communication Server panels. Before SNA sessions or connections can be established, SNA over TCP/IP must determine the IP address of the partner. This is achieved by mapping the SNA identifier of the partner to an IP address using the following steps:
|Note:||The default value for snasuffix is SNA.IBM.COM. For additional information on the SNA domain name suffix, refer to the online help.|
Figure 20 shows examples of domain names generated by SNA over TCP/IP.
Figure 20. Formats of the Domain Names That SNA over TCP/IP Builds
When the IP network includes SNA over TCP/IP gateways, consider the following additional address mapping issues:
This section describes the TCP/IP name resolution function, used by AnyNet to map SNA resources to IP addresses. This function queries both the local HOSTS file and any domain name servers to convert a domain name (for example, lu1.neta1.sna.ibm.com) into an IP address (for example, 10.1.1.1).
The HOSTS file (in the drivers\etc subdirectory of your Windows NT system directory) lists:
For example, if your IP address is 10.1.1.1, network ID is NETA1, SNA resource name is LUA1, and SNA domain name suffix is the default (sna.ibm.com), enter the following in your HOSTS file:
Each SNA identifier is mapped to a corresponding IP address by a domain name server. The location of these servers is configured in the Network section of the Control Panel.
For more information on HOSTS files and domain name servers, refer to your TCP/IP documentation. If your workstation is using the TCP/IP support in Windows NT, refer to the online TCP/IP documentation that is included with the Windows NT product.
The following information pertains to gateways but not to access node functions.
For configurations that have two or more SNA over TCP/IP gateways connecting an SNA network with two or more IP networks, you need todefine a unique SNA control point (CP) name and a unique SNA connection network name for each IP network.
All LUs that reside on access nodes in the IP network appear to reside on a node with this CP name.
Use the reverse data file of the domain name server or the HOSTS file to define the CP name and the connection network name for a given IP network. Map the IP address 127.0.0.3 to the CP name and map the IP address 127.0.0.4 to the connection network name.
The following example shows entries in the reverse data file. For an IP network with SNA network ID NETA, CP name MYCPNAME, and connection network name MYCNET, you would define the following entries:
127.0.0.3 NETA.MYCPNAME. 127.0.0.4 NETA.MYCNET.
The AnyNet SNA over TCP/IP function of Communications Server provides a default CP name ($ANYNET.$GWCP) and a default connection network name ($ANYNET.$GWCNET). In configurations with one IP network, you can use the default by not defining a CP name or a connection network name. In configurations with multiple gateways connecting multiple IP networks, one IP network can use the default. You must, however, define a unique CP name and connection network name for all other IP networks.
Figure 21 shows how to define the CP name and the connection network name for a configuration with two IP networks.
Figure 21. Defining a CP Name and a Connection Network Name
If you are using the SNA over TCP/IP gateway and your configuration meets the following naming restrictions, you can reduce the number of domain name server entries by defining a domain name entry for each SNA network ID that can be accessed through one or more SNA over TCP/IP gateways.
By coding a single domain name entry for each SNA network ID, you do not have to define a domain name entry for every LU in the SNA network that you want to communicate with over the IP network. You can use a wildcard entry (*) to specify the LU name of all LUs that have the same SNA network ID. By substituting a wildcard entry for the luname in the entry, you define a single domain name server entry that represents all LUs in that particular network.
|Note:||If you use the wildcard entry, you must use the full wildcard. Partial wildcards, such as LUA*, are not valid.|
The wildcard entry is mapped to the IP address of the first SNA over TCP/IP gateway used to reach the network with that SNA network ID. As shown in Figure 22, logical units SNAAPPL1, APPC1, APPC2, and LU5 reside in network NETB and can only be reached from the IP network through an SNA over TCP/IP gateway with IP address IPgwg. If the SNA domain name suffix is SNA.IBM.COM, you define the following entry in the domain name server:
This entry is used for all four logical units.
|Note:||You have the option of defining each logical unit individually.|
Figure 22. Domain Name Server Definitions for a Single Gateway Connected to an SNA Network with Two Network IDs
Each SNA network must have a unique entry. As shown in Figure 22, if you also have SNAAPPLX, APPCX, and LUY in network NETC, which can only be reached through the SNA over TCP/IP gateway with IP address IPgwg, the domain name server entries are as follows:
*.NETB.SNA.IBM.COM IPgwg *.NETC.SNA.IBM.COM IPgwg
In addition, each gateway must have a unique entry. If you add a parallel SNA over TCP/IP gateway, as shown in Figure 23, with IP address IPgwh to the preceding example, the domain name server entries are as follows:
*.NETB.SNA.IBM.COM IPgwg *.NETC.SNA.IBM.COM IPgwg *.NETB.SNA.IBM.COM IPgwh *.NETC.SNA.IBM.COM IPgwh
Figure 23. Domain Name Server Definitions for Parallel Gateways Connected to an SNA Network with Two Network IDs
The following information pertains to access nodes only, and not to gateways.
When an SNA application initiates a session, Communications Server must first determine which transport to use - either SNA, IP, or a combination of the two.
You configure which transport you prefer by setting the routing preference. The routing preference can be set for the whole node via the default routing preference on the AnyNet over TCP/IP device or on a per LU basis when defining partner LUs.
The routing preference table is used only for new sessions. Previously existing sessions use the same transport; they are not brought down and rerouted if the routing preference table is changed.
|Note:||The routing preference for a node only governs sessions that are initiated from the node (access node sessions). Sessions that go through a node are not affected by the routing preference.|
You can set or modify the default routing preference to one of the following:
This section includes examples of AnyNet enabling SNA over IP communication. The following configuration instructions are complete only for the Windows NT operating system. In all examples, the SNA domain name suffix is SNA.IBM.COM.
For more information about configuring AnyNet for any other platforms mentioned in this section (such as VTAM or AS/400), refer to the appropriate product documentation.
Follow these steps to establish communications between the two Windows NT nodes. Note that in this example, the CP names are used as LU names.
For Node A, do as follows:
For Node B, do as follows:
Follow these steps to establish communications between Node A and Node B.
For Node B, do as follows:
For Node A, add the following entries to the HOSTS file:
192.168.7.10 CP2.NETA.SNA.IBM.COM 192.168.7.10 DEPLU1.NETA.SNA.IBM.COM
Note that MVS AnyNet SNA over TCP/IP currently requires DLUS/DLUR for dependent LU communication.
Follow these steps to establish communications between Node B and the VTAM host.
For Node A, do as follows:
For Node B, add the following to the local HOSTS file:
Follow these steps to establish communications between Node C and Node A.
For Node B, do as follows:
For Node C, do as follows:
For Node A, add the following entry to the HOSTS file:
10.1.1.2 CP2.NETA.SNA.IBM.COM 10.1.1.2 DEPLU1.NETA.SNA.IBM.COM
Follow these steps to establish communications from the Nodes A and D to Node E.
For Node A, do as follows:
10.2.4.8 CP5.NETB.SNA.IBM.COM 127.0.0.4 IPNET1.GWCNET 127.0.0.3 IPNET1.CP1
For Node B, add the following entries to the HOSTS file:
10.2.4.6 CP1.NETA.SNA.IBM.COM 127.0.0.2 DEPLU1.NETA.SNA.IBM.COM 10.2.4.6 DEPLU1.NETA.SNA.IBM.COM 127.0.0.4 IPNET1.GWCNET 127.0.0.3 IPNET1.CP1
For Node C, add the following entries to the HOSTS file:
172.20.1.2 CP4.NETC.SNA.IBM.COM 127.0.0.2 DEPLU2.NETC.SNA.IBM.COM 172.20.1.2 DEPLU2.NETC.SNA.IBM.COM 127.0.0.4 IPNET2.GWCNET 127.0.0.3 IPNET2.CP2
For Node D, do as follows:
172.20.1.1 CP5.NETB.SNA.IBM.COM 127.0.0.4 IPNET2.GWCNET 127.0.0.3 IPNET2.CP2
This section contains helpful hints on tuning, TCP/IP connectivity via SLIP or PPP, and dynamic IP addresses.
If you can access an LU through multiple SNA over TCP/IP gateways, and you have mapped that LU name to multiple IP addresses, increase the CONN_RETRY_SECS and CONNWAIT_SECS parameters of the ANYNET_COMMOM_PARAMETERS keyword when configuring the AnyNet base parameters. This ensures that TCP connections will be attempted to all possible adapters and gateways. It can take as long as 90 seconds for a TCP connection to fail to an inactive IP address.
Generally, AnyNet SNA over TCP/IP depends on SNA resources (for example, LU names, CP names, or idblk/num) being statically mapped to IP addresses. However, depending on your configuration and how your connections are initiated, you might be able to use AnyNet SNA over TCP/IP in environments where IP addresses are dynamically assigned (for example, DHCP).
An SNA over TCP/IP access node with a dynamically assigned IP address may always initiate sessions to another SNA over TCP/IP access node or gateway with a static IP address.
The only way an SNA over TCP/IP access node or gateway with a static IP address (node A) can initiate a session to a partner with a dynamic IP address (node B) is:
|Note:||The information in this section applies to LU 0, 1, 2, 3, or dependent 6.2 applications.|
SNA over TCP/IP access nodes with dynamically assigned IP addresses can support dependent LU communications if the following criteria are met:
Dependent LU communication through DLUS/DLUR over AnyNet SNA over TCP/IP is not supported if the DLUR node has a dynamically assigned IP address.
This section contains information about how to configure Sockets over SNA.
The Sockets over SNA access node function of Communications Server enables WinSock compliant applications to communicate over SNA networks. The Sockets over SNA gateway function enables socket applications in SNA and IP networks to communicate.
Figure 24 shows the structure of a Windows NT node that is running Sockets over SNA and illustrates how socket application programs and Sockets over SNA operate on a Windows NT node.
Figure 24. Structure of a Windows NT Node Running Sockets over SNA
WinSock is an API that lets socket applications run in a Windows environment.
Sockets over SNA does not provide a WinSock interface and does not process socket calls. Instead, WinSock applications use the WinSock interface of the native TCP/IP stack. The Sockets over SNA gateway code enables these applications to communicate across the SNA network.
Sockets over SNA gateway will allow socket applications running in an IP network to communicate with socket applications running on Sockets over SNA nodes. This is accomplished by routing packets between the SNA and IP networks and transforming them between SNA and IP protocols. The AnyNet gateway device driver assists in routing packets between TCP/IP and SNA networks, and the Sockets over SNA code converts between the two protocols.
To enable TCP/IP-formatted information to route over SNA, Sockets over SNA maps IP addresses to SNA network-qualified LU names. When an application program invokes Sockets over SNA to establish a stream connection with another application program, Sockets over SNA establishes two half-duplex LU 6.2 conversations for the stream connection.
Sockets over SNA establishes one LU 6.2 conversation for all datagrams sent to a single destination. Conversations dedicated to datagram traffic are deallocated if they are unused for some specified period of time.
When an application program invokes Sockets over SNA to communicate with another application program, it supplies the IP address of the destination node. Sockets over SNA must map the IP address to an SNA address to issue an appropriate LU 6.2 call. For every IP address that identifies a node, there will be a corresponding SNA network-qualified name.
Routing and Mapping Overview explains how address mapping works and provides guidelines and requirements for setting up IP-LU address mapping.
Sockets over SNA gateways enable communication between socket application programs in IP and SNA networks by combining the routing function of TCP/IP with the protocol translation and address mapping capabilities of Sockets over SNA.
Protocol translation and address mapping are required when data is routed between nodes that use different transport protocols. The Sockets over SNA gateway automatically performs protocol translation after determining the type of transport associated with the destination IP address. For a summary of the routing and mapping process, see How the Sockets over SNA Gateway Routes and Maps Data.
Sockets over SNA supports WinSock 1.1 and WinSock 2.0 (Windows NT 4.0 only) applications that use AF_INET sockets.
Sockets over SNA does not support applications that use broadcasting.
If you intend to use Sockets over SNA gateway to route information to and from an MVS/ESA node configured with the VTAM V3R4.2 Sockets over SNA function, you must first install the route function on the MVS/ESA node. To install the route function on MVS/ESA, install the program temporary fix (PTF) UW03567. You can obtain PTFs through any of the following sources:
If you do not have access to these sources, contact the IBM Support Center.
This section describes what the network planner should consider before configuring a network with Sockets over SNA.
This section explains basic concepts of Internet addressing and how these concepts relate to routing and mapping. It includes the following information:
Every host is assigned at least one unique Internet Protocol (IP) address, which is used to route data through the network.
|Note:||In the IP suite of protocols, host refers to an end system and can be any workstation; it does not have to be a mainframe.|
The IP address assigned to the host does not define a host on the network; it defines a network interface on that host to a network. For example, the address of the SNA network interface identifies a node's connection to the SNA network.
A gateway host has a unique IP address for each network interface. Because Sockets over SNA gateway routes SNA and TCP/IP data, you must set up unique IP addresses for the TCP/IP and SNA interfaces.
The following section describes the IP address format, address classes, and network masks. For more detailed information, see your TCP/IP documentation.
An IP address consists of a 2-part, 32-bit address field:
Default network masks are shown in Table 5.
Table 5. IP Address Masks Supported by Sockets over SNA
|For a dotted decimal IP address in the form a.b.c.d, the range of values for a is:||Default Network Mask|
Sockets over SNA uses two types of masks:
The subnet mask is used in routing and is specified during the configuration of the local node and routes. You can accept the default subnet mask or specify a value other than the default to define subnetwork addresses.
The address mask is used for generated IP-LU address mapping and is specified during configuration.
Each host has an IP routing table that stores information about possible destinations and how to reach them. Route entries are added when:
For a routing table example, see Figure 25.
For each route you define through the SNA interface (sna0), there must be a corresponding SNA network ID to which the IP network address is mapped. The number of SNA network IDs you define depends on how you want to map the IP network to the SNA network.
For example, if the socket applications using SNA are configured to use IP subnetworks 188.8.131.52 and 184.108.40.206, you can define an SNA network ID that corresponds to each IP subnetwork, or you can define one SNA network ID that corresponds to both subnetworks. Sockets over SNA does not require a unique one-to-one mapping between an IP network address and an SNA network ID.
You can use either explicit or generated mapping to map IP addresses to SNA LU names:
Sockets over SNA uses the address mask to map the network portion of the IP address to the SNA network ID and the host portion to the SNA LU name. The LU template value is used to determine the characters and the positions of characters used in the LU name.
You can display the generated LU name for a given IP address using the sxmap command line utility. The syntax for this utility is:
sxmap convert <IP address> <address mask> <LU template>
The following steps briefly describe how Sockets over SNA Gateway determines whether to route data over SNA or TCP/IP, and how address mapping is handled:
Figure 25 shows an example of an IP routing table.
Figure 25. Example of an IP Routing Panel
+--------------------------------------------------------------------------------+ |Destination IP Address Destination Mask Gateway IP Address Use Count | |---------------------------------------------------------------------------- | |220.127.116.11 255.255.255.255 18.104.22.168 10 | |10.0.0.0 255.0.0.0 22.214.171.124 0 | |10.11.0.0 255.255.0.0 126.96.36.199 37 | |127.0.0.1 255.255.255.255 127.0.0.1 8 | |188.8.131.52 255.255.0.0 184.108.40.206 0 | |220.127.116.11 255.255.255.0 18.104.22.168 368 | +--------------------------------------------------------------------------------+
The route discovery function provided by Sockets over SNA gateway can help you route TCP/IP traffic more efficiently and reduce the number of explicitly defined route statements in your network. You do not have to select or configure this function.
One of the problems with large networks is how to discover the addition of new networks or subnetworks and which router to use to get to the new network or subnetwork. Sockets over SNA solves this problem by having all nodes initially use a default router that notifies other nodes when a more direct route is discovered. This is more efficient than using the typical TCP/IP solution of broadcasting routing information.
|Note:||To effectively use this function, algorithmic mapping of IP addresses to LU names and an APPN backbone network should be used. Otherwise, nodes must explicitly define LU names and IP addresses for all remote nodes with which they communicate.|
Figure 26 shows a configuration example.
Figure 26. Example of a Network Using the Sockets over SNA Route Discovery Function
In this scenario:
Gateways 2 and 3 define Gateway 1 as their default router. If a remote network or subnetwork is known to Gateway 1, Gateways 2 and 3 do not have to explicitly define these routes.
If the network or subnetwork is known to Gateway 1 and a more direct path is available, Gateway 1 sends an ICMP redirect message back to the requester indicating the path to take in the future. This ICMP redirect message updates the requester's routing table. Therefore, Gateways 2 and 3 dynamically build their routing tables for remote networks and subnetworks as needed.
Sockets over SNA uses LU 6.2 conversations to enable communication between socket application programs. When an LU 6.2 conversation is established, Sockets over SNA defines the mode and associated session characteristics of the connection. Communications Server uses the mode name to identify characteristics of the connection between the two Sockets over SNA nodes.
The default Sockets over SNA mode is BLANK. You can use the default mode for Sockets over SNA or define your own. To change the default Sockets over SNA mode, from the SNA Node Configuration window, click Configure AnyNet Sockets Over SNA and then click Modes. You can define another default mode for all TCP/IP traffic and assign a specific mode to a specific TCP/IP port.
If you specify an alternative mode that is not defined by Communications Server, you must define the session characteristics associated with that mode to Communications Server.
The idle timeout start option enables you to adjust the number of idle seconds before Sockets over SNA deallocates a datagram conversation. This interval enables you to balance using system resources to maintain an existing datagram conversation and taking longer to reestablish a new datagram conversation. For example, if you set this value low, unused datagram conversations end faster, but it takes longer to send the next datagram. The default idle-timeout interval is 90 seconds.
To modify the start option, from the SNA Node Configuration window, click Configure AnyNet Sockets over SNA, then click View/Change/Add, click the Advanced tab and select a new value for this option.