Multiple Interfaces on Core

[dukat]

Hi,

I've added a new (faster) Interface on the core, and I want to change the internal one. It used to be eth0, but now it's eth2. How can I change that on the web page? Even better, how can I have both networks configured as internal networks?

Say something like this: eth0 - 192.168.80.x; eth2: 192.168.81.x - both should be served as the internal ones. Any advice?

[Matthew]

Isn't that what the Adminsite Home -> Advanced -> Network Settings "Swap Interfaces" button does?

FWIW, the underlying OS configs to select which HW ethernet interface (ie. which card/port) is mapped to which logical interface (ie. eth[0,1]), you have to edit /etc/udev/rules.d/70-persistent-net.rules (or maybe its generator rules in /etc/udev/rules.d/75-persistent-net-generator.rules ), and /etc/network/interfaces .

[dukat]

I don't want to swap interfaces - I want to add another internal interface, and here the admin site doesn't seem to help.

But the udev rules is a good starting point. Except that LMCE doesn't seem to use them for Interface names. Looking around, it seems LMCE still uses /etc/iftab for this. Is this going to change in 710?

[1audio]

The clues you need are in the web admin panel under advanced-configuration-devices-core. There is a field that specifies the ethernet interfaces. however what you are trying to do is bond several to the same network. Thats uncharted territory for LMCE. There probably is good Linux info for that and please let us know if you are successful.

[Matthew]

I don't want to swap interfaces - I want to add another internal interface, and here the admin site doesn't seem to help.

I don't know. I've no idea what that adminsite page would show with 3 HW interfaces.

But the udev rules is a good starting point. Except that LMCE doesn't seem to use them for Interface names. Looking around, it seems LMCE still uses /etc/iftab for this. Is this going to change in 710?

I switched my own interfaces by editing that 70/network udev rules file to swap the eth0/1 names, and the admin site GUI kept synced to that properly.

[dukat]

So, I spent my Sunday playing around, and I made some progress. First, switching the interfaces was really easy - I just renamed the new eth2 to old eth0 in /etc/iftab and LMCE had no problems with the new interface. I'm still surprised about the other comment about udev rules for changing interface names. While know this working perfectly on my other client box running plain Kubuntu 7.10, my LMCE core only uses iftab.

Now, how to get the other interface as a second internal network? I configured eth2 manually in /etc/network/interfaces to to become 192.168.81.1. It took me quite a lot of time to figure out that I also had to update the firewall to make it usable. The following helped:
iptables -A INPUT -s 192.168.81.0/24 -j ACCEPT

With that, the connection was up, but I can use it only if I configure the client's IP manually. I don't know how to get DHCP working. I added a new section in /etc/dhcp3/dhcpd.conf on core

subnet 192.168.81.0 netmask 255.255.255.0 {
    range 192.168.81.10 192.168.81.40;
}

But this didn't do the trick. Anyone knows about DHCP to give me a hint?

[Matthew]

So, I spent my Sunday playing around, and I made some progress. First, switching the interfaces was really easy - I just renamed the new eth2 to old eth0 in /etc/iftab and LMCE had no problems with the new interface. I'm still surprised about the other comment about udev rules for changing interface names. While know this working perfectly on my other client box running plain Kubuntu 7.10, my LMCE core only uses iftab.

Now, how to get the other interface as a second internal network? I configured eth2 manually in /etc/network/interfaces to to become 192.168.81.1. It took me quite a lot of time to figure out that I also had to update the firewall to make it usable. The following helped:
iptables -A INPUT -s 192.168.81.0/24 -j ACCEPT

With that, the connection was up, but I can use it only if I configure the client's IP manually. I don't know how to get DHCP working. I added a new section in /etc/dhcp3/dhcpd.conf on core

subnet 192.168.81.0 netmask 255.255.255.0 {
    range 192.168.81.10 192.168.81.40;
}

But this didn't do the trick. Anyone knows about DHCP to give me a hint?

If your DHCPd is serving all the ethernet interfaces on its machine, then I think that should have worked. LMCE's dhcpd3 should default to watching each ethernet interface, so it should have worked. But maybe your method of installing/configuring the new interface is not revealing it to dhcpd3. Do the instructions at "dhcp server on multiple interfaces." help? When you manually run a DHCP client on a host attached by a LAN segment to the new ethernet port on the LMCE Core (eg. (dhclient eth0) or whichever is the client's ethernet interface name), what does the client report?

[1audio]

If the new interface is at 192.168.81.1 and the DHCP is serving on 192.168.80.XXX then its addresses won't work on the new segment or will they? I thought the new port would be in the same segment and just increasing the thoughput. This is a little different.

[Matthew]

If the new interface is at 192.168.81.1 and the DHCP is serving on 192.168.80.XXX then its addresses won't work on the new segment or will they? I thought the new port would be in the same segment and just increasing the thoughput. This is a little different.

The new ethernet is just another interface on the Core. The dhcpd should serve that interface as designated by the dhcpd.conf , which the one described in this topic seems (to me) to do, as it will start up and serve every ethernet interface found on the Core.

[dukat]

If the new interface is at 192.168.81.1 and the DHCP is serving on 192.168.80.XXX then its addresses won't work on the new segment or will they? I thought the new port would be in the same segment and just increasing the thoughput. This is a little different.

How could I bring it into the same segment? That would be also ok for me, and I think would make configuration much easier. I assigned a new network, because this is the only way I thought it would work.

I'll try the other DHCP hints later on. Thanks for the hints.

[1audio]

The dhcpd should serve that interface as designated by the dhcpd.conf , which the one described in this topic seems (to me) to do, as it will start up and serve every ethernet interface found on the Core.

I don't thinbk its quite that simple. Networking is still very murky to me but I have picked up a few of the concepts. First it should only serve DHCP addrsses on designated ports or it will send them out the external port which would mess things up a little. Second if the IP rage is not within the range it can talk to (the class 1 class 2 etc. thing I have a fuzzy concept of) it may pass IP addresses out a port that can't talk back to the port.
I thought the second NIC on the network would be 192.168.80.XXX in an address not within the range that the DHCP serves. I'm doing this with an old GPIB network interface that needs a different prototcol (RARP) to get an IP address. I left a gap in the sequence and set up RARP in LMCE to supply that address (If I had a Windows network I'd be sunk.).
I'm not sure of the reason for a second NIC. That would help us understand the goal of this effort.

[Matthew]

The dhcpd should serve that interface as designated by the dhcpd.conf , which the one described in this topic seems (to me) to do, as it will start up and serve every ethernet interface found on the Core.

I don't thinbk its quite that simple. Networking is still very murky to me but I have picked up a few of the concepts. First it should only serve DHCP addrsses on designated ports or it will send them out the external port which would mess things up a little. Second if the IP rage is not within the range it can talk to (the class 1 class 2 etc. thing I have a fuzzy concept of) it may pass IP addresses out a port that can't talk back to the port.
I thought the second NIC on the network would be 192.168.80.XXX in an address not within the range that the DHCP serves. I'm doing this with an old GPIB network interface that needs a different prototcol (RARP) to get an IP address. I left a gap in the sequence and set up RARP in LMCE to supply that address (If I had a Windows network I'd be sunk.).
I'm not sure of the reason for a second NIC. That would help us understand the goal of this effort.

dhcpd defaults to serving every ethernet interface that's up when dhcpd is started, unless specific interfaces are specified on its startup commandline:

The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line. This should be done on  systems where dhcpd is unable to identify non-broadcast interfaces, but should not be required on other systems. If no interface names are specified on the command line dhcpd will identify all network interfaces which are up, eliminating non-broadcast interfaces if possible, and listen for DHCP broadcasts on each interface.

LMCE's dhcpd is started by the /etc/init.d/dhcp3-server wrapper. Which includes /etc/default/dhcp3-server , which in turn defines the interfaces invoked by the init.d script in the dhcpd commandline. I expect that the LMCE Adminsite edits /etc/default/dhcp3-server .

[colinjones]

That is the default, but with LMCE my understanding was that it should only be serving the internal network, not the external network. That is one of the points of having the networks partitioned, so that the LMCE network doesn't interfere with any existing network. And this is the way you are supposed to be able to have your external network served by your, say, broadband router's DHCP server, whilst LMCE serves the internal network.

1audio - you are right about this messing things up! And yes potentially you could end up with it passing out "non routable" addresses if it wasn't for the fact that for every interface that is listening you need to have a "scope" setup that responds to local broadcasts and has an IP range for a subnet that the LMCE interface itself resides on. That ensures that the "external" client can always talk at least to that interface - ie no need for routing which is essentially what you concern was about. Otherwise it could end up on an islanded subnet with no accessibility to a local router that could get its packets off that island - because the correct router for that range is on the other side of the LMCE box, the internal interface. Each interface can also have any number of other scope definitions for remote subnets. Those remote clients can't broadcast to the DHCP server because these broadcast can't leave their own subnet. But the router for that subnet can see these broadcasts, and can have an IP Helper setup to tell it where the DHCP server is. It then unicasts the request to the DHCP server with its own IP address as the source. The DHCP server then infers the subnet that the client is on from the router's source IP address, and if it has a scope definition for that subnet it will respond back via the router to the client with a lease.

BTW, there are ways of fudging it so that 2 nodes on different subnets can communicate without a router as long as they are physically and logically on the same network segment, but you don't want to go there!

[Matthew]

That is the default, but with LMCE my understanding was that it should only be serving the internal network, not the external network. That is one of the points of having the networks partitioned, so that the LMCE network doesn't interfere with any existing network. And this is the way you are supposed to be able to have your external network served by your, say, broadband router's DHCP server, whilst LMCE serves the internal network.

Nah, like I said:

dhcpd defaults to serving every ethernet interface that's up when dhcpd is started, unless specific interfaces are specified on its startup commandline:

The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line. This should be done on  systems where dhcpd is unable to identify non-broadcast interfaces, but should not be required on other systems. If no interface names are specified on the command line dhcpd will identify all network interfaces which are up, eliminating non-broadcast interfaces if possible, and listen for DHCP broadcasts on each interface.

LMCE's dhcpd is started by the /etc/init.d/dhcp3-server wrapper. Which includes /etc/default/dhcp3-server , which in turn defines the interfaces invoked by the init.d script in the dhcpd commandline. I expect that the LMCE Adminsite edits /etc/default/dhcp3-server .

Code: [Select]

# cat /etc/default/dhcp3-server
INTERFACES="eth1"
eth1 is my inside LAN segment. That file should say 'INTERFACES="eth1 eth2"' when eth1 and eth2 are the inside LAN segments (and presumably eth0 is the outside LAN segments). Then the trick is making /etc/dhcp3/dhcpd.conf specify the right PNP configs for the right subnets assigned on those eth[1,2] interfaces. I believe that the DHCPd will find different subnet {} blocks in the same dhcpd.conf file, and assign each subnet {} block to an ethernet interface in the order specified on the dhcpd commandline (and therefore in the order in the INTERFACES environment var defined in /etc/default/dhcp3-server ). So each subnet {} block can be defined with IP# ranges, PNP and other parameters specific to its ethernet interface.

[dukat]

Thank you all for the hints you gave. In the end this proved way to complicated for me so I dropped it...

Still I think having two internal interfaces would make sense, especially if one is a wlan device acting as an access point. Well, I might try it again if I can configure this from the web in LMCE 8.10.