From: Winter, R. Stephen (SWinterIZZATbecu.org)
Date: Mon Jan 05 2004 - 21:31:22 EST
Mike, A quick caution before you but a second-hand pair. There is a license file on the BigIP's that is required for the software to work. If that's not there, you will need to "register" with F5 (we paid about 5k for an HA pair I think, but we wanted maintenance and everything) If you lose the hard-drive, you will need that license file, so make sure you copy it somewhere safe. Also, if you ever change the NIC, you'll have problems. The license is tied to the MAC address...
Ok.. Without the SSL card you will not be able to terminate the SSL on the Big IP. But, you can still load balance by passing the packets directly to an SSL Server. I don't remember if the F5 can read the SSL ID, but I know we did have some issues with the renegotiating of the SSL ID's, so you will need to setup a different type of persistence (mabye by source address will work for your situation)
The source address of the original packet can be retained (default unless you add the Natting). In a "normal" config, you usually only re-write the destination address to the pool member. You can NAT the source address if you want to. (and sometimes you need to). If you don't NAT, you will need the BigIP to be the default gateway. You can setup the BigIP to NAT on the way or (or not) for the pool member initiating traffic out pas the BigIP if you do have it as the default gateway... (If you don't NAT, you can set it to forward as well...)
I hope I wrote this as clearly as I saw it in my head...
-----Original Message-----
From: Michael Ferraro [mailto:mikeIZZATmyvest.com]
Sent: Monday, January 05, 2004 3:55 PM
To: lb-lIZZATvegan.net
Subject: [load balancing] F5 BigIP HA Questions
Hi,
We're about to buy a pair of F5 BigIPs in the secondary market and I had
a few questions I was hoping somebody could help us with. Since we're
not looking to buy new, we can't really have the F5 sales engineers
helping us out too much...
If the BigIP doesn't have an SSL accelerator, what functionality do we
lose aside from rapid decryption/re-encryption of traffic? Can a BigIP
still function as an SSL endpoint without the card? My impression is
no.
If the BigIP can't be an SSL endpoint w/out an SSL Accelerator card, how
would it function to load-balance HTTPS traffic? My assumption is that
it can read the SSL session ID w/out decrypting the packets, use round
robin (or another method) to distribute the connections among pool
members, and use that SSL session ID to route future requests for that
session to the same pool member. If that's true, what about IE 5.5+'s
habit of changing (renegotiating) SSL IDs periodicially? Can BigIP
v4.2.6 account for that?
When NAT'ing traffic to pool members, is the source IP address unchanged
by the BigIP? If not, I'm assuming that I have to have the BigIP's IP
be the default router for my pool members. Yuck. If the BigIP is the
default router, what about non-HTTPS traffic (e.g., SSH) originating
from the pool members -- will it simply forward that traffic, too?
Thanks in advance!
Regards,
Mike
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
NOTICE: This communication and any attachments may contain privileged or otherwise confidential information. If you are not the intended recipient or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received without printing, copying, retransmitting, disseminating, or otherwise using the information. Thank you.
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Mon Jan 05 2004 - 21:45:47 EST