Bug 24074 - pulse does not correctly assign netmask or broadcast addresses
pulse does not correctly assign netmask or broadcast addresses
Status: CLOSED DEFERRED
Product: Red Hat High Availability Server
Classification: Retired
Component: piranha (Show other bugs)
1.0
All Linux
high Severity high
: ---
: ---
Assigned To: Phil Copeland
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-15 17:25 EST by Paul Lussier
Modified: 2015-01-07 18:42 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-11 17:22:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Red Hat Bugzilla 2001-01-15 17:25:10 EST
The pulse code leaves the determination of netmask and broadcast
information up to the ifconfig program, which almost always uses the
wrong values unless the network in question is a natural Class C
network.

For anyone using Class A or Class B network address ranges subnetted
into smaller networks, ifconfig always uses the appropriate classes
natural netmask and determines the broadcast from a combination of the
IP address/netmask.  This results in netmasks of 255.0.0.0 for a class
A network and 255.255.0.0 for a class B network, and broadcasts of
X.255.255.255 and X.Y.255.255 respectively.

What is needed is a mechanism for setting the netmask within lvs.cf
so that the netmask and broadcast can be determined and subsequently
passed as arguments to ifconfig.
Comment 1 Red Hat Bugzilla 2001-01-16 12:11:23 EST
Forwarded to Phil for review
Comment 2 Red Hat Bugzilla 2001-05-11 17:22:05 EDT
This is being worked on. You will be able to specify a network bas on all
virtual IP addresses, the net router, and the real server.

Note You need to log in before you can comment on or make changes to this bug.