Connectivity Problems Using VARSUBNETTING In
Static Environment
APAR Identifier ...... PQ50059 Last Changed ........ 01/09/13
CONNECTIVITY PROBLEMS USING VARSUBNETTING IN STATIC ENVIRONMENT
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 3 Date Closed ......... 01/08/09
Component .......... 5735FAL00 Duplicate of ........
Reported Release ......... 410 Fixed Release ............ 999
Component Name TCP/IP V2 FOR V Special Notice
Current Target Date .. Flags
SCP ...................
Platform ............
Status Detail: SHIPMENT - Packaged solution is available for
shipment.
PE PTF List:
PTF List:
Release 410 : UQ56827 available 01/08/13 (1000 )
Parent APAR: PQ46571
Child APAR list:
ERROR DESCRIPTION:
The GATEWAY statement in the TCP/IP server configuration file
has been coded to make use of VARSUBNETTING, but certain
networks cannot be reached. With the GATEWAY statement
entries that follow:
GATEWAY
128.90 = TOK1 DEFAULTSIZE 0.0.252.0 0.0.160.0
128.90 = ETH1 DEFAULTSIZE 0.0.255.0 0.0.244.0
DEFAULTNET 128.190.160.87 TOK1 DEFAULTSIZE 0
hosts on the 128.90.245, 128.90.246, and 128.90.247 networks
cannot be reached. Traces show that outbound packets are
being placed on the ETH1 adapter, instead of the TOK1 adapter
that is associated with the DEFAULTNET entry.
LOCAL FIX:
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: z/VM TCP/IP LEVEL 410 USERS *
****************************************************************
* PROBLEM DESCRIPTION: Incorrect routes chosen when using *
* variable subnets. *
****************************************************************
* RECOMMENDATION: APPLY PTF *
****************************************************************
When using variable subnetting, the routing logic
may choose an incorrect route. This causes packets
to go out the wrong interface.
PROBLEM CONCLUSION:
The FindRoute logic has been changed to check subnet masks
on route matches. If the mask of the 'matching' route is
not equal to the route being tested no match is returned and
the search continues.
FindSubnetRoutesVisitNode, FindSupernetRoutesVisitNode
and FillIpRoutingTree routines have been changed to
handle zero subnet destination addresses.
In addition, in FillIpRoutingKey, the code was changed to use a
routing key of the NetAddress for SubnetInfoOnly routes.
This will prevent the AMPX errors in MPROUTE.
TEMPORARY FIX:
COMMENTS:
MODULES/MACROS: MSTCP TCIPDOW TCPIP TCTREEP
SRLS: NONE
RTN CODES:
CIRCUMVENTION:
MESSAGE TO SUBMITTER: