After you have configured the local network node, the network node will operate as an APPN router, communicating with other network nodes and accepting incoming session requests from end nodes. You can customize the APPN router for greater control and security by performing the following tasks:

• Statically defining links (adjacent link stations) to end nodes

• Statically defining entries into the network node's directory

You also can customize the APPN router by configuring the following items:

• Links to connection networks

• Parallel TGs

• Data link switching (DLSw) between nodes

• APPN and Boundary Routing environments

You normally do not have to define links (adjacent link stations) to end nodes. In APPN, end nodes make a link request to a network node to access the network. When a network node provides routing and topology services for an end node, the network node is called the network node server for the end node. End nodes can have links to more than one network node at a time, but only one network node can be the network node server to that end node at one time.

Because end nodes make incoming link requests to the network node, the process is dynamic, meaning end nodes can link to one network node for a certain time, then break the link and link to another network node for a different session request. As a result, it may not be practical to statically define links to end nodes if you have different network nodes that can serve as network node servers. If you have many end nodes, statically defining links for each one may not be practical.

You may want to statically define links to end nodes if you have a secure environment or want greater control over the network.

The procedure to define links to end nodes in your network node domain is similar to the procedure used to define links to other network nodes. Low-entry networking (LEN) end nodes are a subset of end nodes, and you define links to LEN end nodes the same way. However, if the LEN end node has more than one LU, then you need to statically predefine these LUs; for more information, see "Preconfiguring LEN End Node LUs" later in this chapter.

To define links to end nodes in your network node domain, follow these steps:

1 .   Define the link to an end node on a port and specify the node type as EN using:

ADD !<port> -APPN AdjLinkSta <type>(NN|EN|Learn) <max_btu_size>(99-8912) [[Cmac|Ncmac] dest media addr] [Sap=<num>] [CPName=[netid.]cpname] [Nodeid=<ID>] [LinkName=<name>] [TGprof=<name>] [AutoStart=(Yes|No)] [CPSess=(Yes|No)] [HPR=(Yes|No)] [ErrorRecovery=(Yes|No)]

or, if running SDLC traffic on the port:

ADD !<port> -APPN SdlcAdjLinkSta <type>(NN|EN|Learn) <max_btu_size>(99-8912) <station addr>(Hex 1-FE) [CPName=[netid.]cpname] [Nodeid=<ID>] [LinkName=<name>] [TGprof=<name>] [AutoStart=(Yes|No)] [CPSess=(Yes|No)][HPR=(Yes|No)] [ErrorRecovery=(Yes|No)] [SendWindow=<num>] [ContactTimer=<num>] [NoRspTimer=<num>] [NoRspTimRetry=<num>]

APPN over SDLC connections is supported on all types of HSS 3-Port modules, including V.35, RS-232, and RS-449.

In addition to the adjacent link station's node type, you specify the maximum BTU size, and the destination media address control (MAC) address for non-SDLC traffic, or the destination station address for SDLC traffic. Optionally, you can set the node's CP name, node ID, link name, TG profile, whether auto startup will be supported, and whether the link will support CP-CP sessions with the adjacent node. The default for end nodes is to support CP-CP sessions. For non-SDLC traffic, you can set the node's Service Access Point (SAP) number. For SDLC traffic, you can set SDLC attributes such as SendWindow, ContactTimer, NoRspTimer and NoRspTimRetry. If the adjacent link station will not support HPR, make sure to specify HPR=No to turn off HPR support.

For example, to add a link to an end node in an ISR network named "ENGREEN" to port 3 with a maximum BTU size of 1033 (specifying the appropriate MAC address and not fully qualified CP name), and to specify the link will support auto startup, enter:

ADD !3 -APPN AdjLinkSta EN 1033 N100040C08ACE Sap=08 CPName=ENGREEN AutoStart=Yes HPR=No

For information on how to obtain the MAC address of a node, see the documentation for the end node device or applications. Most SNA and token ring environments use noncanonical MAC address formats. To convert a MAC address to canonical format, use the MacAddressConvert command.

If you set the -SYS MacAddrFmt parameter to noncanonical, then you do not need to precede the MAC address with N or Ncmac.

2 .   After you have defined the link to the end node, define the link characteristics using:

SETDefault -APPN LinkStaCHar = <LinkStation name> [EffectCap=<string>] [ConnectCost=<0-255>] [ByteCost=<0-255>] [Security=<string>] [PropDelay=<string>] [Usd1=<0-255>] [Usd2=<0-255>] [Usd3=<0-255>]

With this command, you set attributes such as byte cost, security, connection cost, and effective capacity for the adjacent link station. For more information on configuring this parameter, see the description of the LinkStaCHar parameter in the APPN Service Parameters chapter in Reference for Enterprise OS Software.

3 .   Repeat steps 1 and 2 for each end node (or LEN end node) that you will allow to link directly with the local network node.

Defining Links to Unknown Node Types

You may not know if a node is a network node or an end node, or know the node name or CP name. To define an adjacent link station to an unknown type of node, enter the ADD -APPN AdjLinkSta command or the ADD -APPN SdlcAdjLinkSta command and specify the node type as LEARN. If you specify LEARN, the system learns the node type as well as other information such as the node name and CP name. To add a link station to a node whose node type is learned, you must at least know the MAC address of the node. To add an SDLC link station to a node whose type is learned, you must at least know the station address of the node.

For example, to define a link station on port 4 to an unknown node type with a maximum BTU size of 1033 and a noncanonical MAC address of %100040C08ACE, enter:

ADD !4 -APPN AdjLinkSta LEARN 1033 %100040C08ACE

The network node maintains a directory of nodes it knows about, and any logical units on those nodes. When an incoming session request comes to the network node, the network node uses the information stored in the directory to determine the location of the destination LU. If the destination LU is not located in the network node's domain, the network node sends locate requests to adjacent network nodes.

Figure 145 shows a network node and what nodes would be included in the network node's directory. Network node A is the local node. The shaded area indicates nodes that would be included in network node A's directory, either dynamically learned or statically defined. End nodes A1 and A2 are in network node A's domain, and would be dynamically learned and added to the directory. LEN end node A3 is also in network node A's domain; if there are other LUs on that LEN node other than the LU for the node's CP, these additional LUs would have to be statically defined (for more information on defining LEN end node LUs, see below). Network nodes B and C are also dynamically learned in network node A's directory because both are adjacent nodes, one hop away.

Network node D would not be included in the directory because it is not an adjacent node, and is two hops away. End nodes C1 and C2 would not be included because they reside in network node C's domain; as a result, end nodes C1 and C2 would be included in network node C's directory.

Figure 145 Nodes Included in the Network Node Directory (Example)

When you display the directory, the display shows the location of the logical units. In this example for network node A's directory, end nodes LUs on A1 and A2 would be registered entries, meaning they were dynamically learned, and the location would be domain, meaning they reside in the local domain. The LU on LEN end node A3 would be a home entry (meaning it was statically defined), and the location would be domain. For more information on displaying the directory, see the DIRectory parameter in the APPN Service Parameters chapter in Reference for Enterprise OS Software.

Preconfiguring LEN End Node LUs

When a LEN end node is added to an APPN network as an adjacent link station, the LEN end node sends an XID3 to the network node when the link activates. In this XID3, the LEN end node's CP name is sent in the ox0E control vector type F4. This CP name maps to the LEN end node's LU name. However, if the LEN end node has more than one LU, then you must statically preconfigure those LUs into the network node directory.

Figure 146 is an example of two LEN end nodes connected directly with the intermediate network node. On a LEN end node, the single LU that maps to the node's CP name that was sent in the control vector is dynamically registered through the XID3 with the network node when the link is activated. In the figure, both LU AA on PC AA and LU BB on PC BB would be dynamically registered.

Figure 146 LEN End Node LU Registration

You must statically define LEN end node LUs in the following situations:

• If the LU name does not match the CP name

• If the control vector does not send the LU name

• If the LEN end node has LUs in addition to the LU registered through the XID3

The PCs in the figure show the last situation, in which both PCs have additional LUs. Since the XID3 only registers the LU for the network name control vector, these additional LUs must be statically defined into the network node's directory using the AdjLenDef parameter.

In APPN, when two LEN end nodes have a peer-to-peer connection, either side can activate the connection or start a session to the other node. The LEN end node that activates the connection sends a BIND to the other node. For the connection to work, the LEN end node that receives the BIND has to be preconfigured into the network node directory so that the network node can find the destination LU to send the session request.

For example, if LU AA in the figure activates a session to LU BB2, then LU BB2 must be preconfigured in the network node's directory; otherwise, the session request will not be successful. If LU AA2 wants to activate a session to LU BB2, both LUs need to be preconfigured in the network node directory. After these two LUs are preconfigured, either LU can initiate a connection. Also, once LUs are preconfigured in the network node directory, other LUs in the network can find them. Conversely, if LUs that require preconfiguration are not in the network node directory, other LUs in the network will not find them.

To statically define LEN end node LUs into the network node directory, follow these steps:

1 .   If you have LEN end nodes with more than one LU, or LEN end nodes in the network node domain that will receive BINDs that do not match the CP name in the XID, you must statically define these LUs using:

ADD -APPN AdjLenDef [adjnetid.]<adjcpname> [adjlu ...]

This command statically defines any logical units on the LEN end node in the local network node server's directory.

For example, to add the three LUs named AA1, AA2, and AA3 on the LEN end node AA, enter:

ADD -APPN AdjLenDef AA AA1 AA2 AA3

When you add CP and LU names, the names are converted to all uppercase, even if you enter some lowercase letters. When entering this command, you can use the not fully qualified CP name. Use this command to define up to 4 LUs at a time; to define additional LUs, reenter the command. You can register up to 256 LUs on the network node.

2 .   Repeat the previous step for each LEN end node in your network node's domain with more than one LU. The entries take effect immediately.

For information on how to display entries in the directory, see "APPN Directory Information" later in this chapter.

Deleting LEN End Node LUs

You can delete statically defined LEN end node LU entries from the directory using the DELete -APPN AdjLenDef command. You can specify individual LUs to be deleted. If you do not specify LU names in the command, the entire adjacent node is deleted from the directory, along with all LUs belonging to the adjacent node.

For example, to delete the LUs named AA2 and AA3 on node AA, enter:

DELete -APPN AdjLenDef AA AA2 AA3

In most configurations, you do not need to statically define network nodes and regular end nodes in the directory. You do need to determine how many cached entries you will allow and if you have LEN end nodes that receive BINDs, you must statically define them for the directory.

Unlike LUs on LEN end nodes that may require static definition, LUs on end nodes and network nodes are normally learned dynamically. Although not required, you can also statically predefine the location of LUs on other nodes in the network.

To preload entries into the APPN directory cache, use:

ADD -APPN DirectoryEntry [netid.]<resource name> <type(LU|EN|NN|Wild)> [[netid.]<parent_name> <parent_type(EN|NN)>] [[netid.]<grandparent_name> <grandparent_type(NN)>]

Using this command, you enter the resource type into the directory. If the resource is not a network node, you must specify the parent name and parent type of the resource. The resource parent and child is used for destination node broadcast searches. When a node or LU is a child resource, the child must reply to the parent for a search to be completed.

Figure 147 is a simple example of how this directory hierarchy works. In this example on the network HQ, the network node NN22 is the parent resource to the end node ENGREEN, which is the child. ENGREEN is the parent resource to the LU named NSDOS, which is a child resource residing on that end node.

Figure 147 Parent and Child Directory Entries

To add a directory entry in which the LU named HQ.NSDOS is the child to the end node HQ.ENGREEN, which is a child entry to the network node HQ.NN22, enter:

ADD -APPN DirectoryEntry HQ.NSDOS LU HQ.ENGREEN EN HQ.NN22 NN

In this example, the network node HQ.NN2 is the grandparent entry to the LU HQ.NSDOS. When entering an entry for a grandchild (three levels down), you must specify the grandparent name. The grandparent type will always be a network node.

Alternatively, you can enter these directory entries separately. For example, you can enter the following three commands, the first to define the network node, the second to define a child entry for the end node, and the third to define a child entry for the LU:

ADD -APPN DirectoryEntry HQ.NN22 NN

ADD -APPN DirectoryEntry HQ.ENGREEN EN HQ.NN22 NN

ADD -APPN DirectoryEntry HQ.NSDOS LU HQ.ENGREEN EN HQ.NN22 NN

You can add wildcard entries to the directory. Wildcards are of two types: full, where you just enter an asterisk (*), or partial, where you enter part of the name and an asterisk (for example, LU7*).

To add a partial wildcard entry for all LUs that start with "LU7" as child entries to HQ.NN22, enter:

ADD -APPN DirectoryEntry LU7* Wild HQ.NN22 NN

To delete entries from the network node directory, use:

DELete -APPN DirectoryEntry [netid.]<lu_name> <type(LU|EN|NN|Wild)>

For example, to delete the directory entry NSDOS, for the LU on ENGREEN, enter the following command, entering the LU name and specifying the type as LU:

DELete -APPN DirectoryEntry HQ.NSDOS LU

If you delete a resource, all the child entries and grandchild entries belonging to that resource will also be deleted. For example, if you delete the grandparent entry HQ.NN22, the child entry HQ.ENGREEN and the grandchild entry HQ.NSDOS will also be deleted.

Configuring Parallel Transmission Groups

A transmission group (TG) is the link between two nodes. By configuring parallel TGs, you can configure two links from the local network node to the same adjacent node. This can provide more flexibility in routing APPN traffic to and from a single device. With parallel TGs, you can configure two links between the same two nodes, but not more than two.

Parallel TGs are not recommended for links over the same LAN, because there is no practical benefit for doing so; if you have parallel TGs over the same LAN and the LAN is busy, then both TGs will be busy.

If you configure parallel TGs between two NETBuilder II network nodes, then you only need to configure the partner node as an adjacent link station on one side.

There are several reasons why parallel TGs can be useful on your network:

• They can provide redundant links between nodes, to enable one link to take over if the other fails.

• You can assign different security levels to different TGs between nodes, allowing greater control over the traffic.

• You can assign different classes of service to each of the two TGs, allowing you to isolate different types of traffic over each link.

• You can have greater bandwidth between two nodes

When running parallel TGs, the CP-CP sessions can only go over one link at a time. With CP-CP session error recovery, if the link goes down the CP-CP sessions can be brought back up on the other link. For more information, see "CP-CP Sessions on Parallel TGs" later in this chapter.

Figure 148 is an example of parallel TGs being used for redundant links. In the configuration, both links between the network nodes are running at the same speed, and are running the same type of traffic. Each link is over a different port.

Although the links are redundant, if one link fails the traffic is not automatically switched to the second link. Unlike connectionless protocols, which can auto- matically switch links if a link fails, APPN is connection-oriented. As a result, if a link fails you will lose data, but you can restart your sessions over the second link.

Figure 148 Parallel TGs for Redundant Links

Figure 149 is an example of parallel TGs being sent over two different LANs. This configuration allows you to have redundancy between two nodes in your LAN environment. If one LAN fails, then you can restart sessions over the second LAN. If you configured both links on the same LAN, and the LAN fails, then both nodes would be isolated.

Figure 149 Parallel TGs over Different LANs for Resiliency

Figure 150 is a configuration in which parallel TGs are being used to isolate different types of traffic through different classes of service. The link on the left is set for a capacity of 256 KB and is being used for interactive traffic between terminals and the host; this type of traffic demands quicker response time so the class of service (COS) being used allows for a higher priority and the link is set for a higher speed. The link on the right is being used for lower speed batch transmissions, and as a result, is using the BATCH class of service and the link is set to a lower speed. In this example, the interactive traffic will be prioritized higher than the batch traffic.

For more information on configuring APPN class of service, see the Configuring APPN Class of Service chapter.

Figure 150 Parallel TGs for Isolating Class of Service Traffic

Configuring Parallel TGs on the Network Node

Figure 151 is an example of a NETBuilder II bridge/router network node with parallel TGs over two different ports to an AS/400. In this example, the TGs are on two different FDDI rings, one being used for primary traffic and the other used as a backup.

Figure 151 Configuring Parallel TGs

To configure the parallel TGs for ports 4 and 6 on the NETBuilder II bridge/router in the figure, follow these steps:

1 .   Define the ports using:

SETDefault !<port> -APPN PortDef = <DLC type> (LLC2|FR|PPP|DLSW|SDLC|UNdef) <max_btu_size>(99-8192) [ActLimit=<limit>(1-512)] [TGprof=<name>] [HPR=(Yes|No)] [ErrorRecovery=(Yes|No)] [DatMode=(Half|Full)] [ROle=(Pri|Sec|Neg)]

Define port 4 for LLC2 traffic, a maximum BTU size of 1033, and assign the TG profile "FDDI" by entering:

SETDefault !4 -APPN PortDef = LLC2 1033 TGprof=FDDI

Define port 6 for LLC2 traffic, a maximum BTU size of 1033, and assign the TG profile "FDDI" by entering:

SETDefault !6 -APPN PortDef = LLC2 1033 TGprof=FDDI

2 .   Define the adjacent link stations for both ports using:

ADD !<port> -APPN AdjLinkSta <type>(NN|EN|Learn) <max_btu_size>(99-8912) [[Cmac|Ncmac] dest media addr] [Sap=<num>] [CPName=[netid.]cpname] [Nodeid=<ID>] [LinkName=<name>] [TGprof=<name>] [AutoStart=(Yes|No)] [CPSess=(Yes|No)] [HPR=(Yes|No)] [ErrorRecovery=(Yes|No)]

Add the adjacent link station to port 4 to the destination media address on the AS/400 (entering the address in noncanonical format), a SAP of 08, and to specify autostart and CP-CP session activation by entering:

ADD !4 -APPN AdjLinkSta NN 1033 %10005A265BED Sap=08 TGprof=FDDI AutoStart=Yes CPSess=Yes

CP-CP sessions can only be active over one TG at a time.

Add the adjacent link station to port 6 for the different destination media address, a SAP of 08, specifying autostart and support for CP-CP sessions by entering:

ADD !6 -APPN AdjLinkSta NN 1033 %100608C26C15 Sap=08 TGprof=FDDI AutoStart=Yes CPSess=Yes

You can configure any adjacent link station characteristics using the LinkStaCHar parameter.

You cannot assign specific numbers to specific TGs. The TG numbers are assigned through negotiation between the two nodes.

You can also configure parallel TGs for links to an SDLC device. You perform the same procedure, but you use the SdlcAdjLinkSta parameter.

When parallel TGs are configured between 3Com network nodes and both TGs support CP-CP sessions, a CP-CP session on one TG will not switch to the other TG if the user disables the port or path. This situation occurs because both sides learn about the link failure at different times. The network node with the disabled port or path learns about the link failure immediately and tries to bring CP-CP sessions up on the second TG. However, the second network node does not learn about the link failure until LLC2 times out. Because the node thinks the link is still up, the second network node does not allow CP-CP sessions to start on the second TG. After five attempts at bringing up CP-CP sessions on the second TG, the second TG will be flagged as not supporting CP-CP sessions, which prevents CP-CP sessions from coming up on that second TG.

To prevent this situation, manually stop the first TG by entering the SET -APPN LinkStaCONTrol <LinkName> Deactivate command before disabling the port and path. By doing this, both network nodes then learn that the link has gone down at the same time, and CP-CP session can be activated on the second TG.

Parallel TGs and Source Route Dual-TIC Topologies

You can configure parallel TGs in environments in which dual or multiple token ring interface cards (TICs) are configured on front-end-processors. For more information on dual-TIC topologies, see "Configuring DLSw for Dual-TIC Topologies" in the Configuring Data Link Switching for SNA and NetBIOS Networks chapter.

Configuring DLSw Between Network Nodes

You can configure your APPN network so that you can send SNA traffic encapsulated in TCP packets over an IP network between two APPN network nodes using DLSw.

To configure DLSw between APPN nodes, additional configuration is necessary. Figure 152 is an example of two bridge/routers acting as APPN network nodes using DLSw to encapsulate SNA traffic in TCP packets across an IP internetwork. Table 36 lists the commands that need to be configured on each bridge/router in the figure.

Figure 152 Configuring DLSw Between Two APPN Network Nodes

Table 36 Commands to Configure DLSw Between Two APPN Network Nodes

Commands entered on Bridge/Router A	Commands entered on Bridge/Router B
SETDefault -IP CONTrol = Enable	SETDefault -IP CONTrol = Enable
SETDefault -TCP CONTrol = KeepAlive	SETDefault -TCP CONTrol = KeepAlive
SETDefault -TCP KeepAliveLimit = 3	SETDefault -TCP KeepAliveLimit = 3
SETDefault !1 -LLC2 CONTrol = Enable	SETDefault !2 -LLC2 CONTrol = Enable
SETDefault -LLC2 TUNnelVRing = 100	SETDefault -LLC2 TUNnelVRing = 100
SETDefault -DLSW Interface = 129.213.1.1	SETDefault -DLSW Interface = 129.220.1.2
ADD !1 -DLSW PEer 129.220.1.2	ADD !1 -DLSW PEer 129.220.1.1
SETDefault -DLSW CONTrol = EnableSNA, DisableNetBios	SETDefault -DLSW CONTrol = EnableSNA, DisableNetBios
SETDefault !0 -APPN PortDef = DLSW 1033	SETDefault !0 -APPN PortDef = DLSW 1033
ADD !0 -APPN AdjLinkStation NN 1033 N%100040200954

As shown in the figure, you configure the network nodes as DLSw peers and the DLSw tunnel interface information using the normal procedure. For specific instructions on how to configure DLSw peers, see the Configuring Data Link Switching for SNA and NetBIOS Networks chapter.

You cannot perform bridging and tunneling of the same MAC address from an end station. You can perform either bridging only or tunneling only, but not both at the same time.

After configuring the two bridge/routers as DLSw peers, to configure DLSw tunneling between two APPN network nodes, follow these steps:

1 .   On both APPN network nodes acting as DLSw tunnel peers, configure the APPN port definition using the SETDefault !<port> -APPN PortDef syntax, specifying DLSw as the DLC type.

When specifying the port definitions for DLSw, you must specify the port number as !0. You only need to set the port definition for !0 for ports used for DLSw, and you should not specify !0 when setting the port definition for any other DLC type.

On bridge/router A in the figure, using port 0 and setting a maximum BTU size of 1033, enter:

SETDefault !0 -APPN PortDef = DLSw 1033

On bridge/router B in the figure, using port 0 and setting a maximum BTU size of 1033, enter:

SETDefault !0 -APPN PortDef = DLSw 1033

The maximum BTU size does not have to match on both sides of the tunnel. If the maximum BTU sizes differ, the smaller value will be used.

2 .   On the bridge/router that will initiate the connection, configure the tunnel peer bridge/router as an adjacent link station using:

ADD !<port> -APPN AdjLinkSta <type>(NN|EN|Learn) <max_btu_size>(99-8912) [[Cmac|Ncmac] dest media addr] [Sap=<num>] [CPName=[netid.]cpname] [Nodeid=<ID>] [LinkName=<name>] [TGprof=<name>] [AutoStart=(Yes|No)] [CPSess=(Yes|No)]

When you enter the command, you specify that the peer is a network node, the maximum BTU size, and the MAC address of the tunnel peer. In this case, the tunnel peer will always be a network node, since the bridge/router can only serve as a network node. The MAC address you enter is the address of the tunnel peer bridge/router, not the destination SNA host (also shown in the figure).

In the example shown in the figure, enter the following command on bridge/router A to add the link station as a network node with a maximum BTU size of 1033 and a SAP value of 08:

ADD !0 -APPN AdjLinkSta NN 1033 N%100040200954 Sap=08

When adding the adjacent link station for DLSw, you must specify the port number as !0 to map to port 0 configured in the previous step.

For more information about configuring data link switching, see the Configuring Data Link Switching for SNA and NetBIOS Networks chapter. For information on parameters in the DLSw Service, see the DLSw Service Parameters chapter in Reference for Enterprise OS Software.

Boundary Routing is the 3Com system architecture that allows a network administrator to connect a central office network to a large number of small remote office networks (leaf networks). You can configure APPN to work in Boundary Routing environments, but there are limitations as to the types of configurations that can be set up. No additional APPN configuration is required for Boundary Routing environments. For information on Boundary Routing concepts and how to configure the central office router, see Chapter 41.

The 3Com Boundary Routing architecture is different from the APPN concepts of boundary nodes and border nodes. The 3Com APPN implementation supports the concept of boundary nodes but does not support the Systems Network Architecture (SNA) concept of border nodes or perform the border function. For clarification of these terms, see the IBM document, APPN Architecture and Product Implementations Tutorial listed in "IBM APPN References" later in this chapter.

Figure 153 is an example of a NETBuilder II bridge/router acting as an APPN network node and performing as the central site router in a Boundary Routing configuration connected to a SuperStack II NETBuilder bridge/router acting as a leaf node, which in turn is connected to a token ring network with APPN end nodes. The CP-CP session takes place between the NETBuilder II network node and the end node. The SuperStack II bridge/router acting as the leaf node does not participate in the CP-CP session, and cannot serve as an APPN node because the APPN software is not supported on the SuperStack II bridge/router platform. In this situation, no special configuration is required on the SuperStack II bridge/router.

Figure 153 Configuring APPN with the Boundary Routing Architecture

You can also use Boundary Routing with APPN connection networks. For more information, see "Using Connection Networks in Boundary Routing Environments" later in this chapter.

If you are configuring APPN for Boundary Routing, the following special configuration is required on the central site bridge/router:

• You must configure the port definition to DLSw by entering:

SETDefault !0 -APPN PortDef = DLSW

• To enable the central site bridge/router to send ring information to the leaf node, you must configure the central site WAN link as a source route link, and turn on route discovery for both IP and LLC2 using:

SETDefault !<port> -SR RouteDiscovery = IP, LLC2