|Summary:||piranha gui does not save netmask|
|Product:||[Retired] Red Hat Cluster Suite||Reporter:||Martin Poole <mpoole>|
|Component:||piranha||Assignee:||Marek Grac <mgrac>|
|Status:||CLOSED WONTFIX||QA Contact:||Cluster QE <mspqa-list>|
|Version:||3||CC:||cluster-maint, mkrenz, xli|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-06-14 20:10:56 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Martin Poole 2005-04-07 10:33:16 UTC
Description of problem: The GUI does not save the value of the NAT nmask. There is no way to change the mask other than manually editing the lvs.cf file and inserting a nat_nmask value. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. select a NAT configuration 2. modify netmask. 3. reload interface. Actual results: no value stored in config file Expected results: value gets stored. Additional info: I would argue that if the lvs ip is within the same subnet as that of any existing ip/alias on the chosen interface then it should use the same netmask. The effects of allowing multiple overlapping subnets on a single interface (or at all) can be extreme. In the cases I have seen the result was an overlapping set of netmasks for the same region (10/8 & 10.0.0/24) which meant VPN clients didn't work, various other subnets couldn't see the lvs ip, the ARP table filled, iptables masquerading interface enforcement failed, and general service degradation/failure. Obviously fixing the GUI is a first step, but some thought on the above (or incorporation of a really big warning) would also be nice.
Comment 1 Lon Hohberger 2005-11-21 22:27:52 UTC
This works in my setup. Maybe I've got the wrong version?
Comment 2 Lon Hohberger 2005-11-21 22:29:50 UTC
Actually, nat_nmask seems to be preserved even if I change router types...
Comment 3 Mark Krenz 2005-12-05 15:53:26 UTC
For what its worth, I'm having the same problem on piranha-0.7.10-2.
Comment 4 Lon Hohberger 2005-12-06 20:00:09 UTC
Martin, Mark - I reproduced it on 0.7.10 on RHCS3/RHEL3, but RHCS4 is 0.8.x, which is what this bug is filed against. Was it mistakenly filed against RHCS4 when it should have been against RHCS3? /me is confused... I think it should be version 3, not 4; it works for me on 4.
Comment 5 Martin Poole 2005-12-07 09:06:54 UTC
I think you'll find BZ has wobbled. I filed this back in April against RHCS3. I'm glad to hear you've reproduced the problem. I was dealing with a customer issue where they had both /22 & /28 mask subnets in evidence.
Comment 6 Lon Hohberger 2005-12-07 14:47:43 UTC
Changing to RHCS 3, then.
Comment 9 Stanko Kupcevic 2006-11-07 21:46:10 UTC
*** Bug 198479 has been marked as a duplicate of this bug. ***
Comment 10 Lon Hohberger 2007-06-14 19:53:52 UTC
Reassigning to component owner