Re: NLB Terminal Servers



Here's my input to your questions:


"For the "Management" NIC's should these be the only two nodes on this
Vlan?? "
-- Yes, unless you will be scaling your NLB cluster beyond 2 nodes. You can
go up to 32 nodes and each additional node's MGMT NIC should be in this
"MGMT" VLAN.

"If the clients can not reach the "Management" NIC's what purpose do they
serve? Do the "Management" NIC's act as the heartbeat for the NLB cluster??"
--In a word, "yes"

"Do you need static routes on the "Management" NIC's "
--No, in fact, you do NOT want to set gateway info for these NICs. You'll
only end up with issues if you have multiple default gateways on your
server(s).

"Why not use a cross over cable? "
--Simply, because the cross-over cable becomes a single point-of-failure

Should I use Unicast or Multicast??
-- I'll just quote the experts:
"NLB relies on the fact that incoming packets are directed to all cluster
hosts and passed up to the NLB driver for filtering. In its default unicast
mode of operation, this is achieved by NLB reassigning the station (MAC)
address of the network adapter for which it is enabled and all cluster hosts
are assigned the same MAC (media access control) address. In multicast mode,
NLB assigns a layer-2 multicast address to the cluster adapter instead of
changing the adapters station address.

Both modes of operation have their pros and cons. The advantages of unicast
mode are that it works seamlessly with all routers and layer-2 switches (and
layer-3 switches which are configured to operate in layer-2 mode). The
disadvantages are:

. Unicast mode induces switch flooding, where all switch ports are
flooded with NLB traffic, even ports to which non-NLB servers are attached;

. Since all hosts in the cluster have the same IP Address and the same
MAC Address, there is no inter-host communication possible between the hosts
configured in unicast mode.


Multicast allows inter-host communication because it adds a layer two
multicast address to the cluster instead of changing it and this makes
inter-host communication possible as the hosts retain their original unique
MAC addresses and already have unique Dedicated IP Addresses. However, in
multicast mode, the ARP reply sent out by a host in the cluster, in response
to an ARP request, maps the clusters unicast IP Address to its multicast MAC
Address. Such a mapping in an ARP reply is rejected by some routers and so
administrator must add a static ARP entry in the router mapping the Cluster
IP Address to its MAC Address"



Is it best to set the NLB from the servers themselves or use NLB Manager
from a client machine?
--Opinion time: I'd say that if you have a number of clusters, you might be
best to centrally manage your clusters from a single administrative console
(XP). This should also map to your organization's administrative model.
However, if you are a smaller operation and have a single or just a few
clusters, you might simply choose to administer using NLB Manager directly
from the nodes.


I hope this helps answer your questions...


--
Ryan Sokolowski
MVP - Windows Server - Clustering
MCSE, CCNA, CCDA, BCFP
Avanade
http://www.Avanade.com

"A troubleshooter's best tool is the Event Viewer and understanding the
events and messages contained therein."

This posting is provided "AS IS" with no warranties, and confers no rights.

"Gerald Aigenbauer" <ga@xxxxxx> wrote in message
news:ukQwWM%23TFHA.2712@xxxxxxxxxxxxxxxxxxxxxxx
> hi fog!
>
> no it doesn´t matter, the binding order should be first public, than
> privat nic.
> you can make a private vlan for cluster inside communication only, that´s
> ok. no client need to connect there.
>
> gerald aigenbauer.
>
>
> "foghorn69@xxxxxxxxxxxxxx"
> <foghorn69newspostalias@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
> news:5F9042A0-335B-4B1F-B9E8-A726A84540A0@xxxxxxxxxxxxxxxx
>> Gerald,
>>
>> I read the article. Again it seems straight forward. Does it matter if
>> you
>> use Local Area Connection 1 for the public NIC and Local Area Connection
>> 2
>> for the private NIC.
>>
>> Can you confirm my config and comment on my questions in my first post.
>> Should the private NIC cards be the only two nodes on that VLAN? Thanks!
>>
>> "Gerald Aigenbauer" wrote:
>>
>>> hi!
>>>
>>> look to that how-to... you can find here the config details for a
>>> seperate
>>> heart beat network adapter:
>>> http://www.windowsitpro.com/Article/ArticleID/23885/23885.html
>>>
>>> gerald aigenbauer.
>>>
>>> "foghorn69@xxxxxxxxxxxxxx"
>>> <foghorn69newspostalias@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im
>>> Newsbeitrag
>>> news:6BF0F9EB-B3A8-4A02-AD1E-222A13443671@xxxxxxxxxxxxxxxx
>>> > We tried to load balance our TS using a Cisco 11500 CSS since we had
>>> > some
>>> > open port that are web farm wasn't using. However, this proved to be
>>> > problematic. After reading many posts in this support group on how to
>>> > setup
>>> > NLB on Windows 2003 it seems pretty straight forward. I just wanted
>>> > to
>>> > confirm my settings before I try this again and disrupt our production
>>> > environment. I also have a few follow up questions.
>>> >
>>> > We are networked using Cisco 4500 series switches configured to use
>>> > VLAN's.
>>> > We have two TS nodes each with two NIC cards. I think one of the
>>> > problems
>>> > we
>>> > ran into last time is using one one NIC card on each TS. I was getting
>>> > unicast flooding when there is an ARP request for the MAC address of
>>> > the
>>> > virtual IP address assigned to the NLB. This was causing network
>>> > connectivity issues.
>>> >
>>> > Suggested Settings:
>>> >
>>> > Node1 - TS
>>> > Public/NLB NIC
>>> > IP address: 10.10.2.1
>>> > Subnet: 255.255.255.0
>>> > Gateway: 10.10.2.254
>>> > DNS: as appropriate
>>> > VIP Address: 10.10.2.3
>>> > VLAN: 1
>>> >
>>> > "Management" NIC
>>> > IP address: 192.168.1.1
>>> > Subnet: 255.255.255.0
>>> > Gateway: N/A
>>> > DNS: N/A
>>> > VLAN: 2
>>> >
>>> > Node2 - TS
>>> > Public/NLB NIC
>>> > IP address: 10.10.2.2
>>> > Subnet: 255.255.255.0
>>> > Gateway: 10.10.2.254
>>> > DNS: as appropriate
>>> > VIP Address: 10.10.2.3
>>> > VLAN: 1
>>> >
>>> > "Management" NIC
>>> > IP address: 192.168.1.2
>>> > Subnet: 255.255.255.0
>>> > Gateway: N/A
>>> > DNS: N/A
>>> > VLAN: 2
>>> >
>>> > For the "Management" NIC's should these be the only two nodes on this
>>> > Vlan??
>>> >
>>> > If the clients can not reach the "Management" NIC's what purpose do
>>> > they
>>> > serve? Do the "Management" NIC's act as the heartbeat for the NLB
>>> > cluster??
>>> >
>>> > Do you need static routes on the "Management" NIC's
>>> >
>>> > Why not use a cross over cable?
>>> >
>>> > Should I use Unicast or Multicast??
>>> >
>>> > Is it best to set the NLB from the servers themselves or use NLB
>>> > Manager
>>> > from a client machine?
>>> >
>>> > Thanks!!
>>>
>>>
>>>
>
>


.



Relevant Pages

  • NLB & separate RDP connection for network adapters
    ... We have two terminal servers configured as members of a NLB cluster. ... one for management and one bound to NLB. ...
    (microsoft.public.windows.server.clustering)
  • NLB & separate RDP connections for network adapters
    ... We have two terminal servers configured as members of a NLB cluster. ... one for management and one bound to NLB. ...
    (microsoft.public.windows.terminal_services)
  • Re: NLB Manager QUery
    ... Windows NT/2000/2003 Cluster Technologies ... They were trying to get Windows 2003 Multicast NLB to work ... Because NLB did not work them in Unicast mode. ...
    (microsoft.public.windows.server.clustering)
  • Re: NLB Terminal Servers
    ... Should the cluster IP address be included in the TCPIP properties under ... unless you will be scaling your NLB cluster beyond 2 nodes. ... > --No, in fact, you do NOT want to set gateway info for these NICs. ... > Should I use Unicast or Multicast?? ...
    (microsoft.public.windows.server.clustering)
  • Re: NLB fails in differnt subnets
    ... Test server NLB configurations: ... NLB Mode: Multicast with 1 NIC ... You will probably need to reconfigure using Unicast and add a second NIC for management of the NLB cluster. ...
    (microsoft.public.windows.server.clustering)