C H A P TER 3

Migration Scenarios
This chapter describes basic configuration and shows several sample networks. For each network, it
describes the network design, explains when and why to use that network design, and in some cases
briefly describes how to migrate from or coexist with a FEP. Examples include:
• Single CIP to a single host
• Dual CIP to a single host
• Multi-LPAR single CIP
• APPN network
• APPN in a sysplex environment
• SNI-to-APPN border node migration

SNA Communication over CSNA

SNA nodes communicate to the CIP using LLC2, a connection-oriented data link protocol for LANs.
An LLC2 stack on the CIP card communicates with either the adjacent SNA device (over a physical
Token Ring) or to DLSw+ or APPN running in the channel-attached router, as illustrated in
Figure 3-1.

Figure 3-1 Communication between CSNA in the CIP and SNA Nodes

Mainframe

XCA
VTAM

FID2, FID4
CIP

CIP LLC2
7500
Internal Rings ...

LLC2 RP
Token Virtual
End Station Ring Ring
LLC2
DLSw+
APPN

Migration Scenarios 3-1

VTAM Definitions

The CIP running CSNA will support multiple internal LAN interfaces, each of which looks like a
LAN port to VTAM. (VTAM supports a maximum of 18 LAN ports.) However, only a single LAN
port is required. CSNA also supports up to 256 open LLC2 SAPs per LAN port.

VTAM Definitions
The CIP running CSNA is not an SNA addressable node—it has no PU or LU appearance. CSNA is
defined to the host control program (MVS or VM) as a channel-to-channel machine (a 3088). This
provides VTAM a physical connection out to the LAN through a subchannel.
To enable VTAM communication over the CIP to SNA devices, you must configure an XCA major
node and a switched major node to VTAM. The XCA major node allows VTAM to communicate
with the CIP, and the switched major node definition allows SNA devices to communicate with
VTAM over the CIP.

External Communication Adapter Major Node Definition

Define an XCA major node for each connection (port) between VTAM and a CSNA connection. A
single XCA major node can support up to 4096 LLC2 connections, although experience has shown
that better results are achieved with 3000 or fewer LLC2 connections per XCA major node. If more
LLC2 connections are needed, define additional XCA major nodes. Multiple XCA major nodes can
also be configured for availability, with each one pointing to a different CIP.
The CSNA feature is defined to the host control program (MVS or VM) as being a
channel-to-channel adapter or machine (CTCA), for example, a 3088. VTAM identifies the CSNA
gateway through a combination of the following:
• ADAPNO—Adapter number
• CUADD—Subchannel address
• SAPADDR—SAP address
XCANAME VBUILD TYPE=XCA ** EXTERNAL COMMUNICATION ADAPT**
PORTNAME PORT ADAPNO=?, ** RELATIVE ADAPTER NUMBER ** X
CUADDR=???, ** CHANNEL UNIT ADDRESS ** X
MEDIUM=RING, ** LAN TYPE ** X
SAPADDR=4 ** SERVICE ACCESS POINT ADDRESS**
GRPNAME GROUP ANSWER=ON, ** PU DIAL INTO VTAM CAPABILITY** X
AUTOGEN=(5,L,P), ** AUTO GENERATE LINES AND PUS ** X
CALL=INOUT, ** IN/OUT CALLING CAPABILITY ** X
DIAL=YES, ** SWITCHED CONNECTION ** X
ISTATUS=ACTIVE ** INITIAL ACTIVATION STATUS **

Switched Major Node Definition

Configure one or more switched major nodes. Within a switched major node definition, configure
every SNA PU that will access VTAM through the CIP. For each PU, configure its associated LUs.
Many networks today already have the SNA devices defined in a switched major node. For example,
if the devices attach to a FEP over Token Ring, they are already defined as part of a switched major
node. In this case, the only change is to add the XCA major node.
SWMSNAME VBUILD TYPE=SWNET, ** X
MAXGRP=14, ** X
MAXNO=64 **
PUNAME PU ADDR=01, ** X
PUTYPE=2, ** X
IDBLK=???, ** X
IDNUM=?????, ** X

3-2 Data Center Design and Implementation: SNA Internetworking

 Router Configuration

ISTATUS=ACTIVE **
LUNAME1 LU LOCADDR=02
LUNAME2 LU LOCADDR=03
LUNAME3 LU LOCADDR=04
LUNAME4 LU LOCADDR=05
LUNAME5 LU LOCADDR=06

Router Configuration
The router must be configured to:
• Bridge traffic from a physical LAN or a router component (DLSw+, SRB, SR/TLB, and so forth)
onto the router virtual ring
• Bridge data from the router virtual ring to one of the CIP internal rings, or connect a data link
user (APPN, DSPU) to one of the CIP internal rings
• Connect the CIP to VTAM
Figure 3-2 shows the major configuration parameters of the CIP and of the Token Ring interfaces
and how they are logically combined using the source-bridge definition. The CIP ring is referred to
as an internal ring. The RSP ring is referred to as a virtual ring.

Figure 3-2 Using Virtual Rings to Provide Connectivity

CIP Router Configuration

adapter 0 4000.7513.0001

CSNA lan tokenring 0

Internal Ring
300
source-bridge 300 1 100

Bridge 1

Virtual Ring
Group 100
source-bridge ring-group 100
interface tokenring 1
Bridge 1 source-bridge 1 1 100

TRIP

Token
Ring
Real Segment

Configure an adapter on the CIP to be associated with the XCA major node definition. For each
adapter configured, CSNA creates an internal Token Ring. A virtual bridge connects the CSNA
internal ring to a virtual ring group in the router. The Token Ring interface processor (TRIP) is also
configured to connect to the same virtual ring group as the CIP.

Migration Scenarios 3-3

Router Configuration

Configuration Relationships in the ESCON Environment

Figure 3-3 shows the relationship among router configuration, VTAM parameters, and MVS IOCP
generation commands when the CIP connects via an Escon director. Figure 3-4 shows the
relationship among router configuration, VTAM parameters, and MVS IOCP generation commands
when the CIP connects via bus and tag.

Figure 3-3 Relationship among MVS, VTAM, and Router Configurations: ESCON

Router Configuration IOCP

ESCON Director
source-bridge ring-group 100 resource part=((lpar1,1), (lpar2 2 ))

interface channel 1/0 chpid path=((21)),type=cnc,

csna C1 2 0 10 A2 C1 shared,switch=3,
partition=( lpar2 )
interface channel 1/2
lan tokenring 0
cntlunit cunumbr= 000e,
source-bridge 1 2 100
path=(21),unit=sctc,
adapter 0 4000.7513.0001
unitadd=(( 10,16 )),
link= a2, cuadd= 0

VTAM Configuration iodevice address= (110,16) ,

cunumbr=( 000e ),
vbuild type=xca unit=sctc
port adapno= 0 ,cuaddr= 110,
sapaddr=04, medium=ring
group answer=no, autogen=(25,I,p),
call=inout,dial=yes

3-4 Data Center Design and Implementation: SNA Internetworking

 Scenario 1: Single CIP to Single Host

Configuration Relationships in the Bus and Tag Environment

Figure 3-4 Relationship among MVS, VTAM, and Router Configurations: Bus and Tag

Router Configuration IOCP

source-bridge ring-group 100 chpid path=((21)),type=bl
interface channel 1/0
csna 0100 10 cntlunit cunumber= 000e,
protocol s4 path=(21),unit=3088,
interface channel 1/2 unitadd=(( 10,16 )),
lan tokenring 0 shared=n ,protocl=s4
source-bridge 300 1 100
adapter 0 4000.7513.0001 iodevice address= ( 110,16 ) ,
cunumbr=( 000e ),
unit=ctc

VTAM Configuration
vbuild type=xca
port adapno= 0 ,cuaddr= 110,
sapaddr=04, medium=ring
group answer=no, autogen=(25,I,p),
call=inout,dial=yes

Scenario 1: Single CIP to Single Host

The first scenario is a network that replaces a FEP with a CIP. As shown in Figure 3-5, there is a
single mainframe in this network. Historically, IBM SNA networks were built using the IBM FEP,
and remote terminals were connected via SDLC links. In the Before scenario, a second FEP was in
place for backup only.
In the After scenario, one FEP has been replaced with a channel-attached router with a CIP. Both the
CIP and the remaining FEP have the same MAC address. Eventually the second FEP will also be
replaced, but for now it provides SNI connectivity to a supplier and can also function as a backup to
the CIP. DLSw+ is used to transport SNA traffic from remote sites to the central site.
Once data reaches the headquarters site, DLSw+ sends most traffic to the CIP, which will typically
be the first to respond to explorers, but in the event that the CIP is not available, the FEP is
automatically used.

Migration Scenarios 3-5

Scenario 1: Single CIP to Single Host

Figure 3-5 Single CIP to Single Host

Before

Cluster Controller

Token
Host A
Ring

Cluster Controller

After

Cluster
Controller CIP Router A

Token
Ring

Cluster
Controller
Host A

Reasons for Change

The FEP was at capacity and the customer preferred to use their information services dollars on
technology that would carry them into the future as well as address today’s requirement. In addition,
the Cisco channel-attached router replacing the leased FEP would pay for itself in 18 months—with
savings coming from lease costs and monthly NCP licensing costs. Migrating from an SDLC/FEP
network to a LAN/channel-attached router network simplified SNA system configuration
significantly and reduced the downtime for planned outages. Finally, the customer planned to use
TCP mainframe applications in the near future and wanted to build an infrastructure that enabled
them to do that.

Design Choices
This customer opted to combine SNA functionality (DLSw+) and WAN connections in the CIP
router, because the network was very small (25 sites). The design provides a very safe fallback to the
FEP, but at the same time enables SRB dynamics and configuration simplicity.

3-6 Data Center Design and Implementation: SNA Internetworking

 Scenario 2: Redundant CIP to Single Host

Configuration
XCA Major Node Configuration
XCANODE VBUILD TYPE=XCA
PRTNODE PORT ADAPNO=0,CUADDR=770,SAPADDR=04,MEDIUM=RING,TIMER=30
*
GRPNODE GROUP ANSWER=ON, X
AUTOGEN=(100,L,P), X
CALL=INOUT, X
DIAL=YES, X
ISTATUS=ACTIVE

Router Configuration
!
source-bridge ring-group 100
!
interface tokenring 1/0
no ip address
no ip route-cache
ring-speed 16
source-bridge 200 1 100
!
interface Channel1/0
no ip address
csna 0100 70
!
interface Channel1/2
no ip address
no keepalive
lan TokenRing 0
source-bridge 300 1 100
adapter 0 4000.7000.0001
!
end

Implementation Overview
The first step is to implement DLSw+ from the remote site to the central site and to change the FEP
access from SDLC to Token Ring. As part of this step, configure the VTAM switched major nodes.
Once that is done, the following steps enable the CIP in this configuration:
Step 1 Perform IOCP generations to configure the channel definitions, as shown in either
Figure 3-3 or Figure 3-4.
Step 2 Configure VTAM XCA major node.
Step 3 Configure the attached router with the CIP definitions and bridge traffic from the internal
ring group to the CIP virtual ring.
Step 4 Vary the channel online (Vary E00,ONLINE).
Step 5 Confirm the CIP is online (Display U,,,E00,1).
Step 6 Activate the VTAM XCA (Vary NET,ACT,ID=name_of_member).

Scenario 2: Redundant CIP to Single Host

Initially this site had a 3745-410 running in twin-standby mode to provide better network resiliency.
In this case there is one active NCP while the second one is in standby mode. The second NCP takes
over only if the first NCP has problems. This allows quick recovery from storage-related failures and
Migration Scenarios 3-7
Scenario 2: Redundant CIP to Single Host

from a CCU hardware check. Note that the idle CCU is totally inactive unless a failure is detected.
With the inclusion of duplicate Token Ring, addressing this design can also provide another level of
network redundancy.
Optionally, the 3745-410 could be configured in twin-backup mode, where each CCU controls
approximately half the network. It is the equivalent of having two 210s running at half capacity. If
there is a failure in one CCU, the other CCU can take over, just as in the first example. However,
only half the resources are impacted and hence recovery is faster.
Irrespective of the configuration in use, the use of CSNA on two Cisco 7500 series routers with one
or more CIP cards can provide better load sharing and redundancy features, as described in the
previous chapter in the section titled “Designing for High Availability.”
The After scenario is designed so there is no single point of failure in the network. The redundant
CIP to a single host scenario is often used when the end systems cannot afford the downtime of a
failure. For many companies that require online access to provide 24 by 7 customer support, the loss
of host access for even a short period of time can incur a significant loss in both income and
credibility. It is important for these networks to implement a solution that will avoid or minimize the
amount of downtime due to network problems.
Also for these companies the redundancy option provides the necessary network configuration to
perform maintenance or configuration changes to the network with minimal impact to the
end-system users.
Providing redundancy to the single CIP to single host solution is quite straightforward. In Figure 3-6,
two Cisco 7500 routers, each with a CIP, are deployed in place of the 3745-410. In this example both
CIPs have the same virtual MAC address. When one router is not available, the SNA end system will
automatically find the backup router using standard SRB protocols. Note that in both the Before and
the After networks, loss of a channel-attached gateway is disruptive.

Figure 3-6 Redundant CIPs to Single Host

Before

4700s with DLSw+

3745-410
Token (Twin-Standby Mode)
Ring

Token
Ring

After

4700s with DLSw+ 7000/7500

Token
Ring

Token
Ring

7000/7500

3-8 Data Center Design and Implementation: SNA Internetworking

 Scenario 2: Redundant CIP to Single Host

Reasons for Change

The 3745-410 did not have the capacity to support the entire network if one of the processors was
down. During outages, the entire network slowed down. To address this problem with more FEPs
was not cost-effective. In addition, this enterprise was considering migrating their campus to FDDI,
which the 3745 does not support. With the Cisco channel-attached routers, they could migrate their
campus to either FDDI or ATM in the future.

Design Choices
In this network they opted to separate DLSw+ from the channel-attached router. This minimizes both
scheduled and unscheduled outages in their network. Also, they already had DLSw+ installed in
these routers before they installed the CIPs. Hence, this simplified migration. Finally, as their
DLSw+ routers (Cisco 4700s) reach capacity, it is less costly to add a Cisco 4700 router than a Cisco
7500 with a CIP. Either of the channel-attached routers can handle their entire capacity today, and if
the network grows, they have sufficient slots in their 7500s to add CIPs to their channel-attached
routers.
The network uses load balancing across central site DLSw+ routers and duplicate Token Rings to
ensure there is no single point of failure, as shown in Figure 3-7.

Figure 3-7 Dual Routers with Duplicate MACs

Channel Channel
RTRA Adapter Adapter RTRB
CIP CIP
4000.0000.0001 4000.0000.0001

Virtual Virtual
Ring Ring
300 400

Virtual Virtual
Ring Ring
100 101

Token Ring Interface Processor Token Ring Interface Processor

4000.7123.FF01 4000.7123.FF02 4000.7123.FF03 4000.7123.FF04

Ring 200
Dual Apex Rings
Ring 201

DLSw+ DLSw+

Migration Scenarios 3-9

Scenario 3: Single CIP to Multiple Host

Router Configuration
This configuration uses the same MAC address on internal Token Ring LANs of two different
routers.
RTRA
!
source-bridge ring-group 100
int tok 0/0
source-bridge 200 1 100
int tok 0/1
source-bridge 201 2 100
!
interface Channel1/0
no ip address
csna 0100 70
!
lan TokenRing 0
source-bridge 300 1 100
adapter 0 4000.0000.0001
!

RTRB
!
source-bridge ring-group 101
int tok 0/0
source-bridge 200 1 101
int tok 0/1
source-bridge 201 2 101
!
interface Channel1/0
no ip address
csna 0100 80
!
lan TokenRing 0
source-bridge 400 1 101
adapter 0 4000.0000.0001
!

Scenario 3: Single CIP to Multiple Host

This scenario shows a legacy SNA network with several remote sites connected via SDLC links to
cluster controllers. Also, a high-speed line was connected to a remote 3745 at a site that demanded
high-speed connection back to the mainframe and had more remote users than a cluster controller
could support. This enterprise also had a separate multiprotocol network running in parallel.
At the data center, there are two VTAMs. One is used primarily for production and the other used
primarily for testing. There is little, if any, cross-domain routing. Figure 3-8 shows the Before and
After networks.

3-10 Data Center Design and Implementation: SNA Internetworking

 Scenario 3: Single CIP to Multiple Host

Figure 3-8 Replacing a Single FEP with a Channel-Attached Router

Before

Token
Ring

After

7000/7500

Token
Ring

Reasons for Change

The primary reasons for change were to minimize costs and increase throughput and flexibility. The
remote 3745 was replaced with a lower-cost Cisco 4500 router to eliminate recurring NCP and
maintenance charges, consolidate multiprotocol and SNA WAN traffic, and simplify network
configuration. The central site FEP was replaced with a channel-attached router to increase channel
throughput and to enable TCP/IP on the mainframe in the future.

Design Choices
This enterprise chose not to implement APPN even though they had multiple mainframes. The
reason is that all SNA sessions were in the same domain. The VTAM in the second mainframe was
simply used for testing and backup. They chose not to implement two channel-attached routers for
redundancy, but they did select to use two CIPs in a single channel-attached router. This created
higher availability than they had previously, and provided an option in the future to separate CIP

Migration Scenarios 3-11

Scenario 3: Single CIP to Multiple Host

functionality across multiple CIPs. In the future they plan to add TN3270 server capability to the CIP
to allow access to VTAM applications from Web-based clients, and they also anticipate a need for
TCP/IP on the mainframe. Figure 3-9 shows the logical configuration.

Figure 3-9 Dual CIPs in a Single Router

CIP CIP
LLC2 LLC2
502 505
4000.3745.5001 4000.3745.5001

Virtual
Ring
501

Token Ring Interface Processor

4000.7123.FF01 4000.7123.FF02

Ring 200

Ring 201

Router Configuration
!
source-bridge ring-group 501
int tok 0/0
source-bridge 200 1 501
int tok 0/1
source-bridge 201 2 501
!
interface Channel1/0
no ip address
csna 0100 70
!
interface Channel1/1
no ip address
csna 0101 80
!
interface Channel1/2
no ip address
no keepalive
lan TokenRing 0
source-bridge 502 1 501
adapter 0 4000.3745.5001
lan TokenRing 1
source-bridge 505 1 501
adapter 1 4000.3745.5001
!

3-12 Data Center Design and Implementation: SNA Internetworking

 Scenario 4: Migrating to APPN

Scenario 4: Migrating to APPN

In the Before environment, the FEP provided SNA routing. The FEP can be replaced without loss of
function by implementing APPN in a channel-attached router. APPN was being considered for this
data center even if the FEP were not being replaced. Recent enhancements to VTAM’s APPN
implementation simplify network definition and enhance availability.
This scenario shows the replacement of the FEP with a Cisco router running APPN/DLUR. One host
is configured as an NN and the other as an EN. The NN provides NN server function for the EN and
provides DLUS functionality. Figure 3-10 illustrates this scenario.

Note For more detail on APPN, refer to the Cisco APPN Design and Implementation guide.

Figure 3-10 APPN Scenario

Before

Token 3745-410
Ring

Token
Ring

After

4700s with DLUR 7000/7500

Token
Ring

Token
Ring

7000/7500

Reasons for Change

This enterprise was interested in simplifying their SNA network and reducing their FEP dependency
to reduce costs. They also wanted to improve throughput at the data center. Although they were
starting with APPN/ISR routing, they intend to migrate to HPR in the future. With HPR, loss of a
channel gateway, LAN adapter, or channel adapter can be dynamically recovered without disrupting
end-user sessions.

Design Choices
This enterprise chose to put DLUR functionality in their existing data center routers to maximize the
scalability of their channel-attached routers and minimize the cost of their total network. In addition,
when they migrate to HPR, this design will allow them to nondisruptively reroute around the failure
of a channel-attached router by configuring the channel-attached router as an ANR node.

Migration Scenarios 3-13

APPN in a Parallel Sysplex Environment

Router Configuration
This partial router configuration shows that there are three required parameters and one optional
parameter for defining an APPN connection. Refer to the VTAM configuration manuals for more
details on the changes required to VTAM.
The APPN CONTROL-POINT command is used to identify the router.
The LINK-STATION defines the connection to the router. (This statement is required in at least one
of two APPN nodes connected over a link.)
The PORT defines a point of connection into the APPN network.
The APPN ROUTING command is optional and will automatically start APPN routing when the
router is started.

4700 Router Configuration

version 11.0
!
hostname RTRA
!
enable password cisco
!
appn control-point NETA.RTRA
dlus NETA.VTAMA
dlur
complete
!

!
appn link-station linkA
complete
!
appn port porta dlsw
complete
!
appn routing
!
end

APPN in a Parallel Sysplex Environment

APPN is required in VTAM, at a minimum, in order to take advantage of a Parallel Sysplex
environment. In the Before picture illustrated in Figure 3-11, APPN is implemented in each VTAM
host, while the FEPs and the rest of the network continue to use subarea protocols. This environment
allows SNA sessions to take advantage of generic resources. The Generic Resource feature of
VTAM enables end-user sessions to be dynamically spread across alternate, identical images of an
application. The end user logs on to a generic resource (for example, CICS), and the CMC host
(which is also an ICN) establishes the session with a specific application (perhaps CICS01) running
in one of the migration data hosts. The CMC/ICN balances CICS sessions across all the sysplex
processors, and recovery from the failure of any single processor is disruptive but dynamic. In
VTAM V4R4 and the latest CICS, this recovery will be nondisruptive, using a facility know as
Multi-Node Persistent Sessions (MNPS).
In the After picture shown in Figure 3-11, data center routers provide DLUR function for legacy
traffic. The Cisco channel-attached router can handle the capacity of multiple FEPs, so there are only
two channel-attached routers in the After picture. The DLUR function was installed in existing data

3-14 Data Center Design and Implementation: SNA Internetworking

 Scenario 5: Migrating from SNI to APPN

center routers to maximize scalability and availability. The DLUR router routes traffic directly to the
correct migration data host using APPN routing. (In the After picture, if there were really no FEPs,
you could convert the ICNs to NNs and the MDHs to ENs.)

Figure 3-11 Parallel Sysplex Environment

Before CMC1 /ICN1 MDH 1

APPN MDH 2 1CN2/CMC2

ESCON Coupling
Director Facility

ICN1/DLUS MDH1 MDH2 ICN2 / DLUS (Backup)

After

ESCON Coupling
Director Facility

APPN

NN/DLUR NN/DLUR

Scenario 5: Migrating from SNI to APPN

In the Before environment, Enterprise A connected to a value-added network over a back-to-back
SNI connection. Enterprise A had a small network with a single FEP. They wanted to eliminate the
FEP, but they were using it for SNI.
In the After environment, the FEP in Enterprise A has been replaced with a Cisco channel-attached
router. In the first phase, the router was configured for local DLSw+ conversion from LAN to SDLC.
In the second phase, for which the configuration in Figure 3-12 applies, APPN/DLUR functionality
was added to allow the channel-attached router to directly route all steady-state session traffic going
to the value-added network, without requiring VTAM. In the value-added network, VTAM
migrated to become an ICN. It continues to use subarea protocols for attaching to other networks,

Migration Scenarios 3-15

Scenario 5: Migrating from SNI to APPN

but uses APPN for attaching to this network. In the future, as more enterprises select this
connectivity option, the value-added network provider hopes to replace some FEPs with Cisco
channel-attached routers.

Note For more detail on APPN, refer to the Cisco APPN Design and Implementation guide.

Figure 3-12 SNI Scenario

Before
Value Added
Enterprise A Network
NETID A NETID B

SNI
Back-to-Back

SDLC
Token
Ring

Value Added
Enterprise A Network
NETID A NETID B

VTAM
VTAM Border
Network SNI Node
Node Back-to-Back /ICN CNN

SDLC

After

Reasons for Change

Enterprise A was interested in reducing their FEP costs. The value-added service provider had a
large number of FEPs supporting SNI, and by migrating one customer, they only put a small dent in
their FEP SNI traffic. However, they also recognized that as soon as one migration was successful,
they could offer this alternative to other clients. They were willing to do this for Enterprise A in the
hopes that it would allow them to migrate other customers in the future.

3-16 Data Center Design and Implementation: SNA Internetworking

 Scenario 5: Migrating from SNI to APPN

Design Choices
Enterprise A and the value-added service provider chose to use the border node (BN) function of
APPN. They selected this alternative because Enterprise A was already migrating to APPN/DLUR,
and this option gave them the most application flexibility (either session end could initiate the
connection) while at the same time providing topology independence. Additional design alternatives
for SNI are discussed in the section, “The Cisco Channel-Attached Router as a FEP Alternative” in
the chapter, “Introduction to SNA on the CIP.”

Router Configuration
The following shows the router configuration in the final phase.
interface Channel 1/0
no ip address
no keepalive
csna 0100 00

interface Channel 1/2

no ip address
no keepalive
lan TokenRing 0
source-bridge 7 1 1000
adapter 0 4000.7507.0000

interface Serial4/0
no ip address
encapsulation sdlc
no ip route-cache optimum
bandwidth 64
no keepalive
nrzi-encoding
sdlc vmac 4000.3745.0000
sdlc address 01
sdlc partner 4000.7507.0000 01
sdlc dlsw 1

appn control-point NETA.CP7507

dlus NETA.VTAMA
dlur
complete
!
appn port CIP rsrb
desired-max-send-btu-size 1500
max-rcv-btu-size 1500
retry-limit infinite
rsrb-virtual-station 4000.7507.0001 6 1 1000
complete
!
appn port SDLC0 Serial4/0
sdlc-sec-addr 02
complete
!
appn link-station VANFEP
port SLDC0
retry-limit infinite
sdlc-dest-address 0
complete
!
appn link-station VTAMA
port CIP
lan-dest-address 4000.7507.0000
retry-limit infinite

Migration Scenarios 3-17

Scenario 5: Migrating from SNI to APPN

complete
!
appn routing
!
end

3-18 Data Center Design and Implementation: SNA Internetworking