From: ORACLE ADMINISTRATOR (oraadmin@bajajauto.co.in)
Date: Thu Jul 25 2002 - 00:58:52 EDT
Hi Admins,
Thanks to,
david.ross@cantire.com
benoit.audet@edsgires.com
petergergen@kpmg.com.au
"Dave Yablonski" <dry@geisinger.edu>
For there replies...
My original posting::
Hi Admins...,
Yesterday we got message in kern.log file..
"vmunix: arp: local IP address *.*.*.* in use by hardware address"
No one was able to connect to server,Only from consol we can get log
in..
Actually we found out,that was IP address conflict..
Could you suggest possible ways to go for a solution of a problem..
Thanks.
atul
---------------------------------------------------------------------------------------------------------------------------
Replies:::
Davis Ross>>
The usual cause of this problem is that two different devices on the
network have claimed the same IP address. The Unix machine should
refuse
to bind to the address, which is why you cannot log in through it.
In the kernel log, you should see a message like this one:
Jul 24 10:37:02 SERVER vmunix: arp: local IP address 192.168.1.1 in use
by
hardware address 00-80-5F-20-16-B5
This tells you that the other device using your IP address has a
hardware
address of 00-80-5F-20-16-B5 (your addresses will, of course, be
different). All you need to do is track down the machine with that
hardware address and shut it down.
Finding that machine can be tricky. There are a few tricks that I
know
of which may help, but it really all depends on what kind of machine has
stolen your IP address.
For a unix machine, "telnet 192.168.1.1" will often bring up a login
banner telling you the server name. If telnet has been disabled,
"telnet
192.168.1.1 25" will sometimes still bring up Sendmail.
If it is a Windows box, the Windows command "NBTSTAT -A 192.168.1.1"
will
tell you the name of the machine and the user who is logged in.
Network devices like routers or terminal servers often respond to
"telnet
192.168.1.1 80" if they have a web interface, or "snmpwalk 192.168.1.1
public system" if they have SNMP enabled (you may need to install
snmpwalk
seperately -- It's part of the CMU SNMP package, but I'm not sure if it
is
in Tru64 unix).
If nothing else works, "ping 192.168.1.1" will at least validate that
the
rogue server is still using your address. You can then look up the
prefix
of the hardware address (00-80-5F in my example) and use that to find
the
manufacturer of the network card which is being used. There are
publicly
available lists of ethernet prefixes, such as
http://www-lor.int-evry.fr/~pascal/NetInfos/vendor.html, but I find that
the easiest way is to just enter the prefix itself into Google and see
what
comes up. In this case, 00-80-5F is a Compaq network card so I would
know
to look for a Compaq PC.
A network "sniffer" program, such as tcpdump or ethereal, could be
used
to capture traffic coming from the rogue hardware address. If you're
lucky, you might find something interesting there which could help you
track it down.
Of course, if the cause is a malicious user rather than a simple
mistake,
then you're on your own. An "address conflict" could be generated by
anybody with a connection to your local network just by creating an ARP
reply packet with a bogus hardware address. There really isn't any
defense
against this kind of attack, but it is uncommon since it cannot be
performed from a remote network.
Hope this helps.
--------------------------------------------------------------------------------------------------------------------------------
>>benoit.audet
Another network device is using your address on the same subnet. Catch
the
"MAC" address (hardware address) to find out which machine it is. This
is
the only way.
Good luck!
-------------------------------------------------------------------------------------------------------------------------------
>>peter gergen
Hi
Make sure all non-servers (pc's , laptops , PDAs , etc) use dynamic IP
addressing through DNS.
All servers should use static addresses and that address range should be
administered by one/two people.
Counsel users/admins who setup static ip addresses to avoid this
practice.
You can't stop this from happening again without a plan to reduce the
possibility of it occurring by taking the abovementioned steps.
Regards
---------------------------------------------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:47 EDT