|
|
This chapter describes SNA Switching Services (SNASw), which supersedes all functionality previously available in the Advanced Peer-to-Peer Networking (APPN) feature in the Cisco IOS software. SNASw configuration will not accept the previous APPN configuration commands. Previous APPN users should use this chapter to configure APPN functionality using the new SNASw commands.
For a complete description of the SNASw commands mentioned in this chapter, refer to the "SNA Switching Services Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 2 of 2). To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
This chapter contains the following sections:
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Platform Support for Cisco IOS Software Features" section in the "Using Cisco IOS Software" chapter.
SNASw provides an easier way to design and implement networks with Systems Network Architecture (SNA) routing requirements. Previously, this network design was accomplished using APPN with full network node (NN) support in the Cisco router. This type of support provided the SNA routing functionality needed, but was inconsistent with the trends in Enterprise networks today. The corporate intranet is replacing the SNA WAN. Enterprises are replacing their traditional SNA network with an IP infrastructure that supports traffic from a variety of clients, using a variety of protocols, requiring access to applications on a variety of platforms, including SNA applications on enterprise servers.
While SNA routing is still required when multiple servers must be accessed, the number of nodes required to perform this function is decreasing as the IP infrastructure grows and as the amount of native SNA traffic in the network decreases.
SNASw enables an enterprise to develop their IP infrastructure, while meeting SNA routing requirements.
SNASw provides the following SNA routing functions:
The Branch Extender (BEX) function enhances scalability and reliability of SNA routing nodes by eliminating topology updates and broadcast directory storms that can cause network instability. BEX appears as an NN to downstream end node (EN), low-entry networking (LEN) node, and PU 2.0 devices, while also appearing as an EN to upstream devices. The BEX function eliminates APPN topology and APPN broadcast search flows between SNASw nodes and the SNA data hosts in the network. This feature is key to providing a reliable turn-key installation because the network administrator no longer needs to develop in-depth knowledge of the level and characteristics of broadcast directory search and topology update traffic in the network. Such knowledge and analysis was commonly required to build successful networks utilizing NN technology without BEX.
SNASw enables BEX functionality by default. SNASw treats all defined links as BEX "uplinks" and all dynamic links created by stations connecting into SNASw as Branch Extender "downlinks." No specific configuration is necessary to enable BEX functionality.
Figure 223 illustrates the BEX functionality.
SNASw also supports the Enterprise Extender (EE) function. EE offers SNA HPR support directly over IP networks. EE also uses connectionless User Datagram Protocol (UDP) transport. SNA COS and transmission priority are maintained by mapping the transmission priority to the IP precedence and by mapping transmission priority to separate UDP port numbers, allowing the IP network to be configured based on these elements. Cisco's IP prioritization technologies, such as weighted fair queueing (WFQ), prioritize the traffic through the IP network. EE support on the IBM Communications Server for S/390 allows users to build highly reliable SNA routed networks that run natively over an IP infrastructure directly to the Enterprise servers. These network designs reduce points of failure in the network and provide reliable SNA networks.
Figure 224 illustrates the EE functionality.
SNASw contains the following usability features designed to make SNA networks easier to design and maintain:
When scaling the SNASw function to hundreds or thousands of nodes, many network administrators find that defining a unique control point (CP) name on each node generates unnecessary configuration overhead. Dynamic CP name generation offers the ability to use the Cisco IOS hostname as the SNA CP name or to generate a CP name from an IP address. These facilities reuse one SNASw configuration across many routers and eliminate the specific configuration coordination previously required to configure a unique CP name for each SNA node in the network. Administrators can still explicitly configure the CPname within the SNASw configuration.
Most SNA node implementations require specific tuning of the SNA basic transmit unit (BTU) in the configuration. SNASw analyzes the interface maximum transfer units (MTUs) of the interfaces it uses and dynamically assigns the best MTU values for that specific port. For served dependent PU 2.0 devices, SNASw uses the downstream MAXDATA value from the host and dynamically sets the SNA BTU for that device to the MAXDATA value.
SNASw can receive connect-out instructions from the IBM Communications Server for S/390. This function allows the system to dynamically connect-out to devices that are configured on the host with the appropriate connect-out definitions. This feature allows connectivity to SNA devices in the network that were traditionally configured for connect-out from the host.
 |
Note DLUR connect-out can be performed over any supported data-link type. |
Early HPR implementations failed to perform well in environments subject to packet loss (for example, Frame Relay, IP transport) and performed poorly when combined with other protocols in multiprotocol networks. SNASw implements the second-generation HPR flow-control architecture, called Responsive Mode Adaptive Rate-Based (ARB) architecture. Responsive Mode ARB addresses all the drawbacks of the earlier ARB implementation, providing faster ramp-up, better tolerance of lost frames, and better tolerance of multiprotocol traffic.
SNASw offers full control over the number of devices supported by a specific port. The max-links configuration on the SNASw port controls the number of devices that are served by this port. When the max-links limit is reached, SNASw no longer responds to test frames attempting to establish new connections. SNASw allows load sharing among different SNASw nodes that offer service to the same SNA MAC addresses.
SNASw contains the following enhanced tools for managing SNA networks:
Messages issued by SNASw are archived in a buffer log that is queried and searched at the console or transferred to a file server for analysis. Each message has a single line that identifies the nature of the event that occurred. The buffer log also maintains more detailed information about the message issued.
SNA frames entering or leaving SNASw are traced to the console or to a cyclic buffer. These frames are analyzed at the router or transferred to a file server for analysis. The trace is sent to a file server in a SNA-formatted text file or in binary format readable by existing traffic analysis applications.
The SNASw internal information is traced in binary form, offering valuable detailed internal information to Cisco support personnel. This information helps diagnose suspected defects in SNASw.
SNASw supports the following Management Information Bases (MIBs):
The CiscoWorks Blue Maps application retrieves relevant SNASw data from these MIBs and displays it in a manner that simplifies and speeds up problem isolation and resolution.
SNASw supports several connection types to serve all SNA connectivity options, including the following types:
SNASw natively supports connectivity to Token Ring, Ethernet, and FDDI networks. In this configuration mode, the MAC address used by SNASw is the locally configured or default MAC address of the interface.
Using virtual Token Ring allows SNASw access to a source-route bridging (SRB) network, which allows the following configuration:
Virtual Token Ring allows you to connect to local LAN media through SRB technology. Virtual Token Ring and SRB allow SNASw to respond to multiple MAC addresses over the same physical interface. Because there is no limit to the number of virtual Token Ring interfaces that can connect to a specific LAN, you can configure multiple MAC addresses, which respond to SNA requests over the same LAN. When using native LAN support, SNASw responds only to requests that target the MAC address configured on the local interface.
Virtual Token Ring and SRB connect SNASw to a SNA Frame Relay infrastructure. FRAS host and SRB Frame Relay are configured to connect virtual Token Ring interfaces that offer SNASw support for Frame Relay boundary access node (BAN) or boundary network node (BNN) technology.
Virtual Token Ring and SRB can be used to connect SNASw to the Channel Interface Processor (CIP) or Channel Port Adapter (CPA) in routers that support those interfaces.
SNASw uses Virtual Data-Link Control (VDLC) to connect to data-link switching plus (DLSw+) transport and local switching technologies. VDLC is used for a number of connectivity options, including the following two:
Using VDLC, SNASw gains full access to the DLSw+ transport facilities, including DLSw+ transport over IP networks, DLSw+ transport over direct interfaces, and DLSw+ support of direct Frame Relay encapsulation (without using IP).
Through VDLC, SNASw gains access to devices connecting through synchronous data link control (SDLC) and qualified logical link control (QLLC). This access allows devices connecting through SDLC and QLLC access to SNASw.
SNASw provides the following benefits:
With the BEX function, the number of network nodes and the amount of broadcast traffic are reduced.
Limiting SNASw routers to the data center and using the BEX function eliminates SNA broadcasts from the IP network. With EE, SNA traffic is routed using the IP routing infrastructure while maintaining end-to-end SNA services.
By eliminating NNs and using the BEX function, configuration tasks are minimized. Additionally, Cisco has enhanced its auto-configuration capability to eliminate previously required commands.
By placing all SNA routers in the data center, fewer SNA routers are required, and they can be easily configured using virtually identical configurations.
By adding Cisco-unique capabilities to connect-out and distribute traffic across multiple ports, access to resources is improved. Additionally, by supporting the newest HPR ARB flow control algorithm, bandwidth management for SNA traffic is improved.
Two new traces, interprocess and data-link, provide an easier way to view SNASw activity. The APPN Trap MIB allows the user to notify the operator in event of a debilitating problem. Console message archiving provides better tracking of network activity. The ability to format traces so that they are readable by other management products simplifies network management because results are more readily available.
SNASw interfaces with SNA implementations on the market: upstream NNs, ENs, LENs and PU 2.0. It also provides full DLUR support to allow dependent PU and LU traffic to flow over the APPN network to SNA data hosts.
See the "SNASw Configuration Examples" section for examples.
To define an SNASw CP name, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router#snasw cpname {netid.cpname | netid [hostname | ip-address interface-name]} | Defines an SNASw CP name. |
|
Note Configuring a CP name activates SNASw. Conversely, removing a CP name definition deactivates it. |
If you plan to provide services to dependent LUs connecting to this SNASw node, you will be using the DLUR functionality within SNASw. SNASw defaults to using its current active upstream Network Node Server (NNS) as the preferred Dependent LU Server (DLUS) for the node. To override this default and explicitly configure the DLUS name, configure the snasw dlus command. In addition, you can configure node-wide defaults for the DLUS and backup DLUS that this node contacts.
To specify DLUR or DLUS services for this CP name, use the following command in SNASw control point configuration mode:
| Command | Purpose |
|---|---|
Router#snasw dlus primary-dlus-name [backup backup-dlus-name] [prefer-active] [retry interval count] | Specifies the parameters related to DLUR/DLUS functionality. |
There are several ways that SNASw enables connectivity over different interface types. In the simplest cases, using automatically configured real LAN interfaces enables default interface definitions. SNASw is also capable of connecting to virtual interfaces that are not preconfigured on the router.
Virtual Token Ring interfaces are useful for connections to a CIP/CPA in the same router and for connectivity to Frame Relay transport solutions via SRB. Multiple virtual Token Ring interfaces allow SNASw to respond to multiple MAC addresses through the same real router LAN interface. Use the following commands to configure a virtual interface:
| Command | Purpose | |
|---|---|---|
Step 1 | Router#interface virtual-tokenring number | Configures a virtual Token Ring interface to connect to an SRB infrastructure. |
Step 2 | Router#source-bridge vring bridge ring-group | Associates a virtual Token Ring interface with a source-route bridge group. |
Step 3 | Router#source-bridge spanning | Indicates this interface should respond to spanning-tree explorers. |
Step 4 | Router#mac-address mac-address | Configures a MAC address on a real or virtual LAN interface. |
A port can also be associated with the VDLC or HPR/IP features. The VDLC feature enables SNASw to send and receive traffic to other Cisco IOS software features such as DLSw+. If a port is associated with a VDLC interface, that port does not take an interface name as generally required by the snasw port command.
The HPR/IP feature establishes SNASw links over IP networks. If a port is associated with an HPR/IP interface, then you must configure the hpr-ip keyword first, followed by the interface name.
To associate a port with a specific interface, use the following command in global configuration mode:
|
Note SNASw ports do not dynamically adjust to interface configuration changes that are made when
SNASw is active. For example, if you change an interface MAC address or MTU, SNASw may not
recognize the new value. If you want to make changes to an interface and want SNASw to adjust to
the new interface changes, you may need to either delete and redefine the port that is using that
interface or stop and restart SNASw. The interface must be defined before the ports that use them are defined and activated. SNASw does not support EtherChannel interfaces (neither port-channel interfaces nor Fast Ethernet interfaces configured with the channel-group command). Do not try to configure a SNASw port with either of these EtherChannel interface types. |
 |
Caution Changing active SNASw interfaces might interrupt SNASw connections. |
In many cases, if the destination LU is initiating the connection, a link definition is not necessary. A link definition is built dynamically when the destination LU initiates the connection. Links typically need to be defined for upstream connectivity. Downstream devices initiate connectivity into SNASw; therefore, links should not be defined on SNASw to downstream devices.
In SNASw link configuration, you must associate the link with the SNASw port that it will use. For all traditional links, the snasw link command must be associated with a remote MAC address. The MAC address identifies the partner address to which SNASw attempts to establish a link. For all HPR/IP links, the command is associated with a remote IP address. The IP address identifies the partner address to which SNASw attempts to establish a link.
To define an SNASw logical link, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router#snasw link linkname port portname [rmac mac-address | ip-dest ip-address] [rsap sap-value] [nns] [tgp [high | low | medium]] [nostart] | Defines an SNASw logical link. |
When a LEN node connects into an SNASw node, SNASw dynamically learns the CP name of the LEN and places it in its directory. In addition, SNASw dynamically learns the LU names of all LUs on the LEN that initiate independent sessions. Only define the location when an ILU on a LEN device is not sharing the node's CP name and does not initiate the first session. In all other cases the LU's location will be learned dynamically.
The directory entry is created the next time the LEN node connects in. If there is already a link to the LEN node active and you add a new snasw location statement, it will not take effect until the next time the LEN CP connects in.
To define a resource location, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router#snasw location resource-name owning-cp cpname | Configures the location of a resource. |
|
Note You must configure an owning CP for each partner LU configured. The owning CP is the CP name for the LEN node on which the partner resource resides. Location definitions are never required for resources located on APPN ENs or NNs. |
Unless otherwise defined with the nostart operand, SNASw starts automatically when a CP name is configured, and SNASw ports and links are also automatically started once they are configured. If stopped, they can be restarted using one of the following privileged EXEC commands, as needed:
| Command | Purpose |
|---|---|
Router#snasw start | Starts SNASw. |
Router#snasw start link linkname | Activates the specified SNASw link. |
Router#snasw start port portname | Activates the specified SNASw port. |
Unless otherwise defined with the nostart operand, SNASw and SNASw port and link definitions are started automatically when SNASw starts. To stop SNASw or to stop SNASw ports and links when making configuration changes or when resetting the ports or links, use one of the following commands in privileged EXEC mode, as needed:
| Command | Purpose |
|---|---|
Router#snasw stop | Deactivates SNASw. |
Router#snasw stop link linkname | Deactivates the specified SNASw link. |
Router#snasw stop port portname | Deactivates the specified SNASw port. |
|
Note Removing a CP name definition stops SNASw. |
You can monitor the status and configuration of SNASw by issuing any of the following commands in privileged EXEC mode:
You can troubleshoot SNASw by issuing any of the following commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
Router#ping sna [-1] [-c consecutive packets] [-i number-iterations] [-m mode] [-n] [-r] [-s size][-t tpname] [-u userid -p password] destination | Initiates an APPC session with a named destination LU to run the APING transaction program to check network integrity and timing characteristics. |
Router#show snasw dlctrace [all | last | next] [brief | detail] [filter filter-string] [id recordid] | Displays the captured DLC trace information to the console. |
Router#show snasw ipstrace [all | next | last] [filter filterstring] [id recordid] | Displays interprocess signal trace on the router console. |
Router#show snasw pdlog [brief | detail] [all] [last] [next] [filter filterstring] [id recordid] | Displays entries in the cyclical problem determination log to the console. |
Router#show snasw summary-ipstrace [id recordid] [last number-records | filter number-records | all | next | last] | Displays the special "footprint" summary interprocess signal trace on the router console. |
Router#snasw dump | Initiates file transfer of SNASw trace files from internal buffers to a file server. |
Router#snasw pathswitch [rtp-connection-name | all] | Forces an HPR pathswitch for an RTP connection. |
You can also troubleshoot SNASw by issuing any of the following commands in global configuration mode:
This section provides the following configuration examples:
Figure 225 illustrates a basic SNASw link over Token Ring without HPR. In this figure, Port TOK0 is used for upstream links toward the host, and Port TOK1 is used for downstream devices connecting to SNASw. These devices are configured to connect to 4000.1234.abcd. The conntype nohpr operand is designed to turn off HPR capabilities on upstream and downstream links.
|
Note In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw over Token Ring without HPR is as follows:
interface TokenRing0/0 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache ring-speed 16 interface TokenRing0/1 mac-address 4000.1234.abcd no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache ring-speed 16 snasw cpname NETA.ROUTERCP snasw dlus NETA.HOSTCMC1 backup NETA.HOSTCMC2 snasw port TOK0 TokenRing0/0 conntype nohpr snasw port TOK1 TokenRing0/1 conntype nohpr snasw link HOSTCMC1 port TOK0 rmac 4000.aaaa.cccc snasw link HOSTCMC2 port TOK0 rmac 4000.aaaa.dddd
Figure 226 illustrates a basic SNASw link over Token Ring with HPR support. In this figure, Port TOK0 is used for upstream links toward the host, and Port TOK1 is used for downstream devices connecting to SNASw. These devices are configured to connect to 4000.1234.abcd.
|
Note In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw over Token Ring allowing HPR is as follows:
interface TokenRing0/0 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache ring-speed 16 interface TokenRing0/1 mac-address 4000.1234.abcd no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache ring-speed 16 snasw cpname NETA.ROUTERCP snasw dlus NETA.HOSTCMC1 backup NETA.HOSTCMC2 snasw port TOK0 TokenRing0/0 snasw port TOK1 TokenRing0/1 snasw link HOSTCMC1 port TOK0 rmac 4000.aaaa.cccc snasw link HOSTCMC2 port TOK0 rmac 4000.aaaa.dddd
In Figure 227, SNASw co-exists with CSNA CIP channel support in the same router. Two adapters are opened on the CIP, one from HOSTCMC1 on adapter 1 and one from HOSTCMC2 on adapter 2. SNASw is configured to connect these two hosts through port CIP via the SRB infrastructure. In addition, SNASw has two ports configured for downstream devices. Using this configuration, SNASw responds to downstream clients connecting to 4000.1234.1088 and 4000.1234.1089 through a single Token Ring interface (Token Ring 0/0). The router's hostname is used to derive an SNASw CP name, which is NETA.SNASWRT1.
|
Note In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw connecting to a CIP over virtual Token Ring with SRB is as follows:
hostname snaswrt1 ! source-bridge ring-group 100 source-bridge ring-group 200 ! interface Channel2/1 no ip address no keepalive csna E040 70 csna E020 72 ! interface Channel2/2 no ip address no keepalive lan TokenRing 0 source-bridge 101 1 100 adapter 0 4000.0000.cccc adapter 1 4000.0000.dddd ! interface TokenRing0/0 no ip address ring-speed 16 source-bridge 201 1 200 source-bridge spanning ! interface Virtual-TokenRing0 no ip address no ip directed-broadcast ring-speed 16 source-bridge 102 1 100 source-bridge spanning ! interface Virtual-TokenRing1 mac-address 4000.1234.1088 no ip address no ip directed-broadcast ring-speed 16 source-bridge 202 1 200 source-bridge spanning ! interface Virtual-TokenRing2 mac-address 4000.1234.1089 no ip address no ip directed-broadcast ring-speed 16 source-bridge 203 1 200 ! snasw cpname NETA hostname snasw dlus NETA.HOSTCMC1 backup NETA.HOSTCMC2 snasw port CIP Virtual-TokenRing0 snasw port DOWNSTRM Virtual-TokenRing1 conntype no-hpr snasw port DOWNSTRM Virtual-TokenRing2 conntype no-hpr snasw link HOSTCMC1 port CIP rmac 4000.0000.cccc snasw link HOSTCMC2 port CIP rmac 4000.0000.dddd
Figure 228 illustrates a basic SNASw link over HPR/IP on the upstream connections to the host. The downstream devices connect through Token Ring 0/0.
|
Note In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw over HPR/IP is as follows:
interface Ethernet1/0 ip address 172.18.49.28 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface TokenRing0/0 mac-address 4000.1234.1088 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache ring-speed 16 ! snasw cpname NETA.ROUTERCP snasw dlus NETA.HOSTCMC1 backup NETA.CMCHOST2 snasw port HPRIP hpr-ip Ethernet1/0 snasw port TOK0 TokenRing0/0 snasw link HOSTCMC1 port HPRIP ip-dest 172.18.51.1 snasw link HOSTCMC2 port HPRIP ip-dest 172.18.51.2
Figure 229 illustrates a basic SNASw link using local switching with QLLC.
|
Note This figure and example show only the configuration related to the downstream QLLC device.
Upstream connectivity is not shown in this configuration. In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw link using Local Switching with QLLC is as follows:
! source-bridge ring-group 70 dlsw local-peer ! interface Serial4/0 no ip address no ip directed-broadcast encapsulation x25 no ip mroute-cache no keepalive qllc accept-all-calls clockrate 19200 qllc dlsw vmacaddr 4000.1111.1111 partner 4000.2222.2222 ! snasw cpname NETA.ROUTERCP snasw port VDLCP vdlc 70 mac 4000.2222.2222 conntype nohpr
Figure 230 illustrates a basic SNASw link using local switching with SDLC.
|
Note This figure and example show only the configuration related to the downstream SDLC device.
Upstream connectivity is not shown in this configuration. In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw link using local switching with SDLC is as follows:
! source-bridge ring-group 1689 dlsw local-peer ! interface Serial1 no ip address no ip directed-broadcast encapsulation sdlc no ip route-cache no ip mroute-cache no keepalive clockrate 9600 sdlc role primary sdlc vmac 4000.3174.0000 sdlc address C2 sdlc sdlc-largest-frame C2 521 sdlc xid C2 05DABBBA sdlc partner 4000.4500.00f0 C2 sdlc dlsw C2 ! snasw cpname NETA.ROUTERCO snasw port SDLC vdlc 1689 mac 4000.4500.00f0
In Figure 231, downstream devices connect in SNASw over Asynchronous Transfer Mode (ATM) Ethernet LANE. Upstream connectivity is achieved using DLSw+ for connections to the host systems. Downstream devices connect to the standby MAC address on the ATM sub-interface.
|
Note In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw with Ethernet LANE over ATM is as follows:
! source-bridge ring-group 111 dlsw local-peer peer-id 10.56.56.1 keepalive 10 promiscuous dlsw remote-peer 0 tcp 10.56.56.2 ! interface ATM2/0 mtu 1500 no ip address no ip directed-broadcast atm clock INTERNAL atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi atm pvc 60 1 36 aal5nlpid no atm ilmi-keepalive ! interface ATM2/0.1 multipoint no ip directed-broadcast lane client ethernet RED no cdp enable !
interface ATM2/0.2 multipoint ip address 10.10.50.60 255.255.255.0 no ip redirects no ip directed-broadcast lane client ethernet BLUE no cdp enable standby 1 priority 200 preempt standby 1 authentication xxxx standby 1 mac-address 000b.e291.0000 standby 1 ip 10.10.50.70 ! interface Serial3/1 ip address 10.56.56.1 255.255.255.0 no ip directed-broadcast encapsulation ppp no keepalive no fair-queue clockrate 56000 ! snasw cpname NETA.ROUTERCP snasw dlus NETA.SJMVS3 backup NETA.HOSTCMC2 snasw port ATM202 ATM2/0.2 conntype nohpr snasw port DLSWP vdlc 111 mac 4000.0189.0016 conntype nohpr snasw link HOSTCMC1 port DLSWP rmac 4000.aaaa.cccc snasw link HOSTCMC2 port DLSWP rmac 4000.aaaa.dddd !
Figure 232 illustrates how to combine SNASw and SRB over Frame Relay functionality to provide native RFC 1490 connectivity over Frame Relay BAN. The host is configured to respond to 4000.aaaa.cccc through the Frame Relay connection over Serial1. Downstream would be configured to connect into Virtual TokenRing0.
|
Note In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration for SNASw with SRB Frame Relay (Frame Relay BAN Support) is as follows:
source-bridge ring-group 100 source-bridge ring-group 200 ! interface TokenRing0 no ip address no ip directed-broadcast ring-speed 16 source-bridge 202 1 200 ! interface Virtual-TokenRing0 mac-address 4000.1234.1001 no ip address no ip directed-broadcast ring-speed 16 source-bridge 201 1 200 ! interface Serial1 encapsulation frame-relay ! interface serial 1.1 point-to-point frame-relay interface-dlci 30 ietf source-bridge 101 1 100 ! interface Virtual-TokenRing1 mac-address 4000.1111.2222 no ip address no ip directed-broadcast ring-speed 16 source-bridge 102 1 100 source-bridge spanning ! snasw cpname NETA.ROUTERCP snasw port frame virtual tokenring 1 conntype nohpr snasw link HOSTFRAM port FRAME rmac 4000.aaaa.cccc
On the CIP router, configure the following:
source-bridge ring-group 300 interface serial 1/0 encapsulation frame-relay ! interface serial 1/0.1 point-to-point frame-relay interface 30 ieft source-bridge 101 1 300 ! interface channel 2/1 no ip-address no keep alive csna E040 70 !
interface serial channel 2/2 no ip-address no keep alive lan tokenring 0 source-bridge 301 1 300 adapter 0 4000.aaaa.cccc
Figure 233 illustrates how to connect a downstream Frame Relay BNN device (Frame Relay Access Device) over native RFC 1490 in SNASw.
|
Note This figure and example show only the configuration related to downstream Frame Relay BNN
Support. Upstream connectivity is not shown in this configuration segment. In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
The configuration SNASw with FRAS Host (Downstream Frame Relay BNN Support) is as follows:
source-bridge ring-group 200 interface serial 1/2 no ip-address encapsulation frame-relay letf frame-relay map llc2 17 ! interface virtual-tokenring 0 mac-address 4000.1234.1001 ring-speed 16 source-bridge 201 1 200 ! interface virtual-tokenring 1 ring-speed 16 source-bridge 202 1 200 fras-host bnn serial 1/2 fr-lsap 04 umac 4000.1234.2002 hmac 4000.1234.1001
The following section compares the configuration of SNASw vs APPN connecting VTAM to the CIP using CMPC.
|
Note SNASw supersedes all functionality previously available in the APPN feature in the Cisco IOS
software. SNASw configuration will not accept the previous APPN configuration commands and
APPN is no longer supported. Previous APPN users should use this chapter to configure APPN
functionality using the new SNASw commands. In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
Figure 234 illustrates the VTAM connecting to SNASw on the CIP using CMPC.
Configuration for TRL Node LAGTRLB
LAGTRB VBUILD TYPE=TRL
LAGTRLB TRLE LNCTL=MPC,MAXBFRU=8,REPLYTO=3.0, X
READ=(2F2), X
WRITE=(2F3)
Local SNA Major Node LAGLNB
LAGNNB VBUILD TYPE=LOCAL
LAGPUB PU TRLE=LAGTRLB, X
ISTATUS=ACTIVE, X
XID=YES,CONNTYPE=APPN,CPCP=YES
Honduras Router
source-bridge ring-group 100 ! interface Channel6/1 no ip address no keepalive cmpc C020 F2 LAGUNAB READ cmpc C020 F3 LAGUNAB WRITE ! interface Channel6/2 no ip address no keepalive lan TokenRing 0 source-bridge 88 3 100 adapter 2 4000.bbbb.bbbb lan TokenRing 2 tg LAGUNAB llc token-adapter 2 20 rmac 4000.0000.bbbb rsap 24 ! ! interface Virtual-TokenRing0 mac-address 4000.0000.bbbb no ip address no ip directed-broadcast ring-speed 16 source-bridge 61 2 100 ! snasw cpname NETA.HONDURAS snasw port VTOK Virtual-TokenRing0 snasw link MVS2D port VTOK rmac 4000.bbbb.bbbb
By comparison, Figure 235 illustrates the VTAM connecting to the APPN NN on the CIP using CMPC.
Configuration for TRL Node LAGTRLB
LAGTRB VBUILD TYPE=TRL
LAGTRLB TRLE LNCTL=MPC,MAXBFRU=8,REPLYTO=3.0, X
READ=(2F2), X
WRITE=(2F3)
Local SNA Major Node LAGLNB
LAGNNB VBUILD TYPE=LOCAL
LAGPUB PU TRLE=LAGTRLB, X
ISTATUS=ACTIVE, X
XID=YES,CONNTYPE=APPN,CPCP=YES
Honduras Router
interface Channel6/1
no ip address
no keepalive
cmpc C020 F2 LAGUNAB READ
cmpc C020 F3 LAGUNAB WRITE
!
interface Channel6/2
no ip address
no keepalive
lan TokenRing 0
source-bridge 88 3 100
adapter 2 4000.bbbb.bbbb
lan TokenRing 2
tg LAGUNAB llc token-adapter 2 20 rmac 4000.0000.bbbb rsap 24
!
appn control-point NETA.HONDURAS
complete
!
appn port RSRBPORT rsrb
local-sap 24
desired-max-send-btu-size 4096
max-rcv-btu-size 4096
rsrb-virtual-station 4000.0000.bbbb 61 2 100
complete
!
appn link-station LAGUNAB
port RSRBPORT
lan-dest-address 4000.0000.beef 14
complete
router eigrp 109
network 172.18.0.0
The following section compares the configurations of SNASw vs APPN while connecting to VTAM on a remote router with DLUR using CMPC.
In the example shown in Figure 236 and Figure 237, DLUS is running on the MVS host. DLUR is running on a remote Cisco 4000 router. The connection from MPC to the APPN stack on the Cisco 4000 is via LLC2. There is no NN on the Cisco 7500. The PC is running Communications Server/2.
|
Note SNASw supersedes all functionality previously available in the APPN feature in the Cisco IOS
software. SNASw configuration will not accept the previous APPN configuration commands and
APPN is no longer supported. Previous APPN users should use this chapter to configure APPN
functionality using the new SNASw commands. In a typical configuration, downstream links are not configured. Instead, the downstream device configures the connection to the SNASw router, and the SNASw router creates a dynamic link definition for the downstream links. |
Figure 236 illustrates a DLUS-to-DLUR configuration using SNASw.
mvs2trld
MVS2TRD VBUILD TYPE=TRL
MVS2TRLD TRLE LNCTL=MPC,MAXBFRU=8,REPLYTO=3.0, X
READ=(2F7), X
WRITE=(2F6)
mvs2lnd
MVS2NND VBUILD TYPE=LOCAL
MVS2PUD PU TRLE=MVS2TRLD, X
ISTATUS=ACTIVE, X
XID=YES,CONNTYPE=APPN,CPCP=YES
Additional Configuration for Router Honduras
interface Channel6/1 cmpc C020 F6 CONFIGD WRITE cmpc C020 F7 CONFIGD READ ! interface Channel6/2 lan TokenRing 0 source-bridge 88 3 100 adapter 4 4000.dddd.dddd tg CONFIGD llc token-adapter 4 40 rmac 4000.0000.dddd rsap 44
Router Dustin
source-bridge ring-group 84 interface Ethernet0 ip address 172.18.3.36 255.255.255.0 media-type 10BaseT ! interface TokenRing0 no ip address ring-speed 16 source-bridge 500 2 84 ! interface Virtual-TokenRing0 mac-address 4000.0000.dddd no ip address no ip directed-broadcast ring-speed 16 source-bridge 94 5 84 ! snasw cpname NETA.DUSTIN snasw dlus NETA.MVS2 snasw port VTOK Virtual-TokenRing0 snasw link MVS2D port VTOK rmace 4000.dddd.dddd
By comparison, Figure 237 illustrates a DLUS-to-DLUR configuration using APPN.
mvs2trld
MVS2TRD VBUILD TYPE=TRL
MVS2TRLD TRLE LNCTL=MPC,MAXBFRU=8,REPLYTO=3.0, X
READ=(2F7), X
WRITE=(2F6)
mvs2lnd
MVS2NND VBUILD TYPE=LOCAL
MVS2PUD PU TRLE=MVS2TRLD, X
ISTATUS=ACTIVE, X
XID=YES,CONNTYPE=APPN,CPCP=YES
Additional Configuration for Router Honduras
interface Channel6/1 cmpc C020 F6 CONFIGD WRITE cmpc C020 F7 CONFIGD READ ! interface Channel6/2 lan TokenRing 0 source-bridge 88 3 100 adapter 4 4000.dddd.dddd tg CONFIGD llc token-adapter 4 40 rmac 4000.0000.dddd rsap 44
Router Dustin
source-bridge ring-group 84 interface Ethernet0 ip address 172.18.3.36 255.255.255.0 media-type 10BaseT ! interface TokenRing0 no ip address ring-speed 16 source-bridge 500 2 84 ! appn control-point NETA.DUSTIN dlus NETA.MVS2 dlur complete ! appn port RSRBPORT rsrb local-sap 44 desired-max-send-btu-size 4096 max-rcv-btu-size 4096 rsrb-virtual-station 4000.0000.dddd 94 5 84 complete ! appn link-station LAGUNAD port RSRBPORT lan-dest-address 4000.0000.beef 14 complete ! appn link-station MVS2D port RSRBPORT lan-dest-address 4000.dddd.dddd 40 complete
Posted: Sat Jan 12 21:33:24 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.