Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 3 - Network Protocols Overview [Cisco IOS Software Releases 12.0 Mainline]

Table Of Contents

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

Apollo Domain

Banyan VINES

DECnet

ISO CLNS

XNS

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

The Cisco IOS software supports a variety of network protocols, from popular protocols such as Internet Protocol (IP) to less frequently used protocols such as Apollo Domain and XNS.

The Network Protocols Configuration Guide, Part 3 and Network Protocols Command Reference, Part 3 describe the following network protocols:

•Apollo Domain

•Banyan VINES

•DECNet

•ISO CLNS

•XNS

This overview chapter provides a high-level description of these technologies. For configuration information, refer to the appropriate chapter in this module.

The Network Protocols Configuration Guide, Part 2 discusses the following network protocols:

•AppleTalk

•Novell IPX

The Network Protocols Configuration Guide, Part 1 discusses the following network protocols:

•IP

•IP Routing

Note   Not all Cisco access servers support the protocols described in this publication. For a model-by-model list of supported protocols, refer to the release notes for the current Cisco IOS release.

Apollo Domain

The Cisco IOS software implementation supports packet forwarding and routing for the Apollo Domain network protocols on Ethernet, Fiber Distributed Data Interface (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). This is necessary because Domain ARP (sometimes called D-ARP) uses the same Ethernet-type value as IP ARP.

•The Cisco implementation of Apollo Domain routing assumes that ARP can be used to locate workstations on the local cable. The following workstations and versions of the Apollo operating system support Domain ARP:

•DN3000 and DN3010 nodes need Version 9.7.4.1, which is available from local Apollo field offices on patch tape 186.

•DN3500, 4000, and 4500 nodes need Version 9.7.5.1, which is available from local Apollo field offices on patch tape 185.

•Version 9.7, which provides ARP for DN5xx-T nodes, needs Version 9.7.4.b101. No patch is available for these workstations. The software is provided only on a DECnet tape.

Note   Release10.0 of the Apollo Domain operating system does not provide ARP. You must migrate to Release10.1 and later versions before you can operate with Cisco routers. Cisco routers support neither the rtchk and lcnode commands nor Domain ARP in Apollo's 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. Cisco's implementation of VINES has been designed in conjunction with Banyan.

Cisco's 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. Cisco's implementation also offers address resolution to respond to address requests and broadcast address propagation. Echo support at the Media Access Control (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, Point-to-Point Protocol (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. DECnet's most recent product release 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 Cisco's support:

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

•The 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 a single vendor's equipment 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.

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

•The 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 Cisco's implementation of DECnet are a subset of the parameters you can modify in Digital's 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. Cisco's 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.

•Cisco's implementation differs from Digital's in the following ways:

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

•Cisco's implementation delays converting packets from Phase IV to Phase V, while Digital's implementation converts as soon as possible.

ISO CLNS

The 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.

Cisco's CLNS implementation also is compliant with the Government Open Systems Interconnection 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 Intra-domain Routing Exchange Protocol.

Both the ISO-developed IS-IS routing protocol and Cisco's 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 only ES-IS, but not IS-IS.

XNS

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, as well as over point-to-point serial lines running HDLC, LAPB, X.25, Frame Relay, or SMDS.

	Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 3
	Network Protocols Overview
Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 3 About the Cisco IOS Software Documentation Using the Cisco IOS Software Network Protocols Overview Configuring Apollo Domain Configuring Banyan VINES Configuring DECnet Configuring ISO CLNS Configuring XNS	Download this chapter Network Protocols Overview Table Of Contents Overview of Apollo Domain, Banyan VINES, DECNet, ISO CLNS, and XNS Apollo Domain Banyan VINES DECnet ISO CLNS XNS Overview of Apollo Domain, Banyan VINES, DECNet, ISO CLNS, and XNS The Cisco IOS software supports a variety of network protocols, from popular protocols such as Internet Protocol (IP) to less frequently used protocols such as Apollo Domain and XNS. The Network Protocols Configuration Guide, Part 3 and Network Protocols Command Reference, Part 3 describe the following network protocols: •Apollo Domain •Banyan VINES •DECNet •ISO CLNS •XNS This overview chapter provides a high-level description of these technologies. For configuration information, refer to the appropriate chapter in this module. The Network Protocols Configuration Guide, Part 2 discusses the following network protocols: •AppleTalk •Novell IPX The Network Protocols Configuration Guide, Part 1 discusses the following network protocols: •IP •IP Routing Note Not all Cisco access servers support the protocols described in this publication. For a model-by-model list of supported protocols, refer to the release notes for the current Cisco IOS release. Apollo Domain The Cisco IOS software implementation supports packet forwarding and routing for the Apollo Domain network protocols on Ethernet, Fiber Distributed Data Interface (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). This is necessary because Domain ARP (sometimes called D-ARP) uses the same Ethernet-type value as IP ARP. •The Cisco implementation of Apollo Domain routing assumes that ARP can be used to locate workstations on the local cable. The following workstations and versions of the Apollo operating system support Domain ARP: •DN3000 and DN3010 nodes need Version 9.7.4.1, which is available from local Apollo field offices on patch tape 186. •DN3500, 4000, and 4500 nodes need Version 9.7.5.1, which is available from local Apollo field offices on patch tape 185. •Version 9.7, which provides ARP for DN5xx-T nodes, needs Version 9.7.4.b101. No patch is available for these workstations. The software is provided only on a DECnet tape. Note Release10.0 of the Apollo Domain operating system does not provide ARP. You must migrate to Release10.1 and later versions before you can operate with Cisco routers. Cisco routers support neither the rtchk and lcnode commands nor Domain ARP in Apollo's 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. Cisco's implementation of VINES has been designed in conjunction with Banyan. Cisco's 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. Cisco's implementation also offers address resolution to respond to address requests and broadcast address propagation. Echo support at the Media Access Control (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, Point-to-Point Protocol (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. DECnet's most recent product release 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 Cisco's support: •Cisco routers interoperate with Digital routers, and Digital hosts do not differentiate between a Cisco router and a Digital router. •The 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 a single vendor's equipment 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. •The Cisco IOS software gives you additional security options through access lists. •The 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 Cisco's implementation of DECnet are a subset of the parameters you can modify in Digital's 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. Cisco's 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. •Cisco's implementation differs from Digital's in the following ways: •You can add Phase V support without modifying your existing Phase IV support. •Cisco's implementation delays converting packets from Phase IV to Phase V, while Digital's implementation converts as soon as possible. ISO CLNS The 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. Cisco's CLNS implementation also is compliant with the Government Open Systems Interconnection 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 Intra-domain Routing Exchange Protocol. Both the ISO-developed IS-IS routing protocol and Cisco's 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 only ES-IS, but not IS-IS. XNS 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, as well as over point-to-point serial lines running HDLC, LAPB, X.25, Frame Relay, or SMDS.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks