[BlueOnyx:01984] Re: IP Addressing on sites

[Michael Stauber]

Hi Chuck,

> Maybe I didn't explain clearly Michael.  I realize that the one Management
> Port won't be visible to the OS and didn't have any expectations of that.
>
> But that doesn't explain why the second Gig-E port isn't visible to the
> GUI.  In fact, the OS doesn't even seem to see it. In the dmesg output,
> there is: eth0: Tigon3 [partno(N/A) rev a200 PHY(5722/5756)] (PCI Express)
> 10/100/1000Base-T Ethernet 00:23:7d:aa:56:b4 There is nothing else for a
> eth1.  I don't think I turned it off in the BIOS, but will have to check
> that the next time I have to boot the machine.

Yeah, if it doesn't show up in "dmesg", then it ain't there. As least as far 
as the OS is concerned. Reasons for this can be that the NIC is disabled, or 
that the Linux kernel has no driver for it. Which then would be a CentOS issue 
(and RedHat, as the CentOS kernel is just a recompiled RHEL5 kernel). Maybe 
there is a separate Linux driver from the vendor of the NIC?

> The real problem is the management GUI using the same netmask asssigned 
> to eth0 as the netmask for all the subinterfaces.

With "subinterfaces" you mean the eth0:0, eth0:1 (and so on) for example?

> We have some virtual servers with just 12-14 sites on them.  We have a
> couple with over 100.  It depends on the size of the sites, number of users
> in the domains, and services provided to them.  So, some of them are
> assigned a /24 block of 256 addresses, some a /25, and most have /26 and
> /27 blocks of 64 or 32 addresses - all in the company's secondary
> networks. 
>
> But all of them have the "management" IP (the one assigned to the box/eth0)
> all in a similar subnet in their primary network.  This greatly simplifies
> management, control of who can get to the management IP, and assignment of
> additional addresses if needed.  Because the management IP never changes
> and is always in that common subnet.  So, that's why we do it that way.
>
> But that management IP subnet is a /28 with 16IPs.  And the GUI just
> automatically assigns that same netmask 255.255.255.240 to the
> subinterfaces for all the site IPs, even if we've assigned an entire /24
> network to the sites.  See the problem?  Suddenly, I can't use the .15
> address in that /24 block, and every 16 addresses after that (the ones that
> would be broadcast if the /24 were broken up into /28 blocks).

I don't have the perfect solution for this at hand. Keep in mind that what 
you're reporting here has been around for as long as the Cobalts and as 
BlueQuartz have been around. They all show the very same behaviour in that 
regards and it's a carry-over from the "appliance" idea.

What speaks against assigning the internal management IP to eth0 and using a 
Netmask as wide as the Netmask from the widest extra network address range? 
Even if your internal management network is smaller. Sure, you get more 
network congestion and topology wise it may not be the greatest thing there 
is. But it could be a quick and dirty fix that works for you.

The other easy "fix" (or work around) here would be to assign one IP from a 
Network with the widest Netmask as primary IP to eth0. That way IP's assigned 
to "subinterfaces" get a Netmask that's a bit wider than it ought to be, but 
for practical purposes the IP will be reachable from the outside.

Then assign your management IP to a virtual site (so that you can reach the 
server under that IP, too). 

Or assign the management IP to the 2nd NIC and hook it up to the switch as 
well. That ain't perfect, but it gets the job done and on the 2nd NIC you can 
specify the smaller Netmask just as you need it.

-- 
With best regards

Michael Stauber