On Wednesday, 03/05/2003 at 05:56 EST, Adam Thornton <[EMAIL PROTECTED]> wrote:
> It doesn't help that the z/OS guys are, more than likely, also all, "AND > THIS IP STUFF IS NEW AND WEIRD AND SCARY. WHY, IT TOOK ME 8 YEARS TO > GET ANY CONNECTIVITY AT ALL RUNNING AND NO ONE, BUT NO ONE, IS GOING TO > TOUCH IT NOW THAT I FINALLY HAVE PACKETS FLOWING. BACK OFF, I SAY! > BACK OFF!" If only learning were always painless.... > > - Change your OSA to OSE (LCS) and use OSA/SF to add all of your > > HiperSocket IP addresses to the OAT > > Wait, wait, wait. Is this the same Alan Altmark who just a few days ago > was saying that Proxy ARP was a bad workaround that would at best just > delay your pain? Because this solution is basically Proxy ARP, just > done at the IP rather than the MAC layer. Not to mention, of course, > that you probably bought your OSA because it was fast, which LCS, > whatever its virtues, generally isn't. Not so fast, Adam, m'boy! This isn't the same as proxy ARP. You still have a router connected to two LANs: one real, one less so. They will have different subnet numbers. The ARP will be for the virtual router, not the final destination. Adding IP addresses to the OAT in this case is not for ARP, per se, but is a way to modify the IP address filter. > > - Don't create the dummy device when using add_vipa4. If you create the > > dummy device, Linux thinks the packet is local and won't route it. But > > don't try to use OSPF or RIP because it won't see the interface. > > And, of course, if you *don't* use a routing protocol, then you have the > problem of "how do I advertise my virtual address"? And then you're > back to some hastily glued-together solution that involves a bunch of > tossing gratuitous ARPs around, and a whole sackful of similar ick. > This, when, clearly the *easy* way to do it (albeit more > resource-intensive) is to define a VIPA address, bound to dummy0, and > advertise it as a host route via OSPF. This doesn't solve your "Can't > route through the OSA unless it's PRIROUTER" problem though. But then when packets arrive with the VIPA address, Linux will try to deliver them locally instead of routing to the other LAN. You can't have your cake and eat it, too! > WHY, oh WHY can we not have something that's a *DUMB* OSA? Been there, done that. Too many (valuable, admittedly slower) CPU cycles get spent discarding useless data. > Yes, I'm sure that the OSA, as designed, works really really well for > shops sharing a single OSA across six MVS, er, OS/390, er z/OS LPARs. > But since it's also the preferred solution for getting traffic into a > penguin farm, could we have something a bit more suited to that task? > Please? If you don't want to share an OSA, don't. Then you are free to be primary router on it an all of these problems go away. > I admit that my anthropomorphization of the OSA is, perhaps, just a wee > bit unfair. Actually, OSAs are very sensitive creatures. They have fragile tentacles and their eyes flash constantly with an eerie lumenescence. Their sensitivity is matched only by their stubbornness, but once they learn something, they don't forget it. Now, the fact that you are having "conversations" with your "special friend" who you claim is a "z/OS guy" is more disturbing..... Lay down here on the couch; tell me what you think..... ;-) But lest you think we don't care about the problems caused by suboptimal OSA configurations, we do. We are examining ways to make virtual networking simpler/easier, both from a h/w and a s/w perspective. Alan Altmark Sr. Software Engineer IBM z/VM Development
