Multihomed (not by choice) question

I have a client with an IBM server who just purchased an ISCSI enclosure for
a 3/4 terabyte raid set.

The device requires that the management port be in a different subnet than
the rest of the network. But the server it's connected to needs to talk to it
on both subnets, one for controlling the device, the other for actually
moving data to and from the array.

The server that it's on is a 2003 DC running WINS (for some legacy apps) and
DNS services. When I turned on the second NIC, I gave it only the IP address
- didn't bind anything else to it, no MS Networking, no F/P sharing. Even
went into the advanced properties, got rid of the "register with DNS" as well
as disabled netbios over tcp/ip.

I still get the IP registered though, both in WINS and in DNS. Since this is
the primary DNS server, I need to keep this second network card from adding
itself to the list.

This machine *used* to be a RRAS server as well for VPN tunnel termination,
and I had followed the KB articles for disabling DNS and WINS registration
for the RRAS adapters. But I have since moved RRAS to another non-DC machine.

I've dealt with changing binding order on NT4, but never had to deal with it
on 2000 or later - just how do I go about it?

And is there a KB article that I'm missing that will help me alleviate this?

I can't believe there's no way to have a network card with no references to
any type of name resolution or anything, so I must be missing something.

Thanks for any information.


--
John D [MVP]

Hello,

At least regarding DNS. Have you checked TCP/IP properties on the 2nd
adapter, Advanced, DNS Tab, Register this connections address in DNS is
cleared?

Hope it helps.
Ivan Torres


"JDThree [MVP]" <(E-Mail Removed)> wrote in message
news:OIzVy%(E-Mail Removed)...
> I have a client with an IBM server who just purchased an ISCSI enclosure
for
> a 3/4 terabyte raid set.
>
> The device requires that the management port be in a different subnet than
> the rest of the network. But the server it's connected to needs to talk to
it
> on both subnets, one for controlling the device, the other for actually
> moving data to and from the array.
>
> The server that it's on is a 2003 DC running WINS (for some legacy apps)
and
> DNS services. When I turned on the second NIC, I gave it only the IP
address
> - didn't bind anything else to it, no MS Networking, no F/P sharing. Even
> went into the advanced properties, got rid of the "register with DNS" as
well
> as disabled netbios over tcp/ip.
>
> I still get the IP registered though, both in WINS and in DNS. Since this
is
> the primary DNS server, I need to keep this second network card from
adding
> itself to the list.
>
> This machine *used* to be a RRAS server as well for VPN tunnel
termination,
> and I had followed the KB articles for disabling DNS and WINS registration
> for the RRAS adapters. But I have since moved RRAS to another non-DC
machine.
>
> I've dealt with changing binding order on NT4, but never had to deal with
it
> on 2000 or later - just how do I go about it?
>
> And is there a KB article that I'm missing that will help me alleviate
this?
>
> I can't believe there's no way to have a network card with no references
to
> any type of name resolution or anything, so I must be missing something.
>
> Thanks for any information.
>
>
> --
> John D [MVP]

On 2/9/2005 3:51:07 AM, "Iván Torres" wrote:
>Hello,
>
>At least regarding DNS. Have you checked TCP/IP properties on the 2nd
>adapter, Advanced, DNS Tab, Register this connections address in DNS is
>cleared?
>
>Hope it helps.
>Ivan Torres
>

Yep, did that.

Would the results be the same if I gave it a second IP on the same network
adapter? The machine isn't multihomed between two different physical networks
- just that IBM demands that the management port on this ISCSI device be on a
different subnet. It's still plugged into the same switch. If I disabled the
second network adapter and gave this other subnet IP to the first adapter as
it's second IP, would that then keep it from registering the way it does when
it's registering two? Would the primary IP address be the one it updates and
the second one just sit there and "hang on"?

Thanks


--
John D [MVP]

"JDThree [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

First,...I think you are worrying about something that doesn't even matter.
If it works and isn't causing DNS problems then leave it alone,...before you
*do* start having problems with it.

Second....
> different subnet. It's still plugged into the same switch. If I disabled
the
> second network adapter and gave this other subnet IP to the first adapter
as
> it's second IP, would that then keep it from registering the way it does
when
> it's registering two?

No. The second IP# needs to be in the same subnet as the master IP of the
Nic. Remember that this second IP# *shares* all the other network settings
with the first IP# because all other network settings are "global" for the
Nic..

Don't "share wires". Run the cable from the second Nic to the RAID unit on
a totally separate wire,...no wire sharing, no hub sharing, no switch
sharing. Unbinding uneeded services and the DNS registration as you already
have is fine,..just do that and leave it.


You said the server needs to talk to it on "both subnets". That doesn't make
any sense at all. The RAID unit does not exist on both subnets, therefore
you can not talk to it on both subnets. Since the Server exists on both
subnets it will talk to it on the subnet that is "common" to both hosts.
That is simply the way TCP/IP functions.

--

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

On 2/9/2005 11:56:32 AM, "Phillip Windell" wrote:
>"JDThree [MVP]" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>
>First,...I think you are worrying about something that doesn't even matter.
>If it works and isn't causing DNS problems then leave it alone,...before you
>*do* start having problems with it.
>
>Second....
>> different subnet. It's still plugged into the same switch. If I disabled
>the
>> second network adapter and gave this other subnet IP to the first adapter
>as
>> it's second IP, would that then keep it from registering the way it does
>when
>> it's registering two?
>
>No. The second IP# needs to be in the same subnet as the master IP of the
>Nic. Remember that this second IP# *shares* all the other network settings
>with the first IP# because all other network settings are "global" for the
>Nic..
>
>Don't "share wires". Run the cable from the second Nic to the RAID unit on
>a totally separate wire,...no wire sharing, no hub sharing, no switch
>sharing. Unbinding uneeded services and the DNS registration as you already
>have is fine,..just do that and leave it.
>
>
>You said the server needs to talk to it on "both subnets". That doesn't make
>any sense at all. The RAID unit does not exist on both subnets, therefore
>you can not talk to it on both subnets. Since the Server exists on both
>subnets it will talk to it on the subnet that is "common" to both hosts.
>That is simply the way TCP/IP functions.
>
>--
>
>Phillip Windell [MCP, MVP, CCNA]
>www.wandtv.com
>
>

I didn't say that it was working fine - the problem is, as I stated, both
cards active get me two registrations in WINS and DNS even though I've tried
to disable all services on the card that might have been involved with
registering. This of course causes problems because clients often hit the
wrong address and of course can't connect. The company has to keep going into
DNS and WINS and removing the "second" entry.

I've already got the unit connected through a crossthrough cable now - but it
doesn't keep anything from registering.

And talking on both subnets - yes, the RAID *DOES* exist on both subnets...
The management port on the device that's set for the "bogus" subnet has to be
in communication with the server - the serveraid program controls the unit
via that second adapter and non-standard subnet, while the ISCSI initiator
actually uses the common IP subnet connection to the main switch to actually
*write the data* that's going to and from the drive. So yes, it makes perfect
sense. This is ISCSI, and that's how IBM has forced this particular unit to
work. The ISCSI initiator on the server's "normal" network cannot be in the
same subnet as the management port that the server uses to control the
device.

Sorry to have asked the question - I didn't realize that ISCSI was going to
be such an unknown factor here. Should have known since even IBM had problems
getting the unit up and running because it's such a new device.

I just wanted to find out how to have a second card not register in DNS and
WINS, not be told that the device can't possibly work the way it really does.

--
John D [MVP]

"JDThree [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I didn't say that it was working fine - the problem is, as I stated, both
> cards active get me two registrations in WINS and DNS even though I've
tried
> to disable all services on the card that might have been involved with
> registering. This of course causes problems because clients often hit the
> wrong address and of course can't connect. The company has to keep going
into
> DNS and WINS and removing the "second" entry.

Ok I see. well, we may have to wait and see what other have to say about
that. I would have known to do only what you have already done.

> I've already got the unit connected through a crossthrough cable now

Good, the cross-over cable is the best way to keep that portion of it. Don't
let anyone talk you into changing that.

> And talking on both subnets - yes, the RAID *DOES* exist on both
subnets...
> The management port on the device that's set for the "bogus" subnet has to
be
> in communication with the server - the serveraid program controls the unit
> via that second adapter and non-standard subnet, while the ISCSI initiator
> actually uses the common IP subnet connection to the main switch to
actually
> *write the data* that's going to and from the drive. So yes, it makes
perfect
> sense. This is ISCSI, and that's how IBM has forced this particular unit
to
> work. The ISCSI initiator on the server's "normal" network cannot be in
the
> same subnet as the management port that the server uses to control the
> device.
>
> Sorry to have asked the question - I didn't realize that ISCSI was going
to
> be such an unknown factor here. Should have known since even IBM had
problems
> getting the unit up and running because it's such a new device.

Relax, you are talking about a network that you can see, feel, and touch
and you know how you built it. While I am talking about a network I have
never seen and have no background knowledge of and have no information on
other than a few lines in an email about a device I have never heard of. so
you will have to allow me a little "catch-up time".

Network Engine's NS6300 Firewall works just like you describe. It has a LAN
interface and a management interface (different subnets). The management
interface connects to a second Nic in a "management" computer. It works
perfectly fine, however the management computer is not a DC running DNS/WINS
and "routing" is not enabled, so the rest of the network never even sees the
management segment and nothing ever gets registered,...so all is happy.
Once the initial setup is done it can be configured to allow management on
any other port so the "management port" is no longer needed and can be
disconnected.

I don't really see a way around your problem if the DC is going to be *both*
the machine that actually uses the Array as a logical drive,..and as the
management machine at the same time. how about finding an innocent
workstation to function as the management machine and have the two nics in
it,..that would solve the whole registration issue. In similar situations I
just have a laptop that I carry around as a "management device" and just
temporarily hook it up to things like that when I need to change
something.What does IBM have to say?,...surely they have run into this issue
and already have a solution developed for it.


--

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

"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> never seen and have no background knowledge of and have no information on
> other than a few lines in an email about a device I have never heard of.
so
> you will have to allow me a little "catch-up time".

What exactly are you using anyway? All I know is "ISCSI" and "RAID", you
haven't told me anything else. Are we talking about a DS6000 Series or
what? Have you checked thier Support Site for any deployment environment
recommendation & warnings or a list of any "gotcha's" that will bit you in
the rear if you don't watch out for them? Like I said in the other
post,..surely they know of the issue,..you can't be the first to experience
it.

--

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

On 2/9/2005 3:03:01 PM, "Phillip Windell" wrote:
>"Phillip Windell" <@.> wrote in message
>news:(E-Mail Removed)...
>> never seen and have no background knowledge of and have no information on
>> other than a few lines in an email about a device I have never heard of.
>so
>> you will have to allow me a little "catch-up time".
>
>What exactly are you using anyway? All I know is "ISCSI" and "RAID", you
>haven't told me anything else. Are we talking about a DS6000 Series or
>what? Have you checked thier Support Site for any deployment environment
>recommendation & warnings or a list of any "gotcha's" that will bit you in
>the rear if you don't watch out for them? Like I said in the other
>post,..surely they know of the issue,..you can't be the first to experience
>it.
>
>--
>
>Phillip Windell [MCP, MVP, CCNA]
>www.wandtv.com
>
>

IBM's new DS300. Used to be normal RAID controlled, but now it has this ISCSI
flavor with no other connectivity. I've gone right to the IBM top gun I know
in my area who bypassed me up their support food chain to the level where you
normally can't get at unless you're paying money, totally independent of any
warranty work and such. They were also unable to get it to work, other than
to tell me "it needs to be this way and we don't know why the initiator won't
work."

I finally got the initiator working myself, and all works fine from the RAID
standpoint, I just can't get the IP to not register.

Still waiting for more from IBM. But it seems it's so new that even they
haven't worked out the bugs yet...

I just wish the client would put this on a file server rather than their
exchange server. We could hang it off anything since the only thing they want
to use it for is file storage. I'm still fighting that battle with them.
They have four servers, one which is going away (the only 2000 machine left
in their domain, a DC). I'd rather hang this off a member server if it's only
going to hold file shares from the server they're getting rid of...



--
John D [MVP]

"JDThree [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> in their domain, a DC). I'd rather hang this off a member server if it's
only
> going to hold file shares from the server they're getting rid of...

That would be the best way, because your issue stems from the fact that it
is running on a machine that also runs DNS (the DC). If you run it on a
machine that does not run DNS it will probably work fine.

Maybe MS Support can sort out why it won't stop registering,...I don't know.

--

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