|
|
This appendix provides information to help you with the setup and configuration of Cisco IOS for S/390 with Cisco 7000 and 7500 routers. It also includes the steps necessary to configure the software for use with GateD Fault Tolerant and Virtual IP Addressing (VIPA).
The following sections are included.
Once a physical connection has been established, MVS must be configured to recognize the CIP and to define a series of subchannels on which the CLAW protocol is used to communicate between Cisco IOS for S/390 and the Cisco 7000/7500 series router. This configuration is performed by adding statements to your MVS input/output configuration program (IOCP) as described in the IOGEN Information section of this manual.
In addition to MVS configuration, both Cisco IOS for S/390 and the Cisco 7000/7500 router must also be configured. The configuration for Cisco IOS for S/390 is performed by adding statements to your TCP configuration member as described in the Configuring the Interface section of this manual. This configuration defines the association between MVS and Cisco IOS for S/390, giving it access to the physical device.
The configuration for the Cisco 7000/7500 router is performed by issuing configuration commands to the router as described in the Configuring the Router section of this manual. These commands provide the final configuration necessary to complete the communications path between Cisco IOS for S/390 and the Cisco 7000/7500 router.
This guide includes information for the following configurations:
The steps provided in this guide assume the following:
For additional information, read the following documents:
Before you install Cisco IOS for S/390, you must define the hardware interfaces needed to support the product. The I/O and IOCP generations define the devices used by Cisco IOS for S/390 to access the network.
aaa | Base address. |
|---|---|
| n | Number of subchannel addresses to be defined. Refer to the appropriate IBM system generation manual for more information. |
,n),PROTOCOL=pr
,ADDRESS=(aaa,2)
pp | Channel path address. |
|---|---|
| number | Unit number. |
| aa | Base unit address. |
| aaa | Base unit address. |
| n | Number of subchannel addresses to be defined. |
| pr | One of these values:
S--3.0MB data streaming mode S4--4.5MB data streaming mode |
| aaa | Base address. |
| n | Number of subchannel addresses to be defined. Refer to the appropriate IBM system generation manual for more information. |
,ADDRESS=(aaa,2),
| pp | Channel path address. |
| number | Unit number. |
| aa | Base unit address. |
| aaa | Base unit address. |
| n | Number of subchannel addresses to be defined. Refer to the appropriate IBM system generation manual for more information. |
| c | Control Unit Address; can be 0 to F. |
This section describes the configuration changes you must make to define Cisco 7000 and 7500 series routers to work with Cisco IOS for S/390.
These are the steps necessary to configure Cisco IOS for S/390:
If you intend to use the TCP Assist feature, you must also code ASSIST on the MEDIA statement. The default is NOASSIST.
T01LL193E Device dev_name: checksum Assist feature is not supported. This message indicates that the CLAW link is unable to connect; it does not specify the reason for the failure. If your router does not support the ChecksumAssist feature, do not code ASSIST on the MEDIA statement.
The MEDIA statement is described in the "Network Configuration" chapter of the Cisco IOS for S/390 Customization Guide.
The NETWORK statement defines the IP addressing of the media.
You must define the host IP address on the NETWORK statement. This IP address will correspond to the CLAW definition for the channel interface in the Cisco 7000 or Cisco 7500 series router.
The NETWORK statement is described in the "Network Configuration" chapter of the Cisco IOS for S/390 Customization Guide.
The CLAW statement specifies configuration parameters for an interface running the CLAW protocol. You must code a CLAW statement with the starting device subchannel address for the Cisco 7000 or 7500 series router in the DEVADDR parameter of this statement. This starting subchannel address corresponds to the CLAW definition for the channel interface of the Cisco router. Additionally, the HOSTNAME and WSNAME parameters on this statement must reflect the host name and workstation name set by the CLAW definition in the router.
If you intend to use the CLAW Packing feature, you must also code PACKED on the CLAW statement. The default is UNPACKED. The CLAW definition for the channel interface in the Cisco router must also be set up for the PACKED feature (see the section Configuring the Router, later in this document).
T01LL194E Device dev_name : packetizing feature is not supported. :
T01LL198# Device dev_name : the CLAW statement does not reflect the controller
configuration PACKED option
The CLAW statement is described in the "Network Configuration" chapter of the Cisco IOS for S/390 Customization Guide.
If you have more than one CIP interface, you must define MEDIA, NETWORK and CLAW statements in the TCPCFGxx member for each interface (as described in the MEDIA Statement, NETWORK Statement, and CLAW Statement sections of this manual), and add the corresponding CLAW command (as described in the CLAW Command section of this manual).
Although there is no relationship between NETWORK and driver statements (CLAW statements), you must consider the organization of these statements under the MEDIA statement(s) for point-to-point type links such as CLAW. Cisco Claw devices have a one-to-one correspondence between the host IP address and a subchannel address pair. Once you establish a MEDIA and NETWORK statement pair, the CLAW statement of the device corresponding to the NETWORK IP address in the Cisco router must follow immediately or the MEDIANAME keyword must be coded. For ease of organization and readability, it is recommended that you code the MEDIA, NETWORK, and CLAW statements, in that order.
If you use Fault Tolerant with your Cisco routers, you must define at least two MEDIA, NETWORK, and CLAW statements that correspond to separate CIP interfaces.
In addition to CLAW configuration commands specific to a particular CLAW connection, each CIP must also receive some basic configuration. This includes a subnet and IP address for each CIP interface, as well as other basic interface configuration commands that are desirable or required for the CIP to operate correctly.
CIP interface configuration commands are to be entered at the interface configuration prompt for the corresponding physical channel connection.
For more details on configuring the CIP, refer to Bridging and IBM Networking Configuration Guide for your version of Cisco IOS for S/390.
The IP ADDRESS command assigns an IP address and associated subnet mask for a given channel interface. The IP address chosen should be within the same subnet as defined by the NETWORK statement in the TCPCFGxx member. Additionally, the mask specified on the IP ADDRESS command must match that specified in the NETWORK statement.
ip address address maskFor more information on the IP ADDRESS command, see the "IP Commands" chapter of the Network Protocols Command Reference, Part 1.
The CLAW command specifies the configuration Cisco IOS for S/390 needs to communicate with the CIP. It provides configuration information necessary to communicate through MVS and to Cisco IOS for S/390.
The parameters associated with communicating through MVS include the channel path and device address that correspond to the CTLUNIT and IODEVICE statements (described in the IOGEN Information section of this manual) in your IOCP.
claw path dev_addr ip_addr host_name dev_name host_app ws_apppath | This hexadecimal value specifies the data path and consists of two digits for the physical connection, one digit for the control unit logical address, and one digit for the channel logical address.
For configuring the CLAW statement in Cisco IOS for S/390, use the form XXHC, where: XX--For ESCON point-to-point or Bus and Tag, this is 01; for switch point-to-point configuration, it is the ESCD port number that the host channel is plugged into. H--For ESCON, this specifies the host partition number if channel path identifier (CHPID) is shared; for Bus and Tag, or non-shared ESCON CHPIDs, it is 0. C--For ESCON-defined control units, this matches the CUADD parameter of the CNTLUNIT macro in the IOCP. |
| dev_addr | Unit address associated with the control unit number and path as specified in the host IOCP file. In this case, it corresponds to the UNITADD field of the CNTLUNIT macro of the IOCP. |
| ip_addr | IP address in the HOME statement of the host TCP/IP application configuration file. In this case, it must match the IP address specified in the corresponding TCPCFGxx member NETWORK statement |
| host_name | Host name in the device statement in the host TCP/IP application configuration file. In this case, it must match the HOSTNAME(name) parameter of the corresponding TCPCFGxx member CLAW statement |
| dev_name | CLAW workstation name in the device statement in the host TCP/IP application configuration file. In this case, it must match the WSNAME( name ) parameter of the corresponding TCPCFGxx member CLAW statement.
This is an optional parameter and should be coded only if broadcast traffic is to be sent to the mainframe (in other words, the gateway dæmon (GateD) is running on the host). |
| host_app | Name of the host application for the CLAW IP link. It will be one of the following:
· TCPIP--for normal channel mode · PACKED--for PACKED channel mode |
| ws_app | Name of the workstation application for the CLAW IP link. It will be one of the following:
· TCPIP--for normal channel mode · PACKED--for PACKED channel mode |
| broadcast | Enable broadcast processing for the subchannel. |
For more information on the CLAW command, see Bridging and IBM Networking Command Reference.
The channel-protocol command defines the data rate for a Parallel Channel interface.
The value for this command corresponds to the PROTOCOL=pr parameter on the CNTLUNIT statement in the IOCP input deck (see the IOCP for Parallel Channel CIPs section of this manual).
The following commands are suggested. For more details on their purpose see Network Protocols Command Reference, Part 1. Additional information can also be found in Bridging and IBM Networking Configuration Guide.
ip route-cache same-interfaceThe GateD routing protocol lets Cisco IOS for S/390 perform some of the functions of a router in a multi-homed environment. Specify configuration parameters for GateD in the GTDCFGxx member.
To use Fault Tolerant GateD you must have at least two CIP interfaces and you must have an equal number of NETWORK and CLAW statements defined in the TCPCFGxx member. If you did not define a MEDIA statement for LOOPBACK, then you should also have the same number of MEDIA statements as NETWORK and CLAW statements.
These are the steps necessary to configure Cisco IOS for S/390 for GateD Fault Tolerant:
These statements and members are described in the "Network Configuration" chapter of the Cisco IOS for S/390 Customization Guide.
To use fault tolerant facilities with Cisco IOS for S/390, you must have at least two CIP interfaces. Within this configuration both the CIP and the MVS host could run the recommended open shortest path first (OSPF) or the Routing Information Protocol (RIP) routing protocol. If correctly configured, this ensures timely recovery in the event of a network outage.
The IP statement controls the operation of the Internet layer. To activate GateD, you must define an IP statement with the GATED parameter specifying the GTDCFGxx member. You must also code FORWARD to allow hosts on one local interface to forward to hosts on another local interface.
Use the GTDCFGxx member to specify configuration parameters for the GateD routing protocol.
The GateD configuration member is very different from most other configuration files for Cisco IOS for S/390. It consists of a sequence of statements, each terminated by a semi-colon (;). Statements are composed of tokens separated by white space (any combination of blanks, tabs, and new lines). Comments use the C style comment, which begins with a "/*" and ends with "*/".
GateD relies heavily on functions and features native to UNIX operating systems. These functions and features are emulated on MVS by Cisco IOS for S/390 or by the SAS/C runtime library. References to the UNIX kernel in this section refer to Cisco IOS for S/390 and not the MVS operating system.
For information about various function routines generally native to UNIX, read the following:
For information about initial configuration, read the "Network Customization" chapter in the Cisco IOS for S/390 Customization Guide.
The traceoptions statement controls tracing options for GateD.
traceoptions traceoption [traceoption [...]]If none is the only option specified, tracing is turned off. If except is specified, flags listed before it are turned on and flags listed after it are turned off. Use this to turn on all but a few flags.
The interfaces statement lets you specify interface options in the GTDCFGxx member.
interfaces {The options statement allows specification of global GateD options.
options [option_list];OSPF is the recommended protocol.
ospf yes | no | on | off
[ {
[ defaults
{
preference preference ;
cost cost ;
tag [ tag | as [ as_tag ] ] ;
type 1|2 ;
} ] ;
[ exportlimit routes ; ]
[ exportinterval time ; ]
[ traceoptions traceoptions ; ]
[ monitorauthkey authkey ; ]
[ area area | backbone
{
authtype 0 | 1 | none | simple ;
stub [ cost cost ];
networks { network [ mask mask ] ; } ;
stubhosts { host cost cost ; } ;
interface interface [ cost cost ]
{
[ enable | disable ] ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
} ;
interface interface nonbroadcast [ cost cost ]
{
pollinterval time ;
routers { gateway [ eligible ] ... } ;
[ enable | disable ] ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
} ;
} ; ]
virtuallink neighborid routerid transitarea area
{
[ enable | disable ] ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
} ; . . .
} ] ;
rip yes | no | on | off [
{
broadcast;
nobroadcast;
nocheckzero;
preference preference;
defaultmetric metric;
interface interface_list [noripin] [noripout]
[metricin metric] [metricout metric]
[version 1]|[version 2 broadcast]
[authentication [none|password]];
...
trustedgateways gateway_list;
sourcegateways gateway_list;
traceoptions traceoptions;
} ] ;
This section gives a brief description of configuring OSPF for your Cisco 7000 and 7500 series router. For more detail, or to configure your router for OSPF beyond what is needed for Fault Tolerance CIP support, read the Network Protocols Configuration Guide, from Cisco, for your version of IOS.
The router ospf command enables OSPF routing on your router. More specific OSPF commands will follow.
router ospf process_id
This router ospf command will be followed by more specific commands describing your OSPF network. These include the network area command, the passive-interface command, and several others, depending on the specifics of your network.
If you plan to run multiple routing protocols in the same router, you should also consider using the DEFAULT-INFORMATION ORIGINATE and REDISTRIBUTE routing commands. These are described in the Network Protocols Configuration Guide, from Cisco, for your version of IOS. OSPF commands also need to be added to the CIP interfaces of your Cisco 7000/7500 routers.
This section gives a brief description of configuring RIP for your Cisco 7000 and 7500 series router.
The router rip command enables RIP routing on your router. Specific RIP commands follow.
router ripThe network command associates a network with a RIP routing process.
network network_number
On each interface supporting RIP, you can tell the router the version of RIP supported. This allows multiple levels to be run on the router at the same time.
As with OSPF, if you are planning to run multiple routing protocols in the router, consider the redistribute and passive-interface routing commands. For more information on these, refer to the Network Protocols Configuration Guide, from Cisco, for your version of Cisco IOS for S/390.
In addition to the previous configuration, users can make use of the VIPA facility to give complete and constant access to their host data. This configuration does require that a separate subnet be defined to the CIP and in the TCPCFGxx member. Since this subnet is virtual, if a route to a real interface goes down, you do not lose access to the host if using the virtual addressing described here.
At this point, you should have a fully configured multihomed Cisco IOS for S/390 system with GateD Fault Tolerant.
These are the steps necessary to configure Cisco IOS for S/390 for GateD Fault Tolerant:
For this example, the following are true:
This diagram illustrates the Cisco IOS for S/390 Fault Tolerant example with VIPA and GateD running OSPF using two Cisco 7000 series routers with CIPs described in this section.
MEDIA VIRTUAL MTU(4096) NAME(VIRTUAL) NETWORK IPPADDRESS(170.202.1.1) SUBNET(255.255.255.0)
MEDIA CLAW NAME(CLAW1) MTU(4096) MSSDEF(4096) MSSOPT(ALWAYS) ASSIST NETWORK IPADDRESS(170.202.10.65) SUBNET(255.255.255.0) MEDIANAME(CLAW1) CLAW DEVADDR(070) BUFSIZE(4096) IBUF(26) OBUF(26) HOSTNAME(HOSTTCPA) WSNAME(CIPTCPA) PACKED MEDIANAME(CLAW1)
MEDIA CLAW NAME(CLAW2) MTU(4096) MSSDEF(4096) MSSOPT(ALWAYS) ASSIST NETWORK IPADDRESS(170.202.11.129) SUBNET(255.255.255.0) MEDIANAME(CLAW2) CLAW DEVADDR(090) BUFSIZE(4096) 8BUF(26) OBUF(26) HOSTNAME(HOSTTCPB) WSNAME(CIPTCPB) PACKED MEDIANAME(CLAW2)
This is an example of GTDCFGxx configuration for the System Diagram:
traceoptions general mark protocol update;
options noresolv;
interfaces {interface vr0 passive;};
routerid 170.202.1.1;
ospf yes
{
backbone
{
networks
{
170.202.1.0 mask 255.255.255.0 ;
170.202.10.0 mask 255.255.255.0 ;
170.202.11.0 mask 255.255.255.0 ;
170.202.0.0 mask 255.255.0.0 ;
};
authtype 0;
interface vr0 nonbroadcast cost 1
{
retransmitinterval 5;
hellointerval 6;
pollinterval 6;
routerdeadinterval 24;
};
interface cl0 nonbroadcast cost 1
{
retransmitinterval 5;
hellointerval 6;
pollinterval 6;
routerdeadinterval 24;
routers {170.202.10.126 eligible ; };
};
interface cl1 nonbroadcast cost 1
{
retransmitinterval 5;
hellointerval 6;
pollinterval 6;
routerdeadinterval 24;
routers {170.202.11.190 eligible ; };
};
};
};
These are examples of the CIP configuration.
CIPA ! version 11.2 service password-encryption service udp-small-servers service tcp-small-servers ! hostname COMPANY-CIPA ! boot system flash slot0:rsp-k-mz_260-4.bin enable password 7 1315991059EA062B25 ! interface Fddi2/0 ip address 170.202.92.252 255.255.255.0 no ip redirects no ip mroute-cache ! interface Channel3/0 ip address 170.202.10.126 255.255.255.0 no ip redirects ip ospf network nonbroadcast ip ospf hello-interval 6 no keepalive
claw 0100 70 170.202.10.65 HOSTTCPA CIPTCPA PACKED PACKED broadcast
!
router ospf 1 network 170.202.0.0 0.0.255.255 area 0 network 190.202.0.0 default-metric 56 2000 255 255 4096 neighbor 170.202.1.65 priority 1 poll-interval 6 ! ip domain-name company.com ! line con 0 login line aux 0 login transport input all line vty 0 4 login ! end
CIPB ! ! No configuration change since last restart ! version 11.2 service password-encryption service udp-small-servers service tcp-small-servers ! hostname COMPANY-CIPB ! boot system flash slot0:rsp-k-mz-260-4.bin enable password 7 131549101AE1972B25 ! interface Fddi0/0 ip address 170.202.92.251 255.255.255.0 no ip redirects ! interface Channel1/0 ip address 170.202.11.190 255.255.255.0 no ip redirects ip ospf network nonbroadcast ip ospf hello-interval 6 no keepalive
claw 0100 90 170.202.11.129 HOSTTCPB CIPTCPB PACKED PACKED broadcast ! !
router ospf 1 network 170.202.0.0 0.0.255.255 area 0 network 170.202.0.0 default-metric 56 2000 255 255 4096 neighbor 170.202.11.129 priority 1 poll-interval 6 ! ip domain-name company.com ! line con 0 login line aux 0 login transport input all line vty 0 4 login ! end
|
|