Changing CORE IP#?

[teedge77]

i cant stay away from him...hes always over here banging my wife.

[Matthew]

After research, discussion in this thread, some more research, and finally just working through the configs on my own network, I have solved the problem of properly configuring a single NIC LMCE to properly serve a LAN by DHCP, switched over from an existing DHCP server. AFAICT, this technique doesn't leave any wrong configurations anywhere inside either LMCE's complex interdependencies or the remnants of the previously existing DHCP system.

* In existing router/gateway
- Disable DHCPd
- Assign LAN IP# on desired subnet (eg 192.168.0.1 )
- Ensure router/gateway is configured to route properly between the newly specified subnet and the other network

* In LMCE Admin site:
- Homepage -> Advanced -> Network -> Network Settings
- Change all 192.168.80.x IP#s to desired subnet (eg. 192.168.0.x )
- Set both NICs to the same IP# (and proper subnet info)
- Reload DCERouter
- Check Homepage -> Advanced -> Network -> Network Settings to be sure settings were properly retained

* /etc/dhcp3/dhcpd.conf :
- Exclude router/gateway IP# from allocatable ranges
- Change "host px[1,2]" lines from 192.168.80.x IP#s to desired subnet IP#s (eg. 192.168.0.253 )
- /etc/init.d/dhcp3-server restart
- Force a LAN host to reset its network configs by DHCP, then test pinging across the router

* Force each host on the LAN to reread its network configs by DHCP (eg. run its DHCP client or reboot if its DHCP client runs at startup).

Note that the dhcpd.conf file regenerated by the LMCE Admin site's Network Settings form has a bug (#3469) which doesn't change all the IP#s properly. There might be other bugs, so check the whole file to be sure it's correct.

This technique leaves a problem in that any configs of your original router/gateway DHCPd are not available to the LMCE DHCPd, unless you manually recreate them in the LMCE's dhcpd.conf file. Also, the router/gateway LAN IP# must be manually discovered/set, and then the LMCE LAN subnet must be manually configured to accommodate it. There is no way to fix that problem, unless the router/gateway allows its LAN IP# to be set by DHCP (ie. a DHCP client running on the router/gateway that is set by the LMCE DHCPd). Conversely, there is no way for LMCE to insert into the router/gateway DHCPd configs the configs that LMCE needs clients for its own services (like IP phones) to automatically get from a DHCPd when they're plugged into a network. The only way to make DHCP fully automatic for LMCE is to use the recommended network architecture of a pair of ethernet ports on the LMCE server (or use a router/gateway DHCPd that can be remotely configured by the LMCE, and a script to glue them together).

I will now attempt to update the wiki...

I updated the wiki article DHCP Plug and Play: Single NIC & Existing DHCPd and have updated it again, so it is more current than the discussion in this forum topic.

[Hagen]

I usually just assign the IP range to the core that the router allready has, then I let theCore DHCP IP range start at 10.0.0.20 to allow for up to 19 routers/switches/+++ with manual IPs.
But wow, you do have a slick solution.

[Matthew]

I usually just assign the IP range to the core that the router allready has, then I let theCore DHCP IP range start at 10.0.0.20 to allow for up to 19 routers/switches/+++ with manual IPs.
But wow, you do have a slick solution.

That's the short explanation of my process. I thought I'd give the explicit details of exactly how to configure the required settings, which is what I'd hoped I'd find in my own search.

A mystery in my process is how come the LMCE DHCPd config says "router <CORE-IP#>", the way it did after the default LMCE installation, but the devices on the network still are using the existing router (unspecified in any DHCPd configs) as Internet gateway. But it does work.

[1audio]

Matthew:
The remaining question is whether the PXE boot will work correctly. It may have some IP address issues hidden in some script that will appear out of nowhere (like so much else in this project). Will you be using a media director in your setup?

[Matthew]

Matthew:
The remaining question is whether the PXE boot will work correctly. It may have some IP address issues hidden in some script that will appear out of nowhere (like so much else in this project). Will you be using a media director in your setup?

It looks like PXE boot is designed to rely on DHCP rather than hardcode:

allow booting;
allow bootp;

option space pxelinux;
option pxelinux.magic code 208 = string;
option pxelinux.configfile code 209 = text;
option pxelinux.pathprefix code 210 = text;
option pxelinux.reboottime code 211 = unsigned integer 32;

(...)

# PXE booting machines
group {
        next-server 192.168.0.10;
        filename "/tftpboot/pxelinux.0";
        option pxelinux.reboottime = 30;

}

If there are any PXE boot dependencies not properly dependent on DHCP, then the switch I did should be a good test to expose them. However, I do not have any media director hosts on my network yet (I'm trying out LMCE piece by piece, and it's been a good strategy so far .

[Zaerc]

Well if that is what you wanted, I guess you could just have turned off DHCP on the modem/router and configured the "external interface" (eth0 not the virtual eth0:0)  staticly in the modem/router's range.  Saves you the of trouble reconfiguring LMCE's DHCP server.

[Matthew]

Well if that is what you wanted, I guess you could just have turned off DHCP on the modem/router and configured the "external interface" (eth0 not the virtual eth0:0)  staticly in the modem/router's range.  Saves you the of trouble reconfiguring LMCE's DHCP server.

Yes, that is in fact what I wanted, except I also wanted the LMCE DHCP server to assign addresses in the existing LAN's Class C IP# range, and service LMCE devices that need LMCE's DHCP support. And I wanted to avoid (or recover from) the bug that regenerates the dhcpd.conf incorrectly. I also wanted to know what I was losing, the actual absolutely required losses, by using a single NIC. Know I know, and so does anyone else reading this thread (or the wiki, or the dhcpd.conf bug report).

What I wanted was for someone to explain how to do that, preferably point to an existing (and tested) explanation, since it's clearly a not uncommon setup. Now the next person will have a better chance of doing it in a few minutes, rather than a few hours, with a minimum of unnecessary noise as they search for the solution.

[Zaerc]

Then why didn't you just ask that instead? 

Anyway I'm so glad you have solved this for once and for all so that we never have to answer these questions ever again... 

And on a side note, don't you think it's just a little odd to give a virtual network adapter the exact same ip address as the physical adapter?

[Matthew]

Then why didn't you just ask that instead? 

Anyway I'm so glad you have solved this for once and for all so that we never have to answer these questions ever again... 

And on a side note, don't you think it's just a little odd to give a virtual network adapter the exact same ip address as the physical adapter?

It's easy when you know how.

[Zaerc]

Then why didn't you just ask that instead? 

Anyway I'm so glad you have solved this for once and for all so that we never have to answer these questions ever again... 

And on a side note, don't you think it's just a little odd to give a virtual network adapter the exact same ip address as the physical adapter?

It's easy when you know how.

My point wasn't really that it's hard to tell somebody to search the wiki.