Case Study: Using DLSw Backup Peers to Control Routing

CASE STUDIES
from the files of
Networking Unlimited, Inc.

WebQuery@NetworkingUnlimited.com
14 Dogwood Lane, Tenafly, NJ 07670
Phone: +1 201 568-7810

Using DLSw Backup Peers to Control Route Utilization

A worldwide organization had performance problems due to the high priority assigned to DLSw traffic on their international links when the SNA service was used for bulk transfers. Networking Unlimited, Inc. designed a configuration that forced only the SNA traffic onto a dedicated low speed link while retaining the ability to automatically use the shared international links for backup as required.

Background

The international links of a worldwide organization were carefully sized to run at nearly full capacity to minimize cost. Weighted fair queuing was used to keep the performance of interactive applications high even when the links were fully loaded with bulk traffic. Problems arose when one of the branches of the organization, running in a pure IBM SNA environment, started transferring large database files (multiple gigabyte size). Because SNA traffic was normally interactive, Data Link Switching (DLSw) was queued at interactive priority and the database transfers had a tremendous negative impact on network performance.

Due to political considerations, upgrading to Cisco proprietary Data Link Switching Plus (DLSw+) was not an option, nor was using FTP to support the database transfers.

Technical Approach

Since the normal level of interactive SNA traffic used by this branch was not that high, Networking Unlimited, Inc. took a two pronged approach to solving the congestion problems. Short term, a low speed line was procured between the two sites guilty of the database transfers. Because the normal SNA traffic was mission critical, it was unacceptable to have a single point of failure between the two sites. At the same time, the routing weights for the link could not be arbitrarily adjusted or the slow link would wind up carrying corporate backbone traffic and be immediately swamped. Indeed, since the link was between autonomous OSPF routing domains routed using BGP, only static routing was acceptable to maintain corporate network stability.

The trick used to force all the DLSw traffic between the two sites to use the dedicated link but not interfere with the corporate network routing, was to use network address translation in the routers at each end of the dedicated link to map the remote addresses at the other end into addresses in the local routing domain. DLSw peerings were then set up to the translated addresses with backup peerings to the corporate addresses. Since NAT allows the dedicated link to present a local address at each end, rather than the real address at the other end of the link, there is no conflict with interdomain routing nor potential for corporate traffic to utilize (and overflow) the link.

DLSw is not affected by the addressing, as SNA sees the connection as a bridged link. By using the DLSw backup commands in IOS 11.2, DLSw peerings communicating over the corporate network are automatically brought up any time the dedicated link should fail, meeting the critical need for no single points of failure. (The actual configuration uses DLSw on two routers at each end, so that failure of a DLSw router will not be a single point of failure either.)

The second prong of the two pronged attack was to use the cost of the dedicated link as a motivator to convince the branch management that implementing FTP on their IBM systems would be a cost saving, rather than costly, solution. Plus they now have the time to test it thoroughly before putting it into production and can delay dismantling the dedicated link until they are sure it is no longer required.

Bottom Line Results

The dedicated link alleviated the congestion problems on the corporate backbone and allowed avoidance of a high cost emergency upgrade. It also resulted in a substantial increase in the time required to execute the database transfers, further encouraging the move to a long-term FTP based solution. The one difficulty which was uncovered was a lack of management visibility of the DLSw peer status in standard network management systems. As a result, a failure which blocked DLSw on the dedicated link but otherwise left the link unaffected was not detected for over a week, and even then the discovery was accidental and only lucky timing prevented a large transfer from overloading the corporate network.