This is a summary of the general issues which we have with Network
Dispatcher. Details have been forwarded to IBM.  We have a simple
network configuration.  I am beginning to think ND is overkill for
what we want.

Can anyone volunteer working examples of Dispatcher configured to load
balance over two web servers with session persistence and Apache
server failover on the same subnet.  We have only been able to get MAC
based routing without session persistence or failover.

1.	MAC Based Routing.

MAC based routing is our preferred solution but testing indicates that
MAC routing does not provide session affinity and server failover.
The load balancer must direct existing browser sessions to the same
web server and only redirect browser sessions if the target web server
becomes unavailable.  It seems that Dispatcher requires content based
routing as a prerequisite for session persistence on the target
server.

HTTP Advisors do not work with MAC based routing.  They return  a load
value of -1 hence they don't detect server failure and Dispatcher
attempts to forward requests to the dead apache server.    HTTP
Advisors only work with content based routing.

2.	Content Based Routing.

Dispatcher Content Based Routing cannot handle an Apache Named Virtual
Host configuration on the loadbalanced web servers.  Named Virtual
Hosting requires a locally resolvable server name on the Apache Server
and the client must supply the HTTP Host header as required by
HTTP/1.1.  Under CBR routing the destination IP(cluster IP submitted
by the client) does not resolve to the local Apache server hostname as
the cluster IP is not defined locally.  Named Virtual Hosting works
with MAC based routing as the cluster IP is defined locally via the
loopback interface.  Packet analysis indicates that Dispatcher is not
forwarding the Host header hence Apache cannot find the corresponding
virtual host name and defaults to the first virtual host entry in the
list.

E.G.

Running Network Dispatcher 4.0.3 on Windows 2000 Server.

Dispatcher is configured to load balance across two IHS webservers on
the same subnet.

The web servers are configured to host multiple virtual sites.  E.G

Apache Config.

<VirtualHost 192.1.2.3>
ServerName server1.com.au
</VirtualHost>

<VirtualHost 192.1.2.35>
ServerName cluster.com.au
</VirtualHost>

server1.com.au resolves to the local IP address 192.1.2.3.

cluster.com.au resolves to the cluster IP address 192.1.2.35 aliased
on the Dispatcher machine.  Apache will fail to resolve cluster.com.au
unless there is a web server running on that IP.  In any case
"ServerName" is not supplied in the host header so Apache defaults to
server1.com.au.























HTTP logs indicate that

f you are using name-based virtual hosts, the ServerName inside a
<VirtualHost> section specifies what hostname must appear in the
request's Host: header to match this virtual host.

The http log indicates that Dispatcher is not forwarding the Se
gatWhen examining the packets

[ Post a follow-up to this message ]

> 1.	MAC Based Routing.
>
> MAC based routing is our preferred solution but testing indicates that

MAC based forwarding does not have access to the actual data in the
packets.  It simply looks at the TCP layer (IP and MAC addresses) to
perform routing and can only base client affinity on that information.
Thus it has client IP based affinity (client A always goes to Server B
if the client sends requests within the affinity timeout).

CBR is a proxy and therefore adds the overhead of looking at the actual
protocol layer data.  It can use affinity based on Cookies, on headers,
URIs, etc.

> 2.	Content Based Routing.
>
> Dispatcher Content Based Routing cannot handle an Apache Named Virtual


I'm not clear whether you're trying this or not because the note gets
truncated, but if you set up CBR, the Apache servers would need Virtual
Hosts for their local names (however many you want to alias on the box
and put into the CBR port:server assignments).  If you set up MAC, then
at least one Virtual Host must be for the cluster.  Any others are not
used in that particular MAC port forwarding, but could exist for other
purposes (testing direct to a server, other cluster:ports, etc).

[ Post a follow-up to this message ]

JLee <leeja@NOSPAMus.ibm.com> wrote in message news:<4068AD23.5030905@NOSPAMus.ibm.com>...[
color=darkred] 
>
> MAC based forwarding does not have access to the actual data in the
> packets.  It simply looks at the TCP layer (IP and MAC addresses) to
> perform routing and can only base client affinity on that information.
> Thus it has client IP based affinity (client A always goes to Server B
> if the client sends requests within the affinity timeout).
>
> CBR is a proxy and therefore adds the overhead of looking at the actual
> protocol layer data.  It can use affinity based on Cookies, on headers,
> URIs, etc.
> 
>
>
> I'm not clear whether you're trying this or not because the note gets
> truncated, but if you set up CBR, the Apache servers would need Virtual
> Hosts for their local names (however many you want to alias on the box
> and put into the CBR port:server assignments).  If you set up MAC, then
> at least one Virtual Host must be for the cluster.  Any others are not
> used in that particular MAC port forwarding, but could exist for other
> purposes (testing direct to a server, other cluster:ports, etc).[/color]

I resolved these issues after some low level packet analysis.  There
were three problems.

1.  Return Address Incorrectly Specified.
 ****************************************
*******
In a cbr configuration the return address is used as the source IP
address in the http packet sent from the Dispatcher server to the web
server.

ndcontrol server add 192.0.8.45:80:192.0.8.41 address 192.0.8.41
router 192.0.8.250 returnaddress 192.0.8.90

The web server replies to the source ip rather then directly to the
browser client.  I configured the return address on the Dispatcher
server by adding the ip via the windows network
connections/properties/advanced dialog which is the usual way of
configuring an alias IP in Windows 2000.

########
Example
########

iceland		192.0.8.32	client ip

europe		192.0.8.45	virtual cluster ip defined on norway

norway		192.0.8.46	dispatcher server NFA/nic physical ip(resolves to
hostname)
norway		192.0.8.90	return address aliased to nic physical ip

sweden		192.0.8.40	webserver1
denmark	        192.0.8.41	webserver2

www.europe.com	WebSite cluster URL.

A local host file entry on the client Iceland  resolves www.europe.com
to the cluster ip 192.0.8.45.
Ping   www.europe.com ----> 192.0.8.45

To keep things simple disable web server on denmark
Open browser on iceland and enter www.europe.com

Packet analysis on norway indicates receipt of http requests with
source ip iceland and destination ip norway.
Packet analysis on sweden indicates no traffic from norway.

There is no traffic because the return address ip 192.0.8.90 is a
local ip on norway and Windows will not forward traffic on this ip.
The return address needs to be defined as a virtual ip within the
cluster in the same way as the cluster ip.

ndcontrol cluster configure 192.0.8.45 en0 255.255.255.0
ndcontrol cluster configure 192.0.8.90 en0 255.255.255.0

Like the cluster ip, the return address ip is only available when
Dispatcher is running on the Dispatcher server.

2.  Return Address Not Specified.
***************************************

The Java GUI tool is handy because it auto generates the correct
config file commands which can be obtuse.  However when the config
file is updated via the GUI it overwrites any entries that have been
added manually such as the return address definition.  If the machine
is bounced and the config file reloaded the return address is not
defined.  it needs to be configured in a separate script that executes
on startup and is not editable by the gui.  I edited the config file
via the GUI and bounced the machine several times.

3.  Virtual Host Mappings.
******************************
The virtual host entries were incorrect for a cbr routing scenario.
They were initially configured for MAC routing and needed to be
changed.

############################
Example.   MAC routing.
############################

Web servers are Sweden and Denmark.

sweden		192.0.8.40	webserver1
denmark	        192.0.8.41	webserver2

Each server has two virtual host entries using named virtual hosting,.
The virtual host address mappings on the web servers DO NOT resolve to
the same local ip.

E.G Sweden.

www.sweden.com	192.0.8.40
www.europe.com	192.0.8.45

Sweden:

VirtualHost 192.0.8.40>
ServerName www.sweden.com
..........
</VirtualHost>

<VirtualHost 192.0.8.45>
ServerName www.europe.com
..........
</VirtualHost>

Denmark:

VirtualHost 192.0.8.41>
ServerName www.sweden.com
</VirtualHost>

<VirtualHost 192.0.8.45>
ServerName www.europe.com
</VirtualHost>

I open a browser on Sweden and enter www.sweden.com which resolves to
192.0.8.40 via a local host file dns entry.  The home page is
displayed.
I open a browser on Sweden and enter www.europe.com which resolves to
192.0.8.45 via the local loopback adapter configured on Sweden for MAC
routing.  The home page is displayed.
I open a browser on the remote client Iceland and enter www.europe.com
which resolves to 192.0.8.45 via a local host file dns entry.  Iceland
attempts to locate 192.0.8.45 by arp address resolution on the local
subnet and finds the cluster ip running under Dispatcher on Norway(NB:
loopback adapters do not respond to arp requests).  ND on Norway
forwards the packet to Sweden using source ip Iceland(192.0.8.32) and
destination ip Sweden(192.0.8.40).  The web server on Sweden replies
directly to the source ip Iceland.  The packet from Sweden will have a
source IP of Sweden so the conversation continues between Sweden and
Iceland.  Norway is out of the picture.

############################
Example.   Dispatcher cbr routing.
############################

Web servers are Sweden and Denmark.

sweden		192.0.8.40	webserver1
denmark	        192.0.8.41	webserver2

Each server has two virtual host entries using named virtual hosting.

Sweden:

VirtualHost 192.0.8.40>
ServerName www.sweden.com
..........
</VirtualHost>

<VirtualHost 192.0.8.40>
ServerName www.europe.com
..........
</VirtualHost>

Denmark:

VirtualHost 192.0.8.41>
ServerName www.sweden.com
</VirtualHost>

<VirtualHost 192.0.8.41>
ServerName www.europe.com
</VirtualHost>

The virtual host address mappings on the web servers BOTH resolve to
the same local ip.

E.G Sweden.

www.europe.com	192.0.8.40
www.sweden.com	192.0.8.40

I open a browser on Sweden and enter www.sweden.com which resolves to
192.0.8.40 via a local host file dns entry.  The home page is
displayed.
I open a browser on Sweden and enter www.europe.com which resolves to
192.0.8.40 via a local host file dns entry.   The home page is
displayed.
I open a browser on the remote client Iceland and enter www.europe.com
which resolves to 192.0.8.45 via a local host file dns entry.  Iceland
attempts to locate 192.0.8.45 by arp address resolution on the local
subnet and finds the cluster ip running under Dispatcher on Norway.
ND on Norway forwards the packet to Sweden using source ip
returnAddress(192.0.8.90) and destination ip Sweden(192.0.8.40).  The
web server on Sweden replies directly to the source ip
returnAddress(192.0.8.90).  Dispatcher on Norway forwards the packet
to Iceland.  The conversation continues between Iceland and Norway
with Norway forwarding the packets to Sweden.

[ Post a follow-up to this message ]