[THIN] Re: slightly ot : load balancing win2k nfuse servers
- From: Brian Lilley <Brian.Lilley@xxxxxxxxxxxxx>
- To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
- Date: Tue, 9 Sep 2003 12:07:51 +0100
I have the answer...
You might be wondering "if you register a unique MAC address on each switch
port, how will the packets be delivered to all members of the array? Packets
should still be sent to the individual switch ports based on the MAC address
assigned to that port". If you're wondering how frames will be delivered to
all members of the NLB array when each switch port connected to an NLB array
member registers a different MAC address, then you're asking the right
questions.
In order to answer that question, you need to think about how the upstream
router learns the MAC address of the destination server. The router doesn't
query switch ports, it uses an ARP broadcast. When the router sends an ARP
request for the MAC address of the virtual IP address, the ARP header
contains the actual NLB MAC address and not the bogus MAC address.
Look at the packet trace information below. Notice that the Ethernet frame
reports the source MAC address in the ARP reply to be 0201AC100001. Notice
that the second octet in the MAC address is 01; this is host ID number 1 in
the array and this is a bogus unicast MAC address. Look at the ARP_RARP
header information. The ARP_RARP header shows that source MAC address to be
02BFAC100001. This is the NLB array address that accepts packets for all
virtual IP addresses bound to the array. The router uses the MAC address in
the ARP header, not the Ethernet header. The switch uses the MAC address in
the Ethernet header, not the ARP header. Pretty clever, eh?
-----Original Message-----
From: Brian Lilley [mailto:Brian.Lilley@xxxxxxxxxxxxx]
Sent: 09 September 2003 10:05
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: slightly ot : load balancing win2k nfuse servers
you the man Ron...thanks for that, it was a great help..
I'm still slightly confused...so excuse the rambling in circles...
The Microsoft documentation on NLB says something like this.... "In
multicast mode, each cluster node makes its own unique MAC address based on
the virtual IP address."
So, each port on the switch will have a unique MAC address for each machine.
If each packet is sent with that unique MAC address when returning packets
to the client machine, and subsequent packets from the client will be
addressed to that unique MAC address, then how would all cluster nodes
receive that packet? My guess is that, the server must register two
addresses on the switch, one for its unique MAC address (because the switch
can only have unique MAC addresses) and one for the multicast address which
each cluster node is listening on.
If this is the case, then sureley when the cluster nodes are sending packets
back to clients, then the source address given would be the multicast
address and not the unique address as per the Microsoft description...
I think I need to go and read some more...
Thanks for the blurb Big Ron, it has helped...
:o)
PS. Big Ron is the standard name given to the sterotypical East End of
London big gangster dude..
-----Original Message-----
From: Ron Oglesby [mailto:roglesby@xxxxxxxxxxxx]
Sent: 08 September 2003 17:37
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: slightly ot : load balancing win2k nfuse servers
Not to pound the new book but since I already had it written here is a
little blurb:
NLB has the ability to work in two different modes: Unicast and
Multicast. When activated NLB automatically places itself in unicast
mode to allow itself to be more router friendly and kinda dummie proof.
When in unicast mode NLB creates a new MAC address to use for the load
balancing operation and assigns it to the network card that has NLB
enabled on it. This then becomes the address that is used by all the
hosts in the cluster. All incoming packets are then received by all
cluster hosts, the NLB drivers are responsible for filtering which
packets are for that host and which are not.
When in multicast mode, NLB uses a multicast MAC address for the cluster
adapters. This allows the hosts to retain their existing MACs and
participate in the cluster by receiving the multicast packets.
Both unicast and multicast modes have their benefits and drawbacks. One
benefit of unicast mode is that it will work out of the box with all
routers and switches (unlike multicast). The disadvantage is that the
hosts in the cluster now all have the same MAC and IP address, due to
this fact they do not have the ability to communicate with each other
via their NLB network card. A second network card is required for
communication between the servers.
Multicast mode does not have the intra-server communication problem that
unicast operation does. The reason for this is that even though all the
hosts share the same IP and a Multicast MAC address they still retain
their original IP address and MAC for their NLB enabled network card.
The major drawback to multicast mode is that it generally requires some
manual configuration on the network infrastructure side. This is
generally the case where Cisco routers reject the ARP replies sent by
hosts in the cluster. Cisco routers see the response to the ARP request
that contains a unicast IP address with a multicast MAC address. The IOS
in Cisco routers sees this as invalid and rejects the update to the ARP
table. In order to resolve this, a manual ARP entry must be made in the
router.
Ron Oglesby
Senior Technical Architect
RapidApp
Office 312.372.7188
Mobile 815.325.7618
email roglesby@xxxxxxxxxxxx
-----Original Message-----
From: Brian Lilley [mailto:Brian.Lilley@xxxxxxxxxxxxx]
Sent: Monday, September 08, 2003 11:32 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] slightly ot : load balancing win2k nfuse servers
sorry, couldn't remember the list address for win2k bits....besides, you
lot
will probably know the answer
, well you better had or else I will stamp my feet and cry until you
do..ok
anyway..a question on network load balancing in a switched environment
I want to build two load balanced IIS servers on win2k advanced server.
I am trying to understand how NLB works in its two modes Unicast and
Multicast.
In Uni-cast I think that the cluster host responds with a unique source
mac
address and in multi-cast
the cluster host responds with a multicast address...
My confusion is this :
In Unicast mode, if the switch sees the source MAC address and then
remembers this as the MAC address
for that port, presumably all subsequent frames for that MAC address
will go
out of that specific port only??
in this case, how would all cluster hosts receive the frames??
Brian Lilley
Systems Integration
m +44 (0)7929 002501
t +44 (0)1249 665421
e brian.lilley@xxxxxxxxxxxxxx
**********************************************************************
The information contained in this e-mail message is intended
only for the individuals named above. If you are not the
intended recipient, you should be aware that any
dissemination, distribution, forwarding or other duplication
of this communication is strictly prohibited. The views
expressed in this e-mail are those of the individual author
and not necessarily those of Vivista Limited.
Prior to taking any action based upon this e-mail message
you should seek appropriate confirmation of its authenticity.
If you have received this e-mail in error, please immediately
notify the sender by using the e-mail reply facility.
**********************************************************************
_____________________________________________________________________
This message has been checked for all known viruses on behalf of Vivista
by MessageLabs.
http://www.messagelabs.com or Email: mailsweeper.info@xxxxxxxxxxxxx
Vivista formerly Securicor Information Systems for further information
http://www.vivista.co.uk
********************************************************
This Week's Sponsor: ThinPrint
http://www.thinprint.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
********************************************************
This Week's Sponsor: ThinPrint
http://www.thinprint.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
_____________________________________________________________________
This message has been checked for all known viruses on behalf of Vivista by
MessageLabs.
http://www.messagelabs.com or Email: mailsweeper.info@xxxxxxxxxxxxx
Vivista formerly Securicor Information Systems for further information
http://www.vivista.co.uk
**********************************************************************
The information contained in this e-mail message is intended
only for the individuals named above. If you are not the
intended recipient, you should be aware that any
dissemination, distribution, forwarding or other duplication
of this communication is strictly prohibited. The views
expressed in this e-mail are those of the individual author
and not necessarily those of Vivista Limited.
Prior to taking any action based upon this e-mail message
you should seek appropriate confirmation of its authenticity.
If you have received this e-mail in error, please immediately
notify the sender by using the e-mail reply facility.
**********************************************************************
_____________________________________________________________________
This message has been checked for all known viruses on behalf of Vivista by
MessageLabs.
http://www.messagelabs.com or Email: mailsweeper.info@xxxxxxxxxxxxx
Vivista formerly Securicor Information Systems for further information
http://www.vivista.co.uk
********************************************************
This Week's Sponsor: ThinPrint
http://www.thinprint.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
_____________________________________________________________________
This message has been checked for all known viruses on behalf of Vivista by
MessageLabs.
http://www.messagelabs.com or Email: mailsweeper.info@xxxxxxxxxxxxx
Vivista formerly Securicor Information Systems for further information
http://www.vivista.co.uk
**********************************************************************
The information contained in this e-mail message is intended
only for the individuals named above. If you are not the
intended recipient, you should be aware that any
dissemination, distribution, forwarding or other duplication
of this communication is strictly prohibited. The views
expressed in this e-mail are those of the individual author
and not necessarily those of Vivista Limited.
Prior to taking any action based upon this e-mail message
you should seek appropriate confirmation of its authenticity.
If you have received this e-mail in error, please immediately
notify the sender by using the e-mail reply facility.
**********************************************************************
_____________________________________________________________________
This message has been checked for all known viruses on behalf of Vivista by
MessageLabs.
http://www.messagelabs.com or Email: mailsweeper.info@xxxxxxxxxxxxx
Vivista formerly Securicor Information Systems for further information
http://www.vivista.co.uk
********************************************************
This Week's Sponsor: ThinPrint
http://www.thinprint.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
Other related posts:
