Multihomed Issue

[Guest]

Situation

All our servers are W2K SP4 & the workstation in question is a W2K SP4 machine
DC1 192.168.1.
DC2 192.168.1.
DNS1 192.168.1.
DNS2 192.168.1.
DHCP1 192.168.1.
Email 192.168.1.

Client NIC1 DHCP (192.168.1.230
NIC2 Fixed 192.168.1.18
Instrument Fixed (cannot change) 192.168.1.

OUR NETWORK-----------NIC1 [Client] NIC2------------Instrumen

The Client PC is hooked up to our network through NIC1, and through the second NIC it is attached to an instrument (which is not attached to anything else, nor does it want to be able to communicate on our network

I have no end of problems when this computer boots up, I find I usually have to disconnect the second NIC from the computer. I have the following issues

1) I am not able to connect to any of the file shares on DC1 (192.168.1.1) I guess this is due to the client getting confused with it's own IP address in NIC2 (even though NIC1 is the primary NIC)? HOW CAN I GET AROUND THIS?????

2) I had to manually set DNS2 as the primary for this client otherwise it would not login properly, I guess this is the same problem as 1)

3) Login takes forever (I've not bothered waiting I just disconnect NIC2 and reboot) Is this due to NIC2 having the same address as DC1

4) I can resolve DNS names for all PC's on the network, however if I
"ping -a 192.168.1.2" I receive the instrument's name rather than the email server's - no big deal as it doesn't use email. I guess this is due to it being in the clients HOSTS file (the instrument manufacturer put it there)

However if I "ping -a 192.168.1.1" it returns DC1's DNS name rather than the clients (this is what I would expect as NIC1 has been elevated to the top of the NIC order) so why is it when I boot up there is no end of trouble? why can I not connect to the shares

All our other instruments around the lab have been configured with a class A network address, as they can be manually set, but for some reason this instruments IP address is not currently changeable

If anyone has some advice/ideas it would be greatly appreciated (I'm sure it's a simple matter (I hope)) If you require further information please contact me

Cheer
Core

 

[Guest]

The client's NIC2 IP address is set to 192.168.1.1 (SAME AS DC1) NOT 192.168.1.189, this is due the instrument only recognising that address

Cheer
Corey

 

[Phillip Windell]

Then you aren't going to be able to use that "instrument" on your network.
Not only can you not use it if the IP# conflicts with something else, but
you also don't want to run two nics in the same machine that are in the same
subnet,...that's why you have to unplug the second nic to boot it up. If the
"instrument" cannot have its configuration changed to something usable, then
it is a worthless device.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The client's NIC2 IP address is set to 192.168.1.1 (SAME AS DC1) NOT

192.168.1.189, this is due the instrument only recognising that address.

 

[Phillip Windell]

Is that the case even though the instrument is ONLY used by the client directly attached
NIC2 and only via NIC2 which is not aware of our network/servers, doesn't patch into
our existing network at all, it simply connects directly to the instrument, which cannot
communicate with other servers/clients? - ONLY NIC1 can communicate with the
network.

Not true. Two nics in the same subnet can be bridged together. But if they
are not bridged together then the very fact that they exist in the machine
on the same subnet creates conflicting entries in the Routing Table of the
OS,...hence why you have to uplug the second NIC during bootup so the NIC
doesn't foul up the routing Table.

I would have thought that if the instrument was configured as 192.168.1.2 & Client
192.168.1.1 then they could communicate between each other via NIC2 (WHICH
THEY DO) and not disturb the network? Then the Client could use NIC1 to
communicate normally with the other clients/servers?

How is it supposed to know to use NIC1 to communicate to the other clients
and servers instead of Nic2?....it can't. They are both in the same subnet,
therefore according to the routing table both are valid interfaes to the
rest of the *same* network,.... so the machine experiences an identity
crisis and starts mumbling to itself.

I would have thought that by setting up NIC2 directly to the instrument that this would
essentially be it's own little network (client->instrument).

No. Networks are not based on physical interfaces, they are based on IP
Addressing, Subnetting, and Subnet Masks.

I might not have been entirely clear when I said it takes too long to bootup, what I meant
was it boots up, I can logon but then I cannot connect to the file shares on DC1, and
there is a definate go slow for an extended period of time (basically the OS more or less
locks up)

Yep!...that's what I have been trying to tell you.

If this is the case and I cannot forcably point NIC1 in the right direction, would assigning
NIC2 a different address help? (I might be able to with the latest firmware for the
instrument).

Yep!,...an address in a *different subnet.* that's what I've been saying.
Either this "instument" has to be changed to a differnt subnet, or you will
have to re-address the whole rest of you network to make it a different
subnet than the "instrument".


I have one other little "brainstorm" that you might be able to try. I
assume this "instrument" connects to that second Nic via a crossover cable
(you never said how you are physically doing it). Take out the second NIC,
add the IP# (that the "instrument" expects to see) to the first Nic as an
additional IP# (secondary IP#). For example, it may have 192.168.1.230 for
the primary IP# and 192.168.1.1 as the secondary IP#. Then plug the
"instrument" into the same hub (or switch) that everything else plugs into.

The "instrument" should find the address it is looking for just fine and the
machine will no longer get a dazed look on its face and mumble to itself.

 

[Guest]

Thank you once again for your response, most helpful

I've been thinking on it, unfortunetly the instrument is unable to change anything other than the last octet (after I upgrade the firmware and only to the client NIC2). So I guess I would be able to change the rest of the network to say

- 192.168.2.0 address range and leave the instrument/NIC2 on the 192.168.1.0 network. (yes the instrument is connected via crossover cable

Your idea regarding the instrument into the switch would unfortunetly not work due to the instrument IP address being fixed to 192.168.1.2 (which is already used by our email server), and I would rather not have the instrument sending whatever type of network traffic it generates to the entire network

If you can see any problems with what I have said please point it out, once again I would like to thank you for your input into my problem

Cheer
Corey

 

[Phillip Windell]

I've been thinking on it, unfortunetly the instrument is unable to change

anything other than the last octet (after I upgrade the firmware and only to
the client NIC2). So I guess I would be able to change the rest of the
network to say:

- 192.168.2.0 address range and leave the instrument/NIC2 on the

192.168.1.0 network. (yes the instrument is connected via crossover cable)

That would work.

Your idea regarding the instrument into the switch would unfortunetly not work due
to the instrument IP address being fixed to 192.168.1.2 (which is already used by
our email server),

Well that shoots down that idea then, usless you want to change the IP# of
the mail server (that's easier than re-addressing the whole network)

and I would rather not have the instrument sending whatever type
of network traffic it generates to the entire network.

That wouldn't amount to "squat" and isn't worth worrying about. I wouldn't
hesitate for a second to put that thing in with the rest of the network.

 

[Guest]

Thank you for your help, much appreciated

Corey