Logo: TUG TORONTO USERS GROUP for Midrange Systems
e -server magazine

January 1997: Volume 12, Number 3

Communicating with Sam

SNA Over Wide Area Networks

By Sam Johnston

From the questions submitted, the selected issue to be addressed in this issue is:


ur company has had a routed frame relay network for just over a year. We are primarily an AS/400 terminal environment, with a small amount of LAN traffic currently. Our current network traffic is 80-90% SNA, however, we have plans to introduce additional Client/Server applications that will significantly increase the amount of IP. I am concerned that our network as configured will not be able to handle the additional IP traffic. Although SNA is generally thought to be very efficient, since introducing the LAN traffic we have had response time issues and have lost mission critical sessions. Our WAN backbone is based on Cisco routers and 56kb frame relay nodes. I am concerned that we will require significant band width increases to support our future environments. Any suggestions?


ou are correct in your comment regarding the efficiency of SNA over the wide area. In our experience, typical AS/400 users deploying SNA as the network protocol for AS/400 data experience very good response times and relatively low network utilization levels, provided routing is done using Data Link Switching (DLSw), the native way to route SNA traffic. The SNA traffic is not very chatty, versus IP or typical LAN traffic, and is very good for ensuring the integrity of mission critical network traffic.

However, given the timing of when you implemented your frame relay network, and given that the backbone is based upon Cisco routers, your current and future issues are likely related to the current network configuration, as opposed to strictly band width. Cisco routers have their roots in routing IP traffic, or in other words wide area networks primarily designed to support LAN originating traffic. Historically, Cisco routers have handled SNA traffic via a methodology called IP Tunneling. In essence, this means that SNA traffic is converted to IP traffic for routing over the WAN. This technique has several disadvantages.

First, IP traffic is very chatty by nature, unlike the very efficient SNA traffic that is native to the AS/400. Hence, the band width required to support comparable levels of IP versus SNA traffic is significantly greater, and consequently more expensive. Given the dominance of SNA in your current network, this is likely why you are so surprised by the response time issues your are experiencing.

The second draw back to IP tunneling is the homogenization of your network traffic into IP, and the resulting difficulty in prioritizing protocols over the network. Your SNA traffic is likely mission critical, which is why you mentioned the issue of losing SNA sessions. Due to all traffic looking the same, it is impossible for you to ensure that your SNA traffic gets priority. The answer, as you have indicated, is to increase the available band width to ensure that you can service the very high peaks. The inability to place priority on your SNA traffic of course compounds the issue of your network already being needlessly chatty due to the IP predominance.

Although band width increases may be necessary as Client/Server applications grow within your environment, the issue remains that you always require needless network capacity until you route the critical SNA traffic via DLSw. Most leading router brands, such as Bay Networks, IBM of course, and now Cisco, provide SNA routing using DLSw in compliance with RFC1795. However, in the case of Cisco, the software that enables DLSw is an upgrade to the basic software. My recommendation would be that prior to increasing your band width, that you implement DLSw in a pilot environment, monitoring the change in network utilization levels. This will most certainly improve response times for those users and eliminate the loss of SNA sessions. It will also provide you with the necessary information for capacity planning the WAN backbone that is required to support the new applications. T < G

Note: Any TUG member wishing to submit a question to Sam can e-mail or forward their typewritten material to the TUG office, or to Intesys. We would be pleased to publish your question and Sam's answer in an upcoming issue of the TUG e-server magazine.