"The Linux Gazette...making Linux just a little more fun!"

Routing Revisited

From BK on Wed, 01 Sep 1999

I have placed two network cards in my system; one to a firewall and the other to a hub serving a small two systems network (I'm a newbie attempting this project.) While booting the kernel detects the two card very well; I have no IRQ confilcts or any other mishaps. I have configured the first card (eth0) using 'ifconfig eth0 192.168.0.1' and card two using 'ifconfig eth1 192.168.0.2'; now if I shutdown the system I and reboot and run 'ifconfig' it only shows me one card (eth0). How do I get the other card to remain constant?

Badiane

First problem: The 'ifconfig' command is in no way persistent. When you configure the IP address, netmask and broadcast address on an interface, that setting only lasts until the next reboot (or the next 'ifconfig').

You need to save the settings for your interfaces in a configuration file somewhere. On a Red Hat system you should find a file named /etc/sysconfig/network-scripts/ifcfg-eth0. Copy that to the name ifcfg-eth1 (in the same directory) and edit the copy. This file is a set of variable assignments which is "sourced" by one of the rc* (start up) scripts. The variables are then used in the 'ifconfig' command.

When you edit that file, it is VERY important that you remember to change the DEVICE= setting to eth1, otherwise you'll overwrite the configuration of your eth0 interface. The name of the ifcfg-* file is not correlated to device name!

Here's an example of a ifcfg-* file from one of my Red Hat systems:

DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
BROADCAST=127.255.255.255
ONBOOT=yes

In this example I'm using the lo, or loopback, interface since this system uses DHCP for its ethernet interface and consequently has no ifcfg-eth0. You want to change all of these settings as appropriate for your other subnet.

This brings us to the second and more drastic problem that you've described. The IP addresses you gave are on the same subnet. That doesn't make sense!

You could probably force it to work with a few proxyarp commands (to publish the extra IP address of eth1 on the LAN to which you've connected eth0, and to also publish the other two IP addresses on eth1's segment to the other network.

Another way to make this addressing scheme work would be to publish special host routes or each of these stray IP addresses on EVERY system on the eth0 network segment. That would also constrain you to systems which can properly handle variable length subnet masking (VLSN).

If this last two paragraphs didn't make sense to you then I suggest TWO things.

Don't do that! If you don't understand proxyarp then definitely don't want to try using it.

Read my "Routing and Subnetting 101" article (the longest I've written for LG TAG to date) at:

The Answer Guy 36: Routing and Subnetting 101

http://www.linuxgazette.com/issue36/tag/a.html

The "Routing and Subnetting 101" article will explain what a subnet is, why you want to use it and give you a few examples and tables for determining the valid ways to subnet your particular network. It will also explain ARP, proxyarp, and the use of RFC1918 addresses (which you're already using --- since 192.168.0.* is one of the Class C address blocks reserved in that RFC).

Since you are using one block of RFC1918 addresses on eth0, you can easily just use another block for eth1. So you could use 192.168.1.*. You can use any number from 1 to 255 for that third octet. You could also use 172.16.*.* on eth1 (and on the other computers/devices on that network segment).

So, solve those two problems and you're well on your way to discovering the next one. (Don't worry, those two are the only problems I can see from what you've described. So that may be enough to get the job at hand done. It's just that I've learned that we don't really solve problems so much as create new ones and, when we're lucky, delay their discovery through periods of apparent functionality).

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 46 October 1999

HTML transformation by of Starshine Technical Services, http://www.starshine.org/

		1	2	3	5	5	6
7	8	9	10	11	12