Troubleshooting
Problem
A LAN segment is experiencing a flood of broadcast packets (also called a Broadcast Storm). Examination of that traffic using a protocol analyzer (sniffer) shows numerous repeated copies of a single broadcast packet being forwarded from OSA interfaces attached to z/Series systems.
Cause
The definition of the subnet mask to be used for an interface is incorrect in one or more z/Series LPARs (z/OS, z/VM or z/Linux). When the configured mask contains fewer bits than the correct setting for the connected LAN, packets being broadcast from other (correctly configured) systems on that LAN will be treated by those LPARs as unicast packets (packets destined for a single system instead of broadcast to all systems). If datagram forwarding is enabled, those LPARs will attempt to resend the packet using the configured routing rules.
When this condition exists for interfaces other than an OSA running in QDIO mode, this will only result in an ARP request for a nonexistent address and the eventual discarding of the packet. However ARP processing for QDIO OSAs is performed in the OSA itself, so the stack on the misconfigured systems will return the packet to the OSA for sending. If multiple LPARs (or VM guests) are sharing this OSA port and the last LPAR to register with the OSA provided the correct subnet mask, the OSA will then recognize the IP address as a broadcast address and resend the packet as a broadcast.
If only one LPAR on this LAN is misconfigured, this will result in every broadcast packet appearing twice on the LAN. If two LPARs are misconfigured, the packet will get repeated until the Time To Live (TTL) value expires (decrements to 0). If three or more LPARs are misconfigured, the number of packets increases exponentially potentially overwhelming the LAN and all connected systems with traffic.
Resolving The Problem
Ensure that all systems have the correct subnet mask configured for all TCPIP devices. The value to be used is determined by the LAN administrator when the network was designed. An incorrect specification will cause many other routing and connectivity problems besides the one described here.
Ensure that the correct mask is supplied on one of the following:
- For z/OS 1.10 or later, the preferred method is to specify the mask on the INTERFACE statement. This replaces the DEVICE/LINK statements for defining the OSA to TCPIP.
- For z/OS and z/VM systems without dynamic routing, the BSDROUTINGPARMS block.
- In the static routes defined in the BEGINROUTES statement in the TCPIP PROFILE. Or, for z/OS 2.1 and earlier, the GATEWAY statement.
- If dynamic routing (OMPROUTE) is used, ensure that the mask is correct on the Interface, OSPF_Interface. or RIP_Interface statements in the OMPROUTE configuration.
Notes:
- If no mask is supplied, the default is to use the mask for the home address' class. For most LAN implementations, this default will be incorrect.
- Define a replaceable static route using BEGINROUTES that provides the subnet mask.
- If Ignore_Undefined_Interfaces=YES is specified in the OMPROUTE configuration, the masks for the undefined interfaces must be provided using BSDROUTINGPARMS or the static route definitions.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21217259