A fix is available
APAR status
Closed as program error.
Error description
After applying VM66302 on a system with an IP Layer VSWITCH the PRIROUTER guest experienced intermittent packet loss. The packets affected were inbound packets with an IP address that was NOT registered to any virtual NIC coupled to the VSWITCH (e.g. IP destination 10.0.0.1 for a VSWITCH with interfaces that registered IP addresses on the 192.168.0.0/24 subnet. These inbound packets should have been delivered to the virtual router guest that had enabled "primary_router" mode. When a series of packets for the unregistered address (e.g. 10.0.0.1) entered the VSWITCH, the first packet was delivered and subsequent packets for the same address were discarded. The virtual router supported 10.0.0.1 but did not register that IP address on this VSWITCH. TRSOURCE data confirmed that an inbound packet with a destination of 10.0.0.1 was delivered to the virtual router (and solicited a reply) but the next one (or more) inbound packet(s) with the same destination were dropped (and counted as RX Discards on the RDEV interface). This was a configuration that was working before applying service.
Local fix
Apply PTF
Problem summary
**************************************************************** * USERS AFFECTED: Virtual routers in a PRIROUTER or SECROUTER * * VSWITCH may experience intermittent packet * * loss after applying APAR VM66302. * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: APPLY PTF * **************************************************************** Virtual routers (VM users with the virtual NIC configured to enable primary router mode or secondary router mode) within a VSWITCH may experience intermittent packet loss. Packets that enter the OSA RDEV interface for a destination that is not explicitly registered to a virtual NIC should be delivered to the virtual NIC registered as the primary router (or secondary router). This works for the first NEW packet for a given destination, but fails for subsequent packets because the destination for a UNICAST router was cached as a list, and the code segment processing a repeat unicast address was expecting a single device pointer to be cached. Subsequent packets that should have used the same router list were discarded until a packet entered for a new destination (wiping out the old cache).
Problem conclusion
The logic in HCPVNSDG to handle a unicast router (primary router or secondary router) is revised to clearly indicate that the router list is stored in the source NIDLLX01 field and the normal unicast target device address is stored in the source NIDDXNID field. Meanwhile, the logic in HCPVNSDG that detects a repeated destination by IP address and VLAN is updated to test for a unicast list first (NIDLLX01) and only use NIDDXNID if there is no unicast router list.
Temporary fix
Comments
APAR Information
APAR number
VM66406
Reported component name
VM CP
Reported component ID
568411202
Reported release
710
Status
CLOSED PER
PE
YesPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-06-19
Closed date
2020-08-09
Last modified date
2021-09-09
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UM35707 UM35708
Modules/Macros
HCPLAN HCPVNS
Fix information
Fixed component name
VM CP
Fixed component ID
568411202
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG27M"},"Platform":[{"code":"PF054","label":"z\/OS"}],"Version":"710","Line of Business":{"code":"LOB16","label":"Mainframe HW"}}]
Document Information
Modified date:
10 September 2021