TBH this is something I have never tested in great detail and would normally use NLB if failover is the priority. However, this customer is being very specific about failover and test plans :-\ -----Original Message----- From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder Sent: 27 May 2006 14:32 To: isapros@xxxxxxxxxxxxx Subject: [isapros] Re: Array Member Failover Jason, I'm afraid Jim's right here. While the marketing materials and stories make CARP appear to be a failover and back tech, we know from long experience that it does work that way :\ Tom Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://blogs.isaserver.org/shinder/ Book: http://tinyurl.com/3xqb7 MVP -- ISA Firewalls > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > Sent: Friday, May 26, 2006 2:49 PM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: Array Member Failover > > WPAD is not designed to provide failover/back. > As you've noticed, this is not going to work. > WPAD is nothing more or less than a "load-spreading" mechanism that > allows the client to use a different ISA for different destinations. > > If you want failover/back, use NLB or another traffic-management > system. > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] > On Behalf Of Jason Jones > Sent: Friday, May 26, 2006 12:42 PM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: Array Member Failover > > Cheers Tom - unfortunately closing the browser doesn't seem to fix the > problem...IE still trys to connect to the primary autoconfig defined > server first then eventually use the other array members (after about > 20-30 seconds). This behaviour seems to happen repeatedly on all > clients fdor every new URL entered > > The only way to fix it is to bring the failed server back online :-( > > ________________________________ > > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] > On Behalf Of Thomas W Shinder > Sent: 26 May 2006 12:18 > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: Array Member Failover > > > Hi Jason, > > Not too low brow for me :) This is a common question with a common > non-answer in the public realm. > > What you need to do is close all browser windows and open a new one. > Then the client connects to a live server. I've never worked out in > detail why this happens, but it's related to the autoconfig script > processing [hand waving explanation] > > Maybe somebody else can chime in with a more detailed explanation. > Bottom line is that you're not going to get completely transparent > failover for Web proxy clients. > > Tom > Thomas W Shinder, M.D. > Site: www.isaserver.org <http://www.isaserver.org/> > Blog: http://blogs.isaserver.org/shinder/ > Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> MVP -- ISA > Firewalls > > > > > ________________________________ > > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > Sent: Thursday, May 25, 2006 4:44 PM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Array Member Failover > > > > Hope this question is not too low brow, if so, kick me and I will > move it to isaserver.org for the masses to mull over ;-) > > Anyhow, has anything changed with array member failover behavior in > EE with ISA2k4 SP2? I am sure I have never had problems with array > member failovers in the past... > > I have recently deployed an SP2 array with several members and while > testing I have noticed that if the server listed as the first entry > defined within the wpad.dat file is unavailable then the browser > delays for quite some time before attempting to connect to other array > members (e.g. working through the server list in the wpad.dat file). > It does seem to get there, but we're talking 20 seconds or so per > website. > Once the website is loaded, performance is fine. When using a new URL, > the delays appears again. > > Apart from failover, balancing and distr caching seems to be working > well. I know I could be using NLB, but I believe the following to be > good practice: > > Web Proxy => Autoconfig script (client side CARP) > FW Client => RR DNS > > I am using a generic name of customerarray.domain.com with RR DNS > entries to balance autoconfig requests between array members. This is > the name used in the autoconfig URL. > > I know NLB may come to mind as a workaround, but it is hard to > implement as the customer is using NIC teaming at the hardware driver > level to aggregate NICS and provide NIC fault tolerance. NLB and NIC > teaming never play well from what I have experienced :-( > > Can someone please define normal behavior for a client that is using > an autoconfig script when array members are unavailable? I kinda get > the feeling the problem is with the browser and not the array, but not > totally sure when IE does with the script in terms of processing... > > I've tried looking at wpad.dat caching and caching of bad proxies, > but neither seems to make much difference... > > Any ideas? > > JJ > > > All mail to and from this domain is GFI-scanned. > > > >