|
|
Many enterprises today maintain two networks: a traditional, hierarchical System Network Architecture (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 and 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. Advanced Peer-to-Peer Networking (APPN) gives the additional flexibility to route SNA natively, without encapsulation. You can use APPN by itself or in combination with RSRB and DLSw+ to provide the best solution for your networking needs.
For a complete description of the commands mentioned in this chapter, refer to the "APPN Configuration Commands" chapter of the Bridging and IBM Networking Command Reference.
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.
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.
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.
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.
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.
See the end of this chapter for "APPN Configuration Examples."
An APPN control point definition is required to use APPN. This definition adds the fully qualified control point name for the node, which is a combination of a network identifier and a control point name. The network identifier (NETID) must be the same as other network nodes in the APPN subnetwork attached to this node. The control point 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 configuration 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 that 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.
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. In addition, you may configure node-wide defaults for the Dependent LU Server and Backup Dependent LU Server that this node will contact.
You may configure the relative resistance you wish this node to have when being considered for APPN intermediate session routeing (ISR). 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.
The ID number and ID block combine to form the identifier for this node in the XID that is exchanged when the local node connects to other nodes.
Cisco offers the ability to use interrupt-switched ISR between APPN ports that have equal maximum basic transmit unit (BTU) sizes. To allow this node to use interrupt switched ISR, perform the following configuration task and ensure that the maximum BTU sizes are equal on the ports that use interrupt switched routing.
| Task | Command |
|---|---|
| Enable the use of interrupt switched ISR when possible. | interrupt-switched |
The following commands allow for the addition, removal, or completion of configuration items within the APPN control point configuration mode.
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:
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 task in global configuration mode:
| 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 in global configuration mode.
| 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 configuration mode. From this mode, you can perform any of the following optional definition tasks that identify various capabilities and attributes of the port.
Each APPN link negotiates a maximum BTU size during connection phase with an adjacent node. This value limits the size of an 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 transmission unit (MTU) for the interface associated with this port.
The maximum BTU for a link can affect APPN ISR performance. Larger maximum BTUs allow more data to be placed in each SNA frame, offering higher data throughput for APPN ISR.
To configure the maximum BTU size, perform the following tasks in APPN port configuration mode:
| 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.
A port is configured, by default, to accept connections from other APPN nodes dynamically without requiring a link station definition for that node. It is possible to configure a port so that it does not accept incoming connection requests unless a link station has been predefined for the partner node.
To configure a port so that it does not accept incoming connection requests, perform the following task in APPN port configuration mode:
| 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 is an RSRB virtual port, the port must be assigned a Media Access Control (MAC) address and must be associated with a source-route bridge ring group.
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."
The following commands allow for the addition, removal, or completion of configuration items within the APPN port configuration 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
|
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.
To define an APPN logical link, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define an APPN logical link. | appn link-station linkname |
Performing this task takes you from global configuration mode into APPN link station configuration mode. From the APPN link station configuration 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 configuration mode.
When defining a link that can initiate a connection to a partner node, a destination address must be provided to allow this node to 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.
For most APPN connections, the adjacent control point name, transmission group 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.
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, perform the following task:
| 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 by performing the following task:
| 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 IOS software. To configure an APPN link for priority or custom queuing, 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 level |
If you are using dependent LU requestor (DLUR), you may configure the primary and backup dependent LU server (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 configuration mode.
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 pu-name |
APPN calculates routes for SNA sessions using a complex algorithm that compares various characteristics of an APPN transmission group 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 transmission group characteristics. However, if you wish to configure transmission group characteristics for an APPN connection, use the configuration commands below.
The following commands allow for the addition, removal, or completion of configuration items within the APPN LINK STATION mode.
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 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 configuration mode.
From APPN connection network configuration mode, you can specify up to five 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 configuration mode.
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 service definition must have between one and eight node rows, between one and eight transmission group 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 than the previous rows 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 transmission group 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 transmission group characteristics do not lie within any the acceptable range for any of the transmission group rows, the link will not be considered when calculating a route with this class of service.
Each transmission group 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 values is specified using a relative value between 0 and 255.
To define a class of service perform the following task in 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 configuration mode. From the class of service mode, you must perform the following tasks:
The following commands allow for the addition, removal, or completion of configuration items within the APPN class of service configuration 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, and 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.
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 control point, 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.luname |
Performing this task takes you from the global configuration mode into the APPN partner LU location configuration mode.
You must configure an owning control point for each partner LU configured. The owning control point 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 control point 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 reduce 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 that 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 the entry as a partial-name wildcard or a full wildcard. | wildcard |
The following commands allow for the addition, removal, or completion of configuration items within the APPN partner LU location configuration mode.
The APPN subsystem may be started via global configuration mode or privileged EXEC mode.
The APPN subsystem may be stopped via global configuration mode or privileged EXEC mode.
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 an APPN ports and link stations to be stopped and started when making configuration changes or when resetting the APPN port or link is desired.
You can monitor the status and configuration of the APPN subsystem by issuing any of the following commands in EXEC mode:
The following sections provide example configurations 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 IOS software will be similar to those shown here.
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.
! interface tokenring 0 ! appn control-point neta.router1 complete ! appn port tr0 tokenring 0 complete ! appn link-station router2 port tr0 lan-dest-address 1111.1111.1112 complete
! tokenring 1 mac address is 1111.1111.1112 interface tokenring 1 ! appn control-point neta.router2 complete ! appn port tr1 tokenring 0 complete
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.
! FDDI0 mac address is 1111.1111.1111 interface Fddi 0 ! 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
! 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
The following example illustrates an APPN link over Frame Relay. Both routers are configured to attempt to establish the connection with the partner.
! interface serial 0 encapsulation frame-relay IETF frame-relay map llc2 22 ! appn control-point neta.router1 complete ! appn port framerly serial 0 complete ! appn link-station router2 port framerly fr-dest-address 22 complete
interface serial 3 encapsulation frame-relay IETF frame-relay map llc2 21 ! appn control-point neta.router2 complete ! appn port frame serial 3 complete ! appn link-station router1 port frame fr-dest-address 21 complete
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.
interface serial 0 encapsulation sdlc sdlc address c1 ! appn control-point neta.router1 complete ! appn port sdlc serial 0 sdlc-sec-addr c1 complete ! appn link-station router2 port sdlc sdlc-dest-address c1 complete
interface serial 3 encapsulation sdlc sdlc address c1 ! appn port sdlc serial 3 sdlc-sec-addr c1 complete
The following example illustrates an APPN link using an RSRB virtual port. This configuration 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.
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 serial 0 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
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 serial 3 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
The following example illustrates an APPN link over QLLC to an AS400.
interface serial 1 no ip address encapsulation x25 dce no keepalive x25 address 1024 x25 map qllc 1234 clockrate 19200 no cdp enable ! appn control-point NETA.APPN1 complete ! appn port QLLC1 serial 1 complete ! appn link-station AS400 port QLLC1 x25-dest-address svc 1234 complete ! end
The following example illustrates an APPN link over ATM:
interface ATM2/0 atm pvc 1 1 12 aal5nlpid map-group atm-appn2 appn control-point NETA.APPN2 complete appn port ATM ATM2/0 complete appn link-station ATMLINK port ATM atm-dest-address 1 complete
The following example illustrates an APPN link over PPP:
interface serial 1 ip address 10.1.1.2 255.255.255.0 encapsulation ppp no keepalive no fair-queue appn control-point NETA.APPN2 complete appn port PPP serial 1 complete appn link-station PPPLINK port PPP complete
The following example illustrates and APPN link over SMDS:
interface serial 0 ip address 10.1.1.1 255.255.255.0 encapsulation smds... appn control-point NETA.APPN2 complete appn port SMDS serial 0 complete appn link-station SMDSLINK port SMDS smds-dest-address c120.0000.0002 complete
|
|