|Summary:||Minor problem with virtual server network mask|
|Product:||[Retired] Red Hat High Availability Server||Reporter:||blane.dabney <blane.dabney>|
|Component:||piranha||Assignee:||Phil Copeland <copeland>|
|Status:||CLOSED ERRATA||QA Contact:||Wil Harris <wil>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-10-16 17:44:43 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Red Hat Bugzilla 2000-09-20 19:00:06 UTC
In the experimental 0.4.17-3 version of piranha, you added a feature to allow a network mask along with the virtual server IP, instead of assuming a classfull mask, which is a much needed feature. However, it still calculates the broadcast address according to the classful mask, which really doesn't seem to cause a problem, as the LVS router itself, in a direct routing or NAT setup, should never try to reply to a packet from that address. It could possibly cause problems in a tunneling setup, however.
Comment 1 Red Hat Bugzilla 2000-09-21 13:07:39 UTC
I would have thought ifconfig defaulted to the netmask settings for broadcast. We'll check into it...
Comment 2 Red Hat Bugzilla 2000-09-21 15:35:41 UTC
That's what I thought too, but when I tested ifconfig yesterday, if you don't specify a broadcast address, it assumes a classful netmask when calculating the broadcast. So it's really a glitch in ifconfig, but you can work around it.
Comment 3 Red Hat Bugzilla 2000-09-21 20:58:41 UTC
I'm in the process of adding the extra code to calculate the broadcast address for you ie broadcast = ( VIP & netmask) | ~netmask ; I didn't spot ifconfig not calculating the broadcast for itself because I was using a 255.255.255.0 netmask. 0.4.17-4 should be out tonight or tomorrow (depending on how god/bad the offsite company meeting goes. Phil =--=