cc/td/doc/product/software/ios11
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring APPN

Configuring APPN

Many enterprises today maintain two networks: a traditional, hierarchical SNA Subarea network and an interconnected LAN network, based on connectionless, dynamic protocols. The advantage of the subarea SNA network is that it is manageable, deterministic, and provides guaranteed response time. The disadvantages are that it requires extensive system definition and does not take advantage of the capabilities of intelligent devices.

Cisco has for many years provided remote source-route bridging (RSRB) and, recently, data link switching plus (DLSw+), which provide encapsulation of SNA traffic and allow consolidation of SNA with multiprotocol networks. APPN now gives the additional flexibility to route SNA natively, without encapsulation. Use APPN can by itself or in combination with RSRB and DLSw+ to provide the best solution for your networking needs.

Cisco's Implementation of APPN

APPN is the second generation of SNA. APPN provides support for client/server applications and offers more dynamics than traditional hierarchical SNA, such as dynamic directory and routing services.

Cisco's APPN implementation includes the following features:

APPN Overview

This section describes some of the components of an APPN network, and reviews some basic SNA terminology. The section identifies and compares node types and compares APPN with subarea SNA.

SNA Terminology

The basic component of an SNA network, subarea or APPN, is the network accessible unit (NAU). A NAU is assigned an 8 character name and an 8 character network identifier which are used to uniquely identify the unit. Examples of NAUs are Logical Units, Physical Units, Control Points and System Services Control Points.

Logical Unit (LU)

An LU is an interface that enables end users to gain access to network resources and communicate with each other. Examples of LUs are printers, terminals, and applications. LUs communicate with each other via LU-LU sessions. The LU-LU session is the basis of meaningful communication in SNA; all end user data traffic communicates through this session type.

A Dependent LU (DLU) requires the services of a VTAM host acting as System Services Control Point (SSCP) to participate in an SNA network. The SSCP must establish connections with each dependent LU before it is able to participate in the network. Dependent LUs, such as 3270 terminals, are only capable of maintaining a single LU-LU session at any one time.

An Independent LU (ILU) does not require the services of an SSCP to participate in an SNA network. In addition, an ILU can establish sessions to more than one partner in the network, and can have multiple parallel sessions with the same partner LU. Applications implementing Advanced Program to Program Communications (APPC) are examples of independent LUs.

Physical Unit (PU)

SNA defines a PU as the representation of the physical device. It is the component that manages and monitors the resources (such as attached links and adjacent link stations) associated with an SNA node.

Physical Unit Type 2 (PU2), the legacy physical unit, can only support dependent LUs and requires the services from a VTAM host to perform network functions.

Physical Unit Type 2.1 (PU2.1), also known as a type 2.1 node, offers peer node capabilities in an SNA environment. A PU2.1 can support both dependent and independent LUs. In addition, a PU2.1 can support a control point, which is central to APPN networking.

APPN extends the PU T2.1 architecture to provide dynamic discovery and definition of resources and routing capabilities for larger, complex networks.

Control Point (CP)

A CP identifies the networking components of a PU Type 2.1 node. In APPN, CPs are able to communicate with logically adjacent CPs by way of CP-CP sessions. Almost all APPN functions, including searches for network resources and discovery of network topology, use CP-CP sessions as the means of communication between nodes.

APPN Node Types

In an APPN network, different node types are used to distinguish different levels of networking capabilities. This section describes APPN node types.

Low Entry Networking (LEN) Node

A LEN node, sometimes called a LEN end node, is a PU 2.1 without APPN enhancements. The following are some of the characteristics of a LEN node:

A LEN node predates APPN but is able to interoperate with an APPN network. Because there is no CP-CP session between a LEN node and its network node, resources at the LEN node must be defined at the NN, reducing dynamic resource discovery capabilities.

End Node (EN)

An EN is a PU2.1 that includes the APPN support necessary to gain full access to an APPN network. However, an EN is not capable of performing in an intermediate role when routing APPN sessions. The following are the characteristics of an EN:

Because an EN lacks full APPN routing capability, it might be thought of as an application host or point of user access. The EN establishes CP-CP sessions with its NN server, so topology and directory information can be exchanged dynamically, eliminating the need to define resources on the NN. The EN may connect to multiple network nodes and LU-LU sessions may be established through any of the connected network nodes, although only one network node may be its network node server at any one time.

Network Node (NN)

An NN implements the APPN extensions to the PU2.1 architecture that allow it to provide intermediate routing services to LEN nodes and ENs.

An NN contains a Control Point to manage:

An NN provides the following network services:

An NN may be a session end point or an intermediate system.

A Network Node Server is a network node providing resource location and route selection services for the LEN nodes, ENs and LUs it serves. The nodes served (ENs or LEN nodes) are defined as being in the network node server's domain.

APPN Concepts

This section describes the basic concepts of APPN and how they interact to provide APPN networking functions.

APPN Connections

The Configuration Services (CS) component of an APPN node manages local interfaces and connections to the APPN network. CS controls the ports and link stations on the node. A port defines a connection to a transport media accessible to APPN, while a link station identifies the addressing information and characteristics of a connection with another node.

An APPN Network: Connection Phase

When two APPN nodes connect, the following activities occur:

The entire connection phase may be configured to occur automatically, or may be triggered manually via EXEC commands.

A link is defined as both the link stations within the 2 nodes it connects and the link connection between the nodes. A link station is the hardware or software within a node that enables the node to attach to, and provide control over, a link connection. A link connection is the physical medium over which data is transmitted. A transmission group, in legacy SNA, may consist of one or more links between 2 nodes. However, in the APPN architecture, transmission groups are limited to a single link. It is therefore common in APPN to use the terms link and transmission groups interchangeably.

Details of Link Activation

The connection phase in APPN begins with link activation which allows initial establishment of communication between nodes. It is dependent of the data link control (DLC) chosen and may not be required for some DLC types. For switched connections, one may think of "dial" and "answer" procedures. In an X.25 network this would be the establishment of a virtual circuit. Once the connect phase has completed, the 2 nodes are able to exchange and establish node characteristics via XID exchanges.

The exchange of XIDs allows a node to determine if the adjacent station is active and to verify the identity of the adjacent node. Node identification fields, including the CP name, will be exchanged. This information exchange allows, for example, a node to correlate an incoming connection with a link station definition on the node.

During XID3 exchange, it is determined which link station shall become primary and which is secondary on the link. The 2 link stations compare the XID3 values for node identifier (block number plus ID number). If the link-stations are defined to negotiable, then the higher node ID becomes primary. If the nodes have the same node ID, each generates a random number and the node with the higher random number becomes primary. The result of the primary-secondary role negotiation determines which node will send the mode-setting command---Set Normal Response Mode (SNRM) for SDLC, Set Asynchronous Balanced mode (SABM) for X.25, and so on.

After the link activation XID exchange has completed successfully, CS creates a new path control instance and instructs the Address Space Manager (ASM) to activate a new address space. Then CS notifies Topology and Routing Services (TRS) that a TG has become active so the APPN topology can be updated. Finally, if a CP-CP session is to be activated, CS notifies SS, who then activates the CP-CP session.

CP - CP Session Activation

After the link is established, the nodes will determine if CP-CP sessions should be established. Between network nodes, CP-CP sessions are normally activated on the first link to become active between the nodes. An EN is responsible for determining which of the network nodes to which it is attached will be used for a CP-CP session. It indicates its choice for network node server by sending BIND to the CP on the adjacent NN. The NN then indicates its acceptance by sending BIND for a second LU6.2 session, completing the CP-CP session pair. Each node uses one session to send CP-CP communication data, while the other is reserved for receiving data from the partner node.

CPSVCMG is the Class of Service (COS) used for CP-CP sessions. It indicates a transmission priority of network, the highest of the 4 transmission priorities in APPN.

When the CP-CP session is established, the CPs exchange capabilities, and in the case of EN to NN CP-CP sessions, registration of the local LUs is performed.

APPN Topology

APPN maintains a structure which represents a map of the APPN network as known to this node. Topology and Routing Service (TRS) is the APPN component responsible for maintaining the topology, which is often called the topology database.

There are two types of information in a topology database, local topology and network topology.

An EN uses the information in its local topology database to send local TG information to the network node server on APPN search requests and replies. The TG information is passed to the NN server when a route is requested, so the NN will be able to select the best TG from the EN to one of its adjacent NNs. In a NN, the local topology database includes information about the attached end nodes and TGs.

Figure 32-1 shows the local topology as it is known to EN A, NN2, and EN B.


Figure 32-1: APPN Local Topology


Network topology contains information on all network nodes in the APPN network as well as the TGs interconnecting them. Every NN maintains a fully replicated copy of the network topology database. Figure 32-2 illustrates an APPN network topology.


Figure 32-2: Network Topology


The network topology database is built from information about the local NN and its TGs to other NNs, and from Topology Database Updates (TDUs) received from adjacent NNs. TDUs are exchanged whenever NNs establish CP-CP sessions with each other. As updates occur in NNs or TGs between NNs, the owning NN sends a TDU to its adjacent NNs, which in turn propagates the TDU to its adjacent NNs until the network topology database is again replicated.

For each NN, certain properties are specified in the TDB. Each node and TG in a network topology database is assigned a unique resource sequence number (RSN). These are incremented to the next even value whenever the owning network node creates a Topology Database Update (TDU) for that resource. TG database entries include an indicator of whether CP-CP sessions are supported, TG weight, TG status (operative or inoperative), the TG number, partner node information and TG characteristics, such as cost per byte, cost per connect time, security level, etc.

TDUs provide updated information to NNs about the node itself and information about all locally owned TGs to other network nodes. TDUs can be triggered by changes in node or TG characteristics.

TRS broadcasts TDUs containing local node information every five days, to prevent other network nodes from discarding valid information, which occurs after 15 days with no update. This 15-day cleanup of the database is called garbage collection.

In Figure 32-3, NN3 adds itself to the network. NN3 forwards information about itself to NN1. NN1 forwards the information to NN2 and NN4. NN2 and NN4 then forward a second TDU to each other. Since it will have the same RSN and information, those TDUs will be discarded.


Figure 32-3: Topology Database Update: Adding a Node


In Figure 32-4, TG6 is activated between NN4 and NN3. TDUs are exchanged between the 2 nodes, so each can build a new topology database. New information is propagated to adjacent nodes once NN4 and NN3 have updated topology databases.


Figure 32-4: Topology Database Update: Adding a Transmission Group


TG6 could be active, but with no CP-CP session established. The TG will still be included in the network topology and forwarded, so that path can be used for sessions.

The APPN Directory and APPN Searches

Directory Services(DS) is the APPN component responsible for management of the directory database and searching for network resources throughout the APPN network. The Directory Database should not be confused with the Topology Database. The Directory Database maintains information about resource names and their owners, while the topology database maintains a network map of NNs and TGs. Directory Services is invoked to locate a session partner, and Topology Services is invoked to compute an optimal route to the session partner once it has been located.

Each APPN network resource must, at a minimum, be defined on the node where the resource exists. Once the resource is defined it can be found through network searches. Optionally, the resource location may be defined in other nodes to optimize Directory Services search logic.

Registered directory entries are created dynamically in the local directory of the NN. These represent local LUs of an adjacent EN, for which the NN is providing network node server function.

Cached directory entries are added dynamically, based on the results of previous searches. A cache entry allows the node to attempt a directed search straight to the destination resource. If a cache entry does not exist, or the entry is incorrect, a broadcast search will be issued to query each NN in the network for the destination resource. Each cache entry is verified before use to make sure the resource is still available. If the resource is not found, a broadcast search is attempted.

Some implementations, including Cisco's, support safe store of the directory cache. The cache entries in a network node's directory database are periodically written to a permanent storage medium, permitting faster access (after a network node failure or initial power-on) by eliminating network broadcast searches for safe-stored resources.

APPN Route Selection

Each APPN session is assigned a route on which the data path for this session will travel. APPN Topology and Routing Services is responsible for the computation of a route for an LU-LU session. A route is an ordered sequence of nodes and TGs that represents a path from an origin node to a destination node. TRS uses the topology database and its Class of Service (COS) definitions to obtain the necessary information necessary to perform a route computation.

While multiple routes may be available between an origin and a destination, the best route is selected (see Figure 32-5). Selection is made through use of the COS to identify the least-cost path that provides the desired level of service.

When a session is requested, Directory Services is responsible for locating the target resource, and TRS is responsible for selecting a route.


Figure 32-5: An APPN Network: Selecting the Best Path

When the origin LU requests a session, it specifies or defaults a mode to use for the session. Among other things, the mode is used to assign a COS to this session request. Acceptable COS characteristics are compared to node and TG characteristics as configured to select the best route.

A COS table entry specifies transmission priority, COS name and one or multiple rows of COS characteristics that are acceptable for that COS. Note that traffic on sessions with the same COS can only flow at the same transmission priority. You would need a separately named entry to achieve a different priority on the same route.

TG characteristics include link speed, cost per connect time, cost per byte, security class (7 levels), propagation delay (LAN the least, satellite the most), and 3 user-defined fields that are user assignable.

Node properties include route additional resistance (RAR) and a congestion indicator.

The COS table can contain multiple entries meeting the criteria, some more acceptable than others. The COS table allows the assignment of weight to each entry to differentiate the value of each entry. For each possible route, compare the characteristics of the component nodes and transmission groups to the ranges of acceptable characteristics as defined in the COS table for that COS. For each NN or TG the characteristics are compared to see if they're within the range of tolerance. If so, a weight is assigned to each node and each TG and is added to the total weight for that particular route.

When all routes are weighed, the one with the lowest weight is selected.Ties are broken by random selection.

Route selection is a complex process and, where multiple routes are available, may involve considerable overhead. To reduce this overhead, TRS uses routing trees to store the best route path to each node in the network for a specific COS. You may configure how many routing trees the node will maintain at any one time.

Connection networks

Connection networks provide extensions to the APPN route calculation algorithm to simplify definitions and enhance connectivity on shared transport media. By specifying a node is a member of a connection network, it may establish a direct connection, when needed, between itself and any other member of the connection network. For example, on one Token Ring, there may be 50 end nodes with links and CP-CP session active to the same network node. The end nodes may communicate with each other through the network node, but this data path, which routes data through the network node then back onto the same media to the target end node, is an inefficient use of both the network node and the transmission media. Alternatively, APPN links could be configured between each end node it a mesh fashion, but this would require over 1000 link definitions! Instead, each end node can be configured as a member of the same connection network. This allows APPN route calculation to calculate a route through the connection network between the two end nodes. The resulting data path is a direct connection between end nodes without requiring a corresponding link definition on either node.

APPN Intermediate Session Routing

After a route is selected, a BIND session command flows from the origin LU to the destination LU over the specified route. The BIND includes:

As the BIND passes through each NN, the NN records the inbound session identifier (local form session identifier or LFSID) carried in the BIND, and assigns a new session identifier to be used on the outbound port. It also builds a "session connector" that connects the inbound session identifier with the outbound session identifier, so that it knows how to forward subsequent packets on this session. The session connector also stores information carried in the BIND, such as segmentation values and transmission priority, so that other components, such as Path Control will be able to utilize the information on session traffic.

No subsequent data packets contain any routing information--they only contain the local form session identifier. Packets are forwarded based on information in session connectors, including port and outbound LFSID. LFSIDs are swapped at each NN since they have local significance only.

Dependent Logical Unit Requestor/Server

A Dependent LU (DLU) is an LU that depends on the System Services Control Point (SSCP) in VTAM to provide services for establishing sessions. Common DLU types are DLU 0, 1, 2, and 3.

Dependent LUs originated in subarea SNA. In early APPN environments, only LU6.2 independent LUs were supported. The PU supporting dependent LUs still required a logical link directly to a subarea network boundary function (VTAM or NCP) in order to operate. Dependent LU Requester provides the extensions to APPN necessary to allow dependent LUs to interoperate in an APPN network and removes the restriction that dependent LUs must have a direct connection to a subarea network boundary function.

Dependent LU Requester is the client half of Dependent LU Requester/Server. The Dependent LU Server (DLUS) is currently implemented in IBM's VTAM version 4.2.

There are three main concepts in DLUS/DLUR:

The DLUR function can reside on an EN or NN that actually owns the dependent LUs. In addition, as in the case for Cisco's implementation, the DLUR can exist in a network node which offers its DLUR services to PU type 2.0 and PU type 2.1 nodes which connect to the DLUR. This arrangement offers consolidation of the LU6.2 control sessions (only one pair is needed for all downstream PUs that the DLUR serves). In addition, it can provide considerable cost savings over upgrading each device that owns dependent LUs to be APPN and DLUR capable.

DLUR function does not have to be active in all APPN nodes---only those with DLUs directly attached. Once encapsulated in the LU6.2 session, the DLUR control traffic (encapsulated SSCP-PU and SSCP-LU control flows) looks like regular APPN traffic.

By providing DLUS support in VTAM, SSCP support is extended to LUs residing on nodes that are nonadjacent to the VTAM or NCP boundary function. Traditional SSCP-PU and SSCP-LU session flows are multiplexed in LU6.2 sessions between the DLUR and DLUS.

The benefits of using the DLUS/DLUR function include:

Configuring APPN

While the essential definitions for APPN are quite simple, APPN offers the ability to define attributes of the APPN network that can become quite complex. To easily manage the capability to define the details of APPN, special configuration command modes and conventions have been developed.

APPN Command Modes

Because APPN offers a large number of configuration options, specific configuration dialogues are used for each major APPN configuration task. When you define the major item, you will automatically enter the detailed configuration mode for that item. There are two options to exit the detailed mode. The "complete" command exits the detailed configuration mode and updates the APPN subsystem with the changes. The "exit" command leaves the definition in "no complete" state and does not update the APPN subsystem.

Completing APPN Definitions

No APPN definition is usable by the APPN subsystem until the definition is marked as complete. This is accomplished by entering the "complete" command when you have finished defining items in the detailed configuration mode.

Changing APPN Definitions

To update a major definition item which is already known to APPN, enter the major item definition as it was originally defined. Then, to indicate that you wish to modify an existing definition, enter "no complete". You will then be able to change the items in the detailed configuration mode for that major definition. Remember to enter "complete" when you have finished changing the configuration item to update the APPN subsystem with your changes.

APPN Configuration Task List

To configure APPN in your network, perform the tasks discussed in the following sections. Because of the hierarchical nature of APPN definitions, you should configure APPN by following the order specified below:

Definition of an APPN Control Point and at least one APPN port are required. In addition, you must start the APPN subsystem to activate APPN routing. The other tasks in this list are optional, and may or may not need to be configured depending on the APPN network configuration you have.

Define an APPN Control Point

An APPN control point definition is required to use APPN. This definition additives the fully-qualified control point name for the node, which is a combination of a network identifier and a CP name. The network identifier (NETID) must be the same as other network nodes in the APPN subnetwork attached to this node. The CP name identifies this node uniquely within the particular subnetwork.
Task Command

Define an APPN Control Point.

appn control-point netid.cpname

Performing this task takes you from global configuration mode into APPN CONTROL POINT mode. From this mode, you can perform any of the following optional definition tasks which identify various capabilities and attributes of the control point.

APPN offers configuration commands allow you to limit the resources on the router that are consumed for APPN. You may configure both the maximum memory and maximum percentage of system buffers that APPN is permitted to use. APPN cached directory entries and cached topology routing trees can additionally be limited to a maximum number.
Task Command

Specify the maximum memory available to APPN

maximum-memory bytes

Specify the maximum percentage of system buffers available to APPN.

buffer-percent percentage

Specify the maximum number of cached directory entries.

max-cached-entries number

Specify the maximum number of cached topology routing trees.

max-cached-trees number

If you plan to use Dependent LU Requestor (DLUR) to provide services for dependent LUs connected to this APPN node, you must indicate that this DLUR function is requested for this control point and may specify the number of PUs, from 1 to 100000, that are served by this DLUR. If you do not specify the maximum number of PUs, there is no limit on the number of PUs served by this DLUR. In addition, you may configure node-wide defaults for the Dependent LU Server and Backup Dependent LU Server that this node will contact.
Task Command

Specify that the DLUR is supported on the control point and optionally specify the maximum number of physical units (PUs) served by this DLUR.

dlur [max-pus number]

Specify the name of the default DLUS that provides SSCP services to the downstream PU.

dlus netid.cpname

Specify the default backup DLUS, to perform SSCP services for downstream PUs if the default DLUS is unavailable.

backup-dlus netid.cpname

You may configure the relative resistance you wish this node to have when being considered for APPN intermediate session routes. This is a number in the range 0 through 255 that specifies this node's relative resistance. The default resistance is 128.
Task Command

Specify the resistance of the local node

route-additional-resistance number

Cisco's APPN implementation allows you to save the APPN directory on a tftp host. This feature allows the node to restore previously learned directory information when the node is restored to service or in the event of a failure.
Task Command

Enable directory safe store and specify the IP host address and the file path for safe store.

safe-store-host ip address address directory path

Specify the number of separate cache instances to save before overwriting previous instances

safe-store-cycle number

Specify how often the directory database is stored to permanent media.

safe-store-interval interval

The id number and id block that this node presents in XID when connecting to other nodes is configurable. Together these represent the node identifier for the local node.
Task Command

Specify the id block, the first 3 digits of the node identifier for the local node.

xid-block-number number

Specify the id number, the last 5 digits of the node identifier for the local node

xid-id-number number

Cisco offers the ability to use interrupt-switched intermediate session routing between APPN ports which have equal maximum Basic Trasmit Unit (BTU) sizes. To allow this node to use interrupt switched intermediate session routing, perform the following configuration task and ensure that the maximum BTU sizes are equal on the port which you wish to use interrupt switched routing.
Task Command

Enable the use of interrupt switched intermediate session routing when possible

interrupt-switched

The following commands allow for the addition, removal, or completion of configuration items within the APPN Control Point mode.
Task Command

Negate or restore the default value for a configuration command

no command

Complete the APPN control point definition, return to global configuration mode, and update the APPN subsystem

complete

Allow modifications to a previously completed APPN control point definition,

no complete

Exit APPN control point definition dialog without completing the definition and without updating the APPN subsystem.

exit

Configure Serial Interface Encapsulation

If you plan to use APPN over a serial interface, the interface must be configured to a serial encapsulation type supported by APPN. The following encapsulations are supported:

Define an APPN Port

An APPN port definition is used to associate APPN capabilities with a specific interface APPN will use. Each interface that will be used for APPN communications requires an APPN port definition statement. A port can be associated with a specific interface by performing the following configuration task:
Task Command

Define an APPN Port associated with a interface

appn port portname interface

A port may also be associated with a source-route bridge ring group to enable APPN to send and receive traffic to any local or remote source-route bridged station. To configure a virtual port that connects to a source-bridge ring-group, perform the following task.
Task Command

Define an APPN Port associated with a source route bridge group.

appn port portname rsrb

Performing either of these tasks takes you from global configuration mode into APPN Port mode. From this mode, you can perform any of the following optional definition tasks which identify various capabilities and attributes of the port.

Each APPN link negotiates a maximum Basic Transmit Unit (BTU) size during connection phase with an adjacent node. This value limits the size of a SNA frame that can be sent over the link. On a port, the maximum BTU that can be received on this port can be configured and will be enforced for every APPN link using this port. In addition, the desired maximum BTU that can be sent by this node can be specified. The maximum BTU must be configured to be smaller than the maximum transmit unit (MTU) for the interface associated with this port.

The maximum BTU for a link can affect APPN intermediate session routing performance. A larger maximum BTUs allow more data to be placed in each SNA frame, offering higher data throughput for APPN intermediate session routing.

The Basic Transmission Unit (BTU) specifies a maximum message size of all SNA control information and data, exclusive of DLC and LLC header information. BTU should be set lower than the MTU to allow for DLC control information such as station addresses, DLC control fields and the routing information field (RIF), if present.

APPN, by default, uses a maximum BTU size which varies from 1280 to 4096 depending on the type of port being defined. Perform the following tasks if you wish APPN to use a different maximum BTU size.
Task Command

Specify the desired maximum receive BTU.

max-rcv-btu-size size

Specify the maximum BTU size for transmission groups using this port.

desired-max-send-btu-size size

APPN, by default, uses SAP 4. Perform the following task if you wish APPN to use a different sap on this port.
Task Command

Specify the local SAP to activate on the interface.

local-sap sap

The maximum number of link stations that can use an APPN port at any one time is configurable, as is the number of this maximum that are reserved for link stations connecting in to this port and link stations connecting out from this port.
Task Command

Specify the maximum number of active link stations allowed on this port.

max-link-stations number

Specify the number of link stations to be reserved for inbound links.

reserved-inbound number

Specify the number of link stations to be reserved for outbound links.

reserved-outbound number

A port is configured, by default, to accept connections from other APPN nodes dynamically without requiring a link station definition for that node. In is possible to configure a port such that it does not accept incoming connection requests unless a link station has been predefined for the partner node.
Task Command

Specify that this port will not create dynamic link stations.

no service-any

The null-xid-poll command permits PU 2.0 devices that connect in with XID0 to build a dynamic link station. It is no longer necessary to configure a link definition. When this command is used, the router expects its partner to reveal its identity first by responding with either XID3 or XID0.

This feature works in a mixed environment of PU 2.0 and PU 2.1 devices where the same APPN port is shared by both types of devices. By default, XID3 is used to poll the devices. When a PU 2.0 device responds with XID0, the link is created and established dynamically. PU 2.1 devices are not affected by this change, and go through the XID3 negotiation as usual.

To configure null-xid-poll, perform the following task in APPN port configuration mode:    
Task Command

Specify that the null XID should be used to poll the remote node associated with this APPN port.

null-xid-poll

Care must be exercised when configuring null-xid-poll. If two Cisco APPN network node routers connect across ports configured with null-xid-poll, the APPN connection will fail because both routers expect the other to respond first using either XID0 or XID3. Similar behavior may occur when a port configured with null-xid-poll attempts communication with a front-end processor configured for XID polling. You only need to configure null-xid-poll when dealing with a PU 2.0 device that does not respond gracefully to the XID3 poll.

If the port defined port is an RSRB virtual port, the port must be assigned a mac address and must be associated with a source route bridge ring group.
Task Command

Assign a mac address and ring number to an RSRB virtual port, and associate it with a source route bridge ring group.

rsrb-virtual-station mac-address local-ring bridge-number target-ring

If the port is defined as an SDLC port, the secondary SDLC address can be specified. For X.25, an X.121 address for this port may be configured.
Task Command

Assign a secondary sdlc address to this port.

sdlc-sec-addr address

Assign an X.121 address for a port on an x.25 interface

x25-subaddress {pvc | svc} address

Many APPN port configuration commands are used to assign link station parameters for dynamic links that use this port. In addition, these values can be used to establish default values for defined link stations associated with this port. The following configuration tasks are used to configure default link station values for link stations associated with this port. For more information on these tasks, see the section "Define an APPN Link Station."
Task Commands

Specify the cost per byte TG characteristic for link stations on this port.

cost-per-byte cost

Specify the cost per connect time TG characteristic for link stations on this port.

cost-per-connect-time cost

Specify the effective capacity TG characteristic for link stations on this port.

effective-capacity capacity

Specify that the link stations on this port should be taken down when no sessions are using the link.

limited-resource

Specify the propagation delay TG characteristic for link stations on this port.

propagation-delay {minimum | lan | telephone | packet-switched | satellite | maximum}

Specify how many times a link-station will attempt activation and the interval between retries

retry-limit {retries | infinite} [interval]

Specify the link station role used in XID negotiations.

role {negotiable | primary | secondary}

Specify the security level TG characteristic for link stations on this port.

security {nonsecure | public-switched | underground-cable | secure-conduit | guarded-conduit | encrypted | guarded-radiation}

Specify the user-defined-1 TG characteristic for link stations on this port.

user-defined-1 value

Specify the user-defined-2 TG characteristic for link stations on this port.

user-defined-2 value

Specify the user-defined-3 TG characteristic for link stations on this port.

user-defined-3 value

The following commands allow for the addition, removal, or completion of configuration items within the APPN PORT mode.
Task Command

Negate or restore the default value for a configuration command.

no command

Complete the APPN port definition, return to global configuration mode, and update the APPN subsystem.

complete

Allow modifications to a previously completed APPN port definition.

no complete

Exit APPN port definition dialog without completing the definition and without updating the APPN subsystem.

exit

Define an APPN Link Station

A link station is a representation of the connection or potential connection to another node. In many cases, if the partner node is initiating the connection, a link station definition is not necessary. It will be built dynamically when the partner node initiates the connection. You must define a link station if you want this node to initiate APPN connections with other nodes. In addition, you may define a link station to specify attributes of an APPN connection regardless of which node initiates the connection.
Task Command

Define an APPN Logical Link.

appn link-station linkname

Performing this task takes you from global configuration mode into APPN Link Station mode. From the APPN LINK STATION mode, you must associate the link station with an APPN port that it will use.
Task Command

Associate a link station with the APPN port that it will use.

port portname

In addition, the following optional configuration tasks can be performed in APPN Link Station mode.

When defining a link that can initiate a connection to a partner node, a destination address must be provided to allow this node contact the partner. This address is also used for incoming connections to associate the appropriate link station with the incoming call. The configuration command for specifying a destination address varies depending on the media in use.
Task Command

Configure a destination address and destination SAP for LAN media that use a 6 byte hardware address. This includes Token Ring, Ethernet, FDDI, and connections through RSRB.

lan-dest-address mac-addr [sap]

Specify the Frame Relay DLCI of the partner node for Frame Relay links.

fr-dest-address dlci [sap]

Specify the SDLC address for the partner node for sdlc links.

sdlc-dest-address address

Specify the X.25 address for the partner node for X.25 links.

x25-dest-address address

For most APPN connections, the adjacent CP name, TG number, and link station role can be learned or negotiated dynamically so there is no reason to configure them. If necessary, these items can be configured with the following commands. If the partner node requests values which differ from the values coded, the link activation will fail.
Task Command

Specify the name of the partner node for the link station.

adjacent-cp-name netid.cpname

Specify the transmission group number for the link.

tg-number number

Specify the link station role.

role {negotiable | primary | secondary}

A link station defaults to attempt a connection with the adjacent node when the APPN subsystem starts. If you wish to define a link, but not have it automatically attempt to establish a connection with the partner node, perform the following task:
Task Command

Specify that the link will not attempt to establish an APPN connection when the APPN subsystem is started.

no connect-at-startup

APPN will attempt to bring up CP-CP sessions on the first active link between network nodes. It is possible to prevent CP-CP session establishment on a link by performing the following task:
Task Command

Specify that no CP-CP sessions will be established on this link.

no cp-cp-sessions-supported

By default, APPN accepts connections and learns the node type of the partner node during XID exchange. If you wish to enforce that only a certain node type is permitted to connect via this link station, configure the following:
Task Command

Specify that the adjacent node type must be verified as a requirement of link activation.

verify-adjacent-node-type {learn | len | nn}

If you want this link to disconnect when no sessions are using it, you may indicate that the link is a limited resource.
Task Command

Specify that the link is to be taken down when no sessions are using the link.

limited-resource

When this node is attempting to establish a connection with an adjacent node, you can configure the number of times this node will attempt to initiate contact and the time interval between connection attempts. Each time the link station is started the retry count is reset and the node will attempt connection until the retry limit is reached.
Task Command

Specify how many times a link-station will attempt activation, and the interval between retries.

retry-limit {retries | infinite} interval

APPN links can be configured to interoperate with priority or custom queuing mechanisms available in the Cisco Router. To configure an APPN link for priority or custom queueing, perform one of the following tasks:
Task Command

Specify the custom queuing queue number for this link station.

link-queuing custom queue-number

Specify the priority queuing parameter for this link station.

link-queuing priority {high | medium | low | normal}

If you are using Dependent LU Requestor (DLUR), you may configure the primary and backup DLUS for links on which this node is providing SSCP services via the DLUR function. These definitions override the node-wide defaults that may have been configured in APPN Control Point mode..
Task Command

Specify the name of the Dependent LU Server (DLUS) node that provides SSCP services to the downstream PUs of the link.

dlus netid.cpname

Specify the backup DLUS node that will be used in the event the primary DLUS is unreachable.

backup-dlus netid.cpname

Normally, DLUR will discover the capabilities of the adjacent node and will initiate the proper XID exchange for pu type 2.0 nodes. However, a node which sends null XID but cannot receive XID3 will require configuration as a type 2.0 device to allow the node to connect properly for DLUR services. In addition, if you wish to configure this node to establish the link to the downstream PU in cases where the DLUS is initiating the activation of the device, you must configure the downstream PU name as it is known to the DLUS. In most cases, the DLUR initiates activation of the device, so coding the PU name is not necessary.
Task Command

Specify that the downstream PU whose dependent LU request is propagated through the link is a PU Type 2.0

pu-type-20

Specify the downstream PU name.

dlur-dspu-name puname

APPN calculates routes for SNA sessions using a complex algorithm which compares various characteristics of a APPN transmission group (TG) with the acceptable range of these characteristics defined in the APPN class of service (COS) requested. Cisco uses defaults for these values that offer basic APPN functionality without the need to customize TG characteristics. However, if you wish to configure TG characteristics for an APPN connection, use the configuration commands below.
Task Commands

Specify the cost per byte TG characteristic for this link.

cost-per-byte cost

Specify the relative cost per connection TG characteristic for the link.

cost-per-connect-time cost

Specify effective-capacity TG characteristic for the link.

effective-capacity number

Specify the propagation delay TG characteristic for the link.

propagation-delay {minimum | lan | telephone | packet-switched | satellite | maximum}

Specify the security level TG characteristic for the link.

security {nonsecure | public-switched | underground-cable | secure-conduit | guarded-conduit | encrypted | guarded-radiation}

Specify the user-defined-1 TG characteristic for this link station.

user-defined-1 value

Specify the user-defined-2 TG characteristic for this link station.

user-defined-2 value

Specify the user-defined-3 TG characteristic for this link station.

user-defined-3 value

The following commands allow for the addition, removal, or completion of configuration items within the APPN LINK STATION mode.
Task Command

Negate or restore the default value for a configuration command.

no command

Complete the APPN link station definition, return to global configuration mode, and update the APPN subsystem.

complete

Allow modifications to a previously completed APPN link station definition.

no complete

Exit APPN link station definition dialog without completing the definition and without updating the APPN subsystem.

exit

Define an APPN Connection Network

An APPN connection network allows nodes on the same shared media to connect directly, even if the is no APPN link defined between them. Connection networks can be used to provide any to any connectivity on a shared media without the need to define any to any link station connectivity. When a route is calculated through a connection network, a dynamic link station will be built and a connection will be established between the nodes on each side of the connection network. You must configure the same connection network name at each node that will participate in the connection network.

To indicate that this node is a member of a specific connection network, perform the following task from global configuration mode:
Task Command

Define an APPN connection network.

appn connection-network netid.cnname

Performing this task takes you from global configuration mode into APPN CONNECTION NETWORK mode.

From APPN CONNECTION NETWORK mode, you can specify up to 5 ports that are visible to the connection network. Usually, only a single port definition is desired for each connection network. However, in some instances it may be desirable to have more than one port as a member of a connection network, especially if two ports are attached to the same physical media. APPN route selection may choose any of the listed ports when calculating routes to or from any other member of this connection network. Therefore, it is important to ensure that each port listed is accessible by means of hardware address from every member of the connection network.

Ensure the port you choose is on an interface type that supports APPN connection networks. Token Ring, Ethernet, FDDI and RSRB virtual ports support connection network definitions.
Task Command

Associate a port name with this connection network definition.

port portname

The following commands allow for the addition, removal, or completion of configuration items within the APPN CONNECTION NETWORK mode.
Task Command

Negate or restore the default value for a configuration command.

no command

Complete the APPN connection network definition, return to global configuration mode, and update the APPN subsystem.

complete

Allow modifications to a previously completed APPN connection network definition.

no complete

Exit APPN connection network definition dialog without completing the definition and without updating the APPN subsystem.

exit

Define an APPN Class of Service

Cisco provides standard predefined APPN class of service definitions that are commonly used in APPN networks. These are #BATCH, #BATCHSC, #CONNECT, #INTER, #INTERSC, SNASVCMG, CPSVCMG. You can define an APPN class of service or modify the predefined definitions. Each class of services definition must have between one and eight node rows, between one and eight tg rows, as well as a transmission priority to be used for this class of service.

Each node row defines the weight to be assigned to a node used in APPN route calculation which is within the range of values for this row. The first row should have the smallest weight and the most restrictive range of acceptable values. Subsequent rows should have higher weight and be less restrictive that the previous in the range of acceptable values. Note that if a node does not fit within the acceptable range for any of the node rows, it will not be considered for inclusion in a route with the class of service.

For each node row defined, specify maximum and minimum values for node congestion and route-additional-resistance. Node congestion is either yes or no; route-additional-resistance is a value between 0 and 255 with higher numbers indicating higher resistance to intermediate routes.

Similarly, each tg row defines the weight to be assigned to a link used in APPN route calculation which is within the acceptable range of values for this row. Like node rows, each subsequent row should increase in weight and be less restrictive than the previous in the range of acceptable values. If the tg characteristics do not lie within any the acceptable range for any of the tg rows, the link will not be considered when calculating a route with this class of service.

Each tg row allows you to specify the maximum and minimum values for cost per byte, cost per connect, link capacity, propagation delay, security and three user defined characteristics. Each of these is specified using a relative value between 0 and 255.

To define a class of service issue the appn class-of-service command from global configuration mode.
Task Command

Define an APPN Class of Service.

appn class-of-service cosname

Performing this task takes you from global configuration mode into APPN Class of Service mode. From the Class of Service mode, you must perform the following tasks:
Task Command

Specify a node row number, the weight for this row, and the minimum and maximum values for allowed for nodes that may be assigned this weight.

node-row index weight weight congestion {yes | no} {yes | no} route-additional-resistance min max

Specify a tg row number, the weight for this row, and the minimum and maximum values for TGs that may be assigned this weight.

tg-row index weight weight byte min max time min max capacity min max delay min max security min max user1 min max user2 min max user3 min max

Specify the transmission priority for the class of service.

transmission-priority {network | high | medium | low}

The following commands allow for the addition, removal, or completion of configuration items within the APPN CLASS OF SERVICE mode.
Task Command

Negate or restore the default value for a configuration command.

no command

Complete the APPN class of service definition, return to global configuration mode, and update the APPN subsystem.

complete

Allow modifications to a previously completed APPN class of service definition.

no complete

Exit APPN class of service definition dialog without completing the definition and without updating the APPN subsystem.

exit

Define an APPN Mode

An APPN mode definition is used by a network node to associate a mode name received on an APPN search or session request with a class of service known to this node. Most APPN nodes will supply the class of service to their network node server, so mode definition may not be required in many APPN networks. However, if this node is providing network node services to an end node that does not supply a class of service, or this node is providing network node services for a LEN node, mode definitions may be required for each mode that is used by the partner node.

Cisco provides standard predefined mode definitions for modes that are commonly used in an APPN network. The predefined mode names are the blank mode, #BATCH, #BATCHSC, #INTER, #INTERSC, CPSVCMG, SNASVCMG. You can change a predefined mode or define a new mode. To define an APPN mode, perform the following task in global configuration mode:
Task Command

Define an APPN Mode.

appn mode modename

Performing this task takes you from global configuration mode into APPN MODE configuration mode. Within this mode, you must assign a class of service to the mode definition.
Task Command

Associate a class of service with the defined mode.

class-of-service cosname

The following commands allow for the addition, removal, or completion of configuration items within the APPN MODE configuration mode.
Task Command

Negate or restore the default value for a configuration command.

no command

Complete the APPN mode definition, return to global configuration mode, and update the APPN subsystem.

complete

Allow modifications to a previously completed APPN mode definition.

no complete

Exit APPN class of service definition dialog without completing the definition and without updating the APPN subsystem.

exit

Define an APPN Partner LU Location

The APPN directory stores names of resources and their owners. Usually this information is learned dynamically via APPN searches. However, you may wish to manually define the location of specific resources. Doing so can improve network performance by allowing directed APPN searches to travel straight to the owning CP, without the need for an initial broadcast search for the resource. However, APPN is known for its dynamic capabilities, not its need for system definition. For this reason, and for easier manageability, it is good practice to define location names only when necessary.

When a LEN node is attached to an APPN network node, all destination resources that reside on the LEN node must be defined on the network node to be reachable via the APPN network.

To define a partner LU location, perform the following task in global configuration mode:
Task Command

Specify the partner resource name.

appn partner-lu-location netid.name

Performing this task takes you from the global configuration mode into the APPN Partner LU Location mode.

You must configure an owning CP for each partner LU configured. The owning CP is the control point name for the LEN, end node, or network node on which the resource resides.
Task Command

Specify the name of the CP owning the partner LU.

owning-cp netid.cpname

If this node is not the network node server for the resource, you may also configure the network node server name. To reap the benefit of reduced APPN searching, the network node server operand must be coded and must be the current server for the resource.

If this node is the network node server for the resource being defined, do not configure a network node server.
Task Command

Specify the name of the network node server for the resource.

serving-nn netid.cpname

A partial name wildcard partner LU is a definition which applies to all resources that match a partial name. For example, a definition for location NETA.PE which is specified as a wildcard definition serves as a entry for NETA.PEANUT and NETA.PENNY, but not NETA.PUMKIN. Be careful when using partial name wildcards, as they can easily cause network problems if resources that match the partial name do not actually exist in the specified location.

A full wildcard partner LU definition is specified by defining a partner LU location without specifying a resource name and specifying the wildcard option. Full wildcards answer positively to any search for any resource in the network. Only one full wildcard definition can exist in an APPN network. Full wildcards are sometimes used when the APPN subnetwork is small and an attached LEN node is the gateway to a large connected network. Full wildcard definitions reduce APPN performance and can cause a variety of network problems. Hence, use of full wildcard definitions should be avoided.
Task Command

Specify this entry as a partial-name wildcard or a full wildcard.

wild-card

The following commands allow for the addition, removal, or completion of configuration items within the APPN Partner LU Location mode.
Task Command

Negate or restore the default value for a configuration command.

no command

Complete the APPN partner LU definition, return to global configuration mode, and update the APPN subsystem.

complete

Allow modifications to a previously completed APPN partner LU definition.

no complete

Exit APPN partner LU definition dialog without completing the definition and without updating the APPN subsystem.

exit

Start the APPN Subsystem

The APPN subsystem may be started via global configuration mode or privileged EXEC mode.
Task Command

Start the APPN subsystem from global configuration mode. Provide this configuration is saved, the APPN subsystem will start each time the router is booted.

appn routing

Start the APPN subsystem from privileged EXEC mode without affecting the current configuration.

appn start

Stop the APPN Subsystem

The APPN subsystem may be stopped via global configuration mode or privileged EXEC mode.
Task Command

Deactivate APPN routing from global configuration mode and remove it from the current configuration.

no appn routing

Deactivate APPN routing from privileged EXEC mode without affecting the current configuration.

appn stop

Starting and Stopping APPN Ports and Link Stations

APPN port and link station definitions are started automatically when the APPN subsystem starts. However, configuration commands will not take effect on an APPN port or link when it is active. The following privileged EXEC commands allow a APPN ports and link stations to be stopped and started when making configuration changes or when resetting the APPN port or link is desired.
Task Command

Deactivate the specified APPN link.

appn stop link linkname

Deactivate the specified APPN port.

appn stop port portname

Activate the specified APPN link.

appn start link linkname

Activate the specified APPN port.

appn start port portname

Monitor the APPN Network

You can monitor the status and configuration of the APPN subsystem by issuing any of the following commands in EXEC mode:
Task Command

Display APPN classes of service that are defined to the local node.

show appn class-of-service [brief | detail]

Display APPN connection networks that are defined to the local node.

show appn connection-network [brief | detail]

Display the contents of the APPN directory database.

show appn directory [brief | detail]

Display dependent LUs served by the DLUR function.

show appn dlur-lu [brief | detail]

Display dependent PUs served by the DLUR function.

show appn dlur-pu [brief | detail]

Display the status of connections to Dependent LU servers

show appn dlus [brief | detail]

Display information about the SNA sessions that are currently being routed through the local node.

show appn intermediate-session [brief | detail]

Display information about the APPN link stations that are active on or defined to the local node.

show appn link-station [brief | detail]

Display information about the APPN modes defined to the local node.

show appn mode [brief | detail]

Display information about the local APPN control point.

show appn node

Display information about the APPN ports that are active on the local node.

show appn port [brief | detail]

Display information about the SNA LU6.2 sessions, such as CP-CP sessions, that originate at the local node.

show appn session [brief | detail]

Display the contents of the APPN topology database.

show appn topology [brief | detail]

APPN Configuration Examples

The following sections provide example configuration that show how to configure various aspects of an APPN network:

These examples specify proper configuration between two Cisco routers. If you are defining an APPN connection to a non-Cisco APPN platform, the configuration for the Cisco router will be similar to those shown here.

Configuring an APPN Link over Token Ring

The following example illustrates a basic APPN link over Token Ring media. In this example, Router 1 is configured to establish the connection, while Router 2 will wait for the connection from Router 1 and build a dynamic link station when Router 1 connects.

Configuration for Router 1
!
interface TokenRing0
!
appn control-point neta.router1
  complete
!
appn port tr0 TokenRing0
  complete
!
appn link-station router2
  port tr0
  lan-dest-address 1111.1111.1112
  complete
Configuration for Router 2
! TokenRing1 mac address is 1111.1111.1112
interface TokenRing 1
!
appn control-point neta.router2
  complete
!
appn port tr1 TokenRing0
  complete

Configuring an APPN Link over FDDI

The following example illustrates an APPN link over FDDI. In this example, each router is configured with a defined link station to the other. Both routers are configured to not accept dynamic APPN connection requests on the FDDI port. Router 1 is configured to attempt to connect to Router  2, retrying every minute if the connection is not established. Router 2 is configured to wait for an incoming call from Router  1 and not attempt to establish the connection.

Configuration for Router 1
! FDDI0 mac address is 1111.1111.1111
interface Fddi0
!
appn control-point neta.router1
  complete
!
appn port fd0 Fddi0
  no service-any
  complete
!
appn link-station router2
  port fd0
  lan-dest-address 1111.1111.1112
  retry-limit infinite 60
  complete
Configuration for Router 2
! FDDI0 mac address is 1111.1111.1112
interface Fddi0
!
appn control-point neta.router1
  complete
!
appn port fd0 Fddi0
  no service-any
  complete
!
appn link-station router2
  port fd0
  lan-dest-address 1111.1111.1111
  no connect-at-startup
  complete

Configuring an APPN Link over Frame Relay

The following example illustrates an APPN link over frame relay. Both routers are configured to attempt to establish the connection with the partner.

Configuration for Router 1
!
interface Serial0
  encapsulation frame-relay IETF							
  frame-relay map llc2 22
!
appn control-point neta.router1
  complete
!
appn port framerly Serial0
  complete
!
appn link-station router2
  port framerly
  fr-dest-address 22
  complete
Configuration for Router 2
!
interface Serial3
  encapsulation frame-relay IETF							
  frame-relay map llc2 21
!
appn control-point neta.router2
  complete
!
appn port frame Serial3
  complete
!
appn link-station router1
  port frame 
  fr-dest-address 21
  complete

Configuring an APPN Link over SDLC

The following example illustrates an APPN link over Synchronous Data Link Control (SDLC). In this example, Router  2 is configured without a link station---it will be built dynamically when contacted by Router  1.

Configuration for Router 1
!
interface Serial0
  encapsulation sdlc
  sdlc address c1
!
appn control-point neta.router1
  complete
!
appn port sdlc Serial0
  sdlc-sec-addr c1
  complete
!
appn link-station router2
  port sdlc
  sdlc-dest-address c1
  complete
Configuration for Router 2
! 
interface Serial3
  encapsulation sdlc
  sdlc address c1
!
appn port sdlc Serial3
  sdlc-sec-addr c1
  complete

Configuring an APPN Link over RSRB Using TCP Local Acknowledgment

The following example illustrates an APPN link using an RSRB virtual port. This allows APPN links to span a routed IP multiprotocol network clouds as well as offering transport over interface encapsulation types not supported natively by APPN. In this example, the interface encapsulation is HDLC, the default for serial interfaces. Both routers are configured to attempt to initiate the connection with the other when their respective link stations are activated.

Configuration for Router 1
source-bridge ring-group 33
source-bridge remote-peer 33 tcp 1.1.1.1
source-bridge remote-peer 33 tcp 1.1.1.2 local-ack
!
interface Serial0
  ip address 1.1.1.1 255.255.255.0
!
appn control-point neta.router1
  complete
!
appn port rsrbport rsrb
  rsrb-virtual-station 1111.1111.1111 13 33
  complete
!
appn link-station router2
  port rsrbport
  lan-dest-address 1111.1111.1112
  complete
Configuration for Router 2
source-bridge ring-group 33
source-bridge remote-peer 33 tcp 1.1.1.2
source-bridge remote-peer 33 tcp 1.1.1.1 local-ack
! 
interface Serial3
  ip address 1.1.1.2 255.255.255.0
!
appn control-point neta.router2
  complete
!
appn port rsrbport rsrb
  rsrb-virtual-station 1111.1111.1112 23 33
  complete
!
appn link-station router1
  port rsrbport
  lan-dest-address 1111.1111.1111
  complete

hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.