Configuring Other Routing Protocols

Cisco IOS software on the Catalyst 4224 Access Gateway Switch supports the following additional routing protocols:

Novell IPX

Novell Internetwork Packet Exchange (IPX) is derived from the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP). IPX and XNS have the following differences:

IPX and XNS do not always use the same Ethernet encapsulation format.
IPX uses the Novell proprietary Service Advertising Protocol (SAP) to advertise special network services. File servers and print servers are examples of services that typically are advertised.
IPX uses delay (measured in ticks) while XNS uses hop count as the primary metric in determining the best path to a destination.

The Cisco Implementation of Novell IPX

The Cisco implementation of the Novell IPX protocol is certified to provide full IPX routing functionality.

IPX MIB Support

Cisco supports the IPX MIB (currently, read-only access is supported). The IPX Accounting group represents one of the local Cisco-specific IPX variables Cisco supports. This group provides access to the active database that is created and maintained if IPX accounting is enabled on a router or access server.

IPX Enhanced IGRP Support

Cisco IOS software supports IPX Enhanced IGRP, which provides the following features:

Automatic redistribution—IPX Routing Information Protocol (RIP) routes are automatically redistributed into Enhanced IGRP, and Enhanced IGRP routes are automatically redistributed into RIP. If desired, you can turn off redistribution. You also can completely turn off Enhanced IGRP and IPX RIP on the device or on individual interfaces.
Increased network width—With IPX RIP, the largest possible width of your network is 15 hops. When Enhanced IGRP is enabled, the largest possible width is 224 hops. Because the Enhanced IGRP metric is large enough to support thousands of hops, the only barrier to expanding the network is the transport layer hop counter. Cisco works around this problem by incrementing the transport control field only when an IPX packet has traversed 15 routers, and when the next hop to the destination was learned via Enhanced IGRP. When a RIP route is being used as the next hop to the destination, the transport control field is incremented as usual.
Incremental SAP updates—Complete SAP updates are sent periodically on each interface until an Enhanced IGRP neighbor is found, and thereafter only when changes are made to the SAP table. This procedure works by taking advantage of the Enhanced IGRP reliable transport mechanism, which means that an Enhanced IGRP peer must be present for incremental SAPs to be sent. If no peer exists on a particular interface, periodic SAPs will be sent on that interface until a peer is found. This functionality is automatic on serial interfaces and can be configured on LAN media.

LAN Support

Cisco IOS software supports routing IPX between Ethernet-emulated LANs and Token Ring-emulated LANs. For more information on emulated LANs and routing IPX between them, refer to the "Configuring LAN Emulation" chapter of the Cisco IOS Switching Services Configuration Guide.

VLAN Support

Cisco IOS software supports routing IPX between VLANs. Users with Novell NetWare environments can configure any one of the four IPX Ethernet encapsulations to be routed using ISL encapsulation across VLAN boundaries. For more information on VLANs and routing IPX between them over ISL, refer to the "Configuring Routing Between VLANs with ISL Encapsulation" chapter of the Cisco IOS Switching Services Configuration Guide.

Multilayer Switching Support

Cisco IOS software supports IPX Multilayer Switching (MLS). For more information on IPX MLS, refer to the "Multilayer Switching" chapter of the Cisco IOS Switching Services Configuration Guide.

IPX Configuration

For details on how to configure IPX protocol, refer to the following documentation, available online at Cisco.com:

Cisco IOS AppleTalk and Novell IPX Configuration Guide, Release 12.2

Cisco IOS AppleTalk and Novell IPX Command Reference, Release 12.2

IBM SNA

Adopting a TCP/IP infrastructure is the first logical step to creating a multiservice network that seamlessly accommodates data, voice, and video.

Enterprise organizations are heavily invested in mainframes and Systems Network Architecture (SNA) and mainframes are still a vital part of enterprise data centers. The goal for these enterprise organizations is to integrate the TCP/IP-based environment with the SNA-based environment. Cisco bridging and IBM networking technologies enable the delivery of SNA data over routers supporting TCP/IP.

The Cisco Four-Phase Model for SNA-to-IP Integration

Cisco has developed a high-level, four-phase model illustrating a typical integration path to incorporate TCP/IP into an SNA-based network. Figure 12-1 illustrates the four-phase integration path. The model helps to describe some common phases in SNA-to-IP integration. A single phase in this integration path might represent the network of some organizations, while two or more phases might represent the network implementation of other organizations in various sectors of their network.

The phases can be differentiated by the protocol that runs in each of three key elements in the network: the mainframe/midrange computer, the network backbone, and the desktop. This section describes the characteristics of each of the phases along with the problems solved, types of products and technologies implemented, and challenges.

Phase One: SNA Centric

An SNA-centric network has SNA, Advanced Peer-to-Peer Networking (APPN), or APPN/High Performance Routing (HPR), protocols running on one or more mainframe/midrange systems.

An SNA-centric network is a very high-speed and dynamic network when compared to the traditional SNA network of the past. ACF/VTAM on the mainframe includes APPN/HPR protocols to support dynamic rerouting around failures and high-speed switching in the network. The mainframe complex, which now comprises multiple complementary metal-oxide semiconductor (CMOS) processors, implements Parallel Sysplex to provide the ultimate in redundancy and session persistence.

The FEP has often been replaced by a high-performance, channel-connected router such as the Channel Interface Processor (CIP) or the Channel Port Adapter (CPA). The network backbone comprises high-speed switches (ATM, Ethernet/Fast Ethernet/Gigabit Ethernet, or Token Ring) and routers running APPN/HPR. Shared Token Ring LANs are being replaced with Token Ring or Ethernet switching to the desktop, offering a dedicated LAN segment and bandwidth to each end user.

Most desktops have PCs running advanced SNA client emulation software such as TN3270 Server. Routers provide support, via features such as Dependent Logical Unit Requester (DLUR) and downstream physical unit (DSPU) concentration, to transport the traffic from the remaining traditional SNA terminals and controllers.

Phase Two: IP Transport

Beginning in the 1980s, large organizations began building TCP/IP-based networks to support client/server applications and systems. UNIX, a dominant operating system for client/server applications, natively supports TCP/IP. As the growth of TCP/IP-based systems continued, organizations often found that they had built parallel networks, one running SNA and one running TCP/IP. This setup is expensive because of the duplication of line costs, equipment, and personnel. To eliminate the duplication, organizations had a choice—run the TCP/IP traffic over the SNA backbone, or run the SNA traffic over the TCP/IP backbone.

Running TCP/IP over an SNA backbone was not a feasible choice because of the lack of redundancy and openness of SNA. Routers, which formed the core of the TCP/IP network, began to support the encapsulation of SNA in TCP/IP for transport across the TCP/IP network.

This encapsulation brings many benefits. First and foremost, while it is encapsulated in TCP/IP, the SNA traffic is dynamically routed around network failures, a benefit that only recently has been added to SNA networks with APPN/HPR. The encapsulation schemes also provide more flexible configurations for SNA devices and reduced polling traffic across the backbone. Cisco offered the first such encapsulation scheme with RSRB. Since then, the industry has adopted a standard, data-link switching (DLSw), that has been very widely accepted and implemented. Routers also provide features such as serial tunnel (STUN) and Block Serial Tunneling (BSTUN) to encapsulate other types of traffic (asynchronous, bisynchronous, and some proprietary protocols) in addition to SNA.

In this second phase of integration, many organizations find that the same end users who are running advanced SNA client emulators to access mainframe and midrange systems are also accessing TCP/IP systems. This means that each PC must run two different protocol stacks—SNA and TCP/IP—for access to host systems.

Phase Three: IP Client

In the third phase of SNA-to-IP integration, organizations eliminated the dual protocol stacks at end-user PCs by implementing emulation software that supports TCP/IP. The same rich functionality that end users relied on in their emulation software remains the same, only it now runs over a TCP/IP stack.

Cisco Transaction Connection (CTRC) provides TCP/IP end-users and servers with direct access to Customer Information Control System (CICS) and IBM DB2 databases. Organizations achieve protocol independence between end-users and hosts, enabling applications to communicate directly to DB2 or CICS without upgrades.

TN3270(E), TN5250, Distributed Relational Database Architecture (DRDA) and Inter-System Communications (ISC) protocol are widely implemented and widely accepted standards for achieving TCP/IP-based access to mainframes and AS/400s. TN3270 Server technology on the router provides support for the TN3270(E) clients. CTRC on the router supports access to IBM DB2 databases from ODBC and JDBC drivers. CTRC also supports access to transaction programs managed by IBM's CICS. In addition to eliminating a second protocol from each desktop, organizations reap the following benefits by implementing low-cost, standards-based solutions such as TN3270(E), TN5250, and CTRC:

Availability of high-performance servers. Very high-capacity and high-performance gateway servers are available that offload the protocol processing of TN3270(E) or TN5250 from the mainframe or midrange host. These servers replace the low-capacity PC gateways that are based on proprietary gateway protocols.
Integration with corporate intranet. Because the desktop is based upon TCP/IP, all the advances taking place in corporate intranets can be brought to mainframe and midrange connections. For example, virtual private networks (VPNs) can be created for secure remote host access. Encryption and authentication can become a new level of security for host access.
Access from a browser. A whole new market, the Web-to-host market, is emerging that allows end users to access host systems using the browser as the standard interface. This setup brings enormous benefits by reducing the software distribution and administration chores for emulation software and this sets the stage for a new, browser-style interface to older applications. Organizations can look to these mission-critical applications to extend new services to their customers, as in the case of home banking, citizen access to government records, and insurance company applications.

Phase Four: IP Centric

In the fourth and final stage of SNA-to-IP integration, the mainframe and midrange systems natively support TCP/IP. They share files with and transfer data to other, non-SNA systems. Corporate databases are securely accessed in a standard way from a variety of different end-user applications. The remaining applications that are based on traditional "green-on-black," character-based terminals are accessed transparently through standard emulation screens or through intuitive, user-friendly Web pages.

TCP/IP-based mainframe and midrange systems offer advanced redundancy and high-availability features similar to those provided to SNA-based applications today. With the full, native support of TCP/IP, the mainframe and midrange systems can be fully participating members in the corporate intranet.

Summary of Four-Phase Model

The four-phase model of SNA-to-IP integration is based on Cisco experience helping to integrate some of the world's largest and most complex SNA networks. In reality, very few organizations go through a stepwise, linear migration from SNA centric to IP transport, to IP client, to IP centric.

For example, many large organizations have run TCP/IP stacks on their mainframes for years, alongside ACF/VTAM, whether they have implemented TCP/IP in the enterprise backbone network or not. Most large organizations will find elements from all four phases represented somewhere in their network. The model, however, is useful to describe the various issues of SNA-to-IP integration, their common solutions, and the characteristics of the network at various points in the change.

Scenarios for SNA-to-IP Integration

There are common elements or scenarios for integrating TCP/IP with SNA networks. This section describes three elements or scenarios, the corresponding phase from the Cisco four-phase integration model, and the Cisco products and software features deployed in these scenarios. This section discusses the following scenarios:

Line Consolidation

Line consolidation involves simplifying the network by providing a single network infrastructure, based on TCP/IP. This structure accommodates SNA and other traffic and allows the elimination of multiple single-protocol lines to each location.

Phase two of SNA-to-IP integration dictates the building of a single network backbone based upon TCP/IP. This setup often allows organizations to consolidate the number of communication lines in the network which simplifies the support and maintenance.

The primary product in a line consolidation project is a multiprotocol router that encapsulates and converts the traffic from the SNA lines. RSRB and DLSw+ are the Cisco IOS technologies used for this conversion. In addition, Cisco routers also support the tunneling of both bisynchronous and certain asynchronous protocols with Cisco IOS features such as STUN and BSTUN and the Airline Product Set (ALPS).

FEP Replacement

FEP replacement involves replacing FEPs (and possibly other special-purpose mainframe channel-attached equipment) with new channel-attached routers that offer high throughput, low costs, and flexible software functionality.

Throughout all phases of the SNA-to-IP integration, high-capacity throughput to the mainframe is a key requirement. Organizations are replacing FEPs with routers with direct channel attachments.

The primary product in a FEP replacement project is a channel-attached router. This router contains the mainframe channel connection hardware supporting either a bus-and-tag or ESCON interface (or multiple interfaces). It also runs the necessary channel protocol software and, in some cases, special software designed to offload communication processing from the mainframe. For example, the Cisco CIP and CPA both support TCP Offload, TCP Assist, CTRC, and TN3270 Server features to offload mainframe cycles.

Desktop Consolidation

In a desktop consolidation, desktops running multiple protocol stacks are simplified to utilize TCP/IP for access to all resources, including mainframes and AS/400s. This consolidation can be accomplished using traditional emulators that utilize TCP/IP instead of SNA for host communication, or it can be accomplished by leveraging new browser-based access approaches.

Phases three and four of the SNA-to-IP integration require end users to access host systems using TCP/IP.

The primary products in a desktop consolidation project are desktop devices, desktop software, and new gateway servers. Other products that may be considered for deployment are additional load-balancing domain name servers, firewalls, and other security devices.

Terminal emulation is, by definition, a client/server implementation. That is, PCs running terminal emulation software communicate with gateway software using either a proprietary or a standard protocol that is at a higher level than the TCP/IP transport. These gateways then communicate directly with the host applications using standard SNA protocols.

Most terminal emulators offer multiple choices of gateway connectivity. The only standard TCP/IP-based protocols for communication to mainframe and midrange systems are TN3270(E) and TN5250, respectively. Many organizations are implementing TN3270 and TN5250 because they are standards and they set the stage for Web-to-host solutions.

SNA Configuration

For details on how to configure SNA protocol, refer to the following documentation:

Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.2

Cisco IOS Bridging and IBM Networking Command Reference, Volume 1, Release 12.2

Cisco IOS Bridging and IBM Networking Command Reference, Volume 2, Release 12.2

Table of Contents