-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSA VIPA feature incompatible with multiple OSA device emulation. #485
Comments
Forgive me for asking what is probably a dumb question (I am not experienced/familiar with VIPA on "the emulated system" that I suspect you're using), BUT... Isn't it the responsibility of the guest O/S (i.e. "emulated system") to direct its OSA command(s) to the proper/desired device? In other words, how can a "SETIP(+VIPA)" be received on "the adapter opposite the adapter intended" unless "the emulated system" specifically issued the command to that adapter? I have not reviewed Hercules's QETH/OSA handler logic before posting this response, but AFAIK, Hercules does not arbitrarily choose which OSA adapter a given command is processed for. AFAIK, command packets are sent by the guest to whichever adapter (device address) it wants to send them to, and AFAIK Hercules processes such command packets for that adapter. So how can such "SETIP(+VIPA)" (command packets?) be processed on the "wrong adapter" as you claim, unless the guest O/S ("emulated system") specifically sent it there on purpose? Again, I'm not that familiar/experienced with using OSA devices, but are you sure you have them configured correctly in your "emulated system" (guest OS)?
Why? Are we not doing what real OSAs do? Because if we're not, then IMO we need to fix that, not rip it out!
I'll take a look. But again, I'm not all that familiar with VIPA and how it works (or is supposed to work) on OSA devices. In the mean time, can you share your proposed change(s) with us? What's the URL of your fork you intend to submit a pull request for? |
VIPA provides the means for network resiliency in the face of adapter failure, media failure ... you get the picture. It allows the OSA stack to choose transport alternatives. The project This is not an observation of a CCW being directed to the wrong device, it's a case of My local fork code rejects the VIPA SETIP, but one could equally argue for a (non-debug) silent ignore since in either circumstance, normal operation is not affected (no emulation of VIPA behaviors exists, so either option could be construed as acceptable). One could also legitimately decide there's a reason to emulate some of the special OSA VIPA behaviors in some future development effort and use a configuration keyword to enable/disable such processing ... but IMHO there isn't a justification for attempting the emulation of VIPA resiliency; we should just ensure it doesn't disrupt normal operation. |
Are you saying that as someone who does know what real OSA's do? I am the author of parts of IMHO, implementing VIPA was a bad idea, but other's believed it was a good idea, and, as I understand it, now use it successfully. As a *nix user I avoid VIPA breaking my networking by using preconfigured tuntap interfaces and running Hercules without privileges. |
I am not an OSA firmware developer, but VIPA and OSA external behaviors are well described in IBM documentation. Like you, I use pre-configured tuntap interfaces on *nix platforms, and when I configured 2 emulated OSA device groups, I observed that after each tunnel interface is assigned the appropriate destination address upon receipt of SETIP+DEFAULT, one or more of the devices can also receive SETIP+VIPA requests for the opposite adapter's address. Since we treated SETUP+VIPA in As long as we have no VIPA behavioral emulation, we should at least take steps to not treat VIPA as SETIP+DEFAULT requests. I'm not making an argument against taking on a development effort that would add additional emulated behaviors to |
The home IPv4 address of each and every defined device/link or interface (OSA, VIPA, what ever) is sent to each and every OSA as a VIPA address. This is how z/OS's TCP/IP stack(s) seem to operate. It makes sense for z/OS, as it's offloading all that boring inbound traffic management to the OSA(s). |
Exactly, and since we don't emulate that part of OSA in |
I'm not sure what your environment is, but I would hate to see any VIPA support disabled. I have a single OSA and multiple VIPAs with Hercules under Windows running. The VIPAs are in separate subnets from the OSA adapter so I'm using OSPF. I do agree that defining two OSAs causes problems. I have to admit I'm still using LCS interfaces on Linux, so I don't know if my OSA configuration would work there. The only 'real-world' behaviour I've found is Windows with multiple LCS adapters and multiple VIPAs, all in the same subnet. ARP takeover and giveback and VIPA owner all work. CTCI-WIN does not support multicast with LCS interfaces, so no OSPF support so single subnet required. |
It sounds to me like we should probably do what bw-gh suggests: accept the request but otherwise do nothing. At least maybe do that only on Linux? Or maybe make it a device statement option? (i.e. a new OSA/QETH configuration file device statement parameter/option?) E.g. vipa=yes|no? (or vipa=acc/rej?) |
In a 2 interface situation using OSA devices at 0400.3 and 0404.3, with some emulated system activating both interfaces, SETIP(+VIPA) may be received for the adapter opposite the adapter intended in addition to SETIP (DEFAULT) for the intended adapter. This can render the host network configuration unusable. Given the limited runtime and emulation goals of Hercules, it seems that VIPA SETIP commands should be rejected.
I have verified that rejecting VIPA SETIP allows successful network operation on both interfaces, but since there were explicit tests for VIPA in
qeth.c
, I'm looking for a wider opinion before creating a pull request.Built from my fork of this project, based on the develop branch:
The text was updated successfully, but these errors were encountered: