On Tue, May 18, 2004 at 10:11:18AM -0600, Eric Diamond wrote:
> Tuesday, May 18, 2004 9:07 AM Kevin Kimmell replied:
....
> > All of the switches on my public network share the traffic of both
> > ranges. Therefor that same eth port on the linux box is
> > plugged in to a switch that has direct access to both ranges.
>
> The physical network (wires/switches) in this case has nothing to do
> with the why the logical network (IP) is working....
....
> 1) Gateway statements define default routes. In general multihomed
> machines don't like default routes. A default route is, by definition, a
> singular entity. THERE CAN BE ONLY ONE! That kind of cramps the style of
> most multihomed implmentations.
This is an important point.
Some multihomed systems would do well to publish a host route in many
but not all situations. Most people expect routing to center on a
hostname when it is the interfaces that have names. Host routes can
help clear up confusion here.
If you have two links with vastly different speeds it can be valuable
to set the default route to the fast line. This however does nothing
for incoming packets.
> For routers/gateways, a default route on the external interface is OK,
> but still be careful. For a multihomed server, in either fault-tolerant,
> load balanced or bandwidth intensive configurations, default routes
> defeat the purpose of creating the multiple connections.
>
> Static routes are a much better solution.
Sort of, static routes can break things as quickly as they can fix
things. If you can run a routing daemon a number of things can heal
themselves. The decision to run a daemon and what daemon depends
mostly on what your network neighbors are doing. It is important to
know that routing daemons can be setup to only listen. If the system
is running routed check the contents of the optional config file
/etc/gateways. If running another routing tool (zebra, etc, RTFM).
> > ...
> > DEVICE=eth0
> > HWADDR=00:0E:7F:37:5B:53
> >
> > [root@dtweb02 network-scripts]# cat ifcfg-eth01
> > ...
> > HWADDR=00:0C:72:30:52:53
>
> Your interface configs are for the same physical device.
For the most part specifying the hardware address is bad style. The
ideal situation is where the driver discovers the hardware address
from the hardware. Things can break badly if you inadvertently
duplicate MAC addresses. Switches get very confused....
Yes keep track of the MAC addresses you have and use, some ISPs use the
MAC address as sort of a passwd to connect. If you have to replace
hardware and your ISP has locked you to the old hardware address you
can use this functionality to get reconnected.
> >From your earlier posting
>
> > 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
> > link/ether 00:0e:7f:30:52:53 brd ff:ff:ff:ff:ff:ff
> > inet 12.168.88.12/24 brd 12.168.88.255 scope global eth0
> > inet 204.117.218.12/24 brd 204.117.218.255 scope global eth0
> > 5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
> > link/ether 00:0e:7f:30:52:52 brd ff:ff:ff:ff:ff:ff
>
> You can see that eth1 should have hardware address 00:0e:7f:30:52:52.
>
> Change that in ifcfg-eth1... Oops, you posted ifcfg-eth01. Check the
> hardware address in ifcfg-eth1 to make sure it's set to the :52 address.
> If it's not, then please post that.
Check all the links to your config files. ifcfg-eth0 could have three
locations the way I do.
$ locate ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/networking/devices/ifcfg-eth0
/etc/sysconfig/networking/profiles/default/ifcfg-eth0
On my FC1 box these are all at the same file/inode (link count =3). I
dislike tools that cannot decide on the one true location for a config
file.... ;-( and no I have no idea why I have three. Anyhow for those
that hand edit files make sure that all the links have matching content.
Different editors manage linked files differently be cautious.
--
T o m M i t c h e l l
/dev/null the ultimate in secure storage.
