Troubleshooting
Problem
After implementing global VRNs, the following VTAM messages were displayed: IST590I CONNECTOUT FAILED FOR PU CNV0074D ON LINE linename IST1139I CONNOUT FOR CNV0074D FAILED - SENSE: FFC80004 IST1045I NODE TYPE = PU_T2 IST314I END IST1903I FAILURE OVER VRN vrn_name TO CP cpname IST1133I CNV0074D IS NOW INACTIVE, TYPE = PU_T2 IST871I RESOURCE CNV0074D DELETED
Diagnosing The Problem
VTAM is attempting to start a connection for a session request. VTAM determines that a new connection to the destination CP needs to be created. VTAM attempts to dial this CP over a connection network. The CONNECTOUT attempt fails because there is an existing connection to this host with the same identifier.
This sense code (FFC80004) indicates duplicate IP address and SAP pair. It appears there was already an existing VRN connection using the same IP address and SAP pair or another connection was already in progress. VTAM attempted to activate a local VRN or GVRN connection for a session. It is possible that one was already in progress between the same CPs and VTAM was attempting another one.
This could also be related to the session failing with sense code 08060027.
The IST1903I message you are seeing is an indication that the named partner node cannot be reached at this time using the connection network path across the named VRN.
The problem is that your local and global Virtual routing nodes, by not specifying the IPADDR parameter on the GROUP definition statements, are causing the IPADDR value on both statements to default to the value specified on the IPADDR VTAM start option. Since both GROUP definition statements default to the same value for IPADDR, a conflict arises between them, causing the issuance of the error messages you are seeing:
1. IST1139I CONNOUT FAILED with sense code FFC80004 (HPR/IP (Enterprise Extender) addressing keys (LSAP, RSAP, IPADDR) duplicate those of a preexisting connection) is being issued because a new connection using a local VRN is trying to use the same IP address as a preexisting connection using a global VRN.
2. Message IST1903I FAILURE OVER VRN vrn_name TO CP cpname is issued for the same reason.
Resolving The Problem
Specify IPADDR parameter on XCA major node GROUP definition statements for EE VRNs
What you need to do to eliminate these messages is to make the following modification to all your EE XCA major node definitions:
Either
(1) Specify the IPADDR parameter on both GROUP statements, making sure the IP address you specify is different for each one.
or
(2) Specify the IPADDR parameter on either GROUP statement, and choose for the IPADDR parameter an IP address that is different from the one specified on your IPADDR start option.
Remove the local VRN
Alternatively, as discussed during the call, you may want to just remove the local virtual routing node, and use the Global VRN for all your EE connections. The disadvantage to having only a single global VRN is that it can lessen your control over who accesses your network. As the SNA Network Implementation Guide points out:
- A global VRN that is defined only by nodes within one of your own subnetworks
- A global VRN that is defined by your external vendor and a subset of the nodes within your own subnetworks
6.4.4.2 Defining multiple global VRNs
If a network is designed with multiple subnetworks, firewalls probably do not exist between these subnetworks. But if this same network also has APPN EBN connectivity to external vendors, a firewall probably exists between them. In this case, it would be beneficial to define two different global VRNs:
This enables you to control which systems external vendors can connect to directly (using global VRN), while still allowing internal systems (in any subnetwork) to directly connect to any of the other system in your subnetworks.
Additionally, defining multiple global VRNs enables you to avoid problems that might occur when multiple external customers connect to your network using the same global VRN. For example, assume Company A connects to Company B using a given global VRN (as shown in Figure 49 in topic 6.4.4.1). If Company B connects to a second company using the same global VRN, it might then be possible for Company A to inadvertently connect directly to that second company.
- Although you can restrict this type of access by implementing the appropriate searching controls, defining a separate global VRN for connectivity to each external vendor increases your control over network access.
Define unique VRN IP addresses
IP addresses for a local virtual routing node and for a global virtual routing node must be unique. See FIN APAR OA37027, titled "MSG TO ALERT OPERATOR THERE IS AN IP ADDRESS CONFLICT WITH A VIRTUAL ROUTING NODE".
Temporarily make connection path over VRN unavailable
You can temporarily make the connection path over the named VRN unavailable until the source of the underlying problem is found and corrected.
First, if it is active, turn off the start option PSRETRY. Issue the
MODIFY VTAMOPTS, PSRETRY=(0,0,0,0)
command to prevent any existing RTPs that are successfully using the named VRN to reach their destination endpoints from path-switching to a less attractive route.
Then take one of the following actions to make the named VRN unavailable:
- Issue the MODIFY TOPO,FUNCTION=QUIESCE, SCOPE=NETWORK command specifying the VRN named in IST1903I to remove the VRN from consideration by Topology in route calculations. Quiescing the VRN will make all paths through this VRN unavailable for all nodes connected to the connection network, not just the path identified in message IST1903I.
- Issue the VARY INACT command for the local link to the VRN.
- Increase the weight of this connection network path by issuing the MODIFY TGP command for the TGs to and from the VRN.
You might need to take the preceding actions (disabling PSRETRY and the single action chosen from the preceding list) from both this node and the partner node to successfully route around the connection network problem. When you have taken these actions, use established procedures to diagnose the underlying problem at both this node and the partner node to find and correct the problem.
When the problem has been corrected, reverse the preceding actions so the current connections and future connection attempts will be rerouted over the connection network path. Depending on which of the preceding actions was taken, do one of the following things:
- Issue the MODIFY TOPO,FUNCTION=NORMAL,SCOPE=NETWORK command for the named VRN.
- Reactivate the local link to the VRN.
- Issue the MODIFY TGP command for the TGs to and from the VRN to decrease the weight of the connection network path.
You can re-enable PSRETRY. This will cause existing RTPs to periodically check for a lower weight path and switch to it if one is available.
The preceding description is found in the description of message IST1903I.
Utilize the UNRCHTIM start option
The UNRCHTIM start option is used to enable the EE connection network reachability awareness function, which is intended to handle the problem that is being raised by the IST1903I message, namely: EE connections through the connection network are not rerouting to an alternate path.
EE connection network reachability awareness is designed to detect the dial failure or connection INOP for the connection over an Enterprise Extender connection network and prevent that specific path to the partner node from being used for a period of time. Use the EE connection network reachability awareness function to indicate that the path to a partner node over an Enterprise Extender VRN should not be used for route selection for a period of time after the initial dial failure or connection INOP, providing time for the underlying connection problem to be corrected.
See the topic "EE connection network reachability awareness" in the SNA Network Implementation Guide for more information on using UNRCHTIM. For syntax instructions on coding UNRCHTIM , see the topic UNRCHTIM start option in the SNA Resource Definition Reference.
Regarding a suggested value in seconds for the "unreachable time" value of the UNRCHTIM start option, it all depends on the duration of the outages you are experiencing. With a lower value such as 10, any outage longer than 10 seconds will mean that unreach records will be created with the first failure. If the outage goes beyond 10 seconds, session setups will begin failing again after 10 seconds and new unreach records will be created. This will happen every 10 seconds until the outage is corrected. So if it is a temporary outage, a low value is good. But if you tend to have longer term outages, then you should use a higher value, such as 300.
You should strongly consider implementing the UNRCHTIM start option with a very high value (at least 300 seconds and perhaps even the maximum value allowed) to permit routing around the VRN for that time interval. You can also use the MODIFY NET,TOPO,FUNCTION=QUIESCE command to quiesce TGs between network nodes and the VRN. The UNRCHTIM start option should be implemented on all network nodes and end nodes.
Concerning a recommended value for partner_limit, IBM Software Support does not have an official recommendation because it is somewhat dependent on your topology. However, the default value (10) is probably a reasonable choice for most installations, and IBM Software Support does not recommend going over 20 or 30. The downside of using larger values is the risk of increased CPU usage by the route calculation algorithm due to long unreachable partner chains (during times when connection network failures are occurring).
Related Information
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21587118