Strange network thing

[Stuart Biggerstaff]

Thanks.  Controlling which onboard NIC gets configured is certainly a
more elegant way of bypassing this issue than physically connecting to
an empty network to bring up the interface.  (Also facilitates remote
admin if reloading the network doesn't suddenly disconnect you.)  I was
ultimately going in that direction--but holding off till I had given
finding the remote system causing the problem a chance.

I would tend to think the same thing would happen if we tried to replace
one of these servers in the DMZ, but we haven't seen it before and we
have replaced a Windows server there with new iron and swap our Linux
web server with its backup about every six months to a year.

My hunch is the culprit is a particular router, as I find nothing to
show that the erroneous MAC is cached at the local switch or the
firewall appliance, but it's also the only piece I can't easily get into
from my desktop.

And since the whole firewall setup is due to be replaced this year,
trying to trace this is probably buying trouble.


Stuart Biggerstaff
Systems Technician
Linda Hall Library of Science Engineering & Technology
5109 Cherry St.
Kansas City, Missouri 64110-2498

Phone:	(816) 926-8748
	(800) 662-1545 x748
FAX:	(816) 926-8790
URL:	www.lindahall.org 
-----Original Message-----
From: linux-users-bounces at linux-sxs.org
[mailto:linux-users-bounces at linux-sxs.org] On Behalf Of Ben Duncan
Sent: Friday, March 07, 2008 8:50 AM
To: SXS Linux Users sxs
Subject: RE: Strange network thing

Hmmm .. could it be udev is doing something ?

Have run into that cloning disk drives on identical machine. Turns out I
am using udev (which all in all is pretty neat), and the entries where
getting fixed.

See if you have a directory  called /etc/udev/rules.d See if there is
something in it like network-devices.rules.
You might have to fgrep for eth in the files to find it since udev rules
can be automagically generated.

In the network file you might something like this:


# Local network rules to name your network cards.
#
# These rules were generated by nethelper.sh, but you can # customize
them.
#
# You may edit them as needed.
# (If, for example, your machine has more than one network # card and
you need to be sure they will always be given # the same name, like
eth0, based on the MAC address) # # If you delete this file,
/lib/udev/nethelper.sh will try to # generate it again the next time
udev is started.

KERNEL=="eth?", ATTR{address}=="00:1b:b9:d9:c8:da", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:2b:29:29:d1:ab", NAME="eth1"

These are going to set the ethernet cards as defined based upon MAC
address.

In my case, all the CLONED hard disks machines where ALWAYS using eth1
instead of etho. After deleting the first line, and changing the second
everything worked as it should ...

As usual your mileage may vary ....





> Answering Lonni's questions, both the original IP and the new one are 
> fixed, and if I ping this IP with the system down or the network 
> interface down, no response.
> 
> As the NIC comes up fine when it's the only thing on the network, I 
> have to assume that it is finding something that tells it the IP is
taken.
> If that was the local ARP cache (for instance), that wouldn't make a 
> difference.  Querying ARP on the other hosts in the subnet, and on the

> firewall appliance, I don't find anything--same for looking in the 
> configuration on the switch it plugs into.
> 
> Actually, when I changed the IP, I changed the gateway address but 
> probably not the actual gateway.  The network port was moved into a 
> different VLAN.  But the problem started not with that but when I 
> disabled the unused second NIC in the OS.  When I did that, the NIC 
> that came up with the active configuration was in fact the one 
> originally designated the second one.  That meant the IP was on a 
> different MAC address, and appparently something it is querying when 
> it tries to load "remembers" the old MAC the IP was associated with.
> 
> What I've been looking for is a diagnostic that would identify where 
> it's happening.
> 
> 
> Stuart Biggerstaff
> Systems Technician
> Linda Hall Library of Science Engineering & Technology
> 5109 Cherry St.
> Kansas City, Missouri 64110-2498

--
Ben Duncan - Business Network Solutions, Inc. 336 Elton Road  Jackson
MS, 39212 "Never attribute to malice, that which can be adequately
explained by stupidity"
        - Hanlon's Razor
_______________________________________________
Linux-users mailing list ( Linux-users at linux-sxs.org )
Unsub/Password/Etc: 
http://linux-sxs.org/mailman/listinfo/linux-users

Need to chat further on this subject? Check out #linux-users on
irc.linux-sxs.org !