Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide, Release 12.2 - Overview of Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS [Cisco IOS Software Releases 12.2 Mainline]

Table Of Contents

Apollo Domain, Banyan VINES, DECNet, ISO CLNS, and XNS Overview

Apollo Domain

Banyan VINES

DECnet

ISO CLNS

XNS

Apollo Domain, Banyan VINES, DECNet, ISO CLNS, and XNS Overview

Note The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set.

Cisco IOS software supports a variety of network protocols. The Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide discusses the following network protocols:

•Apollo Domain

•Banyan VINES

•DECNet

•ISO CLNS

•XNS

The Cisco IOS AppleTalk and Novell IPX Configuration Guide discusses the following network protocols:

•AppleTalk

•Novell IPX

The Cisco IOS IP Configuration Guide discusses the following network protocols:

•IP

•IP Routing

This overview chapter provides a high-level description of Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS. For configuration information, see the appropriate chapter in this publication.

Apollo Domain

Note The Apollo Domain networking protocol will no longer be offered after Cisco IOS Release 12.2. Information about this protocol will not appear in future releases of the Cisco IOS software documentation set.

Cisco IOS software supports packet forwarding and routing for the Apollo Domain network protocols on Ethernet, FDDI, and serial interfaces using High-Level Data Link Control (HDLC) or X.25 encapsulation. The software implementation does not support direct attachment to the 12-MB Domain Token Ring. The following restrictions apply to the Cisco implementation of Apollo Domain:

•When both bridging and Apollo Domain routing are enabled on an Ethernet network, you must specify an Ethernet type code access list that filters out datagrams with the Apollo Domain-type code (hexadecimal 8019). This restriction applies to MCI cards running microcode Version 1.5 or earlier.

•You must set IP addresses on all networks that use the IP Address Resolution Protocol (ARP) (for example, Ethernet and FDDI). Setting the IP addresses is necessary because Domain ARP (sometimes called D-ARP) uses the same Ethernet-type value as IP ARP.

Caution Apollo Domain routing is process switched and therefore may be routed slowly, causing an increase in CPU overhead. This increase in CPU overhead can negatively impact the performance of the routers that route Apollo Domain. Under most circumstances better router performance may be achieved by bridging Apollo Domain traffic.

Note Release 10.0 of the Apollo Domain operating system does not provide ARP. You must migrate to Release 10.1 and later versions before you can operate with Cisco routers. Cisco routers support neither the rtchk and lcnode commands nor Domain ARP in the Apollo 802.5 implementation.

Banyan VINES

The Banyan Virtual Network Service (VINES) protocol is a networking system for personal computers. This proprietary protocol was developed by Banyan Systems, Inc., and is derived from the Xerox Network System (XNS) protocol. The Cisco implementation of VINES has been designed in conjunction with Banyan.

The Cisco implementation of Banyan VINES provides routing of VINES packets on all media. Although the software automatically determines a metric value that it uses for routing updates based on the delay set for the interface, this software implementation allows you to customize the metric. The Cisco implementation also offers address resolution to respond to address requests and broadcast address propagation. Echo support at the MAC level is also available for Ethernet, IEEE 802.2, Token Ring, and FDDI media. Name-to-address mapping for VINES host names also is supported, as are access lists to filter packets to or from a specific network.

DECnet

Digital Equipment Corporation designed the DECnet stack of protocols in the 1970s as part of its Digital Network Architecture (DNA). DNA supports DECnet routing over Ethernet, Token Ring, FDDI, HDLC, PPP, Frame Relay, Switched Multimegabit Data Service (SMDS), X.25, and IEEE 802.2.

DECnet supports both connectionless and connection-oriented network layers implemented by Open System Interconnection (OSI) protocols. The most recent product release of DECnet is called Phase V, which is equivalent to International Organization for Standardization (ISO) Connectionless Network Service (CLNS). Phase V is compatible with the previous release, Phase IV. Phase IV was similar to OSI routing, but Phase V implements full OSI routing, including support for End System-to-Intermediate System (ES-IS) and Intermediate System-to-Intermediate System (IS-IS) connections. An end system (ES) is a nonrouting network node; an intermediate system (IS) refers to a router. ES-IS support allows ESs and ISs to discover each other. IS-IS provides routing between ISs only.

DECnet Phase IV Prime supports inherent MAC addresses, which allows DECnet nodes to coexist with systems running other protocols that have MAC address restrictions.

DECnet support on Cisco routers includes local-area and wide-area DECnet Phase IV routing over Ethernet, Token Ring, FDDI, and serial lines (X.25, Frame Relay, SMDS). The following are the specifics of the Cisco support:

•Cisco routers interoperate with Digital routers, and Digital hosts do not differentiate between a Cisco router and a Digital router.

•Cisco IOS software uses HDLC framing rather than Digital Data Communications Message Protocol (DDCMP) framing for point-to-point lines.

•If you construct a network using both Cisco and Digital equipment, you must ensure that each point-to-point line has the same type of equipment on both ends.

•Cisco and DECnet Phase IV routers have incompatible X.25 support.

•As with point-to-point lines, you must use equipment from a single vendor on the X.25 portion of your network.

•You can configure your Cisco router running software Release 9.1 or later to interoperate with Digital equipment, or you can configure your Cisco router to operate with other Cisco routers that use prior versions Cisco IOS software.

•Cisco IOS software gives you additional security options through access lists.

•Cisco IOS software supports the address translation gateway (ATG), which allows the router to participate in multiple, independent DECnet networks. In case of duplicate addressing, ATG establishes a user-specified address translation table for selected nodes between networks.

•Digital uses some nonroutable protocols that are not part of the DECnet stack. For example, neither Cisco nor Digital routers can route the Maintenance Operation Protocol (MOP) and local-area transport (LAT); instead, these protocols must be bridged.

•The parameters in the Cisco implementation of DECnet are a subset of the parameters you can modify in the Digital Network Control Program (NCP). Cisco uses the same names, the same range of allowable values, and the same defaults wherever possible. You must use the configuration commands to set DECnet parameters. The Cisco DECnet implementation does not set parameters by communicating with NCP.

•Cisco supports DECnet Phase IV-to-Phase V conversion:

–Cost information is represented in native mode for the Phase IV or Phase V protocols.

–Digital has defined algorithms for mapping a subset of the Phase V address space onto the Phase IV address space, and for converting Phase IV and Phase V packets back and forth to support Phase IV hosts in Phase V networks, and vice versa.

•The Cisco implementation and Digital implementation differ in the following ways:

–You can add Phase V support without modifying your existing Phase IV support.

–The Cisco implementation delays converting packets from Phase IV to Phase V; while the Digital implementation converts as soon as possible.

ISO CLNS

Cisco IOS software supports packet forwarding and routing for ISO CLNS on networks using a variety of data link layers: Ethernet, Token Ring, FDDI, and serial.

You can use CLNS routing on serial interfaces with HDLC, PPP, Link Access Procedure, Balanced (LAPB), X.25, SMDS, or Frame Relay encapsulation. To use HDLC encapsulation, you must have a router at both ends of the link. If you use X.25 encapsulation, you must manually enter the network service access point (NSAP)-to-X.121 mapping. The LAPB, X.25, Frame Relay, and SMDS encapsulations interoperate with other vendors.

The Cisco CLNS implementation also is compliant with the Government OSI Profile (GOSIP) Version 2.

As part of its CLNS support, Cisco routers fully support the following ISO and American National Standards Institute (ANSI) standard:

•ISO 9542—Documents the ES-IS routing exchange protocol.

•ISO 8473—Documents the ISO Connectionless Network Protocol (CLNP).

•ISO 8348/Ad2—Documents NSAP addresses.

•ISO 10589—Documents IS-IS Intradomain Routing Exchange Protocol.

Both the ISO-developed IS-IS routing protocol and the Cisco ISO Interior Gateway Routing Protocol (IGRP) are supported for dynamic routing of ISO CLNS. In addition, static routing for ISO CLNS is supported.

Note Cisco access servers currently support ES-IS routing protocol and not IS-IS routing protocol.

XNS

Note The XNS networking protocol will no longer be offered after Cisco IOS Release 12.2. Information about this protocol will not appear in future releases of the Cisco IOS software documentation set.

The XNS protocols, which were developed by the Xerox Corporation, are designed to be used across a variety of communication media, processors, and office applications. Ungermann-Bass, Inc. (now a part of Tandem Computers) adopted XNS in developing its Net/One XNS routing protocol. Standard XNS routing uses the Routing Information Protocol (RIP) update packets and the hop count metric. Ungermann-Bass Net/One uses hello packets and a path-delay metric.

Cisco provides a subset of the XNS protocol stack to support XNS routing. XNS traffic can be routed over Ethernet, FDDI, and Token Ring LANs, and over point-to-point serial lines running HDLC, LAPB, X.25, Frame Relay, or SMDS.

	Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide, Release 12.2
	Overview of Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS
Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide, Release 12.2 About the Cisco IOS Software Documentation Using Cisco IOS Software Overview of Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuring Apollo Domain Configuring Banyan VINES Configuring DECnet Configuring ISO CLNS Configuring XNS	Download this chapter Overview of Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Table Of Contents Apollo Domain, Banyan VINES, DECNet, ISO CLNS, and XNS Overview Apollo Domain Banyan VINES DECnet ISO CLNS XNS Apollo Domain, Banyan VINES, DECNet, ISO CLNS, and XNS Overview Note The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set. Cisco IOS software supports a variety of network protocols. The Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide discusses the following network protocols: •Apollo Domain •Banyan VINES •DECNet •ISO CLNS •XNS The Cisco IOS AppleTalk and Novell IPX Configuration Guide discusses the following network protocols: •AppleTalk •Novell IPX The Cisco IOS IP Configuration Guide discusses the following network protocols: •IP •IP Routing This overview chapter provides a high-level description of Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS. For configuration information, see the appropriate chapter in this publication. Apollo Domain Note The Apollo Domain networking protocol will no longer be offered after Cisco IOS Release 12.2. Information about this protocol will not appear in future releases of the Cisco IOS software documentation set. Cisco IOS software supports packet forwarding and routing for the Apollo Domain network protocols on Ethernet, FDDI, and serial interfaces using High-Level Data Link Control (HDLC) or X.25 encapsulation. The software implementation does not support direct attachment to the 12-MB Domain Token Ring. The following restrictions apply to the Cisco implementation of Apollo Domain: •When both bridging and Apollo Domain routing are enabled on an Ethernet network, you must specify an Ethernet type code access list that filters out datagrams with the Apollo Domain-type code (hexadecimal 8019). This restriction applies to MCI cards running microcode Version 1.5 or earlier. •You must set IP addresses on all networks that use the IP Address Resolution Protocol (ARP) (for example, Ethernet and FDDI). Setting the IP addresses is necessary because Domain ARP (sometimes called D-ARP) uses the same Ethernet-type value as IP ARP. Caution Apollo Domain routing is process switched and therefore may be routed slowly, causing an increase in CPU overhead. This increase in CPU overhead can negatively impact the performance of the routers that route Apollo Domain. Under most circumstances better router performance may be achieved by bridging Apollo Domain traffic. Note Release 10.0 of the Apollo Domain operating system does not provide ARP. You must migrate to Release 10.1 and later versions before you can operate with Cisco routers. Cisco routers support neither the rtchk and lcnode commands nor Domain ARP in the Apollo 802.5 implementation. Banyan VINES The Banyan Virtual Network Service (VINES) protocol is a networking system for personal computers. This proprietary protocol was developed by Banyan Systems, Inc., and is derived from the Xerox Network System (XNS) protocol. The Cisco implementation of VINES has been designed in conjunction with Banyan. The Cisco implementation of Banyan VINES provides routing of VINES packets on all media. Although the software automatically determines a metric value that it uses for routing updates based on the delay set for the interface, this software implementation allows you to customize the metric. The Cisco implementation also offers address resolution to respond to address requests and broadcast address propagation. Echo support at the MAC level is also available for Ethernet, IEEE 802.2, Token Ring, and FDDI media. Name-to-address mapping for VINES host names also is supported, as are access lists to filter packets to or from a specific network. DECnet Digital Equipment Corporation designed the DECnet stack of protocols in the 1970s as part of its Digital Network Architecture (DNA). DNA supports DECnet routing over Ethernet, Token Ring, FDDI, HDLC, PPP, Frame Relay, Switched Multimegabit Data Service (SMDS), X.25, and IEEE 802.2. DECnet supports both connectionless and connection-oriented network layers implemented by Open System Interconnection (OSI) protocols. The most recent product release of DECnet is called Phase V, which is equivalent to International Organization for Standardization (ISO) Connectionless Network Service (CLNS). Phase V is compatible with the previous release, Phase IV. Phase IV was similar to OSI routing, but Phase V implements full OSI routing, including support for End System-to-Intermediate System (ES-IS) and Intermediate System-to-Intermediate System (IS-IS) connections. An end system (ES) is a nonrouting network node; an intermediate system (IS) refers to a router. ES-IS support allows ESs and ISs to discover each other. IS-IS provides routing between ISs only. DECnet Phase IV Prime supports inherent MAC addresses, which allows DECnet nodes to coexist with systems running other protocols that have MAC address restrictions. DECnet support on Cisco routers includes local-area and wide-area DECnet Phase IV routing over Ethernet, Token Ring, FDDI, and serial lines (X.25, Frame Relay, SMDS). The following are the specifics of the Cisco support: •Cisco routers interoperate with Digital routers, and Digital hosts do not differentiate between a Cisco router and a Digital router. •Cisco IOS software uses HDLC framing rather than Digital Data Communications Message Protocol (DDCMP) framing for point-to-point lines. •If you construct a network using both Cisco and Digital equipment, you must ensure that each point-to-point line has the same type of equipment on both ends. •Cisco and DECnet Phase IV routers have incompatible X.25 support. •As with point-to-point lines, you must use equipment from a single vendor on the X.25 portion of your network. •You can configure your Cisco router running software Release 9.1 or later to interoperate with Digital equipment, or you can configure your Cisco router to operate with other Cisco routers that use prior versions Cisco IOS software. •Cisco IOS software gives you additional security options through access lists. •Cisco IOS software supports the address translation gateway (ATG), which allows the router to participate in multiple, independent DECnet networks. In case of duplicate addressing, ATG establishes a user-specified address translation table for selected nodes between networks. •Digital uses some nonroutable protocols that are not part of the DECnet stack. For example, neither Cisco nor Digital routers can route the Maintenance Operation Protocol (MOP) and local-area transport (LAT); instead, these protocols must be bridged. •The parameters in the Cisco implementation of DECnet are a subset of the parameters you can modify in the Digital Network Control Program (NCP). Cisco uses the same names, the same range of allowable values, and the same defaults wherever possible. You must use the configuration commands to set DECnet parameters. The Cisco DECnet implementation does not set parameters by communicating with NCP. •Cisco supports DECnet Phase IV-to-Phase V conversion: –Cost information is represented in native mode for the Phase IV or Phase V protocols. –Digital has defined algorithms for mapping a subset of the Phase V address space onto the Phase IV address space, and for converting Phase IV and Phase V packets back and forth to support Phase IV hosts in Phase V networks, and vice versa. •The Cisco implementation and Digital implementation differ in the following ways: –You can add Phase V support without modifying your existing Phase IV support. –The Cisco implementation delays converting packets from Phase IV to Phase V; while the Digital implementation converts as soon as possible. ISO CLNS Cisco IOS software supports packet forwarding and routing for ISO CLNS on networks using a variety of data link layers: Ethernet, Token Ring, FDDI, and serial. You can use CLNS routing on serial interfaces with HDLC, PPP, Link Access Procedure, Balanced (LAPB), X.25, SMDS, or Frame Relay encapsulation. To use HDLC encapsulation, you must have a router at both ends of the link. If you use X.25 encapsulation, you must manually enter the network service access point (NSAP)-to-X.121 mapping. The LAPB, X.25, Frame Relay, and SMDS encapsulations interoperate with other vendors. The Cisco CLNS implementation also is compliant with the Government OSI Profile (GOSIP) Version 2. As part of its CLNS support, Cisco routers fully support the following ISO and American National Standards Institute (ANSI) standard: •ISO 9542—Documents the ES-IS routing exchange protocol. •ISO 8473—Documents the ISO Connectionless Network Protocol (CLNP). •ISO 8348/Ad2—Documents NSAP addresses. •ISO 10589—Documents IS-IS Intradomain Routing Exchange Protocol. Both the ISO-developed IS-IS routing protocol and the Cisco ISO Interior Gateway Routing Protocol (IGRP) are supported for dynamic routing of ISO CLNS. In addition, static routing for ISO CLNS is supported. Note Cisco access servers currently support ES-IS routing protocol and not IS-IS routing protocol. XNS Note The XNS networking protocol will no longer be offered after Cisco IOS Release 12.2. Information about this protocol will not appear in future releases of the Cisco IOS software documentation set. The XNS protocols, which were developed by the Xerox Corporation, are designed to be used across a variety of communication media, processors, and office applications. Ungermann-Bass, Inc. (now a part of Tandem Computers) adopted XNS in developing its Net/One XNS routing protocol. Standard XNS routing uses the Routing Information Protocol (RIP) update packets and the hop count metric. Ungermann-Bass Net/One uses hello packets and a path-delay metric. Cisco provides a subset of the XNS protocol stack to support XNS routing. XNS traffic can be routed over Ethernet, FDDI, and Token Ring LANs, and over point-to-point serial lines running HDLC, LAPB, X.25, Frame Relay, or SMDS.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.